resolve webdb sync issue

How to resolve the WebDB synchronization Issues

Sometimes,the WebDB can’t be synchronized with the Primary database,and we should handle it according to the reason why the synchronization fails.

It has about three reasons why the synchronization fails.We can receive the alert mail from WebDB,it has detailed error message.

1.      The database is in use.

The detailed description is:

Executed as user: MXB2B-APPDBSTY\it.service. -- Start To Restore TRN LOG With DateCode After 201012021205 [SQLSTATE 01000] (Message 0)  >> Restore LOG Using  F:\DBBackup\DELL\DELL_tlog_201012021210.TRN [SQLSTATE 01000] (Message 0)  Exclusive access could not be obtained because the database is in use. [SQLSTATE 42000] (Error 3101)  RESTORE LOG is terminating abnormally. [SQLSTATE 42000] (Error 3013).  The step failed.

From above description, we can find that there are some sessions querying the WebDB.  And you should check the sessions information , such as the application name, the database user and the hostname of the client, and the sql   statement which is the most important. You can find out all the information in Enterprise Manager<

After about ten minutes, if the application has not been released , you should contact the related team guys to check the sql statements. With their confirmation , you can kill the session.

 

2.      The size of transactional backup file is large(more than 1 GB).

The detailed description is:

Executed as user: MXB2B-APPDBSTY\it.service. -- Start To Restore TRN LOG With DateCode After 201010241835 [SQLSTATE 01000] (Message 0)  >> Restore LOG Using  F:\DBBackup\DELL\DELL_tlog_201010241840.TRN [SQLSTATE 01000] (Message 0)  >> TRN File Size 9562381532 Bytes Larger Than Max Size 8589934592 Bytes -- Will Try To Restore With FullBackup ( Datecode Later Than 201010241840). See the SQL Server error log for more details. [SQLSTATE 42000] (Error 3201)  RESTORE DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013).  The step failed.

From the above description, we can find that the transactional backup file size is more than 8GB which is the TRNFileMaxSize value in the table : shlstatusm  in fxshippinglog database. You should check with b2b team whether they have done some abnormal operations in the production database. Actually, the size of transactional backup file is always less than 500M,if it is more than 1GB, we should also confirm with b2b team.

If only one or two transactional backup file is more than 1GB and less than 2GB,it will take a little long time to restore the backup files , and only delay the sync for a few minutes. we can have it done by restore job itself. But if there are many more large backup files (beyond 3 files ), it will become more and more slowly when doing the restoring, it’s better to recreate the webdb with the latest full backup file.

The detailed configuration of webdb, please refer to document : 10. Web DB Configuration.pdf

3.      Change the recovery mode on the production database

The detailed description:

Executed as user: MXB2B-APPDBSTY\it.service. -- Start To Restore TRN LOG With DateCode After 201010241835 [SQLSTATE 01000] (Message 0)  >> Restore LOG Using  F:\DBBackup\DELL\DELL_tlog_201010241840.TRN [SQLSTATE 01000] (Message 0). The log in this backup set begins at LSN 5000000023900001, which is too late to apply to the database. An earlier log backup that includes LSN 5000000023300001 can be restored. See the SQL Server error log for more details. [SQLSTATE 42000] (Error 3201)  RESTORE DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013).  The step failed.

If you find the reason why webdb can’t be restored is the above one, we can only create a new full backup file of the primary database in full recovery model , and transfer to webdb server to restore the WebDB. Even though it will take a long time , We can just do it when meeting a truncated log.

capture.jpg

How to resolve the WebDB synchronization Issue.docxa.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/90986/viewspace-745918/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/90986/viewspace-745918/