I have been stuck with this problem since last week.

Server Config
System : Sun E250 ( 2 hard disks - One is a mirror) 1 GB ram
OS : Solaris 7
Db2 : version 7.2
Running software raid for mirroring.

The production and failover servers are identical.

Requirement: Online backup of Production database and restore to failover.

Problem:
When I take a online backup of the production database it works superbly, but when i try to restore it to the failover the following error comes up.

"SQL20153N The database's split image is in the suspended state.SQLSTATE=55040"

The funny thing is I have Not set up a split mirror SUSPENDED I/O mode of database backup on production. It looks like the backup image that comes out is of a split mirror database.

I tried getting it out of the suspend mode using "SET WRITE RESUME FOR DATABASE" , It gave an error that a connection does not exist ( which is right) . Then when i try to connect to the database another error comes up " Unable to connect to database due to a previous restore is still pending" . Looks like a catch 22 situation where each command requires the other to be completed.

Is there some setting to revert back to regular online backup (without Suspended I/O backup procedure) ?

thanks once again ..any input ...any information will be helpful.

Best Regards
brat

what command did you use to backup the database, what files did you move across, and what command did you use to restore the database?

Hi,

For the backups i used the following command
db2 BACKUP DATABASE <dbname> ONLINE TO /export/home/db2inst1/<backup-image-dir>

The files were all the log files from the first active log file ( retrieved from get db cfg for <database-name>). They were tarred along with the database image and transferred to the failover server, wehre they were untarred and a restore command was issued as follows

RESTORE DATABASE <database-name> FROM <dbimage-path> TAKEN AT 20040615172021 TO /export/home/db2inst1 INTO <database-name> WITH 2 BUFFERS BUFFER 1024 WITHOUT PROMPTING;

Any help is appreciated.

I am seeing some confusing thing here.first if you have a mirrored disk then your steps will be

1. db2 set write suspend for database.
2. use appropiate OS commands to split the mirroe at the souce db.
3. resume I/O on the souce system.
4. starts the instance on the target system.
5. db2inidb <database name> mirror/standby using <config file>


the above steps are generally use when you don't need to backup the database (with the back command), you use the OS mirroring to get the same functionality.

what I am seeing is that you are confused on the mirror part of the disk.You did perform a backup , then use that backup and the log files to bring the target upto date.
It may happen sometimes and there is always the chance that the two mirrored backups are not in sync(you write to one mirror but you are using the other mirror at the target system) there is also some half page problems.

write suspend is useless with out the dbinit command.

regards,

mujeeb

Hi mujeeb,
thanks for your reply.

Actually I dont want a mirrored backup procedure ( although we have soft raid running) .
Once about a week back I had done
write suspend > backup using backup command > write resume
After that I found out that we cant use the write suspend/resume commands if we are not using the split mirror backup procedure.

Now when i try to take a full backup (without using write suspend/resume) of the database ( online or offline ) and try to restore it on my failover system , it gives the error mentioned below.

"SQL20153N The database's split image is in the suspended state.SQLSTATE=55040"

So basically now, I have no mirror split set up... and my full backup ( old fashioned way) gives the above error.

I need to know what parameters have i inadvertantly set/unset , that my backup images are unable to be restored.

I tried a db2dart on the images, it shows : splitMirrorFlag = 000001 where as 2 weeks back the images show this flag as 00000


going crazy!!!! I NEEEEEEDDDDDd DELIVERENCEEEEEEE!!!

Brat.

Not sure what the problem is? You may want to open a problem with IBM and ask them for some assistance.

All things being equal, the commands you are running should have worked. For the online backups, you will have to bring some of the logs across and do a rollforward (for the online backup); but that should have generated a "rollforward pending" status, not the split-image error.

did you try creating a "temp" database in the same instance where your original one is, issue the full backup, then the online backup and try restoring this one. If you get the same error, there must be something within the instance that still thinks it is a split image. If you don't get the error, then it has to be something within the database. Wish I could offer you better information ...

Have no clue if it would matter, but maybe try doing the redirected restore into an empty database and set all the containers on the "target" system:

create db dbname ...

ie --
restore db origdbname from ... into newdbname replace existing redirect ... ;

set tablespace containers for 1 using (path/file ...);
set tablespace containers for 2 using (path/file ...);

..
..

set tablespace containers for n using (path/file ...);

restore db origdbname continue;

maybe that will work ...

Good luck.

I don't have any clue why it is happening.But I am thinking that during the
first procedure it sets some flag at the source db and further backups
is carrying that flag. can you do the db2dart at the source db and inspects
its output, also there are check the facilities of db2dart that can help you.
I am not helpful over here.

regards,

mujeeb

hi guys,
Thanks chimes and mujeeb for ur replies.

Chimes:
I tried what you suggested, creating a new database and doing a full backup... it seems to work fine so as u mentioned the problem lies with my production database.

I also tried a redirect restore, but it just goes back to the same problem. I didnt have the inclination to try it again.

Mujeeb:
Thanks dude.

I still need the reason for my back up images nnot working

For now anyone facing this problem the stop gap solution to have a backup of ur production is to actually create a split mirror.
i went through the following steps:
1) on the failover system drop all versions of production database
2) tar-gz the following folders from your production
i) <home directory of your instance>/<folder containing the database>
* < folder containing the database> = the folder used during creation of database. It is mostly called DATA
ii) <the container folders>
iii) <home directory of your instance>/<folder with instance name>
3) copy them over to the other system where you want a copy of the production
* note that the failover (other) system has to have the exact same file/folder structure as the production.
4) after untarring and extracting the files/folders to the appropriate folders on the failover, catalog the database on the failover
=> catalog database <db-name> as <alias> on <path>
*<path> = default path of the instance mostly like /export/home/db2inst1
5) os-prompt# db2inidb <db-name> as Mirror. this will put the database in a rollforward pending mode.
6) Copy the latest log files from the production to the failover while maintaining the path
7) => rollforward to end of logs and complete

and VOILA! you have an exact same copy of the database on a failover system. If you wish to keep the failover upto date , simply issue the following command => db2inidb <db-name> as standby. This will put the database in a rollforward pending mode and all you have to do is keep a cron job to copy over the latest logs to the failover. And issue a rollforward database when required.

If anypart is unclear do not hesitate to contact me at bharat51@hotmail.com

Cheers
brat.

sorry i had to bring thisproblem back on the first page... Anyone any ideas ?? am still stuck with this...
Help!!!!
-brat.