FAQ: Technical Details

The required disk space decreases significantly due to the SAP data archiving and the subsequent PBS indexing. The data is compressed in both batch runs. Thus compared to the database, savings of up to 90% are possible in the logistics area. The gain in disk space reduces to only about 60% in financial accounting. This is due to the line items already being stored in compressed form in the database, and the savings effect mainly results from the saving of disk space for the index tables BSIS, BSAS, BSAD and BSAK that are reduced again by about 90%.

Measurements at customers have resulted in an archived accounting document including the PBS index data having an average size of about 600 to 700 bytes. An archived SD order including the PBS index data has an average size of about 1500 to 1700 bytes.

By relieving the load on the R/3 database, the performance and thus the response time of the system increase. Moreover, the times for the system backup decrease. The certainty increases in a large system for being able to execute a restore within an acceptable timeframe. An upgrade to a higher SAP release is often only possible after reducing the data through archiving. You can realize this using the PBS software so that the user does not have to do without a convenient access.

Since the archived data and the PBS indices are outside the database, the disk space in the database, and therefore the costs involved for the administration are reduced considerably. PBS requires only about 10 bytes per document (which is only one GB for 100 million documents) in the database to access the PBS indices. Thus the solutions with the least disk space requirement in the database are the PBS solutions. You also receive the disk space savings in a QA system that is usually a copy of the production system for a key date. You can access the productive SAP archive from both systems using the PBS indexing so that you can test programs that access the archive in the QA system. The disk space for the archives is only required once. If you reduce a database from 400 GB to 200 GB, the QA system also reduces to 200 GB. You have saved 400 GB in the database in which about 50 GB for the SAP archive and the PBS indices is required. In total, you have saved 350 GB! In the same way, you can also access productive SAP archives from the test or development system using the PBS indices.

This is a question of confidence and adaptation of customer-specific programs. Many customers start by archiving completed documents from previous fiscal years and index them using the PBS software. If you have adapted all programs to the archive access, the runtime can also be reduced. There are PBS customers that archive monthly and immediately archive every document that has been completed and thus cannot be changed any more. Most of the documents have a retention period of 3 months, however, to assist end-of-quarter closings only from the database due to the runtime.

The access to the SAP archive via the PBS indices is at least as fast as the database access. Precondition is that the SAP archive is still in the file system of the operating system. If you use a database server and one or more application servers, the SAP archives and the PBS indices should not be on the database server because it is completely reduced from any load due to the archive access. You can also define a special archive server using the NFS mount. If you archive for the first time and the database has already some performance problems, archiving and PBS indexing have an acceleration effect because the database now works more performantly again.

The PBS programs recognize if the SAP archive is in the file system, or has been removed via ArchiveLink to an external storage system without further Customizing settings. The data is read automatically from there if required.

In the simplest case, the PBS indices can be included like the SAP archives in the normal backup concept for the file system of the operating system. This means that the modified directories are saved after the SAP data archiving and the PBS index setup. The data is not changed until the next archiving run. If damage occurs in the file system disks, you can change the drive at any time and reconstruct the content of the defective disk drive per restore. Consequently, the requirements for the archive server drives are by far not as high as those for the database drives for which the data security is often created by mirroring. Thus the costs for such drives are reduced.

Apart from in CFI and CSD, the PBS indices can also be removed with ArchiveLink to optical archive systems and, nevertheless, be processed using the PBS transactions. However, a copy should be retained in the file system due to the access speed.

In theory and in practice any number. If, however, archiving has reached a certain scale and a PBS long-term archiving concept (see this section for more information) has not been realized for the SAP archive, you should contact PBS referring a long-term archiving concept for this SAP archive.

For each PBS module in which the long-term archiving concept for an SAP archiving object has not been realized, a parameter exists in the index setup program. You can define the time from when the data in the PBS index should be transferred using this parameter. If you increase this time in a merge run, all older data is not transferred to the new directory and thus deleted. The disadvantage is that the data cannot be activated again if you need it once more. In this case, the PBS index has to be set up again with the old time. This is not the case for the PBS modules in which a long-term archiving concept has been realized.