Problem running Change Log on Z table

[Former Member]

I have a custom table with 2 key fields, ~5000 records, containing data that has changed often. In the Technical Settings for the table, Log Data Changes is checked and buffering is off. I need to be able to see changes to the data. I run SCU3 on it for a 10 day period, and it times out. So I run it again in background. Basis flags the job for performance problems stating the problems are because the underlying table DBTABPRT is too big for SCU3 to run efficiently.

Are there changes I can make to the table definition so I can use SCU3 to view changes? Or can someone suggest a solution?

Thanks,

--Beth

[Former Member]

Hello Beth,

Even you joined the SDN community on my birthday, I only can suggest that, depending on the stated message,

.... because the underlying table DBTABPRT is too big for SCU3 to run efficiently.

you should talk to the Basis guys and ask them to wipe out the table DBTABPRT appropriately. This table can be huge and the is so much not needed scratch in there.

Have success,

Heinz

[Former Member]

Hi,

Seems like you are logging in lot of changes.

It is a system performance issue.

Please ask BASIS guys to look into it.

-Raj

[Former Member]

Thanks for the responses. Since I have already reported the problem to Basis, and they have asked me to look into a solution, can you provide any guidance on how they should "clean up" the table? Any information or links to information that I can pass on to them would be helpful.

[Former Member]

Hi Beth,

What I am telling you is not a bible text but a way I would pursue solving your issue:

1. take a look at the number of records in DBTABPRT. Open the table using SE11 or SE16 and click the Number of Entries Icon.

2. In SE11 go to Technical Settings and take a look at the Size category. When the number of records exceeds your size category, then adjust it. And run SCU3 again.

Otherwise or when it times out:

Cleanup the table. I am pretty certain SAP provides a program doing this. May this one helps you: RPLDAP_CLEAN_UP_LOG_TABLES.

When not, I would simply create a program and wipe out, let me say, all records older than e.g. 50 days using the SQL DELETE statement. There shouldn't be any problems regarding table-correlations/dependencies. DBTABPRT is pretty much a stand alone table.

Good luck,

Heinz

[Former Member]

Thank you for your help. Basis folks have been able to identify the z tables that are over-populating DBTABLOG, and by unchecking "Log Changes" and deleting the millions of unnecessary rows, we're able to work with the log records we really need.