SQLServer Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

SQL Server Error 802 – Insufficient Memory Available in the Buffer Pool

The main reason behind getting SQL Server error 802 is your SQL Server instance is under memory pressure and there is not enough memory available to allocate further to buffer pool or buffer pool is restricted to not use memory beyond a certain limit. This might be because of various reasons as i have stated in below section. One of the very easy and straight forward approach to fix this error is to increase more memory to SQL Server system and modify max server memory in SQL Server accordingly.

Analysis & Solution

I would suggest to go deeper in this issue before taking any decision to allocate more memory to the system where SQL Server is running. There could be multiple temporary reasons as well which can cause SQL Server to generate below error log:

SQL Server Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

Let’s discuss this issue further and ensure to not forget below points before taking any decisions.

Please comment us about your issue experience and let me know how you have fixed your issue.

Related Articles:

• How to Fix SQL Server Error 701: There is insufficient system memory to run this query
• Understanding Hybrid Buffer Pool in SQL Server
• SQL Server Interview Questions & Answers

The post Fix SQL Server Error 802: There is insufficient memory available in the buffer pool. appeared first on Techyaz.com.

If you have highly transactional SQL Server then enabling Lock Pages in Memory will improve SQL Server performance. Always keep in mind that If you are running SQL Server Instance on virtual machine and when you have decided to enable Lock Pages in Memory for SQL Server then you should also consider setting virtual machine’s memory reservation to match the amount of the provision memory. SQL Server Lock Pages in Memory should also be used in conjunction with the Max Server Memory setting to avoid SQL Server taking over all memory on the virtual machine.

You can use Windows Group Policy tool (gpedit.msc) to enable this policy for SQL Server. You must be system administrator to change this policy. We just need to add SQL Server service account to this policy to enable SQL Server Lock Pages in Memory. If you want to enable it for some other application then you can simply add that application’s service account to this policy.

You need to find the correct SQL Server service account either using SQL Server Configuration Manager or using windows services console (services.msc) before going to enable this policy for SQL Server.

Enable Lock Pages in Memory

1. First step is to get the service account of the process or application for that we need to enable Lock Pages in Memory. As we have to enable Lock Pages in Memory for SQL Server so we will find SQL Server service account.

2. To get the SQL Server service account, you need to either open SQL Server Configuration Manager or you should open windows services console (services.msc). Here you can double click on SQL Server service then you can click at Log on tab. Here, you can see correct service account that is used to run SQL Server.

3. Now you have SQL Server service account. Go to Run command and type gpedit.msc.

4. You will get Local Group Policy Editor console, expand Computer Configuration, and then expand Windows Settings from left side pane of this window.

5. Now, expand Security Settings under Windows Setting folder, and then expand Local Policies.

6. Here, you can see three options, now click at User Rights Assignment folder. All policies will be displayed in the right-side pane.

7. Search Lock Pages in Memory policy in right side pane and then double-click on it to open its property window.

8. Now another window named Lock pages in memory  Properties will appear on your screen, click at Add User or Group tab.

9. Here, you need to enter the SQL Server service account that you have captured at second step. In the Select Users, Service Accounts, or Groups dialog box, select the SQL Server Service account. Once you add SQL Server Service account then click on Ok button to close that window.

10. Now last step is to restart SQL Server Service for this setting to take effect. Now you have enabled SQL Server Lock Pages in memory.

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

Read More:

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Top 10 Perfmon Counters to Identify SQL Server Memory Pressure
• SQL Server Error 701 and Error 802: There is Insufficient System Memory to Run this Query
• SQL Server Memory Allocation & Role of MIN/MAX Server Memory Configuration

The post How to Enable Lock Pages in Memory for SQL Server? appeared first on Techyaz.com.

I have already explained top performance counters to detect Memory and Disk IO bottlenecks in SQL Server in my last articles. Have a look at them (attached below) to get Memory and Disk IO related performance counters and their ideal values for healthy system.

• Top 10 Performance Counters to Identify SQL Server Memory Pressure
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Generally, CPU bottleneck arises because of either your system has not enough CPUs to process current workload or your transactions or applications are poorly designed that causes the high CPU. To deal with SQL Server CPU pressure, we need to either find the high CPU intensive queries and optimize them or increase the total CPU counts of the database server to handle current workload. There can be multiple reasons for high CPU usage like high recompilations of SQL Queries, OS issues, Query design issues: Sorting Joins, Poor Indexes, Condition Clauses etc. Here, I am going to explain about top perfmon counters to identify SQL Server CPU bottleneck.

Perfmon Counters for CPU Usage

Here, I am going to describe about perfmon counters for CPU usage in SQL Server. Ideally, first we should start with looking at CPU usage in Windows Task Manager. If the CPU utilization is continuously going beyond 85%, it means your system is facing CPU bottleneck. Find the list of performance counters to identify SQL Server CPU bottleneck.

Processor: % Processor Time 

One of the very useful CPU perfmon counter for SQL Server is Processor: % Processor Time. This counter displays the percentage of time CPU spends executing a thread that is not idle. If your system is frequently reaching beyond 85% then it means your system is facing CPU bottleneck. The acceptable value for this counter should be less than 50%.

Processor: % User Time

Windows operating system has two modes of processing for any process. One is Kernel mode another one is user mode. This counter shows the percentage of time a process spends executing user processes like SQL Server. If this counter is high it means CPU pressure is because of SQL Server or because of user applications. You should focus to retrieve CPU intensive queries to get the culprit transactions that are causing high CPU pressure. There is no idle value for this counter. You should benchmark each system based on your workload.

Processor: % Privilege Time

This counter shows the percentage of time the processor spends on execution of Microsoft Windows kernel commands, such as processing of SQL Server I/O requests. This counter captures the information about kernel mode and indicates towards poor performance of disk subsystems. Monitor DISK IO related performance counters to identify DISK IO bottleneck and if possible, consider installing a faster or more efficient disk subsystem.

Processor: % Interrupt Time

