(OH-2108) Activities (Tasks) - SNP (2024)

TemSe Objects Consistency Check

Introduction

TemSe is a store for temporary sequential data, e.g. objects that are not normally permanently held in the system. TemSe objects consist of a header entry (stored in table TST0 e.g. and the object itself (stored in the file system or in table TST03)).
This task checks the consistency of the object header and object data. However, it doesn't check the spool requests (stored in table TSP01) and entries in the table TSP02, if output request exists.

Step list

In the main OutBoard Housekeeping menu select "TemSe Objects Consistency Check – Settings" under the Basis/Deletion Tasks.
Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
Shouldyou create new settings, the "Description" field needs to be filled. In "Selection criteria", you can fill "Client" field if the check will be made for a specific client. "TemSe object (pattern)" will determine the range of checked objects.

_{TemSe Objects Consistency Check – Settings detail}

If "Create settings for TemSe Cleanup based on selection" is checked, a consistency check will prepare the settings for "TemSe Objects Cleanup" task. Settings ID can be found in consistency check logs – "Problem class Important".
Click on the info button "Save settings" to save the selection, for any further updates click on "Modify Settings" info button and confirm.
Once settings for TemSe objects consistency check are specified,you may run the created/modified Settings group from the Main menu. There are several options on how to start the deletion, for more information, please refer toExecute and Schedule sections of this user documentation.
You should specify the Settings ID when executing/ scheduling the activity.
To check the status of the run,you can go to the monitor or check the logs.

Recommendations

It is recommended to run a consistency check twice with a gap of approx. 30 minutes. Outputs have to be compared and only those TemSe objects, which are in both, should be deleted. Thus the temporary inconsistencies are eliminated.

Warning

TemSe storage is not intended as an archiving system. It can contain a limited number of spool requests (default value – 32000, but can be increased up to 2 billion) which can affect the performance.

Related Notes

48284

TemSe Objects Cleanup

Introduction

This task follows the previous one. Because of it, see the introduction "TemSe Objects Consistency Check" to learn more about TemSe objects background.

Step list

There are two ways how to prepare the settings.

1. In the main OutBoard Housekeeping menu select "TemSe Objects Cleanup – Settings" under the Basis/Deletion Tasks.

Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
Shouldyou create new settings, the "Description" field needs to be filled. In "Selection criteria", selection of the object can be done in two ways: First is by making it an absolute selection:you can fill "Client" field if the check will be made for a specific client. "TemSe object (pattern)" will determine the range of checked objects. The second way is to create relative selection whereyou can specify how old objects should be deleted and whether also obsolete objects should be deleted.
"Test mode" option is checked by default.

_{TemSe Objects Deletion – Settings detail relative selection}

_{TemSe Objects Deletion – Settings detail relative selection}

1. In "TemSe Objects Consistency Check" task, check "Create settings for TemSe Cleanup based on selection" and execute. Now generated settings are prepared based on consistency check. But be aware, they are not differential as recommended for consistency check and can also contain temporary inconsistencies.

In generated settings, the "Test mode" option is unchecked.
In this case, all TemSe objects that fit the criteria are stored in Select-Options (see the figure below).

_{TemSe Objects Deletion – Multiple selection detail}

Recommendations

It is recommended to run TemSe objects cleanup as a follow-up of TemSe objects consistency check.

XML Messages Deletion

Introduction

SAP Exchange Infrastructure (SAP XI) enables the implementation of cross-system processes. It is based on the exchange of XML messages. It enables to connection of the systems from different vendors and different versions.
SXMSCLUP and SXMSCLUR tables are part of SAP XI. When using SAP XI extensively, their size can increase very rapidly. Therefore, regular deletion is highly recommended.
XML messages deletion task offers the possibility to delete different XML messages in one-step.

Recommendation

It is possible to set a retention period for them separately according to the message type and status. Our recommendation for setting the retention period is the following:

• Asynchronous messages without errors awaiting... 1 day
• Synchronous messages without errors awaiting ... 1 day
• Synchronous messages with errors awaiting ... 0 days
• History entries for deleted XML messages ...30 days
• Entries for connecting IDocs and messages ... 7 days

This task should be scheduled to run on a daily basis.

Step list

In the main OutBoard Housekeeping menu select "XML Message Deletion – Settings" under the Basis/Deletion Tasks.
Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
The next step is to provide time settings for XML Message deletion in settings. The time frame can be specified as Days, Hours, Minutes, and Seconds.

_{XML Message Deletion – Settings detail}

Single Z* Table Cleanup

Introduction

The customer-defined tables can sometimes grow rapidly, depending on the purpose of these tables over time and the content may no longer be needed. OutBoard Housekeeping offers the possibility to delete selected data from any customer-defined table from naming convention Z* / Y* and keep it in the Recycle Bin for a selected period of time.
The name of the task itself points to the intention to safely cleanup only one Z* table during the execution without any development effort in contrast to the OutBoard Housekeeping feature called Custom objects cleanup. This feature enables us to manage any number of related tables but requires some small amount of coding.

Step list

In the main OutBoard Housekeeping menu, select "Single Z* Table Cleanup – Settings" under the Basis/Deletion Tasks.
Then the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
The next step is to provide the table name and generate the selection screen.

_{Single Z Table Cleanup – initial screen*}

The Settings can be saved according to the entered table-specific selections.

_{Single Z Table Cleanup – test run results*}

Test run functionality is available for this task. The result of the test run is the number of entries that will be deleted from the "Z" and moved into the recycle bin for the current selection.
There are several options on how to start the Single Z* Table Cleanup. For more information, please refer to Execute and Schedule sections of this user documentation.

HANA Audit Log Cleanup

Introduction

Old audit data can be deleted from the SAP HANA database audit table. This is only applicable if audit entries are written to the column store database tables. The threshold date can be set as a specific date or it can be set relatively – all log entries older than x days will be deleted.

Step list

In the main OutBoard Housekeeping menu select "HANA Audit Log Cleanup – Settings" under the Deletion Tasks.
Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
The next step is to provide selection conditions for HANA Audit Log Cleanup in settings. The time frame can be specified as 'Before date' or 'Older than (days).

_{HANA Audit Log Cleanup settings}

Recommendation

The size of the table can grow significantly therefore we recommend scheduling this task to delete audit logs on weekly basis. The retention time of logs depends on the company policy and local legal requirements.

HANA Traces Cleanup

Introduction

All the trace files opened by the SAP HANA database and their content can be deleted. Types of trace files that are deleted can be the following:

• ALERT
• CLIENT
• CRASHDUMP
• EMERGENCYDUMP
• EXPENSIVESTATEMENT
• RTEDUMP
• UNLOAD
• ROWSTOREREORG
• SQLTRACE

The task deletes all traces on all hosts when it is executed on a distributed system. Trace files are just compressed and saved, not deleted when checkbox 'With backup' is marked.

Step list

In the main OutBoard Housekeeping menu select "HANA Traces Cleanup – Settings" under the Deletion Tasks.
Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
The next step is to provide selection conditions for HANA Traces Cleanup in the settings. This task can run in test mode and there is also the possibility to store the backup data. Required types of traces can be selected.
Housekeeping allowsyou to delete traces that are older than a set amount of days. In the case of an older release than SAP HANA Platform SPS 09, this setting will be ignored.

_{HANA Traces Cleanup settings}

Recommendation

Our recommendation is to run this task to reduce disk space used by large trace files, especially trace components INFO or DEBUG.

Introduction

Intermediate Documents (IDocs) are stored in several tables in the database. To control their size and improve the access time without losing any IDocs, they can be stored in the archives at the operating system level. These archives can be moved to the external storage media for future retrieval. Archived IDocs should be optionally deleted from the SAP system.
This task encapsulates the SAP NetWeaver data archiving concept using the SARA transaction and WRITE action. The archiving object IDOC contains information about which database tables are used for archiving. In runtime, the report RSEXARCA is executed.

Step list

In the main OutBoard Housekeeping menu select "Intermediate Documents Archiving – Settings" under the Basis/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen, you can set the criteria for the requests to be archived.

_{Intermediate Documents Archiving – Settings detail}

There are several options on how to start the Intermediate Documents Archiving. For more information, please refer toExecute and Schedule sections of this user documentation.

Warning

Only use the archiving if the IDocs were not activated through the application. Please make sure that no IDocs are activated and may still be needed by the application.

Work Items Archiving

Introduction

For archiving and deleting of the work items, the archiving object WORKITEM is used.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept by using the SARA transaction and WRITE action. The archiving object WORKITEM contains information about which database tables are used for archiving. During runtime, the report WORKITEM_WRI is executed.

Step list

In the main OutBoard Housekeeping menu select "Work Items Archiving – Settings" under the Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen,you can set the criteria for the requests to be archived.

For more detailed information, see the contextual help.

_{Work Items Archiving – Settings detail}

There are several options on how to start the Work Items Archiving. For more information, please refer toExecute and Schedule sections of this user documentation.

Prerequisites

Work Items that you want to archive should have the status Completed of Logically deleted (CANCELLED).

Recommendations

We recommend running Work Items archiving regularly. The frequency of archiving is system-specific.

Note

SAP recommends using the archive information structure SAP_O_2_WI_001, which is necessary if you are using ABAP classes or XML objects. If you are using only BOR objects and are already using archive information structure SAP_BO_2_WI_001, you can continue to use it but SAP recommends that you switch to the extended archive information structure SAP_O_2_WI_001.

Change Documents Archiving

Introduction

While using the CHANGEDOCU solution, any document changes to master data, tables, documents, etc. are archived.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept, by using SARA transaction and WRITE action. The archiving object CHANGEDOCU contains information about which database tables are used for archiving. In runtime, the report CHANGEDOCU_WRI is executed.

Step list

In the main OutBoard Housekeeping menu select "Change Documents Archiving – Settings" under the Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen,you can set the criteria for the requests to be archived.

For more detailed information, see the contextual help.

_{Change Documents Archiving – Settings detail}

There are several options on how to start the Change Documents Archiving. For more information, please refer toExecute and Schedule sections of this user documentation.

Recommendations

We recommend running the Change Documents archiving regularly. The frequency of archiving is system-specific.

Note

Use the Change Document Archiving to archive the change documents of master data. Change documents for transactional data should still be archived together with the corresponding archiving of the application.

Warning

The business transactions need to be traceable, change documents cannot be deleted for a certain period of time. However, to reduce data volumes in the database, you can archive those change documents that you no longer need in current business processes. You can keep them outside the database for the duration of the legal retention time.

Links Deletion between ALE and IDocs

Introduction

Links are written in the ALE and IDoc environments. These are required for IDoc monitoring of the document trace and ALE audit.
They result in a rapid increase in the size of IDOCREL and SRRELROLES tables.

Recommendation

Links of the type IDC8 and IDCA can be deleted on a regular basis because they are generally no longer required after the IDocs are successfully posted in the target system. For more information, see the related note.

Related Notes

505608

IDocs Deletion

Introduction

IDoc stands for Intermediate Document. It is a standard SAP document format. IDocs enable the connection of different application systems using a message-based interface.
IDoc data is stored in the following DB tables:

• EDIDCcontrol record
• EDIDOCINDXcontrol record
• EDIDOvalue table for IDoc types
• EDIDOTshort description of IDoc types
• EDIDSstatus record
• EDIDD_OLDdata record
• EDID2data record from 3.0 onwards
• EDID3data record from 3.0 onwards
• EDID4data record from 4.0 onwards
• EDID40data record from 4.0 onwards

In case the old IDocs are being kept in the system, these EDI* tables may have become too big.
Unlike the standard SAP settings, this task is extended and enables to set the date of document creation as absolute or a relative value (relative value has a higher priority).

_{IDOCs deletion – Settings detail}

Recommendation

