dbTalk Databases Forums  

Dbspace recovery

comp.databases.informix comp.databases.informix


Discuss Dbspace recovery in the comp.databases.informix forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
pow43
 
Posts: n/a

Default Dbspace recovery - 02-26-2010 , 10:45 AM






Hi,

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

Reply With Quote
  #2  
Old   
Fernando Nunes
 
Posts: n/a

Default Re: Dbspace recovery - 02-26-2010 , 11:07 AM






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.


On Fri, Feb 26, 2010 at 3:45 PM, pow43 <faber_38 (AT) yahoo (DOT) no> wrote:

Quote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) 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...

Reply With Quote
  #3  
Old   
theBP
 
Posts: n/a

Default Re: Dbspace recovery - 02-26-2010 , 01:02 PM



On 26/02/2010 16:07, Fernando Nunes wrote:
Quote:
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

Reply With Quote
  #4  
Old   
Art Kagel
 
Posts: n/a

Default Re: Dbspace recovery - 02-26-2010 , 01:26 PM



You cannot restore a single dbspace to a new location. You can only restore
a single dbspace to the same existing instance from which it was archived.
You can only restore an entire instance on a new server.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) 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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber_38 (AT) yahoo (DOT) no> wrote:

Quote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Reply With Quote
  #5  
Old   
pow43
 
Posts: n/a

Default Re: Dbspace recovery - 02-27-2010 , 01:14 PM



On 26 Feb, 19:02, theBP <th... (AT) Usenet-News (DOT) Net> wrote:
Quote:
On 26/02/2010 16:07, Fernando Nunes wrote:





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– Skjul sitert tekst –

– 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

Reply With Quote
  #6  
Old   
pow43
 
Posts: n/a

Default Re: Dbspace recovery - 02-27-2010 , 01:26 PM



On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) com> wrote:
Quote:
You cannot restore a single dbspace to a new location. *You can only restore
a single dbspace to the same existing instance from which it was archived..
You can only restore an entire instance on a new server.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a... (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KSwww.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, orby
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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber... (AT) yahoo (DOT) no> wrote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-l... (AT) iiug (DOT) org
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

Reply With Quote
  #7  
Old   
Art Kagel
 
Posts: n/a

Default Re: Dbspace recovery - 02-27-2010 , 08:23 PM



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 (ora
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 haveto
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 (art (AT) iiug (DOT) 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 <faber_38 (AT) yahoo (DOT) no> wrote:

Quote:
On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) com> wrote:
You cannot restore a single dbspace to a new location. You can only
restore
a single dbspace to the same existing instance from which it was
archived.
You can only restore an entire instance on a new server.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a... (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KSwww.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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber... (AT) yahoo (DOT) no> wrote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-l... (AT) iiug (DOT) org
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
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Reply With Quote
  #8  
Old   
Art Kagel
 
Posts: n/a

Default Re: Dbspace recovery - 02-27-2010 , 08:28 PM



Oh, to your question about the sizes and number of dbspaces and chunks:

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 (art (AT) iiug (DOT) 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 8:23 PM, Art Kagel <art.kagel (AT) gmail (DOT) com> wrote:

Quote:
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 thatsome
fumble fingered DBA "accidentally" deleted, you CAN do that, but firstyou
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 (art (AT) iiug (DOT) 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 <faber_38 (AT) yahoo (DOT) no> wrote:

On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) com> wrote:
You cannot restore a single dbspace to a new location. You can only
restore
a single dbspace to the same existing instance from which it was
archived.
You can only restore an entire instance on a new server.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a... (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KSwww.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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber... (AT) yahoo (DOT) no> wrote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-l... (AT) iiug (DOT) org
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
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list



Reply With Quote
  #9  
Old   
pow43
 
Posts: n/a

Default Re: Dbspace recovery - 03-02-2010 , 09:52 AM



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:

--------------------------
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... (AT) gmail (DOT) com> wrote:
Quote:
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, itis
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... (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KSwww.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, orby
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 <faber... (AT) yahoo (DOT) no> wrote:
On 26 Feb, 19:26, Art Kagel <art.ka... (AT) gmail (DOT) com> wrote:
You cannot restore a single dbspace to a new location. *You can only
restore
a single dbspace to the same existing instance from which it was
archived.
You can only restore an entire instance on a new server.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (a... (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KSwww.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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber... (AT) yahoo (DOT) no> wrote:
Hi,

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
_______________________________________________
Informix-list mailing list
Informix-l... (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo...mix-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
_______________________________________________
Informix-list mailing list
Informix-l... (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list– Skjul sitert tekst–

– Vis sitert tekst –

Reply With Quote
  #10  
Old   
theBP
 
Posts: n/a

Default Re: Dbspace recovery - 03-02-2010 , 10:28 AM



On 02/03/2010 14:52, pow43 wrote:
Quote:
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:

snip

You cannot just plug a dbspace from instance1 into another instance2

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.