Application Design Optimization Tips

*****

Use stored procedures instead of passing ANSI-compliant SQL to the database.
This can reduce network traffic because your client will send to server only stored procedure name (perhaps with some parameters) instead of large heavy-duty queries text. Stored procedures can be used to enhance security and conceal underlying data objects also. For example, you can give the users permission to execute the stored procedure to work with the restricted set of the columns and data.
Design the application to run queries asynchronously.
This can improve performance of your application because one query will not wait for the next before it can run.
Consider using Microsoft Transaction Server (MTS) for object pooling.
This can improve performance of your application because MTS allows COM objects to be pooled.
If most of the users have modern power computers ('fat' clients), consider design application to make client data caching.
By doing so, you can reduce the load of your SQL Server because when users will need to access the data they will use local desktop resources, not SQL Server resources.
Consider designing the application to take advantage of the n-tier application model.
By using the n-tier application model, you can increase application's performance and scalability.
Try to restrict the result sets by using the WHERE clause in your SELECT statements.
This can results in good performance benefits because SQL Server will return to client only particular rows, not all rows from the table(s). This can reduce network traffic and boost the overall performance of the query.
Try to restrict the result sets by returning only the particular columns from the table, not all table's columns.
This can results in good performance benefits because SQL Server will return to client only particular columns, not all table's columns. This can reduce network traffic and boost the overall performance of the query.
Try to restrict the result sets by using the select statements with the TOP keyword.
This can improve performance of your application because the smaller result set will be returned. This can also reduce the traffic between the server and the clients.
Use SQL Server cursors to allow your application to fetch a small subset of rows instead of fetching all table's rows.
SQL Server cursors allow application to fetch any block of rows from the result set, including the next n rows, the previous n rows, or n rows starting at a certain row number in the result set. Using SQL Server cursors can reduce network traffic because the smaller result set will be returned.
Use ADO or OLE DB for accessing data from the applications that need high performance.
This can improve performance of your application in comparison with using DAO or ODBC. OLE DB is a low-level COM API for accessing data and ADO is an application-level interface that uses OLE DB. Microsoft recommends to use OLE DB for developing tools, utilities, or low-level components that need high performance and use ADO for general-purpose access programs in business applications (Accounting, Human Resources, and Customer Management).
When you connect to SQL Server, use 'Microsoft OLE DB Provider for SQL Server' instead of 'Microsoft ODBC Driver for SQL Server'.
Because native OLE DB provider is faster than ODBC provider, you should use OLE DB provider whenever possible.
Set a lock time-out so that queries used in your application will not run indefinitely.
You can use the SET LOCK_TIMEOUT command to allow an application to set a maximum time that a statement waits on a blocked resource. When the LOCK_TIMEOUT setting will be exceed, the blocked statement will be canceled automatically, and error message 1222 "Lock request time-out period exceeded" will be returned to the application. Your application should have an error handler that can trap error message 1222.
Avoid using both OLTP and OLAP transactions within the same database.
Because OLTP transactions are optimal for managing changing data and OLAP transactions are optimal for data queries that do not change data try to relegate OLTP and OLAP transactions to their own databases.
Try to avoid using Refresh method when you call stored procedures from the ADO Command object.
This can improve performance of your application because using Refresh method produces extra network traffic. You should explicitly create the stored procedure parameters using ADO code, instead of using the Refresh method to identify the parameters of a stored procedure.
Avoid creating transactions using ADO's methods.
Try to create transactions inside a stored procedure on the SQL Server. By doing so, you can reduce network traffic and boost overall application performance.

Backup/Restore Optimization Tips

*****

Try to perform backup to the local hard disk first, and copy backup file(s) to the tape later.
When you perform backup, some SQL Server commands cannot be made, for example: during backup you cannot run ALTER DATABASE statement with either the ADD FILE or REMOVE FILE options, you cannot shrink database, you cannot run CREATE INDEX statement and so on. So, to decrease the backup operation's time, you can perform backup to the local hard disk first, and then copy backup file(s) to the tape, because tape device usually much more slow than hard disks. The smaller backup operation's time is, the less impact there will be on the server when the backup occurs.
Perform backup on multiple backup devices.
Using multiple backup devices forces SQL Server to create a separate backup thread for each backup device, so the backups will be written to all backup devices in parallel.
Perform backup on a physical disk array, so the more disks in array the more quickly the backup will be made.
This can improve performance because a separate thread will be created for each backup device on each disk in order to write the backup's data in parallel.
Perform backups during periods of low database access.
Because backup is very resource effective, try to schedule it during CPU idle time and slow production periods.
Use full backup to minimize the time to restore databases.
The full backups take the longest to perform in comparison with differential and incremental backups, but are the fastest to restore.
Use incremental backup to minimize the time to backup databases.
The incremental backups take the fastest to perform in comparison with full and differential backups, but are the longest to restore.
Use differential backup instead of incremental backup when the users update the same data many times.
Because a differential backup captures only those data pages that have changed after the last database backup, you can eliminate much of the time the server spends rolling transactions forward when recovering transaction logs from the incremental backups. Using differential backup, in this case, can improve the recovery process in several times.
Try to separate your database to different files and filegroups to backing up only appropriate file/filegroup.
This can results in smaller backup operation's time. The smaller backup operation's time is, the less impact there will be on the server when the backup occurs.
Use Windows NT Performance Monitor or Windows 2000 System Monitor to check a backup impact on the total system performance.
You can verify the following counters: SQL Server Backup Device: Device Throughput Bytes/sec to determine the throughput of specific backup devices, rather than the entire database backup or restore operation; SQL Server Databases: Backup/Restore Throughput/sec to monitor the throughput of the entire database backup or restore operation; PhysicalDisk: % Disk Time to monitors the percentage of time that the disk is busy with read/write activity; Physical Disk Object: Avg. Disk Queue Length to determine how many system requests on average are waiting for disk access.
To decrease the backup operation's time consider backing up more often.
The more often you will make backup, the smaller they will be, and the less impact there will be on the server when the backup occurs. So, to avoid locking users for a long time during everyday work, you can perform backup more often.
Note. The more often you will make backup, the less data you will lost if the database becomes corrupt.
Place a tape drive on another SCSI bus as disks or a CD-ROM drive.
The tape drives perform better if they have a dedicated SCSI bus for each tape drive used. Using separate SCSI bus for a tape drive can results in maximum backup performance and prevents conflicts with other drive array access. Microsoft recommends using dedicated SCSI bus for the tape drives whose native transfer rate exceeds 50 percent of the SCSI bus speed.
Use SQL Server 2000 snapshot backups for the very large databases.
The SQL Server 2000 snapshot backup and restore technologies work in conjunction with third party hardware and software vendors. The main advantages of snapshot backups and restores are that they can be done in a very short time, typically measured in seconds, not hours, and reduce the backup/restore impact on the overall server performance. The snapshot backups accomplished by splitting a mirrored set of disks or creating a copy of a disk block when it is written and required the special hardware and software.

Bulk Copy Optimization Tips

Use nonlogged bulk copy whenever possible.
The nonlogged bulk copy is much faster than logged one, but to use it you must provide all the following conditions:
1. The database option 'select into/bulkcopy' is set to true.
2. The target table is not being replicated.
3. The TABLOCK hint is specified.
4. The target table has no indexes, or if the table has indexes, it is empty when the bulk copy starts.
Use native mode bulk copy whenever possible.
This can improve performance in comparison with the character mode.
Try to use BULK INSERT command instead of bcp or DTS to load data into SQL Server.
The BULK INSERT command is much faster than bcp or the data pump to perform text file import operations, however, the BULK INSERT statement cannot bulk copy data from SQL Server to a data file.

Use the bcp utility instead of DTS when you need to export data from the SQL Server table into a text file.
The bcp utility is much faster than DTS, so try to use it whenever possible.
Specify the number of the first and the last row to bulk copy, if you need to bulk copy not all the rows from the specified data file.
This can results in good performance benefits, because the total amount of data copied will be less.
Specify the number of rows per batch of data copied, if the transaction log was filled before the bulk copy is complete.
Because each batch is copied to the server as one transaction, SQL Server commits or rolls back the transaction for every batch. When you bulk copy large data files, the transaction log can be filled before the bulk copy is complete. In this case, enlarge the transaction log, allow it to grow automatically or specify the number of rows per batch of data copied.
Try to increase the packet_size option.
The packet_size option specifies the number of bytes, per network packet, sent to and from the server. The packet_size can be from 4096 to 65535 bytes with the default of 4096. Increased packet size can enhance performance of bulk copy operations. Try to set the packet_size option to 8192 bytes and continue monitoring.
Use the ORDER hint, if the clustered index exists on the table and the data file is sorted according to the clustered index.
This can significantly improve performance of the bulk copy operation, because SQL Server will load data in the clustered index order without any reorders operations.
If you create a new table and bulk copy data into it, try to bulk load data first and only after that create any indexes.
This can significantly improve performance of the bulk copy operation, because data will be loaded into SQL Server table without any index pages creation during the bulk copy.
If you load data into an empty table with the existing nonclustered indexes, try to drop the nonclustered indexes, bulk load data and only after that re-create the nonclustered indexes.
This can significantly improve performance of the bulk copy operation, because data will be loaded into SQL Server table without any index pages creation during the bulk copy.
If you load data into a nonempty table with the existing clustered and/or nonclustered indexes, and the amount of data added is large, it can be faster to drop all indexes on the table, perform the bulk copy operation, and then re-create the indexes after the data is loaded.
Check the time needed to load data with dropping/re-creating indexes and without dropping/re-creating indexes on your test server before run bulk copy operation on the production server.
If your SQL Server box has multiple CPUs, try to divide loaded data into two or more sources and run multiple instances of BCP on separate clients to load data in parallel.
Because SQL Server allows data to be bulk copied into a single table from multiple clients in parallel using the bcp utility or BULK INSERT statement, try to use parallel data loads whenever possible. To bulk copy data into SQL Server in parallel, you must provide all the following conditions:
1. The database option 'select into/bulkcopy' is set to true.
2. The TABLOCK hint is specified.
3. The target table does not have any indexes.
Specify the TABLOCK hint, if you bulk copy data into an empty table from a single client.
This can improve performance of the bulk copy operation, because this causes a table-level lock to be taken for the duration of the bulk copy operation.
Try to avoid using CHECK_CONSTRAINTS and FIRE_TRIGGERS hints.
Using these hints can significantly degrade performance of the bulk copy operation, because for each row loaded the constraints and insert triggers defined on the destination table will be executed.