This counter Processor: % Interrupt Time tells about the time a processor spends receiving and servicing hardware interruptions during specific sample intervals. This counter indicates a possible hardware issue if the value is greater than 15 percent.

System: Processor Queue Length

This is an important perfmon counter to detect CPU bottleneck. This counter gives information about the number of threads waiting for processor time. If value of this counter is greater than zero then this is a sign of CPU bottleneck. We can further check Compilations/sec and Re-Compilations/sec. A high number of compilations and recompilations usually indicates poor reuse of the query plans. This can be fixed by optimizing your queries and stored procedures.

System: Calls/sec

Any system would have either software calls or application related calls or hardware related calls. This counter System: Calls/sec metric shows the number of software calls to the operating system service routines per second. Similarly, another CPU perform counter Processor: Interrupts/Sec shows the number of hardware calls to the processor. Both perfmon counters can be used to determine the source of the performance issues. The acceptable values for System: Calls/sec are under 20,000. Higher values might indicate excessive operating system activity caused by software applications.

Context Switches/sec

Context Switches occurs when kernel switches processor from one thread to another. The acceptable Context Switches/sec value should be less than 2,000 per processor. If you are observing constant high values of Context Switches/sec and Processor: % Processor Time on your system then this would be a clear sign of processor bottlenecks. Permanent solution to reduce CPU bottleneck is to change the processor to a more powerful one, or add an additional to existing ones.

You might have seen high Context Switches/sec values for systems that are running with multiple SQL Server instances or a system that is hosted other applications along with SQL Server.

Here I have described top perfmon counters for CPU usage on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding Database Shrink Operation and Why should you Avoid it?
• Fix Error 701: There is Insufficient System Memory to Run this Query
• How to Improve Bulk Data Load Performance?

The post Top Perfmon Counters to Identify SQL Server CPU Bottleneck appeared first on Techyaz.com.

• Fix SQL Server Error 701: There is Insufficient System Memory to Run this Query

We can use Windows PerfMon utility to gather current values of all given performance counters. Just type perfmon in run prompt to launch perfmon tool to gather memory related performance counters. Although, Microsoft has also given a DMV related to performance counters that is very useful in collecting data and detecting CPU, IO or memory bottleneck in SQL Server. You can run below command to get all performance counters and their respective values using DMV sys.dm_os_performance_counters. You can also use this DMV to get performance counter values to identify memory pressure in SQL Server.

Select * from sys.dm_os_performance_counters

By default, SQL Server changes its memory requirements dynamically, on the basis of available system resources. I have explained SQL Server Memory Management and how SQL Server allocated memory to their transactions in below attached article.

• SQL Server Memory Allocation & Role of MIN/MAX Server Memory Configuration

Performance Counters to Identify SQL Server Memory Pressure

Let’s discuss top perfmon counters for memory usages to identify its bottleneck. Below is the list of top 10 performance counters to identify SQL Server Memory pressure. If you want to read CPU and Disk IO related perfmon counters then i would suggest you to read below attached articles.

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Memory: Available Bytes

First thing you should look at in case of memory bottleneck in SQL Server is the available memory that can be used by processes. You can get this value by looking at the counter Available Bytes under object Memory. Low value of this counter shows the memory shortage on this server.  Now, you should focus behind the reason of this memory shortage. There might be possibility that some of your applications running on your server are not releasing memory or your system has not enough memory to perform current workload that leads to the memory bottleneck in SQL Server.

Memory: Pages/sec

This counter indicates the total number of pages that are either read from disk or written to the disk due to page fault. When a process requests a data page that is not in memory then it will be retrieved from disk to memory. This process is known is page fault. High value of this counter could indicate the excessive paging. We should further monitor Memory: Page Faults/sec counter to go indepth information. The average Pages/sec value should be below 50. A high value of Pages/sec indicates intensive memory activities like read from and write to disk. It means transactions are getting enough memory that is why they are using disk to process their requests.

Memory: Page Faults/sec

High value of counter Memory: Pages/sec could indicate the excessive paging. Next, we should monitor the Memory: Page Faults/sec counter to make sure that the disk activity is not caused by paging. If you want to determine whether SQL Server or another process is causing excessive paging then we should monitor the Process: Page Faults/sec counter for the SQL Server process instance. This will give an exact picture whether SQL Server is causing this paging issue or not.

Process: Working Set

This counter shows the amount of memory a process can use. This counter value shows whether you have set optimum value in min server memory and max server memory configuration or not. If this value shows constantly below min server memory and max server memory then you have configured too much memory for your SQL Server.

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

This is very important counter and this counter shows the number of percentage that has been satisfied using data cache. Suppose the value of buffer cache hit ratio for your server is 94 it means 94% of total requests for data have been processed using data cache.

The ideal value for this counter is more than 90. Higher the value better the memory health.

SQL Server: Buffer Manager: Page Life Expectancy

Page Life Expectancy is very important counter to measure memory pressure for your system. THis counter indicates the average number of seconds a data page to remain in cache. Ideally, we have read multiple blogs to consider 300 or more as acceptable value but this value varies depending on your system configuration.

The ideal value is more than 300 but always compare this value with your system configuration. Higher the better concept is also applying here.

SQL Server: Buffer Manager: Free List Stalls/sec

This counter also shows a sign of memory pressure or insufficient memory on your server. This displays the number of requests per second where data requests stall because there are no buffers available. Any value greater than two indicates that SQL Server needs more memory.

SQL Server: Buffer Manager: Lazy Writes/sec

This counter tells about total number of Lazy writer performed in a second.  It means total number of times Lazy Writer process moves dirty pages from the buffer to disk. A lower number is better than a higher number. If value of this counter shows higher value continuously more than 20, then we need to add more memory to the system or we should think about optimizing memory intensive operations.

SQL Server: Buffer Manager: Checkpoint Pages/sec

This counter monitors the number of dirty pages per second, which are flushed to disk when SQL Server invokes the checkpoint process. High values for this counter may indicate memory pressure or insufficient memory.

SQL Server: Memory Manager: Memory Grants Pending

