Never set “AutoShrink = true”

In my last post, I wrote how you could detect fragmentation and how to fix it.  This post describes a feature that many people in the SQL Server Community hate. This is a single setting under “Database Properties” and might seem to be a pretty good idea for someone who don’t know all the facts, and will sooner or later result in decreased performance. This feature will in worst case totally fragment your database – tables, indexes and even files on the file system level.

You can run the following command to detect which databases that have turned on AutoShrink:

select name, is_auto_shrink_on 
from sys.databases
where is_auto_shrink_on = 1

You can run the following command to turn off AutoShrink for a database:

alter database [MyDB]
set auto_shrink off

The AutoShrink feature fires every 30 minutes by default and it severly fragement the database.  If you use AutoGrowth as well, this can totally fragment the entire database. AutoShrink starts at end of file and brute-force moving the pages as close to the beginning of the file as possible. These pages are physically getting out of order inside the database. If you have a “full rebuild index” the night before and AutoShrink could fragment the database again.


Measure and Monitoring Disk Performance

Performance on a SQL server much down to how the server handles disk I/O operations. Many enterprise SQL servers are using large SAN instead of local storage systems. When the price development in high-speed storage cards might reduce the concern for poor disk performance. Large datacenters are using these high performance storage cards when systems needs the best IO performance possible. There exists essentially four main storage types, and these are either traditional magnetic drives or SSD disks:

  • Internal drives
  • PCI-E: high speed storage cards
  • DAS: Direct-Attached Storage
  • SAN: Storage Area Networks

How can you measure disk performance? Has the vendor or IT-department given you disks with poor, good or excellent performance? These are questions database administrators have to ask when they receive hardware for a new server. When you a specifying new hardware, don’t just ask for storage based on space requirements. Ask the vendor or IT-department for performance requirements.  Performance parameters for different database types are often measured in the following:

  • Sequential performance in MB/second or GB/second
  • Random performance in input/output operations per second (IOPS)

Sequential performance is very important for data warehouses (DWH) database where large sequential reads are performed on the data files. Random I/O performance very important for databases for Online Transaction Processing (OLTP) where frequent writes to data files and log file. The also applies for Online Analytical Processing (OLAP) where many random reads from cube files.

  • CrystalDiskMark. Is used to measure sequential and randon read/write throughput.
  • SQLIO. Same as CrystalDiskMark, but this is a command line Microsoft tool that is used to determine the I/O capacity of a given configuration. You are able to simulate different block size of the IO request, duration of tests and number of outstanding requrests.

Have have done some testing locally on my laptop where I have a SSD as Disk 0. Here is a screenshot of the result from my SQLIO test. So the performance should be pretty good.