Restoring a database to a test system, handling schema differences

[clvrmnky]

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

[clvrmnky]

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.

[clvrmnky]

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.

[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! =-----

[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! =-----

[Steve Pearson]

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

[Steve Pearson]

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