Solved: LMS 3.1 Backups STILL Failing...

rnieuwhof · ‎05-21-2009

I previoulsy started a thread regarding backup failing. The backups still fail after a restore. The platform is Windows and I have tried to ensure that all necessary patches are applied.

<Snip> from ddbbackup.log

VALIDATE TABLE "itemInvUser"."DCRDeviceFilter"

VALIDATE TABLE "itemInvUser"."DeviceTable"

VALIDATE TABLE "itemInvUser"."event_set_table"

VALIDATE TABLE "itemInvUser"."NOS_DbVersion"

VALIDATE TABLE "itemInvUser"."NOS_NEW_DeviceDetailTable"

4 errors reported

SQL error (-85) -- Communication error

SQL error (-101) -- Not connected to a database

[Thu May 21 12:58:48 2009] Validation D:/CSCOpx/backup\44\dfm\database\dfmInv.db failed.

SQL Anywhere Command File Hiding Utility Version 10.0.1.3694

SQL Anywhere Backup Utility Version 10.0.1.3694

Database server not found

[Thu May 21 12:59:55 2009] Backup dfmInv to D:/CSCOpx/backup\44\dfm\database\dfmInv.db failed second time.

[Thu May 21 12:59:55 2009] ERROR(1101): Database dfmInvDb backup failed and . Check the log file for information.

[Thu May 21 12:59:55 2009] Backup failed: 2009/05/21 12:59:55

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Thu May 21 12:59:55 2009] Removing directory D:\CSCOpx\backup\44

*****************************************

Wise men suggested that I either restore the failing DB or re-initialize it. What are the ramifications of re-initializing dfmInvDb? How do I re-initialize the DB if it is required?

Joe Clarke · ‎05-21-2009

No. In this case, the database is clearly corrupt. That said, we have seen one other instance of persistent dfmInv corruption with another customer. We have engaged Sybase to isolate the root cause. In the meantime, the only workaround has been to reinitialize the databases when the problem occurs.

One thing that may help avoid the corruption is to disable anti-virus scanning or the NMSROOT directory as well as disabling third party backup tools from archiving the NMSROOT contents.

View solution in original post

Joe Clarke · ‎05-21-2009

IF you reinitialize the DFM databases, you lose all of the DFM fault information, and any DFM group customizations you may have done. You will need to reinitialize all of the DFM databases along with the two EMC rps files. To do this:

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmInv dmprefix=INV

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmEpm dmprefix=EPM

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmFh dmprefix=FH

Then delete the following two files:

NMSROOT\objects\smarts\local\repos\icf\DFM.rps

NMSROOT\objects\smarts\local\repos\icf\DFM1.rps

rnieuwhof · ‎05-21-2009

Is there any other form of troubleshooting I can do before I re-initialize? Is that even the right thing to do?

Joe Clarke · ‎05-21-2009

No. In this case, the database is clearly corrupt. That said, we have seen one other instance of persistent dfmInv corruption with another customer. We have engaged Sybase to isolate the root cause. In the meantime, the only workaround has been to reinitialize the databases when the problem occurs.

One thing that may help avoid the corruption is to disable anti-virus scanning or the NMSROOT directory as well as disabling third party backup tools from archiving the NMSROOT contents.