Question 1. Which Edition Support Log Shipping?

Answer :
SQL Server 2005 – Enterprise, Standard, and Workgroup
SQL Server 2008 - Enterprise, Standard, Web, and Workgroup
SQL Server 2008 R2 - Datacenter, Enterprise, Standard, Web, and
Workgroup
SQL Server 2012 - Enterprise, Business Intelligence, Standard, and
Web
Question 2. Who Can Setup Log Shipping?
Answer :
Members of Sysadmin fixed server role
Question 3. Required Recovery Models In Log Shopping?
Answer :
Full or Bulk logged Recovery Model
Question 4. Which Jobs Are Created In Log Shipping?
Answer :
On Primary server – Backup job
On Secondary Sever – Copy, Restore and Alert Jobs
Question 5. Whether Log Shipping Supports Automatic Failover?
Answer :
No, it support only manual failover.
Question 6. Login Can Be Transferred Through Manual Failover?
Answer :
No, you have to create logins and users on secondary server
Question 7. Types Of Secondary Server?
Answer :
Restoring Mode and Stand by mode
Question 8. Difference Between Restoring Mode And Stand By Mode In
Log Shopping?
Answer :
Restoring mode – Database is in restoring mode.  You can not access the
database.
Stand by mode – Database is in read-only node.  You can select the data
from the database.  This database can be used for reporting purpose.
Question 9. What Are The Benefits Of Log Shipping?
Answer :
Easy to setup/configure
Easy to maintain
Easy to failover
Can have multiple secondary servers
Can be configure with mirroring or replication.
Question 10. What Are The Drawbacks Of Log Shipping ?
Answer :
Need to manage each database separately
 Does not support automatic failover.
Logins can not be moved automatically
Question 11. Which System Database Store Log Shipping Related
Information?
Answer :
Msdb
Question 12. What Is The Difference Between Log Shipping 2000 And
2005?
Answer :
Log shipping 2005 uses link Server to communicate between Primary,
Monitor, and Secondary Servers.
For 2000, Check connectivity of Primary, Monitor, and Secondary Servers.
Please note, always check remote connections are enabled on all servers.
Question 13. How To Monitor Log Shipping?
Answer :
Reports- Transaction log shipping standard report
3rd party tool
SQL Server System tables and stored procedures
Question 14. Default Time Of Log Shopping ?
Answer :
15 minutes
Question 15. Full Form Of Tuf?
Answer :
Transaction Undo file
Question 16. List Of Tables Used In Log Shipping?
Answer :
Primary server Tables:
Log_shipping_primary_databases, Log_shipping_monitor_primary,
log_shipping_monitor_error_detail, log_shipping_monitor_alert
Secondary server Tables:
Log_shipping_secondary_databases, Log_shipping_monitor_secondary,
Log_shipping_monitor_error_detail, Log_shipping_monitor_alert,
Log_shipping_monitor_history_detail, Log_shipping_secondary
Question 17. Backup Can Be Compressed In Log Shipping?
Answer :
Yes, SQL server 2008 onwards
Question 18. How To Troubleshoot Log Shipping Issues?
Answer :
Check error log for issue
Check backup, copy, and restore job history.
Check Log shipping standard report
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.

What is High Availability in SQL Server?

A high availability solution masks the effects of a hardware or software failure

and maintains the availability of applications so that the perceived downtime
for users is minimized.SQL Server high-availability solutions improve the
availability of servers or databases.

What all High Availability options are available in SQL Server?

At a high level, there are five main high availability options including a new
feature set to be release with SQL Server 2012:

Log Shipping

Mirroring

Replication

Clustering

AlwaysON
What is Log Shipping?

Log shipping is the process of automating the backup of database and

transaction log files on a production SQL server, and then restoring them onto
a standby server. But this is not all. The key feature of log shipping is that it
will automatically backup transaction logs throughout the day (for whatever
interval you specify) and automatically restore them on the standby server.
This in effect keeps the two SQL Servers Databases in “synch”.

What are the Benefits of Log Shipping?

Benefits of log shipping, let’s take a more comprehensive look:

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.

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.

Implementing log shipping is not technically difficult.

What the drawbacks of Log Shipping?

Log shipping failover is not automatic. The DBA must still manually failover
the server, which means the DBA must be present when the failover occurs.

The users will experience some downtime. How long depends on how well
you implemented log shipping, the nature of the production server failure,
your network, the standby server, and the application or applications to be
failed over.
Some data can be lost, although not always. How much data is lost depends on
how often you schedule log shipping and whether or not the transaction log
on the failed production server is recoverable.

The database or databases that are being failed over to the standby server
cannot be used for anything else. But databases on the standby server not
being used for failover can still be used normally.

When it comes time for the actual failover, you must do one of two things to
make your applications work: either rename the standby server the same
name as the failed production server (and the IP address), or re-point your
user’s applications to the new standby server. In some cases, neither of these
options is practical.

In which recovery model Log Shipping can be configured?

Log Shipping works with Full and Bulk Logged recovery model.

Is it possible to configure Log Shipping from lower version to upper

version and Vice versa?

Yes it is possible to configure Log Shipping from lower to upper version. But it
is not possible vice versa.

What is Log Shipping Monitor Settings?

This setting enables us to setup a monitor on the Log shipping through which
we can monitor the log shipping process.

What all jobs are created after configuring the Log Shipping?

Internally when Log Shipping is configured, there are 4 jobs created between

Primary Server and Secondary Server, they are Backup Job, Copy Job, Restore
Job and Alert Job
Backup job: This job is created on Primary Server; this job takes the
transaction log backup of the Database on a scheduled time

