• Simple
• Full
• Bulk-Logged

Simple Recovery Model

Simple recovery model is used for databases that are not critical or the database is static and data is not changing. We generally use SIMPLE model for lower life cycle databases. Main reason for this is point in time recovery is not possible because transaction log backup is not allowed in this recovery model and database engine automatically clears transactional logs during checkpoint operation. If you want to understand checkpoint operation, you should read attached article.

A common myth is that when a database is configured in Simple recovery model then transactions will not be logged in transaction log files. This is not true and every transaction is logged to the transaction log file. Only difference is that, when that transactions will complete and data is written to disk all logs will flush and be available to log another transaction in same log file. This way you can also deal with the space issue.

Log Shipping, AlwaysOn Availability group and Point-in-Time Restores are not possible in this SIMPLE model because transaction log backups are not allowed in this recovery model. We can recover any database that are running in SIMPLE model till last full or differential backups only. Run below command if you want to view or change the recovery model of the database.

--Check the Recovery Model of the database YourDB_Name
SELECT name, recovery_model_desc  
   FROM sys.databases  
      WHERE name = 'YOURDB_NAME' ;  
GO
--Change Recovery Model to SIMPLE
ALTER DATABASE DBNAME SET RECOVERY SIMPLE
GO

Full Recovery Model

Point in time recovery is possible in full recovery model that is why we use this recovery model for all production and critical databases. Every transactions that are logged in this recovery model can be backed up. Transaction log backup will capture all the logs and clears all the inactive portions of the transaction log file.  You can handle your log file space management by scheduling frequent transaction log backups.

You can also clear the transaction logs from log files by switching the recovery model from Full to Simple but this is never recommended for any production database. If you change the SQL Server recovery model from Full to Simple, logs will be flushed from log file without getting captured into transaction log backup. That will break the log sequence and you will end up losing the point in time recovery for your database. That is why switching recovery model from full to simple is not recommended for production database.

As transaction log backups are allowed in this recovery model so you can recover your database till point in time and there will be no data loss in this recovery model.

--Change SQL Server Recovery Model to FULL
ALTER DATABASE DBNAME SET RECOVERY FULL
GO

Bulk-Logged Recovery Model

Bulk-logged recovery model works similar to Full recovery model except few exceptions during bulk operations. You can use this recovery model if you have to run BULK operations on your database. Bulk-logged recovery model minimally logged such bulk operations to reduce the transaction log space.

Point in time recovery is not possible if you have performed any bulk operation during that time due to the nature of minimally logged operation. If you haven’t performed any bulk operation then point in time recovery can be achieved. Microsoft does not suggest to run any database in bulk-logged recovery model if you don’t have to run any bulk operations.

Best practice is that you change a database recovery model to the bulk-logged immediately before running bulk operations and restore it back to the full recovery model when those operations complete. Also you should run a log backup before switching to bulk-logged recovery model and again take the log backup once you return back to full recovery model post completing bulk operation. Your backup strategy remains the same and it will not break your log sequence. Run below command to change the recovery model to bulk-logged.

--Change Recovery Model to BULK-Logged
ALTER DATABASE DBNAME SET RECOVERY FULL
GO

Change Recovery Model using GUI

1. Connect to SQL Server Instance. in Object Explorer, click the server name to expand the server tree.
2. Expand Databases folder and click on the database for which either you want to change the recovery model of view the recovery model.
3. Right-click on that database, and then click Properties, which opens the Database Properties dialog box.
4. In the Select a page pane, click Options.
5. The current recovery model is displayed in the Recovery model list box.
6. Optionally, to change the recovery model select a different model list. The choices are Full, Bulk-logged, or Simple.
7. Click OK.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding SQL Server Recovery Model appeared first on Techyaz.com.

Related Articles:

• Why Should You Always Turn Off Database Auto Shrink Property?
• Understand the Best Value for Database File Autogrowth Setting
• What is Checkpoint Process in SQL Server?

Virtual Log File

