Compacting/Shrinking a Database [/Compact]

There are several factors which contribute to the physical disk space a SQL Server database uses. Just to name a few:

Over time as records are added, deleted and updated, SQL is constantly growing and shrinking tables as well as generating temporary data structures to perform query manipulations. In order to accommodate the disk storage needs, SQL Server will increase the size of the database (usually by 10%) as needed so the database file size isn’t constantly changing. While this is ideal for performance, it can cause a disconnect with the storage space used because if, for example, you add a very large number of records which causes the database to grow and subsequently delete these records, SQL Server will not automatically reclaim this disk space. If you are using Full Recovery Mode on your databases the transactional log file (LDF) can grow quite large, especially on databases with a high volume of updates.

Compacting (or shrinking) the database will reclaim unused disk space. For small databases (200 MB or less) this usually will not be very much, but for large databases (1 GB or more) the reclaimed space may be significant.

Reindexing a Database [/Reindex]

Much like constantly creating, editing and deleting files can lead to disk fragmentation, inserting, updating and deleting records in a database can lead to table fragmentation. The practical results are the same in that read and write operations suffer a performance hit. While not a perfect analogy, reindexing the tables in a database essentially defragments them. In some cases, this can significantly increase the speed of data retrieval.

Due to the way SQL Server works, tables must be reindexed individually. For databases with a large number of tables this can be real pain to do manually, but our script hits every table in the respective database and rebuilds all the indexes.

Verifying Integrity [/Verify]

In order for a database to remain both functional and produce accurate results, there are numerous integrity items which must be in place. Thankfully, physical and/or logical integrity problems are not very common, but it is good practice to occasionally run the integrity verification process on your databases and review the results.

When the verify process is run through our script only errors are reported, so no news is good news.

Using the Script

The SQLMaint batch script is compatible with SQL 2005 and higher and must be run on a machine which has the SQLCMD tool installed (installed as part of the SQL Server installation). It is recommended you drop this script into a location set in your Windows PATH variable (i.e. C:Windows) so it can easily be called like any other application from the command line.

To view the help information, simply enter:

Examples

To run a compact and then a verify on the database “MyDB” using a trusted connection:

To run a reindex and then compact on “MyDB” on the named instance “Special” using the “sa” user with password “123456”:

Using from Inside of a Batch Script

While the SQLMaint batch script can be used like an application from the command line, when you are using it inside of another batch script, it must be preceded with the CALL keyword.

For example, this script runs all maintenance tasks on every non-system database on a default SQL Server installation using trusted authentication:

Download the SQLMaint Batch Script from SysadminGeek.com