Error: 1101, Severity: 17, State: 2
Could not allocate a new page for database ‘DBNAME’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

There is another error 1105 that is also very much like above error code. Error 1105 can also be fixed using same solution given in this article.

Error 1101 – Root Cause

Main reason behind error 1101 or error 1105 is the insufficient disk space in filegroup/files. You might also get this error if your database drives are running out of space. There are multiple reasons that can cause this error to generate. Some of them are given below.

• You have restricted database maximum file size or put size limits for files.
• Database file drives are running out of space.
• Autogrowth is not enabled for database files.

Solutions

To fix this issue we need to make space for database files to grow. Issue might vary depending on the nature of issue mentioned in above section. Sometimes, you might face this issue if maximum size for database files are restricted to some values so whenever database will grow to that point, SQL Server will not allow to allocate any page to that database. Sometimes you might get error 1101 because you don’t have any space on your database drives. Here, I will discuss each case individually and its solution to fix it.

Unrestrict or Increase Database File Size Limits

You might have enough space in your database drives but still you can get error 1101 because the maximum file size of database files is limited to some value and that causes not to grow your database beyond that size. You can unrestrict or increase the existing value of maximum file size to some bigger value. We have also an option to set database file size to unlimited size value that means database file will grow till the database file drive limit. Make sure to set appropriate autogrowth size for each database files.

You can set unlimited file size option or increase the value of maximum file size using GUI in SQL Server Management Studio or using ALTER statement.

• Connect to Database Instance in SQL Server Management Studio. Expand Database folder.
• Right Click on your database and choose Property window.
• Click on Files tab from left side pane in database property window.
• Here you can see all database files. Now you can click on three dots given next of database files in “Autogrowth/Maxsize” column. You can see max size is set to a limited value as shown in below screenshot. I have chosen unlimited option and clicked on Ok button.

Now we will not get any issue if our database drive has enough space.

Space in Database Drives

Another possibility for this error is, there might be possibility that your drives on which you have placed your database files are running out of space. If this is the case then you have below 4 options.

• Add additional database file to different disk where there is enough space.
• Move additional/unwanted files from your existing database drives.
• Drop/Purge or Move unwanted data (table/indexes)
• Add Additional Disk Space

Immediate fix of this issue is to add new database file to another drive where you have enough space to run your transactions. You can use below command to add addition database file to another disk.

USE [master]
GO
ALTER DATABASE [DBNAME]
ADD FILE (NAME = N'NewFileName', FILENAME = N'F:\mssql\data\newdatafile.ndf', SIZE = 100096KB, FILEGROWTH = 10240KB)
TO FILEGROUP [SECONDARY]
GO

You can also add new database file in SQL Server Management Studio by launching Database Property Window. Select Files from left side pane and Click on “Add” button showing in below screenshot. Make sure to set autogrowth value carefully for any database file. Also it is recommended to enable IFI – Instant File Initialization to speed up autogrowth process for your databases. Refer to below article to get best value for autogrowth for your database files. You can also read what are the benefits and how to enable IFI – Instant File Initialization in below article.

• What Should be the Best Value for database Autogrowth settings?
• How to Enable Instant File Initialization in SQL Server?

You can also have a look at the existing database drives whether there is any unwanted files or older backup files (*.bak) are not stored. Sometimes we run backups into database drives and forgot to delete or move them. Make sure to drop or move all unwanted files to some other location. Database drives should have only database files.

Final and long-term solution is the data purging. Identify the database objects that are not needed and then plan the data removal or data purging process to make space on your database.

We also have an option to extend the database drives as per the data growth. Make sure to plan this activity carefully before deploying it on production servers.

Enable Autogrowth

I have already written an article on Database autogrowth property setting. Read attached article to find out best value for Autogrowth settings.

You might get error 1101 if you have not enabled authogrowth setting for your database files. You need to enable it by launching database property window. You can click on three dots next to each database files in column “Authogrowth/Maxsize” and click at the enable authogrowth checkbox as showing in below screenshot.

You can also use ALTER statement to enable database autogrowth setting for your database file. Remember, you need to run this ALTER statement for each database file separately.

Run below ALTER command to enable autogrowth for database file.