Our recommendation is to run this IDocs Deletion regularly. The period is system-specific.

IDocs Deletion (Central system release >= 7.40)

Introduction

This task replaces the task "IDocs Deletion" in case the central system version is the same or higher than 7.40.
This report deletes IDocs without archiving them. It provides the option for also deleting other objects that were created during IDoc generation - objects such as work items, links, RFC entries, and application logs.

Step list

Make an IDoc selection in accordance with the selection criteria given. If the checkbox 'Test Run' is marked, the IDocs and linked objects will be determined in accordance with the selection made but they will not be deleted. Using the 'Maximum Number of IDocs' parameter, you can control how many IDocs should be deleted. It is not recommended to leave this parameter empty, in case you do, all the IDocs in your selection will be taken into consideration. The recommended value for this parameter is 100000.
Determining the linked objects is a complex process. Activate the additional functions only if the respective objects are created during IDoc generation and are not already removed from your system by another action.
Dynamic variant usage is available for this task.

BCS Reorganization of Documents and Send Requests

Introduction

The Business Communication Services (BCS) offer functions for SAP applications to send and receive e-mails, faxes, or SMS messages. BCS offers an ABAP programming interface connected to SAPconnect allowing for exchanging messages with e-mail servers via SMTP.
This task deletes documents with send requests or documents that are not part of a send request if they are no longer in use and in accordance with the settings under "Reorganization Mode".

Recommendation

It is recommended to run this task when the related tables are increasing over time and data is no longer required.

Related Notes

966854
1003894

Introduction

Some applications use the 'dark folder' (meaning it is not visible in the Business Workplace) to store Business Communication Services documents.
This task removes documents from the 'dark folder' and therefore allows the reorganization of the documents and the document content.

Recommendation

It is recommended to run this task when the SOOD, SOFM, SOC3, SOOS, SOES tables have become considerably large and are not significantly reduced when you run common reorganization reports.

Related Notes

567975

Reorganization Program for Table SNAP of Short Dumps

Introduction

This program deletes old short dumps from the table SNAP. The dumps that may be kept, can be then selected in transaction ST22.
The program parameters that can be set are the following:

• The maximum number of entries to remain after the reorganization.
• The maximum number of table entries to be deleted at once.
• Storage date.

The program first deletes the short dumps older than the storage date and not flagged as protected. If there are more entries in the table SNAP than are specified in the first parameter, later short dumps will also be deleted.
In the program, the delete process is split into small units so that only a certain number of entries can be deleted at one time. This prevents the occurrence of any set problems in the database. The split is set in the second program parameter.

Table Log Database Management

Introduction

Once the table logging is activated, there is a possibility to review the history of changes done in custom tables. These changes are saved in the DBTABLOG table. Logging is carried out "record by record", which means for every change operation, the image of "before state" is written to the log table. This approach is space-consuming. So it is really important to adopt a well-balanced table logging policy to ensure that the data growth of the DBTABLOG table will be acceptable.
It is possible to delete the data saved in DBTABLOG using the RSTBPDEL report.

Recommendation

Our recommendation is to prepare a table-logging policy and to decide with the cooperation of data owners which tables will be logged.

Warning

Activating logging in a table has an important disadvantage – updates/modifications to the Z tables for which logging is activated can become slow.

Spool Administration

Introduction

Spool Administration (transaction SPAD) is intended for administrators to cover the following activities:

• Defining output devices in the SAP system.
• Analyzing printing problems.
• Maintaining the spool database – scheduling in the dialog.

Warning

This task cannot be executed on a system connected via SYSTEM type RFC user.

Introduction

An update is asynchronous (not simultaneous). Bundling all updates for one SAP transaction into a single database transaction ensures the data belonging to this SAP transaction can be rolled back completely.
An update is divided into different modules corresponding with the update of function modules. The SAP System makes a distinction between:

• Primary (V1, time-critical) update module;
• Secondary (V2, non-time-critical) update module.

An update request or update record describes the data changes defined in an SAP LUW (Logical Unit of Work), carried out either in full or not at all (in the database LUWs for V1 and V2 updates).
This tool allows editing of update requests:

• Starting V2 updating (normally, V2 updating starts directly after V1 updating; for some reasons – e. g. performance bottleneck – V2 update should be postponed by unchecking the STARTV2 option)
• Deleting successfully executed update requests (update requests are normally deleted after they have been successfully executed but for performance issues, this behavior should be switched off by unchecking the DELETE option)
• Reorganizing the update tables (termination of a transaction in progress can lead to incomplete update requests in the update tables; to delete them, run this tool with REORG option checked).

Recommendation

If V2 is not updated directly, the update should be started as often as possible (several times a day). Otherwise, the update tables can get very large.
If deletion is not carried out directly, it should be carried out as often as possible (several times a day).
A reorganization of the update tables is necessary only occasionally (once a day is sufficient).

Delete Statistics Data from the Job Run-time Statistics

Introduction

A number of job run-time statistics are calculated during/after the jobs are run. These statistics should be deleted when they become obsolete.
This report reorganizes job run-time statistics. A period can be specified by days or by date. All period-statistics records are deleted.

Recommendation

Our recommendation is to run this task monthly.

Batch Input: Reorganize Sessions and Logs

Introduction

If the batch input functionality of the R/3 system is utilized, log entries are produced. This program is responsible for cleaning up the batch input sessions and their logs.
The report does the following:

• Deletes (successfully) processed sessions still in the system and their logs. Only these sessions are deleted and not "sessions still to be processed", "sessions with errors", and so on.
• Deletes logs, for which sessions no longer exist.

Recommendation

We recommend periodical use of the program RSBDCREO to reorganize the batch input log file once a day. It can run RSBDCREO in the background or interactively.

Warning

Batch input logs cannot be reorganized using TemSe reorganization, they must be reorganized using the program RSBDC_REORG or transactions SM35/SM35P.

Delete Old Spool Requests

Introduction

Report RSPO1041 is used to tidy up the spool database and to delete old spool requests. This must be done regularly in the productive system, as the spool database may only contain 32000 spool requests.
For the additional info, see program documentation (variant screen).
If the previous version of this report (RSPO0041) has been scheduled, it will continue working. It can be re-scheduled but ii cannot be newly scheduled from scratch.

Deletion of Jobs

Introduction

The report RSBTCDEL2 runs in the background. This task is provided by SAP to delete old, inconsistent, and non-deleted jobs from the system. It replaces the previously used report RSBTCDEL.

Recommendation

Our recommendation is to run this task regularly in the background once a day.

Related Notes

784969

Orphaned Job Logs Search and Deletion

Introduction

Obsolete jobs deleted with the report RSBTCDEL (predecessor of current report RSBTCDEL2). Sometimes logs that are left cannot be deleted (e.g. problems with the system). These logs are called "orphans".
This task searches, checks, and deletes these "orphans".

Recommendation

Our recommendation is to run this task regularly in the background once a week.

Related Notes

666290

Spool Files Consistency Check

Introduction

For the SPOOL files, the DIR_GLOBAL directory, or in the client-specific ADSP subdirectories, some of these may be very old. Usually, these files are removed by deleting the relevant spool request. However, under certain circ*mstances, these files may remain in the system as "orphaned" files.

Recommendation

This task checks whether spool requests still exist in the DIR_GLOBAL directory (ADS and SAP GUI for HTML print requests). If no more spool requests exist, the files are deleted. This task should be scheduled daily.

Related Notes

1493058

Administration Tables for BG Processing Consistency Check

Introduction

Background processing stores the job data in multiple database tables and these tables can be checked for consistency. This test is especially important if problems with the database occur and you need to determine whether all job data is still available. The report includes two predefined variants that you can use in the job step. These are:

Variant SAP&AUTOREPNO: Use this variant if consistency problems should only be listed in the output list. No automatic repair of the problems is performed.
Variant SAP&AUTOREPYES: Use this variant, if consistency problems should be logged and automatically corrected.

Recommendation

This task should be scheduled daily.

Related Notes

1440439
1549293

Active Jobs Status

Introduction

Sometimes jobs remain in the status 'active' after the background work process terminates or after database connection problems occur and their status can be corrected manually using transaction SM37. This task will do so automatically.

Recommendation

This task should be scheduled hourly.

Related Notes

16083

Collector for Background Job Run-time Statistics

Introduction

This task creates job statistics and should run daily.

Recommendation

Make sure the note 2118489 is installed in the system otherwise; RSBPCOLL has poor performance and performs too many DB accesses.

Related Notes

16083
2118489

Performance monitor (RFC) Collector

Introduction

This report starts via RFC reports on all servers (SAPSYSTEMS) belonging to the SAP-system of one database (compare SM51), which collects performance relevant data of these servers and writes them to the performance database MONI. Furthermore, it starts the reports to collect and store information about the database system itself. These reports will be started on the database server if there is a dialog system available – otherwise, the first dialog system in the system list will be used.
It has components RSSTAT80 that read local statistic data from the shared memory and stores it in the performance table MONI and component RSSTAT60 that creates statistic data for a day, week, month, and year and reorganizes the table MONI. It also updates the following tables:

RSHOSTDB – data for the host system monitor
RSHOSTPH – protocol changes on host parameters
RSORATDB – analyzes the space of the database
RSORAPAR – protocol changes on database parameters.

Recommendation

This task should be scheduled hourly. It must always be scheduled in the client 000 with a user DDIC or with a user with the same authorization.

Related Notes

16083

Orphaned Temporary Variants Deletion

Introduction

Delete "Orphaned" Temporary Variants.

Recommendation

This task should be scheduled weekly.

Related Notes

16083

Reorganization of Print Parameters for Background Jobs

Introduction

It reorganizes print parameters cross-client. Since the number of print parameters increases more slowly than the number of background processing steps, you can execute this report after longer periods of time (longer than one month).

Recommendation

This task should be scheduled monthly.

Related Notes

16083

Reorganization of XMI Logs

Introduction

When you use external job scheduling tools, XMI log entries are written to the table TXMILOGRAW. The system may write a very large number of log entries, even if the audit level is set to 0. You must therefore reorganize the TXMILOGRAW table manually on a regular basis.

Recommendation

This task should be scheduled weekly.

Related Notes

16083
182963

SOAP Runtime Management

Introduction

This task does the SOAP runtime monitoring by scheduling other SAP standard programs:

SRT_REORG_LOG_TRACE
SRT_COLLECTOR_FOR_MONITORING
SRT_SEQ_DELETE_BGRFC_QUEUES
SRT_SEQ_DELETE_TERM_SEQUENCES
WSSE_TOKEN_CACHE_CLEANUP (Security Group)

Recommendation

This task should be scheduled hourly.

Delete History Entries for Processed XML Messages

Introduction

Historical data consists of a small amount of header information from deleted messages. This historical data is stored in a table and transferred to a second table on a weekly basis. Thus, data from the first table can be removed every week; but the history is still available in the second table for another month.

Recommendation

This task should be scheduled monthly.

Delete XML Messages from the Persistency Layer

Introduction

For the Integration Server/Engine of SAP XI, this periodical task is recommended.

Recommendation

This task should be scheduled daily.

Spool Data Consistency Check in Background

Introduction

The task enables continuous monitoring of inconsistent spool objects. The write locks are analyzed and, if necessary, deleted. All found inconsistent objects are gathered in a table. At the end of the test run, old and new tables are compared according to the following scheme:

The write locks found are deleted without being gathered in a table.
The functions "Delete write locks" and "Delete inconsistencies" can be used independently of each other but this is not recommended. For normal daily use, the limit values for both functions should be the same. At the moment no uses for differing limit values are known.

Recommendation

This task should be scheduled daily.

Related Notes

16083

Topic Business Warehouse is a group of housekeeping tasks, which are Business Warehouse-oriented.

