CTLBS.COM

Data Archiving
——————–

Data archiving refers to the removal of application data from the SAP system using an archiving program and storing the data in an archive file (at least one file).  The system uses an archiving program which is part of an archiving object.

The contents of business objects in the SAP system are distributed across several database tables.
Archiving objects combine the tables which are logically linked by business objects.
This insures that all of the information belonging to a business object is written to an archive file and deleted from the database.

Only data from completed business processes or from selected fiscal years can be archived.
Master data can be archived only if they have been marked with a deletion indicator.Some archiving objects set the deletion indicator in a special pre-processing program for data archiving, such as the archiving object CO_ORDER.

Archiving transactions can be centrally called from transaction SARA.

Data archiving is a two-stage process:
—————————————
1- Creating Archiving Files – The archiving program writes the data to be archived form the R/3 database to the archive files.

2- Deleting the data – The deletion program first reads the data from the archive file and then deletes it from the database.

Optionally, you can run a preprocessing program before starting an archiving session.
Pre-processing programs can, for example, mark for deletion (PP/PM/CO), and provide information on the archivability of data (SD).

1- Creating the Archive file
—————————-
In the first step, the archiving program creates a (first) archive file.
The data to be archived is read from the database in a background process and written to the archive file. This process lasts until the following results occur:
1. Archiving is completed: All data for selection has been read and written.
2. Archiving is not yet complete, but the archive file has reached the maximum size, as specified in Customizing.
3. Archiving is not yet complete but the archive file contains the number of objects as specified in Customizing.

2- Deleting the data
———————
There is one deletion process for each archive file
There are three ways to schedule the delete program:
1- Variant 1 : Run deletion jobs paralel to Archiving
After closing an archive file, ADK opens a new file and continues with the archiving process. The
delete program is then started in parallel. It proceeds to read the data from the archive file which has
just been closed and then deletes the data records from the database.
In this scenario, the archiving and delete programs are running in parallel.
In customizing You must select ’Start automatic’ under “Settings for delete program” in Archiving object – specific
Customizing.
2- Variant 2 : Start delete jobs manually
The system administrator starts the delete program manually after all of the archive files have been
closed.
The archiving session is closed once completed.
The delete run contains one process for each archive file.
In customizing You must select “No scheduling”  under “Delete program settings” in technical Customizing for the archiving object.
Start automatic is not selected.
3- Variant 3: Starting delete jobs automatically
The delete programs are scheduled automatically after all archive files have been closed.
The archiving session is closed once completed.
The delete run contains one process for each archive file.
In Customizing ’Start automatic’ is selected under “Delete program settings” in Technical
Customizing for the archiving object. The “Start at end” is selected in the definition
indicators for the archiving object in transaction AOBJ.

Servers for Archiving and Delete Jobs
————————————-
As of Release 4.5A, when scheduling jobs, you can specify the server on which the background jobs
are to run. If you do not specify a server the archiving program always runs in the background, preferably on a background server that is also
a database server.
You can schedule jobs using external schedulers. To schedule delete jobs outside transaction SARA, see SAP Note 205585.
In SAP R3, SE38 or SM36 can be used.
Events can be used for scheduling.  The event “SAP_ARCHIVING_WRITE_FINISHED” is triggered at the end of archiving session. The event

“SAP_ARCHIVING_DELETE_FINISHED” is triggered at the end of delete jobs belonging to same session.

If the database server has enough free resources and has an R3 instance on it then the netwrok load during archiving can be prevented.

Factors influincing the archiving duration are hardware used,  checks to ensure completeness of business processes, the amount of data to be archived, the

acrhiving sequence, size of the database, system load, archive files (NFS or local)

Archive Development Kit
———————–
All archiving programs are based on the Archive Development Kit
The ADK makes programming interfaces available to the applications to enable the following functions:
· Writing archive files
· Reading archive files
· Including archiving classes

The ADK ensures interpretability or readability of the bit sequences and conversion of the code page
if required. It also carries out automatic temporary structure conversions if changes were made to
the data objects in earlier releases.
 The ADK is included in the archiving programs by calling ADK methods. ADK stores the data in a
standardized format.
 To ensure access to the data, ADK writes management data to the database

Access to archived data is only possible using ADK

Archiving Objects
——————
In data archiving, all of the table records belonging to a data object are written together in context to
an archive file and then deleted from the database.