Cursor Optimization Tips

Try to avoid using SQL Server cursors, whenever possible.
SQL Server cursors can results in some performance degradation in comparison with select statements. Try to use correlated subquery or derived tables, if you need to perform row-by-row operations.
Do not forget to close SQL Server cursor when its result set is not needed.
To close SQL Server cursor, you can use CLOSE {cursor_name} command. This command releases the cursor result set and frees any cursor locks held on the rows on which the cursor is positioned.
Do not forget to deallocate SQL Server cursor when the data structures comprising the cursor are not needed.
To deallocate SQL Server cursor, you can use DEALLOCATE {cursor_name} command. This command removes a cursor reference and releases the data structures comprising the cursor.
Try to reduce the number of records to process in the cursor.
To reduce the cursor result set, use the WHERE clause in the cursor's select statement. It can increase cursor performance and reduce SQL Server overhead.
Try to reduce the number of columns to process in the cursor.
Include in the cursor's select statement only necessary columns. It will reduce the cursor result set. So, the cursor will use fewer resources. It can increase cursor performance and reduce SQL Server overhead.
Use READ ONLY cursors, whenever possible, instead of updatable cursors.
Because using cursors can reduce concurrency and lead to unnecessary locking, try to use READ ONLY cursors, if you do not need to update cursor result set.
Try avoid using insensitive, static and keyset cursors, whenever possible.
These types of cursor produce the largest amount of overhead on SQL Server, because they cause a temporary table to be created in TEMPDB, which results in some performance degradation.
Use FAST_FORWARD cursors, whenever possible.
The FAST_FORWARD cursors produce the least amount of overhead on SQL Server, because there are read-only cursors and can only be scrolled from the first to the last row. Use FAST_FORWARD cursor if you do not need to update cursor result set and the FETCH NEXT will be the only used fetch option.
Use FORWARD_ONLY cursors, if you need updatable cursor and the FETCH NEXT will be the only used fetch option.
If you need read-only cursor and the FETCH NEXT will be the only used fetch option, try to use FAST_FORWARD cursor instead of FORWARD_ONLY cursor. By the way, if one of the FAST_FORWARD or FORWARD_ONLY is specified the other cannot be specified.

DTS Optimization Tips

Avoid using DTS if it is possible to use Transact-SQL distributed query such as a SELECT INTO statement to transfer data.
Using Transact-SQL is the fastest method to move data between SQL Server tables, so try to use Transact-SQL statements to move data whenever possible.
Try to use BULK INSERT statement instead of bcp or DTS to load data into SQL Server from the text file.
The BULK INSERT statement is much faster than bcp or the data pump to perform text file import operations, however, the BULK INSERT statement cannot export data from SQL Server to a data file.
Use the bcp utility instead of DTS when you need to export data from the SQL Server table into a text file.
The bcp utility is much faster than DTS, so try to use it whenever possible.
Try to avoid using data pump operations that use ActiveX transformation scripts.
Because data pump operations that use ActiveX transformation scripts can be up to two to four times slower than copy operations, you should avoid using ActiveX transformation scripts, whenever possible.
If you cannot avoid using ActiveX scripts in your data pump operations, try to use VBScript instead of JScript or PerlScript.
Microsoft recommends to use VBScript because scripts written in VBScript run approximately 10 percent faster than scripts written in JScript, which in turn run approximately 10 percent faster than scripts written in PerlScript.
When the transformation contains many columns (more than 20) and the data pump operations use ActiveX transformation scripts, use ordinal values to refer to columns in ActiveX transformations instead of referring to columns by name.
Use this tip only when the transformation contains many columns. If the transformation contains less than 20 columns, use columns name to refer to columns in ActiveX transformations to make the script easier to read.
Try to use many-to-many copy column transformations instead of one-to-one copy column transformations.
The DTS Import/Export Wizard uses many-to-many column mappings. By default, the DTS Designer assigns one-to-one column mappings to transformations in order to improve readability. Because a single many-to-many copy column transformation is faster then many one-to-one copy column transformations, you can manually set your Transform Data task or Data Driven Query task to use many-to-many column mappings. For example, to set Transform Data task to use many-to-many column mappings in SQL Server 2000 DTS Designer, you can do the following:
1. Choose appropriate Transform Data task in the DTS Designer.
2. Right-click this task and select Properties.
3. On the Transformations tab click 'Select All' button.
4. Click 'Delete All' button.
5. Click 'New' button and choose 'Copy Column' in the Create New Transformation window.
6. Specify the transformation options and click 'OK' button.
You can increase the DTS package priority.
To increase the DTS package priority in SQL Server 2000, try the following:
1. Run SQL Server Enterprise Manager.
2. Expand a server group; then expand a server.
3. Expand Data Transformation Services and choose appropriate package.
4. Right-click package and select 'Design Package'.
5. From the top menu of the DTS Designer click Package and select Properties.
6. On the General tab increase the package priority by moving the slider bar to the right one or two steps (the slider bar has three position, and the default setting is at the second setting).
You can increase the Transform Data task or Data Driven Query task priority.
To increase the Transform Data task priority in SQL Server 2000 DTS Designer, you can do the following:
1. Choose appropriate Transform Data task in the DTS Designer.
2. Right-click this task and select Workflow Properties.
3. On the Options tab increase the task priority by moving the slider bar to the right one or two steps (the slider bar has five position, and the default setting is at the third setting).
Try to use 'Microsoft OLE DB Provider for SQL Server' instead of 'Microsoft ODBC Driver for SQL Server' and 'Microsoft OLE DB Provider for Oracle' instead of 'Microsoft ODBC Driver for Oracle'.
Because native OLE DB provider is faster than ODBC provider, you should use OLE DB provider whenever possible.
Try to avoid DTS lookups.
Because DTS lookups slow down performance, try to use the Transact-SQL statements to perform the same functions.

*****

Check the 'Use fast load' advanced option of the Transform Data task.
When you enable this option, the high-speed bulk-copy processing will be used. To enable this option in SQL Server 2000 DTS Designer, you can do the following:
1. Choose appropriate Transform Data task in the DTS Designer.
2. Right-click this task and select Properties.
3. On the Options tab check the 'Use fast load' option.
Increase the ODBC query time-out value to improve query performance on large SQL Server 2000 DTS packages stored in a repository.
Change this registry setting from the default value (10 seconds): HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Repository\Engine\ODBCQueryTimeout The ODBC query time-out values are measured in seconds.
When using SQL Server 2000 Transform Data task, try to use 'Copy Column' method to transfer data.
This is the fastest way to transfer data using Transform Data task, so it should be used whenever possible.

Index Optimization Tips

