In this post, I am sharing one T-SQL Script to identify the last restored Log backup file of the Secondary database in the SQL Server Log Shipping.

The one of the important points in Log Shipping is, both Primary Database and Secondary Database should be in sync.

If both are out of sync, SQL Server stops the Log Shipping and throws error related to log files.

As a SQL DBA, I am facing this kind of common errors of Log Shipping like:
“.trn is too recent to apply to the secondary database”
“Could not find a log backup file that could be applied to secondary database”

Using below T-SQL script, you can find last restored log backup in the Secondary Database which help you to compare with available log backups of Primary Database.

You can also easily find out any pending restore of log backup.

SELECT
	[lss].[primary_database]
	,[lss].[last_copied_file]
	,[lss].[last_copied_date]
	,[lssd].[secondary_database]
	,[lssd].[last_restored_file]
	,[lssd].[last_restored_date]
FROM [msdb].[dbo].[log_shipping_secondary] AS lss
INNER JOIN [msdb].[dbo].[log_shipping_secondary_databases] AS lssd
        ON [lss].[primary_database] = [lssd].[secondary_database]
WHERE [lss].[primary_database] ='Primary_Database_Name'
ORDER BY [lss].[primary_database]

What are common reasons which breaks or stops the Log Shipping?

• Recent modifications on the shared folders.
• Human error like, either someone used the option of truncate only or switched the recovery model.
• date/time for the windows servers unmatching due to any DST activities.
• Datafile added on Primary on different drives then you need to apply that on secondary with move until that your log shipping restore job will fail.
• Any I/O,Memory,N/w bottleneck.
• Your tuf file is missing.
• You may have set the incorrect value for the Out of Sync Alert threshold.
• Might be you have scheduled the jobs in same time.
• Might be your MSDB database is full.

I’m getting the below error message in restoration job on secondary server, WHY?

” [Microsoft SQL-DMO (ODBC SQLState: 42000)]

Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set

begins at LSN 7000000026200001, which is too late to apply to the database. An earlier

log backup that includes LSN 6000000015100001 can be restored.