examples of archiving objects
———————————-
SD_VBAK Data structure: Orders
SD_VBKA Data structure: Sales activities
RV_LIKP Data structure: Deliveries
PP_ORDER Data structure: Production orders

Archiving objects are defined by the individual applications.You can create customer-specific archiving objects for customer-specific Z and Y tables.
The maintenance transaction for archiving objects is AOBJ. An archiving object must contain archiving and delete programs.
Programs for the following functions are optional: Reload, reporting, fill and empty indexes, preprocessing, and postprocessing. Technically, read programs

are also optional, but from a business point of view, they are required.

Application-specific Customizing includes the criteria that decide whether documents are archivable
or not. As well as meeting these criteria, a document must also have the status CLOSED in order to be archivable.

In transaction AOBJ, the “Buiild index” indicator in basic data means that an index can be created. If it is selected, there must be programs for filling and

emptying indexes. The indexes created are used by the application to access individual archived documents (within the standard transactions). If this

indicator is set, the deletion run fills an application-specific index table with index data for direct access to the document from the application’s standard

transactions. If this indicator is not set, no index data is generated for the deleted records.

Transaction AOBJ
—————–
Displays/maintains information about the archiving objects which are stored table ARCH_OBJ. The definitions of standard archiving objects should not be

cahnged. In AOBJ
– you  enter index fill and empty programs.
– You can enter customer-specific read programs.(enter customer-specific read programs in table ARCH_REPOW with  transaction SM30.)
– You can select “Start at end” to control the delete programs.

Navigation levels of transaction AOBJ
level 1: Archiving object
level 2: Tables which are archived
level 3: Tables in which you only delete
level 4: Maintain network graphic
level 5: Customizing settings
level 6: Archiving classes used
Archiving classes are managed in transaction ACLA.
level 7: Read program
A read program also appears in this selection list if it was entered in the table ARCH_REPOW using SM30
level 8: Customizing transactions
The main archiving criteria is the residence time for transactiona data and deletion indicator for master data.
Residence time: The length of time a document must remain in the database before it can be archived and deleted.
level 9: Info tables for archive data
level 10: Exit routine assignment in generation

Customizing in Data Archiving:
——————————-
Customizing is  required in four areas
1- General settings
you specify the name of the archiving object under which the archive files are to
be created and the file system in which the archive files are to be stored. You carry out maintenance
in transaction FILE. The archiving object in transaction SARA links to this

The name under which the archive file is created on the hard disk is entered in the parameter “phsy file” in the logical file name assigned to an

archiving object. The file name variables can, if necessary, be combined with other characters.
Param_1: Two-character application abbreviation taken from the archiving object
Param_2: One-character alphanumeric number, which guarantees that the archive file name is uunique. During an archiving session, the system adds this

number to an archive file name, where the file name already exists.Max. 36 possible entries (0-9 and a- z).
Param_3: ADK gives the name of the archiving object to the parameter (as of Release 4.5B).

In transaction FILE, you can customize the settings for all clients. If you want to use other settings for a specific client, you can perform

Customizing specifically for this client using transaction SF01.

2- Techincal settings
for an archiving object determine the size of an archive file, for example, and specify whether the delete program is to be run immediately after the

archiving run and whether the archive file created can be stored in an optical archive. The maintenance transaction for technical settings is SARA
3- application specific customizing
you specify the applications and criteria for archiveability for data that is to be analyzed later in the archiving run. You are required to specify

the residence times for transaction data and to set the deletion indicator for master data. Application-specific settings are made in Customizing for

the relevant application.
4- cross-archiving object technical settings
affect, for example, the writing of verification data. When archive files are being written, they can be supplied with verification information. This

does not affect the size of the archive files. Any corrupt files are recognized and a system message is issued. The deletion is then not started.
Data Archiving monitor: Activate or deactivate an administration function in CCMS

size of the Archive File
—————————–
-size in MB
-Max number of data objects
Whichever value is reached first triggers a new file. No value means one file is generated.
Recommended sizes: 100-200 MB
Where there are a lot of files, note that one delete run is scheduled for each archive file and that each delete run contains one background process. The

system workload therefore increases with the number of files
You specify directly the content repository in which the ADK files are to be stored.
You can specify that the archive files are to be stored in the external system before the data is deleted.
If you do not set the “delete program reads from storage system indicator”, a copy of the ADK file is left in the file system after storage and is deleted by