PSA Cleanup

Introduction

PSA Cleanup is part of Business Warehouse deletion tasks.
The Persistent Staging Area (PSA) is the inbound storage area in BI for data from the source system. Requested data is saved unchanged from the source system.
Requested data is stored in the transfer structure format in transparent, relational database tables in BI.
If regular deletion doesn't take place, data from PSA tables can grow to an unlimited size. In applications, this can lead to poor system performance while from an administration point of view it can cause an increase in the use of resources. High volumes of data can also have a considerable effect on the total cost of the ownership of a system.
In OutBoard Housekeeping, it is possible to delete data from PSA tables using retention time.

Step list

In the main OutBoard Housekeeping menu select "PSA Cleanup – Settings" under the Business Warehouse/Deletion Tasks.
Now, the Settings selection must be specified. You can create new settings (1) by entering a new ID or choose from the existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation.

_{PSA Cleanup – Settings}

You can edit the created Settings Group (save the changes by clicking the Save Settings icon on the taskbar at the end of modifying).

1^stSpecify the DataSource Name(s) by clicking on the 'Add Object' Info button. From the list of available Data Sources (F4), you can select which are to be added into the newly created Settings Group & confirm. Also, the source system may be specified as an additional filter for DataSources. The Option to Include/Exclude determines if the result of a selection will be added or removed from a selection.
You can set the DataSource name in a pattern style and by checking "Do you want to save a pattern?" can skip selecting the PSA tables. This is useful ifyou create settings on the group level.

_{PSA Cleanup – DataSource selection}

After the confirmation, you should select PSA tables that are to be cleaned up and confirm the selected PSA tables to be added to the Settings Group list.

_{PSA Cleanup – PSA selection}

_{PSA Cleanup – Settings with patterns and objects}

Icons in the "X" column indicate how the lines will apply to the overall list of PSAs:

Pattern will be evaluated during the task execution and the PSAs will be added to the overall list
Pattern will be evaluated during the task execution and PSAs will be removed from the overall list
PSA will be added to the overall list
PSA will be removed from the overall list
If the pattern is added, by clicking on its technical name it is evaluated, and the list of PSAs is shown.

_{PSA Cleanup – List of PSAs included in the pattern}

2^nd By clicking on the 'Select requests' button,you can specify the Time period for deletion of relevant entries in selected PSA tables and exclude/include the requests with an error or archiving status from processing. From the OutBoard Housekeeping 2.54 version, there is an option that allows the direct deletion of PSA tables by skipping the RecycleBin use.
Note: You can specify different time criteria for every PSA table in the list, if no selection on the PSA table is done, the selected Time parameter will be set for all PSA tables in the list.

_{PSA Cleanup – Time period settings}

3^rd Run 'Test Run' for settings, it will build the overall list of PSAs, scan them, and identify all REQESTIDs, which fulfills the Time period condition. After 'Test Run' execution, the screen "Requests to be deleted" with the list of relevant REQUESTIDs, DataSources, and source systems are opened.

_{PSA Cleanup – Test run result}

Note: If thesettings are created on the group level, the'Test Run' button is unavailable and thus this step is skipped.

4^thThe next step is to set the Time limit for Recycle Bin. Enter the value in days in RecycleBin Period; use the input field or leave the default value, which is 14 days.
Note: Data stored in Recycle Bin is still available and can be possibly restored if necessary during the time period, which was defined during the setup. Once the time period expires, data stored in the Recycle bin will be automatically deleted by manual or scheduled execution of the system task "OutBoard Housekeeping RecycleBin Cleanup".

_{PSA Cleanup – RecycleBin Period}

5^thYou may define the maximum number of jobs that can be running in parallel by using the input field on the right side 'Max jobs'.
Note: If the parallelization parameter "Max. Jobs" is set to 0, execution of such settings will distribute the selection into particular execution chunks. However, the execution of these chunks will not be performed and the respective RunID will be paused.

_{PSA Cleanup – Parallelization – Max job}s

Once the settings for PSA Cleanup have been specified,you may run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.
You should specify the Settings ID when executing/ scheduling the activity.
To check the status of the run,you can go to the monitor or check the logs.

Recommendation

It is recommended to periodically delete:

• All incorrect requests
• All delta requests that have been updated successfully in an InfoProvider and no further deltas should be loaded for.

It helps to reduce the database disk space usage significantly. Our recommended retention time for PSA tables is 15 days and the task should run daily in common but it is application-specific.

ADSO ChangeLog Cleanup

Introduction

ChangeLog cleanup is part of the Business Warehouse deletion tasks.
TheChangeLog is a table /BIC/A*3 that is automatically created for Advanced DataStore Object (ADSO) created with options: Activate data and WriteChangeLog
TheChangeLog contains the change history for delta updating from the data source or InfoProvider to ADSO.
The data is put into theChangeLog via the activation queue and is written to the table for the active data upon the activation. During activation, the requests are sorted according to their logical keys. This ensures that the data is updated in the correct request sequence in the table for active data.
OutBoard™ for Housekeeping offers the possibility to delete data from ChangeLog tables using retention time.

Step list

In the main OutBoard Housekeeping menu select "ADSO ChangeLog Cleanup – Settings" under the Business Warehouse/Deletion Tasks.
The Settings-part of theChangeLog Cleanup allowsyou to specify the selection criterion of the Settings Group as well as the time window for data relevancy. Settings are changed by means of setting corresponding parameters.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation.

_{ADSO ChangeLog Cleanup – Settings Group selection}

You may edit the created Settings Group (save the changes by clicking the Save Settings icon on the taskbar at the end of modifying).

1^st You can specify the ADSO name(s) by clicking on the 'Add Object' Info button. From the list of available ADSOs (F4), you should select the objects to be added into the newly created Settings Group & confirm. Also, InfoArea can be specified as an additional filter for ADSOs. Options Include/Exclude determines if the result of the selection will be added or removed from this selection.
You can set the ADSO name in a pattern style, e.g. "ZADSO*" and by checking "Do you want to save a pattern?" can skip selecting ChangeLog tables. This is useful, should you create settings on a group level.
After the confirmation, you can select and confirm the ChangeLog tables that are to be cleaned up. The selected ChangeLog tables will be added to the Settings Group list.

_{ADSO ChangeLog Cleanup – ADSO selection}

_{ADSO ChangeLog Cleanup – change log selection}

_{ADSO ChangeLog Cleanup – Settings with patterns and objects}

Icons in the "X" column indicate how the lines will apply to the overall list of ChangeLogs:

Pattern will be evaluated during the task execution and theChangeLogs will be added to the overall list
Pattern will be evaluated during the task execution andChangeLogs will be removed from the overall list
ChangeLog will be added to the overall list
ChangeLog will be removed from the overall list

2^nd By clicking on the 'Select requests' button you can specify the Time period for deletion of relevant entries in selected ChangeLog tables.
Note: You may specify different time criteria for every ChangeLog table in the list, if no selection on the ChangeLog table is done, the selected Time parameter will be set for all ChangeLog tables in the list.

_{ChangeLog Cleanup – Time period settings}

3^rd Run 'Test Run' for selected ChangeLog tables. It will scan all ChangeLogs and it will identify all REQESTIDs for particular ChangeLog which fulfill the Time period condition. After 'Test Run' execution, a list of relevant REQUESTIDs, ADSO objects, and InfoArea is opened.

_{ADSO ChangeLog Cleanup – Test run result}

Note: Tocreate the settings on the landscape level, the'Test Run' button is unavailable and thus this step is skipped.

4^th The next step is to set the Time limit for Recycle Bin. Enter the value in days in the RecycleBin Period field or leave the default value, which is 14 days
Note: Data stored in Recycle Bin are available and can be possibly restored if necessary during the time period, which was defined during the setup. Once the time period expires, data stored in the Recycle bin will be automatically deleted by manual or scheduled execution of the system task "OutBoard Housekeeping RecycleBin Cleanup".

_{ChangeLog Cleanup – Recycle Bin Period}

Once the settings for ADSO ChangeLog Cleanup are specified,you can run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information,please refer to Execute and Schedule sections of this user documentation.
You should specify the Settings ID while executing/ scheduling the activity.
To check the status of the run,you can go to the monitor or check the logs.

Recommendation

It is recommended to periodically delete:

• Delta requests that have been updated successfully in an InfoProvider and no further deltas should be loaded for.

It helps to reduce the database disk space usage significantly. This task should be scheduled daily with a retention time of 15 days in a row but it is application-specific.

ChangeLog Cleanup

Introduction

ChangeLog cleanup is part of the Business Warehouse deletion tasks.
TheChangeLog is a table of the PSA that is automatically created for each standard DataStore Object (DSO). Further, for each standard DataStore Object, an export DataSource will be created that serves as a data source for the transfer of data from the ChangeLog to other data targets.
The ChangeLog contains the change history for delta updating from the ODS Object into other data targets, for example, ODS Objects or InfoCubes.
The data are put into theChangeLog via the activation queue and are written to the table for active data. During activation, the requests are sorted according to their logical keys. This ensures that the data are updated in the correct request sequence in the table for active data.
OutBoard Housekeeping is able to delete data from the ChangeLog tables using retention time.

Step list

In the main OutBoard Housekeeping menu select "ChangeLog Cleanup – Settings" under the Business Warehouse/Deletion Tasks.
The Settings-part of the ChangeLog Cleanup allowsyou to specify the selection criterion of the Settings Group as well as the time window for data relevancy. Settings are changed by means of setting corresponding parameters.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation.

_{ChangeLog Cleanup – Settings Group selection}

You may edit the created Settings Group (save the changes by clicking the Save Settings icon on the taskbar at the end of modifying).

1^st You can specify the DataStore name(s) by clicking on the 'Add Object' Info button. From the list of available DataStores (F4), you should select the objects to be added into the newly created Settings Group & confirm. Also, InfoArea can be specified as an additional filter for DataStores. Options Include/Exclude determines if the result of the selection will be added or removed from this selection.
You can set DataStore name in a pattern style, e.g. "ZDSO*" and by checking "Do you want to save a pattern?" can skip selecting ChangeLog tables. This is useful, should you create settings on a group level.
After the confirmation, you can select and confirm the ChangeLog tables that are to be cleaned up. The selected ChangeLog tables will be added to the Settings Group list.

_{ChangeLog Cleanup – DataStore selection}

_{ChangeLog Cleanup – change log selection}

_{ChangeLog Cleanup – Settings with patterns and objects}

Icons in the "X" column indicate how the lines will apply to the overall list of ChangeLogs:

Pattern will be evaluated during the task execution and the ChangeLogs will be added to the overall list
Pattern will be evaluated during the task execution andChangeLogs will be removed from the overall list
ChangeLog will be added to the overall list
ChangeLog will be removed from the overall list

If the pattern is added, by clicking on its technical name, it is evaluated and the list ofChangeLogs is shown.

_{ChangeLog Cleanup – List of change logs included in the pattern}

2^nd By clicking on the 'Select requests' button you can specify the Time period for deletion of relevant entries in selected ChangeLog tables and exclude/include the requests with an error or archived status from processing. From the OutBoard Housekeeping 2.54 version, there is an option that allows direct deletion of ChangeLog tables by skipping RecycleBin use.
Note: You may specify different time criteria for every ChangeLog table in the list, if no selection on the ChangeLog table is done, the selected Time parameter will be set for all ChangeLog tables in the list.

_{ChangeLog Cleanup – Time period settings}

3^rd Run 'Test Run' for selected ChangeLog tables. It will scan all ChangeLogs and it will identify all REQESTIDs for particular ChangeLog which fulfill the Time period condition. After 'Test Run' execution, a list of relevant REQUESTIDs, DataStore objects, and InfoArea is opened.

_{ChangeLog Cleanup – Test run result}

