Rob's SQL Server Blog : 2005

SQL Server 2005 Multi-Site Clustering with Windows Server 2008

robcarrol — Mon, 16 Mar 2009 01:12:00 GMT

I was working recently with a customer who was looking to deploy a SQL Server 2005 cluster across 2 geographically dispersed sites using Windows Server 2008. They were looking to utilise the new clustering improvements in Windows Server 2008 to build a highly available SQL Server solution. The customer required automatic failover between the sites in the event of a disaster, but their current solution required manual intervention by an administrator in order to failover to the disaster recovery site. Automatic failover would increase application availability, and reduce the complexity of the solution. Each site has it's own SAN storage and the customer planned to replicate data between each site using SRDF replication.

This led me to do further research into clustering SQL Server in this type of environment. Windows Server 2008 introduces greater flexibility in the choice of Quorum configuration. The concept of quorum moves away from the requirement of a shared storage resource, but now refers to the number of votes needed to establish a majority. All nodes and a witness resource can get a vote, which removes the disk as the single point of failure as in previous clustering models. The 4 Quorum Models available are:

Node and Disk Majority
Disk Only
Node Majority
Node and File Share Majority

As there is no shared storage between the nodes in a multi-site cluster, 2 of these Quorum models are suitable for multi-site clustering: Node Majority and Node and File Share Majority. Node and Disk Majority and Disk Only should only be used in a multi-site cluster if specifically directed by your storage vendor as your disk replication software needs to support these configurations.

Node and File Share Majority:

This allows the creation of up to 16 nodes with no shared disks. A file share acts as a witness, meaning that a 2 node cluster will have have 3 votes, so connectivity can be lost by either one of the nodes or the witness and the cluster can still continue to function.

A cluster quorum configured to use a node-and-file-share majority is a great solution for multi-site clusters. The file share witness can reside at a third site independent of either site hosting a cluster node for high disaster resilience. A single file server can serve as a witness to multiple clusters (with each cluster using a separate file share witness on the file server).

This configuration gives the highest resilience as the cluster can automatically recover from the loss of any one site without manual intervention.

The File Share Witness (FSW) needs to be in the sane forest as the nodes and be running Windows Server 2003 or Windows Server 2008. For maximum resilience, it is best to locate the FSW at a 3rd site separate from the cluster nodes. The FSW does not need to be attached to shared storage and should NOT be a node in the same cluster.

Node Majority:

A node-majority cluster consists of 3 or more nodes without shared storage. Each of the nodes has a vote and there is no shared disk vote. A majority of votes are necessary to operate the cluster if 2 nodes fail in a 3 node cluster, then the remaining node drops out of the cluster. An administrator can manually over-ride this and force the remaining node to start. When the other nodes come back, majority quorum is achieved again and the cluster comes back online seamlessly.

This configuration works best with an odd number of cluster nodes as it is not enough to have half the cluster nodes functioning in this model. If four nodes were set up in a node-majority configuration, the cluster would continue to operate with the loss of one node but not with the loss of two nodes. You should use an odd number of nodes with Node Majority as 4 nodes can only survive 1 failure, which is the same as 3 nodes.

The node-majority quorum configuration can work when there is more than one cluster node at each site. Consider a multi-site cluster consisting of five nodes, three of which reside at Site A and the remaining two at Site B. With a break in connectivity between the two sites, Site A can still communicate with three nodes (which is greater than 50 percent of the total), so all of the nodes at Site A stay up. The nodes in Site B are able to communicate with each other, but no one else. Since the two nodes at Site B cannot communicate with the majority, they drop out of cluster membership. (Were Site A is to go down in this case, in order to bring up the cluster at Site B, it would require manual intervention to override the non-majority.)

As a result, the Node Majority configuration does not give automatic failover between sites as nodes 4 and 5 cannot achieve quorum. In this situation, you would need to manually force a failover.

SQL Server Networking Considerations:

