The backup you are running doesn't seem to be online. For online you would have the ONLINE keyword, therefore use the logs. If that's the case, you may recover with the normal restore command, and as you cannot rollforward, you will have to send the file SQLOGCTL.LFH to IBM (I had this problem...
Your must have the S0000003.LOG file in the active log directory: /home/db2inst1/db2inst1/NODE0000/SQL00007/SQLOGDIR/
Get the backup from your history log file like this:
db2 list backup all for <dbname>
The output may look like:
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log...
Your must have the S0000003.LOG file in the active log directory: /home/db2inst1/db2inst1/NODE0000/SQL00007/SQLOGDIR/
Get the backup from your history log file like this:
db2 list backup all for <dbname>
The output may look like:
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log...
When you took the backup, it probably was using one more log file. You need to put it in the active log directory and issue:
db2 rollforward db <dbname> to end of logs
db2 rollforward db <dbname> complete
or try rollforward to a pit:
db2 rollforward db <dbname> to yyyy-mm-dd-hh.mm.ss.nnnnnn...
You can restore without any skeleton:
db2 restore database mytest from <device> taken at <timestamp>
if using TSM:
db2 restore database mytest taken at <timestamp> use tsm
Thanks for your reply Mr.Blom. The situation is that besides the primary key, I dont want duplicates in the second column, but I can allow nulls. I think I was not clear enough from the beginning.
Thanks
Hi all.
I have a table with two columns, a primary key and the other column must be unique index to avoid duplicate values, but allowing multiple nulls. The unique index in DB2 for UNIX does not allow duplicate nulls. How can I solve this issue? Any ideas using triggers or something...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.