Here is how to reproduce:
mkdir /home/dbguest0/IBM_blue
mkdir /home/dbguest0/IBM_red
mkdir /home/dbguest0/IBM_blue_logarch
mkdir /home/dbguest0/IBM_red_logarch
mkdir test
db2 create db IBMblue on /home/dbguest0/IBM_blue
db2 create db IBMred on /home/dbguest0/IBM_red
db2 update db cfg for IBMblue using logarchmeth1
disk:/home/dbguest0/IBM_blue_logarch
db2 update db cfg for IBMred using logarchmeth1
disk:/home/dbguest0/IBM_red_logarch
db2 backup db IBMblue to /home/dbguest0/test
db2 backup db IBMred to /home/dbguest0/test
db2 connect to IBMblue
db2 create tablespace ts1
db2 create schema schema1
db2 "create table schema1.table1(c1 int, c2 varchar(256)) in
ts1"
db2 "insert into schema1.table1(c1,c2)
values(1,'blue'),(2,'green'),(3,'red'),(4,'yellow')"
db2 "select * from schema1.table1"
db2 terminate
db2 backup db IBMblue online to /home/dbguest0 include logs
Backup successful. The timestamp for this backup image is :
20140714125053
db2 -v "restore db IBMblue tablespace (ts1) schema(schema1) from
/home/dbguest0 taken at 20140714125053 transport into IBMred
LOGTARGET /home/dbguest0/IBM_red_logarch"
SQL0293N Error accessing a table space container.
SQLSTATE=57048
When examining the db2 trace and comparing the container TAG to
the global database path in transport CB, in the pmodel layer,
when DB2 builds the dbpath (i.e. local database path) in MPP
environments (see note below) DB2 qualifies the dbpath, but not
the global database path. Typically on the staging database DB2
gets the db / gdb paths from the agent CB, so there are no
problems. But sqlbUpdateContainerTagsForTransport is executed
on the target database and it relies on the transport CB for all
the information. During the initial restore, DB2 does flow
parts of the transport CB back (i.e. dbpath) but not the
gdbpath. So what DB2 does is rebuild the gdbpath using the
dbpath, but this is problematic in rare scenarios (i.e. MPP + db
/ gdbpath that resolve to something else when qualified). This
is because we compare the container's tag file database path
(based on the gdbpath) with the rebuilt gdbpath (which is based
on the dbpath and can be qualified).
Note: This can happen in ESE as well. Resolving of paths does
not always work correctly in transport when you have a single
entry in the db2nodes.cfg file (ESE) and a symbolic link,
dual/sub mount point or other. |