Consider creating index on column(s) frequently used in the WHERE, ORDER BY, and GROUP BY clauses.
These column(s) are best candidates for index creating. You should analyze your queries very attentively to avoid creating not useful indexes.
Keep your indexes as narrow as possible.
Because each index take up disk space try to minimize the index key's size to avoid using superfluous disk space. This reduces the number of reads required to read the index and boost overall index performance.
Drop indexes that are not used.
Because each index take up disk space and slow the adding, deleting, and updating of rows, you should drop indexes that are not used. You can use Index Wizard to identify indexes that are not used in your queries.
Try to create indexes on columns that have integer values rather than character values.
Because the integer values usually have less size then the characters values size (the size of the int data type is 4 bytes, the size of the bigint data type is 8 bytes), you can reduce the number of index pages which are used to store the index keys. This reduces the number of reads required to read the index and boost overall index performance.
Limit the number of indexes, if your application updates data very frequently.
Because each index take up disk space and slow the adding, deleting, and updating of rows, you should create new indexes only after analyze the uses of the data, the types and frequencies of queries performed, and how your queries will use the new indexes. In many cases, the speed advantages of creating the new indexes outweigh the disadvantages of additional space used and slowly rows modification. However, avoid using redundant indexes, create them only when it is necessary. For read-only table, the number of indexes can be increased.
Check that index you tried to create does not already exist.
Keep in mind that when you create primary key constraint or unique key constraints SQL Server automatically creates index on the column(s) participate in these constraints. If you specify another index name, you can create the indexes on the same column(s) again and again.
Create clustered index instead of nonclustered to increase performance of the queries that return a range of values and for the queries that contain the GROUP BY or ORDER BY clauses and return the sort results.
Because every table can have only one clustered index, you should choose the column(s) for this index very carefully. Try to analyze all your queries, choose most frequently used queries and include into the clustered index only those column(s), which provide the most performance benefits from the clustered index creation.
Create nonclustered indexes to increase performance of the queries that return few rows and where the index has good selectivity.
In comparison with a clustered index, which can be only one for each table, each table can have as many as 249 nonclustered indexes. However, you should consider nonclustered index creation as carefully as the clustered index, because each index take up disk space and drag on data modification.
Create clustered index on column(s) that is not updated very frequently.
Because the leaf node of a nonclustered index contains a clustered index key if the table has clustered index, then every time that a column used for a clustered index is modified, all of the nonclustered indexes must also be modified.
Create clustered index based on a single column that is as narrow as possibly.
Because nonclustered indexes contain a clustered index key within their leaf nodes and nonclustered indexes use the clustered index to locate data rows, creating clustered index based on a single column that is as narrow as possibly will reduce not only the size of the clustered index, but all nonclustered indexes on the table also.
Avoid creating a clustered index based on an incrementing key.
For example, if a table has surrogate integer primary key declared as IDENTITY and the clustered index was created on this column, then every time data is inserted into this table, the rows will be added to the end of the table. When many rows will be added a "hot spot" can occur. A "hot spot" occurs when many queries try to read or write data in the same area at the same time. A "hot spot" results in I/O bottleneck.
Note. By default, SQL Server creates clustered index for the primary key constraint. So, in this case, you should explicitly specify NONCLUSTERED keyword to indicate that a nonclustered index is created for the primary key constraint.
Create a clustered index for each table.
If you create a table without clustered index, the data rows will not be stored in any particular order. This structure is called a heap. Every time data is inserted into this table, the row will be added to the end of the table. When many rows will be added a "hot spot" can occur. To avoid "hot spot" and improve concurrency, you should create a clustered index for each table.
Don't create index on column(s) which values has low selectivity.
For example, don't create an index for columns with many duplicate values, such as "Sex" column (which has only "Male" and "Female" values), because in this case the disadvantages of additional space used and slowly rows modification outweigh the speed advantages of creating a new index.
If you create a composite (multi-column) index, try to order the columns in the key as to enhance selectivity, with the most selective columns to the leftmost of the key.
The order of the columns in a composite (multi-column) index is very important. This can increase the chance the index will be used.
If you create a composite (multi-column) index, try to order the columns in the key so that the WHERE clauses of the frequently used queries match the column(s) that are leftmost in the index.
The order of the columns in a composite (multi-column) index is very important. The index will be used to evaluate a query only if the leftmost index key's column are specified in the WHERE clause of the query. For example, if you create composite index such as "Name, Age", then the query with the WHERE clause such as "WHERE Name = 'Alex'" will use the index, but the query with the WHERE clause such as "WHERE Age = 28" will not use the index.
If you need to join several tables very frequently, consider creating index on the joined columns.
This can significantly improve performance of the queries against the joined tables.
Consider creating a surrogate integer primary key (identity, for example).
Every table must have a primary key (a unique identifier for a row within a database table). A surrogate primary key is a field that has a unique value but has no actual meaning to the record itself, so users should never see or change a surrogate primary key. Some developers use surrogate primary keys, others use data fields themselves as the primary key. If a primary key consists of many data fields and has a big size, consider creating a surrogate integer primary key. This can improve performance of your queries.
Consider creating the indexes on all the columns, which referenced in most frequently used queries in the WHERE clause which contains the OR operator.
If the WHERE clause in the query contains an OR operator and if any of the referenced columns in the OR clause are not indexed, then the table or clustered index scan will be made. In this case, creating the indexes on all such columns can significantly improve your queries performance.
If your application will perform the same query over and over on the same table, consider creating a covering index including columns from this query.
A covering index is an index, which includes all of the columns referenced in the query. So the creating covering index can improve performance because all the data for the query is contained within the index itself and only the index pages, not the data pages, will be used to retrieve the data. Covering indexes can bring a lot of performance to a query, because it can save a huge amount of I/O operations.
Use the DBCC DBREINDEX statement to rebuild all the indexes on all the tables in your database periodically (for example, one time per week at Sunday) to reduce fragmentation.
Because fragmented data can cause SQL Server to perform unnecessary data reads and the queries performance against the heavy fragmented table can be very bad, you should periodically rebuild all indexes to reduce fragmentation. Try to schedule the DBCC DBREINDEX statement during CPU idle time and slow production periods.
Use the DBCC INDEXDEFRAG statement to defragment clustered and secondary indexes of the specified table or view.
The DBCC INDEXDEFRAG statement is a new SQL Server 2000 command, which was not supported in the previous versions. Unlike DBCC DBREINDEX, DBCC INDEXDEFRAG does not hold locks long term and thus will not block running queries or updates. So, try to use the DBCC INDEXDEFRAG command instead of DBCC DBREINDEX, whenever possible.
Consider using the SORT_IN_TEMPDB option when you create an index and when tempdb is on a different set of disks than the user database.
The SORT_IN_TEMPDB option is a new SQL Server 2000 feature, which was not supported in the previous versions. When you create an index with the SORT_IN_TEMPDB option, SQL Server uses the tempdb database, instead of the current database, to sort data during the index creation. Using this option can reduce the time it takes to create an index, but increases the amount of disk space used to create an index.
Use the SQL Server Profiler Create Trace Wizard with "Identify Scans of Large Tables" trace to determine which tables in your database may need indexes.
This trace will show which tables are being scanned by queries instead of using an index.

File/Filegroups Optimization Tips

Set a reasonable size of your database.
First of all, before database creation, you should estimate how big your database will be. To estimate the reasonable database size, you should estimate the size of each table individually, and then add the values obtained. See this link for more information: Estimating the Size of a Table
Set a reasonable size for the transaction log.
The general rule of thumb for setting the transaction log size is to set it to 20-25 percent of the database size. The smaller the size of your database, the greater the size of the transaction log should be, and vice versa. For example, if the estimation database size is equal to 10Mb, you can set the size of the transaction log to 4-5Mb, but if the estimated database size is over 500Mb, the 50Mb may be enough for the size of the transaction log.
Leave the Autogrow feature on for the data files and for the log files.
Leave this feature to let SQL Server to automatically increase allocated resources when necessary without DBA intervention. The Autogrow feature is necessary when there is no DBA in your firm or when your DBA doesn't have a lot of experience.
Set a reasonable size of the autogrow increment.
Setting a database to automatically grow results in some performance degradation, therefore you should set a reasonable size for the Autogrow increment to avoid automatically growing too often. Try to set the initial size of the database, and the size of the Autogrow increment, so that automatic growth will occur once per week or less.
Don't set the autoshrink feature.
Autoshrinking results in some performance degradation, therefore you should shrink the database manually or create a scheduled task to shrink the database periodically during off-peak times, rather than set Autoshrink feature to on.
Set the maximum size of the data and log files.
Specify the maximum size to which the files can grow to prevent disk drives from running out of space.
Create a user-defined filegroup and make it the default filegroup.
It's a good decision in most cases to store and manage system and user objects separately from one another, so the user objects will not compete with system objects for space in the primary filegroup. Usually, a user- defined filegroup is not created for small databases, for example, if the database is less than 100Mb.
Create a user-defined filegroup and create some tables in it to run maintenance tasks (backups, DBCC, update statistics, and so on) against these tables.
LOAD TABLE and DUMP TABLE are no longer supported in SQL Server 7.0 (and higher), but you can place a table in its own filegroup and can backup and restore only this table. So you can group user objects with similar maintenance requirements into the same filegroup.
If you have several physical disk arrays, try to create as many files as there are physical disk arrays so that you have one file per disk array.
This will improve performance, because when a table is accessed sequentially, a separate thread is created for each file on each disk array in order to read the table's data in parallel.
Don't create many data and log files on the same physical disk array.
Leaving the autogrow feature on for the data and for the log files can cause fragmentation of those files if there are many files on the same physical disk array. In most cases, it's enough to have 1-2 database files on the same physical disk.
For heavily accessed tables, place these tables in one filegroup and place the table's indexes in a different filegroup on different physical disk arrays.
This will improve performance, because separate threads will be created to access the tables and indexes.
For heavily accessed tables with text/image columns, place this table in one filegroup and place text/image columns in a different filegroup on different physical disks.
You can use CREATE TABLE statement with TEXTIMAGE_ON keyword to place text/image columns in a different filegroup. See the SQL Server BOL for details.
Place the log files on other physical disk arrays than those with the data files.
Because logging is more write-intensive, it's important that the disk arrays containing the SQL Server log files have sufficient disk I/O performance.
If one of your join queries is used much more often than others, place the tables used in this query in different filegroups on different physical disk arrays.
If you have read-only tables, place these tables in different filegroups on different physical disk arrays and use the ALTER DATABASE statement to make just this filegroup READ ONLY.
This not only increases read performance, it prevents any data changes and allows you to control permissions to this data.
Use the Windows NT Performance Monitor to determine the appropriate number for the data and log files on your server by checking the Disk Queue Length counter.
Consider reducing the number of files and filegroups you have for your databases if the Disk Queue length on your server averages above 3, and continue monitoring once you have made your changes to ensure that your disk I/O is optimum over the long term.

Full-Text Search Optimization Tips