--Pass logical filename of your database file for under NAME section.
ALTER DATABASE [Techyaz] MODIFY FILE ( NAME = N'Techyaz_Data', FILEGROWTH = 10000KB )

Make sure to enable Instant File Initialization to speedup autogrowth operations. Links to enable Instant File Initialization is attached in this article.

If you are facing this issue for tempdb database then you can consider one more option apart from all of the above options. And this option is to restart SQL Server service if it’s allowed. Keep in mind, SQL Server service restart will cause an outage for few minutes but it will create new tempdb files with initial size and error 1101 will be disappeared. This is not recommended solution because of outage so you should work on long terms solutions.

You can also use above solutions to fix error 1105 that is very much similar to error 1101. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 5144 and Error 5145 for Long or Failed Autogrow of Database Files
• Understanding Autogrowth Operation in SQL Server Databases
• How to Enable IFI – Instant File Initialization?
• Manage Database Files during huge Data Load

The post Fix Error 1101: Could not allocate a new page for database appeared first on Techyaz.com.

Msg 5144
Autogrow of file ‘Data or Log file name’ in database ‘Database’ was cancelled by user or timed out after <n> milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.

Or you will get below message if autogrow operation or data/log file size increase operation will run for longer duration than expected.

Msg 5145
Autogrow of file ‘Data or Log file name’ in database ‘Database’ took <n> milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.

Whenever data or log file growth operation is taking lot of time then a wait type PREEMPTIVE_OS_WRITEFILEGATHER will be shown in to SQL Server. If you want to read more about this wait type then click at the attached link. 

Root Cause

Data and log file initialization takes lot of time if you have to create large database files or large data or log file growth will be performed. Whenever we allocate or extend space to data or log file, it first fills with zeros. Zeroing operation takes lot of time for bigger size autogrowth operations that causes for longer run to complete. We generally see these messages (5144 or 5145) during either extending the data or transaction log files or during autogrowth operation for data or log files.

Microsoft has given a solution named Instant File Initialization to fix the time consuming file size allocation for data files. Once Instant File Initialization will be enabled, your data files size allocation will be done in faster way but unfortunately Instant File Initialization does not work on transaction log files.  Instant file initialization reclaims used disk space without filling that space with zeros. Instead, disk content is overwritten as new data is written to the files. Read below section to overcome these error messages.

Solution

To avoid these messages 5144 or 5145 to be logged, we should plan file size growth carefully. We should set maximum size of the database so that it could not perform frequent autogrowth operation. We can enable Instant File Initialization feature to speed up the data file size allocation. It is not recommended to rely on autogrowth of files as standard operation for obtaining more space in a file. Rather, you should plan out the maximum size of your database and/or transaction log file and allow autogrowth to occur only in unplanned situations for space. Follow below points to avoid this error.

• Enable Instant File Initialization to speed up data file size allocation. Read attached article to enable IFI (Instant File Initialization) on your database server.
• As IFI (Instant File Initialization) does not work on log files so we need to set log files in smaller chunks to avoid any time out error or longer runs.
• Set database size to the maximum size it could be and allow autogrowth settings to occur only in unplanned situations for space.Read attached article to understand Autogrowth setting and its perfect value for database files.

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

Related Articles:

• Manage Transaction Log File during Data Load
• How to Improve Bulk Data Load Performance?
• How to Reduce SQL Server Wait type PREEMPTIVE_OS_WRITEFILEGATHER?
• Why Should You Always Turn Off Database Auto Shrink Property?
• Fix Error 3023: Shrink failed for Log file

The post Fix SQL Server Msg 5144 and 5145 for long or failed autogrow of data and log files appeared first on Techyaz.com.

1. Get log space size
2. View wait statistics data
3. Clear wait statistics data
4. Clear latch statistics data

Let’s discuss each of above tasks as use cases of DBCC SQLPERF command.

Read More

• How to get total no of VLFs (Virtual Log Files) inside Log file?
• Understanding Data Files, Pages & Extents
• How to Avoid Page Split in SQL Server?

Get Transaction Log space using DBCC SQLPERF

We can get transaction log space utilization details like how large your transaction logs are and what percentage of them is in use by executing dbcc sqlperf command. Run below command to get the log space details of all database hosted your SQL Server Instance.