Note: Tocreate the settings on the landscape level, the'Test Run' button is unavailable and thus this step is skipped.

4^th The next step is to set the Time limit for Recycle Bin. Enter the value in days in the RecycleBin Period field or leave the default value, which is 14 days.
Note: Data stored in Recycle Bin are available and can be possibly restored if necessary during the time period, which was defined during the setup. Once the time period expires, data stored in the Recycle bin will be automatically deleted by manual or scheduled execution of the system task "OutBoard Housekeeping RecycleBin Cleanup".

_{ChangeLog Cleanup – Recycle Bin Period}

5^thYou may define the maximum number of jobs that can be running in parallel by using the input field on the right side 'Max jobs'.
Note:If the parallelization parameter "Max. Jobs" is set to 0, the execution of such settings will distribute the selection into particular execution chunks. However, the execution of these chunks will not be performed and the respective RunID will be paused.

_{ChangeLog Cleanup – Parallelization – Max Jobs}

Once the settings for ChangeLog Cleanup are specified,you can run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information,please refer to Execute and Schedule sections of this user documentation.
You should specify the Settings ID while executing/ scheduling the activity.
To check the status of the run,you can go to the monitor or check the logs.

Recommendation

It is recommended to periodically delete:

• Incorrect requests
• Delta requests that have been updated successfully in an InfoProvider and no further deltas should be loaded for.

It helps to reduce the database disk space usage significantly. This task should be scheduled daily with a retention time of 15 days in a row but it is application-specific.

Cube Compression Analysis

Introduction

Dimension tables size significantly affects the performance on the database level (table joins, query performance). This analysis checks two important values for each dimension table:

• Row count – count of rows in the table.
• Ratio – it is calculated as a division of Dimension table rows to Fact table rows.

The ratio acceptable for dimension tables is up to 10% (in order to avoid false alarm, the cube must have more than 30 000 rows).

Steplist

In the main OutBoard Housekeeping menu select "Cube Compression Analysis – Settings" under the Business Warehouse/Deletion Tasks.
Here, the Settings selection must be specified. You can create new settings (1) by entering a new ID 1 or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
Should you create new settings, the "Description" field needs to be filled. In "Selection thresholds", you can fill "Min. rows" field to check only the tables with rows count greater than the minimum. "Min. density (%)" will search for the tables with a ratio greater than selected.

_{Cubes Compression Analysis – Settings detail}

If "Create settings for Task Cube compression based on selection" is checked, a consistency check will prepare the settings for "Cube Compression" task and the settings ID can be found in the consistency check logs under – "Problem class Important".
Click on the info button "Save settings" to save the selection. For any further updates, click on "Modify Settings" info button and confirm.
Once the settings for Cube compression analysis are specified,you can run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.
You should specify the Settings ID while executing/ scheduling the activity.
To check the status of the run,you can go to the monitor or check the logs.

Recommendation

As data volume grows, this task should be run regularly.

Related Notes

1461926

Cube Compression

Introduction

Cube compression is part of Business Warehouse deletion tasks.
Data loaded in the InfoCube is identified with the request IDs associated with them. However, the request ID concept can also cause the same data records to appear more than once in the F fact table. This unnecessarily increases the volume of data and reduces the performance in reporting as the system has to aggregate using request IDs every time the query is executed. The compression of the InfoCube eliminates these disadvantages and brings data from different requests together into one single request. Compression means in this case to roll-up the data so that each data set is only contained once and therefore deleting the request information.
The compression improves the performance as it removes the redundant data. The compression also reduces memory consumption due to the following: Deletes request IDs associated with the data. It reduces the redundancy by grouping by on dimension & aggregating on cumulative key figures.
The compression reduces the number of rows in the F fact table because when the requests are compressed, all data moves from the F fact table to the E fact table. It results in an accelerated loading into the F fact table, faster updating of the F fact table indexes, shorter index rebuilding time, the accelerated rollups (since the F fact table is the source of data for roll-up).
OutBoard Housekeeping is able to compress the cubes using retention time.

Step list

In the main OutBoard Housekeeping menu select "Cube Compression – Settings" under the Business Warehouse/Deletion Tasks.
Settings-part of the OutBoard Housekeeping allowsyou to specify the selection criterion of the Settings Group as well as the time window for data relevancy. Settings are changed by means of setting a corresponding parameter. Parameters are usually different for each system and therefore are not meant to be transported, but are set on each system separately.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.

_{Cube Compression – Settings Group selection}

You can edit the created Settings Group (by clicking the Save Settings icon on the taskbar at the end of modifying, the changes are saved).

You can click on 'Add Object' and select the InfoCube(s) that are to be compressed; once selected, press confirm.

_{Cube Compression – Settings Group selection}

Icons in the "X" column indicate how the lines apply to the overall list of InfoCubes:

Pattern is evaluated during the task execution and the InfoCubes is added to the overall list
Pattern is evaluated during the task execution and InfoCubes is removed from the overall list
InfoCube is added to the overall list
InfoCube is removed from the overall list

If the pattern is added, by clicking on its technical name it is evaluated, and the list of InfoCubes is shown.
As an alternative to manual selection, settings generated by Cube Compression Analysis can be used.
Once the InfoCube(s) is (are) selected, you should specify settings in the Request selection. Here the selection is according to which RequestIDs for InfoCube compression is identified for every InfoCube within the list. Filtering restricts criteria based on the request timestamp "older than xxx days" and on the number of requests to be kept uncompressed. For request limitation, it is possible to enter the values in the following way:

1. Number of unprocessed requests to Process data records older than XXX days
2. Both limitations
3. No limitations: In this case, all requests will be compressed

Also, you can select the option "Zero elimination" after cube compression (see more in the "Zero Elimination after Compression" task).

_{Cube Compression – Time period settings}

For Oracle databases, there is a possibility to check for DIMID duplicates during the execution. This elementary test recognizes whether there are several lines that have different DIMIDs (dimension table key), but have the same SIDs for the selected dimension table for the InfoCube specified. (This can occur by using parallel loading jobs). This has nothing to do with inconsistency. However, unnecessary storage space is occupied in the database.
Since the different DIMIDs with the same SIDs are normally used in the fact tables, they cannot simply be deleted. Therefore, all of the different DIMIDS in the fact tables are replaced by one DIMID that is randomly selected from the equivalent ones.
DIMIDs that have become unnecessary are deleted in the connection. In doing so, not only are the DIMDs deleted that were released in the first part of the repair but so are all of those that are no longer used in the fact tables (including aggregates).
If this option is chosen for any database other than an Oracle Database, it will be ignored during execution.

When InfoCube contains indexes that can slow down the cube compression, you can choose whether before compression itself, the index should be dropped and after compression is done, it is repaired. You can turn on this functionality for DB Indexes or Aggregate Indexes.

You can display identified RequestIDs by clicking on "Test Run".

_{Cube Compression – Test run result}

Note: When creating settings on the group level, the'Test Run' button is unavailable and thus this step is skipped.
As the last step,you can define the maximum number of jobs that can be running in parallel by using the input field on the right side 'Max jobs'.
Note:If the parallelization parameter "Max. Jobs" is set to 0, execution of such settings will distribute the selection into particular execution chunks, but the execution of these chunks will not be performed and respective RunID will be paused.

_{Cube Compression – Parallelization Max jobs}

Once the settings for the InfoCube Compression have been specified,you can run the created/modified Settings group from the Main menu. There are several options on how to start the InfoCube Compression. For more information, please refer to Execute and Schedule sections of this user documentation.
You should specify the Settings ID when executing/ scheduling the activity.
To check the status of the run, you can go to the monitor or check the logs.

Recommendation

Our recommendation is to compress as soon as possible any requests for InfoCubes that are not likely to be deleted; this also applies to the compression of the aggregates. The InfoCube content is likely to be reduced in size so DB time of queries should improve.

Warning

Be careful – after compression, the individual requests cannot be accessed or deleted. Therefore, you should be absolutely certain that the data loaded into the InfoCube is correct.

Cube DB Statistics Rebuild

Note: Task 'Cube DB Statistics rebuild' is obsolete, we recommend 'DB statistics rebuild' instead.

Introduction

The database statistics are used in the system to optimize query performance. For this reason, database statistics should be up-to-date. SAP recommends that the statistics should be updated always in case more than a million new records were loaded into the InfoCube, since the last update.
The database statistics can be automatically recalculated after each load or after each delta upload. To avoid unnecessary recalculations, first, the OutBoard Housekeeping task determines whether the recalculation is needed, and only afterward the statistics are rebuilt. The relevant InfoCubes for statistics update can be listed also using the 'Test run' in the settings definition.
The percentage of the InfoCube data that is used to create the statistics is set to 10% by default by SAP. The larger the InfoCube, the smaller percentage should be chosen, since the demand on the system for creating the statistics increases with the change in size. Cube DB Statistics Rebuild task is using the percentage as it is set up by each InfoCube.

Recommendation

Our recommendation is to run this task regularly, as it will update the statistics only for InfoCubes when needed. It will avoid unnecessary statistics updates, but on the other hand, it will keep the statistics up-to-date.
Note: While Statistics Are Being Built, It is not possible to:
• Delete indexes
• Build indexes
• Fill aggregates
• Roll up requests in aggregates
• Compress requests
• Archive data
• Update requests to other InfoProviders
• Perform change runs.

BI Background Processes

Introduction

The BW environment performs a lot of processes all the time and some may not always be processed in a visible way. Sometimes this happens in the background in series or in parallel processes.
Background Management provides functions for managing these background processes and the parallel processes in the BW system. As a result of its regular activities, messages, and the internal parameters of the background processes executed by the background management are created in the RSBATCHDATA table. In the case of no housekeeping, the RSBATCHDATA table may grow out of control.
In OutBoard Housekeeping, it is possible to delete these messages and the internal parameters using retention time.

Step list

In the main OutBoard Housekeeping menu select "BI Background Processes – Settings" under the Basis/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
Settings part of BI Background Processes allowsyou to specify the selection criterion of the Settings Group.
Now, the Settings selection must be specified:

• Delete Messages by – for the internal messages of BI background management, this defines after how many days these should be deleted.
• Delete Parameters by – for the internal parameters of the background processes, this defines after how many days these should be deleted.
• Fill the "Description" field with a description comment and click on "Save Settings" button.

Note:SAP recommends deleting messages and parameters older than 30 days. This setting should normally prevent table RSBATCHDATA from being overfilled. When defining the deletion selections, make sure to keep the data as long as necessary in order to track any problems that might occur.
To save the settings, click the "Save Settings" button. If you make an update on an already existing settings group, you may save the settings using the "Modify Settings" button. Or delete the complete settings group with the "Delete Settings" info button.
To run this task in a Test mode, check the test mode checkbox, to display available deletion results in logs.

_{BI Background Processes – Settings detail}

Once the settings are specified, you can run the created/modified Settings Group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.
You should specify the Settings ID when executing/ scheduling the activity.
To check the status of the run, you can go to the monitor or check the logs.

Recommendation

Our recommendation is to delete the messages and the parameters stored in the RSBATCHDATA table that are older than 30 days and to run this job on a daily basis.

Warning

You should only delete the messages and the parameters that will no longer be needed. After this report is executed, the logs will be temporarily stored in the recycle bin and eventually deleted.

BW Statistics Deletion

Introduction

BW statistics are part of Business Warehouse deletion tasks.
To evaluate the fundamental functional areas of the Business Information Warehouse, the system stores BW Statistics in the following tables:

• RSDDSTATAGGR
• RSDDSTATAGGRDEF
• RSDDSTATBIAUSE
• RSDDSTATCOND
• RSDDSTATDELE
• RSDDSTATDM
• RSDDSTATDTP
• RSDDSTATEVDATA
• RSDDSTATHEADER
• RSDDSTATINFO
• RSDDSTATLOGGING
• RSDDSTATPPLINK
• RSDDSTATTREX
• ESDDSTATTREXSERV.

