+ Exception CX_SY_OPEN_SQL_DB+
+ Database error text........: "ORA-00060: deadlock detected while waiting for+
+ resource"+
+ Internal call code.........: "[RSQL/INSR//BIC/FDDLK_CBE]"+
+ Please check the entries in the system log (Transaction SM21).+ I'll try to be as simple as possible with this explanation, just to help you understand the basic and necessary principles. h3. What is a deadlock? A deadlock is a condition where two or more users are waiting for data locked by each other. Imagine two processes are running in parallel. *Process A* is currently locking a resource called *Resource 1* and *Process B* is locking *Resource 2*. A *deadlock* would happen if, to continue, *Process A* needs *Resource 2* and *Process B* needs *Resource 1*.TX-00090004-00011000 43 39 *X * 35 46 *S* TX-0006001a-0001397d 35 46 X 43 39 S If you see the value ‘X' in both columns "Hold waits", you may start working in the BW system. If you don't, you should first check your Oracle database. h4. Database Side When we first understand what a deadlock in the database is, we tend to think of two processes fighting for the same records. This isn't always true. The lock may be related to another resource. In Oracle databases, a table contains various blocks of data. The locks are managed inside the blocks. For that purpose, they also contain a list of transactions that are interested in specific rows. This list is called *Interested Transactions List (ITL)*. The *ITL* is composed by transaction slots. Each slot will point out which transaction is interested in which row. For each table/partition, its *INITRANS* and *MAXTRAN* parameters will delimiter how this resource will be managed. *INITRANS* establishes the Initial Transaction Slots. This is the number of transaction slots a block will initially have. *MAXTRANS* defines the maximum number of slots that a block can allocate. According to the necessity, Oracle will dynamically increase the number of slots in the block until it reaches the value set in this parameter. Our recommendation usually concerns increasing *INITRANS*, as Oracle, by default, doesn't reserve much space for it. Therefore, if there is high concurrency, the transaction list usually needs to be extended. This extension is a very expensive and time consuming task. In this situation, transactions may be seen waiting for a "shared not exclusive lock". Therefore, it makes sense to always look for a higher and optimum value for *INITRANS* for all blocks, so the transactions won't have to wait for the list to be extended. *SAP Note #84348* describes a few situations that may cause a deadlock in the database and lists a few suggestions on how to solve it. {code:html}84348 - Oracle deadlocks, ORA-00060.{code} h4. Application Side h5. Drop the Indices BITMAP indices are designed to be used only in Data Warehouse systems. BW creates BITMAP indices on the F-Tables, for example, to improve the reporting performance. However, this type of index is very susceptible to deadlocks, as each index row references various records, not just one. Any DML statement (INSERTS, UPDATES, etc.) will lock many rows within an index. Dropping the secondary indexes from the InfoCube before loading data is recommended to improve dataload performance, but it also prevents deadlocks. Since indices are defined both in the DataBase and in the Dictionary, you may drop it only in the database, and rebuild from the dictionary definition after the load has finished. If you are manually loading the data, you can drop and rebuild the index in RSA1: 
Or, you may set a default option directly to perform this action automatically in before each load. The following popup window appears after clicking on the button "DB Index Creation" 
If you are loading via process chain, you may create variants do manipulate the index: 
h5. Reduce Parallelism Reducing the number of parallel processes or deactivating the parallelism is another way to avoid deadlocks. To change this setting in a DTP, display the object and choose the menu option "Goto -> "Settings for Batch Manager...". 
A popup window will be displayed. You may change the number of parallel processes in the field "Number of Processes". If set to 1, the parallelism is deactivated and the load will be serial. 
For an InfoPackage in a 3.X dataflow, you can load serially by choosing the processing option "PSA and then into Data Targets (Package by Package)". 
