UPDATE PROCESS

Update Process is used to Update the Database.when more than one transnational Dialog steps are involved in a Transaction Then Dialog Updates them in Temporary tables which are updated into Main tables by Update Process.
When Ever a Direct Update is performed on the Database then rollback is not possible.
Local Update: The Dialog Process Updates the Database main tables directly if there are few transactional dialog steps.
Background Process communicates directly with the database and updates the Data.Background Process Updates all the transactional dialog steps in one go into the Database main tables.
Synch Update: Once all the Transactional Dialog steps are committed to the Temp tables then they are updated into Database Main Tables Synchronously. Synch Updates are performed by a dedicated Update Process.
Asynch Update: the Process of updating the temp tables by a dialog process until a commit/roll back is made.
Update Processes(TYPES):
There are three types of Update Processes:
V1: it is used to handle v1 updates(time critical Updates)
V2: it is used to handle v2 updates(non-time critical updates)
V3: BW Updates or massive updates.(currently reserved by SAP)
Update Process Flow:
  1. User Submit the Request for an Update (ex: A Sales Order Creation, User Creation, Purchase Order Creation)
  2. Dialog Process Handles the request and when it identifies the Update then it communicates with Enqueue Process.
  3. Enqueue Process Provides a Lock on the record so that the record will not be available for update and it can be displayed in SM12 until a commit is made.
  4. The Dialog Process Updates all the transactional dialog steps into temporary tables VBHDR, VBDATA, VBMOD, and VBERROR.
  5. Once all the dialog steps are completed then a Commit or roll back takes place. if a commit takes place then a Transaction ID is generated from the Number Range table(NRIV) and the Records are displayed in SM13.The Locks are inherited to update process.
  6. The Update Process reads the temporary tables and Updates the Permanent tables synchronously.Upon Update, the Enqueue Locks are released.
Update Statuses:
Initial(init): When the Dialog Process Completes writing into temp tables and when a commit is made then the records are displayed in SM13 with status ‘init’
run: when the update process updating permanent tables then the status is ‘run’.
error: if the update is terminated then the records are displayed with status ‘error’
AUTO: if the update error is resolved then the system starts the updates automatically using the status ‘AUTO(sys)’
AUTO(DIA): if the update error is resolved then the system start the updates automatically,if they are not started then they can be repeated in SM13 where the status will be ‘AUTO(DIA)’
Note: if v2 processes are not available then v1 update handles the v2 updates.
For every 5 Dialog Processes, one Update Process is required.
Update Processes are configured by using the parameter
rdisp/wp_no_vb=2(v1 Updates)
rdisp/wp_no_vb2=2(v2 Updates)
Number Ranges: These are defined in Transaction SNRO and stored in the table NRIV.
Ever transactional Object has to be defined with the number range during Implementation else SM13(Update)Errors Occurs.
Dialog Process Checks for a Number from the Number Range Interval and Commits the Transaction with that Number in the Temp Tables.
The Update Process Updates the Application(Permanent Tables) with the Transaction ID.
Update Deactivation:
The Update Process gets Deactivated whenever there is a problem in the Database such as Tablespace Overflow, Max Extents Reached, Oraarch directory is full.
The Database Administrator has to resolve the issue, once the issue is resolved the update mechanism can be reactivated.
Do not Deactivate the Update Process Manually in SM14 unless a problem in the database is noticed, else documentation needs to be provided for system log(update terminated manually with a user id, time stamp)
Update Deactivation stuck the entire SAP System.
Set the Parameter rdisp/vb_stop_active to disable the above feature.
set the Parameter rdisp/vbmail=1 to notify the users in case of an update error.
Update Reorganization:
  1. Run the Program RSM13002 to delete the old Updates(Earlier this Program used to run in BTC Mode, SAP Recommends to run this program in Dialog Mode and fails(not allowed)to run in BTC mode)
  2. Set the parameter rdisp/vbreorg=1. it is used to delete the Incomplete Update Requests when the server is restarted.
  3. Set the parameter rdisp/vbdelete=50 . it is used to delete the old update requests based on the Age irrespective of the Status.
  4. Delete Records Manually from SM13(Care full of the current Updates).Generally not recommended as no logs and traces are run to track what has been deleted.