As we know Transaction Log Files internally divided in to small virtual log files. Virtual Log Files also referred as VLF/VLFs. The size or number of virtual log files cannot be configured by administrators but it can be affected by number of reasons.

One of the reason is creating or extending log files. The size of the virtual files after a log file has been extended is the sum of the size of the existing log and the size of the new file increment. Here I will show you how VLFs will be increase when we add a new log file or increase the size of transaction log file.

Having large no. of virtual log files are not a good sign and can affect the performance of backup, restore and database startups. Large numbers means close to thousand or more than thousand vlfs. You will not see any visible impact if you have approx. few hundred vlfs.  I would suggest you to read Transaction Log File Architecture to understand more about this.

We can reduce the number of virtual log files by either Backup the Transaction Log of the database or by shrinking the Transaction Log as much as possible using DBCC SHRINKFILE.  Make sure to do this exercise during a maintenance window.

How to Find Total Number of Virtual Log Files?

Now, I will explain how to get total number of virtual log files (VLF/VLFs) for each database on your SQL Server instance. Microsoft has introduced new DMF to monitor, alert, and avert potential transaction log issues in SQL Server 2017. Earlier we were using DBCC LOGINFO to get such information but now we can get in depth information to deal with transaction log queries with the help of this DMF.

The new DMF is sys.dm_db_log_info that will returns VLF information of the transaction log files.  If we will specify NULL or DEFAULT value, it will return VLF information of the current database. The built-in function DB_ID can also be specified to get details of a particular database. The sys.dm_db_log_info DMF replaces the DBCC LOGINFO statement from earlier versions.

Below script will show you total no. of virtual log Files for all databases hosted on a SQL Server Instance.

SELECT name, count(d.database_id) as "Total_VLF_Count" from sys.databases sd
cross apply sys.dm_db_log_info(sd.database_id) d
group by name

We can see the total no. of VLFs in each database. Now we can create a new database and check the VLF count. I have created a new database “Techyaz” and see the database file details.

Create database Techyaz
GO
sp_helpdb techyaz

Now again check the total no. of VLFs by running same command which I have executed in step 1. We can see total no. of vlfs are 4 for techyaz database.

Now I will increase the size of the log file and see the impact of vlf count. Run below command to increase the size of log file.

USE master;
GO
ALTER DATABASE Techyaz
MODIFY FILE
(NAME = techyaz_log,
SIZE = 15MB);

Now again see the no. of vlfs for each database and here we can see, total no. of vlfs have been increase to 8 now.

Similarly we can notice the impact of vlf if we add another log file on this database. Run below command to add a log file to the database Techyaz. I kept the size of this log file is 5MB.

ALTER DATABASE Techyaz
ADD LOG FILE 
(
    NAME = techyaz_log3,
    FILENAME = '/var/opt/mssql/data/Techyaz_log3.ldf',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
)

Check and verify the newly added log file by running sp_helpdb command.

Check again the total vlf count for this database. Here we can see the total no of vlfs are now 12 in this database. So it is proved that vlf counts are increased if we increase the size of log file as well as we add another log file to the database.

This DMF is also useful in getting filtered output like which database have a specified no of vlf counts and what all databases that have less or more no of vlf counts of a specified value.

Run below command to get the name of databases which has more than 10 virtual log files. You can change the 10 value to 100 or 1000 or 10000. It is up to your requirement.

SELECT name, count(d.database_id) as "Total_VLF_Count" from sys.databases sd
cross apply sys.dm_db_log_info(sd.database_id) d
group by name
having count(d.database_id)>10

We can see only one database has more than 10 vlfs that is techyaz which we just created. Similarly we can check about the db names which has less than 10 VLFs by running same command, just change the condition of greater than to less than.

SELECT name, count(d.database_id) as "Total_VLF_Count" from sys.databases sd
cross apply sys.dm_db_log_info(sd.database_id) d
group by name
having count(d.database_id)<10

