Performance issue with JEST table

[Former Member]

Moved to correct forum by moderator

Hi all,

I have a report which is giving performance issue.

It hits the function module "status_read", which in turn hits the table JEST..

The select query is:

SELECT SINGLE * FROM JSTO CLIENT SPECIFIED

WHERE MANDT = MANDT

AND OBJNR = OBJNR.

I know we should not use client specified, but this is a SAP standard code..

Since this query is hit many times, it results in TIME_OUT error..

I observed that the table JEST has 133,523,962 entries in production and in technical details, the size catagory is metnioned as 3 - (Data records expected: 280,000 to 1,100,000).

Since here, the data size is exceeded, if i change the size catagory to 4 would improve the performance?

Or should I request Client to archive this table? If yes, please guide me how to go for it? I have heard there are archiving objects.. please specify which objects should be considered for archiving...

I could only think of above two solutions, please let me know if there is any other workaround...

thanks!

Edited by: Matt on Jan 27, 2009 11:12 AM

[former_member222860]

Hi,

I'm not sure the exact archiving object for this, here are some archiving objects related to tabel JEST

MM_EBAN
MM_EKKO
MM_MATNR
PP_ORDER
PR_ORDER
PM_NET

pl. go thru them using tcode: SARA

thanks\

Mahesh

[Former Member]

Hi,

Please create the secondary indexes for the table JEST...it will increase the performance.

Regards,

Rohan.

[Former Member]

> Since here, the data size is exceeded, if i change the size catagory to 4 would improve the

> performance?

has no effect at all, it is only a information.

Which table are you talking about JEST or JSTO ?????????

Secondary index, .... out of primary key fields .... nice recommendation.

133 mio. records ... archiving would be a good idea! Probably your only chance!

Siegfried

[Former Member]

Check with this FM - STATUS_READ_ARCHIVE_OBJECT

for archiveing all these tables:

JSTO, JCDO, JEST, JCDS, DJEST

Check them out.

Regards,

CK

[Former Member]

Hi,

Check the table and index size in T-code DB02. if index size is more than table size try to reorganize that. before index reorg check the index storage quality.

Regards

Atchi

[Former Member]

After reorg, update the database statistics.