Translation for Week
Stairway to Transaction Log Management in SQL Server, Level 5: Managing the Log in Full Recovery Mode
SQL Server transaction log management ladder, level 5: Managing log in full recovery mode
Tony Davis, 2012-01-27
In this section, we will review the causes and methods of log backups in full recovery mode, and how to use them to perform a database log backup file recovery with full database backup. Support for full recovery mode to restore the database to any point in time the available log backup, and assumptions can be tail-log backup, up until the last time prior to the failure to submit the transaction.
In full recovery mode, all operations are fully documented. For INSERT, UPDATE, and DELETE operations, which means that for each line was modified, there is a logging, transaction execution sentence description of the ID, the transaction begins and ends, what has changed page, which carried out the data changes, and so on Wait.
When working in full recovery mode, you can record minimally SELECT INTO, BULK INSERT and CREATE INDEX operation is still fully logged, but the implementation is slightly different. These operations are affected by the line are not recorded separately; the contrary, only database pages will be recorded when it is filled. This reduces the log of such eavesdropping operations, while ensuring that there is still a rollback, redo the same point in time restore all the information needed. Kalen Delaney made some investigation records SELECT INTO (http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/15/what-gets-logged-for-select-into.aspx) and index rebuild (http: //sqlblog.com/blogs/kalen_delaney/archive/2011/03/08/what-gets-logged-for-index-rebuilds.aspx) operation, integrity and BULK_LOGGED recovery mode. Differences logging BULK_LOGGED when operating in mode, the smallest log recording operation are discussed in more detail in the Level 6 - log manager logs in batch recovery mode.
Why you should back up the transaction log?
In full recovery mode, only the log backups can lead to truncate the log. Therefore, the transaction log will keep full records of transactions since the last transaction log backup execution. Since all operations have been fully documented, so on a busy system, the log files can be very large, growing very fast.
Therefore, when operating in full recovery mode, in addition to a full backup and (optionally) differential backups, it is important to perform regular transaction log backups. Many novice or part time dba perform a full backup on their database, but they do not perform transaction log backups. Therefore, the transaction log is not truncated, it will continue to grow until it is exhausted in the drive disk space, resulting in SQL Server to stop working.
Once the log backup is performed, it will truncate the log immediately, assuming that has occurred since the last backup checkpoint, and no other factors delay truncated, such as data backup or restore operation. For a complete list of factors, it could delay the recovery of very low frequency cut-off, and the active factor in maintaining a log large areas, they will not need, such as a rogue, long-term uncommitted transactions or database mirroring or replication process, see: http: // msdn.microsoft.com/en-gb/library/ms345414.aspx.
COPY_ONLY transaction log backup
COPY_ONLY back up the transaction log does not truncate the transaction log. Common backup and log log COPY_ONLY backup scheme, "independence" is present; it does not break the log backup chain.
In short, the transaction log backups performed a dual purpose: to allow recovery and revert to a previous point in time, and control the size of the transaction log. May be associated with the transaction log of the most common reason is that the work in full recovery mode, no log backups, or no log backups frequently enough to control the size of the transaction log file.
If you are unsure whether to perform a transaction log backup on a given database, you can use a query similar to the query in Listing 5.1 MSDB database shown in the table back upset.
USE msdb ;
SELECT backup_set_id ,
backup_start_date ,
backup_finish_date ,
backup_size ,
recovery_model ,
[type]
FROM dbo.backupset
WHERE database_name = 'TestDB'
Listing 5.1: progress log backup it?
In the type column, D represents the database backup, L represents log backup, I represents differential backup.
Note that since this data back upset the table can operate without affecting the behavior of backup and recovery, so you may want to verify the results from the query by querying sys. database_recovery_status View last_log_backup_lsn value (see Listing 3.5) or the sys. Database tables, to see the values of log_reuse_wait_desc (backup if needed, will return LOG_BACKUP).
How to back up the transaction log
As mentioned earlier, if you do not perform a full backup at least first, it is impossible to perform the transaction log backup. In fact, if the database is in full recovery mode, but never backed up, then it does not actually work in full recovery mode. Prior to performing the first full backup, the database is automatically cut off mode.
Perform all database backups, including the full backup, log backup or other backup using the BACKUP command. This command accepts a number of options, which is documented here: http: //msdn.microsoft.com/en-us/library/ms186865.aspx. However, the most basic, which is a method commonly used commands to perform a disk full backup as follows:
DatabaseNameTO database backup disk = 'FileLocation \ DatabaseName.bak';
If this is the first backup to be performed, DatabaseName.bak file is created in the specified directory. If there is already such a file, the default behavior is to follow the backup appended to the file. To override this behavior, and the provisions of any existing file should be overwritten, we can use the INIT option, as follows:
DatabaseNameTO database backup disk = 'FileLocation \ DatabaseName. Baker 'WITH initialization;
However, the most common is that each subsequent backup has a unique name; this regard, in the next section, "returned to the point of failure" has more on this.
After each log backups on a regular basis (such as daily) full backup, there will be frequent (eg, hourly), the basic commands are very similar:
Backup log DatabaseNameTO disk = 'FileLocation \ DatabaseName_Log.bak';
Log backup storage
Clearly, backup data and log files should not be stored on the same drive carrying active file. If the drive hardware failure, then all your copies will be lost along with the active file, the backup would be futile. Files should be backed up to a separate device, or back to the local mirror drive.
Frequency of log backup
As mentioned earlier, you may log backup once every 15 minutes, even more frequently. In this case, in order to avoid the need to restore a large transaction log file, you can choose to use a backup program that includes a full and differential backups, transaction log backups.
In fact, the backup program is usually a compromise between the ideal and the real, is a real risk of data loss, the company will pay the price and reducing tradeoff between the cost of the assessment of the risks involved. Many important business applications using a somewhat simpler but still demanding backup program may include regular night full backup and transaction log backups every hour.
Log backup frequency may also be determined by the number of database transactions suffered. For very busy database, in order to control the size of the log, you may need frequent backups.
Log backup frequency calculation is no easy way. Most dba log backup frequency will be the best estimate, and then observe the growth characteristics of the file, and then adjust your backup program as needed to prevent the file is too large.
Log chain and how to break it
As mentioned earlier, if you do not first perform a full backup at least, it is impossible to perform the transaction log backup. To restore a database point in time, a specific point in time or log backup or the end of a particular log backup, there must be a complete log records from the first log backup, a full (or differential backups) until the point of failure. This is known as the logarithm chain.
There are many ways to break the log chain, if you do this, it means that you can only restore the database to log time before breaking the log chain of events made the backup. In short, if you are concerned about the ability to recover data, then disconnect the chain is not a good idea. The two most common ways to break this chain include:
- Loss or damage to a transaction log backup files - you can only restore to a previous good backup log. Log chain will restart a full or differential backup at the next.
- Switch to simple recovery mode - If you have to switch from full recovery mode to simple recovery model, which will break the log chain, because that will trigger the checkpoint, and can immediately truncate the transaction log. When you return to FULL mode, you will need to perform another full backup to restart the log chain. In fact, prior to a full backup, the database will automatically keep the cut mode, you can not back up the log file.
Before sql Server 2008, there are two commands that use the backup log NO_LOG or use TRUNCATE_ONLY backup log (they are equivalent in function), when you issue these commands will be forced to truncate the log file, thus breaking the log chain . You should not issue in any version of SQL Server in the command, but I mention them here because when trying to deal with "out of control log file" careless people still use them without understanding its recovery database the ability to have any effect. See page 8 - help, my log is full, for more details.
Tail log backup
As long as you have the most recent full backup and a complete log chain, you can restore the database to the state at the end of the last log backup prior to any failure. However, if you hour by hour perform a transaction log backup, and failure at 1:45 pm. You may lose 45 minutes of data; in fact, if the fault is very serious, that real-time transaction log can not be retrieved, then you will lose large amounts of data.
Sometimes, however, even if the data file does not exist, real-time transaction log is still available, especially if the transaction log is included on a separate, dedicated drives. If this is the case, you should back up the transaction log in real time, that is, the logging executed since the last log backup generated for the last backup. This will capture the remaining logging activity log file until failure occurs. This is known as tail-log backups, the last one before the operation began to recover and restore what should be done.
Tail-log backup operations and minimum log
If a failure causes data because the database file is not available, and the tail of the log contains a minimum of logging operations, it is impossible to carry out the tail log backup, because it will need to access the data segment in the data file has been changed. Level 6 discuss this, that bulk-logged mode of transaction log management in more detail.
If you want to restore the database is online, then log tail backs up as follows:
BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak' WITH NORECOVERY
NORECOVERY option to restore the database in the state, and suppose you want to perform the next operation is restored. If the database is offline, and can not start, you should still try to back up the tail of the log like that just described (although you can omit the NORECOVERY option, because there is no transaction in progress).
If you determine that the log file has been damaged, the document recommends that, as a last resort, you can try the tail log backup using the following methods:
BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR
If the primary database and the data file is damaged, but the log is available, Microsoft recommends rebuilding the master database, and then back up the last active log. However, the topic is beyond the scope of this staircase, I recommend that you refer to the documentation for more details. See http://msdn.microsoft.com/en-us/library/ms190952.aspx .
Perform the recovery and restoration
After performing tail-log backup (if possible), the next step is to restore the last full backup (if appropriate, followed by a differential backup) and then restoring a full sequence of log backup files, including tail-log backup. The basic syntax for this series of recovery operations is as follows:
RESTORE {DATABASE | LOG} DatabaseNameFROM DISK ='FileLocation\FileName.bak'WITH NORECOVERY;
If you omit the WITH NORECOVERY option when restoring, then by default, RESTORE command will continue to recover. In other words, SQL Server will attempt to coordinate data and log files, rolling forward completed transactions, and then did not complete required to roll back transactions. By using NORECOVERY specified, we indicate that we are entering a SQL Server recovery sequence, before any roll back, you must roll more before the operation. After restoring the last backup in the sequence, the database can be restored as follows:
RESTORE DATABASE DatabaseName WITH RECOVERY
A common requirement is to restore the database to a different location, in this case, you can simply move the file as part of the reduction process, as follows: http: //msdn.microsoft.com/en-us/ library / ms190255.aspx.
Database recovery after failure
The following examples describe how to recover the database, the database in response to fault data file is no longer accessible.
Fully restored to the point of failure
After assuming that database failure (may be caused by a hardware failure) can reach the "active" transaction log, then theoretically should be able to use the following steps to restore and recover the database until the point of failure:
1. Back up the tail of the log
2. Restore the latest full backup (if applicable, plus differential)
3. Then, after a full restore (or differential) backups each transaction log backup and completed before a failure occurs
4. Recovery log backup tail
5. Restore the database
Many examples of the online books are demonstrating that recovery and restoration from the "backup set" (ie, a single storage "device" all backed up) carried out. In practice, this means that when the backup-to-disk backup device is a .bak file is located somewhere on the disk.
Thus, for example, a simple example shown in Listing 5.2 to use the backup set consists of a full backup and a transaction log backup component, and shows how to perform a complete recovery. To run this code, you first need to re-create TestDB database, and then insert a few lines of sample data (for convenience, execute scripts CreateAndPopulateTestDB this operation). This level of code download contains sql). You will also need a database server in the local C: Create a "backup" directory on the drive, or to modify the file path as required.
-- Perform a full backup of the Test database
-- The WITH FORMAT option starts a new backup set
-- Be careful, as it will overwrite any existing sets
-- The full backup becomes the first file in the set
BACKUP DATABASE TestDB
TO DISK = 'C:\Backups\TestDB.bak'
WITH FORMAT;
GO
-- Perform a transaction log backup of the Test database
-- This is the second file in the set
BACKUP Log TestDB
TO DISK = 'C:\Backups\TestDB.bak'
GO
-- ....<FAILURE OCCURS HERE>....
-- The RESTORE HEADERONLY command is optional.
-- It simply confirms the files that comprise
-- the current set
RESTORE HEADERONLY
FROM DISK = 'C:\Backups\TestDB.bak'
GO
-- Back up the tail of the log to prepare for restore
-- This will become the third file of the bakup set
BACKUP Log TestDB
TO DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
GO
-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=1, NORECOVERY;
-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=2, NORECOVERY;
-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=3, NORECOVERY;
-- Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO
Listing 5.2: backup to the backup set and recover from; not recommended
However, the use of backup sets appears to be the legacy of the database when backing up to tape. When backing up to disk, using this program it is not a good idea, because the backup files can quickly become very large.
In fact, the more common situation is that each full backup and transaction log backup files are named, the time and date stamped and can be backed up. For example, most third-party backup tools, the popular community-generated script, and in SSMS Maintenance Plan Wizard / designer, will create a separate file date stamp, for example AdventureWorks_FULL_20080904_000001.bak.
Therefore, the more common backup and recovery program will use the backup unique name, as shown in Listing 5.3.
USE master;
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO
-- Perform a transaction log backup of the Test database
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log.bak'
WITH INIT;
GO
-- ....<FAILURE OCCURS HERE>....
-- Back up the tail of the log to prepare for restore
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_taillog.bak'
WITH NORECOVERY, INIT;
GO
-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY;
-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_taillog.bak'
WITH NORECOVERY;
-- Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO
Listing 5.4: a series of log backups
If a catastrophic failure occurred shortly after 2:30 am, we may need to restore the database to the state when the log backup 2 ends, namely at 2:30 am.
Recovery sequence in this example and in front of us see in Listing 5.3 are very similar, but since the end of the backup is not possible, but we can only be restored to a specific point, so we need to use STOPAT options, as shown in Listing 5.5 Fig.
--RESTORE Full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
--RESTORE Log file 1
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--RESTORE Log file 2
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_Log2.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO
Listing 5.5: Use STOPAT restore to a point in time
Since we STOPAT a specified time in the future, this code will be rolled at the end of the second transaction logs before all completed transactions.
Alternatively, you can specify a STOPAT time, it is located within a particular time transaction log file records. In this case, the database will be restored to the last committed transaction at a specified time. When you want to know what time to recover, but do not know what log backup contains specific time, which is very useful.
You can restore to a specific marked transaction. For example, when you need multiple databases accessed by an application to return to the point logically consistent, which is very useful. There is no further discussion of this topic, but you can find more Books Online (http://msdn.microsoft.com/en-us/library/ms187014.aspx), and Tim Prajdic provides a good example: http: //weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx.
After recovery, "Wrong Transaction"
Outside any context of a database failure, you may need to restore the database and transaction log backups, in order to return the database to a specific point in time error data modification before (such as delete or truncate table).
Your response to this situation will depend on the nature of the problem. If possible, you can disconnect all users from a database (after informing them), and assess the impact of what had just happened. In some cases, you may need to estimate the time when it happened, and then use the time recovery point of the database and log full recovery. After the restoration is complete, you must notify the user some transactions may have been lost, and asking for forgiveness.
Of course, normally you can not in this way disrupt normal business operations to repair accidental data loss. Due to the active database is still running and is being accessed, you can try to restore a backup of the database in standby mode. This allows for more recovery log backups, but use different NORECOVERY, the database is still readable. Recovery program might look like this:
1. In the standby mode, beside the active database to restore the backup database.
2. The error log roll position before the transaction occurs before the data is lost.
3. Copy the missing data to the active copy of the database and delete the recovery.
Of course, this process is not necessarily straightforward, and can be very time consuming. Unless you purchase a special log reading tool, and can directly query the log backups, or it may mean a series of painstaking steps before rolling logs, including the recovery log, check the data, further recovery, and so on, until you determine the error Affairs the exact location of occurrence. Step 3 may be very difficult, because you will not necessarily coincide with the introduction of the current state of database activity data in the system, so there may referential integrity problems.
Let's look at an example of the above steps 1 and 2 of realization. First, let's start from scratch to run CreateAndPopulateTestDB. TestDB sql script to re-create the database, insert and 10 rows of test data to a new LogTest table. In Listing 5.6, we only need to perform a complete database backup (overwrites any previous backup file). If you have not created a "backup" directory, you need to create a "backup" directory, or adjust the path as needed.
-- full backup of the database
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO
Listing 5.6: TestDB full backup
Then, we will insert a new row of data into LogTest table.
USE TestDB
GO
INSERT INTO [TestDB].[dbo].[LogTest]
([SomeInt]
[SomeLetters2])
VALUES
(66666,
'ST')
SELECT * FROM dbo.LogTest
Listing 5.7: the first 11 rows into TestDB
So now we have LogTest table in a database that contains active TestDB line 11, and a backup version contains 10 rows. Now let us capture additional modifications in the log backup, as shown in Listing 5.8.
USE master
GO
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log.bak'
WITH INIT;
GO
Listing 5.8: TestDB log backup
Now, we will simulate a mistake "bad business", simply delete LogTest table, and then perform the final log backup.
USE TestDB
GO
DROP TABLE dbo.LogTest ;
USE master
GO
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log2.bak'
WITH INIT;
GO
Listing 5.9: Disaster!
In order to retrieve lost data without disrupting normal business operations, we will restore TestDB copy of the database in standby mode. Standby database data and log files (referred ANewTestDB) is moved to a "standby" directory (need to pre-create this directory).
-- restore a copy of the TestDB database, called
-- ANewTestDB, in STANDBY mode
USE master ;
GO
RESTORE DATABASE ANewTestDB
FROM DISK ='C:\Backups\TestDB.bak'
WITH STANDBY='C:\Backups\ANEWTestDB.bak',
MOVE 'TestDB_dat' TO 'C:\Standby\ANewTestDB.mdf',
MOVE 'TestDB_log' TO 'C:\Standby\ANewTestDB.ldf'
GO
Listing 5.10: restore TestDB in standby mode copy
Now we have named the new database ANewTestDB, it is in "standby / read only" mode, shown in Figure 5.1
Figure 5.1: standby database
Queries on ANewTestDB database LogTest table will display 10 lines. However, we want to return the table to the state before it is deleted by mistake. Thus, the next step is to restore to the standby database log backup.
USE master
GO
RESTORE LOG ANewTestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH STANDBY='C:\Backups\ANewTestDB_log.bak'
Listing 5.11: standby mode to restore the log backup to ANewTestDB database
The query for ANewTestDB display 11 lines, and now we are ready to copy the data back to the active database. If we further restore the log backups second time, we will realize that we are doing too much, the standby database will be lost in this table.
Another alternate method of recovery is to consider using third-party tools, such as Red Gate's SQL Virtual restore, it provides a way to back up mount as active, full-featured database, without the need for physical recovery.
Whether dba like it or not, developers often have access to the production database to perform ad hoc data loading and change. DBA and developer common responsibility is to ensure the smooth progress of these processes, so as not to cause problems to the above operations. We will first 6 return to this theme later stage - batch processing operations.
Of course, the exact nature of the compensation act required depends on the nature of the adverse trading. If a table "accidental loss", then it is likely you will use the alternative route recovery. At other times, you can simply create a script to "reverse the" wrong changes.
If the damage affects only a limited number of single column or row, you can use a tool like SQL Data Compare Alternatively, it can be directly compared with the backup file, and may perform the row-level recovery.
Or, if you are running SQL Server 2005 Enterprise Edition (or later), and provides the latest snapshot of the database, you can run a query to retrieve data snapshot, as it looks when the database snapshot, and then write an update or insert command data from a database snapshot into the life, the source database.
Finally, as a last resort, a dedicated log reader tool can help you reverse the effects of the transaction, even though I do not know which version of SQL Server 2005 or later if there are any reliable operation.
to sum up
In this layer, we introduce a backup of the database running in full recovery mode and restore the basics of log files, this will be the standard for many of the production database.
For most dba, the execution point in time recovery needs are rare, but, if necessary, to perform point in time recovery is one of the critical tasks; DBA's reputation depends on it.
In case of damage, drive failure, if lucky, point in time recovery may involve the tail of the transaction log backup and restore to the point of failure. If the transaction log is not available, or you are recovering to restore to a point in time before the "wrong transaction" occurs, then the situation will become more difficult, but hopefully some of the techniques involved in this step will help.
This article is part of the SQL Server transaction log management parent stairs.