--Get Transaction Log Size Details
DBCC SQLPERF(logspace)

You can see the below screenshot; all the columns are self-explanatory. We can see percent of log space used out of total space allocated to the log file.

View and Clear Wait Statistics Data

We can get wait statistics data using dbcc sqlperf command as well. We used to get these details using dbcc sqlperf command in older version of SQL Server instances. Although, you can still get wait statistics data using this command in current versions of SQL Server but now there is a better way to get such details using DMV sys.dm_os_wait_stats.  Here, I will show you wait stats data using DMV only. Run below commands to get wait statistics details of your SQL Server instance.

--Get wait Statistics using DBCC command.
DBCC SQLPERF(waitstats)

--Get Wait Statistics using DMV sys.dm_os_wait_stats
SELECT * FROM sys.dm_os_wait_stats
Order by wait_time_ms desc

You can see the details about all wait types on your SQL Server instance. You can also see the total wait time in milliseconds. These information is very important to deal with performance issues but details like total wait time, total waiting tasks count are not the real-time values. These values are accumulated since last SQL Server service start or last time wait stats was reset using dbcc sqlperf command. It is highly recommended to not clear wait stats data until it is required to do that otherwise you will lose valuable information about wait statistics. Read attached article about why should you not clear wait statistics data stored in DMV sys.dm_os_wait_stats.

If you want to get the correct waiting task counts or waiting time then you need to clear the wait statistics data using dbcc sqlperf command. Here, I will show you the difference after clearing the wait stats. Run below command to clear all wait stats data on your SQL Server Instance.

DBCC SQLPERF(“sys.dm_os_wait_stats”, CLEAR)

You can see I have successfully ran this command in below screenshot.

Now we will again run same command to get the wait statistics data. I ran it and I get below data that is showing different than the one showing before clearing wait stats. This way you can better analyze your database performance and waiting tasks and time to reach on any conclusion.

Clear Latch Statistics Data

I described about clearing wait stats data in above section. Here, I will show you how to clear latch statistics data. Latches are locks for RAM memory structures to prevent concurrent access and ensure serial execution of kernel code. You can run SQL command to check current latch statistics data.

--Get latch statistics data
SELECT * FROM sys.dm_os_latch_stats
ORDER BY wait_time_ms desc

You can see current latch statistics details that is also not showing only real time value but it is accumulated data since last SQL Server service restarted or last time latch wait statistics was reset/cleared.

Now we will clear these latch statistics data to get real time value of latch details. Run below dbcc sqlperf command to clear the latch statistics.

DBCC SQLPERF(“sys.dm_os_latch_stats”, CLEAR)

You can see we have successfully executed above command on our SQL Server Instance.

Now go ahead and run same SQL command to get the latch statistics again. You can see now there is no waiting requests on our SQL Server Instance and you are getting real time value about latches.

Related Articles

• Should We Clear Wait Stats Data from DMV sys.dm_os_wait_stats?
• How to Fix BACKUPBUFFER Wait Type?
• How to Improve Bulk Data Load Performance?

These are the 4 use cases of DBCC SQLPERF command that we use during different database activities. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post 4 Different Usages of DBCC SQLPERF in SQL Server appeared first on Techyaz.com.

Let me first give you some background about SAP migration tool like how it works. SAP Migration tool first captures every related information along with data and creates an export file that needs to be copied to the target location or server and then we perform bulk data import with the help of SAP migration tool. Bulk data import or data load will be done locally and not over network.

When we ran SAP migration tools to capture all details, a dump file was created that we have copied to the SQL Server box. We had approx. 900GB of data that needs to be loaded into SQL Server database. When we performed SQL Server data load using SAP migration tools with standard settings, it took around 14 hrs. to complete the bulk data import.  As 14 hrs. was very long time so we decided to work on reducing the total time taken by import process.

We made some changes from both sides application as well as SQL Server database side. SQL Server data load time has reduced drastically to around little more than 6 hours post these change implementations. Here, I am explaining each parameter that we have configured from database side just for this bulk data import.

NOTE: Make sure to revert these changes as per your application/vendor best practices post this bulk data import for OLTP/normal operations. We are changing value considering Data Load only.

