Warm recover failure question

Attempting to perform a worm restore failed. Three dbspaces in the instance, "rootdbs", "physdbs", and "courts". The databases (30) contained in "courts" are not logged and the log device is set to /dev/null. No mirrors. Because of 'pilot error' we needed to restore from the previous Level 0 backup (and scrap a day's work). We placed the server in quiescent mode and started a 'warm' restore: ontape -r -D courts When the restore completed that server came up into on-line mode but the dbspace "courts" came up into 'Inconsistent' status. All attempts to convince the server that the chunk/dbspace was online failed. To recover, we downed the server and did a full (cold) recovery. At what point did I aim for my foot before I pulled the trigger?

FProse wrote: > > Attempting to perform a worm restore failed. > > Three dbspaces in the instance, "rootdbs", "physdbs", and "courts". > The databases (30) contained in "courts" are not logged and the log > device is set to /dev/null. No mirrors. > > Because of 'pilot error' we needed to restore from the previous Level > 0 backup (and scrap a day's work). We placed the server in quiescent > mode and started a 'warm' restore: > > ontape -r -D courts> > When the restore completed that server came up into on-line mode but > the dbspace "courts" came up into 'Inconsistent' status. All attempts > to convince the server that the chunk/dbspace was online failed. > > To recover, we downed the server and did a full (cold) recovery. > > At what point did I aim for my foot before I pulled the trigger? What you describe usually happens after a restore where no logs are rolled forward, as you had done, and then after the restore one shuts the engine down from quiescent mode instead of taking the engine to on-line mode directly. On restarting the engine the restored dbspace(s) are marked inconsistent. The only solutions are to get tech support to force the chunks to be flagged online or to perform the restore again and this time go to online mode immediately after the restore completes. Be careful to wait for fast recovery to complete all the way if you want to shut the engine down and restart it afterwards or you'll be in the same boat. Art S. Kagel

But LTAPE parameter is '/dev/null'. I think the "Inconsistent Status" is logically right whether the engine is restarted, or not. I think so because the logical recovery cannot make the dbspace up to date.. Am I correct ?? (I'm sorry for poor english :-) "Art S. Kagel" wrote: > FProse wrote: > > > > Attempting to perform a worm restore failed. > > > > Three dbspaces in the instance, "rootdbs", "physdbs", and "courts". > > The databases (30) contained in "courts" are not logged and the log > > device is set to /dev/null. No mirrors. > > > > Because of 'pilot error' we needed to restore from the previous Level > > 0 backup (and scrap a day's work). We placed the server in quiescent > > mode and started a 'warm' restore: > > > > ontape -r -D courts> > > > When the restore completed that server came up into on-line mode but > > the dbspace "courts" came up into 'Inconsistent' status. All attempts > > to convince the server that the chunk/dbspace was online failed. > > > > To recover, we downed the server and did a full (cold) recovery. > > > > At what point did I aim for my foot before I pulled the trigger? > > What you describe usually happens after a restore where no logs are > rolled forward, as you had done, and then after the restore one > shuts the engine down from quiescent mode instead of taking the > engine to on-line mode directly. On restarting the engine the > restored dbspace(s) are marked inconsistent. The only solutions are > to get tech support to force the chunks to be flagged online or to > perform the restore again and this time go to online mode immediately > after the restore completes. Be careful to wait for fast recovery to > complete all the way if you want to shut the engine down and restart > it afterwards or you'll be in the same boat. > > Art S. Kagel