Set the virtual memory size to at least 3 times the physical memory installed in the computer, and set the SQL Server 'max server memory' server configuration option to half the virtual memory size setting (1.5 times the physical memory).
Because working with full-text search is very resource expensive, you should have enough physical and virtual memory.
Set the "Maximize Throughput for Network Applications" option.
This can increase full-text search performance, because Windows NT will allocate more RAM to SQL Server than to its file cache. To set this option, you can do the following:
1. Double-click the Network icon in Control Panel.
2. Click the Services tab.
3. Click Server to select it, and then click the Properties button.
4. Click Maximize Throughput for Network Applications, and then click OK.
5. Restart the computer.
Make full-text index population during periods of low database access.
Because full-text index population takes some time, these updates should be scheduled during CPU idle time and slow production periods.
Assign a very large table (a table that has millions of rows) to its own full-text catalog.
This can improve performance, and can be used to simplify administering and monitoring.
You can boost the resource usage for the full-text search service (increase the "System Resource Usage" option for the full-text search service).
Run SQL Server Enterprise Manager, expand a server group then expand a server. Expand "Support Services", then right-click the "Full-Text Search" and select "Properties". Choose the "Performance" tab and increase the "System Resource Usage" option for the full-text search service.
Note. Don't set the "System Resource Usage" option to the "Dedicated" value (right border of the "System Resource Usage" slider bar), because it can negatively affect your SQL Server's performance.
Reduce the full-text unique key size.
To create a full-text index, the table to be indexed must have a unique index. Try to select a numeric column as the full-text unique key to increase the speed of full-text population. If the table to be indexed does not have numeric unique index, consider creating numeric unique index.
If you have several physical disks, create several Pagefile.sys files, so that each Pagefile.sys file will be placed on its own physical disk.
Spreading paging files across multiple disk drives and controllers improves performance on most disk systems because multiple disks can process input/output requests concurrently.
If you use SQL Server 2000, consider using the Change Tracking with scheduled or background update index option versus Incremental Population.
The Change Tracking with scheduled propagation should be used when CPU and memory can be used at scheduled times and changes between the scheduled times are not significant. The Change Tracking with background update index option should be used when CPU and memory are available and the value of an up-to-date index is high.
If you work with SQL Server 7.0, consider using an incremental population when not a large percentage of records were changed or added at once.
Using an incremental population instead of a full population decreases the population time and results in good performance benefits.
If you have several physical disks, place the database files separately from the full-text catalog files.
So, you can improve the speed of full-text queries, because multiple disks can process input/output requests concurrently.
Upgrade to SQL Server 2000, in order to enhance full-text search performance and if you need to work with full-text search in clustered environment.
The full text search is not available in SQL Server 7.0 clustered environment.
If you work with SQL Server 2000, consider using the new top_n_by_rank parameter with CONTAINSTABLE or FREETEXTTABLE.
It can be used to restrict the number of rows returned. The top_n_by_rank parameter specifies that only the n-highest ranked matches, in descending order, will be returned.
Try to use the CONTAINS or FREETEXT predicates instead of the CONTAINSTABLE or FREETEXTTABLE functions to simplify the query's text.
Because qualifying rows returned by the CONTAINSTABLE or FREETEXTTABLE rowset functions must be explicitly joined with the rows in the original SQL Server table, the queries that use the CONTAINSTABLE and FREETEXTTABLE functions are more complex than those that use the CONTAINS and FREETEXT predicates.

SQL Server Settings Optimization Tips

You can increase the 'min memory per query' option to improve the performance of queries that use hashing or sorting operations, if your SQL Server has a lot of memory available and there are many queries running concurrently on the server.
The SQL Server will automatically allocate, at a minimum, the amount of memory set in this configuration setting. The default 'min memory per query' option is equal to 1024 Kb.
You can increase the 'max async IO' option if your SQL Server works on a high performance server with high-speed intelligent disk subsystem (such as hardware-based RAID with more than 10 disks).
This option specifies the maximum number of outstanding asynchronous disk I/O requests that the entire server can issue against a file. By the way, the 'max async IO' SQL Server option is no longer supported in SQL Server 2000.
You can change the 'network packet size' option to the appropriate value.
This option can improve performance on networks whose base topology supports larger packets than TCP/IP's default of 4096 bytes. For example, if client sends or receives large amounts of data, a larger packet size can improve performance, because it results in fewer network reads and writes. The default value for the 'network packet size' option is 4096 bytes. Microsoft does not recommend changing this option, because for most applications, the default packet size of 4096 bytes is best.
You can change the 'fill factor' option to the appropriate value.
The 'fill factor' option specifies how full SQL Server will make each index page. When there is no free space to insert new row on the index page, SQL Server will create new index page and transfer some rows from the previous page to the new one. This operation is called page splits. You can reduce the number of page splits by setting the appropriate fill factor option to reserve free space on each index page. The fill factor is a value from 1 through 100 that specifies the percentage of the index page to be left empty. The default value for fill factor is 0. It is treated similarly to a fill factor value of 100, the difference in that SQL Server leaves some space within the upper level of the index tree for FILLFACTOR = 0. The fill factor percentage is used only at the time the index is created. If the table contains read-only data (or data that very rarely changed), you can set the 'fill factor' option to 100. When the table's data modified very often, you can decrease the 'fill factor' option to 70 percent, for example.
You can increase the 'recovery interval' value.
The 'recovery interval' option specifies the maximum number of minutes per database that SQL Server needs to complete its recovery procedures. The default value of this option is 0. It means that SQL Server will automatically configure this option. SQL Server issues a checkpoint using the 'recovery interval' option. Microsoft does not recommend changing this option in general case, but sometimes you can improve performance by changing this option. You can monitor disk-write activity on the data files, and if you see periodic spikes that send disk utilization to 100 percent, you can increase the recovery interval. In this case, Microsoft suggests setting the 'recovery interval' option to 5 and continuing monitoring.
You can set the 'priority boost' SQL Server options to 1.
You can set this option to 1, if you want from SQL Server to work with a higher priority than other processes on the same computer. The default value is 0. Setting 'priority boost' to 1 can degrade the performance of other applications running on the same computer with SQL Server. So, you should set the 'priority boost' SQL Server options to 1 only if you have dedicated server to SQL Server. In other case, do not change this option.
Set the 'max worker threads' options to the maximum number of the user connections to your SQL Server box.
The default setting for the 'max worker threads' option is 255. If the number of user connections will be less than the 'max worker threads' value, a separate operating system thread will be created for each client connection, but if the number of user connections will exceed this value the thread pooling will be used. For example, if the maximum number of the user connections to your SQL Server box is equal to 50, you can set the 'max worker threads' options to 50, this frees up resources for SQL Server to use elsewhere. If the maximum number of the user connections to your SQL Server box is equal to 500, you can set the 'max worker threads' options to 500, this can improve SQL Server performance because thread pooling will not be used.
You can specify the 'min server memory' and 'max server memory' options.
These options can be used to specify the fixed amount of memory to allocate to SQL Server. In this case, you should set the 'min server memory' and 'max server memory' to the same value (equal to the maximum amount of physical memory that SQL Server will use), and set the 'set working set size' SQL Server option to 1. This can improve performance because SQL Server will not dynamically allocate memory. You can also change these options when SQL Server works on the same computer with other applications. In this case, the 'min server memory' options is used to allow SQL Server works when other applications pretend to use all available memory, and the 'max server memory' options is used to allow other applications work when SQL Server tried to use all available resources.
You can specify the 'set working set size' SQL Server option to reserve the amount of physical memory space for SQL Server.
Unlike SQL Server 6.5, SQL Server 7.0/2000 can automatically allocate memory (can take more memory if SQL Server need it, and can give memory back to operation system). This is one of the main advantages in comparison with previous versions, but dynamic memory allocation takes some time. If you know the maximum amount of physical memory that SQL Server will use, you can specify this amount by setting 'min server memory' and 'max server memory' to the same value (equal to the maximum amount of physical memory that SQL Server will use) and set the 'set working set size' option to 1.

Database Settings Optimization Tips

You can turn off the 'auto create statistics' database option.
When this database option is set to true, statistics are automatically created on columns used in a predicate. By default, this database option is set to true. Because auto creation statistics results in some performance degradation, you can turn off this database option and create statistics manually during off-peak times by using the CREATE STATISTICS statement. By the way, in most cases, it will not provide some performance benefits.
You can turn off the 'auto update statistics' database option.
When this database option is set to true, existing statistics are automatically updated when the statistics become out-of-date. By default, this database option is set to true. Because auto update statistics results in some performance degradation, you can turn off this database option and update statistics manually during off-peak times by using the UPDATE STATISTICS statement. By the way, in most cases, it will not provide some performance benefits.
Turn off the 'autoclose' database option.
When this option is turned on, the database's resources are freed after the last user exits. When the new user will connect to database, the database should be reopened, which takes some time. So, do hot set this database option to true on your production server. By default, this database option is set to true when using SQL Server Desktop Edition, and set to false for all other editions.
Turn off the 'autoshrink' database option.
When this database option is set to true, the database files will be periodically shrink. Autoshrinking results in some performance degradation, therefore you should shrink the database manually or create a scheduled task to shrink the database periodically during off-peak times, rather than set Autoshrink feature to on. By default, this database option is set to true when using SQL Server Desktop Edition, and set to false for all other editions.
You can turn on the 'read-only' database option to prevent users to modify the database's data.
By default, this database option is set to false. If you have data that should not be modified, you can place it into another database and set for this database the 'read-only' option to true. It can increase the speed of your queries. If you need to allow permissions management (for example, prevent some users to select data from some tables), you should create another filegroup and make only this filegroup read-only, because when the 'read-only' database option is set to true, the database's system tables will be also read-only and this will prevent the permissions management.
You can turn on the 'select into/bulkcopy' database option to allow SELECT INTO statements and nonlogged bulk copies.
The nonlogged bulk copy is much faster than logged one, but to use it you must provide all the following conditions:
1. The database option 'select into/bulkcopy' is set to true.
2. The target table is not being replicated.
3. The TABLOCK hint is specified.
4. The target table has no indexes, or if the table has indexes, it is empty when the bulk copy starts.
By default, this database option is set to false.
You can turn off the 'trunc. log on chkpt.' database option to prevent the transaction log from truncating on checkpoint.
This option can be set if the transaction log grows very quickly to prevent the transaction log from filling rapidly and running out of disk space. If you set the 'trunc. log on chkpt.' database option to true, the transaction log cannot be backed up, so you cannot restore your data to the point of failure (only to the time when the last full backup was made). So, the general recommendation about this option is allow it to be turned off, and make the transaction log backup periodically to truncate the log. By default, this database option is set to true when using SQL Server Desktop Edition, and set to false for all other editions.

