Re: IDS 7.2 - Buffer modified in inconsistent chun

Hi Art, Thanks for your suggestion. We have a RAID system where chunk resides in and its RAID monitoring system does not receive any alert/event from the device. Therefore, we suspect the failure of dbspace initializaion was caused by data corruption. We learned a great deal about how to execute full system restore from existing archives and logs. We set LTAPEDEV as /dev/null, meaning that we have no logical log files. We take backup daily using "ontape -s -L 0", thus the loss of latest transactions are minimal. We see "buffer modified in inconsistent chunk" in the log, which means that one of critical dbspaces was damaged, which requires full system restore using cold restore approach. Here, we have following concerns that I would like solicit your insight. 1. As the disk is considered healthy, we think what we need to do is disk space initialization. Can we just invoke "oninit -s" without changing OnLine configuration? In other words, we don't have to save all shared memory/chunk config, copy them over to a new OnLine instance and reconstruct everything from scratch. 2. We are not sure which configuration data needs to be saved before "oninit -s" - we only located the dbspace-chunk mapping that would be lost after disk space initialization. Do I understand correct and what else should we keep, if any? 3. We think the following as the rest of restoring actions, ie. reorganize dbspace-chunk mappings, restore the recent archive with "ontape -r" and move recovery mode to OnLine without rollforward as we have no transaction logs. Is there anything I have missed? 4. Anything else I should worry/keep in mind before starting restore attempt? We want to be very careful about performing all of these so we won't lose important information forever. Best regards,

First, just because the RAID subsystem didn't report any errors doesn't mean that the disks are OK. Especially if this is RAID5, but that's your problem. Second, sending logical logs to /dev/null doesn't mean that transaction loss is minimal, it is maximal. You will have lost every transaction that was committed to the server since the beginning of the last archive if you are discarding your logical logs. Not a good thing at all! But again your problem, not mine. Third, you don't have to save anything and there is no reason to perform an oninit -i at all. Just mount the last archive tapes/files and run ontape -rto restore. After answering appropriately to the prompts for level 1 archives and restoring logical logs, run onmode -m to bring the engine to full online mode before shutting down the engine (or just leave it online). If you shutdown the engine after the restore before it comes to full online mode and completes fast recovery, the chunks will all be marked offline and the engine will not restart. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Aug 11, 2009 at 4:04 AM, YAS ONO <yohelpdeskjp@gmail.com> wrote: > Hi Art, > > Thanks for your suggestion. We have a RAID system where chunk resides in > and > its RAID monitoring system does not receive any alert/event from the > device. > Therefore, we suspect the failure of dbspace initializaion was caused by > data > corruption. > > We learned a great deal about how to execute full system restore from > existing > archives and logs. We set LTAPEDEV as /dev/null, meaning that we have no > logical log files. We take backup daily using "ontape -s -L 0", thus the > loss > of latest transactions are minimal. > > We see "buffer modified in inconsistent chunk" in the log, which means that > one of critical dbspaces was damaged, which requires full system restore > using > cold restore approach. Here, we have following concerns that I would like > solicit your insight. > > 1. As the disk is considered healthy, we think what we need to do is disk > space initialization. Can we just invoke "oninit -s" without changing > OnLine > configuration? In other words, we don't have to save all shared > memory/chunk > config, copy them over to a new OnLine instance and reconstruct everything > from scratch. > 2. We are not sure which configuration data needs to be saved before > "oninit > -s" - we only located the dbspace-chunk mapping that would be lost after > disk > space initialization. Do I understand correct and what else should we keep, > if > any? > 3. We think the following as the rest of restoring actions, ie. reorganize > dbspace-chunk mappings, restore the recent archive with "ontape -r" and > move > recovery mode to OnLine without rollforward as we have no transaction logs. > Is > there anything I have missed? > 4. Anything else I should worry/keep in mind before starting restore > attempt? > > We want to be very careful about performing all of these so we won't lose > important information forever. > > Best regards, > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5ab5b8039c40470d945d4

Hi Art, Thanks for your amazingly quick reply. We on our end are all for the importance of logical logs management and current practice is not good. We will reconfigure the database to enable it once we have restored the system. I am happy to hear that "oninit -i" is not requred and "ontape -r" will do. I understood we answer prompts appropriately regarding level 1 archives and logical logs as we have neither of them, followed by invoking "onmode -m". It sounds simple and straightforward. I will learn more about each of the utilities further with admin and archive/backup guides. Hoping that all details will make more sense now. Again, thank you for all your support - you have saved my hours.

Hi Art, Good news, we could restore the system successfully using "ontape -r". Will move onto the discussion on logical log archive. Thanks a lot!

Great! Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Aug 12, 2009 at 12:55 AM, YAS ONO <yohelpdeskjp@gmail.com> wrote: > Hi Art, > > Good news, we could restore the system successfully using "ontape -r". Will > move onto the discussion on logical log archive. Thanks a lot! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5b43b201d140470ebd9a9