Quick Ontape -r rootdbs question
Doug asked whether an ontape -r restore of a single dbspace (with chunk-path redirection) would also overwrite rootdbs and thus clobber other databases on the target instance. Art Kagel replied that redirection only changes where chunks are written, and that with a dbspace restriction the reserved pages/rootdbs are not restored. Doug's attempt then failed with the dbspace 'not in the dbspace table' between 9.4FC2 and 9.4FC8 servers; Kern Doe argued the real issue is that a dbspace-level restore can only be done into the instance the archive came from, not a different server (a full restore would be needed). The thread ends with Doug asking further questions and no confirmed resolution.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
Yes. Ontape only restores the entire instance or a dbspace. The chunkname/path
redirection only changes where the chunks' data is written NOT which
chunks/dbspaces are written. If you also include a dbspace restriction, then
the reserved pages and rootdbs are not restored (unless you requested it).
Art S. Kagel
----- Original Message -----
From: Doug Fossmeyer <ids@iiug.org>
At: 7/28 10:59:51
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Thank you Art, this will work much better than dbexport/import or
onunload/onload we used to use from 7x.
>>> kagel@bloomberg.net 07/28/2006 8:51 AM >>>
Yes. Ontape only restores the entire instance or a dbspace. The chunkname/path
redirection only changes where the chunks' data is written NOT which
chunks/dbspaces are written. If you also include a dbspace restriction, then
the reserved pages and rootdbs are not restored (unless you requested it).
Art S. Kagel
----- Original Message -----
From: Doug Fossmeyer <ids@iiug.org>
At: 7/28 10:59:51
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hi again. We attempted this process and it failed claiming the dbspace was not
in the dbSpace table. I suspect the issue is the version difference between
servers (we are testing FC8).
Server A has 94FC2
Server B has 94FC8
ontape -s -L 0 from Server Acreate new dbspace on Server B with exact name and chunks as on Server A
ontape -r -D yadda from Server B (Failed with the above message)
We expected 9.4FC8 to be a minor version upgrade capable of addressing the
9.4FC2 ontape -s -L 0 and for the restore to work. So in order for this to
work both servers must be on the same minor version rev? If it is capable of
working with in minor version levels any ideas on what is wrong?
As mentioned the dbspace is the same, the chunks and paths are exactly the
same, I created a database in the dbspace the same name as the archived
database. Oncheck's were run to verify everything is ok.
Thanks in advance,
Doug
>>> DougF@SpokaneSchools.org 07/28/2006 7:54 AM >>>
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
I suspect the problem may not be the version differences but it may be what
you are trying to test. Correct me if understood it wrong, so you guys are
trying to restore databaseA siding in dbspaceA of server1 to server2 that is
having exactly # of dbspaces, # chunks, etc? (yes/no)
huhmm...I don't think it's possible because rootdbs of server2 doesn't know
anything about the databaseA in dbspaceA -- that ontape tape belongs to
server1 unless you do the whole system restore (NOT with -D option) to
server2. It is only possible to use -D if the ontape backup belongs to server2
and you are restoring dbspaceA of server2, but then you also need related
logical logs to complete. Share with me what you find next.
Regards
Doug Fossmeyer <DougF@SpokaneSchools.org> wrote:
Hi again. We attempted this process and it failed claiming the dbspace was not
in the dbSpace table. I suspect the issue is the version difference between
servers (we are testing FC8).
Server A has 94FC2
Server B has 94FC8
ontape -s -L 0 from Server Acreate new dbspace on Server B with exact name and chunks as on Server A
ontape -r -D yadda from Server B (Failed with the above message)
We expected 9.4FC8 to be a minor version upgrade capable of addressing the
9.4FC2 ontape -s -L 0 and for the restore to work. So in order for this to
work both servers must be on the same minor version rev? If it is capable of
working with in minor version levels any ideas on what is wrong?
As mentioned the dbspace is the same, the chunks and paths are exactly the
same, I created a database in the dbspace the same name as the archived
database. Oncheck's were run to verify everything is ok.
Thanks in advance,
Doug
>>> DougF@SpokaneSchools.org 07/28/2006 7:54 AM >>>
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hi, thank for your response. We thought this would work from server A to
Server B if we had a dbspace, chunks, links, and a dbname on Server B matching
what is on server A (except Server B has just placeholder names and no real
tables or data). So if on server B we do a dbimport of the db/data or a onload
of the db/data and THEN the ontape -r -D from Server A to Server B would work?
I was using as a initial reference the email posting from 6-22-06 from Radhe
Webster, very similar scenario. The posting said they use the ontape to
restore from server a to server b regularly with success. We had been using
onunload but it has failed twice now with an ISAM error so we are looking for
alternatives that do not include dbimport or Replication or HPL.
Thanks,
>>> kern_doe@yahoo.com 07/28/2006 12:19 PM >>>
I suspect the problem may not be the version differences but it may be what
you are trying to test. Correct me if understood it wrong, so you guys are
trying to restore databaseA siding in dbspaceA of server1 to server2 that is
having exactly # of dbspaces, # chunks, etc? (yes/no)
huhmm...I don't think it's possible because rootdbs of server2 doesn't know
anything about the databaseA in dbspaceA -- that ontape tape belongs to
server1 unless you do the whole system restore (NOT with -D option) to
server2. It is only possible to use -D if the ontape backup belongs to server2
and you are restoring dbspaceA of server2, but then you also need related
logical logs to complete. Share with me what you find next.
Regards
Doug Fossmeyer <DougF@SpokaneSchools.org> wrote:
Hi again. We attempted this process and it failed claiming the dbspace was not
in the dbSpace table. I suspect the issue is the version difference between
servers (we are testing FC8).
Server A has 94FC2
Server B has 94FC8
ontape -s -L 0 from Server Acreate new dbspace on Server B with exact name and chunks as on Server A
ontape -r -D yadda from Server B (Failed with the above message)
We expected 9.4FC8 to be a minor version upgrade capable of addressing the
9.4FC2 ontape -s -L 0 and for the restore to work. So in order for this to
work both servers must be on the same minor version rev? If it is capable of
working with in minor version levels any ideas on what is wrong?
As mentioned the dbspace is the same, the chunks and paths are exactly the
same, I created a database in the dbspace the same name as the archived
database. Oncheck's were run to verify everything is ok.
Thanks in advance,
Doug
>>> DougF@SpokaneSchools.org 07/28/2006 7:54 AM >>>
Hi,
If you attempt to use the ontape -r with redirection of the chunk names
parameters for a specific database, is there any effect on rootdbs for the
other databases? In other words if we have a 2 server set up described below
and restore one dbspace, will ontape also restore the critical dbspace rootdbs
and affect the other database's in the second server?
primary server 1 (ontape -s -L 0)
database A (dbspace A)
database B (dbspace B)
database C (dbspace C)
backup server 2
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
create a dbspace and chunks in server 2 of database A; execute ontape restore
of dbspace A. Does this also restore the root dbspace thus over writing the
system tables for dbspace D, E, F so that Server 2 dbspace D, E, F remain
intact with the addition of dbspace/database A?
If so we would expect to see:
server 2
database A (dbspace A)
database D (dbspace D)
database E (dbspace E)
database F (dbspace F)
Thanks in advance,
Doug
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.