Ontape restore questions? certainly I am missing some thing!

I performed a level 0 backup, using ontape, with the following parameters in the oncofig file. TAPEDEV /dev/rmt/0 # TAPEBLK 16 # TAPESIZE 22000000 ## Log Archive Tape Device LTAPEDEV /dev/null LTAPEBLK 16 # LTAPESIZE 1024000 # As you notice we do not archive the Log (/dev/null for LTAPEDEV ) since all our inserts and updates to the database are batch loads type. I tried to restore one chunk from the tape using 'ontape -r - D my_chunk'. First I answered 'y' to the question: 'Do you want to restore log tapes? (y/n) y'. but the restore failed because of invalid /dev/null; then I answered 'n' to the same question and the restore terminated with no error; but when I tried to access one database that resides in that chunk I realize that my chunk becomes inconsistent and was marked with 'PI-' flag when I run onstat -d. My questions are: 1 - Why do I need to restore the log tapes since the LTAPEDEV is directed to /dev/null; I just need a physical backup of the chunk I archived? 2 - A level 0 archive is not suppose to back up the log? I changed LTAPEDEV to /dev/rmt/0 and I loaded the same tape and I tried to restore the chunk but it didn't work. The system kept asking me to load an other tape over and over, it is like it did not find the log to be restored and end with the following message "Unexpected end of log tape (errno 0), continuing... "; 3 - Finally how I can get out from this mess without calling Informix support? can I perform, now after 2 weeks, a log backup and use it to restore the chunk. Thanks a lot for any clarification. Sent via Deja.com http://www.deja.com/ Before you buy.

With ontape and OnBar, you can always restore the WHOLE system without needing the logical logs. Then the system is restored to appear as it was at the start of the backup. When you wish to restore only one dbspace, Informix MUST process the logical logs to bring the dbspace up to current values. You cannot restore a single dbspace to a previous (in-time) position. This is done to prevent data inconsistencies. So, since you are not saving your logical logs, your only option is to restore the entire instance to 'start of backup'. Maybe you should consider saving the logical logs???? HTH, Doug <dankami@my-deja.com> wrote in message news:8nribf$jen$1@nnrp1.deja.com... > I performed a level 0 backup, using ontape, with the following > parameters in the oncofig file. > > TAPEDEV /dev/rmt/0 # > TAPEBLK 16 # > TAPESIZE 22000000 #> # Log Archive Tape Device > LTAPEDEV /dev/null > LTAPEBLK 16 # > LTAPESIZE 1024000 #> > > As you notice we do not archive the Log (/dev/null for LTAPEDEV ) > since all our inserts and updates to the database are batch loads type. > > I tried to restore one chunk from the tape using 'ontape -r - D > my_chunk'. > First I answered 'y' to the question: 'Do you want to restore log > tapes? (y/n) y'. but the restore failed because of invalid /dev/null; > then I answered 'n' to the same question and the restore terminated > with no error; but when I tried to access one database that resides in > that chunk I realize that my chunk becomes inconsistent and was marked > with 'PI-' flag when I run onstat -d. > > My questions are: > > 1 - Why do I need to restore the log tapes since the LTAPEDEV is > directed to /dev/null; I just need a physical backup of the chunk I > archived? > > 2 - A level 0 archive is not suppose to back up the log? > I changed LTAPEDEV to /dev/rmt/0 and I loaded the same tape and I > tried to restore the chunk but it didn't work. The system kept asking > me to load an other tape over and over, it is like it did not find the > log to be restored and end with the following message "Unexpected end > of log tape (errno 0), continuing... "; > > 3 - Finally how I can get out from this mess without calling Informix > support? can I perform, now after 2 weeks, a log backup and use it > to restore the chunk. > > > Thanks a lot for any clarification. > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.

You can call Informix support and ask for the 'Down Systems Department' < or something like that>. If the Informix engineer can log into your system via a modem he/she can change the db/sb 'state' flags. The idea is to 'markup the chunk' then the engine can 'accept' the dbspace as a viable resource. Unfortunately, customers are not allowed to use the utility to get them out of the bind. It 'tricks' the engine. Lee <dankami@my-deja.com> wrote in message news:8nribf$jen$1@nnrp1.deja.com... > I performed a level 0 backup, using ontape, with the following > parameters in the oncofig file. > > TAPEDEV /dev/rmt/0 # > TAPEBLK 16 # > TAPESIZE 22000000 #> # Log Archive Tape Device > LTAPEDEV /dev/null > LTAPEBLK 16 # > LTAPESIZE 1024000 #> > > As you notice we do not archive the Log (/dev/null for LTAPEDEV ) > since all our inserts and updates to the database are batch loads type. > > I tried to restore one chunk from the tape using 'ontape -r - D > my_chunk'. > First I answered 'y' to the question: 'Do you want to restore log > tapes? (y/n) y'. but the restore failed because of invalid /dev/null; > then I answered 'n' to the same question and the restore terminated > with no error; but when I tried to access one database that resides in > that chunk I realize that my chunk becomes inconsistent and was marked > with 'PI-' flag when I run onstat -d. > > My questions are: > > 1 - Why do I need to restore the log tapes since the LTAPEDEV is > directed to /dev/null; I just need a physical backup of the chunk I > archived? > > 2 - A level 0 archive is not suppose to back up the log? > I changed LTAPEDEV to /dev/rmt/0 and I loaded the same tape and I > tried to restore the chunk but it didn't work. The system kept asking > me to load an other tape over and over, it is like it did not find the > log to be restored and end with the following message "Unexpected end > of log tape (errno 0), continuing... "; > > 3 - Finally how I can get out from this mess without calling Informix > support? can I perform, now after 2 weeks, a log backup and use it > to restore the chunk. > > > Thanks a lot for any clarification. > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. >