Cristi, sadly you're right. The value I've had in mind has now reduced to zero and
still no end to the validation process. Is there really no indicator in regards to how many entities have to be validated and have already been validated - on a MySQL basis? My event table has 88 million records, is this the number the key_reads status' value will have to reach until this mess comes to an end since ArchMgr possibly checks every single entry in every table? Freundliche Grüße / Best regards Christian Fieres Mainova AG Planung und Betrieb Infrastruktur (M3-ON2) Service Operation Center Solmsstraße 38 60623 Frankfurt Telefon / Phone (069) 2 13-2 36 17 Mobil / Mobile (0170) 5 60 15 63 Telefax / Facsimile (069) 2 13-9 62 36 17 E-Mail [email protected] ----- Weitergeleitet von Christian Fieres/M3-ON/MAINOVA/DE am 08.01.2013 14:42 ----- Von: Cristi Mitrana <[email protected]> An: "spectrum" <[email protected]>, Datum: 08.01.2013 14:40 Betreff: Re: [spectrum] Another thought: Long ArchMgr start with huge DDM DB Hi @ all again, one final thought while my ArchMgr still validates its database: I have compared my MySQL Status output with a running SPECTRUM installation with DDM up and doing what it should. I have seen that on my new machine there is a "key_blocks_unused" counter constantly decreasing while the "key_rad" parameter is growing: mysql> show STATUS LIKE "%key%"; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | Com_assign_to_keycache | 0 | | Com_preload_keys | 0 | | Com_show_keys | 0 | | Handler_read_key | 0 | | Key_blocks_not_flushed | 0 | | Key_blocks_unused | 220989 | <--- | Key_blocks_used | 8565 | | Key_read_requests | 8565 | | Key_reads | 8565 | | Key_write_requests | 0 | | Key_writes | 0 | +------------------------+--------+ 11 rows in set (0,00 sec) In my running DDM environment, this counter is zero: mysql> show STATUS LIKE "%key%"; +------------------------+------------+ | Variable_name | Value | +------------------------+------------+ | Com_assign_to_keycache | 0 | | Com_preload_keys | 0 | | Com_show_keys | 0 | | Handler_read_key | 0 | | Key_blocks_not_flushed | 222 | | Key_blocks_unused | 0 | <----- | Key_blocks_used | 7170 | | Key_read_requests | 2465816151 | | Key_reads | 18893015 | | Key_write_requests | 412673691 | | Key_writes | 79520576 | +------------------------+------------+ 11 rows in set (0,00 sec) Could it be that this is my indicator when to expect an end to this mess? The zero value in the running DDM means the key cache is exhausted. See http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html#statvar _Key_blocks_unused . Basically, key_blocks_unused + key_blocks_used would equal the key cache configured. Comparing the 2 tables, the running DDM has used 7170 blocks and the key cache has peaked, the other DDM (which I assume is the one running the recovery checks) has used 8565 blocks and still has to spare - it's not using too much of the 'key_cache' at the moment. I wouldn't say that key_blocks_unused decreasing would mean anything when the system is running the checks. regards, -- Cristi Mitrana --To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected] Mainova Aktiengesellschaft Solmsstraße 38 D-60623 Frankfurt am Main Vorsitzende des Aufsichtsrates: Dr. h. c. Petra Roth, Oberbürgermeisterin a. D. Vorstand: Dr. Constantin H. Alsheimer (Vorsitzender), Dr. Peter Birkner, Lothar Herbst, Dr. Marie-Luise Wolff-Hertwig Sitz der Aktiengesellschaft: Frankfurt am Main Amtsgericht Frankfurt HRB 7173 USt-ID-Nr. DE 114184034 Mainova steht für besten Service, faire Verträge und top Preise für Ihre Energie - mit Auszeichnung! Mehr Infos unter: http://www.mainova.de/auszeichnung --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
