on 09-15-2008 11:25 AM
Hi Gurus,
We are encountering an ODS activation problem.
We are trying to manually activate a request in the ODS.
When we click on the activate button, it runs for a very long time.
We are loading a data from a Flat file and from another cube to this ODS. Then eventually, it will be loaded to another infocube.
These are the things we tried to do:
1) SM12 - We saw a lock in RSICCONT table
2) Tried to delete this lock and repeat the process but error still happens.
These are the things we did before this activation problem occured:
1) There are some erroneous requests in the ODS caused by "Inconsistent aggregation behavior) -- trying to activate a delta and a full request at the same time.
2) We deleted those erroneous requests from the tables: RSICCONT, RSMONICDP and RSODSACTREQ. After that, all the tables consistently contains the same correct requests.
3) We ran RSRV to check the status of the activation program and it is now OK.
4) We tried to re-init the Cube where this ODS goes to (ZIC_ZZZ). Reint was successful.
Now, we still could not reload these request to the said ODS.
Can anyone help us on this?
Thanks a lot!
Jeffrey
DBIF_RSQL_SQL_ERROR related to database proble. Ask your basis team to look into this.
Thanks.,,
Shambhu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If the load is succeeful and issue is only with activation, just give a try with following.
Select DSO -> Activate Data
From the next screen select the request, and click "Activate in Parallel" button.
From the next screen, select "Dialog" radio button, and select "PARALLEL_GENERATORS".
No of Processes: __ try with 1, if that does not work then try with 2, otherwise 3
(because totally depends on u r server configuration. Couple of months ago, I faced the same issue. First I tried with 3, then with 2..Finally DSO got activated with 1).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Jeffrey,
I would like to have some more infos about your problem, to give any advice:
- How many records are you loading in your request ?
- Did you get an error message, or did you just get impatient ?
- Did you try to add a Full and a Delta request from the same data source to your ODS ?
- What is your BW: 3.5 or 7 ?
- Why did you manipulate internal tables to solve the problem instead of using the correct tools ?
Kind regards,
Jürgen
Edited by: Jürgen Kirsch on Sep 15, 2008 1:07 PM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jürgen,
Please see my reply below:
Thanks for your help!
Regards,
Jeffrey
How many records are you loading in your request ? *600*+ records
Did you get an error message, or did you just get impatient ? We got a short dump and we got impatient
Please see below:
Runtime Errors DBIF_RSQL_SQL_ERROR
Exception
CX_SY_OPEN_SQL_DB Date and Time 15.09.2008 18:26:23
*Short text*
SQL error in the database when accessing a table.
What Happenned?
The database system detected a deadlock and avoided it by rolling back
your transaction.
What can you do?
If possible (and necessary), repeat the last database transaction in the
hope that locking the object will not result in another deadlock.
Note which actions and input led to the error.
For further help in handling the problem, contact your SAP administrator
You can use the ABAP dump analysis transaction ST22 to view and manage
termination messages, in particular for long term reference.
Did you try to add a Full and a Delta request from the same data source to your ODS ? Only Delta request
What is your BW: 3.5 or 7 ? The system is already in 7.0, but the objects we are using is still in 3.5
Why did you manipulate internal tables to solve the problem instead of using the correct tools ? Because the activation is running for a very long time which is not the normal thing. The activation is being done on a daily basis so it should be available before noon. So, the only option we know is to manipulate the tables.
Hi,
take a look:
ODS object: Activation fails - DEADLOCK
SAP Note Number: [634458 |https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bw_whm/~form/handler]
Symptom
A DUMP is triggered during activation:
Runtime errors DBIF_RSQL_SQL_ERROR
Exception CX_SY_OPEN_SQL_DB
The DUMP occurs in the form of an "UPDATE_ATAB".The long text of the DUMP refers to a DEADLOCK that occurred on the active table of the ODS object.
In the monitor you see the message RSDRO 108. In the long text you find the following information:
Message(RFC): An SQL error occurred when accessing a table.
Other terms
ORA-00060, deadlock, DUMP, DBIF_RSQL_SQL_ERROR, CX_SY_OPEN_SQL_DB, ODS,
ODS object, RSDRO108, RSDRO 108, RSM1185, RSM1 185
Reason and Prerequisites
Paralleled activation of data in the ODS object.
Several processes try to write to the same database block.
Solution
Apply note 84348 on the active table of the ODS object (INITRANS and MAXTRANS parameters).
Hope this helps.
Regards
Andreas
Hi Jeffrey,
I am just wondering if you can repair your problem, because by removing entries from system tables you may have made yourself more trouble then benfit.
With this error, I would have tried two things:
1. Ask Basis if the tables for loading are big enough. It may be that the table space is close to exceeded and the automatic increase is deactivated (Oracle, don't know of other databases).
2. Find out, if I could do some buffering of Infoobjects so the SIDs are delivered faster.
3. Disable parallel processing for Activating.
And I would have tried again. But if I understand your "Step 2" correctly, you removed some entries from the system tables which control the activation. I don't know, if you can restart the activation now. Your dump in itself is not so uncommon.
Though I wonder if your 600 entries are the cause of this, because usually 600 entries are not able to trigger parallel processing. Are you sure, that your 600 records Request is the only one which is activated ? Is it possible that another upload was active at time of dump ?
As an afterthought: To disable the long running activation, I would stop the job in SM37 and if necessary in SM50. And if I could not stop the job there, it may be a zombie (my nickname for one of those jobs in SM37 which accumulates runtime, without causing any CPU).
Kind regards,
Jürgen
User | Count |
---|---|
61 | |
9 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.