We have a issue where our DSO has been activating for quite some time
now. We have an enhancement where we need to add fields in the DSO.
However,we found that the DSO is not activated after we have migrated
our. However,during the activation of the DSO, it is taking a very long
time in activating it.
DSO Tech name : ZDSO_RR
The Solution :
When you have large amount of data in the table (ODS), the following is a work around to get the new columns added to the ODS/DSO:
1. Make copy of the existing ODS (ODS1) to ODS2
2. Add new fields to ODS2
3. Load the data from ODS1 to ODS2 using datamart (use ODS2 for further purposes).
If you have some reporting queries defined on ODS1 then you need to do the following:
1. Make copy of the existing ODS (ODS1) to ODS2.
2. Load data from ODS1 to ODS2 using datamart.
3. Delete Data from ODS1.
4. Add new fields to ODS1.
5. Reload the data from ODS2 to ODS1 using data mart.
Please take note :
1) Create a DSO copy
2) Load data from original DSO to DSO copy
3) Delete data from DSO original
4) Migrate the adding new field changes
5) Activate the DSO using program : RSDG_ODSO_ACTIVATE
6) Reload back data to DSO
If you're having the same issue with Infocube, this solution applies to that as well.
This is a blog that share's SAP tutorials for beginner and intermediate level for all SAP people.
Popular Posts
Sunday, June 12, 2011
DTP Error : Maximum package size for data packages was exceed
When we trigger DTP (ZDSO_RR -> ZIC_RR) we encounter the error
"DTP Error : Maximum package size for data packages was exceed"
(Please refer to attachement)
You can refer to this note :
Note 1144332 - Consulting note: Message RSBK 250: Package size exceeded
However, it's does not work with my cube loading. The workaround is to unchecked all the fields in the semantic group. The reload back the data. The the load successful!
Generally this issue occurs when the semantic key is set, and as a result package size is not taken into consideration in case there are more records sent with the same semantic keys.
"DTP Error : Maximum package size for data packages was exceed"
(Please refer to attachement)
You can refer to this note :
Note 1144332 - Consulting note: Message RSBK 250: Package size exceeded
However, it's does not work with my cube loading. The workaround is to unchecked all the fields in the semantic group. The reload back the data. The the load successful!
Generally this issue occurs when the semantic key is set, and as a result package size is not taken into consideration in case there are more records sent with the same semantic keys.
Labels:
ABAP,
DTP,
SAP BI,
SAP Business Warehouse,
SAP BW,
SAP errors
Thursday, June 9, 2011
Steps to upgrade Support Pack Manager
1) Download the latest Support Pack Manager (SPAM) on the SAP service marketplace
2) Transfer the downloaded file to /usr/sap/trans/EPS/in
3) SAP has extract tool to extract the SAR files.You have to login hasadm.Then go to the location where you copied SAR files.Then execute “SAPCAR –xvf ”. Copy all the unextracted file to /usr/sap/trans/EPS/in directory.
4) Login as DDIC. Invoke tcode SPAM and load the extracted files. Support PAckage->Load PAckages->From Application Server
5) Then, click Support PAckage->Load PAckages-> Import SPAM/SAINT Update.
6) Then it will automatically update the Support Pack Manager. You're finished!. You may bump into ABAP Dump. Like me, I bump into LOAD_TEXTPOOL_LOST.
However, if you read SAP note 822379
SPAM/SAINT updates
* Symptom: When you import the SPAM/SAINT update, a range of different runtime errors may occur:
o LOAD_PROGRAM_LOST
o LOAD_PROGRAM_CLASS_MISMATCH
o LOAD_TEXTPOOL_LOST
o SAPSQL_SELECT_WA_TOO_SMALL
o SAPSQL_SELECT_TAB_TOO_SMALL
o SAPSQL_WA_TOO_SMALL
o DDIC_STRUCLENG_INCONSISTENT
o RUNT_ILLEGAL_SWITCH
o CALL_FUNCTION_PARM_UNKNOWN
These errors occur because the source code of the Support Package Manager is modified by the import during the run. CALL_FUNCTION_PARM_UNKNOWN, LOAD_PROGRAM_LOST, LOAD_PROGRAM_CLASS_MISMATCH, and LOAD_TEXTPOOL_LOST occur if the ABAP load or text elements are to be loaded back into the local buffer, and there is a different version in the database.
However, SAPSQL_SELECT_WA_TOO_SMALL, SAPSQL_SELECT_TAB_TOO_SMALL, SAPSQL_WA_TOO_SMALL, DDIC_STRUCLENG_INCONSISTENT and RUNT_ILLEGAL_SWITCH occur if changes are made on the SPAM/SAINT data structures with the SPAM/SAINT update.
Solution: None of these errors will occur again if you restart the Support Package Manager (transaction SPAM) and continue to import the SPAM/SAINT update.
2) Transfer the downloaded file to /usr/sap/trans/EPS/in
3) SAP has extract tool to extract the SAR files.You have to login has
4) Login as DDIC. Invoke tcode SPAM and load the extracted files. Support PAckage->Load PAckages->From Application Server
5) Then, click Support PAckage->Load PAckages-> Import SPAM/SAINT Update.
6) Then it will automatically update the Support Pack Manager. You're finished!. You may bump into ABAP Dump. Like me, I bump into LOAD_TEXTPOOL_LOST.
However, if you read SAP note 822379
SPAM/SAINT updates
* Symptom: When you import the SPAM/SAINT update, a range of different runtime errors may occur:
o LOAD_PROGRAM_LOST
o LOAD_PROGRAM_CLASS_MISMATCH
o LOAD_TEXTPOOL_LOST
o SAPSQL_SELECT_WA_TOO_SMALL
o SAPSQL_SELECT_TAB_TOO_SMALL
o SAPSQL_WA_TOO_SMALL
o DDIC_STRUCLENG_INCONSISTENT
o RUNT_ILLEGAL_SWITCH
o CALL_FUNCTION_PARM_UNKNOWN
These errors occur because the source code of the Support Package Manager is modified by the import during the run. CALL_FUNCTION_PARM_UNKNOWN, LOAD_PROGRAM_LOST, LOAD_PROGRAM_CLASS_MISMATCH, and LOAD_TEXTPOOL_LOST occur if the ABAP load or text elements are to be loaded back into the local buffer, and there is a different version in the database.
However, SAPSQL_SELECT_WA_TOO_SMALL, SAPSQL_SELECT_TAB_TOO_SMALL, SAPSQL_WA_TOO_SMALL, DDIC_STRUCLENG_INCONSISTENT and RUNT_ILLEGAL_SWITCH occur if changes are made on the SPAM/SAINT data structures with the SPAM/SAINT update.
Labels:
ABAP,
SAP,
SAP Administration,
sap patch management,
sap tutorial,
sapsharing
Tuesday, June 7, 2011
PSAPUNDO retention Period
Today our server hitting PSAPUNDO full 100%
Here's how we check the retention period
SQL> show parameter retention
here how to change it.
ALTER SYSTEM SET UNDO_RETENTION = 7200;
or
alter system set undo_retention=7200 scope=both/spfile;
Here's how we check the retention period
SQL> show parameter retention
here how to change it.
ALTER SYSTEM SET UNDO_RETENTION = 7200;
or
alter system set undo_retention=7200 scope=both/spfile;
Labels:
brtools,
oracle,
oracle space management,
psapundo,
sap basis
Subscribe to:
Posts (Atom)