Below is the view of all columns we can see of this DMF. This is very useful DMF and we can get all information as given below. I ran this command for database Techyaz. We can get the db id of this database from step 2 that is 6. We can also see one row for each VLF in the output as this database has 12 VLF so there are 12 rows here along with the details of each VLF.

SELECT * from sys.dm_db_log_info(6)

We can focus on two columns i.e. vlf_active which is 1 for first vlf and 0 for all that means it indicates whether VLF is in use or not. 0 means vlf is not in use and 1 means vlf is active so we can see only one vlf is active for this database.

Another is vlf_status, it indicate status of the VLF. Possible values include

0 – vlf is inactive
1 – vlf is initialized but unused
2 – vlf is active.

As we know this DMV is the replacement of DBCC LOGINFO so we can compare the output of both. Now run DBCC LOGINFO as see the details for database Techyaz.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• SQL Server Architecture Interview Questions & Answers
• Manage Transaction Log File during Data Load
• How to Improve Bulk Data Load Performance?
• Fix SQL Server Error 1105: Could Not Allocate Space for Object in Database because the Filegroup is Full

The post How to Get Total Number of Virtual Log Files inside SQL Server Database Log Files? appeared first on Techyaz.com.

What is Checkpoint Process in SQL Server?

As per book online, a checkpoint creates a known good point from which the SQL Server Database Engine can start applying changes contained in the log during recovery after an unexpected shutdown or crash.

There are lot of operations run in database. If SQL Server performs any modifications to any database pages in memory/buffer cache, SQL Server doesn’t write these modified pages to disk after every change. Rather, SQL Server Database Engine periodically issues a checkpoint on each database and these modified pages and transaction logs in memory will be written to disk as part of checkpoint process.

Checkpoint Types

SQL Server supports four types of checkpoints. Which checkpoint SQL Server database engine will use to write dirty pages to disk is based on their nature of operations and few configuration parameters which we set on instance level as well as database level. Below are the list of checkpoints SQL Server performs.

Automatic Checkpoints

An automatic checkpoint occurs each time the number of log records reaches the number the Database Engine estimates it can process during the time specified in the recovery interval server configuration option. You can set the value of recovery interval using below system stored procedure.

sp_configure 'recovery interval','seconds'

Recovery interval is maximum time that a given server instance should use to recover a database during a system restart. Database Engine estimates the maximum number of log records it can process within the recovery interval. When a database using automatic checkpoints reaches this maximum number of log records, the Database Engine issues an checkpoint on the database.

The frequency depends on the value of recovery interval option of server configuration. The time interval between automatic checkpoints can be highly variable. A database with a substantial transaction workload will have more frequent checkpoints than a database used primarily for read-only operations.

Database Engine generates automatic checkpoints for every database if you have not defined any value for target recovery time for a database. If you define user value for target recovery time for any database, database engine will not use automatic checkpoint and generate indirect checkpoint which I will discuss in next section.

Under the simple recovery model, an automatic checkpoint is also queued if the log becomes 70 percent full.

After a system crash, the length of time required to recover a given database depends largely on the amount of random I/O needed to redo pages that were dirty at the time of the crash. This means that the recovery interval setting is unreliable. It cannot determine an accurate recovery duration. Furthermore, when an automatic checkpoint is in progress, the general I/O activity for data increases significantly and quite unpredictably.

For an online transaction processing (OLTP) system using short transactions, recovery interval is the primary factor determining recovery time. However, the recovery interval option does not affect the time required to undo a long-running transaction. Recovery of a database with a long-running transaction can take much longer than the specified in the recovery interval option.

Typically, the default values provides optimal recovery performance. However, changing the recovery interval might improve performance in the following circumstances:

1. If recovery routinely takes significantly longer than 1 minute when long-running transactions are not being rolled back.
2. If you notice that frequent checkpoints are impairing performance on a database.

If you decide to increase the recovery interval setting, we recommend increasing it gradually by small increments and evaluating the effect of each incremental increase on recovery performance. This approach is important because as the recovery interval setting increases, database recovery takes that many times longer to complete. For example, if you change recovery interval 10 minutes, recovery takes approximately 10 times longer to complete than when recovery interval is set to 1 minute.

