Impact on system of table logging,

[Former Member]

Hi Guys,

I have some question here related to change logs, i tried to search a lot but not able to find answer of my question.

We are using ECC 6.0 with Oracle 10g. Table logging has been enabled by setting the profile parameter as wll as transport parameter also

After that i am able to find out some change logs for some limited table.

1. What will the impact on system if i enabled logging for all the cusomizing table as well as master table.

2. in SE03 if i insert the transport request number then i can see the table or whatever object associated in that request, but suppose the data of the table has been changed and transported then how can we track the changes of the transport request.

3. Table logging will work for all the master table & customizing table or not.

If you have any idea then please let me know.

Regards

Subhash

[Former Member]

Hai,

If logging is switched on, each change to an existing data record (with UPDATE, DELETE) by the user or application program is recorded in the database in a log table (DBTABPRT).

Logging can be done to specific clients of a system or to all clients of the system.

Logging slows down accesses that change the table. First of all, a record must be written in the log table for each change. Secondly, a number of users access this log table in parallel. This can cause lock situations although the users are working with different application tables.

Existing logs can be displayed with Transaction Table History SCU3.

See SAP note 1916.

1). As per the theory above if you activate logging on all Customizing and Master tables, your system will be affected and the performance will be poor. Do not try in a Production system.

2). http://help.sap.com/saphelp_nw04/Helpdata/EN/7e/c81ebb52c511d182c50000e829fbfe/frameset.htm

3). You can do it for all the customizing tables.

http://help.sap.com/saphelp_nw04/Helpdata/EN/7e/c81ebb52c511d182c50000e829fbfe/frameset.htm

Regards,

Yoganand.V

[Former Member]

> 3. Table logging will work for all the master table & customizing table or not.

You can, but probably is an overkill.

The master data tables have their own application specific change documents which would normally take care of the audit trails and legal requirements. You don't need to activate the table log for the system to generate change documents.

Cheers,

Julius

[Former Member]

First of all thanks a lot for your vaulable input. But now i m little bit confused about this. It is a normal process to track the change logs, so can you help me little more in these circumstances what should be ideally done.

Table logging should be enabling only for customizing tables.

What you guys suggest as this process might be runnning all over the world where SAP is running, so can you share your view how you see this process, what should be done in this situations.

Regards

Subhash

[Former Member]

> What you guys suggest as this process might be runnning all over the world where SAP is running, so can you share your view how you see this process, what should be done in this situations.

My view on this is that there are default installation values and defaulted technical properties in the data dictionary which SAP provides.

There is nothing wrong with changing them to meet your requirements, and I normally do change a few (particularly if there is no intention to use a certain feature).

A suggestion:

Activate the table logging globally in all clients using rec/client = ALL and in all systems (DEV, QAS, PRD, etc). The reason for this is that you will typically make customzing changes in DEV and transport them, so you would want to know who changed what in DEV (not PRD - as there you will only see the transport request number). If some tables are generating huge numbers of records, then investigate what is causing that (a where-used-list for the table keeping an eye out of Z* programs is a good place to start).

Activate the transport tool profile as well to recclient = ALL. If you are transporting a lot of customizing all the time, then reconsider whether you really want to transport the stuff. There are also some cases where SAP does not request a transport for some tables which are in the grey area between customizing and master data. If you want to maintain very sensitive master data in DEV, then you can change those settings as well in the data dictionary (transaction SE13).

For the rest of the application specific transaction and master data which is productive only, you can generally rely on the application specific change documents. There are typically in CD* tables, but there are some exceptions in other application areas which take care of their own "logging".

Normally you cannot turn these last ones on or off anyway. They are product features or legal requirements, and sometimes trying to delete the change docs will cause a lot of problems and noise in the system But generally it is possible to archive the majority of them.

That would be my suggestion.

Good luck,

Julius

Edited by: Julius Bussche on Dec 27, 2008 10:07 AM

[Former Member]

Thanks a lot Julius for your detail description. The complete picture is clear now so i can start some analyzing and working now,

Regards,

Subhash

[Former Member]

Thanks Julius,

The information was very helpful, Can you tell me which all tales need not to be logged, or which are essential table to be logged.