Table buffering - Invalidations vs Changes on ST10

[Former Member]

Hello experts,

Could you please let us know what is the difference between the number of "Invalidations" and the number of "Changes" that are registered via ST10 transactions for each table?

We are interested to identify which tables should be unbuffered considering that these metrics hopefully could help us to take a decision, we would like to know what is the basic difference between each of them.

Thanks and best regards,

[HermannGahm]

Hi Rodolfo,

interesting questions:

A change is a DML statement (INSERT, UPDATE, DELET, MODIFY).

A invalidation is flagging an entry (line, region, table) in the table buffer as invalid

because it has been changed.

I suggest to create you own tables (sng, gen, ful), buffer them and run some tests.

I don't know each and every detail since i didn't tested everything here but here are some of my observations.

A change is counted in the DBI and is a (one) change statement. e.g.

INSERT from wa = 1 change

This will lead to 1 invaldiation PER REMOTE APPLICATION SERVER (the local one is updated with the change hence has no invalidation).

As far as i know array statements are counted as a (one) change as well like:

INSERT ... from TABLE

One change would be the UPDATE SET ... .

These statements let to many invalidations in my test (nr. of records / regions to be changed multiplied with the nr. of remote application servers).

To make it more complicated:

we can have invalidations and no changes since:

R3trans or tp might change buffered tables (do invalidations) but record no change in the DBI.

or

if a projection view is changed the change is recorded in the DBI against the view but the the underlying tables

get invalidations as well (like the view) on the remote application servers.

Kind regards,

Hermann

[Former Member]

OK Hermann,

Thank you very much for your detailed explanation, so as I understood one change doesn't necessarily mean that you will have an invalidation, there are additional activities that can cause invalidations, so basically you will always find more invalidations that changes and maybe considering the changes could be one measure to determine if a table should be unbuffered or not.

And what about the tables that keep in "error" status on the "Buffer State" from ST10? I have noticed that these tables have a pretty high number of invalidations compared to the number of changes? I must also mention that I have noticed that this pretty high number of invalidations is very close to the number of sequential reads that are registered on the table, what do you think?

Kind regards,

[HermannGahm]

Hi Rodolfo,

a table is set to status error when (1) the table could not be loaded into the buffer because there was no space left AND (2) if the table is BIG.

Now, what is big? In this case big is defined as follows: the size of the table to be buffered (or region) is > 50 % of the size of the table buffer or the size is more than 100 MB (Release <= 4.6D 0,5 MB).

You can find more details on status error in SAP Note 703035. Then number of invalidations as far is i know comes from DDLOG which is written and read in any case (status of the table does not matter).

I have seen cases wehre we got changes but no invalidations. So sometimes the changes can be higher than the invalidations as well. Personally i treat both of these columns like a (one) value for change indication. For analysis i use the method described by Thomas Schneider in his book SAP Performance Tuing. Here you can find a free test chapter about table buffers:

http://www.sap-press.de/download/dateien/259/sap_press_pog_007.pdf

The mentioned sizes for buffered tables (1 MB, 5 MB) are rather low in my opinion. Today i see table buffers in the gigabytes. So whether a table in a table buffer is big, for me, is not a absolut value but rather a percentage of the available space in the buffer e.g. a table is big if it is 5 % of the table buffer or something like that. So the sizes might be a bit outdated, but the general procedure is still ok i think. (at least i haven't seen something better so far).

Kind regards,

Hermann