Performances on IBINVALUES update

[Former Member]

The table IBINVALUES is one of the most bigger table in our DB, and with indexes the total amout is more than 100 GB, and it is growing.

We have several critical programmes accessing this table; if we perform the sql trace from ST05 we see the time for the insert statements on this table are the most higher.

Both the table and the programmes involved in the update process are standard Sap.

We are investigating how to increase the performances of the insert/update in the IBINVALUES table, but till now we do find anything usefull, from the technical point of view.

We are on Unix/Oracle 920, rel. 47 Enterprise.

Someone has some suggestion ?

regards

[Former Member]

The table IBINVALUES is one of the most bigger table in our DB, and with indexes the total amout is more than 100 GB, and it is growing.

We have several critical programmes accessing this table; if we perform the sql trace from ST05 we see the time for the insert statements on this table are the most higher.

Both the table and the programmes involved in the update process are standard Sap.

We are investigating how to increase the performances of the insert/update in the IBINVALUES table, but till now we do find anything usefull, from the technical point of view.

We are on Unix/Oracle 920, rel. 47 Enterprise.

Someone has some suggestion ?

regards

[Former Member]

When was the last time basis did a database re-org?

Rob

[HermannGahm]

Hi,

>

> Someone has some suggestion ? 
> regards

for your inserts,

from ST05 what is the time per record?

from ST04 (SQL Cache) what is the buffer gets and physical reads per record?

the buffergets per record should be close to sum ( Levels of B-Tree + 1) for all your indexes + 1 for your table block. (You can see Levels of B-Tree in ST5 in the index statistics in ST05).

If this figure is considerably higher you have to get more details e.g. with extended sql trace (event 10046 level 😎 on DB level, in order to find out where the time is spent... . Ask your database administrator for help then.

Generally Speaking: Archiving is a good idea for constantly growing tables. In case of fragmentation reorganization is a good idea as well. However, regarding INSERTS i haven't seen problems so far in respect to big (non archived) or fragmented tables, I only remember problems with SELECTS and UPDATES.

Kind regards,

Hermann