This counter shows the number of processes waiting for memory grant per second. Any value higher than zero indicates a lack of memory. We can also get this information by using a DMV sys.dm_exec_query_memory_grants. Those processes who are waiting to be granted the required memory will show you waiting with RESOURCE_SEMAPHORE wait type. I have explained about resource semaphore wait type in below attached article.

• Fix RESOURCE_SEMAPHORE Wait Type in SQL Server

Here, I have described top 10 performance counters to identify SQL Server memory pressure on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 833: SQL Server has encountered 32 occurrences of I/O requests taking longer than 15 seconds to complete.
• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding ASYNC_IO_COMPLETION Wait Type

The post Top 10 Performance Counters to Identify SQL Server Memory Pressure appeared first on Techyaz.com.

Error 701, Severity: 17, State: 193.
There is insufficient system memory to run this query.

Or

Error 802, Severity: 17, State: 20
There is insufficient memory available in the buffer pool.

Error 701 or Error 802: Root Cause

If SQL Server is running out of memory and has no more memory available to allocate to its transactions then it will generate SQL Server memory error 701 or error 802. SQL Server Memory pressure or insufficient memory issue can be raised due to huge data load or other memory intensive operations.

We should check DBCC MEMORYSTATUS output to get latest snapshot of current memory status of the SQL Server. This command is very useful in troubleshooting memory issues in SQL Server. You might even have failed to run this DBCC command because system does not have enough memory. You need to reduce some memory pressure by stopping or killing some processes and then try to run this command to gather in depth information about SQL Server memory state.

The transaction that failed due to memory pressure and generates error 701 or error 802 might be or might not be the cause of this error. We should analyze the trends to reach on any conclusion.

Solution

There are mainly two reasons behind getting SQL Server memory issues for most of the SQL Server systems. Either your server has less memory to handle the current day to day workload or you are running some of the adhoc transactions that will require more memory for their execution like huge bulk data load, complex reports etc. If your SQL Server is running with insufficient memory during day to day activities then you should seriously evaluate the total workload and propose optimum memory size that can handle your current workload.

If you are planning to run any heavy ad hoc transaction then you should temporary increase the memory that can handle the transaction smoothly or you should run such transactions on a server that are built to handle such loads. You should also consider to reduce the batch size that is optimum for your system.

SQL Server is memory intensive application. We need to plan memory sizing for a server after proper evaluation of server state and overall load that will run on that SQL Server instance. But if you are facing memory issue on one of your SQL Server then first we need to troubleshoot it and find the root cause of this memory pressure. Here I am giving you step by step method to find the actual culprit that are causing the memory issue and possible solutions that can reduce some memory overheads.

First Make sure your SQL Server instance is running on dedicated server and not with other applications. If other applications are also using your database server then make sure they are not eating most of the memory. And, If most of the system memory is taken by other applications then you need to seriously think about migrating those application from this database server.

If you cannot migrate these applications to another server then workaround for such issues are to allocate the maximum memory value to your SQL Server instance. You can do it either by using sp_configure or using GUI. Read attached article to change max memory value for your SQL Server instance.

• Understanding SQL Server Memory Allocation and Role of MIN/MAX Server Memory Configuration

Next thing you should check is the server memory configuration. Check below SQL Server memory configuration parameters:

• max server memory
• min server memory
• min memory per query

Notice any unusual settings and fix them as necessary. All above three options have been covered in detain in above attached article.

Now, check the workload in terms of number of concurrent sessions, currently executing queries along with their memory grants. You should also focus on SQL Server transactions that are seeking huge memory values. Look at the transactions and gather a report for high memory intensive operations. Evaluate them and if possible optimize them so that they can take minimum memory.

• Understanding Memory Wait type Resource_SEMAPHORE and how to fix it?

You can also run below DBCC commands to free several SQL Server memory caches. This will also help you and make some relief for your current running transactions but in longer run it will not help if your system will need more memory to proceed the transactions.

• DBCC FREESYSTEMCACHE
• DBCC FREESESSIONCACHE
• DBCC FREEPROCCACHE

Another effective way to look in to memory status is by getting the output of DBCC MEMORYSTATUS command. You would get a good starting point to look in to culprit memory consumers.

We can also start collecting performance monitor counters for memory. Perfmon counters like the value of SQL Server: Buffer Manager\Buffer Cache Hit Ratio, SQL Server: Memory Manager and Page Life Expectancy will be very helpful in identifying memory pressure on SQL Server system. Analyze the trend for these counters and then decide whether issue is coming during some specific operations or system is continuously facing memory pressure.

Based on these analyses you can choose to either increase the system memory, increase the SQL Server memory allocation or reschedule some of the memory specific transactions to the off hours when load is minimum on the system. You can also reduce the batch size of the transaction to reduce the memory pressure. This will be certainly helpful in troubleshooting memory issues.

It is not necessary that your transactions are poorly designed always that is why SQL Server is taking lot of memory to process it. Sometimes even our systems on which SQL Server runs might have problem that end up with memory pressure. So you should consider all these points while fixing any performance issue.
I hope you like this article. Please follow us on our Facebook page and Twitter handle to get latest updates.

Read More:

• 4 Usages of DBCC SQLPERF in SQL Server
• Manage Transaction Log File during Bulk Data Load
• How to Improve Bulk Data Load Performance?
• Overview of SQL Server Performance Tuning
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

The post SQL Server Error 701: There is Insufficient System Memory to Run this Query appeared first on Techyaz.com.

Server Level Configuration Check

To deal with SQL Server Performance Tuning, it is required to review and check all the server level configuration settings of the SQL Server on periodic basis. Some of these settings may vary depending on the workload and criticality of the application. You can have a look at all the configurational settings by running below command.

sp_configure'show advanced options',1
GO
RECONFIGURE
GO
sp_configure

Index Analysis

The role of indexes in SQL Server performance tuning is very crucial. To achieve better Server performance during data retrieval, it is important to create useful indexes. Proper indexing helps in executing tasks with minimal disk Input\ Output operations and fewer system resources.