It is important to understand the factors that affect bulk data import performance. To speed up the data load, you need to look into below configuration options from DBA standpoint.

Auto Grow

 Autogrow settings can be used to automate SQL Server database file growth. This is very useful property but this can degrade your bulk import performance or data load operations. Read attached article to understand SQL Server Autogrow setting in detail.

Autogrow setting increment must be large enough to avoid the performance penalties.  If you set default or small value during bulk import or data load, database engine will have to perform data file autogrow operation every time the file will be filled with data till maximum size limit. More autogrow operation will take more resources like IO, CPU etc and time to complete the data load transaction.

The exact value for this setting should be based on data growth. You should not be left autogrow in percentage value rather you should use some value in MBs. A general rule of thumb is to set your autogrow setting to about one-eighth the size of the file. Please read attached article to understand how to manage transaction log files during huge data load.

I would suggest keeping database size as much as you are expecting your database will grow to avoid autogrow operation. If you are aware that your database size will be 900 GB post data load, you should set your database size to 900 GB before starting the data load. This will improve the bulk import performance. Make sure to enable IFI (Instant File Initialization) for your SQL Server instance to reduce total time SQL Server takes to set the database size.

Instant File Initialization

As I suggested in above point, Turn IFI (Instant File Initialization) ON to speed up AutoGrow process. If you set a considerable large value to autogrow settings, it will take some time to increase the size by zeroing the disk address. IFI speeds up this process and allow us to create enormous size of data files in quick way. Read attached article to learn more about IFI (Instant File Initialization) and how it will speed up autogrow or data load operation. You will also learn how to enable IFI for your SQL Server instance in this attached article.

Auto Shrink

AutoShrink is very costly operation that should be always OFF even during your daily and normal operations. Turn it OFF immediately. Make sure your disk has enough space to sustain during bulk operations or data load. Repeatedly shrinking and growing the data files will cause file-system level fragmentation, which can slow down performance. It also takes lot of CPU and IO. Read attached article to know why you should always keep Auto_Shrink off.

Reduce Logging

Change recovery model to SIMPLE or BULK-LOGGED to reduce the logging operations. The simple recovery model minimally logs most bulk operations. For a database under the full recovery model, all row-insert operations that are performed during bulk import are fully logged in the transaction log.

For large data imports, this can cause the transaction log to fill rapidly. For bulk-import operations, minimal logging is more efficient than full logging and reduces the possibility that a bulk-import operation will fill the log space. To minimally log a bulk-import operation on a database that normally uses the full recovery model, you can first switch the database to the bulk-logged recovery model. After bulk importing the data, switch the recovery model back to the full recovery model.

Auto_Update_Statistics

Auto_Update_Statistics is very useful property that should be set to ON during normal business operations but here I would suggest turning it off during huge data load or bulk import operations. Updating the statistics also takes resources from the system. This can lead to performance issues when you are doing bulk data. It’s important to keep up-to-date statistics for the optimizer to use, but here we will turn it off and once data load or bulk data inserts will be performed, we will again enable it.

Auto_Create_Statistics

This should be OFF because creating statistics also takes resources from the system that can degrade the overall bulk import performance. Make sure to enable it post data load or bulk inserts operation.

Parallelism – MAXDOP

SAP suggests setting MAXDOP value to 1 during normal business operation so we had this value during first data load that took around 14 hrs. We had assigned half of the CPU cores for the parallel processes during data load and bulk import operations. I believe MAXDOP has contributed significant role in reducing total data load time. Make sure to revert this change to its original value as per your application best practices.

You can change MAXDOP settings either using sp_configure command or using GUI in SSMS by launching SQL Server Instance property window.

Using Batches

Make sure to use an optimum batch size that will increase the bulk data import performance. Importing a large set of data as a single batch can be problematic, so bcp and BULK INSERT let you import data in a series of batches, each of which is smaller than the data file. Each batch is imported and logged in a separate transaction, and after a given transaction is committed, the rows imported by that transaction are committed. If the operation fails, only rows imported from the current batch are rolled back, and you can resume importing data starting at the beginning of the failed batch rather than at the beginning of the data file.

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

