The transaction log is a crucial part of each database that records all transactions and database changes made by each transaction. The purpose of the transaction log is to keep record of all changes that were made in the database. Let’s consider the example from the picture below: Read More
Category: SQL Server Backup
Transaction Log Backup
A transaction log backup contains all transaction log records that have been made between the last transaction log backup or the first full backup and the last log record that is created upon completion of the backup process. The transaction log backup allows to restore a database to a particular point-in-time before the failure has occurred. It is incremental, meaning that in order to restore a database to a certain point-in-time, all transaction log records are required to replay database changes up to that particular point-in-time. Please note that transaction log backup is available only for full or bulk-logged recovery models. The picture below shows how transaction log backup works.
Bulk-logged Recovery Model
The bulk-logged recovery model is designed for intermittent use to improve the performance of bulk imports of large amounts of data. It’s practically the same as the full recovery model with the only exception that under the bulk-logged recovery model some operations are logged minimally. These operations are:
- Bulk import operations (bcp, INSERT … SELECT, and BULK INSERT).
- SELECT INTO operations.
- Partial updates to large value data types using the WRITE clause in the UPDATE statement when inserting or appending new data. Please note that minimal logging is not used when existing values are updated.
- Inserting or appending new data into the text, ntext, and image data type columns using the WRITETEXT and UPDATETEXT statements. Please note that minimal logging is not used when existing values are updated.
- If the database recovery model is set to either bulk-logged or simple, some INDEX DDL operations are minimally logged regardless of whether the operation is executed online or offline. (Minimally logged index operations are as follows: CREATE INDEX, ALTER INDEX REBUILD or DBCC DBREINDEX and DROP INDEX).
COPY_ONLY Backup
In order to understand how to operate the “COPY_ONLY” option and its nature, let’s consider the following example. Assume that a full database backup starts at 00:00 once a day and a differential backup starts every six hours. In the picture below you can see what database changes (marked as pages) are included into each of database backups shown on the picture.
Database Filegroups
Checkpoint
Checkpoint is a process that writes current in-memory dirty pages (modified pages) and transaction log records to physical disk. In SQL Server checkpoints are used to reduce the time required for recovery in the event of system failure. Checkpoint is regularly issued for each database. The following set of operations starts when checkpoint occurs:
- Log records from log buffer (including the last log record) are written to the disk.
- All dirty data file pages (pages that have been modified since the last checkpoint or since they were read from disk) are written into the data file from the buffer cache.
- Checkpoint LSN is recorded in the database boot page.
SQL Server Extent
Eight physically contiguous pages in SQL Server database are called the extent. One page is 8 KB, therefore one extent is 64 KB. Read More
Database Page
Every piece of data in SQL Server is stored in 8 KB database pages. A page is a basic unit of I/O operation. Read More
Database Files
Every database of SQL Server at least has a log file and data file. Log files contain all information that is necessary to restore transactions in the database. Data files contain data and objects (indexes, tables, etc.). Read More
Differential Backup
A differential backup is created similarly to a full backup, but with one important difference – the differential backup only contains the data that has changed since the last full backup (the active portion of the transaction log). Read More