To implement this approach, it is important to understand how indexes are used by ‘Query Processor’ for executing quick data search operation. Even excessive indexes or poor indexes can harm your database performance so better to analyze the data and query before creating any indexes on your table. Read below articles to understand more on SQL Server Indexes.

• Understanding SQL Server Indexes and difference between Clustered and Nonclustered Indexes

SQL Wait Stat Analysis

“Wait Stat Analysis” is an alternate way to identify the symptoms that cause impact on the Server performance. SQL Server constantly keeps track of the reasons for which execution tasks wait or gets delayed; so to detect the reason, one can refer to the Server logs. You can read more about SQL Server Wait types in below attached articles.

• Understanding SQL Server Wait Types and How to get wait type information?
• How to Reduce PREEMPTIVE_OS_WRITEFILEGATHER Wait type in SQL Server?
• Should We Clear Wait Stats Data from DMV sys.dm_os_wait_stats?
• Understanding Resource_Semaphore wait type
• How to Fix BACKUPBUFFER Wait Type?

TempDB Space Review

Another way for optimizing Server performance tuning is through proper analysis of the usage as well as empty and occupied space statistics of TempDB database. Make sure that you TempDB database files are placed separately on different drive. If you place user database files and TempDB database files on same drive you might face high disk IO that will cause performance degradation.

Index Fragment\ Defragment Operation

This approach can better be implemented through analyzing the indexes to detect the extent of fragmentation and to identify which indexes and databases need to be defragmented for ensuring the smooth performance of these components. You can run SQL Server dashboard report to check which indexes are highly fragmented and need to rebuild or reorganize to improve the performance. Read below articles to understand Index rebuild and Reorganize operation in SQL Server.

• Difference between Index Rebuild and Index Reorganize Operation
• How to use Resumable Online Index Rebuild Operation?
• Disk and Performance Impact of running Online Index Rebuild Operation

Application/Program Logs

By referring to the “Windows Event Log” or “SQL Server Error Log”, the actual cause for the inappropriate functionality of either database or SQL Server can be detected. This could help in identifying and rectifying the existing errors that lead to files inaccessibility.

Backup & Recovery Parameters

For better performance tuning, analyze the backup and recovery settings to ensure if they are implemented appropriately. So that the backup files can be restored successfully in case of any unexpected circumstances.

Review Database Files

Review entire database files including primary, secondary as well as log files (MDF, NDF and LDF respectively) to analyze and detect the actual cause that is responsible for the inappropriate functionality of database. Make a practice to keep data and log files on separate drives to reduce the disk IO pressure. You can also analize which data or log file is having highest IO operating, this way you can plan to place that file in a faster disk.

• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters
• Understanding Data Files, Pages & Extents

Blocking and Deadlock Detection

Detecting Deadlocks is not a major task but often requires proper understanding and hands-on experience on the concept to implement it in an accurate manner. To implement the task, it is important to understand the locking mechanism along with its resolution. You can also identify if there is poor application design or coding by analyzing blocking and deadlock occurrence. If it occurs frequently, you can seriously think about optimizing your application or T-SQL coding. Identifying blocking issues will also help you in SQL Server performance tuning.

Hardware Components

Regular examination test over the various components of the SQL Server machine is required to ensure smooth functioning of all the elements as well as to prevent the adverse circumstances that can take place due to major hardware breakdown.

DBCC Implementation

It is very important to understand the nature of Database Console Commands as some of them are very critical and sometimes requires additional attention while execution. Some of these commands include DBCC SRHINKDATABASE, DBCC FREEPROCCACHE, DBCC SHRINKFILE, DBCC REINDEX and DBCC DROPCLEANBUFFER along with some stored procedures such as SP_UPDATESTATS.

• 4 Usages of DBCC SQLPERF in SQL Server

Conclusion

So, these are some of the major mechanisms of SQL Server Performance Tuning concept and when implemented with proper consideration and attention, help in optimizing the performance of the Server. By executing these actions on regular instance of time; the performance issues with the Server and the incorporated databases can be resolved.

The post Overview on SQL Server Performance Tuning appeared first on Techyaz.com.

Should We Clear Wait Stats Data in SQL Server?

We do not recommend to clear the wait stats data frequently because all valuable information about wait statistics will be vanished if you clear them. Always try to capture wait statistics information before clearing wait stats. This way you would have both before and after data. You can use sys.dm_os_wait_stats DMV to get the SQL Server wait statistics information.

Generally, we reset or clear wait stats information to capture actual data during a given time duration because this DMV does not show only current data. The DMV sys.dm_os_wait_stats accumulates all the counts and wait times since last time SQL Server started or its stats got cleared by dbcc sqlperf command.

Here I will show you how to clear the SQL Server wait statistics and the difference between data captured before clearing the wait stats and after clearing the wait stats.

Get Wait Statistics Data

The DMV sys.dm_os_wait_stats provides essential metrics for diagnosing SQL Server performance problems. This DMV captures all the details like waiting requests counts, signal waits and waiting time since last time SQL Server instance got started or last time you have cleared your wait stats using DBCC SQLPERF command. Run below command to get performance wait stats details of your SQL Server instance.

--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 the wait types on your SQL Server instance. You can also see the total wait time in milliseconds. This data is very important if you are dealing with any performance issue but as i discussed above details like total wait time, total waiting tasks counts are the accumulated/incremental values.

Reset or CLEAR Wait Statistics

Now you have captured wait stats information since your SQL Server was started. If you want to get only current waiting task counts or waiting time then you need to reset or clear wait statistics data using dbcc sqlperf command. 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 executed 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 information that is showing different than the one showing before clearing wait stats.

You can see how you will lose valuable information if you will clear your wait stats without capture its earlier data. This way you can also better analyze your database wait types, waiting tasks to reach on any conclusion to fix the issue.

Related Articles

• Understanding SQL Server Wait types
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters
• Understanding Resource_Semaphore wait type

