Change documents are continuously written by applications. It is not allowed to delete change documents, because changes must be documented due to legal reasons. Having such a large Change Documents table will cause many troubles, as the database cannot handle such a huge number of entries with good performance.
Regularly archiving the change documents reduces the amount of entries in the tables CDHDR and CDPOS. Ideally, We should start archiving the change documents even before the tables begin to create performance problems. The larger table CDHDR and table CDPOS are, the more time-consuming the data archiving will be. Large datasets must be transferred to the archive, the selection and processing of which takes a corresponding amount of time. You must distribute the documents to be archived sensibly among several archives. This reduces the runtime for each archive and simplifies the handling.
A continuous, regular archiving of change documents also prevents an excessive growth of the tables in the future. The extent to which change documents are created in a system depends on what applications are being used. Each application writes its own change documents differently. Archive runs can be scheduled depending on the growth of the change document tables in the relevant system.
There are two options to archive change documents:
You can archive them together with the application data in the application archiving object. To do this, the archiving object of the application must use the archiving class CHANGEDOCU. Using transaction AOBJ, you can display all archiving classes used by an archiving object.
If possible, you should archive change documents together with application data. The direct reference between change documents and archive data remains in this case.
You can archive them separately from application data in the archiving object of the change documents CHANGEDOCU. This is necessary if shared archiving is not intended or impossible because the application data is not archived themselves.