Shrink failed for LogFile ‘Logfile_Name”.
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed. (Microsoft SQL Server, Error: 3023)

Here is the screenshot of this error:

We get this error when there is a conflict between backup operation and Shrink operation. SQL Server are designed to follow some rules during Backup and Shrink operations. These are given below:

1. We can run only one database backup at a time. When a full database backup occurs, differential or incremental backups cannot occur at the same time.
2. Only one log backup can happen at a time. A log backup is allowed when a full database backup is occurring.
3. You cannot add or drop files to a database while a backup is occurring.
4. You cannot shrink files while database backups are happening.
5. There are limited recovery model changes allowed while backups are occurring.

When any of these conflicting operations are performed, the commands will be receiving the SQL Server error 3023, SQL Server error 3013 and SQL Server error 3041 messages.

You might also get below error when you perform another database backup if backup is already running for your database.

Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Or if you try to run a differential backup for a database for which full backup is already running, you will get below error code:

Backup Error: 3041, Severity: 16, State: 1.
BACKUP failed to complete the command BACKUP DATABASE MyDatabase WITH DIFFERENTIAL. Check the backup application log for detailed messages.

Solution to fix such issues is to examine the schedules of the various database maintenance activities, and then adjust the schedules so that these operations or commands do not conflict with each other.

Make sure to not run any operation that will conflict with each other. If you get such errors check your SQL Server Agent jobs and wait till that job will be completed. In my case, database backup was running while I was trying to shrink a log file. I did wait for some time and then tried again to shrink that file and this time SQL Server allowed me to run this shrink operation.

Here, i have explained how to fix Microsoft SQL Server error 3023,  error 3013 and error 3041. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Fix SQL Server Error 3023: Shrink failed for LogFile “Log File Name” 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.