Windows Server 2008 now allows nodes in the same cluster to reside in different network subnets and communicate across network routers. However, be aware that SQL Server 2005 and 2008 still require all cluster nodes to reside in the same network subnet, so you will still need to set up virtual local area networks (VLANs) to connect geographically separated cluster nodes. This can have some benefits with regard to client response times though, as DNS replication may impact client re-connection times in the event of a failover from one site to another. VLAN's allow DNS names to stay the same, so can increase availability.

Storage Considerations:

As there is no shared storage between the nodes in a multi-site cluster, the main consideration is how to keep the data replicated between the sites. The choice of 3rd-party replication solution is important and can have a major effect on how you deploy your cluster. As such, you should work closely with your storage vendor from an early stage in the design process.

Synchronous replication results in no data loss, but requires shorter distances between nodes and higher bandwidth to avoid write latency from impacting performance. Asynchronous allows you to stretch cluster nodes across longer distances, however there is a potential for data loss in the event of a failure. Asynchronous data replication also assumes a large enough network bandwidth to keep up with data changes and does not significantly impact application performance.

Conclusion:

As data replication is key in a multi-site SQL Server cluster, work with your storage vendor from an early stage to ensure they support your cluster configuration. Multi-site clustering allows you to achieve high availability and disaster recovery, however it can be a costly and complex solution. You should evaluate your business requirements first and then decide on the best technology to meet these. It could be the case that Database Mirroring, for example, could be used to give you the required level of resilience across geographical sites.

In this case, the customer chose to implement a 2-node, 3-site solution using the Node and File Share Majority quorum model, with a File Share Witness located in the 3rd site. This gives site-level resilience in the event of a disaster and also allows automatic failover between the cluster nodes without having to re-write client applications, meeting the business requirements.

Additional Resources:

Windows Server 2008 Multi-Site Clustering Whitepaper

TechNet Webcast: Geographically Dispersed Failover Clustering in Windows Server 2008

TechNet Webcast: Failover Clustering and Quorum in Windows Server 2008 Enterprise

Support Webcast: Microsoft SQL Server 2005 Failover Clustering on Windows Server 2008

How to: Create a New SQL Server 2005 Failover Cluster (Setup)

Updated: Support Policy for SQL Server on Virtualised Platforms

robcarrol — Wed, 08 Oct 2008 18:48:00 GMT

The support policy for SQL Server running on virtualised platforms has now been updated to include support for SQL Server 2005 running on Hyper-V

http://support.microsoft.com/?id=956893

Microsoft provides technical support for SQL Server 2005 and for SQL Server 2008 that are running in the following hardware virtualization environments:

Windows Server 2008 with Hyper-V
Microsoft Hyper-V Server 2008
Configurations that are certified through the Server Virtualization Validation Program (SVVP) http://windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm

Any non-Microsoft virtualization software that is not a validated configuration through the SVVP program will be handled under the policy in the following KB article:

http://support.microsoft.com/kb/897615/

The following restrictions apply to support for SQL Server products in any hardware virtualization environment:

Guest Failover Clustering is not supported in a virtual machine.
The virtual machine must be running an operating system that is supported for the specific SQL Server version and edition and that is supported for virtualization
The SQL Server product must be a supported version under its current Microsoft Support Lifecycle policy http://support.microsoft.com/?pr=lifecycle

SQL Server 2005 Performance Dashboard

robcarrol — Thu, 12 Jun 2008 14:25:00 GMT

I've had one or two requests recently to set up the Performance Dashboard reports on SQL Server so I've created this blog post to step through the process. Firstly, the Performance Dashboard was created to allow customers and support engineers to monitor the general performance characteristics of a server and investigate the cause of any performance problems that may occur. The goal of the Performance Dashboard is to reduce the time spent discovering the problem so effort can be focused on actually resolving it.

The SQL Server 2005 Performance Dashboard Reports are available as a link off the SP2 Feature Pack (Feb 2007). The Performance Dashboard reports are built on the SQL Server 2005 dynamic management views, accessing data that is already captured by SQL Server 2005. Consequently there is no performance impact of using the dashboard except when you actually open/refresh a report. This allows engineers and customers to go much further on a performance problem while the problem is happening. The Performance Dashboard requires SQL Server 2005 SP2 or later.

