Onbar - URGENT!!!
The problem is that we are trying to restore
database but we have not enough space to restore all storage spaces of the
instance, but we have enough to restore rootdbs, phyldbs, logsdbs and
docubpudbs where the entire database "bpu" is contained to recover some tables
deleted accidentally.
I performed the following:
1- copy the original oncfg_dbserver_shm.0
2- copy the original ixbar.0
3- wirte the log_number until we want to recover on the ixbar.0
4- make the links (to raw devices) only for criticals dbspaces and for
docubpudbs
5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
6- onbar -r -l
On this scenario all worked fine, but the onbar -r -l didn't stop on the log
number specified on ixbar.0 and recover the database up to now, so I couldnt
recover the tables.
As the previus didn't work, I tried the following:
1- same scenario
2- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
3- onbar -r -l -n lognumber
But this opcion "n" is invalid for a not entire instance recover so this
convination didn't work
Finally I also tried:
1- make the links for the criticals dbspaces and for docubpudbs
2- make all the others links to /dev/null
3- run onbar -r -n lognumber
Thats run fine on the beggining, but when it tried to restore the first
dbspace direct to /dev/null, the onbar hunged with the following error:
"unable to start the storage specified errno=0 will not fit in the space
specified on the bar_act.log
On the online.log there are no messeges. I have to killed the onbar and the
instance.
On the other hand, I was wondering if we can do the following:
1- copy the original oncfg_dbserver_shm.0
2- copy the original ixbar.0
3- wirte the log_number until we want to recover on the ixbar.0
4- make the links (to raw devices) only for criticals dbspaces and to
docubpudbs
5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
6- onbar -r -l
7- kill the onbar when is applying the last lognumber that I want
8- If the instance don't start up nicely, anybody knows a way to clean the
inconsistances of the failed log applied?
Does anyone have any other ideas that might help?
Thanks
Viviana
Seems
that you have tried all possibility.
Personnaly, I would restore the whole database on the same system or
another and then extract the data.
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of VIVIANA GOMEZ
Sent: Sunday, October 23, 2005 12:41 PM
To: ids@iiug.org
Subject: Onbar - URGENT!!! [5884]
The problem is that we are trying to restore database but we have not
enough space to restore all storage spaces of the instance, but we have
enough to restore rootdbs, phyldbs, logsdbs and docubpudbs where the
entire database "bpu" is contained to recover some tables deleted
accidentally.
I performed the following:
1- copy the original oncfg_dbserver_shm.0
2- copy the original ixbar.0
3- wirte the log_number until we want to recover on the ixbar.0
4- make the links (to raw devices) only for criticals dbspaces and for
docubpudbs
5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
6- onbar -r -l
On this scenario all worked fine, but the onbar -r -l didn't stop on the
log number specified on ixbar.0 and recover the database up to now, so I
couldnt recover the tables.
As the previus didn't work, I tried the following:
1- same scenario
2- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
3- onbar -r -l -n lognumber
But this opcion "n" is invalid for a not entire instance recover so this
convination didn't work
Finally I also tried:
1- make the links for the criticals dbspaces and for docubpudbs
2- make all the others links to /dev/null
3- run onbar -r -n lognumber
Thats run fine on the beggining, but when it tried to restore the first
dbspace direct to /dev/null, the onbar hunged with the following error:
"unable to start the storage specified errno=0 will not fit in the space
specified on the bar_act.log On the online.log there are no messeges. I
have to killed the onbar and the instance.
On the other hand, I was wondering if we can do the following:
1- copy the original oncfg_dbserver_shm.0
2- copy the original ixbar.0
3- wirte the log_number until we want to recover on the ixbar.0
4- make the links (to raw devices) only for criticals dbspaces and to
docubpudbs
5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
6- onbar -r -l
7- kill the onbar when is applying the last lognumber that I want
8- If the instance don't start up nicely, anybody knows a way to clean
the inconsistances of the failed log applied?
Does anyone have any other ideas that might help?
Thanks
Viviana
Hi,
one thing left to try, but this is not a supported method.
There are two ways to do this:
a) Get help from IBM Informix Technical Support.
This is what I recommend.
b) Do it yourself. As there are some risks of getting it
wrong I don't really recommend this.
- when you copy the ixbar-file, you introduce a change
in the copied file (not in the original).
For this you have to edit the copied ixbar-file like
the following:
- each entry in the ixbar-file has the storage manager
object id encoded (usually in two fields, upper and
lower part of the object id).
- as I don't know your exact version, I can't tell, which
fields these are (field position is subject to change
with different versions). You have to try and match
the object id with info from ON-Bar activity log at
backup time, where the object id is noted (in newer
versions).
- in the file find the entry for the log that's after the last
log you want to restore (e.g. you want to restore up
to and including log 27, find the backup entry for log
28).
- change the object id for this log backup entry (e.g.
for log 28) to some completly incorrect value.
- this incorrect value will cause ON-Bar to stop the
log restore at this point, beacuse it cannot get log 28
from the storage manager with that incorrect object id.
- now do the restore.
- ON-Bar will exit with according messages in ON-Bar
activity log and the server will be in a state called
"logical log restore suspended".
- to get the server out of this "logical log restore
suspended" state, you can try to do "onmode -m" or
do "ontape -l" with an existing, but empty LTAPEDEV
device. ontape will then ask if you have another tape to
restore (as the current one is not OK - it's empty).
Answer this prompt for more tapes with "No".
Then ontape will bring the server to quiescent mode.
- With the server in quiescent mode do a normal
"onmode -m".
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
forum.subscriber@iiug.org wrote on 10/23/2005 10:42:30 PM:
> Seems that you have tried all possibility.
>
> Personnaly, I would restore the whole database on the same system or
> another and then extract the data.
>
> -----Original Message-----
> From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
> Behalf Of VIVIANA GOMEZ
> Sent: Sunday, October 23, 2005 12:41 PM
> To: ids@iiug.org
> Subject: Onbar - URGENT!!! [5884]
>
> The problem is that we are trying to restore database but we have not
> enough space to restore all storage spaces of the instance, but we have
> enough to restore rootdbs, phyldbs, logsdbs and docubpudbs where the
> entire database "bpu" is contained to recover some tables deleted
> accidentally.
>
> I performed the following:
> 1- copy the original oncfg_dbserver_shm.0
> 2- copy the original ixbar.0
> 3- wirte the log_number until we want to recover on the ixbar.0
> 4- make the links (to raw devices) only for criticals dbspaces and for
> docubpudbs
> 5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
> 6- onbar -r -l
>
> On this scenario all worked fine, but the onbar -r -l didn't stop on the
> log number specified on ixbar.0 and recover the database up to now, so I
> couldnt recover the tables.
>
> As the previus didn't work, I tried the following:
> 1- same scenario
> 2- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
> 3- onbar -r -l -n lognumber
> But this opcion "n" is invalid for a not entire instance recover so this
> convination didn't work
>
> Finally I also tried:
> 1- make the links for the criticals dbspaces and for docubpudbs
> 2- make all the others links to /dev/null
> 3- run onbar -r -n lognumber
>
> Thats run fine on the beggining, but when it tried to restore the first
> dbspace direct to /dev/null, the onbar hunged with the following error:
> "unable to start the storage specified errno=0 will not fit in the space
> specified on the bar_act.log On the online.log there are no messeges. I
> have to killed the onbar and the instance.
>
>
> On the other hand, I was wondering if we can do the following:
> 1- copy the original oncfg_dbserver_shm.0
> 2- copy the original ixbar.0
> 3- wirte the log_number until we want to recover on the ixbar.0
> 4- make the links (to raw devices) only for criticals dbspaces and to
> docubpudbs
> 5- onbar -r -p rootdbs phyldbs logsdbs docubpudbs
> 6- onbar -r -l
> 7- kill the onbar when is applying the last lognumber that I want
> 8- If the instance don't start up nicely, anybody knows a way to clean
> the inconsistances of the failed log applied?
>
> Does anyone have any other ideas that might help?
> Thanks
> Viviana