Indirect Checkpoints

This checkpoint was introduced in SQL Server 2012. Indirect checkpoints provide a configurable database-level alternative to automatic checkpoints. In the event of a system crash, indirect checkpoints provide potentially faster, more predictable recovery time than automatic checkpoints. We can set the TARGET_RECOVERY_TIME in Indirect checkpoint for any database by executing below ALTER DATABASE statement.

--Change DBNAME with your database name.
ALTER DATABASE DBNAME SET TARGET_RECOVERY_TIME =target_recovery_time {SECONDS | MINUTES}

The difference between Automatic and Indirect checkpoint is, recovery interval configuration option uses the number of transactions to determine the recovery time as opposed to indirect checkpoints which makes use of number of dirty pages.

When indirect checkpoints are enabled on a database receiving a large number of DML operations, the background writer can start aggressively flushing dirty buffers to disk to ensure that the time required to perform recovery is within the target recovery time set of the database. This can cause additional I/O activity on certain systems which can contribute to a performance bottleneck if the disk subsystem is operating above or nearing the I/O threshold.

1. Indirect checkpoints enable you to reliably control database recovery time by factoring in the cost of random I/O during REDO.
2. Indirect checkpoints reduce checkpoint-related I/O spiking by continually writing dirty pages to disk in the background. However, an online transactional workload on a database configured for indirect checkpoints can experience performance degradation. This is because the background writer used by indirect checkpoint sometimes increases the total write load for a server instance.

Indirect checkpoint is the default behavior for new databases created in SQL Server 2016. Databases which were upgraded in place or restored from a previous version of SQL Server will use the previous automatic checkpoint behavior unless explicitly altered to use indirect checkpoint.

Manual Checkpoints

Manual checkpoint issued when you execute a T-SQL CHECKPOINT command for a database. By default, manual checkpoints run to completion. Throttling works the same way as for automatic checkpoints.

Internal Checkpoints

Internal Checkpoints are generated by various server components to guarantee that disk images match the current state of the log. Internal checkpoint are generated in response to the following events:

1. Database files have been added or removed by using ALTER DATABASE.
2. A database backup is taken.
3. A database snapshot is created, whether explicitly or internally for DBCC CHECK.
4. An activity requiring a database shutdown is performed. For example, AUTO_CLOSE is ON and the last user connection to the database is closed, or a database option change is made that requires a restart of the database.
5. An instance of SQL Server is stopped by stopping the SQL Server (MSSQLSERVER) service. Either action causes a checkpoint in each database in the instance of SQL Server.
6. Bringing a SQL Server failover cluster instance (FCI) offline.

Checkpoint generated by SQL Server in different scenario

Now one question might come to your mind that how SQL Server decide which checkpoint should be used between Automatic and Indirect checkpoint if a database has target recovery time value is set to use indirect checkpoint. Below are the configuration values based on which SQL Server considers to generate either automatic checkpoint or indirect checkpoint?

1. Automatic checkpoints whose target recovery interval is 1 minute will be generated if ‘recovery interval’ value in sp_configure command and TARGET_RECOVERY_TIME value in ALTER DATABASE command is set to 0.
2. Automatic checkpoints whose target recovery interval is specified by the user defined setting of the sp_ configure recovery interval option if TARGET_RECOVERY_TIME value in ALTER DATABASE command is set to 0 and if ‘recovery interval’ value in sp_configure command is non zero.
3. Indirect checkpoints when target recovery time is determined by the TARGET_RECOVERY_TIME value in ALTER DATABASE command.

You can follow attached link to understand SQL Server Transaction Log Architecture which is also related to checkpoints topic. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Manage Transaction Log File during Data Load
• Why Should You Always Turn Off Database Auto Shrink Property?
• understand the best value for database file autogrowth
• SQL Server Architecture Interview Questions & Answers

The post What is Checkpoint Process in SQL Server? appeared first on Techyaz.com.