Recovery Models in SQL SERVER
One of the first things that needs to be set in order to
create the correct backups is to set the proper recovery model for each
database. The recovery model basically tells SQL Server what data to keep
in the transaction log file and for how long. Based on the recovery model
that is selected, this will also determine what types of backups you can
perform and also what types of database restores can be performed.
Simple
The simple recovery model does what it implies, it gives you a simple backup that can be used to replace your entire database in the event of a failure or if you have the need to restore your database to another server. With this recovery model you have the ability to do complete backups (an entire copy) or differential backups (any changes since the last complete backup). With this recovery model you are exposed to any failures since the last backup completed. Here are some reasons why you may choose this recovery model:
The simple recovery model does what it implies, it gives you a simple backup that can be used to replace your entire database in the event of a failure or if you have the need to restore your database to another server. With this recovery model you have the ability to do complete backups (an entire copy) or differential backups (any changes since the last complete backup). With this recovery model you are exposed to any failures since the last backup completed. Here are some reasons why you may choose this recovery model:
- Your data is not critical and can easily be recreated
- The database is only used for test or development
- Data is static and does not change
- Losing any or all transactions since the last backup is not a problem
- Data is derived and can easily be recreated
Type
of backups you can run:
- Complete backups
- Differential backups
- File and/or Filegroup backups
- Partial backups
- Copy-Only backups
Bulk_Logged
The bulk logged recovery sort of does what it implies. With this model there are certain bulk operations such as BULK INSERT, CREATE INDEX, SELECT INTO, etc... that are not fully logged in the transaction log and therefore do not take as much space in the transaction log. The advantage of using this recovery model is that your transaction logs will not get that large if you are doing bulk operations and you have the ability to do point in time recovery as long as your last transaction log backup does not include a bulk operation as mentioned above. If no bulk operations are run this recovery model works the same as the Full recovery model. One thing to note is that if you use this recovery model you also need to issue transaction log backups otherwise your database transaction log will continue to grow. Here are some reasons why you may choose this recovery model:
The bulk logged recovery sort of does what it implies. With this model there are certain bulk operations such as BULK INSERT, CREATE INDEX, SELECT INTO, etc... that are not fully logged in the transaction log and therefore do not take as much space in the transaction log. The advantage of using this recovery model is that your transaction logs will not get that large if you are doing bulk operations and you have the ability to do point in time recovery as long as your last transaction log backup does not include a bulk operation as mentioned above. If no bulk operations are run this recovery model works the same as the Full recovery model. One thing to note is that if you use this recovery model you also need to issue transaction log backups otherwise your database transaction log will continue to grow. Here are some reasons why you may choose this recovery model:
- Data is critical, but you do not want to log large bulk operations
- Bulk operations are done at different times versus normal processing.
- You still want to be able to recover to a point in time
Type
of backups you can run:
- Complete backups
- Differential backups
- File and/or Filegroup backups
- Partial backups
- Copy-Only backups
- Transaction log backups
Full
The full recovery model is the most complete recovery model and allows you to recover all of your data to any point in time as long as all backup files are useable. With this model all operations are fully logged which means that you can recover your database to any point. In addition, if the database is set to the full recovery model you need to also issue transaction log backups otherwise your database transaction log will continue to grow forever. Here are some reasons why you may choose this recovery model:
The full recovery model is the most complete recovery model and allows you to recover all of your data to any point in time as long as all backup files are useable. With this model all operations are fully logged which means that you can recover your database to any point. In addition, if the database is set to the full recovery model you need to also issue transaction log backups otherwise your database transaction log will continue to grow forever. Here are some reasons why you may choose this recovery model:
- Data is critical and data can not be lost.
- You always need the ability to do a point-in-time recovery.
- You are using database mirroring
Type
of backups you can run:
- Complete backups
- Differential backups
- File and/or Filegroup backups
- Partial backups
- Copy-Only backups
- Transaction log backups
Changing Recovery Models
The recovery model can be changed as
needed, so if your database is in the Full recovery model and you want to issue
some bulk operations that you want to minimally log you can change the recovery
model to Bulk_Logged complete your operations and then change your database
model again. The one thing to note is that since there will be a bulk
operation in your transaction log backup that you can not do a point in time
recovery using this transaction log backup file that contains this bulk
operation, but any subsequent transaction log backup can be used to do a
point in time recovery.
Also, if your database is in the Simple
recovery model and you change to the Full recovery model you will want to issue
a full backup immediately, so you can then begin to also do transaction log
backups. Until you issue a full backup you will not be able to take
transaction log backups.
To change the recovery model you can use
either SQL Server Management Studio or T-SQL as follows:
Management
Studio
- Right click on the database name, select Properties, select the Options tab and select recovery model from the drop-down list and select OK to save.
T-SQL
|
-- set to Full recovery
ALTER DATABASE AdventureWorks SET RECOVERY FULL GO
-- set to Bulk Logged recovery
ALTER DATABASE AdventureWorks SET RECOVERY BULK_LOGGED GO
-- set to Simple recovery
ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE GO |
No comments:
Post a Comment