Copy Job: This job is created on Secondary Server, this job Copies the
transaction log Backup from Primary Server to the Standby/Secondary
Server.

Restore Job: This job is created on Secondary Server; this job restored
the copied transaction log backup on the Secondary Server.

What permissions are required for shared folders on Primary and

secondary for the service accounts?

For the backup job, read/write permissions to the backup directory are
required to the following:

SQL Server service account on the primary server instance.

Proxy account of the backup job. By default, this is the SQL Server Agent
account on the primary server instance.

For the copy job, read permissions to the backup directory and write
permissions to the copy directory are required by the proxy account of the
copy job. By default, this is the SQL Server Agent account on the secondary
server instance.

For the restore job, read/write permission to the copy directory are required
by the following: The SQL Server service account on the secondary server
instance. The proxy account of the restore job. By default, this is the SQL
Server Agent account on the secondary server instance.

What is the copy Job in Log shipping and on which instance it’s created?

Created in secondary server for every log shipping configuration.

Copy the backup files from backup folder into copy folder.

It deletes old files and old history from copy folder.

On backup folder we have to grant read permission to secondary server

account and read-write permissions on copy folder.

What is Monitor server?

An optional instance of SQL Server that tracks all of the details of log shipping,
including:

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.

What are Log Shipping System Tables and in which database these are
stored?

SQL Server Log Shipping System Tables

log_shipping_monitor_primary – Stores one monitor record per primary
database in each log shipping configuration.

log_shipping_monitor_secondary – Stores one monitor record per secondary

database in a log shipping configuration.

log_shipping_primary_databases – Stores one record for the primary database

in a log shipping configuration.

log_shipping_secondary – Stores one record per secondary ID

What are Log Shipping System Store Procedures?

SQL Server will issue a series of steps to synchronize the information between
primary/secondary server and the monitor server. This can be implemented
by running the below undocumented log shipping stored procedures:

sp_processlogshippingmonitorprimary

sp_processlogshippingmonitorsecondary

Is it possible load balance in Log Shipping?

Yes, it’s possible in log shipping, while configuring log shipping we have the
option to choose standby or no recovery mode, there we select STANDBY
option to make the secondary database readonly.

What is STANDBY Mode on the secondary database?

We can reduce the load on our primary database by using a secondary server
for read-only query processing. To do this, the secondary database must be in
STANDBY mode.

What’s the difference between the secondary being in “Restoring” vs.

“Standby”?
There are two options for configuration when we place the secondary
database in standby mode:

We can choose to have database users disconnected when transaction log

backups are being restored. If we choose this option, users will be
disconnected from the database each time the log shipping restore job
attempts to restore a transaction log to the secondary database.
Disconnection will happen on the schedule you set for the restore job.

We can choose not to disconnect users. In this case, the restore job cannot
restore transaction log backups to the secondary database if there are users
connected to that database. Transaction log backups will accumulate until
there are no user connections to the database.

What is TUF file?

TUF stands for Transaction Undo file.

What will happen to Log Shipping if TUF file is corrupted or lost?

The log shipping will not work. We have to setup the Log Shipping again.

If you create a Job on the Primary database server, will it automatically

be created on the secondary server or not?

No, it will not be created on the secondary server.

If you create a user on the Primary database, will it automatically be

created on the secondary or not?

Yes, it will be created automatically on the secondary database.

If you add a file on the Primary database in the same location which
exists on the target, will it automatically be created on the secondary or
not?

Yes, it will be created automatically on the Secondary database if the file is

added to the Primary database.

If you add a file on the Primary database in a location which does not
exist on the target, will it automatically be created on the secondary or
not?

No, Log Shipping will hang. We have to manually restore the Log backup with
MOVE option on the secondary database to rectify the issue.

Is it possible to configure Log shipping on the database server with

different collation?

No.

Can we configure Log Shipping between the different domains?

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

domains.

What are the store procedures to monitor Log Shipping?

We can execute the below Log Shipping System Stored Procedure to monitor
log shipping and get detailed information about log shipping.

sp_help_log_shipping_monitor – This is the how SQL Server generates the Log

Shipping Status report by executing

sys.sp_help_log_shipping_monitor – This procedure returns the log shipping

status (whether it is healthy or not) as well as metadata such as primary and
secondary database names, time since last backup, last backup file, last
restore file, etc…

sp_help_log_shipping_monitor_primary – returns all columns from the

log_shipping_monitor_primary table for the specified primary log shipping
database. It returns server name, database name, time of last backup, backup
threshold, threshold alert and history retention period.

sp_help_log_shipping_monitor_secondary – returns all columns from

log_shipping_monitor_secondary table for the specified secondary log
shipping database. It will return database name, server name, restore
threshold, last copied file, time of last copy / restore and history retention
period.

Can we setup multiple secondary databases in Log Shipping?

Yes, we can setup multiple secondary databases in Log Shipping.

Can we shrink log shipped database log file?

Yes, we can shrink the log file, but we shouldn’t use WITH TRUNCATE option.
If we use this option obviously log shipping will be disturbed.

Can we take full backup of the log shipped database in primary server?

Yes it’s possible. We can take full backup of log shipped database and this
won’t affect the log shipping.

What editions of SQL Server is log shipping available in?

2012 – Enterprise, Business Intelligence, Standard, and Web

2008R2 – Datacenter, Enterprise, Standard, Web, and Workgroup

2008 – Enterprise, Standard, Web, and Workgroup

2005 – Enterprise, Standard, and Workgroup

Can we take full backup of the log shipped database in secondary

server?

No, we won’t be able to execute BACKUP command against a log shipped

database in secondary server.