Dbspace recovery
pow43
I have started testing revovery of a singe dbspace or all. The senario
is that the server that the IDS was running on is completely gone and
we have to restore a backup from the backupsystem (we use Veritas
NetBackup) to a new server/host running the same IDS version (for time
being 11.50.FC5 64-bits). On this new server I wanted to restore the
db_tables dbspace after creating it with same size. I created the
dbspace and started a ontape -r db_tables using the fullbackup (ontape
-s -L 0) from the old "gone" instance, but it failed with error :
Spaces to restore:1
[db_tables ]
Physical restore failed - DBspace db_tables can not be restored; not
in DBspace table.
A full resore of all the dbspaces failed also with error:
Spaces to restore:1
[db_rootdbs ]
2
[db_loglog ]
3
[db_physlog ]
4
[db_temp ]
5
[db_tables ]
6
[db_indices ]
Physical restore failed -
[db_rootdbs ]
Invalid DBspace list
Program over.
After a bit of research I understod that the dbspaces has to be made
excatly with the not only the same names, but also the dbspace number.
So I reInitialized the rootdbs (it was named something else on the new
server) and all the abow dbspaces in the same order. Still it failes:
-bash-3.00$ ontape -r -D db_tables
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Continue restore? (y/n)y
Spaces to restore:1
[db_tables ]
Physical restore failed - Archived 'db_tables' is a different space
from the
current 'db_tables'. Only physical restores of
existing spaces are allowed.
Program over.
... and a full resore of all dbspaces ...
-bash-3.00$ ontape -r
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Continue restore? (y/n)y
Spaces to restore:1
[db_rootdbs ]
2
[db_loglog ]
3
[db_physlog ]
4
[db_temp ]
5
[db_tables ]
6
[db_indices ]
Physical restore failed -
[db_temp ]
Invalid DBspace list
Program over.
I then ran archecker on the fullbackup device/file (archecker -t -d -v
-s /opt/informix/data/LEVEL_0_backup), and all looked ok.
The difference between old server/instance and the new one is that the
rawdevices used have differnt paths and names, the DBSERVERNAME is
different and of course the hostname.
Does these 3 differences also be the same as the old "gone" host and
IDSinstance or what am I doing wrong?
Regards!
-POW
Fernando Nunes
Anyway... The PATHNAMEs of the chunks in a "simple" ontape -r must match.
But if you need to change them you can use the -rename or -f filename syntax.
Note that in case a server is lost you will need a full cold restore.
Warm restores (with the engine up) can be used for non-critical dbspaces, but they assume you have a backup of the same server. They'll need logical restores to bring the system into a consistent state, and they're used to recover chunks/dbspaces where you had physical disk problems.
Hope this helps.
Regards.
_______________________________________________
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
theBP
> I got a bit confused. You mention you use NetBackup, but then your
> commands use ontape. I assume NetBackup is used for filesystem and
> ontape for Informix.
> Anyway... The PATHNAMEs of the chunks in a "simple" ontape -r must match.
> But if you need to change them you can use the -rename or -f filename
> syntax.
>
> Note that in case a server is lost you will need a full cold restore.
> Warm restores (with the engine up) can be used for non-critical
> dbspaces, but they assume you have a backup of the same server. They'll
> need logical restores to bring the system into a consistent state, and
> they're used to recover chunks/dbspaces where you had physical disk
> problems.
>
> Hope this helps.
> Regards.
>
>
Also, you cannot just plug a dbspace from an instance into another instance
Art Kagel
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a...@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.
pow43
>
> – Vis sitert tekst –
Hi Fernando,
Sorry the confusion. We use NetBackup for filebackups (in the past we
used ontar against NetBackup) and ontape for Informix backups. I'll
try the rename option. As Art says the new location must use the same
INFORMIXSERVER name as the original.
Thanks!
-Per Otto Westheim
pow43
> >http://www.iiug.org/mailman/listinfo/informix-list– Skjul sitert tekst –
>
> – Vis sitert tekst –
Hi Art,
Sounds logical I admit. So ... the INFORMIXSERVER must be the same
(name) and the dbspaces in the same order (dbspacenumber) as the
original instance .. right? What about the size of the dbspaces, can
they be larger than the original or must they have the exact size as
the originals? What about chuncks added to the dbspaces, same story
here with order/number and size?
Thanks!
-Per Otto Westheim
Art Kagel
- In order to restore a single dbspace other than the ROOTDB space, called a warm restore, the ROOTDB space must exist.
- If you are restoring a no-ROOTDB dbspace to the same machine/instance, say after a few chunks' disks failed that belong to that one dbspace (or a few dbspaces for that matter), then the ROOTDB dbspace is already in place (assuming that the ROOTDB dbspace's chunks did not fail of course) and you ONLY have to restore the non-ROOTDB dbspace(s) that you need to restore.
- If, on the other hand, you want to restore just one dbspace to another machine so that you can, for example, try to extract rows that some fumble fingered DBA "accidentally" deleted, you CAN do that, but first you have to perform a cold restore of the ROOTDB dbspace. Once that's accomplished you can perform a warm restore any other single dbspace(s).
Note that if you intent is to recover deleted data or a dropped table, it is probably faster to use the archecker utility's ability to extract the table's data directly from the archive and insert it into any table you want - the original table or a structural copy of the table you can use to stage the data and filter it for rows you want to recover.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a...@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.
Thanks!
-Per Otto Westheim
Art Kagel
Each chunk path must exist. Although you can use ontape's chunk rename feature to restore to different chunks even with different offsets there must be a one-to-one relationship between the original chunks and the new ones and they must be at least as large as the original chunk files or devices. You CAN map say two 1GB chunks to different offsets of the same 2GB or larger file or device, but that's still two chunks mapping to two chunks. Get it?
You only have to make sure that the chunks for the ROOTDB dbspace and the dbspaces which you want to restore exist. Any chunks belonging only to dbspaces which you will not be restoring do not have to exist, the engine will be marking them down/offline anyway. You will have to set ONDBSPACEDOWN appropriately to permit the engine to remain online with some chunks marked down, though.
The dbspaces will be the same as the originals when the restore is complete, at least those dbspaces which you choose to restore will be.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a...@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.
NO! the INFORMIXSERVER name is completely irrelevant. Ok here are the important points:
- In order to restore a single dbspace other than the ROOTDB space, called a warm restore, the ROOTDB space must exist.
- If you are restoring a no-ROOTDB dbspace to the same machine/instance, say after a few chunks' disks failed that belong to that one dbspace (or a few dbspaces for that matter), then the ROOTDB dbspace is already in place (assuming that the ROOTDB dbspace's chunks did not fail of course) and you ONLY have to restore the non-ROOTDB dbspace(s) that you need to restore.
- If, on the other hand, you want to restore just one dbspace to another machine so that you can, for example, try to extract rows that some fumble fingered DBA "accidentally" deleted, you CAN do that, but first you have to perform a cold restore of the ROOTDB dbspace. Once that's accomplished you can perform a warm restore any other single dbspace(s).
Note that if you intent is to recover deleted data or a dropped table, it is probably faster to use the archecker utility's ability to extract the table's data directly from the archive and insert it into any table you want - the original table or a structural copy of the table you can use to stage the data and filter it for rows you want to recover.
IIUG Board of Directors (a...@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 Sat, Feb 27, 2010 at 1:26 PM, pow43 <fabe...@yahoo.no> wrote:
Thanks!
-Per Otto Westheim
pow43
I have now tried som recovery attempts both warm restore of one
dbspace and a could one with all dbspaces inc. rootdbs. I also have
tried the rename option, but it have failed every time. Do you see
what I'm doeing wrong?:
WARM RESTORE:
--------------------------
ATTEMPT 1) with rename
--------------------------
-bash-3.00$ ontape -r -rename -p /dev/vx/rdsk/f_efaDG/db_tables01 -o 0
-n /dev/zvol/rdsk/vm-efainfx-1/zvols/db_efa1 -o 0 -D db_tables
Server is in an incompatible state or user authentication failed.
-bash-3.00$ ontape -r -D db_tables
DBspace 'db_tables' is online; restoring 'db_tables' will bring all
chunks
comprising the DBspace OFFLINE and will terminate all active
transactions and queries accessing the DBspace.
OK to continue?
DBspace 'db_tables' is online; restoring 'db_tables' will bring all
chunks
comprising the DBspace OFFLINE and will terminate all active
transactions and queries accessing the DBspace.
OK to continue?yes
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Continue restore? (y/n)y
Spaces to restore:1
[db_tables ]
Physical restore failed - Archived 'db_tables' is a different space
from the
current 'db_tables'. Only physical restores of
existing spaces are allowed.
Program over.
-bash-3.00$ onstat -d
IBM Informix Dynamic Server Version 11.50.FC5 -- On-Line -- Up
00:17:35 -- 165888 Kbytes
Dbspaces
address number flags fchunk nchunks pgsize
flags owner name
10330028 1 0x60001 1 1 2048 N
B informix db_rootdbs
1149a6b8 2 0x40001 2 1 2048 N
B informix db_loglog
118a5c20 3 0x40001 3 1 2048 N
B informix db_physlog
117bae20 4 0x42001 4 1 2048 N
TB informix db_temp
114b89d8 5 0x40005 5 1 2048 ND
B informix db_tables
118ca4e0 6 0x40001 6 1 2048 N
B informix db_indices
6 active, 2047 maximum
Chunks
address chunk/dbs offset size free
bpages flags pathname
103301c0 1 1 0 1000000
994161 PO-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/
db_rootdb
1197bd68 2 2 0 1000000
919947 PO-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/
db_loglog
118a5db8 3 3 0 1000000
49947 PO-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/
db_physlog
114b8028 4 4 0 1000000
999947 PO-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/db_temp
114b8b70 5 5 0 1000000
0 PD-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/db_efa1
118ca678 6 6 0 1000000
999947 PO-B- /dev/zvol/rdsk/vm-efainfx-1/zvols/db_efa2
6 active, 32766 maximum
NOTE: The values in the "size" and "free" columns for DBspace chunks
are
displayed in terms of "pgsize" of the DBspace to which they
belong.
Expanded chunk capacity mode: always
This left the chunk belonging to the dbspace db_tables in DOWN/
DISABLED state (se abowe)!? I tried to drop it useing onspaces and in
onmonitor, but no luck ... 'can not drop, dbspace is not empty' and
similar messages. Since this is an unused server for time being I just
reinilized the rootdbs and created the dbspaces once more. So warm
restoring a single dbspace did not work. Next approach was cold
restore ..
COLD RESTORE
-----------------------
ATTEMPT 1)
-----------------------
onmode -ky
-bash-3.00$ ontape -r -D db_tables
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Spaces to restore:1
[db_tables ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1999 Informix Software,
Inc.
Initialization Time 11/29/2004 11:53:07
System Page Size 2048
Version 16
Index Page Logging OFF
Archive CheckPoint Time 02/23/2010 22:00:29
Dbspaces
number flags fchunk nchunks flags
owner name
1 40001 1 1 N B
informix
db_rootdbs
2 40001 2 1 N B
informix
db_loglog
3 40001 3 1 N B
informix
db_physlog
4 40001 4 1 N B
informix
db_temp
5 40001 5 1 N B
informix
db_tables
6 40001 6 1 N B
informix
db_indices
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 1000000 893413 PO-B /dev/vx/rdsk/f_efaDG/
db_rootdbs
2 2 0 1000000 9947 PO-B /dev/vx/rdsk/f_efaDG/
db_loglog
3 3 0 1000000 999947 PO-B /dev/vx/rdsk/f_efaDG/
db_physlog
4 4 0 4000000 3999747 PO-B /dev/vx/rdsk/f_efaDG/
db_tempdbs01
5 5 0 5000000 4345423 PO-B /dev/vx/rdsk/f_efaDG/
db_tables01
6 6 0 5000000 4760735 PO-B /dev/vx/rdsk/f_efaDG/
db_indices01
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - Invalid DBspace list
Program over.
-----------------------------
ATTEMPT 2) with rename
-----------------------------
-bash-3.00$ ontape -r -rename -p /dev/vx/rdsk/f_efaDG/db_tables01 -o 0
-n /dev/zvol/rdsk/vm-efainfx-1/zvols/db_efa1 -o 0 -D db_tables
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Spaces to restore:1
[db_tables ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1999 Informix Software,
Inc.
Initialization Time 11/29/2004 11:53:07
System Page Size 2048
Version 16
Index Page Logging OFF
Archive CheckPoint Time 02/23/2010 22:00:29
Dbspaces
number flags fchunk nchunks flags
owner name
1 40001 1 1 N B
informix
db_rootdbs
2 40001 2 1 N B
informix
db_loglog
3 40001 3 1 N B
informix
db_physlog
4 40001 4 1 N B
informix
db_temp
5 40001 5 1 N B
informix
db_tables
6 40001 6 1 N B
informix
db_indices
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 1000000 893413 PO-B /dev/vx/rdsk/f_efaDG/
db_rootdbs
2 2 0 1000000 9947 PO-B /dev/vx/rdsk/f_efaDG/
db_loglog
3 3 0 1000000 999947 PO-B /dev/vx/rdsk/f_efaDG/
db_physlog
4 4 0 4000000 3999747 PO-B /dev/vx/rdsk/f_efaDG/
db_tempdbs01
5 5 0 5000000 4345423 PO-B /dev/vx/rdsk/f_efaDG/
db_tables01
6 6 0 5000000 4760735 PO-B /dev/vx/rdsk/f_efaDG/
db_indices01
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - Invalid DBspace list
Program over.
-----------------------------------------
ATTEMPT 3) all dbspaces inc. rootdbs:
-----------------------------------------
-bash-3.00$ ontape -r
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Spaces to restore:1
[db_rootdbs ]
2
[db_loglog ]
3
[db_physlog ]
4
[db_temp ]
5
[db_tables ]
6
[db_indices ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1999 Informix Software,
Inc.
Initialization Time 11/29/2004 11:53:07
System Page Size 2048
Version 16
Index Page Logging OFF
Archive CheckPoint Time 02/23/2010 22:00:29
Dbspaces
number flags fchunk nchunks flags
owner name
1 40001 1 1 N B
informix
db_rootdbs
2 40001 2 1 N B
informix
db_loglog
3 40001 3 1 N B
informix
db_physlog
4 40001 4 1 N B
informix
db_temp
5 40001 5 1 N B
informix
db_tables
6 40001 6 1 N B
informix
db_indices
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 1000000 893413 PO-B /dev/vx/rdsk/f_efaDG/
db_rootdbs
2 2 0 1000000 9947 PO-B /dev/vx/rdsk/f_efaDG/
db_loglog
3 3 0 1000000 999947 PO-B /dev/vx/rdsk/f_efaDG/
db_physlog
4 4 0 4000000 3999747 PO-B /dev/vx/rdsk/f_efaDG/
db_tempdbs01
5 5 0 5000000 4345423 PO-B /dev/vx/rdsk/f_efaDG/
db_tables01
6 6 0 5000000 4760735 PO-B /dev/vx/rdsk/f_efaDG/
db_indices01
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
Physical restore failed - ONCONFIG ROOTPATH: '/dev/zvol/rdsk/vm-
efainfx-1/zvols/db_rootdb' differs from archive: '/dev/vx/rdsk/f_efaDG/
db_rootdbs'
Correct ONCONFIG before restoring this archive.
Program over.
-------------------------------------------
ATTEMPT 4) just rootdbs with rename option
-------------------------------------------
-bash-3.00$ ontape -r -rename -p /dev/vx/rdsk/f_efaDG/db_rootdbs -o 0 -
n /dev/zvol/rdsk/vm-efainfx-1/zvols/db_rootdb -o 0 -D db_rootdbs
Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press
Return to continue ...
Archive Tape Information
Tape type: Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC5
Archive date: Tue Feb 23 22:00:29 2010
User id: informix
Terminal id: ?
Archive level: 0
Tape device: /backup/informix/backup_device
Tape blocksize (in k): 64
Tape size (in k): 10000000
Tape number in series: 1
Spaces to restore:1
[db_rootdbs ]
Archive Information
Informix Dynamic Server Copyright(C) 1986-1999 Informix Software,
Inc.
Initialization Time 11/29/2004 11:53:07
System Page Size 2048
Version 16
Index Page Logging OFF
Archive CheckPoint Time 02/23/2010 22:00:29
Dbspaces
number flags fchunk nchunks flags
owner name
1 40001 1 1 N B
informix
db_rootdbs
2 40001 2 1 N B
informix
db_loglog
3 40001 3 1 N B
informix
db_physlog
4 40001 4 1 N B
informix
db_temp
5 40001 5 1 N B
informix
db_tables
6 40001 6 1 N B
informix
db_indices
Chunks
chk/dbs offset size free bpages flags pathname
1 1 0 1000000 893413 PO-B /dev/vx/rdsk/f_efaDG/
db_rootdbs
2 2 0 1000000 9947 PO-B /dev/vx/rdsk/f_efaDG/
db_loglog
3 3 0 1000000 999947 PO-B /dev/vx/rdsk/f_efaDG/
db_physlog
4 4 0 4000000 3999747 PO-B /dev/vx/rdsk/f_efaDG/
db_tempdbs01
5 5 0 5000000 4345423 PO-B /dev/vx/rdsk/f_efaDG/
db_tables01
6 6 0 5000000 4760735 PO-B /dev/vx/rdsk/f_efaDG/
db_indices01
Continue restore? (y/n)y
Do you want to back up the logs? (y/n)n
WARNING: server initialization failed, or possibly timed out (if -w
was used).
Check the message log, online.log, for errors.
Physical restore failed - ONCONFIG ROOTPATH: '/dev/zvol/rdsk/vm-
efainfx-1/zvols/db_rootdb' differs from archive: '/dev/vx/rdsk/f_efaDG/
db_rootdbs'
Correct ONCONFIG before restoring this archive.
Program over.
///////
So I am not able to restore a singe dbspace, rootdbs and all dbspaces
with warm or cold restore. Obviosly I am doing somthing wrong, but I
can not figure out what? Any help and suggestion really appreciated!
Regards!
-Per Otto
On 28 Feb, 02:23, Art Kagel <art.ka...@gmail.com> wrote:
> NO! the INFORMIXSERVER name is completely irrelevant. Ok here are the
> important points:
>
> - In order to restore a single dbspace other than the ROOTDB space,
> called a warm restore, the ROOTDB space must exist.
> - If you are restoring a no-ROOTDB dbspace to the same machine/instance,
> say after a few chunks' disks failed that belong to that one dbspace (or a
> few dbspaces for that matter), then the ROOTDB dbspace is already in place
> (assuming that the ROOTDB dbspace's chunks did not fail of course) and you
> ONLY have to restore the non-ROOTDB dbspace(s) that you need to restore.
> - If, on the other hand, you want to restore just one dbspace to another
> machine so that you can, for example, try to extract rows that some fumble
> fingered DBA "accidentally" deleted, you CAN do that, but first you have to
> perform a cold restore of the ROOTDB dbspace. Once that's accomplished you
> can perform a warm restore any other single dbspace(s).
>
> Note that if you intent is to recover deleted data or a dropped table, it is
> probably faster to use the archecker utility's ability to extract the
> table's data directly from the archive and insert it into any table you want
> - the original table or a structural copy of the table you can use to stage
> the data and filter it for rows you want to recover.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (a...@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
theBP
> Hi Art/Fernando,
>
> I have now tried som recovery attempts both warm restore of one
> dbspace and a could one with all dbspaces inc. rootdbs. I also have
> tried the rename option, but it have failed every time. Do you see
> what I'm doeing wrong?:
>
>
> WARM RESTORE:
>
You cannot just plug a dbspace from instance1 into another instance2
pow43
Acording to other guys it should work, but I am a bit uncertain
now .... Which other option do I have to be able to make a backup on
one instance and in a situation be able to import this backup on
another host and IDS instrance? I know dbexport would be a
possebility, but not if the db is huge ... several 100 GB's ....
-POW
Fernando Nunes
dbspace restores between instances don't work.
For a dbspace to be recovered, you have to roll forward the logical logs
since the start of the backup of that dbspace. This is assumed to
guarantee the integrity of the data. If the instance is different, the
logical log rollforward would obviously fail.
I personally understand the requirement of being able to "move" dbspaces
from one instance to another since we can imagine scenarios where this
could be acceptable (if the dbspace only contains objects of a specific
database and if that database has no more objects except those included
in that dbspace). But this is not supported. Basically the idea is that
we don't let customers shoot themselves in the foot (even if they're
just pointing down and away from the feet).
Regards.
Art Kagel
server! I thought I said that several days ago.
Another option is to get my dbimport/dbexport replacement utility package myexport which can use the hploader to unload and load the data VERY fast to/from disk and it can process all or many tables in parallel and it does not lock the data base while it's working.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a...@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.
pow43
Ok ... I think we maybe misunderstand eachother a little. I work
mostly with Sybase and Oracle and in Sybase ASE I restore db's accross
hosts and instances even. importing into different versions on a
regular basis and it works perfectly. Dbexport/import ... HPL or
similar approches (""aka"" bcp/sybmigrate in Sybase and exp/imp or
datapump in Oracle) are not at all an option when we are planning
Disaster plan for Informix databases. Then we must look at mirror/snap
solutions on the SAN (we are using Solaris zfs btw) and not useing
Informix tools.
Thanks!
Per Otto
Fernando Nunes
If it affects only a dbspace, you need to recover it in the original instance.
If it affects a complete machine/instance you need to recover the whole instance and not a dbspace (in the same machine or another).
Also, if you're planning for disaster/recovery take a look at MACH 11 technology (HDR/RSS/SDS/ER).
That should give you plenty of options for whatever you need to do.
The option of moving a dbspace can have several usage scenarios, but I can't see how disaster recovery is one of them?
Regards.
_______________________________________________
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
Art Kagel
For disaster recovery, Informix has ontape and onbar which archive and restore the entire server onto the same machine or a different one as long as the machines are binary compatible and run the same OS. That's simple and fast. That's disaster recovery. In addition, Informix has HDR, SDS, and RSS secondary servers so that you can continue servicing client applications immediately after a server crashes, that's disaster avoidance. But that does not seem to be what you were asking about.
If all you are trying to do is to restore the archived server onto a different machine, then it is trivial:
- Create the links for each chunk to some existing storage on the machine that is at least as big as the original chunk
- To determine what the chunks are in case you have not saved a copy of the onstat -d report from the server before it crashed, you can start the restore and it will print out the list of chunk paths and their sizes and offsets (offset + size equals how much storage you'll need on the replacement chunk device or file unless you use the remapping option of ontape to relocate the chunks elsewhere).
- Make sure the ownerships and permissions are correct on the chunks (informix:informix 0660)
- run "ontape -r" and stand back
However, you keep asking about restoring a single dbspace to a different already running server instance. You cannot do that, correct. What has that to do with SNAPping SAN storage. What does that have to do with disaster recovery? Disaster recovery is about restoring an entire database server instance, not restoring a single dbspace or a single database. Usually that kind of partial restoration is about recovering from fumble fingers and that's a different animal. Other applications for this that I've seen is copying production data to a QA or Dev. environment. If these are your scenarios, which are not disaster recovery at all, then, yes ontape and onbar are not the correct tools for you. Actually, dbexport and dbimport (or myexport and myimport) and other scripted solutions are what most of us use and they work well. For large to massive databases hploader reading from one instance and piping its output to another hploader copy which is inserting the data into the remote server works VERY well. Beyond that, now with 11.50.xC6's EXTERNAL TABLES
So, what is the recovery scenario that you are that you are trying to plan recovery from?
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a...@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.