1. 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.

2. 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

3. 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.

4. What are the Benefits of Log Shipping?

Benefits of log shipping, lets take a more comprehensive look:

 Log shipping doesnt 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.

5. 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 users applications to the new
standby server. In some cases, neither of these options is practical.

6. In which recovery model Log Shipping can be

configured?

Log Shipping works with Full and Bulk Logged recovery model.

7. 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.

8. 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.

9. 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.

10. 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.

11. What is the copy Job in Log shipping and on

which instance its 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.

12. 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.
 13. 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

14. 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

15. Is it possible load balance in Log Shipping?

Yes, its 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.

16. 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.

17. Whats 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.

18. What is TUF file?

TUF stands for Transaction Undo file.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. Is it possible to configure Log shipping on the

database server with different collation?

No.

25. Can we configure Log Shipping between the

different domains?

Yes, we can configure Log Shipping on the server residing in different domains.
 26. 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.

27. Can we setup multiple secondary databases in

Log Shipping?

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

28. Can we shrink log shipped database log file?

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

29. Can we take full backup of the log shipped

database in primary server?
Yes its possible. We can take full backup of log shipped database and this wont
affect the log shipping.

30. 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

31. Can we take full backup of the log shipped

database in secondary server?

No, we wont be able to execute BACKUP command against a log shipped database
in secondary server.

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 doesnt 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 Id 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 Id 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 dont 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 servers 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.