One thing we should always keep in mind that if we change database default path in SQL Server then it will not change or move the database file locations for your existing databases. If you want to move all existing databases or you want to change database files path to the new location then you need to manually do it for each database.

Once you will change default database file locations then all databases you will create on that SQL Server Instance will be created on new location. Suppose your existing SQL Server default database location is set in C drive and now you have decided to change it to D drive for data files and F drive for Log files then all databases you will create post this change will be created in these both drives. If you will mention any other specific drive during database creation then SQL Server uses that drive and not these database default locations. The SQL Server data file will be created in D drive and log file will be created in F drive but all the existing databases that were created earlier in C drive will not move to new SQL server database file location. If you want to move these databases or want to change database files location then you need to manually do it either by detach-attach method or by ALTER statement.

Change Database Default Locations in SQL Server

It’s very simple method to change default log file location or default data file location in SQL Server. Let’s start to change default database path in SQL Server.

• Launch SQL Server Management Studio and connect to your SQL Server Instance for which you must change default log file location or default data file location in SQL Server.
• Now right click at SQL Server Instance node and choose Properties option.
• You will get server properties window on your screen. Click at “Database Settings” from left side pane. You will get all server level details for SQL Server databases in right side pane. Look at the database default locations option given bottom of the right-side pane. Here you can see separate default location for data files, Log file and backup files.

• You can see database default locations for each file are showing in C drive. It means every database that will be created without mentioning their data or log file location will go to above given SQL Server database default locations.
• To change database default path, you need to browse current database default locations for each file to new the new location. Click at three dots showing next to data file or log file locations and then select the new path.
• Repeat same exercise for each file. To change default data file location, click at three dots next to data path and select new path here. Similarly, click at three dots next to log file location to change default log file location. If you want to change default backup file location then do the same for backup location as well.
• Click ak Ok button once you made changes for desired database file locations.
• Last step is to restart SQL Server services to apply this change and bring it into effect.

Once you will restart SQL Server services, your SQL Server default database location will be changed to the new path. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Get Total Number of Virtual Log Files in SQL Server Transaction Log File
• SQL Server Error 1105: Could Not Allocate Space for Object in Database because the filegroup is full
• How to Change SQL Server Instance Name?
• Why Should You Always Turn Off Database Auto Shrink Property?

The post How to Change Database Default Locations in SQL Server? appeared first on Techyaz.com.

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

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

Error 1101 – Root Cause

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

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

Solutions

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

Unrestrict or Increase Database File Size Limits

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

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

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

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

Space in Database Drives

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

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

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

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

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

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

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

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

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

Enable Autogrowth

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

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

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

Run below ALTER command to enable autogrowth for database file.

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

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

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

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

Read More:

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

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

There are two ways to perform shrink operation on your SQL Server databases.

Automatic Shrinking

Automatic Shrinking can be enabled by setting Auto_Shrink database property to ON. SQL Server database engine will automatically perform shrink database operation on your database whenever required. Unless we have a specific requirement, we should not set the AUTO_SHRINK database option to ON because it degrades your database performance. SQL Server shrink database files also increases IO overhead that leads to poor performance. Read below article where I have explained how this option degrades database performance and why we should not set Auto_Shrink database option to ON.

• Why Should You Always Turn Off Database Auto Shrink Property?

Manual Shrinking

We can use DBCC SHRINKDATABASE or DBCC SHRINKFILE statement to manually shrink database log file or data file within a database. Shrink database operation runs at file level. When you use DBCC SHRINKDATABASE, it also shrink the size of data or log files. We can stop the execution of DBCC SHRINKDATABASE and DBCC SHRINKFILE operations at any point in the process, and any completed work is retained.

One question most of the DBA ask that should we shrink database or should we shrink database log file or data file in SQL Server?The answer of this question is simple, we should not perform shrink operation regularly. Database Shrink operation is resource intensive operations because data pages are moved from the end of the file to unoccupied space closer to the front of the file. This process put pressure on system IO and CPU and also causes high fragmentation. You might also face some blocking issues during the shrink operation. That’s the reason it’s not recommended to shrink data file or log file on frequent or routine basis. SQL Server shrink database files should be avoided.

We should generally perform shrink operation if we truncate or drop table or tables from the database. If we remove or purge bigger chunk of data from your database then also we can perform shrink operation to reclaim the unused space to the disk. Always leave some space to the database to perform its routine operations. Most databases require some free space for regular day-to-day operations. Do Not Shrink such databases and their database files because databases will again allocate required space for their operation. Make sure to rebuild your indexes post database shrink operation if you need to perform it.

Also you should keep this in mind that we cannot shrink a database while the database is being backed up. Similarly, you cannot backup a database while a shrink operation on the database is in process. Here you have learnt about SQL Server shrink database files.
I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the best value for database file autogrowth?
• Fix SQL Server Error 5144 and 5145: Failed Data or Log file Autogrow Operation
• Fix Error 3023: Shrink failed for Log file

The post Understanding Database Shrink Operation and Why Should We Avoid It? 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.