Now you understand that we should not reset or clear wait stats frequently because wait stats data is very crucial to deal with any performance issue. You can reset or clear the wait stats but make sure to capture the data before clearing the wait stats. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Should We Clear Wait Statistics Data from DMV sys.dm_os_wait_stats in SQL Server? appeared first on Techyaz.com.

1. Excellent – You Disk Subsystem is responding perfectly for respective counter.
2. Good – You Disk Subsystem is responding fairly for respective counter and you can consider it good considering your workload and other resource utilization.
3. Poor – You Disk Subsystem is not responding well for respective counter and it requires your intervention to drill down more to understand the reason behind slowness.

If you want to read about CPU and Memory related performance counters then i would suggest you to go through with below attached articles.

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Top 10 Perfmon Counters to Identify SQL Server Memory Pressure

Below are the list of important perfmon disk counters that we will be discussing in this article.

• Average Disk Sec/Read
• Average Disk Sec/Write
• Average Disk Sec/Transfer
• Average Disk Queue Length
• Current Disk Queue Length
• Disk Read/Sec and Disk Write/Sec
• %Disk Time
• %Idle Time

Average Disk Sec/Read

Average Disk Sec/Read is important perfmon disk counter that shows the average time in seconds needed to read data from disk and better explain the disk latency. We can find these counters at the logical and physical disk object level. The value for this counter is generally the number of seconds it takes to do each read. The shorter the time needed to read or write data, the faster the system. If you constantly get this counter value more than 20ms then it means your disk is not performing well.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds (0.006 sec)
• Good, if the value of this counter is up to 15 milliseconds (0.015 sec)
• Poor, if the value is constantly more than 15 milliseconds (0.015 sec)

Average Disk Sec/Write

Average Disk Sec/Write is also an important counter that shows the average time in seconds needed to write data to disk. that can better explain the disk latency. This counter can be tracked at the logical and physical disk level. The value for this counter is generally the number of seconds it takes to do each read. The shorter the time needed to read or write data, the faster the system. If you constantly get this counter value more than 20ms then it means your disk is not performing well.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds
• Good, if the value of this counter is up to 15 milliseconds
• Poor, if the value is constantly more than 15 milliseconds.

Average Disk Sec/Transfer

Average Disk Sec/Transfer is a time that measures average latency for read or write operations. If the Average Disk Sec/Transfer value increases, this indicates that the I/O subsystem is not optimally keeping up with the I/O demand. This counter is available under Logical Disk and Physical Disk object. If you are keeping a watch on this counter make sure to have a look at above perfmon disk counters Average Disk Sec/ Read and Average Disk Sec/Write as well because Average Disk Sec/Transfer is the average of both read and write counters so you need to find out high value is due to read operation or write operation. Below are the values that will tell you whether your disk is performing excellent, good or it is performing slow and requires your intervention to improve its performance.

Your disk performance is:

• Excellent, if the value of this counter is less than 6 milliseconds
• Good, if the value of this counter is up to 15 milliseconds
• Poor, if the value is constantly more than 15 milliseconds.

Average Disk Queue Length

Average Disk Queue Length counter shows you the average number of read and write requests that were queued on the selected physical disk. If this value is exceeding its threshold frequently then we should also look at other perfmon disk counters Average Disk Read Queue Length and Average Disk Write Queue Length. This way you can diagnose whether Average Disk Queue Length is high due to high read or high write operation. The recommended value for this counter is less than 2 per individual disk so if you have multiple disks then your recommended value for Average disk queue length would be twice the no of disks.

Be careful when using thresholds of 2 with SQL Server and SANs.  This value can be much higher than 2 if you have multiple disks.  Let’s say you have 6 drives and Average disk queue length counter is showing around 12, then you should consider your Average disk queue length value 9/6 = 1.5 not 9.

Your disk performance is:

• Excellent, if the value of this counter is less than 1.5 per drive.
• Good, if the value of this counter is up to 2 per drive.
• Poor, if the value is constantly more than 2 per drive,

Current Disk Queue Length

Current Disk Queue Length is the number of disk requests that are currently waiting as well as requests currently being serviced. The difference between average disk queue length and current queue length is CDQL tells current load whereas ADQL tells load during a given time frame. The Current Disk Queue Length metric in Windows Performance Monitor is available for both physical and logical disk. The Current Disk Queue Length value should be less than 2 per disk.

Your disk performance is:

• Excellent, if the value of this counter is less than 1.5 per drive.
• Good, if the value of this counter is up to 2 per drive.
• Poor, if the value is constantly more than 2 per drive.

Disk Read/Sec and Disk Write/Sec

Disk Reads/Sec and Disk Writes/Sec show you the number of read and write operations happening per second on the disk. If you want to set the benchmark for disk capacity then you can determine it by gradually increasing the load on the system.

Your disk performance is:

• Excellent, if the value of this counter is less than 75% of total disk capacity.
• Good, if the value of this counter is up to 85% of total disk capacity.
• Poor, if the value is constantly more than 85% of total disk capacity.

%Disk Time

%Disk Time counter tells how busy the disk is in performing read and write operations. You can see its values normal even your disk has serious disk performance issue. You should compare its value with current/average disk queue length before reaching on any conclusion about disk issue.

Your disk performance is:

• Excellent, if the value of this counter is less than 75% of total disk capacity.
• Good, if the value of this counter is up to 85% of total disk capacity.
• Poor, if the value is constantly more than 85% of total disk capacity.

%Idle Time

%Idle Time measures the percentage of time the disk was idle during the sample interval. The disk is idle when it’s not processing read and write requests. If you are constantly getting its value less than 40% then you can either move some applications from your machine to another machine if you are running other applications as well apart from SQL Server or You can change the current disk system with a faster disk system.

Your disk performance is:

• Excellent, if the value of this counter is greater than 60% of total disk capacity.
• Good, if the value of this counter is greater than 50% of total disk capacity.
• Poor, if the value is constantly less than 40% of total disk capacity.

Related Articles:

