SQL Server 2008 Tips

By

The Technocrats

Configure a Fail-Safe Operator for Notifications

When things go wrong with notification, operators do not get notified and problems might not be corrected in a timely manner. To
prevent this, you might want to designate a fail-safe operator. The fail-safe operator is notified in the following situations:

SQL Server Agent cannot access system tables in the msdb database, which is where operator definitions and notification
lists are stored.
All pager notifications to designated operators have failed, or the designated operators are off duty (as defined in the
pager schedule).

To configure a fail-safe operator:

1. Right-click the SQL Server Agent entry in SQL Server Management Studio, and then select Properties.
2. In the SQL Server Agent Properties dialog box, select the Alert System page.
3. Select Enable Fail-Safe Operator to define a fail-safe operator.
4. Use the Operator drop-down list to choose an operator to designate as the fail-safe operator. You can reassign the fail-safe duty
by selecting a different operator, or you can disable the feature by clearing Enable Fail-Safe Operator.
5. Use the Notify Using check boxes to determine how the fail-safe operator is notified.
6. Click OK.
Using the fail-safe operator on pager notification failure might seem strange, but it is a good way to ensure that alerts are handled
efficiently. E-mail and net send messages almost always reach their destination—but the people involved are not always watching
their mail or sitting at their computer to receive net send messages, so the fail-safe operator is a way to guarantee notification.

Configure Parallel Processing in SQL Server 2008

A lot of calculations are required to determine whether parallel processing should be used. Generally, SQL Server processes queries
in parallel in the following cases:

When the number of CPUs is greater than the number of active connections.
When the estimated cost for the serial execution of a query is higher than the query plan threshold (The estimated cost
refers to the elapsed time in seconds required to execute the query serially.)

Certain types of statements cannot be processed in parallel unless they contain clauses, however. For example, UPDATE, INSERT,
and DELETE are not normally processed in parallel even if the related query meets the criteria. But if the UPDATE or DELETE
statements contain a WHERE clause, or an INSERT statement contains a SELECT clause, WHERE and SELECT can be executed in
parallel. Changes are applied serially to the database in these cases.
To configure parallel processing, simply do the following:
1. In the Server Properties dialog box, go to the Advanced page.
2. By default, the Max Degree Of Parallelism setting has a value of 0, which means that the maximum number of processors used
for parallel processing is controlled automatically. Essentially, SQL Server uses the actual number of available processors,
depending on the workload. To limit the number of processors used for parallel processing to a set amount (up to the maximum
supported by SQL Server), change the Max Degree Of Parallelism setting to a value greater than 1. A value of 1 tells SQL Server
not to use parallel processing.
3. Large, complex queries usually can benefit from parallel execution. However, SQL Server performs parallel processing only when
the estimated number of seconds required to run a serial plan for the same query is higher than the value set in the cost threshold
for parallelism. Set the cost estimate threshold using the Cost Threshold For Parallelism box on the Advanced page of the Server
Properties dialog box. You can use any value from 0 through 32,767. On a single CPU, the cost threshold is ignored.
4. Click OK. These changes are applied immediately. You do not need to restart the server.

You can use the stored procedure sp_configure to configure parallel processing. The Transact-SQL commands are:
exec sp_configure "max degree of parallelism", <integer value>
exec sp_configure "cost threshold for parallelism", <integer value>
Configure SQL Server 2008 to Automatically Manage File
Size
With SQL Server 2008, you can manage database and log size either automatically or manually. You can use SQL Server
Management Studio or Transact-SQL to configure database or log size.
Using SQL Server Management Studio, you can configure automatic management of database and log size by performing the
following steps:
1. Start SQL Server Management Studio. In the Object Explorer view, connect to the appropriate server, and then work your way
down to the Databases folder.
2. Right-click the database you want to configure, and then select Properties from the shortcut menu.
3. Select Files from the Select A Page list in the Database Properties dialog box. Each data and log file associated with the database
is listed under Database Files. For each data and log file, do the following:

Click the button to the right of the file’s Autogrowth box to adjust the related settings. This will display the Change
Autogrowth For dialog box.
Set the file to grow using a percentage or an amount in megabytes, and then either restrict the maximum file growth to a
specific size or allow unrestricted file growth.
Click OK.

4. Optionally, access the Options page and set Auto Shrink to True. Auto Shrink compacts and shrinks the database periodically.
5. Click OK when you have finished. Your changes take effect immediately without restarting the server.

Recover Missing Data in SQL Server 2008 Using a Partial

Restore
If you suspect part of a database is missing or corrupted, you can perform a partial restore to a new location so that you can
recover the missing or corrupted data. To do this, use the PARTIAL option with the RESTORE DATABASE statement in Transact-SQL.
You can restore partial databases only at the filegroup level. The primary file and filegroup are always restored along with the files
that you specify and their corresponding filegroups. Files and filegroups that are not restored are marked as offline, and you cannot
access them.
To carry out the restore and recovery process:
1. Perform a partial database restore. Give the database a new name and location in the RESTORE DATABASE statement and use
MOVE/TO to move the original database source files to new locations. For example:

RESTORE DATABASE new_custdb_partial

FILEGROUP = 'Customers2'
FROM DISK='g:\cust.dmp'
WITH FILE=1,NORECOVERY,PARTIAL,
MOVE 'cust' TO 'g:\cu2.pri',
MOVE 'cust_log' TO 'g:\cu2.log',
MOVE 'cust_data_2' TO 'g:\cu2.dat2'
GO
2. Extract any needed data from the partial restore, and insert it into the database from which it was deleted.

Customize Memory Allocation for Queries in SQL Server

2008
By default, SQL Server 2008 allocates a minimum of 1024 KB of memory for query execution. This memory allocation is guaranteed
per user, and you can set it anywhere from 512 KB to 2 GB. If you increase the minimum query size, you can improve the
performance of queries that perform processor-intensive operations, such as sorting or hashing. If you set the value too high,
however, you can degrade the overall system performance. Because of this, you should adjust the minimum query size only when
you are having trouble executing queries quickly.
The default setting of 1024 KB of RAM works in most cases. However, you might want to consider changing this value if the server
operates in an extremely busy environment, with lots of simultaneous queries running in separate user connections, or in a
relatively slow environment, with few (but large or complex) queries. In this case, four factors should determine your decisi on to
adjust the minimum query size:

The total amount of free memory (when the system is idle and SQL Server is running)
The average number of simultaneous queries running in separate user connections
The average query size
The query response time you hope to achieve

A compromise is often necessary when setting these values. You cannot always get an instant response, but you can optimize
performance based on available resources. Use the following equation to get a starting point for the optimization:
FreeMemory / (AvgQuerySize * AvgNumSimulQueries)

For example, if the system has 2200 MB of free memory, the average query size is 2 MB, and the average number of simultaneous
queries is 50, then the optimal value for the query size is 2200 MB / (2 * 50), or 22 MB. Generally, this value represents the
maximum you should assign given the current environment, and you will want to lower this value if possible.
To allocate memory for queries, complete the following steps:
1. In the Server Properties dialog box, go to the Memory page and set a value for the Minimum Memory Per Query box. This value
is set in kilobytes.
2. Click OK.

You can also use the stored procedure sp_configure to set the minimum query size. The related command is:
exec sp_configure "min memory per query", <number of kilobytes>