Note. You can set the above database options by using the sp_dboption system stored procedure or Enterprise Manager. If you want to set the above database options for the newly created database, you should set these options for the model database.

Operation System Optimization Tips

Set a reasonable size of your PAGEFILE.SYS file(s).
Microsoft recommends that the Windows NT PAGEFILE.SYS file(s) be set to physical RAM + 12 MB for the initial size and physical RAM + half of physical RAM for the maximum size. Microsoft recommends that the Windows 2000 PAGEFILE.SYS file(s) be set to 1.5 times the amount of physical RAM.
If you used additional SQL services such as Full-Text Search service, the size of PAGEFILE.SYS file(s) should be increased.
To increase the size of PAGEFILE.SYS file(s), you can do the following:
1. Double-click the Control Panel System applet and select the Performance tab.
2. Click the "Virtual Memory" button.
3. Set appropriate size of the PAGEFILE.SYS file(s).
4. Restart the computer.
Create another pagefile.sys files on every separate physical drives (Except drive contains the Windows NT system directory).
Spreading paging files across multiple disk drives and controllers improves performance on most disk systems because multiple disks can process input/output requests concurrently.
If you have a lot of RAM, you can configure your Windows NT server to never page out drivers and system code to the pagefile that are in the pageable memory area.
Run regedit and choose:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Set DisablePagingExecutive to 1 and reboot the server box.
Set the "Maximize Throughput for Network Applications" option.
This can increase SQL Server performance, because Windows NT will allocate more RAM to SQL Server than to its file cache.
To set this option, you can do the following:
1. Double-click the Network icon in Control Panel.
2. Click the Services tab.
3. Click Server to select it, and then click the Properties button.
4. Click Maximize Throughput for Network Applications, and then click OK.
5. Restart the computer.
You can increase performance by disable last access update files date.
Run regedit and choose:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate
Add key NtfsDisableLastAccessUpdate as REG_DWORD and set it to "1".
Use minimum protocols on the server box (only TCP/IP, for example).
Because each protocol uses RAM and CPU, you can remove unused protocols to release resources for SQL Server using.
Use minimum services on the server box.
Try to remove from startup IIS service, FTP server service, Gopher, SMTP, WINS, DHCP, Directory Replicator and so on, if you do not need to use these services. You can start these services manually when you will need them.
When multiple transport protocols are installed, set the most frequently used protocol to the first place in the binding list.
If you installed several protocols, Windows NT negotiates network connections in the order that the protocols are prioritized in the network services binding list. So, the first protocol in the binding list will be used before the other installed protocols. You can improve the overall performance by setting the most frequently used protocol to the first place in the binding list.
Use as few counters in Performance Monitor, as possible.
Because each Performance Monitor counter uses some server resources, it is a great idea to use as few counters in Performance Monitor, as possible.
Do not use Open GL screen savers on your server box.
Because Open GL screen savers use a lot of system resources, it is a great idea to not use them on a server box.
Use as few types of Audit Policy events, as possible.
Because each type of Audit Policy events uses some server resources, it is a great idea to use as few types of Audit Policy events, as possible. Try to not use "File and Objects Access" and "Process Tracking" Audit Policy events, because they most resource expensive in comparison with other Audit Policy events.
Set the performance boost for the foreground applications to "None".
This ensures that background applications (SQL Server, for example) will get higher priority than foreground applications.
To set the performance boost for the foreground applications to "None", you can do the following:
1. Double-click the Control Panel System applet and select the Performance tab.
2. On the Application Performance box drag the arrow to set the boost to "None".

You can increase the I/O Page Lock Limit to increase the performance of the reads and writes operations.
Run regedit and choose:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Set IoPageLockLimit to the maximum bytes you can lock for I/O operations.

Optimization tips for designing tables

Normalize your tables to the third normal form.
A table is in third normal form (3NF) if it is in second normal form (2NF) and if it does not contain transitive dependencies. In most cases, you should normalize your tables to the third normal form. The normalization is used to reduce the total amount of redundant data in the database. The less data there is, the less work SQL Server has to perform, speeding its performance.
Consider the denormalization of your tables from the forth or fifth normal forms to the third normal form.
Normalization to the forth and fifth normal forms can result in some performance degradation, especially when you need to perform many joins against several tables. It may be necessary to denormalize your tables to prevent performance degradation.
Consider horizontal partitioning of the very large tables into the current and the archives versions.
The less space used, the smaller the table, the less work SQL Server has to perform to evaluate your queries. For example, if you need to query only data for the current year in your daily work, and you need all the data only once per month for the monthly report, you can create two tables: one with the current year's data and one with the old data.
Create the table's columns as narrow as possible.
This can reduce the table's size and improve performance of your queries as well as some maintenance tasks (such as backup, restore and so on).
Try to reduce the number of columns in a table.
The fewer the number of columns in a table, the less space the table will use, since more rows will fit on a single data page, and less I/O overhead will be required to access the table's data.
Try to use constraints instead of triggers, rules, and defaults whenever possible.
Constraints are much more efficient than triggers and can boost performance. Constraints are more consistent and reliable in comparison to triggers, rules and defaults, because you can make errors when you write your own code to perform the same actions as the constraints.
If you need to store integer data from 0 through 255, use tinyint data type.
The columns with tinyint data type use only one byte to store their values, in comparison with two bytes, four bytes and eight bytes used to store the columns with smallint, int and bigint data types accordingly. For example, if you design tables for a small company with 5-7 departments, you can create the departments table with the DepartmentID tinyint column to store the unique number of each department.
If you need to store integer data from -32,768 through 32,767, use smallint data type.
The columns with smallint data type use only two bytes to store their values, in comparison with four bytes and eight bytes used to store the columns with int and bigint data types respectively. For example, if you design tables for a company with several hundred employees, you can create an employee table with the EmployeeID smallint column to store the unique number of each employee.
If you need to store integer data from -2,147,483,648 through 2,147,483,647, use int data type.
The columns with int data type use only four bytes to store their values, in comparison with eight bytes used to store the columns with bigint data types. For example, to design tables for a library with more than 32,767 books, create a books table with a BookID int column to store the unique number of each book.
Use smallmoney data type instead of money data type, if you need to store monetary data values from 214,748.3648 through 214,748.3647.
The columns with smallmoney data type use only four bytes to store their values, in comparison with eight bytes used to store the columns with money data types. For example, if you need to store the monthly employee payments, it might be possible to use a column with the smallmoney data type instead of money data type.
Use smalldatetime data type instead of datetime data type, if you need to store the date and time data from January 1, 1900 through June 6, 2079, with accuracy to the minute.
The columns with smalldatetime data type use only four bytes to store their values, in comparison with eight bytes used to store the columns with datetime data types. For example, if you need to store the employee's hire date, you can use column with the smalldatetime data type instead of datetime data type.
Use varchar/nvarchar columns instead of text/ntext columns whenever possible.
Because SQL Server stores text/ntext columns on the Text/Image pages separately from the other data, stored on the Data pages, it can take more time to get the text/ntext values.
Use char/varchar columns instead of nchar/nvarchar if you do not need to store unicode data.
The char/varchar value uses only one byte to store one character, the nchar/nvarchar value uses two bytes to store one character, so the char/varchar columns use two times less space to store data in comparison with nchar/nvarchar columns.
Consider setting the 'text in row' SQL Server 2000 table's option.
The text, ntext, and image values are stored on the Text/Image pages, by default. This option specifies that small text, ntext, and image values will be placed on the Data pages with other data values in a data row. This can increase the speed of read and write operations and reduce the amount of space used to store small text, ntext, and image data values. You can set the 'text in row' table option by using the sp_tableoption stored procedure.
If you work with SQL Server 2000, use cascading referential integrity constraints instead of triggers whenever possible.
For example, if you need to make cascading deletes or updates, specify the ON DELETE or ON UPDATE clause in the REFERENCES clause of the CREATE TABLE or ALTER TABLE statements. The cascading referential integrity constraints are much more efficient than triggers and can boost performance.

Transact-SQL Optimization Tips

