IDS 7.31/SunOS 5.7 ontape restore problem
After a disk failure, the poster recreated cooked chunks/symlinks and tried a cold 'ontape -r' restore on IDS 7.31 under Solaris 7, but it died with "Physical restore failed - restore reserved pages failed". Suggestions included lowering TAPEBLK from 1024 to 256 (a dd test showed 1024K reads were fine) and reviewing the dbspace recreation steps. The actual fix, from Jacques Renaut and Art Kagel, was that ontape needs an auto-rewind tape device: changing TAPEDEV from /dev/rmt/0cbn to /dev/rmt/0cb let the restore complete successfully.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello and Happy 2010!
On Xmas eve 2009 one of the disks on a server that I admin went offline,
taking with it an Informix database that is much missed. First I
re-initialized the database chunks by executing the following:
touch mytest_db1
touch mytest_db2
touch mytest_db3
chmod 660 mydb*
onspaces -c -d mytestdb -p /mytest_db1 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db2 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db3 -o 0 -s 2000000
I made sure that the chunk size matched the chunk size of the missing
chunks (2 GB). I've read some posts on the net that say that one need
not create the chunks, merely touch the files and set the correct 660
permissions. I didn't know what to believe, so I made the chunks.
Then I snapped the database symlinks for my missing databases (mytestdb)
to above newly created chunks. My understanding is that only the symlink
paths needs to stay the same, not the target to which the links point.
I then attempted cold restoring from the last known good 8mm Exabyte tape
backup
for our database.
mt -f /dev/rmt/0cbn rewind
onmode -yuck
ontape -r
Archive Tape Information
Tape type: Archive Backup Tape
Online version: Informix Dynamic Server Version 7.31.UC4
Archive date: Wed Jun 27 12:31:22 2007
User id: informix
Terminal id: /dev/pts/4
Archive level: 0
Tape device: /dev/rmt/0cbn
Tape blocksize (in k): 1024
Tape size (in k): 138240000
Tape number in series: 1
Spaces to restore:1 [rootdbs ]
2 [livedb ]
3 [testdb ]
4 [traindb ]
5 [llogdbs ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
Initialization Time 10/25/2003 00:28:45
System Page Size 2048
Version 6
Archive CheckPoint Time 06/27/2007 12:31:26
paces
number flags fchunk nchunks flags owner name
1 1 1 1 N informix rootdbs
2 1 2 16 N informix mydb
5 1 5 1 N informix llogdbs
6 2001 6 1 N T informix tempdb
7 2001 7 1 N T informix tempdb2
8 2001 26 1 N T informix tempdb3
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 400000 333479 PO- /dblnk/live/my_root
2 2 0 1000000 13 PO- /dblnk/live/my_db1
3 3 0 1000000 13 PO- /dblnk/test/mytest_db1
4 4 0 1000000 65217 PO- /dblnk/train/mytrain_db1
5 5 0 700100 47 PO- /dblnk/llog/my_llogs
6 6 0 500000 499497 PO- /dblnk/live/my_temp1
7 7 0 500000 499497 PO- /dblnk/live/my_temp2
8 2 0 1000000 395348 PO- /dblnk/live/my_db2
9 2 0 1000000 15 PO- /dblnk/live/my_db3
10 2 0 1000000 3 PO- /dblnk/live/my_db4
11 2 0 1000000 59 PO- /dblnk/live/my_db5
12 2 0 1000000 8 PO- /dblnk/live/my_db6
13 4 0 1000000 869947 PO- /dblnk/train/mytrain_db2
14 2 0 1000000 79371 PO- /dblnk/live/my_db7
15 2 0 1000000 3 PO- /dblnk/live/my_db8
16 2 0 1000000 6 PO- /dblnk/live/my_db9
17 2 0 1000000 2711 PO- /dblnk/live/my_db10
18 2 0 1000000 550379 PO- /dblnk/live/my_db11
19 2 0 1000000 24997 PO- /dblnk/live/my_db12
20 2 0 1000000 24997 PO- /dblnk/live/my_db13
21 4 0 500000 499997 PO- /dblnk/train/mytrain_db3
22 2 0 1000000 399997 PO- /dblnk/live/my_db14
23 2 0 1000000 999997 PO- /dblnk/live/my_db15
24 2 0 1000000 999997 PO- /dblnk/live/my_db16
25 3 0 1000000 11483 PO- /dblnk/test/mytest_db2
26 8 0 500000 499497 PO- /dblnk/live/my_temp3
27 3 0 1000000 834997 PO- /dblnk/test/mytest_db3
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - restore reserved pages failed
Program over.
When I Googled the above error message, the advice that I read said to
make sure the TAPE blocksize was set correctly using either mt and/or the
onconfig file. mt on SunOS 5.7 doesn't support setting the blocksize
as far as I could determine from it's arcane manpage and the onconfig
file that ontape uses has the correct blocksize (1024K) and total tape
size (138,240,000K). Another post I read said to make sure that the
path to the symlinks that point to the chunks had not changed name.
I made doubly sure of this.
Any further insights as to what I can do to make this `go' would be
much appreciated.
TIA,
Marshall
Some older UNIX systems do not actually support tape block sizes larger than
256K though they will accept a larger block size, however, under the hood
the drivers are actually writing 4 256K blocks not one 1024K block. At
restore time, the logical tape subsystem reports the actual block size when
ontape queries it with fstat(), discovers the discrepancy, and aborts. You
would never know if you don't ever test your restores. Try setting
TAPEBLOCK to 256 instead of 1024 and see if that fixes the problem.
Art
Art S. Kagel
AdvanceDataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
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, Jan 6, 2010 at 2:26 PM, MARSHALL HAHN-TAYLOR <
marshall_hahn-taylor@canb.uscourts.gov> wrote:
> Hello and Happy 2010!
>
> On Xmas eve 2009 one of the disks on a server that I admin went offline,
> taking with it an Informix database that is much missed. First I
> re-initialized the database chunks by executing the following:
>
> touch mytest_db1
> touch mytest_db2
> touch mytest_db3
> chmod 660 mydb*
> onspaces -c -d mytestdb -p /mytest_db1 -o 0 -s 2000000
> onspaces -a mytestdb -p /mytest_db2 -o 0 -s 2000000
> onspaces -a mytestdb -p /mytest_db3 -o 0 -s 2000000>
> I made sure that the chunk size matched the chunk size of the missing
> chunks (2 GB). I've read some posts on the net that say that one need
> not create the chunks, merely touch the files and set the correct 660
> permissions. I didn't know what to believe, so I made the chunks.
>
> Then I snapped the database symlinks for my missing databases (mytestdb)
> to above newly created chunks. My understanding is that only the symlink
> paths needs to stay the same, not the target to which the links point.
>
> I then attempted cold restoring from the last known good 8mm Exabyte tape
> backup
> for our database.
>
> mt -f /dev/rmt/0cbn rewind
> onmode -yuck
> ontape -r>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: Informix Dynamic Server Version 7.31.UC4
> Archive date: Wed Jun 27 12:31:22 2007
> User id: informix
> Terminal id: /dev/pts/4
> Archive level: 0
> Tape device: /dev/rmt/0cbn
> Tape blocksize (in k): 1024
> Tape size (in k): 138240000
> Tape number in series: 1
>
> Spaces to restore:1 [rootdbs ]
> 2 [livedb ]
> 3 [testdb ]
> 4 [traindb ]
> 5 [llogdbs ]
>
> Archive Information
>
> Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
> Initialization Time 10/25/2003 00:28:45
> System Page Size 2048
> Version 6
> Archive CheckPoint Time 06/27/2007 12:31:26
> paces
> number flags fchunk nchunks flags owner name
> 1 1 1 1 N informix rootdbs
> 2 1 2 16 N informix mydb
> 5 1 5 1 N informix llogdbs
> 6 2001 6 1 N T informix tempdb
> 7 2001 7 1 N T informix tempdb2
> 8 2001 26 1 N T informix tempdb3
>
> Chunks
> chk/dbs offset size free bpages flags pathname
> 1 1 0 400000 333479 PO- /dblnk/live/my_root
> 2 2 0 1000000 13 PO- /dblnk/live/my_db1
> 3 3 0 1000000 13 PO- /dblnk/test/mytest_db1
> 4 4 0 1000000 65217 PO- /dblnk/train/mytrain_db1
> 5 5 0 700100 47 PO- /dblnk/llog/my_llogs
> 6 6 0 500000 499497 PO- /dblnk/live/my_temp1
> 7 7 0 500000 499497 PO- /dblnk/live/my_temp2
> 8 2 0 1000000 395348 PO- /dblnk/live/my_db2
> 9 2 0 1000000 15 PO- /dblnk/live/my_db3
> 10 2 0 1000000 3 PO- /dblnk/live/my_db4
> 11 2 0 1000000 59 PO- /dblnk/live/my_db5
> 12 2 0 1000000 8 PO- /dblnk/live/my_db6
> 13 4 0 1000000 869947 PO- /dblnk/train/mytrain_db2
> 14 2 0 1000000 79371 PO- /dblnk/live/my_db7
> 15 2 0 1000000 3 PO- /dblnk/live/my_db8
> 16 2 0 1000000 6 PO- /dblnk/live/my_db9
> 17 2 0 1000000 2711 PO- /dblnk/live/my_db10
> 18 2 0 1000000 550379 PO- /dblnk/live/my_db11
> 19 2 0 1000000 24997 PO- /dblnk/live/my_db12
> 20 2 0 1000000 24997 PO- /dblnk/live/my_db13
> 21 4 0 500000 499997 PO- /dblnk/train/mytrain_db3
> 22 2 0 1000000 399997 PO- /dblnk/live/my_db14
> 23 2 0 1000000 999997 PO- /dblnk/live/my_db15
> 24 2 0 1000000 999997 PO- /dblnk/live/my_db16
> 25 3 0 1000000 11483 PO- /dblnk/test/mytest_db2
> 26 8 0 500000 499497 PO- /dblnk/live/my_temp3
> 27 3 0 1000000 834997 PO- /dblnk/test/mytest_db3
>
> Continue restore? (y/n)y
> Do you want to back up the logs? (y/n)n
> Physical restore failed - restore reserved pages failed
>
> Program over.
>
> When I Googled the above error message, the advice that I read said to
> make sure the TAPE blocksize was set correctly using either mt and/or the
> onconfig file. mt on SunOS 5.7 doesn't support setting the blocksize
> as far as I could determine from it's arcane manpage and the onconfig
> file that ontape uses has the correct blocksize (1024K) and total tape
> size (138,240,000K). Another post I read said to make sure that the
> path to the symlinks that point to the chunks had not changed name.
> I made doubly sure of this.
>
> Any further insights as to what I can do to make this `go' would be
> much appreciated.
>
> TIA,
>
> Marshall
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0ce03d0ecc8d14047c84c47a
You wrote:
Hello and Happy 2010!
On Xmas eve 2009 one of the disks on a server that I admin went offline,
taking with it an Informix database that is much missed. First I
re-initialized the database chunks by executing the following:
touch mytest_db1
touch mytest_db2
touch mytest_db3
chmod 660 mydb*
onspaces -c -d mytestdb -p /mytest_db1 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db2 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db3 -o 0 -s 2000000
I made sure that the chunk size matched the chunk size of the missing
chunks (2 GB). I've read some posts on the net that say that one need
not create the chunks, merely touch the files and set the correct 660
permissions. I didn't know what to believe, so I made the chunks.
Then I snapped the database symlinks for my missing databases (mytestdb)
to above newly created chunks. My understanding is that only the symlink
paths needs to stay the same, not the target to which the links point.
I then attempted cold restoring from the last known good 8mm Exabyte tape
backup
for our database.
mt -f /dev/rmt/0cbn rewind
onmode -yuck
ontape -r
Archive Tape Information
Tape type: Archive Backup Tape
Online version: Informix Dynamic Server Version 7.31.UC4
Archive date: Wed Jun 27 12:31:22 2007
User id: informix
Terminal id: /dev/pts/4
Archive level: 0
Tape device: /dev/rmt/0cbn
Tape blocksize (in k): 1024
Tape size (in k): 138240000
Tape number in series: 1
Spaces to restore:1 [rootdbs ]
2 [livedb ]
3 [testdb ]
4 [traindb ]
5 [llogdbs ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
Initialization Time 10/25/2003 00:28:45
System Page Size 2048
Version 6
Archive CheckPoint Time 06/27/2007 12:31:26
paces
number flags fchunk nchunks flags owner name
1 1 1 1 N informix rootdbs
2 1 2 16 N informix mydb
5 1 5 1 N informix llogdbs
6 2001 6 1 N T informix tempdb
7 2001 7 1 N T informix tempdb2
8 2001 26 1 N T informix tempdb3
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 400000 333479 PO- /dblnk/live/my_root
2 2 0 1000000 13 PO- /dblnk/live/my_db1
3 3 0 1000000 13 PO- /dblnk/test/mytest_db1
4 4 0 1000000 65217 PO- /dblnk/train/mytrain_db1
5 5 0 700100 47 PO- /dblnk/llog/my_llogs
6 6 0 500000 499497 PO- /dblnk/live/my_temp1
7 7 0 500000 499497 PO- /dblnk/live/my_temp2
8 2 0 1000000 395348 PO- /dblnk/live/my_db2
9 2 0 1000000 15 PO- /dblnk/live/my_db3
10 2 0 1000000 3 PO- /dblnk/live/my_db4
11 2 0 1000000 59 PO- /dblnk/live/my_db5
12 2 0 1000000 8 PO- /dblnk/live/my_db6
13 4 0 1000000 869947 PO- /dblnk/train/mytrain_db2
14 2 0 1000000 79371 PO- /dblnk/live/my_db7
15 2 0 1000000 3 PO- /dblnk/live/my_db8
16 2 0 1000000 6 PO- /dblnk/live/my_db9
17 2 0 1000000 2711 PO- /dblnk/live/my_db10
18 2 0 1000000 550379 PO- /dblnk/live/my_db11
19 2 0 1000000 24997 PO- /dblnk/live/my_db12
20 2 0 1000000 24997 PO- /dblnk/live/my_db13
21 4 0 500000 499997 PO- /dblnk/train/mytrain_db3
22 2 0 1000000 399997 PO- /dblnk/live/my_db14
23 2 0 1000000 999997 PO- /dblnk/live/my_db15
24 2 0 1000000 999997 PO- /dblnk/live/my_db16
25 3 0 1000000 11483 PO- /dblnk/test/mytest_db2
26 8 0 500000 499497 PO- /dblnk/live/my_temp3
27 3 0 1000000 834997 PO- /dblnk/test/mytest_db3
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - restore reserved pages failed
Program over.
When I Googled the above error message, the advice that I read said to
make sure the TAPE blocksize was set correctly using either mt and/or the
onconfig file. mt on SunOS 5.7 doesn't support setting the blocksize
as far as I could determine from it's arcane manpage and the onconfig
file that ontape uses has the correct blocksize (1024K) and total tape
size (138,240,000K). Another post I read said to make sure that the
path to the symlinks that point to the chunks had not changed name.
I made doubly sure of this.
Any further insights as to what I can do to make this `go' would be
much appreciated.
TIA,
Marshall
-----------------------------------------------------------------------------
I think the problem is simply that you are using a no-rewind device. The
ontape process opens and reads the 1st block to print out the chunks it's
restoring etc...It then closes the device and reopens it. At that point it is
expecting to do it's read and reread the block it used to display that
chunk/dbspace information, and if it's can't, the restore will fail. I think
if you just do the restore with a rewind device it should work.
Jacques Renaut
IBM Informix Advanced Support
APD Team
So in my onconfig file, I should set
TAPEBLK 1024 # Tape block size (Kbytes)
to
TAPEBLK 256 # Tape block size (Kbytes)
right?
I'll try that...
Marshall
Hmmm... our Exabyte drive is a `no rewind' device b/c it automatically rewinds
upon ejection of the tape? Is that what you mean?
I'll try ejecting the tape, re-inserting it, then running `ontape -r' without
first running `mt -f /dev/rmt/0cbn rewind'. Please let me know if that is what
you were prescribing.
Thanks again!
Marshall
Let me recap to make sure I know what you are saying. It looks like your
dbspace and chunks for a database were stored on a hard drive that failed, but
the Informix instance was installed and configured elsewhere. If that is the
case, I am not sure why you added a new dbspace to your instance before the
restore. It appears that you are using "cooked" space for your database. I
understand the process as follows:
Create the files to be used:
touch mytest_db1
touch mytest_db2
touch mytest_db3
chmod 660 mydb*
Create the symbolic links to the files created above. The symbolic links will
look the same name as was used in the database that failed. The only
difference is that they point to a different disk now.
ln -s .......
ln -s .......
ln -s .......
mt -f /dev/rmt/0cbn rewind
onmode -yuck
ontape -r
I am assuming that the links to the root dbspace and the temp dbspaces either
still exist or that they are using the same space referred to above and
everything is together. I am thinking that the error message you received was
misleading.
Larry
> To: ids@iiug.org
> From: jrenaut@us.ibm.com
> Subject: Re: IDS 7.31/SunOS 5.7 ontape restore problem [18575]
> Date: Wed, 6 Jan 2010 15:56:35 -0500
>
> You wrote:
> Hello and Happy 2010!
>
> On Xmas eve 2009 one of the disks on a server that I admin went offline,
> taking with it an Informix database that is much missed. First I
> re-initialized the database chunks by executing the following:
>
> touch mytest_db1
> touch mytest_db2
> touch mytest_db3
> chmod 660 mydb*
> onspaces -c -d mytestdb -p /mytest_db1 -o 0 -s 2000000
> onspaces -a mytestdb -p /mytest_db2 -o 0 -s 2000000
> onspaces -a mytestdb -p /mytest_db3 -o 0 -s 2000000>
> I made sure that the chunk size matched the chunk size of the missing
> chunks (2 GB). I've read some posts on the net that say that one need
> not create the chunks, merely touch the files and set the correct 660
> permissions. I didn't know what to believe, so I made the chunks.
>
> Then I snapped the database symlinks for my missing databases (mytestdb)
> to above newly created chunks. My understanding is that only the symlink
> paths needs to stay the same, not the target to which the links point.
>
> I then attempted cold restoring from the last known good 8mm Exabyte tape
> backup
> for our database.
>
> mt -f /dev/rmt/0cbn rewind
> onmode -yuck
> ontape -r>
> Archive Tape Information
>
> Tape type: Archive Backup Tape
> Online version: Informix Dynamic Server Version 7.31.UC4
> Archive date: Wed Jun 27 12:31:22 2007
> User id: informix
> Terminal id: /dev/pts/4
> Archive level: 0
> Tape device: /dev/rmt/0cbn
> Tape blocksize (in k): 1024
> Tape size (in k): 138240000
> Tape number in series: 1
>
> Spaces to restore:1 [rootdbs ]
> 2 [livedb ]
> 3 [testdb ]
> 4 [traindb ]
> 5 [llogdbs ]
>
> Archive Information
>
> Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
> Initialization Time 10/25/2003 00:28:45
> System Page Size 2048
> Version 6
> Archive CheckPoint Time 06/27/2007 12:31:26
> paces
> number flags fchunk nchunks flags owner name
> 1 1 1 1 N informix rootdbs
> 2 1 2 16 N informix mydb
> 5 1 5 1 N informix llogdbs
> 6 2001 6 1 N T informix tempdb
> 7 2001 7 1 N T informix tempdb2
> 8 2001 26 1 N T informix tempdb3
>
> Chunks
> chk/dbs offset size free bpages flags pathname
> 1 1 0 400000 333479 PO- /dblnk/live/my_root
> 2 2 0 1000000 13 PO- /dblnk/live/my_db1
> 3 3 0 1000000 13 PO- /dblnk/test/mytest_db1
> 4 4 0 1000000 65217 PO- /dblnk/train/mytrain_db1
> 5 5 0 700100 47 PO- /dblnk/llog/my_llogs
> 6 6 0 500000 499497 PO- /dblnk/live/my_temp1
> 7 7 0 500000 499497 PO- /dblnk/live/my_temp2
> 8 2 0 1000000 395348 PO- /dblnk/live/my_db2
> 9 2 0 1000000 15 PO- /dblnk/live/my_db3
> 10 2 0 1000000 3 PO- /dblnk/live/my_db4
> 11 2 0 1000000 59 PO- /dblnk/live/my_db5
> 12 2 0 1000000 8 PO- /dblnk/live/my_db6
> 13 4 0 1000000 869947 PO- /dblnk/train/mytrain_db2
> 14 2 0 1000000 79371 PO- /dblnk/live/my_db7
> 15 2 0 1000000 3 PO- /dblnk/live/my_db8
> 16 2 0 1000000 6 PO- /dblnk/live/my_db9
> 17 2 0 1000000 2711 PO- /dblnk/live/my_db10
> 18 2 0 1000000 550379 PO- /dblnk/live/my_db11
> 19 2 0 1000000 24997 PO- /dblnk/live/my_db12
> 20 2 0 1000000 24997 PO- /dblnk/live/my_db13
> 21 4 0 500000 499997 PO- /dblnk/train/mytrain_db3
> 22 2 0 1000000 399997 PO- /dblnk/live/my_db14
> 23 2 0 1000000 999997 PO- /dblnk/live/my_db15
> 24 2 0 1000000 999997 PO- /dblnk/live/my_db16
> 25 3 0 1000000 11483 PO- /dblnk/test/mytest_db2
> 26 8 0 500000 499497 PO- /dblnk/live/my_temp3
> 27 3 0 1000000 834997 PO- /dblnk/test/mytest_db3
>
> Continue restore? (y/n)y
> Do you want to back up the logs? (y/n)n
> Physical restore failed - restore reserved pages failed
>
> Program over.
>
> When I Googled the above error message, the advice that I read said to
> make sure the TAPE blocksize was set correctly using either mt and/or the
> onconfig file. mt on SunOS 5.7 doesn't support setting the blocksize
> as far as I could determine from it's arcane manpage and the onconfig
> file that ontape uses has the correct blocksize (1024K) and total tape
> size (138,240,000K). Another post I read said to make sure that the
> path to the symlinks that point to the chunks had not changed name.
> I made doubly sure of this.
>
> Any further insights as to what I can do to make this `go' would be
> much appreciated.
>
> TIA,
>
> Marshall
> -----------------------------------------------------------------------------
>
> I think the problem is simply that you are using a no-rewind device. The
> ontape process opens and reads the 1st block to print out the chunks it's
> restoring etc...It then closes the device and reopens it. At that point it is
> expecting to do it's read and reread the block it used to display that
> chunk/dbspace information, and if it's can't, the restore will fail. I think
> if you just do the restore with a rewind device it should work.
>
> Jacques Renaut
> IBM Informix Advanced Support
> APD Team
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Hi Jacques,
To testing the tape device if it supported a blocksize = 1024k , you can try
it command :
mt -f /dev/rmt/0cbn rewind
dd if=/dev/rmt/0cbn bs=1024k count=100 of=/dev/null
It command read 100 block of 1024k each one and send it to /dev/null.
I remenber that in Solaris you can set the parameters of tape with mt -f
device set arg=value
Regards
Adolf.
---------[ Received Mail Content ]----------
Subject : Re: IDS 7.31/SunOS 5.7 ontape restore problem [18575]
Date : Wed, 6 Jan 2010 15:56:35 -0500 (EST)
From : "JACQUES RENAUT" <jrenaut@us.ibm.com>
To : ids@iiug.org
You wrote:
Hello and Happy 2010!
On Xmas eve 2009 one of the disks on a server that I admin went offline,
taking with it an Informix database that is much missed. First I
re-initialized the database chunks by executing the following:
touch mytest_db1
touch mytest_db2
touch mytest_db3
chmod 660 mydb*
onspaces -c -d mytestdb -p /mytest_db1 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db2 -o 0 -s 2000000
onspaces -a mytestdb -p /mytest_db3 -o 0 -s 2000000
I made sure that the chunk size matched the chunk size of the missing
chunks (2 GB). I've read some posts on the net that say that one need
not create the chunks, merely touch the files and set the correct 660
permissions. I didn't know what to believe, so I made the chunks.
Then I snapped the database symlinks for my missing databases (mytestdb)
to above newly created chunks. My understanding is that only the symlink
paths needs to stay the same, not the target to which the links point.
I then attempted cold restoring from the last known good 8mm Exabyte tape
backup
for our database.
mt -f /dev/rmt/0cbn rewind
onmode -yuck
ontape -r
Archive Tape Information
Tape type: Archive Backup Tape
Online version: Informix Dynamic Server Version 7.31.UC4
Archive date: Wed Jun 27 12:31:22 2007
User id: informix
Terminal id: /dev/pts/4
Archive level: 0
Tape device: /dev/rmt/0cbn
Tape blocksize (in k): 1024
Tape size (in k): 138240000
Tape number in series: 1
Spaces to restore:1 [rootdbs ]
2 [livedb ]
3 [testdb ]
4 [traindb ]
5 [llogdbs ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
Initialization Time 10/25/2003 00:28:45
System Page Size 2048
Version 6
Archive CheckPoint Time 06/27/2007 12:31:26
paces
number flags fchunk nchunks flags owner name
1 1 1 1 N informix rootdbs
2 1 2 16 N informix mydb
5 1 5 1 N informix llogdbs
6 2001 6 1 N T informix tempdb
7 2001 7 1 N T informix tempdb2
8 2001 26 1 N T informix tempdb3
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 400000 333479 PO- /dblnk/live/my_root
2 2 0 1000000 13 PO- /dblnk/live/my_db1
3 3 0 1000000 13 PO- /dblnk/test/mytest_db1
4 4 0 1000000 65217 PO- /dblnk/train/mytrain_db1
5 5 0 700100 47 PO- /dblnk/llog/my_llogs
6 6 0 500000 499497 PO- /dblnk/live/my_temp1
7 7 0 500000 499497 PO- /dblnk/live/my_temp2
8 2 0 1000000 395348 PO- /dblnk/live/my_db2
9 2 0 1000000 15 PO- /dblnk/live/my_db3
10 2 0 1000000 3 PO- /dblnk/live/my_db4
11 2 0 1000000 59 PO- /dblnk/live/my_db5
12 2 0 1000000 8 PO- /dblnk/live/my_db6
13 4 0 1000000 869947 PO- /dblnk/train/mytrain_db2
14 2 0 1000000 79371 PO- /dblnk/live/my_db7
15 2 0 1000000 3 PO- /dblnk/live/my_db8
16 2 0 1000000 6 PO- /dblnk/live/my_db9
17 2 0 1000000 2711 PO- /dblnk/live/my_db10
18 2 0 1000000 550379 PO- /dblnk/live/my_db11
19 2 0 1000000 24997 PO- /dblnk/live/my_db12
20 2 0 1000000 24997 PO- /dblnk/live/my_db13
21 4 0 500000 499997 PO- /dblnk/train/mytrain_db3
22 2 0 1000000 399997 PO- /dblnk/live/my_db14
23 2 0 1000000 999997 PO- /dblnk/live/my_db15
24 2 0 1000000 999997 PO- /dblnk/live/my_db16
25 3 0 1000000 11483 PO- /dblnk/test/mytest_db2
26 8 0 500000 499497 PO- /dblnk/live/my_temp3
27 3 0 1000000 834997 PO- /dblnk/test/mytest_db3
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - restore reserved pages failed
Program over.
When I Googled the above error message, the advice that I read said to
make sure the TAPE blocksize was set correctly using either mt and/or the
onconfig file. mt on SunOS 5.7 doesn't support setting the blocksize
as far as I could determine from it's arcane manpage and the onconfig
file that ontape uses has the correct blocksize (1024K) and total tape
size (138,240,000K). Another post I read said to make sure that the
path to the symlinks that point to the chunks had not changed name.
I made doubly sure of this.
Any further insights as to what I can do to make this `go' would be
much appreciated.
TIA,
Marshall
-----------------------------------------------------------------------------
I think the problem is simply that you are using a no-rewind device. The
ontape process opens and reads the 1st block to print out the chunks it's
restoring etc...It then closes the device and reopens it. At that point it is
expecting to do it's read and reread the block it used to display that
chunk/dbspace information, and if it's can't, the restore will fail. I think
if you just do the restore with a rewind device it should work.
Jacques Renaut
IBM Informix Advanced Support
APD Team
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
You wrote:
Hmmm... our Exabyte drive is a `no rewind' device b/c it automatically rewinds
upon ejection of the tape? Is that what you mean?
I'll try ejecting the tape, re-inserting it, then running `ontape -r' without
first running `mt -f /dev/rmt/0cbn rewind'. Please let me know if that is what
you were prescribing.
Thanks again!
Marshall
------------------------------------------------------------------------------
I believe at the unix level whether the device rewinds when it's closed
depends on the name you call it. So in your case you are using /dev/rmt/0cbn.
That 'n' on the end is what indicates that the device is no-rewind. I think if
you have the device file /dev/rmt/0cb then it would rewind when the ontape
process closed and reopened. So it may be as simple as just changing TAPEDEV
in your onconfig file to /dev/rmt/0cb if that device file is available.
Jacques Renaut
IBM Informix Advanced Support
APD Team
PPPLLLEEEAAASSSEEE!!! Qoute the post to which you are replying!!!!!!!!!!!
I've now said that four times this week alone!
I have no idea what you were responding to, but ontape wants an auto rewind
device NOT a norewind device!
Art
Art S. Kagel
AdvanceDataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. 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, Jan 6, 2010 at 4:39 PM, MARSHALL HAHN-TAYLOR <
marshall_hahn-taylor@canb.uscourts.gov> wrote:
> Hmmm... our Exabyte drive is a `no rewind' device b/c it automatically
> rewinds
> upon ejection of the tape? Is that what you mean?
>
> I'll try ejecting the tape, re-inserting it, then running `ontape -r'
> without
> first running `mt -f /dev/rmt/0cbn rewind'. Please let me know if that is
> what
> you were prescribing.
>
> Thanks again!
>
> Marshall
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0ce03d0e2cce3c047c8629f0
> Let me recap to make sure I know what you are saying. It looks like your
> dbspace and chunks for a database were stored on a hard drive that failed,
> but the Informix instance was installed and configured elsewhere. If
> that is the case, I am not sure why you added a new dbspace to your
> instance before the restore. It appears that you are using "cooked"
> space for your database. I understand the process as follows:
Hi Larry,
Yes, two of my databases were stored on drives that failed. One of them I
wish to recover. Informix is installed on the same system on a different,
healthy, drive. I created a new dbspace b/c at some point in the process
of searching for an answer on the Net, I stumbled across two opinions
about how to restore a dbspace using ontape - one that said effectively
`just touch, chmod and you're good to go', the other that said `touch,
chmod, use onspaces.'.
> I am assuming that the links to the root dbspace and the temp dbspaces
> either still exist or that they are using the same space referred to
> above and everything is together. I am thinking that the error message
> you received was misleading.
temp and rootdbs are well, thank you. The error message is misleading
b/c really I should have just touch'd, chmod'd the dbspace files and
then tried restoring?
thx,
Marshall
Hey Adolfo,
I just tried what you suggested and it worked, so I guess the 1024K block size
is correct:
$ mt -f /dev/rmt/0cbn rewind
$ dd if=/dev/rmt/0cbn bs=1024k count=100 of=/dev/null100+0 records in
100+0 records out
Thanks for suggesting the check =)
>PPPLLLEEEAAASSSEEE!!! Qoute the post to which you are replying!!!!!!!!!!!
>I've now said that four times this week alone!
Will do.
>I have no idea what you were responding to, but ontape wants an auto
>rewind device NOT a norewind device!
> Art
I've changed my onconfig file to use /dev/rmt/0cb instead of
/dev/rmt/0cbn per your and Jacques advice.
I'm running 'ontape -r' now and this time it's taking a long time after
the last line (see below) to return, which *might* be a good thing (?).
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
There doesn't appear to be any kind of status output to let me know it's
working.
Yours with fingers crossed...
-mt
You wrote:
>PPPLLLEEEAAASSSEEE!!! Qoute the post to which you are replying!!!!!!!!!!!
>I've now said that four times this week alone!
Will do.
>I have no idea what you were responding to, but ontape wants an auto
>rewind device NOT a norewind device!
> Art
I've changed my onconfig file to use /dev/rmt/0cb instead of
/dev/rmt/0cbn per your and Jacques advice.
I'm running 'ontape -r' now and this time it's taking a long time after
the last line (see below) to return, which *might* be a good thing (?).
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
There doesn't appear to be any kind of status output to let me know it's
working.
Yours with fingers crossed...
-mt
-------------------------------------------------------------------------
Marshal,
In a seperate window/terminal, if you have your environment variables set up
properly, you should be able to look at onstat -D to monitor which chunk is
currently getting writes performed to it. All chunks need to restore all the
pages on the archive before it completes. So the fact that it didn't
immediately error would be a good indication it's restoring pages now, but the
onstat -D should allow you to monitor/confirm it is progressing.
Jacques Renaut
IBM Informix Advanced Support
ADP Team
Dear Art, Larry, Adolfo, and Jacques,
Thanks *very* much for the help! I just got our database back up this morning
and there was much rejoicing.
What made all the difference was setting the tape dev in my onconfig file to
TAPEDEV /dev/rmt/0cb # Tape device path
from what it was
TAPEDEV /dev/rmt/0cbn # Tape device path
That is to say, from a no-rewind ('0cbn') to a rewind ('0cb') device.
Cheers,
Marshall