Monitoring the Updates:
Execute SM13 to Monitor the Updates. Ensure that there are no pending Updates or standing updates unless it is a massive update System
SAPSQL_ARRAY_INSER_DUPREC
This is very known dump occurs in a production environment. This dump occurs when any transaction or job is trying to insert duplicate records into a table.Check whether this error is caused by the user or the program
Check whether the Update is terminated in a Local Customer Program if required Correct the Program.If the issue is global such as program error which is occurring after the installation, after an add-on, after a support package, after an upgrade, after a kernel patch update/upgrade, refer the issue to SAP Support with High Priority. SAP Provides an interim note or patch to resolve the issue.While reporting an issue to SAP Check SM21, ST22 and Failed Module in SM13 with Error Message.
Cancelled Updates can be repeated by using the option Repeat Update.
Most of the Cancelled Updates May comes with an error(no retry).
If the Record Does not exist in the system then ask the User to create the transaction again.
Resolve any database issues when the updates are pending or stuck with certain errors like ora-1629,30,31,51,52,53,54 and ora-255,272 which are specific to Oracle database.The Resolutions(corrective measures) are available for Oracle errors in DB17
Update Function Modules are not found and Update gets terminated

Comments

Post a Comment

Popular posts from this blog

SPOOL WORK PROCESS

Spool Process: It is the Only Process that is used to output the documents to a Printer, fax, email etc.. Spool Work Processes are created by using parameter risp/wp_no_spo=1 it is possible to configure more than one spool work process based on available resources. Spool Process Work Flow: User Submits the request to print a Document. The Dialog Process handles the request and print directly or schedules to print in the background.The Print requests are stored in the TemSe(Temporary Sequential Files) Temporary Sequential Files are stored either at File System or at database Level which is defined by parameter rspo/store_location. rspo/store_location=”G” or ‘DB’ G means global directory stores the TEMSE in /usr/sap/SID/SYS/global db mean the Tables TST01 and TST03.(TST01 Contains Print Attributes and TST03 Contains the Spool Data to be Printed) Due to Spool in DB the DB Size Increases, as a Result, the backup time increases and Tapes may not fit with the data for S...
Read more

ENQUEUE WORK PROCESS

It is used to lock and unlock the Objects during an update.These locks are displayed in SM12 and Held for longer hours until the transaction is committed or rollback.These locks are issued from a lock table which resides in the main memory of the instance where enqueue process is created/located. Enque Processes are configured by parameter rdisp/wp_no_enq=1. Generally One Enque Process for instance is sufficient,more then one is required in a massive update system. The Lock table size on the memory ranges between 4mb to 100 MB(200 MB in the Net weaver 7.3 Systems ) It is defined by parameter enque/table_size=4 to 200 MB. For 4mb of enqueue table size, the Number of lock/owners/objects/arguments can be restricted up to 3715. Enqueue Flow: User submits the Request for an Update. The Dialog or Background Process Handles the Request Dia or BTC Processes communicates with Enqueue Process and obtains a lock on the record so that no other user has to write access to that r...
Read more

DIALOG PROCESS

Dialog Process: It is the only process that is used to communicate with end users Interactively using Classic GUI or Through RFC or through Http Protocol. The Average Response Time for each dialog step is 600 ms.it is displayed through ST03n Each Process can execute up to a maximum runtime of 600 seconds.if any process goes beyond this time an additional time of 60 seconds is given and the process is timed out.(ST22)(it is not mandatory to allocate additional 60 seconds Each Process Serves 5-10 users.(Calculated based on ST07) Each Process Requires 75mb to 300 mb Memory Each Process can Handle the requests that are initiated for background, spool & update and update them in temporary tables. Dialog Process is not restricted to a User and Users are not restricted to a process which is referred as process multiplexing Parameters to configure dialog processes is rdisp/wp_no_dia There should be at least minimum two dialog processes and maximum up to 100 processes. The ...
Read more