Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Activating Table Logging

Former Member
0 Likes
2,309

Hi All

We are currently looking at activating table logging on our ECC system, as we have some tables that will require logging for an internal auditing process. So far I have activated the Log Data Changes in SE13 however I am a little concerned about implementing the rec/client parameter as I am not sure how this will effect performance and database size.

I am aware that SAP have logging already set on quite a few tables, but with out the parameter set these will not log.

Does anyone have any experience of doing this, what was the effect and is there anything i should be aware of?

I know all systems are different, but any advice would be great.

Thanks

Phil

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
2,250

Hi Phil,

I've not been able to measure any change in performance on systems where I have implemented table logging.

The data is stored in DBTABLOG and it's growth is entirely dependent on what you are logging and changing. From memory the SAP defined lists are all config/customisation tables and as there will/should be infrequent change in these in the prod environment, the log size will not grow in the same way that the Security Audit Log files do.

If you log tables containing transactional data then you will get a large growth in the table size and you will need to think about archiving.

The approach that I usually take is to activate logging on config tables in the dev environment and a specific set of customer defined tables in production.

Hope that helps

Cheers

Alex

4 REPLIES 4
Read only

Former Member
0 Likes
2,251

Hi Phil,

I've not been able to measure any change in performance on systems where I have implemented table logging.

The data is stored in DBTABLOG and it's growth is entirely dependent on what you are logging and changing. From memory the SAP defined lists are all config/customisation tables and as there will/should be infrequent change in these in the prod environment, the log size will not grow in the same way that the Security Audit Log files do.

If you log tables containing transactional data then you will get a large growth in the table size and you will need to think about archiving.

The approach that I usually take is to activate logging on config tables in the dev environment and a specific set of customer defined tables in production.

Hope that helps

Cheers

Alex

Read only

0 Likes
2,250

Thats great Alex, thank you.

My research on what are Systems Analysists are trying to do is log changes to Customer Master data, this is for internal and external auditing. I am not too concerned as we make very little changes, however I will be monitoring this very closely once this goes live.

Read only

0 Likes
2,250

Hi Phil,

Usually XD04 (or similar) is used for monitoring changes to Customer Master Data - is there any reason why your internal/external audit don't want to use this? When I was performing process audits this transaction was always sufficient as long as it was used (rather than be ignored).

Cheers

Alex

Read only

0 Likes
2,250

Hi Alex

Yes you are right, however the tables we need top log are custom tables. We seem to have bolted so many extra elements relating to customer master that we need to lo these aswell.

Cheers

Phil