• Disk and Performance Impact of running Online Index Rebuild Operation
• How to fix IO error: SQL Server has encountered N occurrence(s) of I/O requests taking longer than 15 seconds to complete.
• Improving Bulk Data Load Performance in SQL Server
• Understanding ASYNC_IO_COMPLETION Wait Type

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

The post Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters appeared first on Techyaz.com.

SQL Server has encountered 32 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [E:\MSSQL\Data\database_file.mdf] in database [Database_Name] (%d). The OS file handle is 0x000000F543. The offset of the latest long I/O is: 0x000000004h583.

This message indicates that SQL Server has issued a read or write request from disk, and the I/O requests taking longer than 15 seconds to return. Microsoft SQL Server reports Event Id 833 to the event log, and above text in the ERRORLOG file along with other symptoms like high wait times for PAGEIOLATCH waits or other disk IO related wait types in SQL Server.

Why we get this issue/warning?

SQL Server database is designed to perform intensive disk I/O operations. An I/O operation may be either a read or a write operation and the standard disk speed to perform these operations is around 10 milliseconds or less. If any of the read or write operation takes more time to perform their activity and generally disk speed reaches or exceeds 15 seconds of time, then database engine reports event id 833 along with above log information in error log file.

If you receive such messages, it does not mean problems with SQL Server. They are reported to let DBAs and system administrator know about poor storage performance and help them to investigate why the I/O request took so long. Long I/Os often indicate a SQL Server workload that is too intense for the disk subsystem. Disk Subsystems perform poorly/slowly because of either stuck or stalled IO operations. Before going ahead let’s first understand about stuck and stalled IO operation.

Stuck I/O

Stuck I/O is defined as an I/O request that does not finish.  To resolve a stuck I/O condition, you must usually restart the computer or perform a similar action. A stuck I/O condition typically indicates one of the following:

• Faulty hardware
• A bug in an I/O path component

Stalled I/O

Stalled I/O is defined as an I/O request that does finish or that takes excessive time to finish. Stalled I/O behavior typically occurs because of one of the following reasons:

• The hardware configuration
• The firmware settings

Below is the list of items that can cause stuck or stalled I/O operations on disk subsystem that can adversely affect SQL Server performance.

• Faulty hardware
• Incorrectly configured hardware
• Firmware settings
• Filter drivers
• Compression
• Bugs
• All transactions are in one drive like (backup, live database updates)
• Blocking
• Latch contentions
• Missing Indexes in databases

Resolution

Disk I/O problems are one of the most difficult problems to diagnose and to find the root cause. There might be multiple reasons due to which your disk subsystems perform slow. First step towards fixing such issue is to examining the event logs for any hardware related error messages and then proceed towards fix accordingly. Follow below steps to reduce the IO overheads on your database server if I/O requests taking longer than 15 seconds or perfoming slow.

1. Check & update all missing device drivers and firmware with the latest updates.

2. Analyze memory pressure and CPU usages trends as well because if you will run with CPU or memory pressure, there might be possibility slow disk performance.

3. Monitor disk I/O performance counters either using Performance Monitor or using DMVs to examine your disk subsystem workload. Read attached article to get the optimum values for all given counters. It’s highly recommended to monitor these counters for a while, and then compare it to your disk baselines value that you had captured during stress testing or load testing exercise.

• Average Disk Sec/Transfer
• Average Disk Sec/Read
• Average Disk Sec/Write
• Average Disk Queue Length
• Current Disk Queue Length
• Disk Read/Sec
• Disk Write/Sec
• %Disk Time

4. Microsoft suggests being careful when you use the performance counters because SQL Server takes full advantage of asynchronous I/O capabilities that push the disk queue lengths heavily. Therefore, longer disk queue lengths alone do not indicate a problem. So, compare every counter with their baseline and then analyze the trend.

5. Monitor SQL Server Wait Types, If the disk is slowing all the times then you will get wait types PAGEIOLATCH, WRITELOG or LOGBUFFER with high wait time.

6. Exclude SQL Server Data and Log files from antivirus software scans. If your database files are configured to be scanned by antivirus software then this will have slowed your disk performance.

7. If you are getting this issue on a specific time then I would suggest checking the conflict between your SQL Server Agent Jobs? There might be some data load/Disk IO intensive query or database maintenance activities will be running parallelly at the same time. Change the Agent jobs schedule time carefully so that they should not conflict to each other.

8. Don’t place database files and backups on single drive. Always place data file, log files and tempdb files on separate drives to reduce disk IO overhead. Also, it is highly recommended to run backups on separate drive because if you run backups on data drives then this can reduce disk performance.

9. Check your database files property for which you are getting this error. The size of database files should not be limited to fixed size with auto growth disabled. Enabling the auto growth of all the data files with appropriate value can fix this issue if you have put limits of database files growth. Read the attached article to understand the best value for database file autogrowth.

10. Disk I/O can perform poorly if there is no proper indexing on your tables. You can use Index Turning Wizard to resolve I/O pressure on the system. You can find missing indexes from most used or accessed tables and create appropriate indexes to reduce query time and resources overhead.

Disable this Error to Log using Trace flag 830

Microsoft has given us an option to disable stalled or stuck I/O detection by using trace flag 830, although we do not recommend that you do this.

To disable detection when SQL Server starts, use the -T830 startup parameter to disable detection every time that SQL Server is started. To disable detection for an instance of SQL Server that is currently running, use the following statement:

dbcc traceoff(830, -1)

This setting is effective only for the life of the SQL Server process.

Related Articles:

• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters
• How to Improve Bulk Data Load Performance?
• What is ASYNC_IO_COMPLETION wait type?
• Understanding BACKUPBUFFER wait type

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

The post Fix Event ID 833: SQL Server has encountered 32 occurrence(s) of I/O requests taking longer than 15 seconds to complete. 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.

