Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Problem restoring Informix rootdbs with Netbackup 4.5FP6. ASSERT: file bar_unix.c line 1253

Created: 03 Jun 2009 • Updated: 21 May 2010 | 2 comments

Environment:

Solaris 8
IBM Informix Dynamic Server Version 9.40.FC6
Netbackup 4.5 FP_6

This is an old version and Symantec doesn't support any more.

I'm trying to recover a production database in a test environment.

My backup has no problems but when I try to restore in bar_act.log I have the following problem.

************************************************** ******
2009-04-14 10:29:44 16858 16856 Begin cold level 0 restore rootdbs (Storage Mannager copy ID: 1 1237915000).
2009-04-14 10:29:44 16858 16856 ASSERT: file bar_unix.c line 1253 - contact product support
2009-04-14 10:29:44 16858 16856 See also: /tmp/core.16858
2009-04-14 10:31:53 16858 16856 Process 16858 received signal 11. Process will exit after cleanup.
************************************************** *******

But the log in Netbackup shows me that the recover of rootdbs was succesfull and continue restoring all dbspaces without problems.

But when I tried to recover logs it shows me the following error
************************************************** *****
2009-05-20 20:00:10 5575 5573 Unable to start the logical log restore: plogdbs which contains a logical log or physical log file
is being restored and rootdbs has not been physically restored.
If the ROOT DBspace or a DBspace containing the physical log or a logical
log file is restored, then the ROOT DBspace and all DBspaces containing
a logical log file or physical log file must be physically restored..
2009-05-20 20:00:10 5575 5573 /informix/bin/onbar_d complete, returning 131 (0x83)
************************************************** ***

I found this  in /opt/openv/netbackup/logs/infxbsa

When I restore rootdbs, I have the following messages:

11:58:24.990 [10962] <4> closeApi: INF - server EXIT STATUS = 0: the requested operation was successfully completed
11:58:24.990 [10962] <4> close_image: INF - restore completed SUCCESSFULLY
11:58:24.990 [10962] <4> close_image: INF ---- end of Restore ---
11:58:24.990 [10962] <4> VxBSAEndTxn: INF - entering VxBSAEndTxn.
11:58:24.990 [10962] <4> VxBSAEndTxn: INF - Transaction being ABORTED.
11:58:24.990 [10962] <4> VxBSATerminate: INF - entering VxBSATerminate.
11:58:24.990 [10962] <4> VxBSAGetEnv: INF - entering GetEnv -BBSA_DEBUGFD
11:58:24.990 [10962] <4> VxBSAGetEnv: INF - returning -
************************************************** *****8
When I restore other dbspaces I have the following the Transaction es commited instead of Aborted.

13:59:58.953 [2320] <4> closeApi: INF - EXIT STATUS 0: the requested operation was successfully completed
14:00:03.950 [2320] <4> closeApi: INF - server EXIT STATUS = 0: the requested operation was successfully completed
14:00:03.950 [2320] <4> close_image: INF - restore completed SUCCESSFULLY
14:00:03.950 [2320] <4> close_image: INF ---- end of Restore ---

14:00:03.950 [2320] <4> VxBSAEndTxn: INF - entering VxBSAEndTxn.
14:00:03.950 [2320] <4> VxBSAEndTxn: INF - Transaction being COMMITED.
14:00:09.645 [2320] <4> VxBSATerminate: INF - entering VxBSATerminate.
14:00:09.645 [2320] <4> VxBSAGetEnv: INF - entering GetEnv - NBBSA_DEBUGFD
14:00:09.645 [2320] <4> VxBSAGetEnv: INF - returning -

The difference is with rootdbs doesn't commit XBSA transaction but the restore is succesful. It writes all information to continue recover all dbspaces, but  XBSA is not finishing the transaction and leaves rootdbs with a flag that doesn't close operation.

Two years ago I recover the same  server, but I haven't found any reference to this error.

I'm completely lost, any help I really appreciate it.

Comments 2 CommentsJump to latest comment

Abesama's picture

rootdb - then it is not an alternate-name-restore, just alternate-client-restore.
I do not know much about Informix restore, but I found these TNs.

if it turns out to be a bug, you might need to upgrade.
because of a bug, or because of whatever else, it's also possible that the backup itselfl is not done properly/damaged.

http://seer.entsupport.symantec.com/docs/319298.htm

http://seer.entsupport.symantec.com/docs/304542.htm

http://seer.entsupport.symantec.com/docs/282364.htm

http://seer.entsupport.symantec.com/docs/285088.htm

Good luck!

Abe

Anger Management

Abesama's picture

rootdb - then it is not an alternate-name-restore, just alternate-client-restore.
I do not know much about Informix restore, but I found these TNs.

if it turns out to be a bug, you might need to upgrade.
because of a bug, or because of whatever else, it's also possible that the backup itselfl is not done properly/damaged.

http://seer.entsupport.symantec.com/docs/319298.htm

http://seer.entsupport.symantec.com/docs/304542.htm

http://seer.entsupport.symantec.com/docs/282364.htm

http://seer.entsupport.symantec.com/docs/285088.htm

Good luck!

Abe

Anger Management