Full Proof way to determine if ontape is restoring

Hey sorry for this basic question. IDS 9.4 databases. When I run ontape -r I tend to execute onstat -D to monitor it's execution in that you can see the "page Wr" (number of paqes written) increase as a way to determine that the ontape is actually really doing anything. Does anyone known of any other real time queries/checks soneone can perform? This becomes necessary when restores take longer than usual for whatever reason. Thanks

Onstat -D or onstat -g iof are the only ways to monitor the progress of a restore, unfortunately. Art S. Kagel Oninit On Mon, May 12, 2008 at 3:47 PM, WILL LANDSTROM <willlandstrom@yahoo.com> wrote: > Hey sorry for this basic question. IDS 9.4 databases. When I run ontape -r > I > tend to execute onstat -D to monitor it's execution in that you can see > the > "page Wr" (number of paqes written) increase as a way to determine that > the > ontape is actually really doing anything. Does anyone known of any other > real > time queries/checks soneone can perform? This becomes necessary when > restores > take longer than usual for whatever reason. > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Thanks Art. There are actually a few I/O chunk is inconsistemt chunk messages in the online.log. However these may be due to the fact that I ran an oncheck -pr during the ontape -r just to see what I could find. Do these messages necessarily indicate a real problem? Or is it one of those "let the restore finish" and check the database after it is done situations? I probably should not have run the oncheck but it only reads/checks and should not done any harm, at least I believe that is true. Thanks for your response.

During the restore all of your chunks are marked inconsistent in the chunk table on disk and in memory until the logical log restore, if any, completes and you have brought the engine fully online to complete the fast recovery rollforward/rollback process. (In fact, if you shutdown the instance after a restore before bringing the engine fully online, all chunks will be marked inconsistent when you try to bring the engine back online again.) So, this is probably expected behavior. I wouldn't even run the onchecks again after the restore, just run an onstat -d and see what the chunk status is at that point. Art S. Kagel Oninit On Mon, May 12, 2008 at 3:58 PM, WILL LANDSTROM <willlandstrom@yahoo.com> wrote: > Thanks Art. There are actually a few I/O chunk is inconsistemt chunk > messages > in the online.log. However these may be due to the fact that I ran an > oncheck> -pr during the ontape -r just to see what I could find. Do these messages > necessarily indicate a real problem? Or is it one of those "let the > restore > finish" and check the database after it is done situations? I probably > should > not have run the oncheck but it only reads/checks and should not done any > harm, at least I believe that is true. Thanks for your response. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Art. Thanks for the useful info. Very helpful

Hey has anyone seen during an ontape -r that the status on the system CHPT REQ for the past 4 hours> Anyone see this?

On 12/05/2008, Art Kagel <art.kagel@gmail.com> wrote: > Onstat -D or onstat -g iof are the only ways to monitor the progress of a > restore, unfortunately. > > Art S. Kagel > Oninit > > On Mon, May 12, 2008 at 3:47 PM, WILL LANDSTROM <willlandstrom@yahoo.com> > wrote: > > > Hey sorry for this basic question. IDS 9.4 databases. When I run ontape -r > > I > > tend to execute onstat -D to monitor it's execution in that you can see > > the > > "page Wr" (number of paqes written) increase as a way to determine that > > the > > ontape is actually really doing anything. Does anyone known of any other > > real > > time queries/checks soneone can perform? This becomes necessary when > > restores > > take longer than usual for whatever reason. > > > > Thanks > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > onstat -g arc is also quite useful as it shows the progrss through each dbspace Keith