the delete program.

The delete program uses the commit counter to trigger a database commit after a specified number of archived objects. The setting of this value affects

program performance. Recommended commit counter setting: A value greater than 10 is generally not recommended. You are strongly advised to manually check the

value of the commit counter (see Note 69143).

Data Archiving Variants:
—————————-
Each archiving session uses an archiving variant. The variants contain the following info.
– Selection criteria for the data to be archived
– Whether delete program runs in test mode or not
A separate delete program variant must be saved for each delete program . There must be at least one test and one live run variants.
Archiving variants are maintained in the archiving transaction just before the archiving session

SAP& / CUS& variants –> saved in client 000 and accessible to all clients
non SAP& / CUS& variants –> saved in specific clients and imported

Application Specific Customizing in SD
—————————————–
SD_VBAK    –> Table V_TVARA     –>    transaction VORA    Residence time per sales org. and per document type.  User exit possible
SD_VBRK    –> Table V_TVARR     –>    transaction VORR    Residence time per sales org. and per document type.  User exit possible. Activate check FI

doc.
RV_LIKP    –> Table V_TVARL     –>    transaction VORL    Residence time per sales org. and per document type.  User exit possible. Activate check FI

In standard the starting point for residence time is the documetn creation date.

Customer specific checks/User Exits:
examples.
1. A sales order requires an internal procurement. The sales order should remain in the system until the production is complete.
Consequently, the time to be checked is not based on the document creation date.
2. Based on the order, the system creates a purchase order. The purchase order is to be archived before the order.

Creating user exits for SD Archiving:
1- Call transaction  SE38 and run report SDCLVOFM .
2- locate  REAK  – Order
RERK  – Billing doc
RELK     – DElivery
3- change mode must be selected
4- In the next screen select the specified form routine and call teh source text. Then enter the customer specific code
5- Actiocate the user exit
6- Enter teh number of the exit in the application speciifc customizing in the RNR field

For SD user exits, see Note 114340. The returned value is contained in the variables SV_ARCHBAR. The entry X stands for archivable, space stands for non-

archivable.

DATABASE ANALYSIS
—————–

Use DB02 or DBACOCKPIT to get information on table sizes , indexes, table spaces
Use DB15 to get information on which archive objects contain which tables or vice verca. Also get information on space statistics for tables
Use TAANA to get table analysis information. It provides information on how the data is distributed to the various clients.
The variant DEFAULT is always available, but differentiates the documents according to the client only.
SAP can provide an ARCHIVE variant that contains archiving relevant criteria.
Separate customer-specific variants can be created, if needed.
The system lists the data corresponding to the criteria in the analysis. Thus the selection criteria that are most efficient for minimizing the data

in the database can be determined.
Analyses are saved in the database in specific tables that belong to TAANA. Delete the results as
soon as your data archiving run is complete.To delete analyses, choose Utilities > REorganize analysis

Use ALO1 to reach to DRB (Document relationship browser).
Finds an SAP document and all its related documents. You can branch to specific documetns from DRB. Each BOR object is identified by its key.

Dependencies between Archiving Objects:
—————————————
Check the network graphic in SARA for a chosen archiving object. Network grphic shows the last archive date. Green finished, yellow incomplete run.

MM_MATBEL -> MM_INVBEL -> MM_REBEL
MM_EKKO -> MM_EBAN -> MM_EINA -> MM_ASMD
SD_VFKK -> SD_VTTK -> RV_LIKP -> SD_VBRK -> SD_VBAK -> SD_VKA -> SD_COND
MM_SPSTOCK -> MM_MATNR
IDOC

List of most important Arch. Objects
————————————-
FI_DOCUMNT
FI_GLF_IT
FI_SL_DATA
MM_EKKO
MM_EBAN
MM_MATBEL
MM_ACCTIT
SD_VBAK
SD_VBRK
RV_LIKP
PP_ORDER
PCA_OBJECT
CO_ALLO_ST
COPA1_*
COPA2_*
CO_ITEM

DATA ARCHIVING USING SARA
—————————
Scheduling archive and delete jobs
Use transaction SARA to schedule ADK sessions. Before starting the delete job, make sure that the archive files that have been created are available
and have been saved. In the case of parallel processing of delete and archive jobs, you must ensure that you can access backup on the database in case