After a certain period of time, the statistics are not used, therefore not needed anymore. They can be deleted to reduce data volume and increase performance when accessing these tables.
With OutBoard Housekeeping, it is possible to delete these BW Statistics using retention time.

Step list

In the main OutBoard Housekeeping menu select "BW Statistics – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled and selected whether or not the settings ID will be run in a test mode.
You may also restrict the deletion of BW statistics based on source objects:

• Query
• Logs
• Aggregates
• Data Transfer Process
• Data on Deletion

You need to click on the "Save settings" button to save the selection, for any further updates, click on "Modify Settings" info button and confirm.

_{BW Statistics – Settings detail}

Once the settings for BW Statistics cleaning are specified, you can run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.

Recommendation

Our recommendation is to delete BW Statistics older than 60 days.

Warning

Analyze the usage of BW Statistics in the system before deleting them, because OutBoard Housekeeping deletes the BW statistics permanently.

Bookmark Cleanup

Introduction

Bookmarks are useful if you want to return to a particular navigational status (that includes the level to which some hierarchy has been expanded) of a Web application or an ad-hoc query that was created using the Web. You can set a bookmark to enable a recall to a particular navigational status at a later date because the system creates and stores a URL for the bookmark.
In OutBoard Housekeeping, it is possible to clean up these bookmarks based on internal parameters using retention time.
In the main OutBoard Housekeeping menu select "Bookmark Cleanup – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.

_{Bookmark Cleanup – Settings detail}

You can restrict the cleanup of bookmarks based on:

• Selection Parameters
  • Date created/ last accessed
  • User Name
  • Template
• Bookmark State (All/ Stateful/ Stateless)
• Bookmark Type (All/without/with Data)

To run this task in a Test mode, check the test mode checkbox, to display available cleanup results in logs.
Once the settings for the Bookmark Cleanup are specified, you may run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.

Web Template Cleanup

Introduction

A Web template determines the structure of a Web application. Web Application Designer is used to insert placeholders into the HTML document for Web Items (in the form of object tags), data providers (in the form of object tags), and BW URLs. The HTML document with the BW-specific placeholders is called a Web template. Web templates are checked into the Web Application Designer. The HTML page that is displayed in the Internet browser is called a Web application. Depending on which Web items were inserted into the Web template, a Web application contains one or more tables, an alert monitor, charts, maps, and so on.
The Web template is the keystone of a Web report. It contains placeholders for items and commands URLs. Data providers, items, and command URLs are generated for Web reports.
In OutBoard Housekeeping, it is possible to clean up the Web Templates based on internal parameters and use retention time.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.
In settings, the field 'Last used' represents the number of days that have passed since the template was last used and the field 'Created before' represents the number of days passed since the template was first created.

_{Web Template Cleanup – Settings detail}

You can restrict the cleanup web templates based on the following parameters:

• Created before (days)
• Last used (days)
• User Name
• Template (Tech Name)

It is possible to run this task in Test mode. Mark this option to display available cleanup results in logs.
Once the settings for the Web Template Cleanup are specified, you may run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information, please refer toExecute and Schedule sections of this user documentation.

Precalculated Web Template Cleanup

Introduction

A Precalculated web template isa complete document that doesn't require a database connection, essentially they areweb templates filled with data.After filling the web template with the data, this can be distributed and used withoutexecuting an OLAP request. As these templates are filled with data, they require more space than the traditionalWeb Template as these templates are filled multiple times with data.
In OutBoard Housekeeping, it is possible to clean up these bookmarks based on internal parameters using retention time.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.

_{Precalculated Web Template – Settings detail}

You can restrict the cleanup Precalculated Web Templates based on the following parameters:

• Older than (Creation Date)
• User Name
• Template (Tech Name)

It is possible to run this task in a Test mode. Mark this option to display available cleanup results in logs.
Once settings for the Precalculated Web Template Cleanup are specified, you may run the created/modified Settings group from the Main menu. There are several options on how to start the deletion. For more information,please refer toExecute and Schedule sections of this user documentation.

Extended Query Statistics Cleanup

Introduction

Datavard (DVD) Extended Query Statistics is information that is collected on top of standard OLAP statistics.
These statistics are collected when DVD Extended Query Statistics enhancement is installed in the system and collecting is turned on. Extended statistics store information about filters that were used for each query/navigational step execution and create source information for use in other DVD analysis products. If these are not deleted manually, their growth in size is unlimited. Two tables /DVD/QS_QINFO and /DVD/QS_QVAR are filled when a query is executed in the system. The speed of growth depends on overall query usage and the number of filters used on average. In productive systems, it is not uncommon that the total size of these tables can grow 0.5 GB per week.
In OutBoard Housekeeping it is possible to clean up the Extended Query Statistics based on internal parameters.

Recommendation

Periodical deletion of Extended Query Statistics should reduce database disk space usage significantly. Our recommendation is to delete all statistics that are no longer needed for analysis in other DVD products.
For example, Heatmap query usage analysis should be done once a month and after this analysis, all statistics of that month should be cleaned if there is no other planned analysis for a bigger time frame.

Step list

In the main OutBoard Housekeeping menu select "Extended Query Statistics Cleanup – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.
You then need to fill in optional parameters:

• ID – generated unique statistic ID
• Query datum – datum of query execution
• Query ID – report specific ID
• User – username of the query creator

It is possible to run this task in a Test mode. Mark this option to display available cleanup results in logs.

_{Extended Query Statistics Cleanup – Settings detail}

Warning

If no parameters are specified, all queries will be deleted.

Unused Dimension Entries of an InfoCube Cleanup

Introduction

During the deletion of data from InfoCubes, it is possible that this data in their respective dimension tables of InfoCubes are retained for future processing. This data can occupy valuable space in the database and is easily forgotten, as it is no longer visible in the InfoCube. Task Unused Dimension Entries of an InfoCube Cleanup deals with this retained data if it is no longer needed.

Step list

In the main OutBoard Housekeeping menu, select "Cube Compression – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
You can then specify InfoCubes and InfoCube patterns that will be used in the execution of the task.

_{Unused Dimension Entries of an InfoCube – Settings Group selection}

In the 'Add object' submenu, you can specify individual InfoCubes or patterns that are to be processed during the execution.

_{Unused Dimension Entries of an InfoCube – InfoCube(s) specification}

A test run is available for this task, which gives an overview of unused dimension entries.

_{Unused Dimension Entries of an InfoCube – Test run results}

Warning
Test run results and task logs follow standard SAP logging logic for this task. So the first five unused entries of a dimension are displayed followed by a summary for each dimension if there are more than five unused entries. If there are five or fewer unused entries in a dimension, no summary is displayed and the information about unused entries of the next dimension follows.

_{Unused Dimension Entries of an InfoCube – Example of summary in results}

Query Objects Deletion

Introduction

Transaction RSZDELETE is intended for mass deletion of queries and reusable query components (structures, filters, calculated, or restricted key figures and variables) from the system.
As of OutBoard Housekeeping release 2.35, this functionality is enhanced with RecycleBin support. This allows storing deleted queries and query components in RecycleBin for specified retention time.

Step list

In the main OutBoard Housekeeping menu select "Query Objects Deletion – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
Settings part of Query Objects Deletion allows you to specify the selection criterion of the Settings Group.

_{Query Objects Deletion – Settings detail}

Workbook and Role Storage Cleanup

Introduction

There may be workbooks where there is no longer a reference in a role or in the favorites. Similarly, references to non-existing workbooks may exist in roles or favorites.
In the SAP Easy Access menu or in the role maintenance, the references to workbooks are deleted without a check performed to see whether it may be the last reference. In these cases, the workbook is also deleted in the document storage in the BEx Analyzer or BEx Browser.
This task enables the deletion of references to workbooks in roles and favorites whose workbooks do not exist in the document storage. The task also allowsyou to delete workbooks for which no references exist in roles or favorites in the document storage.
As of OutBoard Housekeeping release 2.35, this functionality is enhanced with RecycleBin support. This allows storing deleted references in RecycleBin for specified retention time.

Step list

In the main OutBoard Housekeeping menu select "Query Objects Deletion – Settings" under the Business Warehouse/Deletion Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.
The settings part of Query Objects Deletion allows you to specify the selection criterion of the Settings Group.

_{Workbooks and Role Storage Cleanup – Settings detail}

It is possible to run this task in a Test mode (checked by default) and it will write the analysis results into task logs.

Workbook Cleanup

Introduction

BEx Analyzer is an analytical, reporting, and design tool embedded in Microsoft Excel. Workbooks that are created with this tool can be saved to multiple locations, e.g. SAP NetWeaver server. Workbooks are saved as binary files in the database system and can consume a lot of space. Especially if multiple workbooks are being created for the same purpose i.e. every month and are not used after that.

In OutBoard™ for Housekeeping, it is possible to delete unused workbooks from the system using retention time and OLAP statistics.

Step list

In the main OutBoard Housekeeping menu, select “Workbook Cleanup” under the Business Warehouse/Deletion Tasks.

You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation.

In the settings part of the Workbook Cleanup, you can specify the selection criterion of the Workbook to be cleaned up. It is possible to run this task in a Test mode (checked by default) and it will write the analysis results into task logs.
You need to fill in these parameters:

• Workbook ID
• Person Responsible
• Type of Workbook
• Location of Data Storage
• Last usage (in days)
• Delete all with no statistics checkbox – excludes statistics and deletes all the bookmarks according to selection parameters
• Retention time in days – the amount of time for the cleaned bookmark to be kept in the recycle bin
• Verbose logs checkbox – enhances logs with additional information about each Bookmark processing

Recommendation

Our recommendation is to delete unused workbooks on a regular basis. Note that it is crucial to collect OLAP statistics for workbooks, otherwise the deletion program is unable to identify workbooks that are unused. Statistics for workbooks can be set in the transaction RSDDSTAT.

Warning

When OLAP statistics are not collected, the deletion program by default excludes such workbooks from deletion. Be careful when you chose the settings option 'Delete all with no statistics', it will delete all workbooks that do not have any OLAP statistics for the given selection. If you decide to use this option, always use the recycle bin (set 'Retention time in days' > 0). You can then easily reload possibly missing workbooks.

BusinessObjects: Office Cleanup

Introduction

SAP BusinessObjects Analysis is an analytical, reporting, and design tool embedded in Microsoft Excel. Workbooks that are created with this tool can be saved to multiple locations. One of such locations is the SAP NetWeaver server. Workbooks are saved as binary files in the database system and can consume a lot of space. Especially when multiple workbooks are being created for the same purpose i.e. every month and are not used after that.

In OutBoard™ for Housekeeping, it is possible to delete unused workbooks from the system using creation time.

Recommendation

Our recommendation is to delete unused workbooks on regular basis with the usage of the recycle bin.

Warning

The task is using for the deletion creation of the time stamp. This means the object could be used recently but unfortunately, the header table doesn't contain this information. You should always use a recycle bin (set 'Retention time in days' > 0). You can then easily reload possibly missing objects.

Tables Buffering on Application Server

Introduction

Table buffering on the Application Server is part of Business Warehouse buffering tasks.
Buffering on the application server is to avoid accessing the database server too often. In the case of too many sequential reads and a small percentage of invalidations (buffer refreshes), the buffering will increase the performance when accessing the tables.
OutBoard Housekeeping offers the possibility to evaluate the table buffering settings in the test mode. The result is a list of tables to be buffered according to current settings.

Step list

In the main OutBoard Housekeeping menu, select "Tables Buffering on Application Server – Settings" under the Business Warehouse/Buffering Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information,please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.
You may choose to set the threshold parameters for the tables to be buffered:

