467,858 Members | 1,595 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,858 developers. It's quick & easy.

Restoring a database to a test system, handling schema differences

I've got a database backup from another system which I'd like to restore
to a test system. Both the backup and restore systems are Solaris 8. I
don't recall the DB2 version, but I do know that the backup and restore
versions match. If it matters, I'm only accessing this db via the UNIX
command line, and then programmatically via JDBC (by an app that does
all the actual queries and updates).

I do not have access to the original system.

The problem I'm having is that the tables are being created attached to
a schema that does not exist on my test system. This is probably due to
the fact that the instance names are different. That is, the table is
started and altered by a "userid1" user, so table foo is accessed via
USERID1.FOO. Of course, the default instance or userid I'm testing with
is something like "clvrmnky", so the default tables are never found.

Is there a way to change the problem table schema to something else on
restore? Can this be changed in the backup image?

Should I just create a new instance name that matches the schema?

Should I just alter every single table so that it is essentially moved
to the a new schema I create?

I looked a bit into a redirected restore, but this seems to concern
itself more with the locations of tablespaces. This does not seem to be
my problem.

--
cm
Nov 12 '05 #1
  • viewed: 3366
Share:
6 Replies
On 19/04/2004 6:00 PM, clvrmnky wrote:
I've got a database backup from another system which I'd like to restore
to a test system. Both the backup and restore systems are Solaris 8. I
don't recall the DB2 version, but I do know that the backup and restore
versions match. If it matters, I'm only accessing this db via the UNIX
command line, and then programmatically via JDBC (by an app that does
all the actual queries and updates).

I do not have access to the original system.

The problem I'm having is that the tables are being created attached to
a schema that does not exist on my test system. This is probably due to
the fact that the instance names are different. That is, the table is
started and altered by a "userid1" user, so table foo is accessed via
USERID1.FOO. Of course, the default instance or userid I'm testing with
is something like "clvrmnky", so the default tables are never found.

[...]
Note to self: just create aliases to the tables in question with the
"correct" schema name. Feeding "db2 create alias ..." a list of tables
in a shell script loop did the trick.
Nov 12 '05 #2
On 19/04/2004 6:00 PM, clvrmnky wrote:
I've got a database backup from another system which I'd like to restore
to a test system. Both the backup and restore systems are Solaris 8. I
don't recall the DB2 version, but I do know that the backup and restore
versions match. If it matters, I'm only accessing this db via the UNIX
command line, and then programmatically via JDBC (by an app that does
all the actual queries and updates).

I do not have access to the original system.

The problem I'm having is that the tables are being created attached to
a schema that does not exist on my test system. This is probably due to
the fact that the instance names are different. That is, the table is
started and altered by a "userid1" user, so table foo is accessed via
USERID1.FOO. Of course, the default instance or userid I'm testing with
is something like "clvrmnky", so the default tables are never found.

[...]
Note to self: just create aliases to the tables in question with the
"correct" schema name. Feeding "db2 create alias ..." a list of tables
in a shell script loop did the trick.
Nov 12 '05 #3
Ian
clvrmnky wrote:
On 19/04/2004 6:00 PM, clvrmnky wrote:
I've got a database backup from another system which I'd like to
restore to a test system. Both the backup and restore systems are
Solaris 8. I don't recall the DB2 version, but I do know that the
backup and restore versions match. If it matters, I'm only accessing
this db via the UNIX command line, and then programmatically via JDBC
(by an app that does all the actual queries and updates).

I do not have access to the original system.

The problem I'm having is that the tables are being created attached
to a schema that does not exist on my test system. This is probably
due to the fact that the instance names are different. That is, the
table is started and altered by a "userid1" user, so table foo is
accessed via USERID1.FOO. Of course, the default instance or userid
I'm testing with is something like "clvrmnky", so the default tables
are never found.

[...]
Note to self: just create aliases to the tables in question with the
"correct" schema name. Feeding "db2 create alias ..." a list of tables
in a shell script loop did the trick.


Or, write your queries to use fully qualified table names. As in,
'select * from userid1.foo' instead of 'select * from foo'

Good luck,


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #4
Ian
clvrmnky wrote:
On 19/04/2004 6:00 PM, clvrmnky wrote:
I've got a database backup from another system which I'd like to
restore to a test system. Both the backup and restore systems are
Solaris 8. I don't recall the DB2 version, but I do know that the
backup and restore versions match. If it matters, I'm only accessing
this db via the UNIX command line, and then programmatically via JDBC
(by an app that does all the actual queries and updates).

I do not have access to the original system.

The problem I'm having is that the tables are being created attached
to a schema that does not exist on my test system. This is probably
due to the fact that the instance names are different. That is, the
table is started and altered by a "userid1" user, so table foo is
accessed via USERID1.FOO. Of course, the default instance or userid
I'm testing with is something like "clvrmnky", so the default tables
are never found.

[...]
Note to self: just create aliases to the tables in question with the
"correct" schema name. Feeding "db2 create alias ..." a list of tables
in a shell script loop did the trick.


Or, write your queries to use fully qualified table names. As in,
'select * from userid1.foo' instead of 'select * from foo'

Good luck,


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #5
Another option, which works in the CLP ('db2') at least: After connecting
to the db, issue the following command:

[ db2 ] set schema userid1

Regards,
-steve p.
-------------------
Steve Pearson
DB2 UDB Development
Portland, OR, USA
Nov 12 '05 #6
Another option, which works in the CLP ('db2') at least: After connecting
to the db, issue the following command:

[ db2 ] set schema userid1

Regards,
-steve p.
-------------------
Steve Pearson
DB2 UDB Development
Portland, OR, USA
Nov 12 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Fischer Ulrich | last post: by
1 post views Thread by Robbert van Geldrop | last post: by
5 posts views Thread by Troels Arvin | last post: by
17 posts views Thread by darien.watkins | last post: by
reply views Thread by jack112 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.