Microsoft SQL Server Error 5009 While Adding Database File

I was working on a migration project where we had to load huge data in a SQL Server database on the target server. To optimize data load performance, we had decided to create database with the final size on the destination server. The final size of database post data import was around 800 GB. We made some configurational changes to reduce data import time. Extending database files size was one of the step to reduce data load time. If you want to learn how to speed up data import then I would suggest reading attached article.

We decided to add one more log file on separate drive considering extensive log growth during data load. While adding the log file, we got error 5009. Full error details are given below.

One or more files listed in the statement could not be found or could not be initialized. CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file ‘T:\Techyaz_log3.ldf’.(Microsoft SQL Server, Error: 5009)

As error suggests, I don’t had enough permission to create this file on given location where i was trying to create the log file. There are two solutions to fix this issue. First solution is to set the Operating system permission on the mentioned .ldf file to full permission for your login account and SQL Server service account. While second solution is to change the location to the path where you have enough permission to create or add database files. Any of these two solutions will fix your problem. Let’s go to another version of Microsoft SQL Server Error 5009 while extending the log file.

Microsoft SQL Server Error 5009 While Extending the Size of Log File

When i changed the location to create this ldf file to a directory T:\Data\Techyaz_log3.ldf this time log file was created but we get same issue again while extending the size of this log file. Next, I was assigning bigger value to each data and log files. We had successfully increased data files size in few minutes because we had already enabled Instant File Initialization to skip zeros process on storage but we faced Microsoft SQL Server error 5009 again while increasing the size of log files. i was extending  log file with bigger values. As we know Instant File Initialization does not work for transaction log files so extending the size of log files was taking lot of time. This time access denied issue was disappeared but error 5009 issue was there only. Error description for this error is given below.

Msg 5009, Level 16, State 9, Line 1
One or more files listed in the statement could not be found or could not be initialized.

To fix this error, we had passed small value to extend the file size. Earlier we were trying to increase the log file in a slot of 40 GB in single go. It was taking time to finish but most of time log file size got extended with 40GB but sometimes we had received above Microsoft SQL Server error 5009. When we got this error, we extend the size of log file to 10Gb in place of 40GB that we were doing previously. Reducing the value while extending the log file has fixed this issue and log files had been extended to its future size successfully.

Microsoft SQL Server Error 5009 While Removing Database File

Some of the blogs have suggested that they got SQL Server error 5009 while removing a logical file in SQL Server but surprisingly I got this error while creating or increasing the size of log file. So if you are getting this error while removing any database file then you can keep reading this article to solve this issue.

Whenever we add any database file then its entry got captured in system catalog files, if you are trying to delete any database file then there might be possibility that logical name of the file that you try to remove is not unique in the system catalog tables. For example, this issue occurs if the file existed in the database earlier, and then the file was removed. When you remove the file, it will try to drop earlier file that has been removed but its metadata is not cleaned and appear like ghost file.

You should follow below steps to fix this issue.

• Create a new logical file with different name and the same data type. For example, If your file;s logical name is Techyaz_Logical_Name then create this new file with “Techyaz_Logical_Name_New”. Run below command to create this file.

ALTER DATABASE [Techyaz] 
ADD FILE ( NAME = N'Techyaz_Logical_Name_New', FILENAME = N'T:\DATA\Techyaz_file4.ndf', SIZE = 10MB, MAXSIZE = 100MB)

• Now we will remove the logical file that we have created in step 1, as in the following example:

ALTER DATABASE [Techyaz] REMOVE FILE [Techyaz_Logical_Name_New]

• Run a transaction log backup of the database.
• Now go ahead and remove the logical file that were trying to remove earlier and your received Microsoft SQL Server Error 5009.

Here, I have described multiple possibilities and fixes for Microsoft SQL Server Error 5009. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Manage Transaction Log File during Data Load
• How to get total no of virtual log files in a transaction log file
• Fix Error 3023: Shrink failed for Log file
• Understanding SQL Server Transaction Log Architecture
• Fix SQL Server Error 1105: Could Not Allocate Space for Object in Database because the Filegroup is Full
• Fix SQl Server Error 5144 and 5145 for long and failed Autogrow of data and log file

The post SQL Server Error 5009: One or more files listed in the statement could not be found or could not be initialized 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.

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.

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.