Deadlocks

[Former Member]

Hi All,

I have couple of Ques on deadlock

What is deadlock ? when it will occur ? how can we identity that there is a deadlock? what are the steps to slove the deadlock?

can any one tell about this.

thanx

Shreya

[Former Member · Accepted solution]

Hi Shreya,

You can refer to OSS Notes - 84348, 631668, 751203.

Refer this link:

Bye

Dinesh

[Former Member]

Hi Shreya,

you can get these error in data load. which will typically have the following details.

Database error text........: "ORA-00060: deadlock detected while waiting for

resource"

Internal call code.........: "[RSQL/INSR//BIC/FZPUR_VNDR ]"

Please check the entries in the system log (Transaction SM21).

Reason For error :

This can happen when SMON is running or any DBA process is running.

Causes: This can happen when SMON is running or any DBA

Solution: Contact the DB People Ticket is raised for DBA who can adjust the schedules for SMON process.

If the update mode is delta, technical status of job is changed to red and request is deleted from the datatarget. Infopackage for Delta update is triggered again to get delta from R/3 back. If its full update,request is deleted from the datatarget and Infopackage is triggered again to get full update.

Reward Points if this is useful .

Thanks,

Srinivas.

[Former Member]

Shreya,

Symptom:
The loading of data into InfoCubes terminates with an ORA 60, "deadlock detected". The monitor log shows a "CALLER 70 missing" entry and the request is flagged as red.

Reason:
For basic InfoCubes in SAP BW, there are two fact tables for including transaction data: The F and the E fact table.Unlike the E fact table, the F fact table contains the information about the request from where the transaction data originates.When loading data (when receiving requests), the system writes data into the F fact table.During "compression", the system summarizes data from different requests and writes it to the E fact table.To ensure good reporting performance, it is important that you only keep data from a few requests in the F fact table, which means that you should compress requests as soon as possible.Also bear in mind that deleting transaction data according to the request is only possible from the F fact table, as only this table contains the information regarding which data belongs to which request.You should therefore compress a request as soon as you are certain that the data loaded is correct.When you install BW on an ORACLE database, BITMAP indexes are created on the fact tables to improve the reporting performance of the system.These indexes have a negative effect on system performance when you load data; the deadlock (ORA 60) mentioned above may also occur so that data loading terminates completely. The DEADLOCKs occur during parallel insert operations because ORACLE does not support a blocking concept for BITMAP indexes at data record level.

Solution:·

Before loading transaction data, delete secondary indexes on the fact tables and recreate them after you have loaded the data.

On the screen for administering data targets in the Administrator Workbench (transaction RSA1, context menu of an InfoCube: Administer), you can set this to be executed automatically by the system.

Alternatively, you can also load requests serially into InfoCubes.

This avoids the deadlock problem, however, you should note that after some loading processes, it is necessary to reorganize the BITMAP indexes because they degenerate very heavily.

Thanks

Ramu

[Former Member]

Hi Shreya,

A deadlock is a situation where two or more processes try to update the same table at the same time. In BW they can occur if you are loading data into a ods object with at least 2 paralell processes. In the syslog (transaction sm21) you will get information about it and it can be solved by serializing a load process. Additionally you might search the oss for some more information and may be more solutions for solving it.

regards

Siggi