Table SUBSDATEM

[stancu_adi]

Hello guys,

Do you know what is for the table SUBDATEM? I have an incident 1542 as usr3 exceeded 93% and after i checked /usr3/mao i found this table for which the idx table is quite big:
(1101)xa011001> ll -h -S | grep SUB
-rw-r--r-- 1 mtcl tel 619M Mar 16 10:55 SUBSDATEM.idx
-rw-r--r-- 1 mtcl tel 500K Mar 16 10:55 SUBSDATEM.dat


BR,

Adrian

[sadim]

That table, as far as i know, it gathers the timestamp of the last modification of the objects (users, pilots,...).
Are you sure that this is the file that is trigering the incident. Normally that incident indicates a partition, not a directory.
I have already seen this incident on old OXE versions and it was due the quantity (not the individual size) of files related to the logrotate incident mechanism.
Can you show the detailed incident?

Regards

[tgn]

i've checked crossover with another installation.
partition which is mounted to /usr3 is 985MB big. 151MB are used. the index file SUBSDATEM.idx is only 133kB big. so i assume your index file is not ok. try to rebuild it with fichges and the option to rebuild index (but use with care and only if you know what it will do).

regards...


--- back to basics... focus your eyes on the essential things... ---

[sadim]

Sorry, i miss that the big file is the .idx and not the .dat file. So tgn is must probably right.

Regards

[stancu_adi]

Hi guys,

Thanks for answers.
Indeed it's not normal that this index file to be so big and it was the cause of 1542 incident.
I use fichges recover subsdate command (rebuild only index file) and then everything was OK as should be:

(1101)xb011001> ll -h | grep SUBSDATE
-rw-r--r-- 1 mtcl tel 500K Mar 17 19:12 SUBSDATEM.dat
-rw-rw-r-- 1 mtcl tel 585K Mar 17 19:12 SUBSDATEM.idx

The values in dat file were OK as i could dump the records...so i suppose that only queries with condition would not work so well
After this a mastercopy and it's OK.

BR

Adrian