Install the Dashboard by running the msi from the link above, which will install to a default location of Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard. After setup finishes, open Management Studio and connect to the server and run the SETUP.SQL script (once for each SQL instance you want to monitor). Then from Object Explorer select the server, right mouse click and choose Reports – Custom Reports and browse to find the PERFORMANCE_DASHBOARD_MAIN.RDL file. This report is the only report intended to be directly loaded from SSMS; all other reports are accessed as a drill through off of the main report. The help file, PERFDASH.CHM has details about setup and permission requirements, how each report is accessed, details about the general methodology used in the dashboard and how you can use/interpret the information on each individual report.

Support Webcast: Microsoft SQL Server 2005 Failover Clustering on Windows Server 2008

robcarrol — Mon, 19 May 2008 22:53:00 GMT

A new Level 300 support webcast has been scheduled for Monday the 9th of June, 10:00 AM Pacific Time. The summary of the session is as follows:

This Support WebCast focuses on how to plan, implement, and administer a Microsoft SQL Server 2005 failover cluster on Windows Server 2008. This session provides step-by-step instructions about how to install SQL Server 2005 clustered instance on a Windows Server 2008 cluster. It also discusses the options you can use to move SQL Server 2005 failover cluster from Windows Server 2003 to Windows Server 2008.

http://support.microsoft.com/default.aspx?scid=kb;en-us;953170&sd=rss&spid=2855

SQL Server Locking

robcarrol — Sun, 18 May 2008 10:30:00 GMT

Locking is a mechanism used by the Microsoft SQL Server Database Engine to synchronize access by multiple users to the same piece of data at the same time.

Before a transaction acquires a dependency on the current state of a piece of data, such as by reading or modifying the data, it must protect itself from the effects of another transaction modifying the same data. The transaction does this by requesting a lock on the piece of data. Locks have different modes, such as shared or exclusive. The lock mode defines the level of dependency the transaction has on the data. No transaction can be granted a lock that would conflict with the mode of a lock already granted on that data to another transaction. If a transaction requests a lock mode that conflicts with a lock that has already been granted on the same data, the instance of the Database Engine will pause the requesting transaction until the first lock is released.

When a transaction modifies a piece of data, it holds the lock protecting the modification until the end of the transaction. How long a transaction holds the locks acquired to protect read operations depends on the transaction isolation level setting. All locks held by a transaction are released when the transaction completes (either commits or rolls back).

Applications do not typically request locks directly. Locks are managed internally by a part of the Database Engine called the lock manager. When an instance of the Database Engine processes a Transact-SQL statement, the Database Engine query processor determines which resources are to be accessed. The query processor determines what types of locks are required to protect each resource based on the type of access and the transaction isolation level setting. The query processor then requests the appropriate locks from the lock manager. The lock manager grants the locks if there are no conflicting locks held by other transactions.

TRANSACTION ISOLATION LEVEL

Controls the locking and row versioning behavior of Transact-SQL statements issued by a connection to SQL Server. There are 5 levels:

READ UNCOMMITTED:

Statements can read rows that have been modified by other transactions but not yet committed.

READ COMMITTED:

Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

REPEATABLE READ:

Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes.

SNAPSHOT:

Specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of the transaction.

SERIALIZABLE:

Statements cannot read data that has been modified but not yet committed by other transactions. No other transactions can modify data that has been read by the current transaction until the current transaction completes. Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

More details on all the transaction isolation modes can be found here in Books Online

Lock Granularity and Hierarchies

Locking at a smaller granularity, such as rows, increases concurrency but has a higher overhead because more locks must be held if many rows are locked. Locking at a larger granularity, such as tables, are expensive in terms of concurrency because locking an entire table restricts access to any part of the table by other transactions. However, it has a lower overhead because fewer locks are being maintained.

