Hi All...here is the list of SAP BI Production Support
issues along with the resolution. Hope it will be helpful for the people who
are working in support environment.
1. DTP Failure
Select the step-> right click and select
“Display Message”-> there we will get the message which gives the reason for
ABEND.
A DTP can failure due to following reasons, in
such case we can go for restarting the job.
·
System Exception Error
·
Request Locked
·
ABAP Run time error.
·
Duplicate records
·
Erroneous Records from PSA.
Duplicate records:
In case of duplication in the records, we can find it in the error message
along with the Info Provider’s name. Before restarting the job after deleting
the bad DTP request, we have to handle the duplicate records. Go to the info
provider -> DTP step -> Update tab -> check handle duplicate records
-> activate -> Execute DTP. After successful competition of the job
uncheck the Handle Duplicate records option and activate.
DTP Log Run:
·
If a DTP is taking log time than the regular run time
without having the back ground job, then we have to turn the status of the DTP
into Red and then delete the DTP bad request (If any), repeat the step or
restart the job.
·
Before restarting the Job/ repeating the DTP step,
make sure about the reason for failure.
·
If the failure is due to “Space Issue” in the F fact
table, engage the DBA team and also BASIS team and explain them the issue.
Table size needs to be increased before performing any action in BW. It’ll be
done by DBA Team. After increasing the space in the F fact table we can restart
the job.
Erroneous Records from
PSA:
When ever a DTP fails because of erroneous records while fetching the data from
PSA to Data Target, in such cases data needs to be changed in the ECC. If it is
not possible, then after getting the approval from the business, we can edit
the Erroneous records in PSA and then we have to run the DTP.
Go to PSA -> select
request -> select error records -> edit the records and save.
Then run the DTP.
2. INFO
PACKAGE FAILURE:
The following are the reasons for Info Pack failure.
·
Source System Connection failure
·
tRFC/IDOC failure
·
Communication Issues
·
Processing the IDOC Manually in BI
·
Check the source system connection with the help of
SAP BASIS, if it is not fine ask them to rebuild the connection. After that
restart the job (Info Pack).
Go to RSA1 ->
select source system -> System -> Connection check.
·
In case of any failed tRFC’s/IDOC’s, the error message
will be like “Error in writing the partition number DP2” or “Caller 01, 02
errors”. In such case reprocess the tRFC/IDOC with the help of SAP BASIS, and
then job will finish successfully.
·
If the data is loading from the source system to DSO
directly, then delete the bad request in the PSA table, then restart the job
·
Info Pack Long Run: If an info pack is running long,
then check whether the job is finished at source system or not. If it is
finished, then check whether any tRFC/IDOC struck/Failed with the help of SAP
BASIS. Even after reprocessing the tRFC, if the job is in yellow status then
turn the status into “Red”. Now restart / repeat the step. After completion of
the job force complete.
·
Before turning the status to Red/Green, make sure
whether the load is of Full/Delta and also the time stamp is properly verified.
·
Time Stamp
Verification:
Select Info Package-> Process Monitor -> Header
-> Select Request -> Go to source System (Header->Source System) ->
Sm37-> give the request and check the status of the request in the source
system -> If it is in active, then we have to check whether there any
struck/failed tRFC’s/IDOC’s
If the request is in Cancelled status in Source system
-> Check the Info Pack status in BW system -> If IP status is also in
failed state/cancelled state -> Check the data load type (FULL or DELTA)
-> if the status is full then we can turn the Info Package status red and
then we can repeat/restart the Info package/job. -> If the load is of Delta
type then we have to go RSA7 in source system-> (Compare the last updated
time in Source System SM37 back ground job)) Check the time stamp -> If the
time stamp in RSA7 is matching then turn the Info Package status to Red ->
Restart the job. It’ll fetch the data in the next iteration
If the time stamp is not updated in RSA7 -> Turn
the status into Green -> Restart the job. It’ll fetch the data in the next
iteration.
Source System
|
BW System
|
Source System RSA7
|
Source System SM37
|
Action
|
I/P
Status RED(Cancelled)
|
I/P
Status (Active)
|
Time
stamp matching with SM37 last updated time
|
Time
stamp matching with RSA7 time stamp
|
Turn
the I/P Status into Red and Restart the Job
|
I/P Status RED(Cancelled)
|
I/P Status (Cancelled)
|
Time stamp matching with SM37 last updated time
|
Time stamp matching with RSA7 time stamp
|
Turn the I/P Status into Red and Restart the Job
|
I/P Status RED(Cancelled)
|
I/P Status (Active)
|
Time stamp is not matching with SM37 last
updated time
|
Time stamp is not matching with RSA7 time stamp
|
Turn the I/P status into Green and Restart the job
|
I/P Status RED(Cancelled)
|
I/P Status (Cancelled)
|
Time stamp is not matching with SM37 last
updated time
|
Time stamp is not matching with RSA7 time stamp
|
Turn the I/P status into Green and Restart the job
|
·
Processing the IDOC
Manually in BI:
When there is an IDOC which is stuck in the BW and
successfully completed the background job in the source system, in such cases
we can process the IDOC manually in the BW.
Go to Info Package -> Process Monitor -> Details
-> select the IDOC which is in yellow status(stuck) -> Right click ->
Process the IDOC manually -> it’ll take some time to get processed.
******Make sure that we can process the IDOC in BW
only when the back ground job is completed in the source system and stuck in
the BW only.
3. DSO
Activation Failure:
When there is a failure in DSO activation step, check
whether the data is loading to DSO from PSA or from the source system directly.
If the data is loading to DSO from PSA, then activate the DSO manually as
follows
·
Right click DSO Activation Step -> Target
Administration -> Select the latest request in DSO -> select Activate
-> after request turned to green status, Restart the job.
·
If the data is loading directly from the source system
to DSO, then delete the bad request in the PSA table, then restart the job
4. Failure
in Drop Index/ Compression step:
When there is a failure in Drop Index/ compression
step, check the Error Message. If it is failed due to “Lock Issue”, it means
job failed because of the parallel process or action which we have performed on
that particular cube or object. Before restarting the job, make sure whether
the object is unlocked or not.
There is a chance of failure in Index step in case of
TREX server issues. In such cases engage BASIS team and get the info reg TREX
server and repeat/ Restart the job once the server is fixed.
Compression Job may fail when there is any other job
which is trying to load the data or accessing from the Cube. In such case job
fails with the error message as “Locked by ......” Before restarting the job,
make sure whether the object is unlocked or not.
5. Roll Up
failure:
“Roll Up” fails due to Contention Issue. When there is
Master Data load is in progress, there is a chance of Roll up failure due to
resource contention. In such case before restarting the job/ step, make sure
whether the master data load is completed or not. Once the master data load
finishes restart the job.
6. Change Run
– Job finishes with error RSM 756
When there is a failure in the attribute change run
due to Contention, we have to wait for the other job (Attribute change run)
completion. Only one ACR can run in BW at a time. Once the other ACR job is
completed, then we can restart/repeat the job.
We can also run the ACR manually in case of nay
failures.
Go to RSA1-> Tool -> Apply Hierarchy/Change Run
-> select the appropriate Request in the list for which we have to run ACR
-> Execute.
7. Transformation
In-active:
In case of any changes in the production/moved to the
production without saving properly or any modification done in the
transformation without changing, in such cases there is a possibility of Load
failure with the error message as “ Failure due to Transformation In active”.
In such cases, we will have to activate the
Transformation which is inactive.
Go to RSA1 -> select the transformation ->
Activate
In case of no
authorization for activating the transformation in production system, we can do
it by using the Function Module - RSDG_TRFN_ACTIVATE
Try the following steps to use
the program "RSDG_TRFN_ACTIVATE” here you will need to enter certain
details:
Transformation ID:
Transformation’s Tech Name (ID)
Object Status: ACT
Type of Source: “Source Name”
Source name: “Source Tech Name”
Type of Target: Target Name
Target name: “Target Tech Name”
A.
Execute. The Transformation
status will be turned into Active.
Then we can restart the job.
Job will be completed successfully.
8. Process
Chain Started from the yesterday’s failed step:
In few instances, process chain
starts from the step which was failed in the previous iteration instead of
starting from the “Start” step.
In such cases we will have to
delete the previous day’s process chain log, to start the chain form the
beginning (from Start variant).
Go To ST13-> Select the
Process Chain -> Log -> Delete.
Or we can use Function Module
for Process Chain Log Deletion: RSPROCESS_LOG_DELETE.
Give the log id of the process
chain, which we can get from the ST13 screen.
Then we can restart the chain.
Turning the Process Chain Status using Function Module:
At times, when there is no progress in any of
the process chains which is running for a long time without any progress, we
will have to turn the status of the entire chain/Particular step by using the
Function Module.
Function Module: RSPC_PROCESS_FINISH
The program
"RSPC_PROCESS_FINISH" for making the status of a particular process
as finished.
To turn any DTP load which was
running long, so please try the following steps to use the program
"RSPC_PROCESS_FINISH" here you need to enter the following details:
LOG ID: this id will be the id
of the parent chain.
CHAIN: here you will need to
enter the chain name which has failed process.
TYPE: Type of failed step can
be found out by checking the table "RSPCPROCESSLOG" via
"SE16" or "ZSE16" by entering the Variant & Instance of
the failed step. The table "RSPCPROCESSLOG" can be used to find out
various details regarding a particular process.
INSTANCE & VARIANT:
Instance & Variant name can be found out by right clicking on the failed
step and then by checking the "Displaying Messages Options" of the
failed step & then checking the chain tab.
STATE: State is used to
identify the overall state of the process. Below given are the various states
for a step.
R Ended with errors
G Successfully completed
F Completed
A Active
X Canceled
P Planned
S Skipped at restart
Q Released
Y Ready
Undefined
J Framework Error upon
Completion (e.g. follow-on job missing)
9. Hierarchy save Failure:
When
there a failure in Hierarchy Save, then we have to follow the below process...
If
there is an issue with Hierarchy save, we will have to schedule the Info
packages associated with the Hierarchies manually. Then we have to run Attribute
Change Run to update the changes to the associated Targets. Please find the
below mentioned the step by step process...
ST13->
Select Failed Process Chain -> Select Hierarchy Save Step -> Rt click
Display Variant -> Select the info package in the hierarchy -> Go to RSA!
-> Run the Info Package Manually -> Tools -> Run Hierarchy/Attribute
Change Run -> Select Hierarchy List (Here you can find the List of
Hierarchies) -> Execute.
No comments:
Post a Comment