[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally “.

Was your sql server or agent restarted yesterday in either source or destination ? because the error states there is a mismatch in LSN. A particular transaction log was not applied in the destination server hence the subsequent transaction logs cannot be applied as a result.

You can check log shipping monitor \ log shipping tables to check the which transaction log is last applied to secondary database.

Incase if you are not able to find the next transaction log in secondary server shared folder, you need to reconfigure log shipping.

What are your basic steps to reconfigure the Log Shipping?

• Disable all the log shipping jobs in source and destination servers.
• Take a full backup in source and restore it in secondary server using the With Standby option.
• Enable all the jobs you disabled previously in step1.

Is it possible load balance in log shipping?

Yes: its possible in log shipping, while configuring log shipping you have the option to choose standby or no recovery mode, there you select STANDBY option to make the secondary database readonly.

Can I take full backup of the log shipped database in secondary server?

No: You cannot take the full backup.

What are the benefits of Log Shipping?

• Log shipping doesn’t require expensive hardware or software. While it is great if your standby server is similar in capacity to your production server, it is not a requirement. In addition, you can use the standby server for other tasks, helping to justify the cost of the standby server.
• Once log shipping has been implemented, it is relatively easy to maintain.
• Assuming you have implemented log shipping correctly, it is very reliable.
• The manual failover process is generally very short, typically 15 minutes or less.
• Depending on how you have designed your log shipping process, very little, if any, data is lost should you have to failover. The amount of data loss, if any, is also dependent on why your production server failed.
• Implementing log shipping is not technically difficult. Almost any DBA with several months or more of SQL Server 7 experience can successfully implement it.

Once the primary server comes back online, is it a difficult process to switch back to the primary database server?

• Traditionally, depending on the size and number of database that are invloved in logshipping, it may or may not be difficult.
• Database size and your network bandwidth matters a lot. Normally, you just have to resetup log-shipping. Meaning – point all your apps to primary and in background, do a full backup of primary, copy that to secondary server and restore it with no-recovery with subsequent log backups.
• To minimize the downtime, you can use “Reverse logshipping” will prove to be a huge help.

Will changing the Recovery model to Full (from simple) have any issues?

Yes. Changing recovery model breaks the log chain.

Will my existing backups (using Symantec Backup Exec) be affected by enabling log shipping and switching to a full recovery model?

Once you setup logshipping, there is no need to take any additional log backups. In fact, any adhoc log backups will break the log chain. Use COPY_ONLY backups.

There are two servers. one is primary and the other is secondary. primary is on production server.

• Logshipping configured and working fine. Suddenly, after some days, the sync between the servers is not there.
• What is the immediate action?
• First thing I’d do is check the backup log job and the copy job which copies the job from the primary to secondary and after that check the restore job which restores the log on the secondary. If there are no errors there then I’d start looking in msdb at the log shipping tables and see if I could determine the error from there.

Do we require any endpoints for Log Shipping?

We don’t need to create endpoints or assign port in log shipping, which is required for database mirroring.

What are the log shipping frequent issues you have faced?

It depends. I have seen some issues like transaction log cannot restored on the secondary database which is due to that the transaction log sequence is broken.

You might find that the last backed up/copied/restored files do not reflect correctly in the log shipping reports when you use a remote monitor server. What is this issue?

The last copied and restored file will show up as null if the monitor instance is not on the same box as the secondary instance. The last backed up file will show up as null if the monitor instance is not on the same box as the primary instance if the select @@servername value is not used as the monitor server name while configuring the log shipping monitor.

What do you know about the below error?

Error: During startup of warm standby database ‘testdb’ (database ID 7), its standby file (‘<UNC path of the TUF file>’) was inaccessible to the RESTORE statement. The operating system error was ‘5(Access is denied.)’.

If you have configured Log Shipping with STANDBY mode on SQL Server 2008 and the destination folder for the TLOGS uses a remote server on which the sqlservice/sqlagent is not a Local Admin, then the restore job will fail every time.

The sp_resolve_logins stored procedure runs successfully; however, it does not perform the expected modifications to the security on the secondary server. Why?

The sp_resolve_logins stored procedure requires an up-to-date BCP file of the primary server’s syslogins system table. These logins must already by created on the secondary server.

Log Shipping Backup and Out of Sync alerts are firing, even when the secondary server is updated with the transaction log backups. Is this possible?

Yes. It is possible that the alerts might fire even when the secondary database is being updated. If the alert threshold is set to a value less than double the time between back up and copy or restore jobs, the alerts might be raised.

What are the main differences between Log Shipping and Database Mirroring?

Log Shipping:

• It automatically sends transaction log backups from one database (Known as the primary database) to a database (Known as the Secondary database) on another server. An optional third server, known as the monitor server, records the history and status of backup and restore operations. The monitor server can raise alerts if these operations fail to occur as scheduled.
• It has a manual Failover.
• You can use a secondary database for reporting purposes when the secondary database restore in STANDBY mode.
• The servers involved in log shipping should have the same logical design and collation setting.
• The databases in a log shipping configuration must use the full recovery model or bulk-logged recovery model.
• The SQL server agent should be configured to start up automatically.
• You must have sysadmin privileges on each computer running SQL server to configure log shipping.

Mirroring:

• Database mirroring is a primarily software solution for increasing database availability.
• It has a Automatice Failover.
• Mirrored DB can only be accessed using snapshot DB.
• It maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine.
• Verify that there are no differences in system collation settings between the principal and mirror servers.
• Verify that the local windows groups and SQL Server logins definitions are the same on both servers.
• Verify that external software components are installed on both the principal and the mirror servers.
• Verify that the SQL Server software version is the same on both servers.
• Verify that global assemblies are deployed on both the principal and mirror server.
• Verify that for the certificates and keys used to access external resources, authentication and encryption match on the principal and mirror server.

Does the secondary instance need to be licensed?

I am not the licensing police, and I am not Microsoft – check with your licensing representative to clarify your exact situation. Generally, you can have one warm standby server. However, the second someone starts using it for reporting, testing, or anything else, you need to license it like any other server.

When log shipping is set up, Agent jobs are created to alert me if a backup, copy, or restore fails. How do I get notified?

You need to go into the Agent job, pull up Notifications, and choose your method – email an operator, or write to the event log, for example.

Are my logins shipped from the primary to the secondary?

No, they are not. You’ll need to set up a separate method to sync the logins.

What is the difference between the secondary being in Restoring vs. Standby?

Restoring means the database is not accessible. Standby means it is read-only. You make this decision when you set up the log shipping.

If the database is in Standby mode, users can query it – except when a log backup is being restored. You need to decide if a restore job will disconnect users, or if the restore is delayed until after the users are disconnected.

Can we configure log shipping if the SQL server service account is running under local system account?

Yes:If the SQL Server service account is running under the local system account on the primary server, you must create the backup folder on the primary server and specify the local path to that folder here. The SQL Server service account of the primary server instance must have Read and Write permissions on this folder.

What happens to the log shipping in case if you have added the data file on the primary server ?

If both primary & secondary servers as same Disk configuration settings then you can ignore & secondary will takes up, how ever if you changed anything at the Primary side for ex->you have created the folder & added the folder or you have added to any other drive then you have to restore the Next trn backup (i,e after adding the data file) with MOVE option.

Does index operation logging in log shipping?

Yes: It is fully logged operation so it will replicate on secondary as well.

May I shrink the log files of Primary Database?

Yes, you can shrink the log files but make sure that before it copied into Secondary Database.

What do you know about the TUF file?

TUF stands for ->T ->Transaction  U->Undo  F->File  so it is Transaction Undo file.

It contains the Modification that were not committed on the Primary database when the Transaction log backup was in progress and when the log was restored to another database…so at some point of time when the next trn restored on the secondary side then SQL server uses the data from the Undo file and it starts restoring the Incomplete transactions.

My Tuf file deleted unfortunate when the server was shutdown or during the server down time then what will happens to the logshipping?

The log shipping will not work, Incase if you have OS level Backup then you can restore the file then you can be cool.

Can we configure Log Shipping between the different domains?

Yes, we can configure Log Shipping on the server residing in different domains.

After some disk issues at the production server the logshipping continually failed. So I tried a full back up the primary database and restored the secondary database with this full  backup and started the log shipping again. And the logshipping backup of the primary database failed with the error message below:

*** Error: BACKUP detected corruption in the database log. Check the errorlog for more information.

BACKUP LOG is terminating abnormally.

• Stop all user activity in the primary database.
• Switch to the SIMPLE recovery model (breaking the log backup chain and removing the requirement that the damaged portion of log must be backed up).
• Switch to the FULL recovery model.
• Take a full database backup (thus starting a new log backup chain).
• Start the logshipping job.

Does the file name first_file_000000000000.trn indicate that the copy or restore job was unsuccessful?

Each run of the copy and restore job is associated with at least one file. By default, if no files are copied or restored in a certain run of any of these two jobs, SQL Server places first_file_000000000000.trn in the file name field. This may or may not indicate a problem.

Does the sp_resolve_logins stored procedure work for remote logins in SQL Server?

No: The sp_resolve_logins stored procedure only works for typical logins. Any remote logins must be created manually on the secondary server.

Why is the log shipping check box sometimes dimmed in the Maintenance Plan dialog box?

• Multiple databases might be selected for the Maintenance Plan.
• The database that is selected is not in the Full or Bulk Logged Recovery model.
• SQL Server Enterprise Edition is not installed on the server.

Can I configure primary and secondary servers to use SQL authentication to connect to the monitor server?

Yes. It is possible to use either Windows or SQL authentication for primary and secondary servers to connect to the monitor server.

Why backup job failed on Primary server and thrown below error messages?

*** Error: Backup failed for Server ‘<Server Name>’. (Microsoft.SqlServer.SmoExtended) ***

*** Error: An exception occurred while executing a Transact-SQL statement or batch.(Microsoft.SqlServer.ConnectionInfo) ***

 *** Error: BACKUP LOG cannot be performed because there is no current database backup.

This message is thrown because the database is never backed up fully before. Do a full backup of the primary database to solve this issue.

What does sp_resolve_logins do?

At the time of the log shipping role change, the sp_resolve_logins stored procedure requires a BCP file of the syslogins system table from the primary server. This stored procedure loads the BCP file into the temporary table and loops through each login to verify if a login with the same name exists in the secondary server’s syslogins system table.

Execution of this stored procedure is required only if there are new logins created on the primary server after log shipping has been initialized and those same logins are not created on the secondary servers with the same SID.

What are your basic prerequisites for configuring Log Shipping?

• Check SQL Server edition which supports Log Shipping.
• The servers involved in log shipping should have the same case-sensitivity settings.
• The databases in a log shipping configuration must use the full recovery model or bulk-logged recovery model.

How to monitor the Log Shipping configurations and operations?

We can use sp_help_log_shipping_monitor system stored procedure to monitor basic thing about the Log Shipping.

How to display the Transaction Log Shipping Status report on a server instance?

Connect to a monitor server, primary server, or secondary server.

Right-click the server instance in Object Explorer, point to Reports, and point to Standard Reports.

Click Transaction Log Shipping Status.

Which are the basic system tables to track the information about the Log Shipping?

• log_shipping_monitor_alert
• log_shipping_monitor_error_detail
• log_shipping_monitor_history_detail
• log_shipping_monitor_primary
• log_shipping_monitor_secondary

Which permission is requireD to enable a Log Shipping?

You must be a sysadmin on each server instance to enable log shipping.

When Primary instance failed, we require fail-over management so during this exercise what is our big problem to enable a Secondary Instance for further operation?

Typically, the primary and secondary databases are unsynchronized, because the primary database continues to be updated after its latest backup job. Also, in some cases, recent transaction log backups have not been copied to the secondary server instances, or some copied log backups might still not have been applied to the secondary database.

What are your basic steps to perform Fail-over Secondary server in Log Shipping, when Primary Server fails?

• Take the Tail of Log from Primary server if possible.
• Restore Tail of log into all Secondary Database.
• Remove Log-shipping configuration from Primary Server.
• Select any one of Secondary server and bring into online with Alter Database DBName set Online.
• Right click on Primary Database and Generate script for Users and Logins.
• Then move the script to Secondary server to create Users and Logins.
• Re-configure log shipping from New Server (Secondary server).

How we can swap the role between Primary Server and Secondary Server?

• Bring the secondary database online, backing up the transaction log on the primary server with NORECOVERY.
• Disable the log shipping backup job on the original primary server, and the copy and restore jobs on the original secondary server.
• Enable the log shipping backup job on the secondary server (the new primary server), and the copy and restore jobs on the primary server (the new secondary server).

I want to know drop a database which is a part of Log Shipping, How it is possible?

If you are planning to delete a database that is part of a log shipping configuration, remove log shipping first.

You can remove log shipping from a primary database by disabling it in SQL Server Management Studio or by using the log shipping Transact-SQL stored procedures. When you remove log shipping from a database, all log shipping related jobs and schedules will be removed, along with log shipping history and error information. The databases themselves on both the primary and secondary servers will not be changed.

Which stored procedures used to remove a secondary database in Log Shipping?

On the primary server, execute sp_delete_log_shipping_primary_secondary to delete the information about the secondary database from the primary server.

On the secondary server, execute sp_delete_log_shipping_secondary_database to delete the secondary database.

Which stored procedures used to remove a Log Shipping?

On the primary server, execute sp_delete_log_shipping_primary_secondary to delete the information about the secondary database from the primary server.

On the secondary server, execute sp_delete_log_shipping_secondary_database to delete the secondary database.

On the primary server, execute sp_delete_log_shipping_primary_database to delete information about the log shipping configuration from the primary server. This also deletes the backup job.

Delete the secondary database from the secondary server if desired.

I want to perform migration of high availability Log Shipping to Always On Availability Group. What are the prerequisites for Log Shipping?

• The log shipping primary database must reside on the instance of SQL Server that hosts the initial/current primary replica of the availability group.
• For a given log shipping secondary database to be converted to an Always On secondary database, it must:
• Use the same name as the primary database.
• Reside on a server instance that hosts a secondary replica for the availability group.
• Once the backup job has run on the primary database, disable the backup job, and once the restore job has run on a given secondary database, disable the restore job.
• After you have created all the secondary databases for the availability group, if you want to perform backups on secondary replicas, you need to re-configure the automated backup preference of the availability group.

How can I continue to log ship to the former primary server without restoring a database backup?

It is possible to log ship between two servers repeatedly without having to restore the complete database backup. The requirement is that both the primary and secondary servers are available when you perform the role change procedure.

What do you know about the Error Message 14421?

Message 14421 does not necessarily indicate a problem with Log Shipping. This message indicates that the difference between the last backed up file and last restored file is greater than the time selected for the Out of Sync Alert threshold.

What do you know about the Error Message 14420?

Message 14420 does not necessarily indicate a problem with log shipping. The message indicates that the difference between the last backed up file and current time on the monitor server is greater than the time that is set for the Backup Alert threshold.

Logshipping primary database backup job failed with the following error:

 *** Error: Cannot open backup device ‘\\..\BACKUP LOG is terminating abnormally.

SQL Server agent does not have appropriate permission to access the shared folder. Granting access solves this problem.

What is a Log Shipping?

It is a shipping of SQL Server transaction log from one server to another server. It is a one kind of high availability feature of SQL Server.

You can use log shipping to send transaction logs from one database (the primary database) to another (the secondary database) on a constant basis. Continually backing up the transaction logs from a primary database and then copying and restoring them to a secondary database keeps the secondary database nearly synchronized with the primary database.

Would you please explain the basic work of Log Shipping?

Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled.

What are the main operations involved in Log Shipping?

• Log shipping consists of three operations:
• Back up the transaction log at the primary server instance.
• Copy the transaction log file to the secondary server instance.
• Restore the log backup on the secondary server instance.

Does Log Shipping support automatic failover?

A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.

Can we use a secondary database as Reporting purpose?

Yes: we can use a secondary database for reporting purpose.

What is a Primary server or database in Log Shipping?

The primary server in a log shipping configuration is the instance of the SQL Server Database Engine that is your production server. The primary database is the database on the primary server that you want to back up to another server. All administration of the log shipping configuration through SQL Server Management Studio is performed from the primary database.

Can I apply Simple Recovery Model to Parimary database of Log Shipping?

No:The primary database must use the full or bulk-logged recovery model; switching the database to simple recovery will cause log shipping to stop functioning.

What is a Secondary server or database in Log Shipping?

The secondary server in a log shipping configuration is the server where you want to keep a warm standby copy of your primary database. A secondary server can contain backup copies of databases from several different primary servers.

One single Secondary server could be used for multiple primary server.

The secondary database must be initialized by restoring a full backup of the primary database. The restore can be completed using either the NORECOVERY or STANDBY option.

What do you know about the Monitor Server of Log Shipping?

This is an optional server which tracks all of the details of log shipping.

Details like:

• When the transaction log on the primary database was last backed up.
• When the secondary servers last copied and restored the backup files.
• Information about any backup failure alerts.
• Another important thing is,
• Once the monitor server has been configured, it cannot be changed without removing log shipping first.

What kind of different SQL Jobs involved in Log Shipping Operations?

Log shipping involves four jobs, which are handled by dedicated SQL Server Agent jobs. These jobs include the backup job, copy job, restore job, and alert job.

The basic work of these jobs is, How frequently log backups are taken, how frequently they are copied to each secondary server, and how frequently they are applied to the secondary database.

What is the main use of Backup Job?

When log shipping is enabled, the SQL Server Agent job category “Log Shipping Backup” is created on the primary server instance.

A backup job is created on the primary server instance for each primary database. It performs the backup operation, logs history to the local server and the monitor server, and deletes old backup files and history information. By default, this job will run every 15 minutes, but the interval is customizable.

What is the main use of Copy Job?

When log shipping is enabled, the SQL Server Agent job category “Log Shipping Copy” is created on the secondary server instance.

A copy job is created on each secondary server instance in a log shipping configuration. This job copies the backup files from the primary server to a configurable destination on the secondary server and logs history on the secondary server and the monitor server. The copy job schedule, which is customizable, should approximate the backup schedule.

What is the main task of Restore Job?

• The SQL Server job category “Log Shipping Restore” is created on the secondary server instance when log shipping is enabled.
• A restore job is created on the secondary server instance for each log shipping configuration. This job restores the copied backup files to the secondary databases. It logs history on the local server and the monitor server, and deletes old files and old history information.
• Scheduling these jobs with the same frequency keeps the secondary database as closely aligned with the primary database as possible to create a warm standby database.

What is the main use of Agent Job?

If a monitor server is used, an alert job is created on the monitor server instance. This alert job is shared by the primary and secondary databases of all log shipping configurations using this monitor server instance.

This job raises alerts (for which you must specify alert numbers) for primary and secondary databases when backup and restore operations have not completed successfully within specified thresholds.

Do you know what is the default time interval in Log Shipping?

It is 15 minutes.

What is the solution of the below error?

“Error: The restore operation cannot proceed because the secondary database ‘<Database Name>’ is not in NORECOVERY/STANDBY mode.(Microsoft.SqlServer.Management.LogShipping)”

Restore the secondary database with the full backup of the primary database with NORECOVERY and REPLACE option.