Try to restrict the queries result set by using the WHERE clause.
This can results in good performance benefits, because SQL Server will return to client only particular rows, not all rows from the table(s). This can reduce network traffic and boost the overall performance of the query.
Try to restrict the queries result set by returning only the particular columns from the table, not all table's columns.
This can results in good performance benefits, because SQL Server will return to client only particular columns, not all table's columns. This can reduce network traffic and boost the overall performance of the query.
Use views and stored procedures instead of heavy-duty queries.
This can reduce network traffic, because your client will send to server only stored procedure or view name (perhaps with some parameters) instead of large heavy-duty queries text. This can be used to facilitate permission management also, because you can restrict user access to table columns they should not see.
Try to avoid using SQL Server cursors, whenever possible.
SQL Server cursors can result in some performance degradation in comparison with select statements. Try to use correlated subquery or derived tables, if you need to perform row-by-row operations.
If you need to return the total table's row count, you can use alternative way instead of SELECT COUNT(*) statement.
Because SELECT COUNT(*) statement make a full table scan to return the total table's row count, it can take very many time for the large table. There is another way to determine the total row count in a table. You can use sysindexes system table, in this case. There is ROWS column in the sysindexes table. This column contains the total row count for each table in your database. So, you can use the following select statement instead of SELECT COUNT(*): SELECT rows FROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid <>
Try to use constraints instead of triggers, whenever possible.
Constraints are much more efficient than triggers and can boost performance. So, you should use constraints instead of triggers, whenever possible.
Use table variables instead of temporary tables.
Table variables require less locking and logging resources than temporary tables, so table variables should be used whenever possible. The table variables are available in SQL Server 2000 only.
Try to avoid the HAVING clause, whenever possible.
The HAVING clause is used to restrict the result set returned by the GROUP BY clause. When you use GROUP BY with the HAVING clause, the GROUP BY clause divides the rows into sets of grouped rows and aggregates their values, and then the HAVING clause eliminates undesired aggregated groups. In many cases, you can write your select statement so, that it will contain only WHERE and GROUP BY clauses without HAVING clause. This can improve the performance of your query.
Try to avoid using the DISTINCT clause, whenever possible.
Because using the DISTINCT clause will result in some performance degradation, you should use this clause only when it is necessary.
Include SET NOCOUNT ON statement into your stored procedures to stop the message indicating the number of rows affected by a T-SQL statement.
This can reduce network traffic, because your client will not receive the message indicating the number of rows affected by a T-SQL statement.
Use the select statements with TOP keyword or the SET ROWCOUNT statement, if you need to return only the first n rows.
This can improve performance of your queries, because the smaller result set will be returned. This can also reduce the traffic between the server and the clients.
Use the FAST number_rows table hint if you need to quickly return 'number_rows' rows.
You can quickly get the n rows and can work with them, when the query continues execution and produces its full result set.
Try to use UNION ALL statement instead of UNION, whenever possible.
The UNION ALL statement is much faster than UNION, because UNION ALL statement does not look for duplicate rows, and UNION statement does look for duplicate rows, whether or not they exist.
Do not use optimizer hints in your queries.
Because SQL Server query optimizer is very clever, it is very unlikely that you can optimize your query by using optimizer hints, more often, this will hurt performance.

Miscellaneous Optimization Tips

Try to perform backup at the local hard disk first, and copy backup file(s) to the tape later.
When you perform backup, some SQL Server commands cannot be made, for example: during backup you cannot run ALTER DATABASE statement with either the ADD FILE or REMOVE FILE options, you cannot shrink database, you cannot run CREATE INDEX statement, you cannot make SELECT INTO, bulk load and so on. So, to improve backup performance, you can perform backup at the local hard disk first, and then copy backup file(s) to the tape.
Use nonlogged bulk copy whenever possible.
The nonlogged bulk copy is much faster than logged one, but to use it you must provide all the following conditions:
1. The database option 'select into/bulkcopy' is set to true.
2. The target table is not being replicated.
3. The TABLOCK hint is specified.
4. The target table has no indexes, or if the table has indexes, it is empty when the bulk copy starts.
Use native mode bulk copy whenever possible.
This can improve performance in comparison with the character mode.
Try to use BULK INSERT command instead of bcp or DTS to load data into SQL Server.
The BULK INSERT command is much faster than bcp or the data pump to perform text file import operations, however, the BULK INSERT statement cannot bulk copy data from SQL Server to a data file.
Use the bcp utility instead of DTS when you need to export data from the SQL Server table into a text file.
The bcp utility is much faster than DTS, so try to use it whenever possible.
Keep transactions as short as possible.
This can be used to prevent deadlocks.
Consider the horizontally partitioning the very large tables into the current and archives versions.
This can improve performance of your select statements.
Normalize your database's tables to the third normal form.
A table is in third normal form (3NF) if it is in second normal form (2NF) and if it does not contain transitive dependencies. In most cases, you should normalize your tables to the third normal form.
Consider the denormalization of your database's tables from the fourth or fifth normal forms to the third normal form.
Normalization to the fourth and fifth normal forms can results in some performance degradation, so it can be necessary to denormalize your database's tables to prevent performance degradation.
Create the table's columns as narrow as possible.
So, you can reduce the table's size, this can improve performance of your queries and some maintenance tasks (such as backup, restore and so on).
Use varchar/nvarchar columns instead of text/ntext columns whenever possible.
Because SQL Server stores text/ntext columns on the Text/Image pages separately from the other data, stored on the Data pages, then it can take more time to get the text/ntext values.

Use char/varchar columns instead of nchar/nvarchar if you do not need to store unicode data.
So, you can reduce the table's size, this can improve performance of your queries and some maintenance tasks (such as backup, restore and so on).
Use char/nchar data type instead of varchar/nvarchar if the column's size will be 4 bytes or less.
The char data type is a fixed-length data type and varchar data type is variable-length data type. So, by using char data type, you can increase the probability of in-place update instead of delete/insert or deferred update. The in-place update is the most effective method of modification, when it is used the data changed on its physical place. When the row's size is changed, the delete/insert modification method can be used. This results in some performance degradation.
If you need to delete all tables rows, consider using TRUNCATE TABLE instead of DELETE command.
Using the TRUNCATE TABLE is much fast way to delete all table's rows, because it removes all rows from a table without logging the individual row deletes.
You can increase the speed of sorting operation up to 20 percent, if you will use Binary sort order instead of Dictionary sort order, which is used by default.
Binary sort order is the simplest and fastest sort order, but it is used not often, because binary sort is not case-insensitive and it is based on the numeric values (from 0 through 255) of the characters in the installed character set.
Don't use Enterprise Manager to access remote servers over a slow link or to maintain very large databases.
Because using Enterprise Manager is very resource expensive, use stored procedures and T-SQL statements, in this case.
Try to install SQL Server on a standalone server box, not on a primary or backup domain controller.
Because domain controllers have extra overhead, you should install SQL Server on a standalone server box to dedicate all of the server's power to SQL Server.

Replication Optimization Tips

Avoid publishing unnecessary data.
Try to restrict the amount of published data. This can results in good performance benefits, because SQL Server will publish only the amount of data required. This can reduce network traffic and boost the overall replication performance.
Place the published database log and distribution database log on the separate disk drives.
Because logging is more write-intensive, it is important that the disk arrays containing the SQL Server log files have sufficient disk I/O performance.
Do not configure the distribution database to expand or shrink automatically.
Microsoft recommends to set a fixed size for the distribution database. Setting a database to automatically grow results in some performance degradation, therefore you should set a reasonable initial size of the distribution database.
Place the distribution component of replication on its own dedicated server.
This topology is used for performance reasons when the level of replication activity increases or the server resources become constrained. It reduces Publisher loading, but it increases overall network traffic. This topology requires separate Microsoft SQL Server installations, one for the Publisher and one for the Distributor.
Run the Snapshot Agent as infrequently as possible.
The Snapshot Agent bulk copies data from the Publisher to the Distributor, which results in some performance degradation. So, try to schedule it during CPU idle time and slow production periods.
Avoid using continuous replication.
Try to schedule replication to occur at regular intervals instead of using continuous replication.
Avoid replicating text, ntext and image columns.
These data types require more storage space and processing than other column data types.
Replicate the execution of stored procedures when a large number of rows are affected.
For example, instead of replicating a very large number of insert, update and delete statements, you can create stored procedure, which will contain all these statements, and replicate to subscriber only the execution of this stored procedure. This can reduce network traffic and boost the overall replication performance.
Set the "Maximize Throughput for Network Applications" option.
This can increase SQL Server performance, because Windows NT will allocate more RAM to SQL Server than to its file cache. To set this option, you can do the following:
1. Double-click the Network icon in Control Panel.
2. Click the Services tab.
3. Click Server to select it, and then click the Properties button.
4. Click Maximize Throughput for Network Applications, and then click OK.
5. Restart the computer.
Specify the 'min server memory' options.
This option is used to set a minimum amount of memory allocated to SQL Server. Microsoft recommends that the 'min server memory' options be set to at least 16 MB of memory to avoid low memory availability during replication activities, if the server is a remote Distributor or a combined Publisher and Distributor. You can also change these options when SQL Server works on the same computer with other applications. In this case, the 'min server memory' option is used to allow SQL Server works when other applications pretend to use all available memory.
If you work with SQL Server 2000 in a central publisher with remote distributor topology (when the distribution component of replication resides on its own dedicated server) and Publisher connected with the Distributor over slow LAN or WAN, consider compressing the snapshot files.
This is a new SQL Server 2000 replication feature, which allows you to decrease network traffic by compressing snapshot files.
Try to enable pull or anonymous subscriptions to increase the Distributor performance.
This can increase the Distributor performance, because Distribution Agent processing will be moved from the Distributor to Subscribers.
Increase the MaxBcpThreads property of the Snapshot Agent.
This property specifies the number of bulk copy operations that can be performed in parallel. By increasing this value, bulk copy operations can run faster, because they will be perform in parallel. To increase the MaxBcpThreads value in the Snapshot Agent profile, you can do the following:
1. Run SQL Server Enterprise Manager.
2. Expand a server group; then expand a server.
3. Expand Replication Monitor; then expand the Agents and click the Snapshot Agents folder.
4. Right-click appropriate publication and select Agent Profiles...
5. Click the New Profile button to create the new profile with the appropriate MaxBcpThreads value.
6. Choose the newly created profile.
Note. Do not set this property too high, it can results in some performance degradation, because SQL Server will have to spend extra time managing the extra threads. Increase this property to 2 and continue monitoring.
Set the OutputVerboseLevel property of the Distribution Agent, the Log Reader Agent, the Merge Agent, and the Snapshot Agent to 0.
This property specifies whether the output should be verbose. There are three available values:
0 - only error messages are printed
1 - all of the progress report messages are printed
2 - all error messages and progress report messages are printed
The default value is 2. You can increase performance by printed only error messages.
To set the OutputVerboseLevel value to 0, you can do the following:
1. Run SQL Server Enterprise Manager.
2. Expand a server group; then expand a server.
3. Expand Replication Monitor; then expand the Agents and click the appropriate agent folder.
4. Right-click appropriate publication and select Agent Properties...
5. On the Steps tab, double-click the Run agent step, and then add the -OutputVerboseLevel 0 in the Command text box.
You can minimize the performance affect of history logging by selecting 1 for the HistoryVerboseLevel property of the Distribution Agent, the Log Reader Agent, the Merge Agent, and the Snapshot Agent.
This property specifies the amount of history logged during distribution operation (for a Distribution Agent), during a log reader operation (for a Log Reader Agent), during a merge operation (for a Merge Agent), or during a snapshot operation (for a Snapshot Agent).
To set the HistoryVerboseLevel value to 1, you can do the following:
1. Run SQL Server Enterprise Manager.
2. Expand a server group; then expand a server.
3. Expand Replication Monitor; then expand the Agents and click the appropriate agent folder.
4. Right-click appropriate publication and select Agent Properties...
5. On the Steps tab, double-click the Run agent step, and then add the -HistoryVerboseLevel 1 in the Command text box.
If you work with SQL Server 2000 consider using the -UseInprocLoader agent property.
If this option was set, the in-process BULK INSERT command will be used when applying snapshot files to the Subscriber. You cannot use this property with character mode bcp, this property cannot be used by OLE DB or ODBC Subscribers.
To set the UseInprocLoader property, you can do the following:
1. Run SQL Server Enterprise Manager.
2. Expand a server group; then expand a server.
3. Expand Replication Monitor; then expand the Agents and click the Distribution Agents or Merge Agents folder.
4. Right-click appropriate publication and select Agent Properties...
5. On the Steps tab, double-click the subscription agent step, and then add the -UseInprocLoader property in the Command text box.
Increase the Log Reader Agent ReadBatchSize parameter.
This parameter specifies the maximum number of transactions read out of the transaction log of the publishing database. The default value is 500. This option should be used when a large number of transactions are written to a publishing database, but only a small subset of those are marked for replication.
If you work with transactional replication, increase the Distribution Agent CommitBatchSize parameter.
This parameter specifies the number of transactions to be issued to the Subscriber before a COMMIT statement is issued. The default value is 100.
Create an index on each of the columns that is used in the filter's WHERE clause.
If you do not use indexes on columns used in filters, then SQL Server must perform a table scan.
If you work with merge replication, use static instead of dynamic filters.
Because SQL Server requires more overhead to process the dynamic filters than static filters, for best performance you should use static filters, whenever possible.

