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.

What is Database Mirroring?

Database mirroring is a solution for increasing the availability of a SQL Server database. Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model.

Database mirroring is the creation and maintenance of redundant copies of a database. The purpose is to ensure continuous data availability and minimize or avoid downtime that might otherwise result from data corruption or loss, or from a situation when the operation of a network is partially compromised.

What are the benefits of Database Mirroring?

• It increases the availability of a database. In the event of a disaster, in high-safety mode with automatic failover, failover quickly brings the standby copy of the database online.
• It Increases the data protection.Database mirroring provides complete or almost complete redundancy of the data, depending on whether the operating mode is high-safety or high-performance.
• It Improves the availability of the production database during upgrades.To minimize downtime for a mirrored database, you can sequentially upgrade the instances of SQL Server that are hosting the failover partners.

How Database Mirroring works in SQL Server?

Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.

One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session.

The principal and mirror servers communicate and cooperate as partners in a database mirroring session. The two partners perform complementary roles in the session: the principal role and the mirror role. At any given time, one partner performs the principal role, and the other partner performs the mirror role.

Database mirroring involves redoing every insert, update, and delete operation that occurs on the principal database onto the mirror database as quickly as possible. Redoing is accomplished by sending a stream of active transaction log records to the mirror server, which applies log records to the mirror database, in sequence, as quickly as possible.

What is a automatic failover?

The process by which, when the principal server becomes unavailable, the mirror server to take over the role of principal server and brings its copy of the database online as the principal database.

What is a principal database principal server?

Principal database is a read-write database whose transaction log records are applied to mirror database and Principal server is an instance on which the principal database resides.

What is a mirror database and mirror server?

The copy of the database that is typically fully synchronized with the principal database and the mirror server is an instance on which the mirror database resides.

What is a failover partners?

The two server instances (the principal server or the mirror server) that act as role-switching partners for a mirrored database.

What is a forced service?

A failover initiated by the database owner upon the failure of the principal server that transfers service to the mirror database while it is in an unknown state.

What is a High-performance mode of the Mirroring?

The database mirroring session operates asynchronously and uses only the principal server and mirror server. The only form of role switching is forced service.

What is a High-safety mode of the Mirroring?

The database mirroring session operates synchronously and, optionally, uses a witness, as well as the principal server and mirror server.

What is a redo queue?

It receives transaction log records that are waiting on the disk of a mirror server.

What is a send queue?

It holds the unsent transaction log records that have accumulated on the log disk of the principal server.

What is role switching?

Within the context of a database mirroring session, the principal and mirror roles are typically interchangeable in a process known as role switching. Role switching involves transferring the principal role to the mirror server. In role switching, the mirror server acts as the failover partner for the principal server. When a role switch occurs, the mirror server takes over the principal role and brings its copy of the database online as the new principal database. The former principal server, if available, assumes the mirror role, and its database becomes the new mirror database. Potentially, the roles can switch back and forth repeatedly.

What is Transaction safety?

A mirroring-specific database property that determines whether a database mirroring session operates synchronously or asynchronously. There are two safety levels: FULL and OFF.

What is Witness server?

To support automatic failover, a database mirroring session must be configured in high-safety mode and also possess a third server instance, known as the witness.Unlike the two partners, the witness does not serve the database. Supporting automatic failover is the only role of the witness.

What happened, when a DBA paused the session?

Pausing preserves the session state while removing mirroring. When a session is paused, the principal server does not send any new log records to the mirror server. All of these records remain active and accumulate in the transaction log of the principal database. As long as a database mirroring session remains paused, the transaction log cannot be truncated.

What are the Prerequisites to set up a Database Mirroring?

• The partners and the witness, if any, must be running on the same version of SQL Server.
• The two partners, that is the principal server and mirror server, must be running the same edition of SQL Server. The witness, if any, can run on any edition of SQL Server that supports database mirroring.
• The database must use the full recovery model. The simple and bulk-logged recovery models do not support database mirroring.
• Verify that the mirror server has sufficient disk space for the mirror database.
• When you are creating the mirror database on the mirror server, make sure that you restore the backup of the principal database specifying the same database name WITH NORECOVERY.