• Max. Table size
• Max. Sequential reads
• Max. Invalidation (in percent)

These parameters can be applied for previous or this month's statistics.
Click on the info button "Save settings" to save the selection.

_{Tables Buffering on App. Server – Settings detail}

Once the settings for Tables buffering cleaning are specified, you can run the created/modified Settings group from the Main menu. There are several options on how to start the buffering, for more information, please refer toExecute and Schedule sections of this user documentation.

Recommendation

Our recommendation is to buffer the tables on the application server according to the results of the test run of this analysis.

Warning

Continue to analyze the usage and invalidations of buffer on a regular basis (monthly).

Number Range Buffering

Introduction

Number Range Buffering is part of Business Warehouse buffering tasks.
During the Master Data Load, each record will go to the database table NRIV and will pick a new SID number. Similarly, also during the Info Cube data loading each record will go to database table NRIV and gets the new DIMID. In the case of a huge amount of data, the performance of loading will be decreased because all the records will go to the database table to get new either the SID or DIMID numbers. In order to rectify this problem, we need to use buffered numbers rather than hitting the database every time.
OutBoard Housekeeping offers the possibility to buffer required SID and DIMID range objects with the defined buffering value.

Step list

In the main OutBoard Housekeeping menu select "Number Range Buffering – Settings" under the Business Warehouse/Buffering Tasks.
Settings part of Number Range Buffering allowsyou to specify the selection criterion of the Settings Group. You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled and selected whether or not the settings ID will be run in a Test mode.

_{Number Range Buffering – Settings detail}

Number Range Buffering supports three different activities:

1. Buffering NR object
2. Unbuffering NR object
3. Unbuffering NR for package dimension

Select option in the task Number range buffering was based (OutBoard Housekeeping release older than 2.61) on the number range object number for SID and DIMID. Due to the fact that these numbers are different throughout the landscape, the select options are now based on InfoObject name (NR for InfoObject) and Cube dimensions (NR for InfoCube).
In the NR object buffering, specify selection conditions for SID NR object, NR for InfoObject or DIMID NR object, and NR for InfoCube. If necessary, specify the buffer level, too. In the NR object unbuffering specify selection conditions for the NR object to be unbuffered, if necessary.
You need to click on the button "Save settings" to save selection, for any further updates click on "Modify Settings" info button and confirm.
Once the settings for Number range buffering cleaning are specified, you can run the created/modified Settings group from the Main menu. There are several options on how to start buffering. For more information, please refer to Execute and Schedule sections of this user documentation.

Recommendation

Our recommendation is to buffer all SID and DIMID number range objects with the buffering value of 10.

Warning

The number range object of characteristic 0REQUEST should never be buffered. Therefore, it is always filtered out by default. The number range object of the Package Dimensions should never be buffered. Therefore, these are always filtered out by default.

Related Notes

1948106
857998

Archiving of Request Administration Data

Introduction

The administration tables and log tables of the DTP/ InfoPackage increase with each new request. This in turn affects the performance.
The log and administration data for requests can be archived. This results in improved performance of the load monitor and the monitor for load processes. It also allows for freeing up tablespace on the database.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept, by using SARA transaction and WRITE action. The archiving object BWREQARCH contains information about which database tables are used for archiving. In runtime, the report RSREQARCH_WRITE is executed.

Step list

In the main OutBoard Housekeeping menu select "Archiving of Request Administration Data – Settings" under the Business Warehouse/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks are. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen, you can set the criteria for the requests to be archived.

_{Archiving of Request Administration Data – Settings detail}

There are several options on how to start the Archiving of Request Administration Data. For more information, please refer toExecute and Schedule sections of this user documentation.

Recommendation

To avoid unnecessary reloading of data from the archive, we recommend that you should only archive administration data from requests that are more than three months old and will probably not be edited again.

Warning

1. After an upgrade from SAP BW 2.x or 3.x to SAP NetWeaver 7.x, the reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA are to be executed at least once for all objects. We recommend the execution of the report in the background.
2. Because of different selection screens on various BW releases, it is not possible to utilize an inheritance of settings and execution. It is highly recommended to prepare specific settings ID for each landscape node.

Archiving of BI Authorization Protocols

Introduction

The table RSCELOG is used as a storage for Authorizations Log files. These are created when the authorization protocol is switched on in RSECPROT. This in turn can affect the performance.
Authorizations Log files can be archived. This results in improved performance of the load monitor and the monitor for load processes. It also allows you to free up the tablespace on the database.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept by using the SARA transaction and WRITE action. The archiving object RSECPROT contains information about which database tables are used for archiving. In runtime, the report RSECPROT_ARCH_WRITE is executed.

Step list

In the main OutBoard Housekeeping menu select "Archiving of BI Authorization Protocols – Settings" under the Business Warehouse/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen, you can set the criteria for the logs to be archived.

For more detailed information, see the contextual help.

_{Archiving of BI Authorization Protocols – Settings detail}

There are several options on how to start the Archiving of BI Authorization Protocols. For more information, please refer to Execute and Schedule sections of this user documentation.

Recommendation

We recommend archiving and delete BI Authorization protocols, when:

• Write step is canceled with EXPORT_TOO_MUCH_DATA dump when writing to the authorization log;
• RSECLOG table is becoming quite large;
• Authorization logs are not required anymore;
• BW reports have been suffering suddenly and abnormal delays;
• Traces showed table RSECLOG as the most accessed table.

Related Notes

1592528

Archiving of BI Authorization Change Logs

Introduction

As of BW 7.30, it is possible to archive the ChangeLog of analysis authorizations using the archiving object RSEC_CHLOG.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept by using the SARA transaction and WRITE action. The archiving object RSEC_CHLOG contains information about which database tables are used for archiving. In runtime, the report RSEC_CHLOG_ARCH_WRITE is executed.

Step list

In the main OutBoard Housekeeping menu select "Archiving of BI Authorization Change Logs – Settings" under the Business Warehouse/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen, you can set the criteria for the requests to be archived.

For more detailed information, see the contextual help.

_{Archiving of BI Authorization Change Logs – Settings detail}

There are several options on how to start the Archiving of BI Authorization Change Logs. For more information, please refer toExecute and Schedule sections of this user documentation.

Recommendation

We recommend archiving the data before making a system copy, as this involves a large amount of data that is not actually needed in the new system.

Warning

This task works on BW 7.30 systems and higher. It means central and satellite systems must meet these requirements. In case the central system doesn't meet these requirements, it is not possible to create the settings variant. In the case, satellite systems do not meet the requirements, report RSEC_CHLOG_ARCH_WRITE is not found and is not executed.

Archiving of Point-of-Sale Aggregates

Introduction

While using the POS solution, a large amount of data can be generated and this increases the data volume rapidly. The data of POS transactions can be summarized using aggregates, which reduce the size of data significantly. However, regular archiving of this data is very important.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept by using the SARA transaction and WRITE action. The archiving object /POSDW/AGG contains information about which database tables are used for archiving. In runtime, the report /POSDW/ARCHIVE_WRITE_AGGREGATE is executed.

Step list

In the main OutBoard Housekeeping menu select "Archiving of Point-of-Sale Aggregates – Settings" under the Business Warehouse/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information,please refer to the Creating a Settings ID section of this user documentation.
In the variant screen, you can set the criteria for the requests to be archived.

For more detailed information, see the contextual help.

_{Archiving of Point-of-Sale Aggregates – Settings detail}

There are several options to start the Archiving for Point-of-Sale Aggregates. For more information, please refer to Execute and Schedule sections of this user documentation.

Prerequisites

Prior to the processing of the POS aggregates archiving, all POS transactions for the selected Store/Date combination must have one of the following statuses: Completed, Rejected, or Canceled. It is also assumed that these data are no longer required to be available for SAP POS DM.

Recommendations

We recommend running POS aggregates archiving regularly. The frequency of archiving is system-specific.

Warning

This task works on systems where the SAP Point of Sale solution is installed. It means central and satellite systems must meet these requirements. In case the central system doesn't meet these requirements, it is not possible to create a settings variant. In the case satellite systems do not meet the requirements, report /POSDW/ARCHIVE_WRITE_AGGREGATE is not found and is not executed.

Archiving of Point-of-Sale Transactions

Introduction

While using the POS solution, a large amount of data can be generated that increases the data volume rapidly. Regular archiving of this data is very important.
This OutBoard Housekeeping task encapsulates the SAP NetWeaver data archiving concept by using the SARA transaction and WRITE action. The archiving object /POSDW/TL contains information about which database tables are used for archiving. In runtime, the report /POSDW/ARCHIVE_WRITE is executed.

Step list

In the main OutBoard Housekeeping menu select "Archiving of Point-of-Sale Transactions – Settings" under the Business Warehouse/Archiving Tasks.
The settings are maintained the same way as standard SAP housekeeping tasks. For more information, please refer to the Creating a Settings ID section of this user documentation.
In the variant screen,you can set the criteria for the requests to be archived.

For more detailed information, see the contextual help.

_{Archiving of Point-of-Sale Transactions – Settings detail}

There are several options on how to start the Archiving of Point-of-Sale Transactions. For more information, please refer toExecute and Schedule sections of this user documentation.

Prerequisites

Prior to processing the POS transactions archiving, all POS transactions for the selected Store/Date combination must have one of the following statuses: Completed, Rejected, or Canceled. It is also assumed that this data is no longer required to be available for SAP POS DM.

Recommendations

We recommend running POS transactions archiving regularly. The frequency of archiving is system-specific.

Note

If you are using SAP POS DM implemented on BW powered by HANA, do not use this archiving object /POSDW/TL. Use /POSDW/TLF instead.

Warning

This task works on systems where the SAP Point of Sale solution is installed. It means central and satellite systems must meet these requirements. In case the central system doesn't meet these requirements, it is not possible to create a settings variant. In the case that satellite systems do not meet the requirements, report /POSDW/ARCHIVE_WRITE is not found and is not executed.

Enablement for archiving request admin. data for ADSOs

Introduction

Requests generated with BW 740 have a TSN and a SID if an ADSO was the target of the request.

These requests have also been updated to the tables RSBMONMESS_DTP, RSDMREQ_DTP, and RSBLOGPAR_DTP and not to the new RSPM tables for logging.

However, the requests cannot be archived with BWREQARCH, since they do not generate an entry in RSREQDONE.

The newly delivered report RSREQARCH_SIDTSNREQ_REQDONE generates these RSREQDONE entries, which have the sole purpose of enabling the archiving of the requests with transaction SARA.

Notes

2708933 - P22; DTP; REQARCH; RSPM; TSN: Archiving requests with SID and TSN

Temporary Database Objects Removing

Introduction

In SAP BW, there are dynamically created temporary database objects (such as tables or views). They are created during query execution or other processes that read data from BW InfoProviders.
With BI 7.x these objects are always created in the ABAP dictionary.
These objects have a name that starts with the '/BI0/0' prefix followed by one alphanumeric character for the object type and a numerical eight-digit identification: /BI0/01 ... temporary tables used in connection with a query processing. They are used once, the system usually deletes them automatically (unless the process did dump) and the names are reused.
/BI0/02 ... tables that are used for external hierarchies.
/BI0/03 ... not used any longer.
/BI0/06 ... similar to '/BI0/01', but tables are not deleted from the SAP DDIC.
/BI0/0D ... tables are used in context with the open hub functionality. They are not permitted to be deleted.
/BI0/0P ... tables occur in the courses of an optimized pre-processing that contains many tables. These tables can be reused immediately after releasing them.
With BI 7.x, temporary table management has been improved. Now it provides SAP_DROP_TMPTABLE report to remove temporary objects.

Recommendations