Stored Procedures Optimization Tips

Use stored procedures instead of heavy-duty queries.
This can reduce network traffic, because your client will send to server only stored procedure name (perhaps with some parameters) instead of large heavy-duty queries text. Stored procedures can be used to enhance security and conceal underlying data objects also. For example, you can give the users permission to execute the stored procedure to work with the restricted set of the columns and data.

Include the SET NOCOUNT ON statement into your stored procedures to stop the message indicating the number of rows affected by a Transact-SQL statement.
This can reduce network traffic, because your client will not receive the message indicating the number of rows affected by a Transact-SQL statement.
Call stored procedure using its fully qualified name.
The complete name of an object consists of four identifiers: the server name, database name, owner name, and object name. An object name that specifies all four parts is known as a fully qualified name. Using fully qualified names eliminates any confusion about which stored procedure you want to run and can boost performance because SQL Server has a better chance to reuse the stored procedures execution plans if they were executed using fully qualified names.
Consider returning the integer value as an RETURN statement instead of an integer value as part of a recordset.
The RETURN statement exits unconditionally from a stored procedure, so the statements following RETURN are not executed. Though the RETURN statement is generally used for error checking, you can use this statement to return an integer value for any other reason. Using RETURN statement can boost performance because SQL Server will not create a recordset.
Don't use the prefix "sp_" in the stored procedure name if you need to create a stored procedure to run in a database other than the master database.
The prefix "sp_" is used in the system stored procedures names. Microsoft does not recommend to use the prefix "sp_" in the user-created stored procedure name, because SQL Server always looks for a stored procedure beginning with "sp_" in the following order: the master database, the stored procedure based on the fully qualified name provided, the stored procedure using dbo as the owner, if one is not specified. So, when you have the stored procedure with the prefix "sp_" in the database other than master, the master database is always checked first, and if the user-created stored procedure has the same name as a system stored procedure, the user-created stored procedure will never be executed.
Use the sp_executesql stored procedure instead of the EXECUTE statement.
The sp_executesql stored procedure supports parameters. So, using the sp_executesql stored procedure instead of the EXECUTE statement improve readability of your code when there are many parameters are used. When you use the sp_executesql stored procedure to executes a Transact-SQL statements that will be reused many times, the SQL Server query optimizer will reuse the execution plan it generates for the first execution when the change in parameter values to the statement is the only variation.
Use sp_executesql stored procedure instead of temporary stored procedures.
Microsoft recommends to use the temporary stored procedures when connecting to earlier versions of SQL Server that do not support the reuse of execution plans. Applications connecting to SQL Server 7.0 or SQL Server 2000 should use the sp_executesql system stored procedure instead of temporary stored procedures to have a better chance to reuse the execution plans.
If you have a very large stored procedure, try to break down this stored procedure into several sub-procedures, and call them from a controlling stored procedure.
The stored procedure will be recompiled when any structural changes were made to a table or view referenced by the stored procedure (for example, ALTER TABLE statement), or when a large number of INSERTS, UPDATES or DELETES are made to a table referenced by a stored procedure. So, if you break down a very large stored procedure into several sub-procedures, you get chance that only a single sub-procedure will be recompiled, but other sub-procedures will not.
Try to avoid using temporary tables inside your stored procedure.
Using temporary tables inside stored procedure reduces the chance to reuse the execution plan.
Try to avoid using DDL (Data Definition Language) statements inside your stored procedure.
Using DDL statements inside stored procedure reduces the chance to reuse the execution plan.
Add the WITH RECOMPILE option to the CREATE PROCEDURE statement if you know that your query will vary each time it is run from the stored procedure.
The WITH RECOMPILE option prevents reusing the stored procedure execution plan, so SQL Server does not cache a plan for this procedure and the procedure is recompiled at run time. Using the WITH RECOMPILE option can boost performance if your query will vary each time it is run from the stored procedure because in this case the wrong execution plan will not be used.
Use SQL Server Profiler to determine which stored procedures has been recompiled too often.
To check the stored procedure has been recompiled, run SQL Server Profiler and choose to trace the event in the "Stored Procedures" category called "SP:Recompile". You can also trace the event "SP:StmtStarting" to see at what point in the procedure it is being recompiled. When you identify these stored procedures, you can take some correction actions to reduce or eliminate the excessive recompilations.

SQL Server 2000 Optimization Tips

For the very large databases, use distributed partitioned views to partition tables horizontally across multiple servers.
This is a new SQL Server 2000 feature, which is available when using SQL Server 2000 Enterprise Edition only. Due to distributed partitioned views, SQL Server 2000 now on the first place in the TPC-C tests.
Use indexed views to increase the speed of your queries.
The result set of the indexed view is persist in the database and indexed for fast access. Because indexed views depend on base tables, you should create indexed views with SCHEMABINDING option to prevent the table or column modification that would invalidate the view. Furthermore, using views instead of heavy-duty queries can reduce network traffic and can be used to facilitate permission management.
Consider using the WITH SORT_IN_TEMPDB option when you create an index and when tempdb is on a different set of disks than the user database.
Using this option can reduce the time it takes to create an index, but increases the amount of disk space used to create an index.
You can specify whether the index keys are stored in ascending or descending order.
For example, using the CREATE INDEX statement with the DESC option (descending order) can increase the speed of queries, which return rows in the descending order. By default, the ascending order is used.
Consider creating index on computed columns.
In SQL Server 2000, you can create indexes on computed columns. To create index on computed column, the computed column must be deterministic, precise, and cannot has text, ntext, or image data type.
Consider setting the 'text in row' table option.
The text, ntext, and image values are stored on the Text/Image pages, by default. This option specifies that small text, ntext, and image values will be placed on the Data pages with other data values in a data row. This can increase the speed of read and write operations and reduce the amount of space used to store small text, ntext, and image data values. You can set the 'text in row' table option by using the sp_tableoption stored procedure.
Use table variables instead of temporary tables.
The table variable is a new SQL Server 2000 feature. The table variables require less locking and logging resources than temporary tables, so table variables should be used whenever possible.
Use cascading referential integrity constraints instead of triggers, whenever possible.
For example, if you need to make cascading deletes or updates, you can specify ON DELETE or ON UPDATE clause in the REFERENCES clause of the CREATE TABLE and ALTER TABLE statements. The cascading referential integrity constraints are much more efficient than triggers and can boost performance.
If you work with SQL Server 2000 Enterprise Edition use SAN (System Area Network) protocols instead of LAN (Local Area Network) or WAN (Wide Area Network).
SANs are more reliable than LANs or WANs and support high levels of messaging traffic by lowering CPU loads and message latency.
Use user-defined functions to encapsulate code for reuse.
The user-defined functions (UDFs) contain one or more Transact-SQL statements that can be used to encapsulate code for reuse. Using UDFs can reduce network traffic.
Set the 'awe enabled' server configuration option to 1 if you work with SQL Server 2000 Enterprise or Developer edition and have more than 4 gigabytes (GB) of physical memory.
Because SQL Server 2000 can support up to a maximum of 64 gigabytes (GB) of physical memory, you can purchase the appropriate server box and get all advantages of it hardware platform.
Use the DBCC INDEXDEFRAG statement to defragment clustered and secondary indexes of the specified table or view.
DBCC INDEXDEFRAG statement is an online operation. Unlike DBCC DBREINDEX, DBCC INDEXDEFRAG does not hold locks long term and thus will not block running queries or updates. So, try to use the DBCC INDEXDEFRAG command instead of DBCC DBREINDEX, whenever possible.
You can use INSTEAD OF triggers to perform enhance integrity checks on the data values.
The INSTEAD OF trigger is a new SQL Server 2000 feature. These triggers can be used to enforce business rules when constraints cannot be used.

