Unanswered: Cold Restore with renaming rootdbs chunk - Informix IDS11.70
I have an AIX6.1 server that i am running Informix IDS11.70. I want to make cold restore of my instance with renaming the chunks (changing the paths) including rootdbs chunk.
i tried this by using a file that ontape is using in order to rename the chunks. For example, the first lines look like this:
/IDS/rootdbs_chk01 10 /IDSh/rootdbs_chk01 10
/IDS/tempdbs1_chk01 4 /IDS_live/tempdbs1_chk01 4
/IDS/tempdbs2_chk01 4 /IDS_live/tempdbs2_chk01 4
/IDS/tempdbs3_chk01 4 /IDS_live/tempdbs3_chk01 4
Offset is 4 for all chunks except rootdbs that is 10. For some reason, it doesnt seem to accept the value 10 as offset for rootdbs. When i am running the command
ontape -r -rename -f filelist
to do the cold restore with rename i get the following message: Error at line 1 in input file filelist
This message appears only when i assign the value 10 as offset for rootdbs. If i change it to 4 then i get completely different message: Physical restore failed - The old chunk path (/IDS/rootdbs_chk01, 4) in the input file does not exist in the backup
It seems really strange. I dont understand why i get this error when i have the correct offset (value that is given in onconfig file).
Also can anybody confirm that it is possible to rename the rootdbs like the way i described above? Cause this is the first time that i am trying to rename the primary rootdbs chunk during cold restore and i am not sure if i have to do something else or not.
yes i checked the permissions. they are set as informix.informix 660.
i guess that if it was the access rights then i should get the same error under any conditions.
in this case i get different message according to the value of rootoffset that is set to the file.
Memory speaking, you should have in your TARGET onconfig file, for the parameters ROOTPATH and ROOTOFFSET, the values of the SOURCE onconfig file, in your case you should have int he TARGET onconfig:
yes thats the strange thing. this is why i mentioned in my first post that only rootdbs chunk has value 10 as offset and all the other chunks are 4. cause i read that from the onconfig file. This is what it is included there: ROOTNAME rootdbs ROOTPATH /IDS/rootdbs_chk01 ROOTOFFSET 10
at this point i want to mention also something else cause really it seems that it is a "weird" behavior in what i described in my first post.
in this AIX server that i am doing the cold restore, i have another INFORMIX instance that is identical with this.
actually the other instance is there to perform daily backups of the databases. i basically clone the disks of the "LIVE" environment to the disks of this "backup" server and then i export the databases for backup.
this instance that i am building now, its again a copy of this "LIVE" instance but this is for End of Month purposes which i need to keep some extra backups.
so the thing that worries me is that the primary rootdbs chunk is under /IDS/rootdbs_chk01 on both instances. this path exists on my server but in order to avoid some "corruption or other problems" i want to redirect the rootpath for my second "End of Month" instance.
this is the whole scenario. but still i cannot understand why i get an error when i use rootdbs offset 10 in my file.
Not sure I understand everything on your scenario, but the baseline is that this functionality works perfectly: some of my customers use it several times per week to make clones of the instances (with onbar though).
Something is certain: you cannot have 2 instances on the same server with the same rootpath!
Now the thing is: to restore the archive to another instance, you must copy the source onconfig file to the target onconfig file, keep the same ROOTPATH and ROOTOFFSET, change DBSERVERNAME on target (eventually SERVERNUM is restoring on the same box, because you cannot init 2 instances with the same SERVERNUM on the same box). Good to modify also MSGPATH if you do not want to mix mboth instances log files...
When you restore with the -f option, ontape will convert the OLD ROOTPATH to the NEW ROOTPATH(beware permissions and ownership for the NEW one), and WRITE the new values in the TARGET onconfig file just before restoring.
In the meanwhile, do not try to start two instances having the same ROOTPATH value in their respective onconfig file.
If you do the operation again, (next day for instance) you will have to have the OLD ROOTPATH and ROOTOFFSET values AGAIN in the TARGET onconfig file.
well you confirm my concerns about same rootpath for 2 separate instances. thank you for that.
about the onconfig files. even though on both instances i basically clone the same environment ("LIVE"), i am not replicating the INFORMIXDIR path. so i created 2 separate onconfig files for these 2 instances and basically used the guidelines that you refer above. i have the same ROOTPATH and ROOTOFFSET but different SERVERNUM and MSGPATH and of course different DBSERVERNAME.
permissions of rootdbs chunks seems ok also because i do not get the same error when i use different value for rootoffset in my file.
when i use the line below: /IDS/rootdbs_chk01 10 /IDSh/rootdbs_chk01 10
i get the error "Error at line 1 in input file filelist"
when i use this line: /IDS/rootdbs_chk01 4 /IDSh/rootdbs_chk01 4
i get the error "Physical restore failed - The old chunk path (/IDS/rootdbs_chk01, 4) in the input file does not exist in the backup"
the second error seems logical as the rootoffset set in onconfig file is set to 10. so it is normal to get this error i guess.
but i cannot understand why i get the first error. it doesnt seem to be permissions
one stupid suggestion:
build the -f file from scratch again. There may be a hidden character or so.
just to test, run
ontape -r -rename -p /IDS/rootdbs_chk01 -o 10 -n /IDSh/rootdbs_chk01 -o 10
and see what you obtain next
ie without the -f file option, just checking the contents of the first line of the file
I am not sure you can use the -p -o options several times in the same command ( for all the chunks...)
well i think your suggestions are "natural" under these circumstances.
i thought about this as well, that it may have some characters that it is causing this.
i tried to delete the first line and write it again but it didnt work but your second suggestion is the one that it makes things even more strange.
i run the command just like you typed it and i get the following: Error in parsing command line at '10'
at first i thought that it may need to put number 10 into quotes or something but it doesnt seem to help
i am using Informix Dynamic Server Version 11.70.FC2
very interesting post and link that you posted before. it seems that it can recognize the number now as a value for offset but maybe i miscalculated the size. i get this error: Physical restore failed - The old chunk path (/IDS/rootdbs_chk01, 10240) in the input file does not exist in the backup
i thought that rootoffset=10 equals with 10240 kilobytes.
in the meantime, my other instance (Daily) in online right now. is there a way to get the offset value in kilobytes by doing onstat -d or something like that? just to find the correct number to put in the command.
You run on AIX, with 4K pages. you will find the offset of your chuncks by running onstat -d. Look at the column 'offset' and multiply this value by 4 to have the right value in Kb.
another thing: to check the names of your chunks, my memory says that if you run
ontape -r ( without any option)
ontape would display the list of the chunks that are contained in the archive.
check against the values you have in your -f file.
Do not forget to stop ontape -r before actually completing it ;-)
Thank you very much for your patience. Your tip to use ontape -r was all it needed to point out what was happening.
i dont know why but even though rootoffset is set to 10 actually is not 10. i use ontape -r and i notice that rootdbs offset was 2 whereas other dbs offsets was 1. so i changed my filelist and instead of 10 or 4 that i used before i use 8. and it worked just fine!!
thank you again this thing was starting to be a nightmare but now it goes smoothly.
Because we didn't wanted to restore the whole instance we've managed to change the chunk paths in
1. shutdown instance
2. hexedit all chunk files belonging to that instance and replacing the path info
3. change ROOTPATH in onconfig
4. start up again and everything was fine BUT just because our old path had the same length as the new one... otherwise the hexedit will fail