scc5 delete client processing coepl long time

[Former Member]

I am deleting client using scc5, and now ,it is processing "coepl" . but two days pasted, it is still processing coep.

this table have about 15000000 rows. I have check alert.log, it seems the database is ok. and in AIX OS, I can see many disk

I/O using topas,

in sm50, I can see a work process is running for sequential read and delete coepl, it seems it is still running.

and select count(*) from coepl, the total rows is decreasing.

I do not know whether it is ok that processing coepl such a long time?

Could you give me some advices?

thanks a lot.

Edited by: victor on May 19, 2010 2:15 AM

Edited by: victor on May 19, 2010 2:15 AM

Edited by: victor on May 19, 2010 2:17 AM

Edited by: victor on May 19, 2010 2:24 AM

Edited by: victor on May 19, 2010 2:28 AM

[Former Member · Accepted solution]

Hi Victor,

Usually table COEPL grows too quickly and it belongs to CO to store Line Items for Activity Types (by Period). Its all ok till the time you are able to see in SM50 and Work process is wrking on deleting the client. You can check the same in SE16 and enter the table name as COEPL and check for number of entries. Also from next time I would like to suggest you to follow the process to delete the client.

Suppose if you need to delete a client 105, you can create a command file "del105" with following entries ..

Clientremove

Client = 105

Select *

Place the command file in /usr/sap/trans/bin

$ cd /usr/sap/trans/bin

$ R3trans u2013w <log file name> -u 1 <command file name > e.g. $ R3trans -w del105.log -u 1 del105

To check the progress...

$ tail -f del105.log

Reorg the database.. its fast and its accurate.. !!

Ref: http://www.erphome.net/pdf/saezpdf/017saez.pdf

Edited by: prateek_y on May 19, 2010 4:23 AM

[Former Member · Accepted solution]

Hello Victor,

Are you using Oracle as database ?

When we perform client deletes or client copies (to an existing client where data also needs to be deleted first) we often have problems with some large tables (especially the delete).

This is very often caused by the index quality of the primary key.

First perform a trace of some minutes with ST05 of the process number where SAP deletes COEPL.

Afterwards analyze the trace and find out via which indexSAP performs the SELECTS and DELETES from COEPL.

Probably this will be the primary key.

It is a good idea to rebuild this index from time to time especially when a lot of data is deleted (or is being deleted), because database indices are NEVER rebuild automatically after a DELETE statement.

The rebuild of the index can be done online via program RSANAORA.

Also check this SAP Note about index quality:

[https://service.sap.com/sap/support/notes/444287|https://service.sap.com/sap/support/notes/444287]

PS : Also when you use another DB as Oracle I suppose index quality is very important regarding performance.

Success.

Wim