Note. Because triggers are more resource expensive, use constrains instead of triggers, whenever possible.

SQL Server 6.5 Optimization Tips

Set a reasonable size of your database.
Because SQL Server 6.5 database cannot automatically grow, you should estimate how big the database will be. To estimate the reasonable database size, you should previous estimate the size of each table individually, and then add the values obtained.
Set a reasonable size for the transaction log.
Because SQL Server 6.5 transaction log cannot automatically grow, you should estimate how big the transaction log will be. The general rule of thumb for setting the transaction log size is to set it to 20-25 percent of the database size. The less the size of your database, the greater the size of the transaction log should be, and vice versa. For example, if the estimation database size is equal to 10Mb, you can set the size of the transaction log to 4-5Mb, but if the estimation database size is over 500Mb, the 50Mb can be enough for the size of the transaction log.
You can place a database device on a raw partition.
It can increase the speed of your queries and modify operations on 20 percents and more.
Move tempdb database on its own database device to simplify administering and monitoring.
This is the description:
1. Create new device with appropriate size (tempdb_dev for example).
2. Uncheck "Default device" option for the master database device (this option is enable for the master database device by default).
3. Set "Default device" option for the tempdb_dev device.
4. From the Enterprise Manager (or sp_configure) set tempdb to be in RAM (set value to 1).
5. Stop and restart MSSQLServer service.
6. From the Enterprise Manager (or sp_configure) set tempdb to not be in RAM (set value to 0).
7. Stop and restart MSSQLServer service.
You can put the tempdb database to be in RAM.
If your queries contain subqueries, or GROUP BY, or ORDER BY clause, you can increase their performance by placing the tempdb database into RAM.
Create separate device for the transaction log.
In SQL Server 6.5, any database (except the master database) can span multiple devices. If you want to ensure recoverability and reduce contention, you should place the transaction log on a separate device.
For heavily accessed table with text/image columns place this table on a one device and place text/image columns on a different device on separate physical disks.
It can be useful to simplify administering and monitoring.
Place a table on one physical device and its nonclustered indexes on a different physical device.
This will improve performance, because separate threads will be created to access the tables and indexes.
Split a large, heavily-used table across database devices on two separate disk controllers.
This will improve performance, because when a table is accessed sequentially, a separate thread is created for each physical device on each disk array in order to read the table's data in parallel.
Create separate physical device and place some tables in it to run maintenance tasks (backups, DBCC, update statistics, and so on) against these tables.
You can group user objects with similar maintenance requirements into the same physical device. It can be useful to simplify administering and monitoring.
If you have several physical disk arrays, try to create as many physical devices as there are physical disk arrays so that you have one physical device per disk array.
This will improve performance, because when a table is accessed sequentially, a separate thread is created for each physical device on each disk array in order to read the table's data in parallel.
You can backup and restore a single table.
It can be used to improve the speed of backup process and decrease the backup size. In SQL Server 7.0 and higher, the LOAD TABLE statement is no longer supported.
If you create default constraint for some fields, you should define these fields as NOT NULL.
It can be used to store storage space.

Place all nullable fields to the end of the fields list (after fields with fixed length), so than more often this field will contain NULL value, the closer to the end of the record it should be placed.
It can be used to store storage space.
If you use OR logical operation to find rows from a MS SQL 6.5 table, and there is index on the field for which values you use OR operation, then you can improve performance by writing two queries and combine their result sets by using the UNION ALL statement.
If you use OR logical operation to find rows from a MS SQL 6.5 table, and there is index on the field for which values you use OR operation, then MS SQL 6.5 can use worktable with dynamic index on searchable field instead simple index search. So, if the table is very big, it can take a lot of time. You can increase the speed of this query by divide it into to select statement and union this statements with UNION ALL operator. For each query the appropriate index will be used, and this way can increase the speed of the new select statement in several times in comparison with the first one.

Analysis Services optimization tips

You can use the Usage-Based Optimization Wizard to optimize partition performance based on the history of queries previously sent to the cube.
To run the Usage-Based Optimization Wizard run Analysis Manager, right-click the appropriate cube and choose 'Usage-Based Optimization', then complete the steps in the wizard.
Try to separate the OLTP server with the OLAP server if these servers very hard used by many users.
In this case, placing the OLAP server on its own dedicated server can boost the overall performance of the queries.
Note. When you use HOLAP or ROLAP cubes, placing cubes on a dedicated server can decrease performance if the data warehouse and Analysis Services will be connected via slow link.
Try to use the MOLAP or HOLAP cubes instead of the ROLAP cubes, if you have enough amount of disk space.
The MOLAP and HOLAP cubes provide batter performance in comparison with ROLAP cubes, but can use more disk space to store the cube's data.
Set the 'read only' data warehouse database option to true.
This can reduce the time needed to process the cube and increase the speed of queries against the data.
If the data warehouse database is a read only database, you can create as many indexes as needed to for your Analysis Services queries.
If all of your Analysis Services queries are covered by the indexes, only indexes will be used to get the queries data, and the overall performance of these queries will be greatly maximized.
Create all indexes in the data warehouse database with a 'fill factor' option of 100.
Using a 'fill factor' option of 100 ensures that the index pages will be as full as possible. This can increase the speed of queries and reduce the amount of space used to store the index data.
Make a cube process during periods of low users activity.
Because a cube process can take much time, this operation should be scheduled during CPU idle time and slow production periods.
Declare the foreign key relationships between the fact table and the dimension tables and create the indexes for every foreign key in the dimension tables.
This can greatly maximize the overall performance of the queries against the indexed data.
Increase the level of aggregation for your cubes to boost the performance of the Analysis Services queries.
The larger the level of cube's aggregation will be, the faster the queries will be executed, but the more amount of disk space will be used and the more time it will take to process the cube. So, you should make some monitoring to get the best value for the level of aggregation for your cubes.
Consider placing cubes on their own server to distribute the load, if these cubes are large and very busy.
Placing each cube on its own dedicated server can distribute the workload among these servers and boost the overall performance.
If your OLAP server does not have CPU bottleneck, try to increase the "Maximum number of threads" Analysis Services option.
By default, the "Maximum number of threads" value is equal to two times the number of CPUs in the server computer. If you decide to increase this value, run System Monitor to check that there is no CPU bottleneck. To increase the "Maximum number of threads" option, run Analysis Manager, right-click the server name and choose 'Properties', then go to the 'Environment' tab.
If you have a dedicated server for Analysis Services, increase the "Minimum allocated memory" Analysis Services option.
By default, the "Minimum allocated memory" value is equal to one-half of the server computer's memory. Because allocation memory takes some time, if you will increase this value, you can avoid frequently automatic memory allocation. To increase the "Minimum allocated memory" option, run Analysis Manager, right-click the server name and choose 'Properties', then go to the 'Environment' tab.
If the OLAP server has a lot of RAM, increase the "Read-ahead buffer size" Analysis Services option.
This option indicates the maximum amount of data placed into memory during each read of the database. The larger this value will be, the less disk read operation will be required to read the cube's data. The default value is 4 Mb. Try to increase this value to 8 Mb and continue monitoring. To increase the "Read-ahead buffer size" option, run Analysis Manager, right-click the server name and choose 'Properties', then go to the 'Processing' tab.
If the OLAP server has a lot of RAM, increase the "Process buffer size" Analysis Services option.
This option indicates how much data is processed in memory before an I/O is performed. The larger this value will be, the fewer the I/O operations will be required. The default value is 4 Mb. Try to increase this value to 8 Mb and continue monitoring. To increase the "Process buffer size" option, run Analysis Manager, right-click the server name and choose 'Properties', then go to the 'Processing' tab.
If you install Analysis Services for SQL Server 2000 Enterprise Edition, you can create multiple partitions in a cube.
Using multiple partitions allows the source data and aggregate data of a cube to be distributed among multiple server computers. This can boost performance, because the workload will be distributed across multiple I/O devices.

*****

Anil

Sunday, November 29, 2009

SQL Server 2000 Optimization Tips

Application Design Optimization Tips

Backup/Restore Optimization Tips

Bulk Copy Optimization Tips

Cursor Optimization Tips

DTS Optimization Tips

Index Optimization Tips

File/Filegroups Optimization Tips

Full-Text Search Optimization Tips

SQL Server Settings Optimization Tips

Database Settings Optimization Tips

Operation System Optimization Tips

Optimization tips for designing tables

Transact-SQL Optimization Tips

Miscellaneous Optimization Tips

Replication Optimization Tips

Stored Procedures Optimization Tips

SQL Server 2000 Optimization Tips

SQL Server 6.5 Optimization Tips

Analysis Services optimization tips

No comments:

Post a Comment

About Me

Blog Archive

Followers