DATA Archiving in ISU - Role of ZARI* tables after data archiving

[former_member602144]

Hello Experts,

I have been archiving Print document and Billing documents since 2017.

As we all know that after archiving, the archived data sits in ZARI* staging tables, but we are not purging the data from these ZARI* tables. I want to know what percentage of the archived data goes in ZARI* tables after archiving and how much database space is actually reclaimed if we archive the documents and not purge the ZARI* tables.

So the idea is to understand are we really freeing up the database by archiving or we are just moving the data from database tables to staging (ZARI*) tables?

Also, does creating index in ZARI* tables help in reducing some storage space? Can anyone let me know of any other way to reduce the storage space from these staging tables without purging the data? Reason why we have never purged the data is, we are reading some data from ZARI* tables for reporting purpose.

[JGery]

Hello Rupsa!

I would like to provide some comment.
Your sentence need to be corrected:
"So the idea is to understand are we really freeing up the database by archiving or we are just moving the data from database tables to staging (ZARI*) tables?"

The ZARIX* tables do not contain the actual archived data. These tables are index tables, which show for evaluation/reading purposes, in which archive file and within archive file in which offset the questioned archive data object can be found. Please note that many applications rely on ZAIRX* index tables (e.g. on Archive Information System) to display own archived business objects in application transactions. So for end users, who want to display archived objects in well known application transactions, it is really important that infostructure (ZARIX table) is filled with index data.

If you archive a business object from many different tables, it can be a lot data archived from various tables. Independently how many table entries were archived for this one business object, only one entry/line will be created in ZARIX table, if infostructure is filled with this business object. So you still can save more space even if you use infostructures (ZARIX tables).

You have to decide with your application colleagues whether you want to access archived data or not for certain application data, e.g. for certain archiving objects. If you do not need this access for end users or for evaluation, than you do not need infostructure (ZARIX* tables) to fill with data, so ZARIX table will be empty. Keep in mind that you can always fill and delete entries from infostructure ZARIX* tables via SARI. So you an also have empty infostructure and if archived data needs to be read, that you fill infostructure with appropriate data, and when reading archived data is not needed anymore, you can remove entries from infostructure ZARIX* tables.

We have no definite list of applications which are using Archive Information System (this is a decision at Application side), so we can not provide you info what percentage Infostructue (ZARIX*) is used by applications.
For more info check the online help:

https://help.sap.com/viewer/f0944a4717b5464f8d2343f9a44ff65b/latest/en-US/4d8c77cb910b154ee10000000a...

Regards
Gergely

[rafael_cano_perez]

Hello Rupsa

I have no experience with ISU archiving but with SAP archiving in general.

When you archive SAP documents you can configure archive information structures, which are part of the sap archive information system, to keep some data online, even though in different dedicated tables ( the ZARI* you mention ), before the data is deleted form the document tables.

Here is where you need a balanced approach in selecting which information you need to be available online after archiving the documents, because if you select a lot of fields you end up using a lot of space and the archiving benefits, from the point of view of space consuption, becomes less obvious.

Using the ADK it is possible to read data out of the archived data stored in files in the operating system, or content server, so you can still build some reporting tools without the need to have the information reloaded or online, but not with the same speed and flexibility of the archive information systems. This is the reason it exists.

Hope it helps.

Best regards, Rafael Cano