How Does that Work?

…
<PSA & DSO Changelog
Deletion>

Author: Thad Gustafson

Applicable Releases: NW2004S
Test conducted on BI SP 12 (Oracle 10.2 DBMS)

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 1 OF 6 02/04/08 11:10 AM
1 Business Scenario
A PSA or Data Store Change-log maintenance strategy has been implemented to clean up and/or
remove old data from temporary/staging areas in BI. In some cases after the standard BI job
(BI_PSAD*) has run program RSPSADEL1 (PSA Delete Program based on table RSPSADEL), the
database size has not decreased as expected in DB02 and old requests and data are still visible
through the data browser tools (SE16, etc.)

2 The Result
This scenario occurs due to how the standard delete process works in SAP BI. In order to efficiently
handle data on the database level, SAP BI waits until all requests in a given table partition of a
PSA/Change-log table have been flagged for deletion before performing the actual delete on the
database using a drop partition statement. To the end user or to the application, all requests that
have been flagged as deleted are no longer considered available to the load process.

This is not an issue, but simply something to be aware of if your friendly basis team begins to ask
questions about why space is being handled in a certain way, or if someone is looking at the change
log with the data browser and sees data for requests that have been deleted.

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 2 OF 6 02/04/08 11:10 AM
3 The Step By Step Explanation

1. The size of table partitions for PSA Maintain Control Parameters for the data transfer
and Change-log tables is defined
centrally in SPRO for ALL. • PSA partition size
dataSources. The default is set at 1 Here you set the number of records that is reached before
million records. This means that BI the system creates a new partition for the PSA table. This
value is set at 1,000,000 records by default.
will keep writing requests to the
same partition until it meets or Note:
exceeds that number. The o This setting applies to DataSources from all source
systems.
application will not write a request
across partitions, meaning one
request will always be in one and
only one partition. It is possible to
have loading requests (type REQU_
or DTPR 1 _ ) in the same partition as
an activation request (type ODSR_).

2. To set the partitioning parameter for

PSA/Change-log tables, one may
use transaction RSCUSTV6 or go
through the project IMG (SPRO)
using the menu path shown.

1
DTPR_ requests will only be present in the RSTSODSPART table for loads from Write Optimized
DSO objects and DTP Error Stacks

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 3 OF 6 02/04/08 11:10 AM
3. Using an example to demonstrate
the PSA/Change-log deletion, a
generated PSA table
/BIC/B0000180000 is displayed in
transaction DB02 (Database
Performance: Tables & Indexes).
One may see that there are several
partitions that exist for this table by
the suffix attached to the table name.
In this case 5 partitions are shown
(0002 – 0007).

4. In the table RSTSODSPART

(Partitioning Information), the same
table is displayed, showing which
requests exist in which partitions of
the table, and how many records are
in each request. Partition 2 has one
request with over a million records
(meaning the next request would
automatically get written to the next
partition as shown, in partition
0003). Summing all the records for
the requests that exist in a partition,
one will observe that a new partition
is created as soon as the threshold is
met from RSCUSTV6. The last
partition (0007) is still being loaded
to in the example.

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 4 OF 6 02/04/08 11:10 AM
5. If one removes data and maintains
the PSA/Change-log for table
/BIC/B00001800000, but selects to
do so based upon a time interval
which has requests in two partitions,
the following scenarios may result.
I. If there are other requests in one of
the partitions that are newer than
the date provided or criteria
provided for the deletion:
Control data for the requests
meeting the deletion criteria will
be removed from table
RSREQICODS for the logical
tablename of the PSA table in
question as shown in the job log.
If all requests in a partition can be
removed based upon the criteria,
the application will execute a
“drop partition” command and
remove the database partition
along with all the data in the
partition as shown in the job log
and in DB02 (partition 0002 was
completely removed).
Requests in a partition with other
requests that do not meet the
deletion criteria will be marked as
“Deleted” in table RSTSODSPART
and will no longer be visible from
the “Deleting Change Log Data”
screen available from the manage
menu of a DSO and will no longer
be visible in the manage
dataSource screen.
The requests and their associated
data will still be visible through
SE16 if one is browsing table
contents.
The storage size of the associated
tables as well as the physical
partitions will persist in DB02 until
all requests in the partition can be
removed.

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 5 OF 6 02/04/08 11:10 AM
 II. If all the requests in the partitions
meet the deletion criteria based
upon the “older than” or “before”
selection:
All data will be removed from the
associated table with the drop
partition statement and no longer
be visible anywhere in BI.
The partition will no longer exist
in the database or be visible from
DB02.
The table RSTSODSPART will no
longer contain entries for that
partition.

HOW DOES THAT WORK… PSA&DSO CHANGELOG DELETION.DOC PAGE 6 OF 6 02/04/08 11:10 AM