Trace single table

[Former Member]

Hi All,

Currently we have not facilitated any trace in SAP system.

My requirement is to trace only single table. Can anyone guide me for how to set the selection criteria in ST05

or is there any other txn or way to set trace for single table.

Actually data from one table has been deleted 3 time we want trace the reason for that.

Thnx in Advance.

[ravi_lanjewar]

Yes, You can set the trace on table.

Goto to transaction st05, Check box SQL trace and click on push button Activate trace with filter.

Pop off box will display, put * in user name and in table name have to option on for include & exclude .

In include having 5 table name you can define your table name there to set trace on table.

[Former Member]

I would not recommend to filter in advance, always trace everything and use 'Summary by SQL statements' to get an overview!

Often ypou will see that other tables are the more important one. Otherwise it is easy to concentrate on the special ones in the summary.

Next step would be to filter in the display.

Only as a last resort I would filter already in trace taking.

[HermannGahm]

Hi Siegfried,

as far as i understood the original question the table is known and it is not about performance but functionality (find the source of deletes on a specific table). Given that i think filtering while taking the trace is a very good idea.

For performance related question i agree that no filters should be applied in the beginning. But even here we have to use the filters later from time to time to make the traces smaller. With the default setup (10 files with each 16 MB) and big statements (e.g. FAEs) the trace can only cover 3 minutes of a running program. In such cases we try to exclude the FAE's after we have analyzed them to capture other tables.

Kind regards,

Hermann

[Former Member]

>as far as i understood the original question the table is known and it is not about performance but functionality (find the source of >deletes on a specific table). Given that i think filtering while taking the trace is a very good idea.

o.k., Hermann, you are probably right in this case. Then the stack trace, if available, can help. But maybe it is even better to check the non-aggregated ABAP Trace.

Otherwise, I know how the answers in this forum are often taken. Therefore I wanted to add my concerns.

Siegfried

[HermannGahm]

Hi Siegfried,

> Otherwise, I know how the answers in this forum are often taken. Therefore I wanted to add my concerns.

I see and i agree.

ABAP Trace is a good idea as well if the program(s) is/are known .

Another idea is the SQL cache. If the deletes happened recently they might still be in the sql cache.

We can use the table filter there.

Without knowing the program(s) i would start with the SQL cache in ST04 i think.

ST05 with filters had to be systemwide without knowing the program(s).

If the program is known SE30 / SAT / ST12 is the better choice i think.

Kind regards,

Hermann

[volker_borowski2]

Hi,

if the database is oracle, you might search the SAPNET FAQ note for "flashback query".

You might be able to pinpoint the time when the deletion took place, which might lead you to a job which is responsible.

Flashback works like i.E.

select * from table as of timestamp(...)

See the corresponding flashback note for syntax.

But I see that the charming point in sqltrace is, that you'll get the calling ABAP source.

If you'll not going tracking it down this way, consider to implement a DB trigger for a while.

Let the trigger flag a row in a monitoring table.

Have a script polling the monitoring table for the flag beinig set and if yes have it paging the DBA,

who can then dig imediately in the sql-cursor cache to find the calling ABAP source.

Triggers are not gererally supported in SAP, so just keep it active for the while it needs to track this one down.

Volker