This report is not recommended to run on a regular basis. It might be useful to run it manually due to some exceptional situations when many temporary objects have been created.

Warning

The SAP_DROP_TMPTABLES report deletes all objects (except for the temporary hierarchy tables) without taking into account whether or not they are still in use. For example, this can result in the terminations of queries, InfoCube compression, and data extraction.

Related Notes

1139396
514907

Process Chain Logs and Assigned Process Logs Deletion

Introduction

Process chains are used in the BW landscape to automate the loading sequence. There are multiple running process chains at a given time. Their logs are stored in the database to be ready for future analysis. Storing older logs may use up the disk space and it is required to delete the older process chain execution log.
Process chains are executed at different frequencies – daily, weekly, monthly, at a specific calendar day, etc. There are the following tables that hold information about process chain logs: RSPCLOGCHAIN, RSPCPROCESSLOG.
The RSPC_LOG_DELETE report is designed to delete the process chain log.

Recommendation

Our recommendation is to delete process chain logs according to the process chain frequency of execution. In the case of daily or weekly execution, we recommend deleting logs older than 3 months, in the case of monthly or quarterly execution we recommend deleting logs older than 6 months, other frequencies as per requirement.

Process Chain Instances Deletion

Introduction

An instance is generated for each process chain execution and is stored in the tables RSPCINSTANCE and RSPCINSTANCET.

Steplist

You can provide the following input information to the settings:

• "Older than" field – entries older than set date will be deleted;
• If "without corresponding chain run" option is checked, the variant entry without execution of a chain run will be deleted;
• If "delete log" option is checked, these logs will be deleted.

Recommendation

Execute the task with the appropriate settings to delete the entries from the DB tables.

Automatic Deletion of Request Information in Master Data/Text Provider

Introduction

Master data InfoProviders, resp. text InfoProviders contain request information. It may be useful to keep the request information limited. This would mean deleting old requests (administration information) from master data InfoProviders and text InfoProviders to improve the performance and decrease main memory consumption.
The report RSSM_AUTODEL_REQU_MASTER_TEXT deletes obsolete request information from master data InfoProviders and text InfoProviders.

Recommendation

Our recommendation is to schedule the report periodically or in a process chain.

Unused Master Data Deletion

Introduction

In the case the selective master data deletion is required, there are two options:
In a single record level – using this task in master data maintenance and/or deletion mode.
Master data can be deleted only, if:

• No transaction data exist for the master data;
• Master data are not used as an attribute for an InfoObject;
• There are no hierarchies for this master data.

Steplist

Fill all fields to select the required master data:

Error Handling Log Analysis

Introduction

During Data Transfer Processes (DTP) different kinds of errors can occur. There is the RSBERRORLOG table (Logs for Incorrect Records) that stores the error handling logs due to the following and other reasons: Warnings that are created during the master data uploads for duplicate records and single record error messages in customer-specific transformation routines.
Thus, the RSBERRORLOG table can grow very significantly and can affect overall system performance.
To identify which DTPs are responsible for table size increase there is the report RSB_ANALYZE_ERRORLOG. It provides an overview of all DTP error stack requests and the number of records marked with errors.

Recommendation

Our recommendation is to run RSB_ANALYZE_ERRORLOG (in a background mode) to learn which DTP creates the most erroneous records in the RSBERRORLOG table. Thereafter we recommend running the report RSBM_ERRORLOG_DELETE to reduce the RSBERRORLOG table size. This action should be done monthly.

Related Notes

1095924

Error Handling Log Deletion

Introduction

During Data Transfer Processes (DTP) different kinds of errors can occur. There is RSBERRORLOG table (Logs for Incorrect Records), which stores error-handling logs due to the following and other reasons:

• Warnings that are created during master data upload for duplicate records.
• Single error record messages in customer-specific transformation routines.

Thus, the RSBERRORLOG table can grow very significantly and can affect overall system performance.
There is the RSBM_ERRORLOG_DELETE report which helps to reduce the size of the RSBERRORLOG table.

Recommendation

Our recommendation is to run the analyzing report RSB_ANALYZE_ERRORLOG (in a background mode) in advance to learn which DTP creates the most erroneous records in the RSBERRORLOG table. Thereafter we recommend running the RSBM_ERRORLOG_DELETE report to reduce the RSBERRORLOG table size. This action should be done monthly.

Related Notes

1095924

PSA Requests Error Logs Deletion

Introduction

If the relevant requests are deleted from the PSA, in most cases the system automatically deletes the PSA error logs. Otherwise, the program RSSM_ERRORLOG_CLEANUP can be used to delete them.

PSA Partition Check

Introduction

This task can be used in cases where the partitioning logic of PSA ignores the PARTNO field, the error stack for DTPs is created with a global index. A global index is created with the key fields of the DataSource and the active table of the write-optimized DSOs is partitioned, though there is a global index. See more in Related Notes.

Related Notes

1150724

PSA Partno. Correction

Introduction

The data may be written with an incorrect PARTNO = '0' into the wrong partition without any checks. When there is a deletion run on the PSA/CHANGELOG, the drop of the lowest existing partition will fail. This task helps to repair the requests written into the incorrect partition and will re-assign them to the correct partition. See more in Related Notes.

Related Notes

1150724

PSA Directory Cleanup

Introduction

This task 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 to check if data has been deleted or written into incorrect partitions. See more in Related Notes.

Related Notes

1150724

PSA Definition Cleanup

Introduction

While deleting requests from the PSA or due to the terminations when generating the transfer rules, in some circ*mstances, reference-free PSA metadata objects may be generated or may remain. This table partially remains in an inconsistent state. Therefore, the DDIC Tool displays these tables as incorrect.

Related Notes

1150724

Query Consistency Check

Introduction

Report ANALYZE_RSZ_TABLES is designed as a check-tool for detecting and solving different types of inconsistencies in the main query definition database tables.
The working mode of the task changed from the previous version. It no longer runs in one-system mode. This means it cannot be executed throughout all the landscape. However, the change offers a more detailed output, which enables you to drill down further into output subsections.

Warning

This task cannot be executed on a system connected via SYSTEM type RFC user.

Related Notes

792779

The F Fact Table Unused/Empty Partition Management

Introduction

Each loading process of transaction data into an InfoCube generates a new request. For each request, a separate partition is created in the F fact table. When the F table is condensed into the E table of a cube, the partition corresponding to this request is deleted after the condensing has been successful. Partition with this name is never again created. In addition, the entry corresponding to this request is deleted in the packet dimension table. Selective deletion from the InfoCube can remove the data of the entire request without removing the accompanying partitions. Empty partitions are those that no longer contain any data records. They probably result from removing the data from the InfoCube via a selective deletion. Unusable partitions might still contain some data. However, no entry for this request is contained in the packet dimension table of the InfoCube. The data is no longer taken into consideration by reporting. The remaining partitions are created if a condenser run has not been correctly ended.

Recommendation

We recommend using the report SAP_DROP_EMPTY_FPARTITIONS to display empty or unusable partitions of the F fact tables of an InfoCube and if necessary to remove them.

Zero Elimination After Compression

Introduction

The InfoCube compression often results in records within a compressed table in which key figures have 0 value. If these key figures are with aggregation behavior SUM, zero value records can be deleted. This can be achieved by selecting the option "Zero elimination" during compression or – if this option is not used – by applying the RSCDS_NULLELIM report.

Notes

The elimination of zero values may result in orphaned dimension entries. Therefore, regular dimension trimming is required when using zero elimination.

Recommendation

We recommend using the report RSCDS_NULLELIM after running the cube compression task if the "Zero Elimination" flag was not set.

Cluster Table Reorganization

Introduction

Cluster table RSIXWWW can contain large datasets that can be no longer accessed. This results in bottlenecks with the disk space.

Recommendation

We recommend running the program RSRA_CLUSTER_TABLE_REORG regularly to delete the entries in the table RSIXWWW that are no longer required.

BEx Web Application Bookmarks Cleanup

Introduction

Bookmarks are saved navigational states of a Web application. They are created in the BI system when using Export and Distribute -> Bookmark function, when saving an ad hoc analysis in BEx Web Analyzer or when personalizing Web applications.
With this task, it is enabled to reorganize the bookmarks that result from the Web template in SAP NetWeaver 7.0 format.

Warning

This task cannot be executed on a system connected via SYSTEM type RFC user.

BEx Web Application 3.x Bookmarks Cleanup

Introduction

Bookmarks are saved navigational states of a Web application. They are created in the BI system when using Export and Distribute -> Bookmark function, when saving an ad hoc analysis in BEx Web Analyzer or when personalizing Web applications.
With this task, it is enabled to reorganize the bookmarks that result from the Web template in SAP NetWeaver 3.x format.

Warning

This task cannot be executed on a system connected via SYSTEM type RFC user.

BEx Broadcaster Bookmarks Cleanup

Introduction

A bookmark ID is the identification number (ID) for a saved navigational state of a Web application. A view ID is the identification number (ID) for a saved navigational state of a query. These IDs are generated when online links for information broadcasting are created.
With this task, it is possible to reorganize and delete bookmark IDs and view IDs that were created by the system for information broadcasting and that are no longer needed.

Recommendation

To automate the reorganization of bookmarks and view IDs, this task can be scheduled to run periodically in the background.

Jobs without Variants Deletion

Introduction

Sometimes the error message "Variant xxx does not exist" occurs. This is due to inconsistencies, which happened during a system or client copy, a transport, or a call-back happening at the wrong client.

Recommendation

Use this task according to related notes to repair inconsistencies or mismatch call-back/client.

Related Notes

1455417

Delete BW RSTT Traces

Introduction

Sometimes RSTT traces cannot be systematically deleted. In this case,you can use this task to correct this problem.

Related Notes

1142427

Deletion of orphaned entries in Errorstack/Log

Introduction

The size of RSBKDATA or RSBKDATAINFOis constantly growing. Task removes orphaned data intemporarystorage of the Data Transfer Process for requests.

Related Notes

2407784 - How to clean up RSBKDATA and related tables

Clean up the DTP Runtime Buffer

Introduction

The size of RSBKDATA or RSBKDATAINFOis constantly growing. These tables contain thetemporary storage of the Data Transfer Process and can be deleted once DTP is successfully completed.

Recommendation

SAP recommends runningthis taskdaily.

Related Notes

2407784 - How to clean up RSBKDATA and related tables

Operational Delta Queue cleanup

Introduction

The Operational Data Provisioning (ODP) framework has been greatly enlarged during the last releases of SAP Business Warehouse (BW). Framework using Operation Delta Queue (ODQ) as temporary storage for data that are loaded from the data sources and pushed further for all subscribers of the queue. These queues should be cleanup to avoid unnecessary utilization of database resources.

Recommendation

SAP recommends runningthis taskdaily.

Related Notes

• 2286619 - ODQ_CLEANUP deletes entries in simulation mode

• 2190229 - Composite request can only be confirmed by the subscriber

• 2166526 - Solution to delete unconfirmed requests in transaction ODQMON
• 1836773 - How to delete outdated entries from delta queues
• 1745317 - ODQ: Cleanup Notification does not pass Queue Names

• 1735928 - ODQ: Improvements for Cleanup

• 1655273 - ODQ: More than one cleanup job per client

• 1599248 - ODQ: Real-time Support

• 1507908 - ODQ: Client dependency of the Cleanup Job is undefined

• 706478 - Preventing Basis tables from increasing considerably

Introduction

The size of the RSOTLOGOHISTORY table is growing. The table contains the metadata of the object versions which can be deleted.

Settings

You can specify the object type and deletion date to which data should be deleted. If you want to execute the task in a test mode, please use option Check only.

Recommendation

We recommend creating a dynamic variant and schedule this task for relevant objects on monthly basis.