The following table shows the resources that the Database Engine can lock.

Resource	Description
RID	A row identifier used to lock a single row within a heap.
KEY	A row lock within an index used to protect key ranges in serializable transactions.
PAGE	An 8-kilobyte (KB) page in a database, such as data or index pages.
EXTENT	A contiguous group of eight pages, such as data or index pages.
HOBT	A heap or B-tree. A lock protecting an index or the heap of data pages in a table that does not have a clustered index.
TABLE	The entire table, including all data and indexes.
FILE	A database file.
APPLICATION	An application-specified resource.
METADATA	Metadata locks.
ALLOCATION_UNIT	An allocation unit.
DATABASE	The entire database.

Lock Modes

The Microsoft SQL Server Database Engine locks resources using different lock modes that determine how the resources can be accessed by concurrent transactions.

The following table shows the resource lock modes that the Database Engine uses.

Lock mode	Description
Shared (S)	Used for read operations that do not change or update data, such as a SELECT statement.
Update (U)	Used on resources that can be updated. Prevents a common form of deadlock that occurs when multiple sessions are reading, locking, and potentially updating resources later.
Exclusive (X)	Used for data-modification operations, such as INSERT, UPDATE, or DELETE. Ensures that multiple updates cannot be made to the same resource at the same time.
Intent	Used to establish a lock hierarchy. The types of intent locks are: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX).
Schema	Used when an operation dependent on the schema of a table is executing. The types of schema locks are: schema modification (Sch-M) and schema stability (Sch-S).
Bulk Update (BU)	Used when bulk copying data into a table and the TABLOCK hint is specified.
Key-range	Protects the range of rows read by a query when using the serializable transaction isolation level. Ensures that other transactions cannot insert rows that would qualify for the queries of the serializable transaction if the queries were run again.

Full details of SQL Server's lock modes can be found in this article.

Lock Compatibility (Database Engine)

Multiple transactions can acquire concurrent locks on the same resource if their lock modes are compatible. If a transaction requests a lock mode that conflicts with an existing lock, the transaction is paused until the first lock is freed. For a full list of lock mode compatibilty see this article

Key-Range Locking

Key-range locks protect a range of rows implicitly included in a record set being read by a Transact-SQL statement while using the serializable transaction isolation level. The serializable isolation level requires that any query executed during a transaction must obtain the same set of rows every time it is executed during the transaction. A key range lock protects this requirement by preventing other transactions from inserting new rows whose keys would fall in the range of keys read by the serializable transaction.

Key-range locking prevents phantom reads. By protecting the ranges of keys between rows, it also prevents phantom insertions into a set of records accessed by a transaction.

A key-range lock is placed on an index, specifying a beginning and ending key value. This lock blocks any attempt to insert, update, or delete any row with a key value that falls in the range because those operations would first have to acquire a lock on the index. For example, a serializable transaction could issue a SELECT statement that reads all rows whose key values are between 'AAA' and 'CZZ'. A key-range lock on the key values in the range from 'AAA' to 'CZZ' prevents other transactions from inserting rows with key values anywhere in that range, such as 'ADG', 'BBD', or 'CAL'.

More details can be found in Books Online here

Lock Escalation

Lock escalation is the process of converting many fine-grain locks into fewer coarse-grain locks, reducing system overhead while increasing the probability of concurrency contention. See the Lock Escalation (Database Engine) chapter on BOL for full details

Dynamic Locking

The Microsoft SQL Server Database Engine uses a dynamic locking strategy to determine the most cost-effective locks. The Database Engine automatically determines what locks are most appropriate when the query is executed, based on the characteristics of the schema and query. For example, to reduce the overhead of locking, the optimizer may choose page-level locks in an index when performing an index scan.

Dynamic locking has the following advantages:

Simplified database administration. Database administrators do not have to adjust lock escalation thresholds
Increased performance. The Database Engine minimizes system overhead by using locks appropriate to the task
Application developers can concentrate on development. The Database Engine adjusts locking automatically

