10 Locks In an SAP system, many users can simultaneously read the contents of database tables. However, for changes to the dataset, you must ensure that only one user can change a particular table's content at a time. For this purpose, table content is locked during a change operation. The first section of this chapter introduces you to the concept of locking for SAP and database systems. If locks remain in place for a long time, wait situations can occur, which limit the throughput of the SAP system. The second part of the chapter deals with the general performance aspects of using locks. The SAP system uses special buffering techniques for availability checking with ATP logic, and for document number assignment. These techniques (discussed in Sections 10.3 and 10.4) reduce lock time and can maximize throughput. When Should You Read this Chapter? You should read this chapter to help you: > Find out more about database locks and SAP enquewes > Analyze system problems that are caused by database locks of enquewes This chapter does not offer instruction on programming SAP transac- tions. Use ABAP textbooks or SAP Online Help for this. 404 Database Locks and SAP Enqueues To book a vacation, you must check that all necessary components are available: flights, hotels, bus or boat transfers, and so on. The “all or nothing" principle applies: I'no flights are available, you will not need a hotel room and so on. Since you usually check the availability ofthe var 455 lex]10 Locks fed fed ous components one after the other, you want to be certain that another user doesn't change any of the items in the sequence before the entire booking is completed. You can use locks to do this, which preserve data consistency. The locking concepts of SAP and database systems have the same ultimate purpose of preserving data consistency, but they are based on different technologies and used in different situations. Locks that the database system manages are known as database locks, and locks that the SAP system manages are known as SAP enqueues. 1011 Exclusive Lock Waits The lock handler of a database instance manages database locks. The locked entity is typically a row in a database table (special exceptions are detailed later). Database locks are set by all data-changing SQL state- ‘ments (UPOATE, INSERT, DELETE) and by the statement SELECT FOR UPOATE. Locks are held until the SQL statement CO%™!7 (database commit) final- izes all changes and then removes the corresponding database locks. The time interval between two commits is called a database transaction. A program can undo the effects of all modifying SQL statements by execut- ing a database rollback with the SQL statement R0.L84C. In this case, all database locks are also removed. ‘A program that uses database locks to make a travel booking, for exam- ple, would use the SQL statement SéLECT FOR UPDATE. A particular item of travel data is read and locked with this statement. When each relevant data item has been read and the booking is ready to be made, the data is changed in the table rows with the command UPDATE, and then the COvMIT command is used to finalize changes and release all locks. Once lock has been set, other users can still read the affected data (a simple SELECT is still possible), but they cannot lock it. Therefore, they cannot perform an UPDATE or SELECT FOR UPDATE, which means the original lock is exclusive. After a transaction step, the SAP work process automatically triggers a database commit (or a database rollback). This removes all locks and means a database lock does not last through multiple transaction steps (through multiple input screens in the SAP system). 496Database Locks and SAP Enqueves | 104 1042 SAP Enqueues To lock through several SAP transaction steps, use SAP enqueue admin- istration. Work processes in the enqueue table, located in the main memory, manage SAP enqueues. To retain these enqueues even when an SAP instance is shut down, they are also saved in a local file on the enqueue server. ‘An SAP enqueue locks a logical object. Therefore, an enqueue can lock rows from several different database tables if these rows form the basis of a single business document. An SAP enqueue can also lock one or more complete tables. SAP enqueue objects are defined and modified in the ABAP dictionary (dictionary section Lock Objects. They are closely related to the concepts SAP transaction and logical unit of work (SAP LUW). Both of these are described extensively in the ABAP literature for dia- log programming. Therefore, this chapter will not discuss the functions and uses of these techniques as part of ABAP programs. Rather, we will focus on aspects related to performance analysis. If you discover perfor- mance problems caused by the incorrect use of SAP enqueues, consult the responsible ABAP developer. ‘An SAP enqueue is a logical lock that acts within the SAP system. If ‘a row in a database table is locked by an SAP enqueue, it can still be changed by an SQL statement executed from the database or by a cus- tomer developed ABAP program that does not conform to SAP enqueue conventions. Therefore, SAP enqueues are only valid within the SAP system, Database locks, in contrast, resist all change attempts. They lock a table row “tight” for all database users and prevent changes by users outside the SAP system. For each object that can be held by an enqueue, there are two function modules: an enqueue module and a dequeue module. To set an enqueue, an ABAP program must explicitly call the enqueue module; to remove it, the program must call the corresponding dequeue module. As a result, SAP enqueues can be held in place through multiple transaction steps. ‘When an SAP transaction is completed, all SAP enqueues are automati- cally removed. Let's discuss how SAP enqueue administration works, using our vaca- tion example. The trip includes several components, such as flight, hotel 457 SAP enqueue objects Function modules G110 Locks reservations, and bus transfers. The individual components of the trip are processed on different input screens, with several transaction steps, and ate locked using SAP enqueues. After determining the availability of each component, you can confirm the booking for the entire trip. This concludes the dialog part of the transaction. Under the protection of the enqueues, an update work process then transfers the changes to the database tables. When the update has been completed, the SAP LUW is finished, and the enqueues are unlocked. ‘An SAP LUW can also contain program modules that require a V2 update. An SAP enqueue is not used for this. You should not use mod- ules that use this V2 update to process data that requires the protection of enqueues. ‘Table 10.1 compares the main features of database locks and enqueues. EE SET Locked object Individual rows ofa Logical abject, such as database table document defined in the ABAP dictionary How objectis locked _Implictly using Explicitly by the ABAP. modifying SQL program calling an statements (uch as enqueue module UPDATE and SELECT FOR UPDATE) How lockisremoved implicitly with the SQL_ Explicitly by calling a statement CONIT or dequeue module ROLLBACK Usually at the end of Usually at the end ofa an SAP transaction transaction step ‘Maximum duration One transaction step Over multiple transaction steps Result of lock conflicts Wait situation, referred Program-specifc, for toas exclusive lock example, the error wait message “Material X is locked" How ta monitor Transaction B01, Transaction SAV12, Exclusive Lock Waits Enqueue Monitor Table 101 Festures of Database Locks and SAP Enqueves 458‘Monitoring Locks 10.2 Monitoring Locks In this section, you will find information on how to monitor database locks and SAP enqueues. 10.21 Exclusive Lock Waits What happens in the event ofa lock conflict, when a work process wants to lock an object that is already locked? With database locks, the second process waits until the lock has been removed. This wait situation is known as an exclusive lock wait. Most databases do not place a time limit on these locks. Ifa program fails to remove a lock, the wait situation can continue indefinitely. This could become a major problem if the program fails to release a lock ‘on critical SAP system data such as the number range table NRIV. There isa danger that one work process after another will be waiting for this lock. If all work processes are waiting, no work process is available to allow you to intervene from within the SAP system. If you can identify the program holding the problem lock, you can terminate it through the operating system as a last alternative. To monitor current lock wait situations, call the database lock monitor (Transaction DBO1), which you can start from the DBA Cockpit (Trans- action DBACOCKPIT by selecting PERFORMANCE + WAIT SITUATIONS ON Locks AND DeADLOcKs or from the system-wide work process overview (Transaction SM66) by selecting Goro + DB Locks. For a description of this monitor and information on how to trouble shoot lack wait situations, see Chapter 2, Section 2.3.4, Other Database Checks. Lock wait situations increase database time and result in high database times in workload monitor statistics. Some database systems explicitly monitor lock wait times, which you can view in the database performance monitor. With the following sample program you can provoke a lock situation on the database: REPORT zts_lock DATA: Iv_text type natxt 459 Exclusive lock waits [ed 10.210 Locks Typical problems ELECT SINGLE FOR UPDATE text FROM TLOO INTO 1v_ti sprs] = “DE AND ARGS = ‘00° AND msgnr = “O01 BREAKPOINT act WHERE To do so, proceed as follows: 1. Start the program in the ABAP Workbench (for instance, via Transac- tion SE38). After a few seconds, the debugger opens, and the pro- ‘gram stops at the 8REAK-POINT command. Before that, the program has set a database lock using the SELECT SINGLE FOR UPDATE com mand. Because the program waits in the debug mode, this database lock is not undone. 2. Now open a second session and restart the program. An hourglass is displayed in the second session. 3. Again, you can restart the program in a thitd session, and the system again displays an hourglass. 4. Open another session and start the database lock monitor as pre- viously described. The lock situation is displayed, and you can see ‘which work process holds the lock and which one waits. Based on the work process overview (Transaction SMSO) and the database process monitor, you cant now analyze what happens in the process that holds the lock, In this example, the process overview displays the Stopped status gives and Debug as the reason. 5. Now go to the debugger, where you continue the execution of the program in the first session. The program is terminated, and the data- base lock is undone due to an implicit commit or rallback of the data- base Interface. As a result, the program can continue in the second session, which had to wait at the SELECT SINGLE FOR UPDATE com- mand up to now. So within a very short period of time, it will reach the #t€AK-POINT command and start the debugger. 6. Continue the program in the debugger for the second session, and, if you started the program in further sessions, in these sessions to release the locks. Basically, you should set programs to request locks as late as possible. It is preferable for a program to read and process data from the database before setting locks or making changes in the database. This is illustrated‘Monitoring Locks | 10.2 in Figure 10.1. The top part of the diagram shows how several changes are made during a database transaction and how, as a result, database locks are held for too long. The lower part of the diagram shows a more appropriate programming method: The uausaction is programmed sv that it collects the changes in an internal table and then transfers these changes to the database as a group at the end of the transaction. This reduces the lock time in a database. a) Individual Updates Commit ABAP yoy + Database 4 $f __l | __§ Database Locks ey Appends to Internal Table sion ABAP y+ y yo Database Database Locks Figure 103 Locks Should @e Set as Late as Possible Performance problems due to delays in releasing locks frequently occur when customers modify the programming of update modules. The sepa ration of update modules from dialog modules is an attempt to reduce the number of locks needed in the dialog part of a transaction, because changes to the database and the associated locks are mainly the task of the update modules. However, sometimes the update module is modi fied, for example, to supply a customer-developed interface with data This modification may cause problems if the update module has already set locks and, for example, the modification generates expensive SQL statements, The locks cannot be released until the SQL statements are fully processed, and lengthy lock waits may result. 461 causes10 Locks Deadlocks Table locks Another source of problems with locks is background programs that set locks and then run for several hours without initiating a database com- mit. If dialog transactions need to process the locked objects, they will be forced to wait until the background program finishes or initiates a database commit, To solve this problem, you should either ensure that the background program initiates @ database commit at regular intervals (vvithout sacrificing data consistency) or that it runs only when it will not interfere with dialog processing. Similar problems may occur when back- ground jobs are run in parallel, that is, when a program is started several times simultaneously. Parallel processing is recommended only when the selection conditions of the programs do not lock the same data While you are working in the ABAP debugger, database commits are gen- erally not initiated, and all locks stay in place until you are finished. You should therefore avoid using the debugger in a production SAP system ‘We'll now present an example ofa situation known as adeadlack. Assume that work process one and work process two both want t0 lock a list of| ‘materials, Work process one locks material A, and work process two locks ‘material B, Then, work process one tries to lock material B, and work process two tries to lock material A. Neither work process is successful because the materials already have locks on them. The work processes block each other. A deadlock is identified by the database instance and solved by sending an error message to one of the work processes. The corresponding ABAP program is terminated, and the error is logged in the SAP syslog. You can avoid deadlacks with correct programming. In our example, the program should be changed so that its internal material list is sorted before any locks are set. Then the lock on material A will always be set before the lock on material B. Therefore, programs requiring the same materials are serialized and not deadlocked. Deadlocks should occur very rarely. Frequent deadlocks indicate incor- rect programming or configuration of the database instance. In some database systems such as DB2 and MaxDB, if a work process places single-row locks on more than 10% of the single rows in a table, the locks are automatically replaced by table locks. Here, the database decides that it is more efficient to lock the entire table for a work pro- 462Monitoring Locks | 10.2 cess than to maintain several locks on individual rows. Table locking has consequences for parallel processing in background jobs, where each program is intended to update a different part of the same table at the same time, It is not possible to schedule background jobs so that one updates the first half of the table and the other updates the second half, because the database may decide to lock the table exclusively for one of the jobs. One program that is particularly affected by this is the period closing program in materials management. There are database parameters you can use to specify when the database [4] should convert single-row locks to a table lock. Sometimes the database locks entire tables for administrative reasons. [1] ‘This happens when indexes are created or when particular tables and indexes are analyzed, for example, during the Oracle analysis YAL!04TE STRUCTURE. If these actions are performed during production operation, substantial performance problems may result 10.2.2, SAP Enqueues SAP enqueues are managed in the enqueue table located in the global main memory of the enqueue server. The work processes in the enqueue server directly access the enqueue table; the enqueue server also carries ‘out lock operations for work processes from other application servers, ‘which are communicated via the message service. The following abbre ations are used in Figure 10.2: DIA, dialog work process; ENQ, enqueue work process; MS, message service; DP, dispatcher; ENQ tab, enqueue table. ng jf op aT Figure 10.2 Communication for Setting and Removing SAP Enqueves 46340 | Locks Performance problems with SAP enqueues Enqueve statistics For work processes in the enqueue server, setting and releasing locks takes less than 1 millisecond; for work processes in other application servers, it takes less than 100 milliseconds fan SAP enqueue is requested but is already held by another user, the attempt to set a lock is rejected, and an error message Is sent back to the ABAP program. The application developer has to decide how to deal with this error message with suitable programming, For programs in dialog mode, the error message is normally forwarded to the user, for example, with the message "Material X is locked by user Y" For back- ground programs, you will normally attempt to set the lock again later. Afiera certain number of unsuccessful attempts, as errar message is writ- ten to the program log. If SAP enqueues are held for too long, performance problems can arise because after a failed attempt, the user will repeat the entry. Take, for example, a user who needs to process a material list, and to do so needs to set 100 SAP enqueues. If the attempt to set lock number 99 fails, the program is interrupted with the message “Material number 99 is locked, and all of the previous system work is in vain and must be repeated. Therefore, rejected enqueue requests lead to higher system workload and restrict the throughput of transactions. You can get an overview of all currently active SAP enqueues by using Transaction SM12: Toots + ADMINISTRATION * MONITOR * LOCK ENTRIES. Start the test programs to diagnose errors: ExrRas * DiaoNose, or EXTRAS * Diacnose 1s VB. If errors are idemtified, check the SAP Service Marketplace for notes or contact SAP directly. You can view statistics on the activity of the enqueue server with the ‘menu option ExrRas + Statistics. The first three values show the number of enqueue requests, the number of rejected requests (unsuccessful because the lock requested was already held by another), and the number of errors that occurred during the processing of enqueue requests. The number of unsuccessful requests should not be more than 1% of the total number of enqueue requests. There should be no errors. 464Number Range Buffering | 10.3, 10.3 Number Range Buffering With many database siructures, it is necessary to be able to directly access individual database records, You do this with a unique key. Num- ber ranges assign a serial number that forms the main part of this key. Examples of these numbers include order numbers and material master numbers. SAP number-range management monitors the number status so that previously assigned numbers are not reissued 10.31 Fundamentals of Number Range Buffering A business object for which a key must be created using the number range is defined in the SAP system as a number range object. A number range contains a number range interval with a set of permitted characters. ‘The number range interval is made up of numerical or alphanumeric characters and is limited by the From-Number and To-Number fields. You can assign one or more intervals to a number range. The current number level of a range, which is the number that is to be assigned next, is stored in the database table NRIV. Ifa program needs a number (for example, from the number range MATBELEG), it goes through the following steps: 1. The program reads the current number level from the NRIV table and, at the same time, locks the MATBELEG number range. To set the lock, the SQL statement SELECT F08 UPDATE is applied to the row of the NRIV table that corresponds to the MATBELEG number range. 2. The program increases the number range level by one by updating the table NRIV. 3. The number range in the database remains locked until the program completes its DB LUW by performing a database commit or database rollback. If an error occurs before the lock is released, the document cannot be created, and the change in table NRIV is rolled back; that is, the previous number level is returned, This ensures that numbers are assigned chronologically and without gaps. Bottlenecks can occur when many numbers are requested from a par- ticular number range within a short period of time. Because the number 465 Technical Implementation0 Locks Main memory butfering Entering the number range butter range is locked in the database from the time of the initial reading of the current number level to the time of the database commit, all business processes competing for number assignment must wait their turn, and this limits transaction throughput Buffering the corresponding number range solves this lock problem. SAP offers two ways of doing this: main memory buffering and buffering each SAP instance in an additional database table (NRIV_LOKAL). By buflering number ranges in main memory, the database table NRIV does not have to be accessed for each number assignment; rather, the number is read from the buffer. The number range interval buffer is located in the main memory of SAP instances. A certain amount of new numbers is stored in each buffer. When these numbers have been used up, a new set of numbers is obtained from the database, The number range level in the database table NRIV is increased by the range of num- bers transferred to the buffer. When a number is taken from the buffer and assigned to a document, the number range level in the database remains unchanged Entering a set of new numbers in a buffer involves several technical steps, as follows: 1. For example, a program needs a number from the MATBELEG num- ber range, which is buffered in the main memory. It discovers that the number range buffer in its SAP instance is empty. 2. The program starts an asynchronous RFC to fill the number range buffer, This REC is processed in a second dialog work process. Table NRIV is read and locked, the number range buffer is filled, table NRIV is updated, and the action is concluded with a database commit. The first work process (in which the original program is running) remains stopped while this takes place. In the work process overview, the ‘Action field shows Stopped and Reason displays NUM. 3. When the number range buffer has been filled, the original program can resume work. During this process, the program that checked the buffer for a number and the program that refills the number range buffer must run in sepa rate database LUWs. This is the only way to ensure that the commit of the second program can finalize the changes in table NRIV and release 466Number Range Butering | 40.3 the lock without performing a commit for the first program's LUW data- base. To accomplish this, the two programs are run in separate work processes. ‘To guarantee that work processes are available for refilling the buffer with new numbers, the work process dispatcher program gives prefer- ‘ential treatment to requests for new number sets. Main memory buffering of number ranges has the following consequences: » When an SAP instance is shut down, the remaining numbers in the buffer, that is, the numbers that have yet to be assigned, are lost. This causes a gap in number assignment. » Due to the separate buffering of numbers in various SAP instances, the chronological sequence in which numbers are assigned is not reflected in the sequence of the numbers themselves, which means a document with a higher number may have been created before a doc ument with a lower number. You should not buffer this object in main memory if you prefer to pre~ vent gaps in the number assignment for a particular document type ‘or number range object or if sequential numbering of documents is required by law. In this case, you can use another buffering technique: Instead of man- aging the number range for a particular type of document centrally in fa single row of table NRIV, number intervals are selected by the sys- tem for each SAP instance and managed in a separate database table (NRIV_LOKAL. In this table, the name of the SAP instance forms part of the primary key. Database locks associated with number assignments for new documents will then appear only in those areas of table NRIV_ LOKAL that correspond to a particular SAP instance. With extended local number-range buffering (SAP Note 179224), you can buffer number range intervals for each SAP instance and buffer work processes locally. (The name of the SAP instance and the logical number of the work process form part of the primary key of the local number range.) With this buffering technique, one lock problem is conclusively ruled out. 467 (1 Busfering in NRIV_LOKAL10 | Locks Keep in mind the following points: > Buffering in table NIRV_LOKAL is useful only when the user is work ing simultaneously on several SAP instances. For very high throughput (for example, processing point-of-sale entries in SAP for Retail), local buffering on the instance and work process levels (arf possible, main memory buffering) is recommended. » Numbers are not assigned to documents in numerical order. There- fore, a document with a higher number may have been created before a document with a lower number. » Some of the numbers in a particular interval may not be assigned, for example, at the end of a financial year or during the renaming of an instance. The program RSShR0A1 shows details on the numbers that have not been assigned. To enter a new set of document numbers in table NRIV_LOKAL, a new Interval is synchronously read from table NRIV, and the affected row of table NRIV remains locked until the commit occurs. If the interval of numbers read from table NRIV is too small, frequent accesses to table NRIV to obtain new numbers during mass processing may cause lock waits, Therefore, when large quantities of similar documents are being created across several instances, ensure that the selected interval is suf- ficiently large. Table 10.2 provides a summary of the buffer types for number ranges. Ct permed ui batrng No gaps in Lock waits with Only fits. ‘umber allocation, parallel processing essential to have chronological no gaps in number order allocation, if numbers must be in sequence, and only a low ‘throughput is needed Table 10.2. Types of Buffering for Number Ranges 468Number Range sutering | 10.3 Buffering | Method ions id In the main No lock wait No gaps Standard for most memory memory problems, fast number allocation, number ranges access (main no chronological memory instead of order database) Local,on Temporarily stored Lock wait Sequence not Largely replaced instance on the database problems reduced, chronological, by the method level table NRIV_ number allocation locks occur within described in the LOKAL, with almost gap-ftee an instance, following line in hhumber range many instances this table and SAP instance necessary if forming part of throughput is high the key Local, on Temporarily stored No lock wait Sequence not point: instance on the database _ problems, chronological of-sale entries in and work table NRIV_ number allocation SA? for Retail process LOKAL. with practically gap- level number range, _—free SAP instance, and work process number forming, the key Table 10.2 Types of Buffering for Numbor Ranges (Cont) 10.3.2 Activating Number Range Buffering To activate or deactivate number range buffering, proceed as follows: 1. Call the Number Range Maintenance transaction: Toots + ABAP Worksencn + Devetorment + Orier Tors + Numer RANGES oF enter Transaction SNRO. 2, Enter an object name and select Change. 3. To activate the main memory buffering, from the menu, select Fort + SET UP BUFFERING * MAIN MEMORY. Enter the quantity of numbers to be held in the buffer in the No. of Numbers in Buffer field and save the change. The specified amount of numbers from table NRIV will thereby be buffered. 46910 | Locts [+] Finding out the current number range level ‘To activate buffering in table NRIV_LOKAL, in the menu of the number jenance transaction, select EDIT + SET UP BUFFERING * LocAL, ng, from the menu, select Eprr * Ser uP BUFFERING + No BUFFERING. Please note that these changes will be overwritten if the number range object is replaced with, for example, a new release. After every update, check whether number range buffering has been affected. To view the current number range level, use Transaction SNRO. For buff- ered number range objects, the level indicated here is the next available number that has not yet been transferred to a buffer in an application server. The level indicated is higher than the last number assigned. You can check the current number level of the buffer for cach SAP instance with Transaction SM56. 1. Call Transaction $M56, and in the menu select Goto * ITEMS. 2. In the dialog box, enter the client, the relevant number range object, and if required, the relevant subobject. 10.3.3. Monitoring Number Range Buffering To identify performance problems related to number assignment, call the exclusive database lock monitor (Transaction DB01). At peak processing times, lock waits of several minutes for table NRIV are too long. If this ‘occurs, from the initial screen of the database lock monitor, proceed as follows: 11 Identify the number range involved: > If you are using an Oracle database, double-click the row showing the lock on table NRIV, This brings you to a screen with detailed information on the locked row. The name of the number range is indicated in the Object column (for example, RF_BELEG). » For other databases, start an SQL trace fora user who is waiting for the database lock to be removed. With this SQL trace, you can identify the number affected by the lock in the SQL. statement. 2. Find out the buffering status of the number range. 470» If buffering is not currently activated, check to see if the corte: sponding object can be bullered. > Ifthe number range is already buffered, check whether the quan- tity of numbers in the buffer can be increased. Table NRIV will then be accessed less frequently. Only experienced SAP developers or consultants should change the buf ering mode for number ranges for the following reasons: > Activating buffering may cause gaps in number assignment, which could be a problem if gap-free number assignment is mandatory or if st is assumed that numbering will be gap-free. > Having too few numbers in the buffer can cause performance prob: Jems by requiring the buffer to be refilled too often. The disadvantage in having a range that is too large is that too many numbers are lost if the SAP instance is shut down, SAP Notes on many number ranges are available in the SAP Service Mar- ketplace and contain details on buffering status and recommendations for how many numbers should be loaded into a number range buffer. You should never change the buffering mode for an SAP default number range without first looking for relevant notes on the object, Some notes are listed in Appendix G. 10.4 ATP Server ‘The availability check establishes the availability of materials in the SAP logistics modules, for example, for sales orders or production orders. The availability check discussed in this book is based on ATP logic (available to promise). Either of two factors can reduce performance during an availability check: » Locks ‘The material being checked for availability must be locked with an SAP enqueue. When the lock is in place, it may block other users who need to work with the material, especially if the lock remains for a an ATP Server [ 1 10.410 Locks long time or the material is frequently worked on. As a result, locks limit the throughput of the availability check, » Read accesses for tables RESB and VBBE An availability check is used to ensure that a material will be available at a specific time in the future. As part of the check, incoming move- ments planned before that time are added to the current stock, ‘whereas planned outward movements are subtracted. In this context, totaling material reservations and secondary requirements for pro- duction orders is critical to performance, as isthe totaling of customer requirements for sales orders, which are stored in tables RESB and BBE, respectively. Reading and calculating these reservations and requirements can lead to a high availability check runtime. [+] Table RESB may be as large as 1GB or even larger. Depending on cus- tomizations, the current date through the date on which the material should be available must be read for the availability check on all RESB records for a material. The availability check is carried out on a dedicated SAP instance ~ the ATP server. The ATP server has a buffer in shared memory in which ATP- relevant information is stored. This significantly reduces accesses to the Gatabase tables RESB and VBBE. The ATP server is not a separate instal- lation, It is a logical service running on an SAP instance, and as such it forms part of the SAP system. 10.41 ATP Server Fundamentals ‘arp server Figure 10.3 shows how an ATP server works in the system landscape. functionality Jf an SAP work process on SAP instance B has to check the availability of a material, it uses a remote function call (RFC) to communicate the request through the network to the server where the ATP server resides. In Figure 10.3 the ATP server is configured on SAP instance A (@). This, «all is sent between the gateway services of the two SAP instances (@). A dialog work process on the ATP server (@) processes the availability check. The following abbreviations are used in Figure 10.3: DIA, dialog work process; GW, gateway service; DP, dispatcher; ENQ tab, enqueue table; E/ buffer, exporvimport butler. 47RESB BBE Peer Figure 10.3 Communication During an Availability Check Using the ATP Server The SAP work process on the ATP server uses subtotals for calculating the availability of a material, which have already been calculated for other availability checks and are stored in the main memory of the ATP server in the export/import buffer. These subtotals consist ofa calculation for each day's material reservations (from table RESB) ot sales require- ments (from table VBBE) for every possible combination of material, plant, storage location, and batch. Dally totals per combination of mate- rial, plant, storage location, and batch are compressed and stored in the exportimport buffer. The export/import buffer therefore contains two groups of entries: one for RESB data and one for VBBE data. The size of the entries depends on the number of days for which subtotals exist. When checking the availability of a material, the work process does not read RESB and VBBE data from the database: rather, it reads from the export/import buffer (see Figure 10.3). This method considerably improves performs. Special delta processing guarantees consistency between the buffer and database. While checking availability, the SAP work process sets and removes SAP enqueues that are necessary to guarantee data consistency. To set and remove enqueues with only minimal performance loss, the ATP and enqueue servers should run on the same SAP instance. 43 AIP Server 10.410 Locke Loclaing with (] Activate Shing A special SAP technique is used in the ATP server availability check: locking with quantities. Instead of relying on exclusive SAP enqueues, which allow only one user to lock a material, this technique uses shared enqueues. Shared enqueues can be used by several users on the same object at the same time, which means several users can check the avail- ability of a material atthe same time. 10.4.2 Configuring the ATP Server Correctly configuring the ATP server isa technical procedure that resolves, two specific problems with the availability check: frequent accesses to the RESB and VBBE tables. However, the ATP server does not solve all the problems associated with the availability check. It is very important 10 optimize application-related aspects af the availability check during customizing, For example: » Set sensible reorder times and planned horizons for materials. > Deactivate individual checking of materials that are used in bulk, such as screws or nails. > Regularly archive reservations. ‘The SAP Empowering Workshop, "Technical Optimization of the Avail ability Check,” provides application-related optimization measures. Tables RESB and VBBE are accessed by database views during the avatl ability check. An availability check with SQL trace will give you access to the views ATP_RESB or ATP_VBBE. To activate the ATP server, set the SAP profile parameter rai sp/atp_ server to the name of the SAP instance that provides the ATP server (for example, enghost_ PRD_00). The value of this parameter must be identical for all SAP instances and should therefore be set in the default profile. The ATP server and the enqueue server should run on the same SAP instance. ‘The SAP profile parameters rsdb/obj/butfersize and rsd /ob,j/nex_ ‘objects configure the size and maximum number of entries in the export import buffer. The size of an entry in the export/import buffer depends 474‘on the number of days for which subtotals exist, For each additional dey, the size of the entry increases by around 50 bytes. If reservations are cal- culated for a combination of material, plant, storage location, and batch for 20 days, the size of the entry would be around 1KB. If your company expects a maximum of 10,000 combinations, and for each combination there are an average of 20 days of daily reservation or sales requite- ‘ment subtotals, you would set the size of the export/import buffer to 20,000KE (parameter rsdb/obj /buf fers ize) and the maximum number of entries at 20,000 (parameter rsab/obj /nax_obsects). You should activate locking with quantities for all materials to be checked for availability using the ATP server. This is done using the checking group of each material. To activate locking with quantities for a checking group, proceed as follows: 1. Call up customizing: TOOLS + BUSINESS ENGINEER * CUSTOMIZING * Continur. 2, Select IMPLEMENT PROJECIS * DISPLAY SAP REFERENCE IMG. 3. Select: SALES AND DISTRIBUTION + BASIC FUNCTIONS + AVAILABILITY CHECK AND TRANSFER OF REQUIREMENTS * AVAILABILITY CHECK * AVAIL- ABILITY CHECK WITH ATP LOGIC AND AGAINST PLANNING * DEFINE CHECK- ING GROUPS, A screen appears in which you can set the characteristics of the checking groups for the availability check. 4. To set locking with quantities for a particular checking group, select the checkbox in the Block QtRq column. ‘Many availability checks are carried out simultaneously on large instal- lations, and as a result, some parameters on the enqueue or ATP server ‘may limit the number of RFC connections and must be set to values that are sufficiently large. Table 10.3 lists these parameters. To ensure that sufficient dialog work processes are available for the availability check, you require at least five dialog work processes on the enqueue/ATP server, even if no users are working on this server. The enqueue server also requires sufficient SAP extended memory. Monitor the use of extended memory at regular intervals. 475 ATP Server | 10.4 Activating locking with quantities Other resources10 | toes ery De ize for Locking with Crrunes rdisp/tm_max_no disp/max_comm_ ‘Maximum number of frontend connections 2500 Intable tm_adm. entries Numberof maximum possible CPIC/RFC 2500, Connections (table comm_adm) ‘ow/max_conn Number of maximum possible gateway +2500 connections (table conn tbl) rdisp/wp_no_dia Number of dialog work processes 25 en/initial_size ns Size of extended memory +2250 edisp/ROLL_SHM Size of roll buffer In 8kB blacks 24,000 @2m8) GH Table 10.3 Parameter Settings forthe ATP Server or Enqueue Server When Using, Locking with Quantities For the most recent information on sizing for the export/import buffer, see SAP Notes 24762 and 99999, You can also use locking with quantities independently of the ATP server. Note the recommendations provided in the "Other Resources" section above if you set locking with quantities without the ATP server. 10.4.3 Monitoring the ATP Server Transaction ACBD offers monitoring and administration functions for the export/import butfer in the ATP server, such as: > Complete or partial deletion of the export/import buffer (with regard to ATP data) » Adjusting the exporvimport buffer to the database ‘This transaction allows data fiom the database to be preloaded into the export/ ‘import buffer, Otherwise, data loading does not occur until th fist availabil- ity check is made for each combination of material, plant, and table. You can monitor the contents of the expor/import bulfer (from a techni- cal point of view) in the SAP memory configuration monitor (Transaction $702) by selecting DETAIL ANALYSIS MENU * IMPORT/EXPORT BUFFER * BUFFERED OsJECTS. The most important fields in this monitor are Table 476Name (ATPSB for ATP server objects), Object Name (this field contains the clients, the information, whether it is an RESB entry [RE] or a VBBE cenuy [VB], the plant, and the material number) Size (size of an enty), and Used (number of accesses to this entry). You can monitor the shared enqueues that are used when locking with ‘quantities in the SAP enqueue monitor (Transaction $M12). They are indicated by the entry ATPENG in the Table field and are marked with a ‘cross in the Shared field ‘Monitoring SAP enqueues is one of the regular system administration tasks. SAP enqueues that are held over several hours are an indication of an ettor in a program or that a program is being used incorrectly. 10.5 Summary The database and SAP systems both offer their own lock concepts (data- base locks and SAP enqueues). Locks held for a long time can lead to performance problems and can even bring the system to a standstill. You can monitor exclusive database lock wait situations with the help of ‘Transaction DBO1 and wait situations caused by SAP enqueues with the help of Transaction SM12 Give special attention to locks associated with both number ranges (used to generate, for example, order numbers or document numbers) and availability checks. Sections 10.3, Number Range Buffering, and 10.4, ATP Server, show ways to identify bottlenecks in these areas and how to them. Key topics in this respect are the ATP server (for the avail- ability check) and number range buffering (for number assignment). Important Concepts in this Chapter After reading this chapter, you should be familiar with the following concepts: > Database locks and SAP enqueues » Locking with quantities > ATP server > Reset or check the number range buffer a7 summey | 10.5 [+]10 | Locks Questions 1, Which of the following statements are correct? @) When you set an SAP enqueue, you lock one or more tables in the database. b) Affer an SAP enqueue has been placed, the corresponding database table can still be changed by an Update request from programs such as customer-developed ABAP reports © A database lock is usually released at the end of a transaction step, whereas an SAP enqueue is usually released at the end of an SAP transaction. d) A database lock that lasts too long can cause an SAP system stand- stil 2, Which of the following statements are correct with regard to the ATP server? a) The ATP server should always be configured on the database server. b) The ATP server is an independent SAP installation with its own database on a separate computer. ©) The ATP server reduces the number of accesses to tables RESB and VBBE. 3. When butffering number range objects in main memory, which of the following considerations should you bear in mind? a) Because buffering occurs in all SAP instances, buffer synchroniza- tion may cause some numbers to be assigned twice +) Gaps occur in the number assignment when you are using buffered number ranges. You must check whether these gaps are permitted by law and are acceptable from a business point of view. ©) If the quantity of numbers in the buffer is too small, performance problems will result (particularly during mass data entry using batch or fast input) 4) Sufficient physical memory must be available, because number range buffering consumes a lot of memory. 478