ITEM: AW2473L
DB2 6000 2.1.1/migrating data base
Response:
env:
db2 v2.1.1,aix 4.1, 7015-990
desc:
restoring db2 v1.2 into v2.1.1. Restore failed wiht sql0298 sqlstate=
428b2.
action:
The customer is trying to restore a 25gig v1 database into v2. Before
doing the restore he first created a brand new v2 instance which had
the same name as v1 instance. He than created a v2 database where
he put all the 3 tablespace on a separate logical volume on a separate
filesystem. Each tablespace had 8 containers. His userspace was on
a 42 gig file system. when doing a restore he got sql0298 which says
that container path in invalid. He removed all his containers and tried
restore again but it failed. I conferenced Allan and he said that
he had worked with kinda problem earlier and that problem is at
toronto. Allan said that he would try to locate that pmr to see what
the resolution was and do a little research to see if he can come up
with something. Customer also wanted to know how to write scipt to
create tablespaces ??
action:
researched and found nothing that resembled this situation. Came
across pmr0x555.302 which more or less discusses the same problem but
a bad path was never encountered.
DESC:
DB2/6000 1.2 Migration/Restore --> DB2/6000 2.1.1
.
The results of the migrate/recover using DB2/2 2.1.1 as a
front-end to DB2/6000 2.1.1.
.
The OS/2 GUI crashes under identical circumstances.
.
- Message pops up that the recover job is suspended because
tablespace containers need to be redefined.
- I select redefine.
- The DB2DD GUI crashes, running DB2/2 2.1.1 on OS/2.
.
The GUI simply just disappears from the machine!
I can restore the database if I use a DB2/6000 2.1.1 backup,
even remotely from OS/2. It works perfectly.
.
Again, it's only the migration or conversion during the restore
that fails.
I wanted to give you some additional information. If I restore
a V2.1.1 backup to this database everything works fine. I can pause
the restore for container definition, etc. It's only when I attempt
to do the migrate/restore of a V1.2 database that the GUI crashes
and I receive error messages such as: SQL0298N with a SQLSTATE of
428B2.
.
I'm now attempting to do the restore through the DB2/2 GUI. I'll
keep you posted. Please keep me posted if there are anymore PTFs I
need to apply.
.
---------------------------------------------------------------------
.
I've been working with Allan C., and I've opened a problem on
DB2. Here's what's happened since my original note:
.
1. Applied U441788, and updated instance, as per Allan C.
- Successful
2. Started a redirected restore through the the DB2DD GUI
- Recover starts,
- Message pops up that the recover job is suspended because
tablespace containers need to be redefined.
- I select redefine.
- The DB2DD GUI crashes, running on a 150 X-Station
.
Is this a known problem? I still can't start the restore.
.
----------------------------------------------------------------------
FROM: Dale M. in Toronto.
.
If you are going to pre-allocate your containers you must use the
redirected restore option from db2dd. Otherwise we will drop your
existing db and use the default container definitions.
.
----------------------------------------------------------------------
.
FROM: Joe
SUBJECT: Original Question
.
I have a 25Gb DB2/6000 1.2 offline database backup to 8mm tape.
I have a new DB2/6000 2.1.1 instance. I have created the new
database with 8 containers in each tablespace. Each container in
userspace1 has been mounted on a 4Gb logical volume, making
userspace1 large enough to hold a 32Gb database. All tablespaces
and containers report "normal". I can do a DB2 Connect to this
database, so all appears well. All containers are mounted and
normal.
.
I started the restore of the V1.2 database backup. It somehow
ignores the mounted containers, and fills up the home file system
where the instance owner/SQL00001 resides. If I attempt to restore
a V2.1.1 backup it succeeds! The V2.1.1 backup is only 8Gb, but it
definitely uses the LVs mounted on the containers in the tablespace.
After the restore, the containers show 7% full, (df command).
.
Are there any special considerations? I have read the DB2 Admin.
guide on database migration. I have read in the forums that this
method is supported.
Dale: tried redirected database restore through db2/ failed GUI crashed
tried test on DB/2 same crash error FYS3175 DB2tmui.dll
both GUI's crash after redirected restore
applied Db2/6000 ptf U441788 succesfully/same problem on restore occurred
ACTION:
I created the sample database under v1.2. I took
this backup and over to a system with a v2.1.1.2
on it. I made sure that both systems are using the
same user id. Then on the v2.1+ system I did the
following:
.
TEST 1
=======
1. created a database called sample
2. restored the v1.2 backup
RESULT: This worked
.
TEST 2
=======
0. dropped the new database
1. recreated the database sample w/ the container
"userspace" for the user table space.
(The TS was mount and permission set correctly
prioir to creating the DB.)
2. restored the v1.2 backup and as documented and
expected the TS container was not used.
.
TEST 3
=======
0. dropped the new database
1. recreated the database sample w/ the container
"userspace" for the user table space.
(The TS was mount and permission set correctly
prioir to creating the DB.)
2. restored the v1.2 backup via db2d so as to use
the redirect option. The GUI through up an
error window which remained blank and then the
entire GUI came crubmling down.
.
SUMMARY
=======
You can not restore a version 1.2 database to a v2.1.1.2
database via the redirect restore method.
Begining of Text for PMR 0483X,49R,000
ACTION:
Mail describing problem and steps taken by customer.
This has been editted for legability.
The most resent information is first. So, as you
read you will be moving into the history of the problem.
.
DESC:
DB2/6000 1.2 Migration/Restore --> DB2/6000 2.1.1
.
The results of the migrate/recover using DB2/2 2.1.1 as a
front-end to DB2/6000 2.1.1.
.
The OS/2 GUI crashes under identical circumstances.
.
- Message pops up that the recover job is suspended because
tablespace containers need to be redefined.
- I select redefine.
- The DB2DD GUI crashes, running DB2/2 2.1.1 on OS/2.
ACTION:
I saw the work around mentiond and tried to reproduce
the process; however, I could not get it to work. I
have listed the steps I followed below and the results.
Did I miss something?
.
TEST 0X555,302 WORK AROUND
===========================
1. create mounts .../SQL00001/SQLS0000 etc
I created upto SQLS0004 for a total of
5 containers. Mounted FSs, moved file SQLSEG.NAM,
and remounted in correct place. Also,
made sure ownership is correct.
2. db2 create db sample user managed by system ...
- this created a v2 db in .../SQL00001
3. db2 restore db sample into sample
- database files were restored into SQLS0000 and
that's it. The migration completed successfully.
Nothing was placed in the other segments. In fact,
them SQLSEG.NAM file was deleted from other segments
and the containers removed from the table space.
.
MOUNT NOT INCLUDED AS CONTAINERS
==================================
1. db2 create db sample
- this created a v2 db in .../SQL00001
2. create mounts .../SQL00001/SQLS0000 etc
I created upto SQLS0004 for a total of
5 containers. Mounted FSs, moved files,
and remounted in correct place. Also,
made sure ownership is correct.
3. db2 restore db sample into sample
- database files were restored into SQLS0000 and that's it.
The migration completed successfully. No other directory
was used for data storage.
.
Also, I did mention that there might me a work around to
customer based on what I had seen in the PMR 0X555,302;
hwoever, he would still like to get it to work as a
redirected restore if possible.
Redirected restore is not supported for a V1 database. The intention of
redirected restore is to allow redefinition of containers. V1 databases
do not have containers to redefine. I have not tried personally, but
apparently, the following scenario should work:
o create database
o create required containers and do mounts if required (do not move any
files around)
o perform the restore/migration
Guess the above scenario does not work. Tried creating 4 directories
under SQL00001 named SQLS0000 to SQLS0003. Only SQLS0000 was used.
Sent Joseph a note letting him know that redirected restore is not
supported for a V1.2 backup. When restoring a V1.2 database, all files
will be restored to directory SQLS0000. There will be 3 directories
under SQLS0000 named SQLT0000.0, SQLT0001.0 and SQLT0002.0. These
correspond to the tablespaces created in a default V2 database. Also
told him that we are looking into the problem where the db2dd GUI
disappears when attempting to perform a redirected restore on a V1.2
database.
In order to have the V1.2 database be restored to mutiple logical
volumes, create a V2 database specifying a value for numsegs equal to
the number of logical volumes to be used. Under the database directory,
mount all necessary SQLS000x directories required. Restoring the V1.2
database will use all the logical volumes mounted. This information has
been sent to Joe via mail.
Called Joe to find out whether the method sent to him by mail was
sufficient to allow him to continue with his work. He was not in. Left
a message for him to call me back or to send me mail.
Joe sent me a profs note indicating that the restore still did not
work. He said that he was going to install V2 and then attempt to
migrate the database without doing a restore. Called Joe to find out
whether he specified a value for numsegs and to find out the status of
the problem. Joe was not in. Left a message for him to either call me
back or send me a profs note. Waiting for Joe to get back to me.
Joe sent me a note indicating that he was able to restore the v1.2
database to V2.1 using the procedure described above where the database
should first be created and then the file systems mounted under the
SQLSxxx directories. He no longer has a problem with the restore/
migrate of a V1.2 database to V2.1. He does however still have a problem
where the database director windows will simply close under the
following scenario:
1) logon to X-station and set display variable
2) start motif window manager
3) start db2 database director GUI
a. click on database
b. click on tablespaces
c. click on pull-down "Open as Containers"
- containers are displayed
d. close "Conatiners" display
e. choose another tablespace
- click on Containers
- GUI hangs, vertical bars are painted in the "Containers"
detail view
- db2dd will crash after about 5 minutes on a X-station 150
Support Line: DB2 6000 2.1.1/migrating data base ITEM: AW2473L
Dated: June 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:24
Comments or suggestions?
Contact us