R3szchk and MaxDBs "filedirectory"

[Former Member]

A 1.9 TB database (Linux SLES 10 SP1, 7.6.04.10) was copied to another system. When an heterogeneous export is started directly after the copy (of course after having updated system tables) R3szchk runs for more than four days to estimate the table sizes.

When I execute "check database with update" before I start the export, R3szchk needs only a bit more than hour to do the same (even after restarting the database).

Two questions arise here:

- why is the "filedirectory" (which is apprently accessed by R3szchk) not updated during the restore from backup?

- Is there any other way of updating the file directory but doing a check data with update in admin mode?

Markus

[lbreddemann · Accepted solution]

> Two questions arise here:

>

> - why is the "filedirectory" (which is apprently accessed by R3szchk) not updated during the restore from backup?

>

> - Is there any other way of updating the file directory but doing a check data with update in admin mode?

>

Hi Markus,

during the backup/restore the content of the pages is not examined. The pages are treated as data containers in the converter, regardless of what is actually in them.

Thus the information necessary for the filedirectory counter update is just not available then.

Usally the filedirectory counters should be updated automatically in the background. Anyhow, for the initial load of the filedirectory counters after an upgrade to 7.6 an select count(*) has to be performed on all tables once.

The procedure that does this is designed in a manner that it stops the counting of rows as soon as another process want to get a lock for a row in the current table.

For large tables this can lead to situations where the select count(*) never runs through after the upgrade to 7.6.

To avoid this the CHECK DATA in ADMIN mode performs the initial row-counting as well.

Since this problem only occurs for tables that have been created before the upgrade to MaxDB 7.6 only those upgraded databases may need to have a CHECK DATA in ADMIN mode done.

I hope that answers your questions.

The problem with this initial count(*) is, that the table has to be locked during the count for a consistent read. This is not something you want to have while SAP R/3 (or any other application ) is up and running as it will lead to lock-wait situations as soon as the table should be accessed.

Basically you can currently choose when you will have to wait until all counting is done - not if.

KR Lars

[markus_doehr2 · Accepted solution]

Hi Lars,

thanx very much for that explanation.

> Since this problem only occurs for tables that have been created before the upgrade to MaxDB 7.6 only those upgraded databases may need to have a CHECK DATA in ADMIN mode done.

Well - ALL our tables have been created before 7.6 (basically most of them with ADABAS 3.x and then 6.1.x). Can that activity be "seen" somehow (x_cons) or is that something that is totally invisible?

Our database was upgraded to 7.6 at 23.12.2006 (7.6.00.35). I would assume that all tables were touched then at least once. Can I somehow check if this is true? I mean, is there a possibility to check which tables have not yet been updated in the filedirectory?

> Basically you can currently choose when you will have to wait until all counting is done - not if.

Years later... )

Markus

[lbreddemann · Accepted solution]

Hi Markus,

you can check for which tables the filecounterentries are missing via:

select * from sysupdatecounterwanted

I totally forgot: there is a way to force the collection of the filecounters for single tables:

check table <tablename> with share lock

You can also restart the automatic collection with:

db_execute check data as per system table

For more information you may want to check the Wiki page for this: [Internal File Size Information |https://wiki.sdn.sap.com/wiki/x/Tj8]

KR Lars