Displaying Locking Information (Database Engine)

Microsoft SQL Server 2005 provides several ways to get information about the current locking activity in an instance of the Database Engine.

Deadlocking

A deadlock occurs when two or more tasks permanently block each other by each task having a lock on a resource which the other tasks are trying to lock. Both transactions in a deadlock will wait forever unless the deadlock is broken by an external process. More information on deadlocks and techniques to avoid them can be found in BOL.

SQL Server Statistics

robcarrol — Fri, 16 May 2008 11:00:00 GMT

SQL Server 2005 collects statistical information about indexes and column data stored in the database. These statistics are used by the SQL Server query optimizer to choose the most efficient plan for retrieving or updating data. Good statistics allow the optimizer to accurately assess the cost of different query plans, and choose a high-quality plan. All information about a single statistics object is stored in several columns of a single row in the sysindexes table, and in a statistics binary large object (statblob) kept in an internal-only table. In addition, information about statistics can be found in the metadata views sys.stats and sys.indexes

Statistics Used by the Query Optimizer in Microsoft SQL Server 2005

SQL Server 2005 has the ability to automatically create and update statistics. This feature is on by default in SQL Server 2005 and SQL Server 2000. This allows the SQL Server 2005 query optimizer to produce good query plans consistently, while keeping development and administration costs low. If you need more control over statistics creation and update to get good query plans and manage the overhead of gathering statistics, you can use manual statistics creation and update capabilities.

SQL Server 2005 statistics features allow you to:

Implicitly create and update statistics with the default sampling rate (in the SELECT, INSERT, DELETE, and UPDATE commands, use of a column in a query condition such as a WHERE or JOIN clause causes statistics to be created or updated if necessary when automatic statistics creation and update is enabled)
Manually create and update statistics with any desired sampling rate, and drop statistics (CREATE STATISTICS, UPDATE STATISTICS, DROP STATISTICS, CREATE INDEX, DROP INDEX)
Manually create statistics in bulk for all columns of all tables in a database (sp_createstats)
Manually update all existing statistics in the database (sp_updatestats)
List statistics objects that exist for a table or database (sp_helpstats, catalog views sys.stats, sys.stats_columns)
Display descriptive information about statisticsobjects (DBCC SHOW_STATISTICS)
Enable and disable automatic creation and update of statistics database-wide or for a specific table or statistics object (ALTER DATABASE options AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS, sp_autostats, and the NORECOMPUTE option on CREATE STATISTICS and UPDATE STATISTICS)
Enable and disable asynchronous automatic update ofstatistics (ALTER DATABASE option AUTO_UPDATE_STATISTICS_ASYNC)

SQL Server Management Studio allows you to graphically browse and control statistics objects within its Object Explorer view. Statistics are listed in Object Explorer in a folder underneath each table object.

SQL Server 2005 maintains the following information at the table level.

Number of rows in the table or index (rows column in sys.sysindexes).
Number of pages occupied by the table or index (dpages column in sys.sysindexes).

SQL Server 2005 collects the following statistics about table columns and stores them in a statistics object (statblob):

Time the statistics were collected.
Number of rows used to produce the histogram and density information
Average key length.
Single-column histogram, including the number of steps.
A string summary, if the column contains character data. DBCC SHOW_STATISTICS output contains a column "String Index" which has the value YES if a statistics object contains a string summary.

Use sp_helpindex and sp_helpstats to display the list of all statistics available for a given table. sp_helpindex lists all indexes on the table, and sp_helpstats lists all the statistics on the table. Each index also carries the statistical information for its columns. The statistical information created using the CREATE STATISTICS command is equivalent to the statistics built by a CREATE INDEX command on the same columns. The only difference is that the CREATE STATISTICS command uses sampling by default while the CREATE INDEX command gathers the statistics with fullscan since it has to process all rows for the index anyway.

Creating Statistics with SQL Server 2005

You can create statistics in SQL Server 2005 in a number of different ways, as described below.

