Using an external restore to rename chunks
Neil Truby
I want to rename some chunks. So, I do this:
1. Shut the db down
2. Copy the existing chunsk to the new ones
3. ontape -p -e -rename -f /tmp/restore_paths
(restore_paths looks like this:
/tmp/rootdbs_1 0 /global/informix/dbspaces1/rootdbs_1 0
/backup/appdbs_3 0 /opt/informix/dbspaces1/appdbs_3 0)
This doesn't look so promising, as I get the messages below, I assume
because the "external backup" (actually the live chunks themselves) lack a
blocking checkpoint. But by then doing onmode -k/oninit -v it does all come
up and runs happily off the new chunks, thus achieving the objective.
Any comments on this? In particular I'd like to rid myself of the
misleading warning about the chunk being invalid.
Will try 11.5 next.
Thanks
Neil
[UAT][informix@syduatdb1:~]# ontape -p -e -rename -f /tmp/restore_paths
External restore failed.
The external backup for the root chunk (chunk number 1) is not valid.
Program over.
[UAT][informix@syduatdb1:~]# onstat -m
IBM Informix Dynamic Server Version 10.00.FC10W4X -- Fast Recovery (CKPT
REQ) -- Up 00:00:31 -- 2589696 Kbytes
Blocked:CKPT
Message Log File: /opt/informix/online_1.log
15:51:40 Event alarms enabled. ALARMPROG =
'/opt/informix/10.0/etc/alarmprogram.sh'
15:51:40 Booting Language <c> from module <>
15:51:40 Loading Module <CNULL>
15:51:40 Booting Language <builtin> from module <>
15:51:40 Loading Module <BUILTINNULL>
15:51:40 Warning: CONSOLE = /dev/console open failed. Redirecting output to
'/dev/null'.
15:51:45 DR: DRAUTO is 0 (Off)
15:51:45 Requested shared memory segment size rounded from 288KB to 1024KB
15:51:45 Fast poll /dev/poll enabled.
15:51:45 IBM Informix Dynamic Server Version 10.00.FC10W4X Software Serial
Number AAA#B000000
15:51:46 IBM Informix Dynamic Server Initialized -- Shared Memory
Initialized.
15:51:46 Data replication type and state information reset. To start DR,
use
the 'onmode -d' command and wait for the pair to be operational,
before shutting down the database server
15:51:46 Dataskip is now OFF for all dbspaces
15:51:46 Restartable Restore has been ENABLED
15:51:46 Recovery Mode
15:51:49 The external backup for the root chunk (chunk number 1) is not
valid.
Neil Truby
"Neil Truby" <neil....@ardenta.com> wrote in message
news:93vefm...@mid.individual.net...
> IDS 10.0FC10 on Solaris
>
> I want to rename some chunks. So, I do this:
>
> 1. Shut the db down
> 2. Copy the existing chunsk to the new ones
> 3. ontape -p -e -rename -f /tmp/restore_paths
>
> (restore_paths looks like this:
> /tmp/rootdbs_1 0 /global/informix/dbspaces1/rootdbs_1 0
> /backup/appdbs_3 0 /opt/informix/dbspaces1/appdbs_3 0)
>
> This doesn't look so promising, as I get the messages below, I assume
> because the "external backup" (actually the live chunks themselves) lack a
> blocking checkpoint. But by then doing onmode -k/oninit -v it does all
> come up and runs happily off the new chunks, thus achieving the objective.
>
> Any comments on this? In particular I'd like to rid myself of the
> misleading warning about the chunk being invalid.
>
> Will try 11.5 next.
>
> Thanks
> Neil
Exactly the same in 11.5FC7 - restore given warning about invalid chunk, but
then is fine if we onmode -ky and re-start.
jrenaut
> "Neil Truby" <neil.tr...@ardenta.com> wrote in message
Ok, so you are trying to use external restore to change paths for a
current system it looks like.
Well instead of shutting down the server using onmode -ky first, how
about you change it to
1) onmode -c block (the onmode -c block does a checkpoint and puts
some control info about external backups I believe)
2) copy files
3) onmode -ky (server shouldn't checkpoint when shutdown and the
onmode -c block shouldn't allow any writes while the copy is
happening)
4) ontape -p -e blah
But yes, the onmode -c block does put some control information in
reserve pages about external backup so I believe that is probably what
you are missing that would get rid of the warning messages you are
getting when trying to do the external restore. (at least I believe
it would on the 11.x versions, the 10.x versions I'm not as sure)
I didn't have a chance to actually test this, but if I get a chance
I'll let you know how it goes, unless you beat me to it.
Jacques Renaut
IBM Informix Advanced Support
APD team
Neil Truby
>> news:c81bbfa2-2a0a-4651...@c41g2000yqm.googlegroups.com...
On May 23, 11:26 am, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> "Neil Truby" <neil.tr...@ardenta.com> wrote in message
Ok, so you are trying to use external restore to change paths for a
current system it looks like.
Well instead of shutting down the server using onmode -ky first, how
about you change it to
1) onmode -c block (the onmode -c block does a checkpoint and puts
some control info about external backups I believe)
2) copy files
3) onmode -ky (server shouldn't checkpoint when shutdown and the
onmode -c block shouldn't allow any writes while the copy is
happening)
4) ontape -p -e blah
But yes, the onmode -c block does put some control information in
reserve pages about external backup so I believe that is probably what
you are missing that would get rid of the warning messages you are
getting when trying to do the external restore. (at least I believe
>> it would on the 11.x versions, the 10.x versions I'm not as sure)
I beat you to it! And, of course, you're right. Genius!
Thanks
Neil
jrenaut
> I beat you to it! And, of course, you're right. Genius!
>
> Thanks
> Neil
Gah, I was just about to post that I'd tested it and it worked for me
as well. Glad it worked, as I do sort of hate to post things without
getting a chance to test them, especially if the suggestion does turn
out to not work, heh.
Jacques
Neil Truby
> I beat you to it! And, of course, you're right. Genius!
>
> Thanks
> Neil
One of my colleagues has pointed out that the "block" seems to survive the
onmode -ky. So:
1) onmode -c block (the onmode -c block does a checkpoint and puts
some control info about external backups I believe)
2) onmode -ky (server shouldn't checkpoint when shutdown and the
onmode -c block shouldn't allow any writes while the copy is
happening)
3) copy files
4) ontape -p -e blah
works fine too, and is in fact better if you're wanting to change chunk
*names* but the links from the old and new chunk names point to the same
underlying disk, because then step 3 is just a switch of soft links.