there is a disk failure.
In order to minimize the system resources required, the delete jobs can be concatenated to start serially rather than in parallel.
Archiving programs usually create a log. This log can usually be made available centrally by the
ADK and can provide a statistical overview of the archiving.
Logs can be stored in an external storage system.

The functions available in transaction SARA depend on the programs that are defined and stored in transaction AOBJ.
The INDEX function refers to index build and index empty programs, which in turn refer to an application-specific index.
Application-specific indexes enable you to display individual archived documents from an original transaction. FI_DOCUMNT and, as of Release 4.0,

MM_MATBEL can be displayed in this way.

MANAGEMENT contains the data archiving administration function.
The ANALYZE function contains all read programs that are available for archived data.
Choose the “i” button to see the programs used by PREPROCESSING and POSTPROCESSING.
As of Release 4.6C, if you specify in Customizing that the archive files are to be stored in an external storage system, the “storage system” button

is displayed. You can move files from there to an external storage system

Step 1 : Create and archive variant:
Step 2 : Specify the archive user
The user who starts the archiving program requires the authorization SAP_ALL.
Step 3 : Specify start times
Step 4 : Define spool parameters
Since job logs can be large, you are advised not to print them immediately

possible Archiving Checks:
Status check            : IDOC
Pure master data         : MM_MATNR, FI_ACCRECV
Business checks+fiscal year    : C_COSTCTR
Business checks+residence time  : FI, SD, MM, PP, HR applications

Pure master data is usually difficult to archive because, in addition to the deletion indicator, whereused lists are also checked.
To archive a material master, for example, no documents referring to the material can be present in the database

Storing ADK files
Analysinf job logs
Problem solving durinf archiving
Handling ADK admin data
Authority checks within Archiving

Job Schduling and Variant Maintenance: RV_LIKP
———————————————-
Selection
possible by document number (Specify a defined value in the Document number selection criterion to avoid a full table scan.), creation date, delivery

type, sales org, shipping point.
Optional checks
Check FI document.       : Only activate i the system must ensure no uncleared deliveries are archvied
Check flow doc. residence: REsidence time is based on creation date of the last business event and not the creation of the delivery ddoc.
Alternative DB access     : Archiving program stores selected data in an internal table instead of a in a database cursor

The RV_LIKP preprocessing program tells you which documents cannot be archived and why
The RV_LIKP preprocessing log counts internally each unfulfilled criterion for a delivery, that is, there may be more non-archivable deliveries in the log

than there are actual deliveries.

Job Schduling and Variant Maintenance: SD_VBRK
———————————————-
Selection
possible by document number , creation date, invoice type, sales org.
Optional checks
Check flow doc. residence: REsidence time is based on creation date of the last business event.
Alternative DB access     : Archiving program stores selected data in an internal table instead of a in a database cursor

REsidence time : REquired
Flow            : Required : If the billing document has a subsequent document (such as a credit memo request relating to the billing document), the system

checks whether the subsequent document has the overall processing status “Completed”
Accountig doc  : Optional : If “Check accounting” is set in the archiving object Customizing, the system checks whether Financial Accounting has cleared the

billing document (for example, by payment).

Job Schduling and Variant Maintenance: SD_VBAK
———————————————-
Selection
possible by document number , creation date, order type, sales org.
Optional checks
Check purchase order
Check FI document
Has the billing document been cleared in financial accounting (for example, by payment)?
Check flow doc. residence
The system checks whether the subsequent documents belonging to the current sales document have the overall processing status “completed” The

individual steps are as follows:
Selection of follow-on documents in the table VBFA
Checking that the follow-on documents from the selection in the table VBUK have the overall processing status “completed”.
A standard order is only archived if the delivery goods issue has been posted and billed.
A customer quotation is only archived if the accompanying order has been delivered (in this case, the delivery itself is not be checked).
Alternative DB access

Flow Control in SARA
———————-
Check with the user department whether archiving should take place during the working day or at the weekend.
– Execute the test run without creating concrete archive files. The purpose of the test run is only to provide a more accurate assessment of data quantities

and runtimes.
– Discuss the following resource requirements with the system administration:
· Memory
· Background processing (deletion)
· Disk space for archive files
– Recommendation:
Parameter heaparea/nondia should be increased.
The value depends on the customer-specific configuration. Contact your system administrator.
– The required disk space for archive files can be read from the standard log for the test run.