• The optimizer automatically creates single-column statistics as needed as a side effect of optimizing SELECT, INSERT, UPDATE, and DELETE statements when AUTO_CREATE_STATISTICS is enabled, which is the default setting.

• CREATE INDEX generates the declared index in the first place, and also creates one set of statistics for the column combinations constituting the index keys (but not other included columns). CREATE STATISTICS only generates the statistics for a given column or combination of columns.

• Use sp_createstats to create statistics for all eligible columns (all except XML columns) for all user tables in the current database. A new statistics object will not be created for columns that already have a statistics object.

• Use dbcc dbreindex to rebuild one or more indexes for a table in the specified database.

• In Management Studio, expand the folder under a Table object, right click the Statistics folder, and choose New Statistics.

• Use the Database Tuning Advisor (DTA) to create indexes.

Here is an example of a CREATE STATISTICS command on the AdventureWorks.Person.Contact table:

CREATE STATISTICS FirstLast2 ON Person.Contact(FirstName,LastName)
WITH SAMPLE 50 PERCENT

Usually, statistics with default sampling are sufficient to allow good query plans to be produced. However, there may be cases when statistics with larger sample sizes may benefit query optimization, such as when the values in the given column sample are not random. Non-random samples may occur if the data is sorted or clustered. Sorting or clustering may be caused by the creation of indexes, or loading data into a heap structure that is already sorted or clustered. The most commonly used larger sample size is fullscan because it gives the most accurate statistics. The price for using statistics with larger sample sizes is the time required to create the statistics.

The above command creates a single two-column statistics object. In this case, the SAMPLE 50 PERCENT is ignored and a full scan is performed because the table is too small. Sampling is used primarily to avoid excessive scans of data and affects only tables and indices with 1,024 or more pages (8 MB).

In SQL Server 2005, statistics are created for all indices at the index creation time. SQL Server creates single-column statistics automatically when compiling queries. These statistics are created for columns where the optimizer would otherwise have to estimate the approximate density or distribution. There are the following exceptions to this rule. Statistics may not be created automatically when (1) the database is read-only, (2) there are too many outstanding compilations in progress, and (3) the column's data type is not supported for auto stats.

The automatic statistics creation function can be disabled at the database level by executing

ALTER DATABASE dbname SET AUTO_CREATE_STATISTICS OFF

It's recommended that you leave this setting ON. Only disable it if you need to do so to work around known performance issues, such as the need to specify other than the default sampling rate for some tables.

By default, statistics are created by sampling the data set when executing the CREATE STATISTICS command or when the statistics are automatically created. CREATE INDEX scans the whole data set anyway; therefore, the index statistics are initially created without sampling (the equivalent of fullscan). The CREATE STATISTICS command allows you to set the sample size in the WITH clause either by specifying fullscan or the percentage of data or number of rows to scan. It is also possible to inherit the previous sample size when specifying WITH RESAMPLE on the UPDATE STATISTICS command.

For small tables, a minimum of 8 MB of data is sampled. If a table starts small, and you sample with the default sampling rate, and thereafter use the resample option when updating the statistics, you will get the equivalent of fullscan even as the table grows beyond 8 MB. Avoid the use of resample if you want the default sampling rate as table size varies.

The dbcc show_statistics command displays the sample size under the Rows Sampled heading. Statistics created automatically, or updated automatically (as described in the next section) are always generated using default sampling. The default sampling rate is a slow-growing function of the table size, which allows statistics to be gathered relatively quickly even for very large tables.

SQL Server Profiler can monitor automatic statistics creation. The Auto Stats event is in the group of Performance trace events. Select also the IntegerData, Success and ObjectID columns for the Auto Stats event when defining the trace.

The DROP STATISTICS command is used to drop statistics, but it is not possible to drop statistics that are a byproduct of an index. Such statistics are removed only when the index is dropped.

Maintaining Statistics in SQL Server 2005