Database Auto Shrink or Manual shrink operation runs at database file level. It is not recommended to shrink your data files except in case of the few exceptions like data deletion.  You can run shrink operation if you have deleted some portion of the data to reclaim that space. As this shrink operation can cause index fragmentation so make sure to rebuild your fragmented indexes post performing the shrink operation. Shrinking the log file may be necessary in some cases if your log file is full and need to clear some space. However, shrinking the log file should not be part of any regular maintenance activity and should be manually done whenever it will require.

It is always recommended to never run shrink operation as part of maintenance activity even you should avoid running shrink operation manually if you are doing it. If it is needed to run shrink operation, make sure rebuild your indexes. You should always turn off SQL Server Auto Shrink  for all databases to avoid any future performance issue on your database. By default, SQL Server keeps auto shrink turn off on SQL Server instances.

There will be a bad impact on performance if you turn on database auto shrink and autogrowth settings together for any database. Most of the database files have some value to autogrowth setting enabled for the databases or we set the database size to the optimum value keeping some room in the data files to grow and avoid frequent auto growth events. If we will enable SQL Server auto shrink property for such databases, it will shrink the data files and reclaim the free space that we have kept intentionally to avoid autogrow events. In that case, both operations will be performed frequently auto growth and then SQL auto shrink that ultimately lead to the system level fragmentation which causes severe performance issue as well.

So in short, Autoshrink should not be turned on for any databases. This is bad for several reasons that I have concluded in below points.

1. Database Auto Shrink or Manual Shrink causes index fragmentation that will reduce the database performance.
2. Shrink operation takes lot of IO and CPU resources. If the server is already pushing the limits of the IO subsystem, running shrink may push it over, causing long disk queue lengths and possibly IO timeouts.
3. Repeatedly shrinking and growing the data files will cause file-system level fragmentation, which can slow down performance. It wastes a huge amount of resources, basically running the shrink algorithm for no reason.
4. If you combine the autogrow and autoshrink options, you might create unnecessary overhead. Make sure that the thresholds that trigger the grow and shrink operations will not cause frequent up and down size changes. So Autogrow and Autoshrink together can seriously reduce your system performance.
5. SQL Server Auto Shrink and autogrow settings must be carefully evaluated by a trained Database Administrator (DBA); they must not be left unmanaged.

Autoshrink doesn’t work like if the threshold is hit, auto shrink SQL Server operation will start to reclaim space. It uses round robin method to shrink databases if you have multiple databases are set to use auto shrink. SQL Server shrinks a database if needed. Then, it waits several minutes before checking the next database that is configured for auto shrink so your database will need to wait for his turn to execute auto shrink operation.

How to Enable or Disable Auto Shrink in SQL Server?

We can turn on or off database auto shrink SQL Server configuration using GUI and T-SQL both ways. Both are easiest method. Let us first start with GUI method.

Right click on your database for which you want to enable or disable auto shrink and choose Properties. You will get below Database Properties window. Click on Options from left side pane of this window. You can see Auto Shrink option is showing in right side pane. If you want to turn it on, click on drop down of this option and select True.

Below is the T-SQL code to enable or disable the Auto_Shrink option for any database. Change the database name with your database name and execute it.

--Set Auto Shrink ON or True
ALTER DATABASE TechYaz SET AUTO_SHRINK ON
--Set Auto Shrink OFF or False
ALTER DATABASE TechYaz SET AUTO_SHRINK OFF

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

Reference : AUTO_SHRINK database option in SQL Server

Read More:

• Should We Shrink SQL Server Databases or Files?
• Understanding AutoGrowth settings and its impact on Performance
• SQL Server Backups for AlwaysOn Availability Databases
• What is Instant File Initialization and how to enable it?

The post Why Should You Always Turn Off Database Auto Shrink Property? appeared first on Techyaz.com.

Set Optimum Database Size

Your database should have enough size that it never grows and if it grows make sure that Instant file initialization should be enabled on that SQL Server Instance. Autogrowth is an option that should be used to avoid unexpected scenarios of space issues in database files. You should plan your database size in a way that can minimize the use of autogrowth setting. You should figure out how big your database will be over the time and set the database size to that value. Analyze database size on every few months to adjust the size if it requires to increase. This way you can minimize autogrow events to be performed on your database files.

Resize Database Autogrowth in SQL Server

Auto growth events are expensive operations that slow down the performance of your database because whenever an auto-growth event is performed, SQL Server holds up database processing. This equates to slower response time for those SQL commands that are being processing against the database that is growing.

If you run a large transaction that requires the log to grow, other transactions that require a write to the transaction log will also have to wait until the autogrow operation completes. If your database is performing frequent autogrow events, then you have a good scope of performance improvement by proper resizing the database autogrowth settings that will reduce the number of autogrow events to be occurred.

Another negative side of autogrowth is the disk fragmentation. The more autogrow events you have the more physical fragmentation you will have. When your database is physically fragmented, it will take more time for SQL Server to read that databases. To avoid the issues associated with auto-growth events you need to minimize the number of its occurrence.

Change Default Autogrowth Settings

As per my experience, never leave your database files with the default autogrowth settings. The autogrowth default value for data files is 1MB and log files is 10% of total size of the log file. These autogrowth values are inherited from model database. You can change the autogrowth size of each database file of model database that will apply on all databases we create on this SQL Server Instance.

For example: You can change autogrow settings from default value that is 1MB to one-eighth of the database file size. This will again reduce the total number of autogrow events of the database. Make sure that Instant file initialization should be enabled on that SQL Server Instance.

Monitoring

If you know your database growth pattern, then set autogrowth per that growth. If you don’t have any idea about your future database growth, then you should proactively monitor database file sizes and their autogrowth events for a week or month and then set it per the growth pattern. We should also proactively monitor database growth histories for all databases to avoid any future outages due to disk or database file full.

You can analyze database disk usage dashboard report to get the number of times autogrowth event has occurred for your database files. I have explained this later in this article.

Best Practices for Database Autogrowth in SQL Server

You can improve the database performance and can manage the disk space utilization by focusing on below four points. This will also reduce the number of Autogrowth events to be occurred in the database files.