Monitoring Activity in CCMs
—————————
The data archiving monitor is available as of Release 4.6. It is intended to enable the system administrator to monitor archiving sessions in the CCMS monitor

for his or her area (progress control during an archiving session). The data archiving monitor can be deactivated in crossarchiving object Customizing.
Tools -> CCMS -> Control/Monitorin ->alert monitor -> SAP CCMS monitor templates -> Data Archiving

you can display archiving  sessions in SM37

Restart After Program Error in Archiving Program
————————————————
Case 1:
DElete programs are schedueled manually after one or all of the archive files have been created
step1: Schedule the delete jobs for the existing archive files
step2: Delete the defective file from the file system
step3: Re-execute archiving with the same selection criteria
Case 2:
Delete programs are scheduled automaticall after all the archive files have been created. “Start at end” indicator is set in AOBJ
step1: Delete the archive files that have been already created in this session
step2: Set the delete indicator in archive management for teh interrupted session
Step3: Re-execute archiving with the same selection criteria

Restart After Program Error in Delete Program
————————————————
Case1:    cannot delete –> Restart the delete program
CAse2:  an archive file is defective and cant be read –> Contact SAP Support

Most common Program Errors:
————————-
storage : Insufficient storage space
database: Rollback segment overflows before transaction commit -> Change commit counter
database: Database log file overflows -> monitor db log files
database: Mutual blocking during deletion -> start jobs serially, not in parallel

profile  : profile parameter for memory are too small
heap_area_nondia
heap_area_total
tv_newpage_alloc

Archive LOg
——————–
The function module ARCHIVE_WRITE_STATISTICS writes the standard log.
During the test run, the standard log is not created for the following archiving objects:
FI_DOCUMNT
CO_ORDER
MM_MATNR
The logs are deleted when the spool jobs are cleaned up (which occurs on a regular basis).
Therefore, you have to decide what is to happen to the logs.
If you use an external storage system, you can store the archiving and spool logs there using the “store print lists” function.
Otherwise, you could store the data in RFT files in the file system by choosing System -> list-> Save -> In local file in the log display.

Archiving Sessions:
————————-
You can access archive management using transaction SARA.
The sessions are each bundled in groups of 20.

– The short text refers to the contents of an archiving session.
You should record the selection parameters used so that you can see at a glance the contents of archive files in archive management.
– You can also determine the selection parameters used by choosing “user settings” on the initial screen.
You can add or change archiving notes at any time.
– To remove entries in archive management from the database, call the management data for the archiving session in transaction SARA (double-click on the

archive files) and mark for archiving.
– The archiving program for BC_ARCHIVE removes all marked archiving sessions from the database. It is not possible to restrict this to specific objects.
– It is possible to reload archived management entries on an object-specific basis. The entries are then recreated with their original status.
In 4.6C, the reload function can be found by choosing Goto > REload

Administration of Archive Files
———————————
– The management table for archive files is ADMI_FILES.
– The following information on individual archive files is contained in the managment data:
Number of data objects
Sizes in MB
Archiving status
Creation date and time
– Index information is stored in the ARCH_IDX table.
Individual applications can build their own index tables, for example ARIX_<tablename> for FI_DOCUMNT.
– ’Archive file is accessible’ specifies whether ADK can directly access an archive file in the file system. When the detail display of archive files is

called, a “fileopen” occurs.
– Two statuses are possible:
1. Status regarding storage in an external storage system: Stored (in storage system)/not stored (file is in file system or in an HSM system)
2. File status: Archived/archived and deletion/complete. Complete means that an archive session occurred, but no file was created.

To determine whether the archive files have been stored in an optical archive, select a file and choose “storage system”
The “storage” field shows a red light if the archive file is not in the optical archive.
In this case, the red light does not denote an error.

Authoriaztion Checks:
————————–
Auth. object: S_ARCHIVE
Activities:    Write, Read, Delete, Reload

S_archive cehcek for activity and the application area to which teh archiving object belongs to and  archiving object

Auth. object: S_BTCH_JOB

There is at least one application-specific authorization object for each archiving object.
Application-specific authorizations are also required for read access to archives.
The archiving user should have SAP_ALL authorization.
Since it is possible to specify a user when scheduling an archiving session, a session can be started with a system user.