After a series of INSERTs, DELETEs, and/or UPDATEs are performed on a table, the statistics may not reflect the true data distribution in a given column or index. If the SQL Server query optimizer requires statistics for a particular column in a table that has undergone substantial update activity since the last time the statistics were created or updated, SQL Server automatically updates the statistics by sampling the column values (using auto update statistics). The statistics auto update is triggered by query optimization or by execution of a compiled plan, and involves only a subset of the columns referred to in the query. Statistics are updated before query compilation if AUTO_UPDATE_STATISTCS_ASYNC is OFF, and asynchronously if it is ON.

When a query is first compiled, if the optimizer needs a particular statistics object, and that statistics object exists, the statistics object is updated if it is out of date. When a query is executed and its plan is in the cache, the statistics the plan depends on are checked to see if they are out of date. If so, the plan is removed from the cache and during re-compilation of the query the statistics are updated. The plan also is removed from the cache if any of the statistics it depends on have changed.

SQL Server 2005 determines whether to update statistics based on changes to column modification counters (colmodctrs).

A statistics object is considered out of date in the following cases:

The table size has gone from 0 to >0 rows.
The number of rows in the table when the statistics were gathered was 500 or less, and the colmodctr of the leading column of the statistics object has changed by more than 500 since then
The table had more than 500 rows when the statistics were gathered, and the colmodctr of the leading column of the statistics object has changed by more than 500 + 20% of the number of rows in the table when the statistics were gathered

If the statistics object is defined on a temporary table, it is out of date as discussed above, except that there is an additional threshold for recomputation at 6 rows, with a test otherwise identical to test 2 in the previous list.

Table variables do not have statistics at all.

The auto update statistics feature described above may be turned off at different levels.

On the database level, disable auto update statistics using:

ALTER DATABASE dbname SET AUTO_UPDATE_STATISTICS OFF

At the table level, disable auto update statistics using the NORECOMPUTE option of the UPDATE STATISTICS command or CREATE STATISTICS command.
Use sp_autostats to display and change the auto update statistics setting for a table, index, or statistics object.

Re-enabling the automatic updating of statistics can be done similarly using ALTER DATABASE, UPDATE STATISTICS, or sp_autostats.

Auto statistics update is always performed by sampling the index or table using the default sampling rate. To set the sampling rate explicitly, run CREATE or UPDATE STATISTICS

Statistics update is covered by the same SQL Profiler event as statistics creation.

SQL Server and Windows Memory

robcarrol — Thu, 15 May 2008 17:02:00 GMT

SQL Server 2000 Enterprise Edition introduced support for the use of Windows 2000 Address Windowing Extensions (AWE) to address 8GB of memory on Windows 2000 Advanced Server and 32GB of memory on Windows 2000 Datacentre. With AWE, SQL Server can reserve memory not in use by other applications and the OS. Each instance must statically allocate the memory it needs. AWE memory can only be used for the data cache and not for executables, drivers, DLL's, etc.

SQL Server 2000 on Windows 2003/Windows 2000 Advanced Server/Windows 2000 Datacentre:

The use of /PAE and AWE allows SQL Server 2000 to use more than 4GB of RAM. Without /PAE, SQL can only use up to 3GB (with /3GB switch enabled in boot.ini). To allow AWE to use the the memory range above 16GB on Windows 2000 Datacentre, the /3GB switch must not be enabled in the server's boot.ini file. When you allocate SQL Server AWE memory on a 32GB system, Windows 2000 may require at least 1GB memory to manage AWE.

SQL Server 2000 Enterprise and Developer Editions are the only editions that can use AWE.

USING AWE MEMORY (SQL Server 2000)

Run the database engine under a Windows account with the "lock data pages in memory" option enabled. SQL Server setup will automatically grant this permission. If you start an instance from the command prompt (sqlservr.exe), you must manually assign this permission using gpedit.msc. Set the sp_configure option AWE ENABLED and restart SQL Server.

Instances of SQL Server 2000 do not dynamically manage the size of the address space when you enable AWE memory. When you enable AWE and start an instance of SQL 2000, one of the following occurs:

If sp_configure max server memory has been set and there are at least 3GB RAM free on the computer, the instance acquires the amount of memory specified in max server memory
If the amount of memory available is less than max server memory (but more than 3GB), then the instance acquires almost all of the available memory and may leave only up to 128MB of memory free
If max server memory has not been set and there is at least 3GB of free memory available, then the instance acquires almost all of the available memory and may leave only up to 128MB of memory free
If there is less than 3GB of free memory available, memory is dynamically allocated and, regardless of the parameter setting for AWE ENABLED, SQL Server will run in non-AWE mode

Evaluating Memory Usage

Use System Monitor to obtain the correct amount of SQL Server memory usage:

Total Server Memory (KB)
Select memory usage from sysperfinfo

Running Multiple instances with AWE on SQL Server 2000

Each instance must have a max server memory setting.

Sum of max server memory values for all instances should be less than the amount of physical memory on the server. If the sum greater, some of the instances will either not start or will have less memory than is specified in max server memory.

Windows 2000 Usage Considerations:

Before configuring Windows 2000 for AWE memory:

Add the /PAE switch to boot.ini
Add the /3GB switch to enable Windows 2000 Advanced Server and Windows 2000 Datacentre to support a 3GB virtual address space. This allows user applications to address 3 GB of virtual memory and reserves 1 GB of virtual memory for the operating system. However, if there is more than 16 GB of physical memory available on a computer, Windows 2000 needs 2 GB of virtual memory address space for system purposes and therefore can support only a 2-GB virtual address space.
In order to allow AWE to use the memory range above 16 GB, be sure the /3gb parameter is not in the boot.ini file. If it is, Windows 2000 will be unable to address any memory above 16 GB. When allocating SQL Server AWE memory on a 32-GB system, Windows 2000 may require at least 1 GB of available memory to manage AWE. Therefore, when starting an instance of SQL Server with AWE enabled, it is recommend you do not use the default max server memory setting, but instead limit it to 31 GB or less

Using Failover Clustering:

If you are using SQL Server 2000 failover clustering and AWE memory, you must ensure that the summed value of the max server memory settings for all the instances is less than the lowest amount of physical RAM available on any of the servers in the failover cluster. If the failover node has less physical memory than the original node, the instances of SQL Server 2000 may fail to start or may start with less memory than they had on the original node.

SQL SERVER 2005

To enable AWE for SQL Server 2005:

Run the SQL Server account under a Windows account with "Lock Pages in Memory" permissions assigned.
Use sp_configure to set "awe enabled" option to 1
The "Maximize Data Throughput for Network Application" in Control Panel must be selected.

Support for AWE is available only in the SQL Server 2005 Enterprise, Standard and developer editions and only applies to 32-bit OS's. SQL Server 2005 Analysis Services (SSAS) cannot take advantage of AWE mapped memory. If available physical memory is less than the user mode VAS, AWE cannot be used.

Lock pages in memory: Prevents paging the data to virtual memory or disk. Set to OFF by default in SQL Server 2005.

SQL Server 2005 Enterprise Edition can access up to 64GB of memory on Windows 2000 and Windows Server 2003.

Instances of SQL Server 2005 running on Windows 2000 use static AWE memory allocation, instances running on Windows Server 2003 use dynamic AWE memory allocation.

To support over 4GB of physical memory, the /PAE switch must be added to boot.ini file. If more than 16GB of physical memory, the OS needs 2GB of virtual address space for system purposes and can therefore support only a 2GB user mode virtual address space. Remove /3GB from boot.ini file in order to use this memory above 16GB.

The SQL Server buffer pool can fully utilise AWE mapped memory, however only database pages can be dynamically mapped to and unmapped from SQL Server's virtual address space and take full advantage of memory allocated through AWE.

AWE does not directly help supporting additional users, threads, databases, queries and other objects that permanently reside in the virtual address space.

SQL Server 2005 Features Comparison