Related Notes

2248171 - RSOTLOGOHISTORY Cleanup Report

BW Request Status Management cleanup

Introduction

RSMP* contains information regarding requests executed on the BW system. When these tables are big, the overall performance of creating accessing information (DTP loads, activation, and so on) regarding BW requests can be slowed down.

Settings

Name of ADSO object where we want to do the cleanup

Threshold request - all request created before and threshold request itself are going to be cleaned up

Recommendation

We recommend executing the task on regular basis.

Related Notes

2716063 - Improvements of RSPM housekeeping

Change Documents Cleanup

Introduction

During archiving, these change docs are archived together with main objects.But in some other circ*mstances (manual deletion, program failure, messy conversion/migration, etc.) the change docs can stay in the system for non-existent objects.
SAP provides just 1 report for deleting phantom change docs (SD_CHANGEDOCUMENT_REORG), but it's only for SD documents.
In OutBoard Housekeeping, the "Change Documents Cleanup" activity checks and deletes phantom change documents for a wider range of the objects types:

Step list

In the main OutBoard Housekeeping menu select "Change Documents Cleanup – Settings" under the ERP System Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.

_{Change Docs Cleanup – Settings detail}

To run this task in a Test mode, mark the test mode checkbox. This allows you to display available cleanup results in logs.
Once the Settings ID for Change Docs Cleanup is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.

Longtexts Cleanup

Introduction

During archiving, these longtexts are archived together with main objects.But in some other circ*mstances (manual deletion, program failure, messy conversion/migration…) the texts can stay in the system for non-existent objects.
SAP provides a report for deleting phantom texts (RVTEXTE), however, the Housekeeping task supports the Recycle bin as an added functionality.
As with Change documents, longtexts can also stay in the system for non-existent objects. In OutBoard Housekeeping, the "Change Documents Cleanup" activity checks and deletes phantom Longtexts for the following object types:

Step list

In the main OutBoard Housekeeping menu select "Longtexts Cleanup – Settings" under the ERP System Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.

_{Change Docs Cleanup – Settings detail}

It is possible to run this task in a Test mode. Mark this option to display available cleanup results in logs.
Once the Settings ID for Change Docs Cleanup is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.

Marking of Unused Customers / Vendors

A common feature of ERP systems is collecting the data – master and also transactional data. During the years the systems are in use, the number of master data (MD) becomes obsolete, e.g. specific vendors and customers are no longer business partners, materials are replaced by others...
The MD lifecycle makes the portion of master data outdated and thus the space in a database is allocated uselessly.
There is no straightforward way to delete the outdated MD because during the times there is an added number of transactional data bound with MDs. For legal reasons and database consistency, these documents can't stay orphaned in the database without the appropriate MDs. Therefore, the good and safe MD housekeeping approach consists of the following steps:

1. The list of MDs is selected (as a variant).
2. Selected MD, which together with bound documents (untouched for a reasonable period), are marked as blocked and 'for deletion'.
3. The documents bound with selected MD will be archived and deleted (SARA transaction). The same occurs with MD.

Marking of Unused Customers

You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled and selected whether or not the settings ID will be run in a test mode.
You may choose to set select conditions for marking unused customers:

• Customer ID
• Inactive longer than (Days)

_{Marking of Unused Customers – Settings detail}

Once the Settings ID for Marking Unused Customers is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.
Note: Marking of unused customers has no visible output; the customers that fall into select conditions specified in the Settings ID will be flagged with 'marked for deletion'. This flag will be used during SARA archiving with object FI_ACCPAYB with checked 'Consider Deletion Indicator'.

Marking of Unused Vendors

You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled and selected whether or not the settings ID will be run in a test mode.
You can choose to set select conditions for marking unused vendors:

• Customer ID
• Inactive longer than (Days)

_{Marking of Unused Vendors – Settings detail}

Once the Settings ID for Marking Unused Vendors is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.
Note: Marking of unused vendors has no visible output; the vendors that fall into select conditions specified in the Settings ID will be flagged with 'marked for deletion'. This flag will be used during SARA archiving with object FI_ACCRECV with checked 'Consider Deletion Indicator'.

Schedule Manager Tables Cleanup

Introduction

The Schedule Manager (transaction SCMA) enables you to monitor periodic tasks, such as period-end closings in overhead cost controlling. In the Monitor (transaction SCMO) you can display information about all scheduled jobs. The Monitor is a component of the Schedule Manager. The tool saves the information in its own tables (SM*) such as SMMAIN (main information about the entry), SMPARAM (processing parameters), and SMSELKRIT (selection criteria). These tables are prone to growing very large.

Recommendation

You can keep the size of Schedule Manager tables down by regularly deleting monitoring data that is no longer used. Once this data is deleted, you will not be able to monitor any more jobs that have already run. Therefore, it is essential that you only delete data that is no longer needed for monitoring, such as period-end closing data that is older than one year.

Related Notes

803641
Authorisations: authority object'B_SMAN_WPL'

BDocs Deletion

Created by:DVD Client-dependent: yes Settings as variant: noSupport for Recycle bin:no

Introduction

BDocs are CRM-related to intermediate documents. Unlike IDocs, which are asynchronous, BDocs can be used in both synchronous and asynchronous modes.
BDocs are used in CRM for data exchange and they can be quite complex in comparison with IDocs. They are transferred through qRFC or tRFC.
The tables for the business document message flow and the Middleware trace can increase in size considerably. This may cause performance issues during the processing of BDoc messages.
This task extends the standard SAP report SMO6_REORG.

Step list

In the main OutBoard Housekeeping menu select "BDocs Deletion – Settings" under the CRM System Tasks.
You can create new settings (1) by entering a new ID or choose from existing settings (2). For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.

_{BDocs Deletion – Settings detail}

Once the Settings ID for BDocs Deletion is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.

Recommendation

We recommend scheduling this task on a regular basis and setting the delete process for BDoc messages, trace data older than 7 days.

Related Notes

206439

Delete Inactive Versions of Products

Introduction

The task reorganizes the product master. Deletes all inactive versions of products with status I1100 = DELETED.

Recommendation

This task should be scheduled daily.

Deletion of old runID

Introduction

Datavard OutBoard Housekeeping is using multiple tables for handling the execution of tasks. Information like when and how long the task was running is not needed after some time period.

In OutBoard™ for Housekeeping, it is possible to delete already finished runIDs that are older than a certain date.

Recommendation

Our recommendation is to delete runIDs on regular basis.

RecycleBin Cleanup

Introduction

The RecycleBin is an essential part of OutBoard Housekeeping. For the specific tasks, it temporarily stores deleted data and if necessary, this data can be restored back. The number of days for which the data is kept in RecycleBin is called retention time.
When the retention time expires, this data is then permanently deleted from the RecycleBin. This process is provided by the scheduled job FS_SSYSRECBIN_CUDUMMY_SETT.
The RecycleBin cleanup task doesn't require any specific settings.
It is possible to execute this RecycleBin cleanup task the same way as all other tasks – directly from System view or via scheduling from Activity view (for a single system or landscape branch).

Recommendations

To ensure that RecycleBin cleanup doesn't overload the system, it is recommended to run it daily outside of Business Day Hours (this is locally dependent).

RecycleBin Size Recalculation

Introduction

It can happen that the RecycleBin size information is not accurate. The size recalculation task updates this information.
The RecycleBin size recalculation task doesn't require any specific settings.
It is possible to execute this RecycleBin size recalculation task the same way as all other tasks – directly from System view or via scheduling from Activity view (for a single system or landscape branch).

Recommendations

To keep the precise data size information of the RecycleBin, this task should be executed regularly.

Task Analysis

Introduction

The main goal of OutBoard Housekeeping is to remove temporary or obsolete data from SAP systems. This will be achieved by regular running of cleaning OutBoard Housekeeping tasks with appropriate settings. In general, these settings are created and maintained by Housekeeping users. However, it requires some level of expert skills concerning SAP basis & BW.
Therefore, OutBoard Housekeeping providesyou with a helper. Together with OutBoard Housekeeping packages, default settings starting with "_" are distributed. They are based on best practices for the specific OutBoard Housekeeping task.
For a limited set of OutBoard Housekeeping tasks, an analysis of data can be executed. Analysis output can be presented to show how much space can be saved after the task execution. It depends on the thresholds set for the selected settings. These settings can be modified and thus a potential outcome of housekeeping can be evaluated ahead.

Step list

Double click the system you want to work on. Scroll down the main OutBoard Housekeeping menu; select "OutBoard Housekeeping Task Analysis" under the OutBoard Housekeeping System Tasks.You can then create new settings:

1. By entering a new ID
2. By choosing from existing settings

For more information, please refer to the Creating a Settings ID section of this user documentation. Should you create new settings, the "Description" field needs to be filled.Once the Settings ID for OutBoard Housekeeping Task Analysis is specified, you can run the activity from the Main menu. There are several options on how to start the activity. For more information, please refer toExecute and Schedule sections of this user documentation.In this case, the execution and results shown can be reached also by choosing the selected group or system from the context menu in System View.

_{Analyses from System view}

_{Result of system analysis for default settings}

Recommendations

To keep the analysis up-to-date it is recommended to run this task after each execution of OutBoard Housekeeping tasks to which the analysis is connected.

Scheduling of System Lock

Introduction

If the system (or group of systems) needs to be locked on a regular basis, this can be scheduled using the task Scheduling of a System Lock.
In the task settings, set up the period using these time units: days and hours. Once this setting exists, the task can be scheduled by defining the start period and the reoccurrence of the scheduled system lock.
For example, if the system 'X' should be locked every month for the first 2 days, the variant using a period of 2 days should be created afterward the task should be scheduled. Once the locking period is over, the system(s) will be unlocked automatically. In case the lock should be canceled before the locking period is over, the task Cancel Scheduled System Lock can be used.
Check the statement "Pause / resume" support in the task chapter header. For these tasks, there is an automated pause/resume option available when the system lock is scheduled. When the system is being locked, the task finishes the last portion (request or package) and pauses. When the system is unlocked again, the co*ckpit resumes a paused task.

Step List

Double click the system you want to work on. Scroll down the main OutBoard Housekeeping menu and select "Scheduling of System Lock" under the OutBoard Housekeeping System Tasks. You can create new settings: by entering a new ID or choose an existing setting. For more information, please refer to the Creating a Settings ID section of this user documentation. After filling Settings ID, press Continue to get to the Schedule system lock screen.

_{Schedule system lock screen}

Fill in the Description field to specify your settings. In the 'Locking time' part of the screen, there are 2-time characteristics to choose from: Days and Hours. Choose one and Save Settings.To schedule a system lock press the button 'Schedule', fill in your settings ID, and a job run definition. There are 2 options to execute: Scheduled and unscheduled tasks. Press the calendar to check the task was correctly scheduled. After a system lock execution, display Logs to view if all the processes were properly executed. To review detailed information of an active lock, go to the calendar or display scheduling of system lock logs.

Cancel Scheduled System Lock (Ad hoc)

Introduction

This task allows an emergency cancel of the scheduled system lock in case a lock is to be canceled within the valid locking period.
Check the statement "Pause / resume" support in the task chapter header. For these tasks is an automated pause/resume option available, when a system lock (Ad hoc) is scheduled. When the system is being locked, the task finishes the last portion (request or package) and pauses. When the system is unlocked again, the co*ckpit resumes a paused task.
Note: This is just an emergency unlock. The scheduled lock will be automatically deleted after the required period.
Exception: This task doesn't unlock the manual system lock (system locked through Landscape editor).

Step list

Switch to the activity view and scroll down the main OutBoard Housekeeping menu. Double click "Cancel Scheduled System Lock (Ad hoc)" under the OutBoard Housekeeping System Tasks. Execute the task on the system.