Child pages
  • PSA Check and Repair reports
Skip to end of metadata
Go to start of metadata
 Before executing any report below is recommended to search for correction and implement them first
RSAR_PSA_CLEANUP_DIRECTORY/_MSThis report is used to check the PSA tables against the directory entries and the partition related inconsistencies.It is useful in scenarios when the PSA requests are deleted from the administrative data but not from the database, requests are not available in the PSA tree but exist in the corresponding PSA table, all the requests in a partition are deleted but the partition is not dropped and to check if data has been deleted or written into incorrect partitions1063105 (7.X)

1102626 (3.X)
SAP_PSA_PARTNO_CORRECTThis report is used to correct the incorrect partition assignment ie. requests getting assigned to PARTNO "0" in the PSA table.This report also helps reassigning the requests to the correct partition1051664(7.X)

 3RSAR_PSA_PARTITION_CHECKThis check report is used to detect the possible problems of indices and other database related issues of the PSA. This report helps in detecting the following inconsistencies:
   a) Partitioning with global index
   b) Inconsistencies between DDIC definition and DB tables
   c) PSA definition without DDIC entry and vice-versa.
1012607,1338941 (7.X)


This report checks the PSA tables in the system for consistency of the metaobjects and has correction options. If necessary the system set the status to INA in case an old version of the PSA table does not exists in the system anymore. In order to be able to extract data from an old PSA version some points has to be considered (see SAP note 2129192) and also the status has to be ACT in table RSTSODS.

 There are three options provided:
     a) Delete table definitions without DB
     b) Delete PSA definitions that are no longer in use
     c)  Delete initial PSA tables that are not in use

939383,1332091, 2191080

768023 (3.X)


The report checks whether a single request is splitted with two PARTNO values in RSTSODSPART but assigned to single partition in the database.


database table was used multiple times in the contents of the 'RSTSODS'
table.This table defines the usually unique assignment of a PSA table to a
DataSource of a source system.
RSAR_RSTSODS_CHANGELOG_VRSThis report check whether a standard DSO has versioned changelog. It tries to Inactivate the definition of that version of changelog which has no data 1135256
 8RSAR_PSA_NEWDS_MAPPING_CHECKused to find the psa's which are not mapped to any NEW_DS (entry in RSTSODS, no entry in RSDSSEG, entry in RSDS) 1377274, 1649615
 9ZRS_CHECK_ORPHANPSA_NEWDSSets the Objstat = ACT in RSTSODS for entries with RSDSSEG = A , RSTSODS = INA provided the table should be active in the DB. 1649615
 10RSAR_NEWDS_PSA_USEROBJ_CHECKused to cross check the field USEROBJ in RSTSODS with the fields(DATASOURCE , LOGSYS) of RSDSSEG 1435104
 11RSAR_PSA_SPLIT_PARTNO_CORRECTHelps to find and repair duplicate entries in RSTSODSPART. One request should not be stored in multiple partitions. Move records to highest partition and adjust RSTSODSPART 1475255

 only for HANA database; conversion or subsequent partitioning of DSO objects

 1924115, 1776749, 1785116
 13 RSAR_PSA_REPARTITION repartitioning in case max. partion 9999 has been reached 2002607, 2247910









  1. Former Member

    Thank you. Great overview. I solved my Problem with this!

  2. Hi!

    This is great info! Thanks!

    We had a different problem with PSA after migration to BW 7.5. We opened an incident and got the following solution, which you might want to add to your list:

    And the reason for the dump is that the type /BIC/WB000.... mentioned in dumps belonging the previous PSA version does not exists.
    This is documented in the note:
    1765506 SP30:'RS_PSA_TABTYPE_EXISTENCE_CHECK' to check PSA tab types
    Please run the report RS_PSA_TABTYPE_EXISTENCE_CHECK in check mode first and then in repair mode.

    Best regards