1. Recovery Concepts
The concept of database recovery is based on the D in the transactional-integrity ACID properties — transactional durability. Durability means that a transaction, when committed, regardless of hardware failure, must be persistent.
SQL Server accomplishes transactional durability
with a write-ahead transaction log. Every transaction is written to the
transaction log prior to being written to the data file. This provides
a few benefits to the recovery plan:
- The transaction log ensures that every transaction can be recovered up to the last moment before the server stopped.
- The transaction log permits backups while transactions are processed.
- The transaction log reduces the impact of a hardware failure
because the transaction log and the data file may be placed on
different disk subsystems.
The strategy of a recovery plan should be based on the organization's tolerance level, or pain level,
for lost transactions. Recovery-plan tactics involve choosing among the
various backup options, generating a backup schedule, and off-site
storage.
SQL Server backup and recovery are flexible,
offering three recovery models from which to choose. The transaction
log can be configured, based on your recovery needs, according to one
of the following recovery models:
- Simple: No transaction log backups.
- Bulk-logged: The bulk-logged recovery model minimally logs bulk operations, although fully logging other transactions.
- Full: All transactions are logged.
In addition, SQL Server offers the following backup options:
- Full: Complete backup of all data.
- Differential: Backup of all data pages modified since the last full backup.
- Partial: Backup of primary filegroup, every read/write filegroup, and any optionally specified read-only files.
- Transaction log: Backup of all transactions in the log.
- File or filegroup: Backup of all the data in the file or filegroup.
- File differential: Backup of all data pages modified since the last file or filegroup backup.
- Copy-only: Backup all the data without affecting the overall
backup and restore procedures for the database. In other words this
allows you to take a full backup of the database without breaking the
existing backup chain.
Note
Backing up the database may not be the
only critical backup you must perform. If the database-security scheme
relies on SQL Server authentication, backing up the database users is
important as well. In SQL Server 2012 another important feature, called
Contained Databases, makes this user account management much easier.
SQL Server backups are flexible and can handle
any backup-to-file ratio. A single backup instance can be spread across
several backup files, creating a backup set. Conversely, a single backup set can contain multiple backup instances.
Restoration always begins with a full
backup. Differential and transaction log backups then restore the
transaction that occurred after the full backup.
2. Recovery Models
The recovery model configures SQL
Server database settings to accomplish the type of recovery required
for the database, as shown in Table 1. The key differences among the recovery models involve how the transaction log behaves and which data is logged.
Table 1 SQL Server Recovery Models
Although the durability of the
transaction is configurable, the transaction log is still used as a
write-ahead transaction log to ensure that each transaction is atomic.
In case of system failure, SQL uses the transaction log to roll back
any uncommitted transactions and to complete any committed transactions.