The post How to Improve SQL Server Bulk Data Import Performance? appeared first on Techyaz.com.

• 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.

Related Articles:

• Manage Transaction Log File during Data Load
• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the best value for database file autogrowth?
• What is the Suitable Value for Fill Factor?

Logical Architecture

To understand SQL Server Transaction Log File Architecture, we need to start with basics. As we know transaction log file is mandatory database file for a database. Every database must have at least one transaction log file. SQL Server uses transaction log file to capture log records that guarantee the data integrity of the database and for data recovery.

Logically, SQL Server transaction log is a string of log records. Each log record is identified by a log sequence number (LSN). Each new log record is written with the incremental LSN that means a new log record will be assigned a LSN that is higher than the LSN of the record before it. Log records are stored in a serial sequence as they are created.

Operations that recorded in the Transaction Log File

There are many types of operations recorded in Tlog files. These operations include:

1. The start and end of each transaction.
2. Every data modification (insert, update, or delete). This includes changes by system stored procedures or data definition language (DDL) statements to any table, including system tables.
3. Every extent and page allocation or deallocation.
4. Creating or dropping a table or index.
5. Rollback operations. Each transaction reserves space on the transaction log to make sure that enough log space exists to support a rollback that is caused by either an explicit rollback statement or if an error is encountered. This reserved space is freed when the transaction is completed.

The section of the log file from the first log record that must be present for a successful database-wide rollback to the last-written log record is called the active part of the log, or the active log. This is the section of the log required to do a full recovery of the database. You can not truncate any part of active log. 

Physical Architecture

As we know, a series of log records stores in transaction log file. These log files store physically on OS drive/disk along with SQL Server data files. Each transaction log file internally divided into a number of virtual log files. Virtual log files have no fixed size, and there is no fixed number of virtual log files for a physical log file.  The size or number of virtual log files cannot be configured by administrators. You can get total count of virtual log files or vlfs in a SQL Server database log file/s in attached link. Here, i have explained in detail about how to track virtual log files.

The Database Engine chooses the size of the virtual log files dynamically while it 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.

If we define small Tlog file size along with small growth increment then it will cause performance issue to your system because whenever log file needs more room, it will increase log file size frequently due to small size of growth increment so it will create lot of virtual log files as well. This will affect performance of backup and restore operation along with database startup performance.

Microsoft recommends that we should assign log files a size value close to the final size required, and also have a relatively large growth increment value.

How Transactions Log File works?

The transaction log is a wrap-around file. Let us demonstrate it using a scenario given in Microsoft Book Online.

Consider a database with one physical log file divided into four virtual log files. When the database is created, the logical log file begins at the start of the physical log file. New log records are added at the end of the logical log and expand toward the end of the physical log. Log truncation frees any virtual logs whose records all appear in front of the minimum recovery log sequence number (MinLSN). The MinLSN is the log sequence number of the oldest log record that is required for a successful database-wide rollback.

When the end of the logical log reaches the end of the physical log file, the new log records wrap around to the start of the physical log file.

This cycle repeats endlessly, as long as the end of the logical log never reaches the beginning of the logical log. If the old log records are truncated frequently enough to always leave sufficient room for all the new log records created through the next checkpoint, the log never fills. However, if the end of the logical log does reach the start of the logical log, one of two things occurs:

1. If the FILEGROWTH setting is enabled for the log and space is available on the disk, the file is extended by the amount specified in growth_increment and the new log records are added to the extension.
2. If the FILEGROWTH setting is not enabled, or the disk that is holding the log file has less free space than the amount specified in growth_increment, a 9002 error is generated.

If the log contains multiple physical log files, the logical log will move through all the physical log files before it wraps back to the start of the first physical tlog file.

You can follow attached link to understand SQL Server data files, Pages & Extents.  I hope you like this article. Here i have described SQL Server Transaction Log File Architecture that will help you to understand SQL Server database system. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Understanding Database Shrink Operation and Why Should We Avoid It?
• How to Avoid Page Split in SQL Server?
• Fix SQl Server Error 5144 and 5145 for long and failed Autogrow of data and log file

The post Understanding SQL Server Transaction Log File Architecture appeared first on Techyaz.com.