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.

We had few options to overcome this issue. As we were running this database in simple recovery mode, so we didn’t have an option to run the Transaction Log backup. We tried to shrink the log file to manage transaction log file but it was not allowing us to do so. This might be due to the data load execution was in process and active transaction.

Finally, we left out with two options; either extend the log drive or add a log file to the database on a drive that has enough space to accumulate the logs. Extending the existing drive was not possible because data load was in progress and we need to fix this issue without stopping the import/data load. So, we decided to go with another option that was to add a database log file to a drive that has enough space. I have given you step by step method to add a log file to a database in below section.

Add Log File to a Database

I will show you how to add log file to a database using T-SQL statements and using GUI in SQL Server Management Studio to manage transaction log file during data load. This way you can manage if your transaction log file is growing faster.

Using T-SQL Statement

Open new query window and run below T-SQL statement to add a log file TY1_Log3.ldf to database TY1 on F drive. Have a look at below T-SQL code to get other details like sizing and growth details.

--Replace your Database Name and file details in below T-SQL Code.
ALTER DATABASE [TY1]
ADD LOG FILE (NAME = 'TY1_Log3', FILENAME = 'F:\TY1_Log3.ldf', SIZE = 20080 MB, FILEGROWTH = 5024 MB)
GO

Once you execute above T-SQL statement, your log file TY1_Log3.ldf will be added on F drive to the database TY1.

Remember, add the log file in a drive where you have enough space. If you will add log file to data file drive then you might face IO pressure because both data and log files will be on same drive so avoid to keep data and log file on same drive.

Using GUI in SSMS

1. Launch SQL Server Management Studio and connect to the instance of the SQL Server Database Engine. Expand Databases folder, right-click the database in which you have to add the log file, and then click Properties.
2. In the Database Properties dialog box, select the Files page from left side pane.
3. To add a transaction log file, click Add button from lower right side pane.
4. In the Database files grid, enter a logical name for the file. The file name must be unique within the database. Select the file type as log. Specify the initial size of the file. Set Autogrowth column as per your requirement.
5. Specify the path for the file location along with physical log file name. The specified path must exist before adding the file. Make sure that your drive has enough space to host this log file.
6. Click on OK button to create this add this log file to the database.

Once you performed step 6, log file will be added to your database on your identified drive name. These exercises (adding log file to database) doesn’t require any downtime or it will not interrupt any existing transactions. This way you can manage transaction log file during data load if your transaction log file is growing faster.

Read More

• How to get Total no. of Virtual Log Files in a Transaction Log file?
• Understanding Transaction Log File Architecture
• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the best value for database file autogrowth?

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

The post Manage Transaction Log File during Data Load 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.

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