There are instances when Batch Jobs loading to data targets through PSA fail/do not complete. On checking the tRFCs we find there are tRFCs failing with error.
On deeper analysis we find there are short dumps in ST22 for each and every data packet that comes into BW for this particular data load.
Below is the snapshot from ST22.
On looking at the Source Code Extract, it becomes evident that the data load fails while creating a new partition.
On further researching it was discovered that the PSA table had already reached maximum number of partitions. As seen in the below snapshot, the partition number for this particular datasource (PSA) has already been reached to 9999.
As per the SAP Note 1816538 – UNCAUGHT_EXCEPTION in PSA_PART_EXIST because of PSA Partitioning, adding partitions beyond 9999 is not permitted.
When the data load tries to insert records in the PSA it first creates a partition and then loads data into that partition.
There might be times when dropping all data from the PSA would fix the issue (i.e. reset the partition number in the table RSTSODS).
However, when dropping data does not reset the partition number, we need to follow the below procedure:-
1. Make a note of the partition number for the PSA in Development system.
2. Drop all data from the PSA and Replicate the datasource.
3. Activate the data source and capture the data source along with the dependent objects (Update Rule/Transformation/Transfer Rules/Communication Structure).
4. Check the partition number for the PSA again in RSTSODS table – it should have been changed and reset to a lower number.
5. Before moving the change to QA system, make sure to drop all data from the PSA in QA and also make a note of the partition number in QA.
6. After successfully moving the change to QA, check for activation of dependent objects and then check the partition number in RSTSODS table – it should have been reset also.
7. Follow the same procedure before transporting to Production – Drop data from PSA, move the transport and then check the partition number in RSTSODS table – it should have been reset as shown in below snapshot.