Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 High Availability (2005)
 Error 14421

Author  Topic 

jcheng
Starting Member

5 Posts

Posted - 2008-09-05 : 19:27:45
Configured log shipping and I can see all the tran log backups were transferred to the secondary server successfully. Also the database was restored properly. However, on the primary server, I get this error message:



The log shipping secondary database SERVER.database has restore threshold of 45 minutes and is out of sync. No restore was performed for 11910 minutes. Restored latency is 0 minutes. Check agent log and logshipping monitor information. [SQLSTATE 42000] (Error 14421). The step failed.



Is there anything wrong with the log shipping setup?

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-09-05 : 23:16:30
What does the log shipping monitor show? How about the jobs on the secondary server?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

jcheng
Starting Member

5 Posts

Posted - 2008-09-08 : 11:18:59
The log ship backup process was ran successfully - no error on log. Both the copy and restore process on the secondary server were ran successfully as well - no error on these jobs either. However, on the primary server log, the LSAlert process failed with the error I mentioned on my post (error: 14421).
Go to Top of Page

jcheng
Starting Member

5 Posts

Posted - 2008-09-08 : 12:00:53
I've checked the log_shipping_monitor_primary and log_shipping_monitor_secondary table in the primary and secondary server respectively, the last_backup_file, last_copied_file and last_restored_file have the same file name.

I'm still getting the 14421 error.

Thanks.
Go to Top of Page

mvmanohardba@gmail.com
Starting Member

1 Post

Posted - 2008-10-02 : 18:04:45
Hey. I have the same problem and I didn't find any good solution even after googling all over internet. Please suggest us how to fix this.

Thanks a lot.
Go to Top of Page

saurabhsrivastava
Posting Yak Master

216 Posts

Posted - 2008-10-03 : 16:32:48
I am sure we are discussing about SQL server 2005 but want to confirm.
1)What is Windows version and service pack on both primary and secondary
2) What is SQL Server service pack on both primary and secondry server
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-10-03 : 16:41:14
Althought those answers typically will help us, I seriously doubt it is going to help us with this log shipping issue.

saurabhsrivastava, what will you reply with once the answers are provided? How will the answers affect log shipping?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

dcunningham
Starting Member

25 Posts

Posted - 2008-10-04 : 16:50:52
I have found in the past that if you find the file copy & restore processes (jobs) are completing sucessfully, and you've verified that your trn files are being created in the log shipping folder you specified, then the next step in fixing the LS Alert job failure is to determine if a previous attempt at setting up log shipping was completely removed from the system tables for job history and for log shipping. (I don't have those names off the top of my head right now). But in order to fix this, you'll want to stop/delete your current log shipping configuration. Clean-up the dmv / system tables by removing all references to your log shipping target / source. Then turn off all T-Log, Full, & Diff backup jobs on the source db. If jobs are running - let them finish. Then take a full backup of the source database. Restore it to the target database server using 'no recovery' option. When the db restore is finished, it should have an icon after the db name stating that it is 'Restoring' in SSMS. Now you are ready to reinitialze your log shipping. Having verified that all the foundation work has been done, ie. using accounts that have the correct permissions on all your folder used in log shipping, verifying the source db has not been doing any other backups while you were getting the target ready, then setup your log shipping again just as you had it before. You'll find the LSAlert job on both source and target is now reporting success now and it will continue to report success from here on out. You should be good to go. Remember that a target database of log shipping can not be used for any data processing. It is there as a warm standby for DR purposes. If you want to use it in a test environment, just restore the db with full recovery and use it.

Hope this helps.

Dale
Go to Top of Page

saurabhsrivastava
Posting Yak Master

216 Posts

Posted - 2008-10-09 : 19:43:30
quote:
Originally posted by tkizer

Althought those answers typically will help us, I seriously doubt it is going to help us with this log shipping issue.

saurabhsrivastava, what will you reply with once the answers are provided? How will the answers affect log shipping?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog




By service packs and hotfixes at least we can see if this is not a bug with that sp.
Guys please check what is "backup alert threshold and out of sync alert threshold. These alerts trigger error messages 14420 and 14421"
Check this KBA also
http://support.microsoft.com/kb/329133 http://support.microsoft.com/kb/810969
Go to Top of Page
   

- Advertisement -