1. Analyze your database growth pattern and set optimum size of database with the analyzed growth settings. Your database should have enough size that it never grows and if it grows make sure that Instant file initialization should be enabled on that SQL Server Instance.  This will drastically reduce the SQL Server Autogrowth events in day to day life.
2. Proactively monitor database file sizes and their autogrowth events. This helps you to analyze the growth pattern of database files and avoid fragmentation.
3. Consider defragmenting your database file system if you have lot of auto-growth events occurred on your databases.
4. Never leave your database autogrowth with default values, change it as per growth pattern that you analyzed over time.
5. Avoid using autogrowth in percentage, rather give a specific amount of size in MB/GB. Microsoft suggests to set your autogrow setting to about one-eighth the size of the file and test it before deploying on PROD.
6. Turn on the <MAXSIZE> setting for each file to prevent any one file from growing to a point where it uses up all available disk space.
7. The growth increment of your transaction log must be large enough to stay ahead of the needs of your transaction units. Even with autogrow turned on, you can receive a message that the transaction log is full, if it cannot grow fast enough to satisfy the needs of your query.

Change Database Autogrowth in SQL Server?

You can run below command to change the autogrowth value of any database file.

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

You can also change the autogrowth settings using GUI in SSMS. Launch the database property window. Click on files tab from left side pane and then on the three dots (…) that are showing besides every database file. You can see this window in below screenshot.

How to View Total Number of Autogrow Events Occurred on a Database?

You can find the number of autogrowth events occurred for your database by running “Disk Usage” dashboard report. Right click on your database for which you want to see total number of autogrowth events. Choose “Reports” and then select “Disk Usage” as shown in below image.

You will get below dashboard report for disk usage. You can see all details regarding space usage. Auto growth events are also captured in the same report. I have highlighted those entries in below screenshot.

Once you expend the plus + sign, you can see total number of autogrow events that have been occurred for your database. You can count the total numbers and total space as well. Based on this analysis you can alter your autogrowth settings to the optimum value that will reduce that much numbers as it is showing here.

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

Reference: MSDN Article based on Autogrowth

The post Understanding Database Autogrowth in SQL Server appeared first on Techyaz.com.

Related Articles:

• Understanding SQL Server Wait Types
• How to deal with Resource Semaphore Wait type?
• What is BACKUPBUFFER Wait type?
• How to Reduce SQL Server Wait type PREEMPTIVE_OS_WRITEFILEGATHER?
• How to Improve SQL Server Bulk Data Load Performance?

ASYNC_IO_COMPLETION wait type occurs when a task is waiting for asynchronous I/Os to finish.  This wait type is normally seen with few other wait types like BACKUPBUFFER, BACKUPIO etc. This is clear indication of DISK IO issue. You can also get the Average disk queue length or current disk queue length value at the same time when you are getting this wait type. Compare both counters and if these counters have high value then you should look into your storage subsystem. Identify disk bottlenecks, by using Perfmon Counters, Profiler, sys.dm_io_virtual_file_stats and SHOWPLAN.

Any of the following will reduce this wait type occurrence:

1. Add additional IO bandwidth.
2. Balancing IO across other drives. If you are running your backups on same drive in which you have placed your database files. Make sure to keep separate drive for data, log and backups.
3. Reducing IO with appropriate indexing. This can cause major performance issue if you don’t have proper indexes.
4. Check for bad query plans that are consuming most of resources.
5. Check memory pressure if your server has enough memory to run resource extensive operations.

We can also correlate this wait type between Memory pressure and Disk IO subsystem issues.

If you like this tip, you can follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding ASYNC_IO_COMPLETION Wait type in SQL Server appeared first on Techyaz.com.

RESOURCE_SEMAPHORE waits occurs when a query memory request cannot be granted immediately due to other concurrent queries. High waits and wait times may indicate excessive number of concurrent queries, or excessive memory request amounts.

High waits on RESOURCE_SEMAPHORE usually result in poor response times for all database users, and need to be addressed.

It is also useful to correlate high waits on RESOURCE_SEMAPHORE with the Memory Grants Pending and Memory Grants Outstanding SQL Memory Manager performance counters. Higher values for these counters indicate a definite memory problem especially a non-zero value for Memory Grants Pending.

Resource Semaphore is a SQL Server internal mechanism that allows a query to reserve memory only if there is enough free memory available otherwise, a requesting query is forced to wait in queue. When resource semaphore receives new request, it first checks if any query is waiting or not. If any query is waiting in queue then the new request will also be added to the queue based on first come first serve allocation. All these requests in queue will show you waiting with RESOURCE_SEMAPHORE wait type. Once enough memory will be available then memory will be granted to the requests in an order they have been queued.

The root cause of this type of memory problem is when memory-intensive queries, such as those involving sorting and hashing, are queued and are unable to obtain the requested memory. The solution would be to tune the offending queries, or manage their workload so that they are executed at less busy times.

SQL Server has provided few DMVs to identify and fix such memory issues. You can have a look at DMV sys.dm_exec_query_resource_semaphore that will show the current status of resource semaphore . You can also see the output of DMV sys.dm_exec_query_memory_grants to display all queries that have memory granted and those who are waiting to be granted the required memory. All waiting queries would have null value in grant_time column in the output of DMV sys.dm_exec_query_memory_grants.

You can get the queries that are causing or eating most of the memory using above DMVs and from here you can look at the options of optimizing the memory intensive statements. You can also have a look at below article if your system is facing insufficient memory issue.

• SQL Server Error 701 and Error 802: There is Insufficient System Memory to Run this Query
• Understanding SQL Server Memory Allocation and Role of MIN/MAX Server Memory Configuration

I hope you like this article. Please drop your questions and feedbacks in below comment section. You can also follow our facebook page and Twitter handle to get latest updates.

Related Articles:

• Understanding SQL Server Wait Types
• How to Deal with ASYNC_IO_COMPLETION wait type?
• Understanding BACKUPBUFFER Wait type

The post How to Fix RESOURCE_SEMAPHORE Wait Type in SQL Server? appeared first on Techyaz.com.