Title: SQL Server 2005 Architecture

Product: SQL Server 2005

Category: Optimization
Date: Nov 08, 2009 @ 7:51pm

Issue

To help troubleshoot and optimize SQL Server 2005 is to understand its Architecture and tap into the
designer's mind vision.

Summary

 Components of the SQL Server 2005 EngineÂ

• 4 Major components

o 1. Protocol,

o 2. Relational Engine, also called Query Processor,

o 3. Storage Engine, and the

o 4. SQLOS

 Observing Engine Behaviour (DMV, DMF)

Details

Components of the SQL Server Engine

• Protocol

The protocol layer receives the requests and translates it into a form the relational engine can work
with

Also takes the final results of any queries, status messages, or error messages, and translate and send
it back to the client.

• Relational Engine(also called Query Processor)

Accepts SQL batches and determines what to do with them.

For T-SQL queries, it parses, compiles, and optimizes the request and oversees the process of
executing the batch. As the batch is executed, if data is needed, a request for the data is passed to
the storage engine.

• Storage Engine
Manages all data access, both through transaction-based commands and bulk operations such as
backup, bulk insert, and certain DBCC (Database Consistency Checker) commands.

• SQLOS

Handles activities that normally considered to be operating system responsibilities, such as thread
management (scheduling), synchronization primitives, deadlock detection, and memory management,
including buffer pool.

Observing Engine Behavior

DMV and DMF

• Metadata objects in new sys schema to observe internals of SQL Server

• Not real objects, Not based on real tables, but are based on internal server structures

• Similar to pseudo-tables used in SQL Server 2000,

 o they do not provide tracking of detailed resource usage

o not always directly usable to detect resource history

 sysprocesses - observing active process

 syscacheobjects - content of the plan cache

• Allow tracking of detailed query resource history

• Can be use for diagnostics, memory and process tuning, and monitoring across all sessions in
the server

Categories are based on functional area of the information they expose. All exists in sys schema,
name starts with
"dm_" + "code indicating the area of the server"

• dm_exec_*

o Related to execution of user code and associated connections

• dm_os_*

o Low level system information such as memory, locking, and scheduling

• dm_tran_*

o Detail about current transactions

• dm_io_*

o Keeps track of input/output activity on network and disks

• dm_db_*

o Contains details about databases and database objects such as indexes

Protocol

• The API exposed by the protocol layer formats the communication using Microsoft-defined
format called Tabular Data Stream (TDS) packet.Â

• There are .NET-Libraries on both the server and the client computers that encapsulate the TDS
packet inside a standard communication protocol such as TCP/IP, or Named Pipes

o On the Server Side, the .NET-Libraries are part of the Database Engine

o On the Client Side, the .NET-Libraries are part of the SQL Native Client
 • The configuration of the client and the instance of SQL Server determine which protocol is used

o SQL Server can be configure to support multiple protocols simultaneously, coming from
different clients

o Each client connects with single protocol, if client program does not know which protocol
SQL Server listening on, you can configure the client to attempt multiple protocols
sequentially

• (1) Shared Memory

o The simplest, no configurable settings

o Client can connect to SQL instance running on the same computer

o Use this protocol for troubleshooting when you suspect that the other protocol are
configured incorrectly

o Client using MDAC 2.8 or earlier cannot use Shared Memory protocol, if such connection is
attempted, client is switched to Named Pipe protocol

• (2) Named Pipes

o Develop for LAN, portion of memory is used by one process to pass information to another
process so that the output of one is the input of the other

 The second process can be local, or remote

• (3) TCP/IP

o Most widely use protocol over the Internet

o Communicates across interconnected networks

o It includes standards for routing network traffic

• (4) VIA

o works for VIA hardware, specialized protocol, details are available from hardware vendor.

Tabular Data Stream Endpoints

• New concept in SQL Server 2005 for defining connection

• Connection is represented on the server end by a TDS endpoint

o During setup, SQL Server creates an endpoint for each of the four NET-Library protocols
supported by SQL
 o If protocol is enable, all users have access to it.

o For disabled protocols, the endpoints still exists but cannot be used

o Additional endpoint is created for DAC (Dedicated Administrator Connection)

 Can be used only by members of sysadmin fixed server role

Relational Engine (also called Query Processor)

• Determine what your query needs to do and the best way to do it

• The most complex component of Query Processor, and the entire SQL Server product, is the
Query Optimizer

o Query Optimizer determines the best execution plan for the queries in the batch

• Relational Engine also manages the execution of queries, as it request data from the Storage
Engine and processes the results returned

• Communication between Relational Engine and Storage Engine is generally in terms of OLE DB
row sets

o Row set is the OLE DB term for a result set

• The storage Engine comprises the component needed to actually access and modify data on disk

Query Process / Relational Engine Components

1. Command Parser

2. Query Optimizer

3. SQL Manager

4. Database Manager

5. Query Executor

Command Parser

• Handles T-SQL language events sent to SQL Server.

• Checks for proper syntax

 o Syntax error is immediately raised that identify where the error is

o Non-syntax error cannot be explicit about the exact source line that cause the error

• Translate TSQL into an internal format Query Tree

• Only command parser can access the source statement, the statement is no longer available in
source format when the command is actually executed.

Query Optimizer

• Takes the query tree from command parser and prepares it for execution

• Statement that cannot be optimized such as flow-of-control, DDL, are compiled into an internal
form

• Statement that are optimizable are marked and passed to the optimizer (SELECT, INSERT,
UPDATE, and DELETE)

• Optimizer determine which of the many possible ways is the best to process

• It compiles the entire command batch, optimizes queries that are optimizable, and checks
security

• Query optimization and compilation result in an Execution Plan.

• Steps in producing Execution Plan

o Normalize each query, breaks down single query into fine-grained queries

o Then it Optimize it, determines a plan for executing that query

 It is cost-based, optimizer chooses the plan that would cost the least based on
internal metrics

 Internal metrics includes memory requirements, CPU utilization, number of required

I/O

 Optimizer checks the amount of data in the various table affected, looks at the
indexes available

 Looks at a sampling of data values kept for each index or column, distribution
statistics.

 Optimizer considers various access methods and processing strategies, and

chooses the most cost-effective plan

 Optimizer also uses pruning heuristics, ensure that optimizing query doesn't take
longer, that it would take to simply choose a plan and execute it.
  Exhaustive optimization, in contrast, especially with complex queries, could
take much longer to estimate the cost of every conceivable plan, than to
accept a good plan, even if not the best one, and execute it.

o Normalized tree produced is compiled into the execution plan, which is actually a data
structure

 Each command included specifies exactly which table, indexes (if any), security
checks, which criteria to evaluate, constraints are checked

 Steps for calling triggers are slightly different with verifying constraints, specific
steps for triggers are NOT compiled into the execution plan, unlike those for
constraint verification

 If trigger is included for action being taken, a call to the procedure that
comprises the trigger is appended

 Instead-of trigger, replaces the actual data modification command

 After trigger, the trigger plan is branched to the right after the plan for the
modification statement that fired the trigger, before the modification is
committed

 Simple steps with multiple constraints can result in an execution plan that requires
many other tables to also be accessed or expressions to be evaluated

SQL Manager

• Managing stored procedure and plans

• Determines when a stored procedure needs recompilation, and it manages the caching of
procedure plans, so other procedure can reuse them

• Also handles autoparameterization of queries

o In SQL 2005, certain kinds of ad hoc queries are treated as if they were parameterized
stored procedure, and query plans are generated and saved for them

Database Manager

• Handles access to the metadata needed for query compilation and optimization

o Making clear that none of these separate modules can be run completely separately from
the others

• The metadata is stored as data and is managed by the storage engine

• Metadata elements such as datatypes of columns, and the available indexes on a table be
available during the query compilation and optimization phase, before actual query execution
 starts

Query Executor

• Runs the execution plan that the optimizer produce, acting as a dispatcher for all the commands
in the execution plan

• Steps through each command in the execution plan until the batch is complete

• Most of the command requires interaction with the storage engine to modify or retrieve data and
to manage transaction and locking

Storage Engine

• All components involved with he actual processing of data

• SQL Server 2005 separates some of these components into module called the SQLOS

• The storage team engine at Microsoft encompasses three areas:

o Access Method

o Transaction Management

o SQLOS

Access Method

• When SQL Server needs to locate data, it calls the access method code.

o Its employed not only for queries (SELECT), but also for qualified updates and deletes, and
for any data modification operations that need to modify index entries.

• Set up and requests scans of data pages and index pages and prepares the OLE DB row sets to
return to the relational engine

• When data is to be inserted, it receives OLE DB row set from the client

• Constraints components to open table, retrieve qualified data, and update data

• It doesn't actually retrieve the pages; it makes request to the buffer manager, which
ultimately serves up the page in its cache or reads it to cache from disk, retrieving of rows that
meets criteria, known as qualified retrieval.

o Row and Index Operations

 Access Method carried out the actual method of access

 Manipulates and maintains respective on-disk data structures, rows of data, B-tree
indexes

 Row operations code retrieves, modifies, and performs operations on individual

rows, or columns, row is found and appropriately locked as part of a transaction

 After formatting or modifying row in memory, the row operations code

inserts or deletes a row

 For LOB, text, image, or ntext, or if row is too large to fit on a single page,
needs to be stored as overflow data

 Index operations, maintains and supports searches on B-tree

 An index is structured as a tree (Root page, intermediate-level, and lower-

level or branches page)

 A B-tree groups records that have similar index keys, allow fast access to
data by key value

 The B-tree core is its ability to balance the index tree

 Branches are spliced or split apart as necessary, so search for a record

always traverse the same number of levels and therefore requires same
number of page accesses.

o Page Allocation Operations

 Manages collection of pages, keeps tracks which is in used and for what purpose,
and how much available space on each page

 Each database is a collection of 8-Kb disk pages that are spread across one or more
physical files

 SQL Server uses 8 types disk pages

 1. data pages

 2. LOB pages

 3. index pages
  4. PFS pages (Page Free Space)

 5. GAM and SGAM pages (Global Allocation Map and Shared GAM)

 6. IAM pages (Index Allocation Map)

 7. BCM pages (Bulk Changed Map)

 8. DCM pages (Differential Changed Map)

 All user data is stored on data or LOB pages

 All index rows are stored on index pages

 PFS pages keeps track of which pages in a database are available to hold new data

 Allocation pages (GAMs, SGAMs, and IAMs) keep track of the other pages, they
contain no database row, and used only internally

 BCM and DCM are used to make backup and recovery more efficiently

o Versioning Operations

 New in SQL Server 2005 is access through the version store

 Row Versioning allows SQL Server to maintain older version of changed rows

 It supports snapshot isolation, online index builds and triggers

Transaction Services

• Core feature of SQL Server is its ability to ensure that transactions are atomic -- all or nothing.

• Transaction must be durable -- if transaction has been commited, it is recoverable by SQL no

matter what, even if a total system failure occurs 1 ms after the commit was acknowledge

• Transaction properties ACID (atomicity, consistency, isolation, and durability)

• If works is in progress and system failure occurs before the transaction is commited, all the work
is rolled back to the state it exists before the transaction

• Write-ahead logging, makes it possible to always roll back work in progress or roll forward
commited work that has not yet been applied to the data pages.

o It ensure that record of each transaction's changes are captured on disk in the transaction
log before a transaction is acknowledge as committed

o Log records are always written to disk before the data pages where the changes are
actually made are written
 o Writes to transaction log are always synchronous, SQL Server must wait for them to
complete

o Writes to Data Pages can be asynchronous, because all the effects can be reconstructed
from the log if necessary.

• Coordinates logging, recovery, and buffer management

• Delineates the boundaries of statements that must be grouped together to form an operation

• It handles transaction that cross databases within the same SQL Server instance, and it allows
nested transaction sequence

o Nested transactions simply execute in the context of the first-level transaction, no special
action occurs when they are commited

o A rollback that is specified in a lower level of a nested transaction, undoes the entire
transaction

• For distributed transaction to another SQL Server instance, it coordinates with MS DTC (Microsoft
Distributed Transaction Coordinator) using operating system remote procedure calls

• The transaction mgnt component marks save points - points you designate within a transaction
at which work can be partialy rolled back or undone.

• It also coordinates with the locking code when locks can be released, based on the isolation level

o Isolation level determines how sensitive your application is to changes made by others
and consequently how long your transaction must hold locks or to maintain version data
to protect against those changes

• It alsow coordinates with the versioning code to determine when old version are no longer
needed and can be removed

• from the version store

• SQL Server 2005 support 2 concurrency model for guaranteeing the ACID properties of
transactions

o Pessimistic Concurrency

 Guarantess correctness and consistency by locking data so that it cannot be

changed, use by earlier version of SQL Server

o Optimistic Concurrency

 SQL Server 2005 introduced this

 Provides consistent data by keeping older versions of rows with commited values in
 an area of tempdb called the version store

 Readers will not block writers, writers will not block readers

 But writers still block writers

 The cost of these non-blocking reads and writes must be considered

 To support optimistic concurrency, SQL Server needs to spend more time

managing the version store

 Administrator needs to pay close attention to the tempdb database, and

extra maintenance it requires

• Five isolation level are available in SQL Server 2005, 3 of them support only Pessimistic
Concurrency:

o Read Uncommitted (also called "dirty read")

o Repeatable Read

o Serializable

o Snapshot Isolation Level, supports optimistic concurency

o Read Commited, default, can support either optimistic or pessimistic, depending on

database setting

• The behaviour of transaction depends on the isolation level and the concurrency model you are
working with

o Complete understanding of isolation levels also requires an understanding of locking

• Locking Operations

o Crucial function of a multi-user database

o SQL Server lets you manage multi-users simultenously and ensures that the transactions
observe the properties of the chosen isolation level

o Writers do requires lock and can still block other writers, even in a snapshot isolation level

o The locking code acquiresand releases varous types of locks

 Share Lock for reading

 Exclusive Lock for writing

 Intent Lock taken at higher granularity to signal a potential "plan" to perform some
 operation

 Extent locks for space allocation

o It manages compatibilty between the lock types

o Resolves deadlocks

o Escalate locks if needed

o Locking code contrls table, pages, and row locks, as well as system data locks

o Concurrency, with locks or row version, developers needs to be aware, because of impact
to application performance

• Other Operations

o This includes components for controlling utilities

 Bulk load

 DBCC commands

 Backup and restore operations

o Components to control sorting operations and to physically manage files and backup
devices on disk

o Log manager, ensure that log records are written in a manner that guarantee transaction
durability and recoverability

o Buffer Manager, component that manages the distribution of pages within the buffer
pool.

SQLOS

• SQL Server component for managing memory, scheduler, synchronization objects, IO

management, framework for locking and transaction management, deadlock detection, general
 utilities for dumping, exception handling

• Services that need OS access, its like an operating system inside SQL Server

• set of data structures and APIs needed by operations running at any layer of the engine

NUMA architecture (Non-Uniform Memory Access)

• main benefit is scalability, SQL Server is NUMA aware

• SQL Server allows you to subdivide one or more physical NUMA nodes into smaller NUMA nodes,
refer to as software NUMAor soft-NUMA, allows for subdividing CPU but not memory

o Only SQL Server scheduler and SQL Server Network Interaface (SNI) are soft-NUMA aware

o Memory nodes are created based on hardware NUMA, and are not affected by soft-NUMA

• TCP/IP, VIA, Named Pipes, and shared memory can take advantage of NUMA round-robin
scheduling, but only TCP and VIA can affinitize to a specific set of NUMA nodes

• Trend in hardware, to have more than one system bus, each serving small set of CPU

o NUMA limits the number of CPU on any one memory bus

o Each group of processors has its own memory and possibly its own I/O channel, each
group is called a NUMA node, and the nodes are connected to each other by means of
high speed interconnection

o Number of CPU within the NUMA node depends on the hardware vendor

• It is faster to access local memory than the memory associated with other NUMA nodes

• SMP (symmetric multiprocessing) architecture, all memory access is posted in same memory
bus

o Works fine for relatively small number of CPU

o Problem appears if you have many CPU competing for access to the shared memory bus

The Scheduler
You can think of SQL Server scheduler as a logical CPU used by SQL Server workers

• In SQL Server 2005, each actual CPU has a scheduler created for it when SQL Server starts up

o Either set to Online of Offline based on the affinity mask setting

o The default is all scheduler are Online

o Setting the affinity mask can set scheduler status to Offline, without restarting SQL Server
  Any worker assigned to the scheduler is first completed and no new work is
assigned

• Prior to SQL Server 7.0, scheduling was entirely dependent on underlying Windows operating
system

o Window scheduler knew nothing about the needs of a relational database system

o it treated SQL Server worker threads same as any other process running

o SQL Server scheduler runs as cooperative rather than pre-emptive scheduler

 It relies on worker threads or fibers to voluntarily yeild often enough so one process
doesn't have exclusive control of the system

o Much greater control and scalability than it is possible with the Windows generic
scheduler

• High performance system such as SQL Server function best when the scheduler needs its special
needs

• A private scheduler could support SQL Server task using fibers, as well as threads

• Context switching and switching into kernel mode could be avoided as much as possible

• Scheduler in SQL 7.0 and 2000 was called User Mode Scheduler (UMS), primarily run on user
mode

• SQL Server 2005 calls its scheduler SOS Scheduler, and improves on UMS

• SQL Server Workers

o Workers are created when the scheduler receives a requests (a task to execute)

o There are no idle workers, a worker can be destroyed if idle for 15 minutes, or if SQL
Server is under memory pressure

o Each worker can use 512 Kb (half Mb) of memory on 32-bit, and at least 2Â Mb on a 64-bit
system

 So destroying multiple workers and freeing their memory can yeild an immediate
performance improvement on memory starved system

o SQL Server handles worker pool very efficiently, even on large systems with multiple
users

o A worker can either be a thread or a fiber that is bound to a logical scheduler

 o If Affinity Mask Configuration option is set, each scheduler is affinitize to a particular CPU

o Each worker is associated with a single CPU

o Each scheduler is assigned a worker limit based on the configured Max Worker Threads

o Each scheduler is responsible for creating or destroying workers as needed

o A worker cannot move from one scheduler to another

 But as worker are destroyed or created, it can appears as if workers are moving
between schedulers

• SQL Server Tasks

o A unit of work for SQL Server worker is a request, or a task

o Which you can think of an equivalent to a single batch sent from the client to the server

o Once a request is sent, it is bound to a worker, the the worker processes the entire
requests before handling any other requests

 Holds true even when the request is blocked, such as while wait for a lock or for I/O
to complete

o SPID (sessionID) is not the same as task

 SPID is a connection or a channel over which requests can be sent

 There is not always an active requests on any particular SPID

 In SQL 2000, each SPID is assigned to a scheduler when an initial connection is

made, and all request sent to the same SPID are handled by the same scheduler

 The assignment of SPID to a scheduler is based on the number of SPID

already assigned to the scheduler

 New SPID is assigned to schduler with fewest user

 In SQL 2005, a SPID is no longer bound to a particular scheduler

 Each SPID has a preferred scheduler, which is the scheduler that most
recently processed a requests from the SPID, which initially assigned to
scheduler with lowest load

 dm_os_schedulers, look at load factor on each scheduler

 When subsequent requests are sent from the same SPID, the new task is
given to scheduler with lowest load factor
  There is a restriction that all tasks for one SPID must be processed by
scheduler on the same NUMA node.

 Exception is when query is being executed as a parallel query across

multiple CPUs

 Optimizer can decide to use more CPU that are available on the NUMA
node processing the query, so other CPU (and other schedulers) can
be used

• Threads vs. Fiber

o User Mode Scheduler, was design to work with workers running either threads or fiber

o Windows fiber

 Less overhead, and multiple fiber can run on a single thread

 You can configure SQL Server to run in fiber mode by setting Lightweight Pooling
option to 1

 Fiber mode was actually intended for special niche situation in which SQL Server
reaches a limit in scalability due to spending too much time switching between
threads contexts or switching between user mode and kernel mode

 In most environments, the performance gained by fibers is quite small compared to

benefits of tuning in other areas

o Certain components of SQL Server don't work well when run in fiber mode

 SQL Mail and SQL XML, CLR queries needs certain thread-specific facilities provided
by Windows

o Although it is possible for SQL Server to switch to thread mode to process requests that
need it, the overhead might be greater than the overhead of using threads exclusively

• NUMA and Schedulers

o With NUMA configuration, every node has some subset of machine's processor and the
same number of schedulers

o When a machine is configure for hardware NUMA, each node has the same number of
processors

 For soft-NUMA, you can assign different numbers of processors for each node

 There will still be the same number of schedulers as processors

 o When SPID are first created, they are assigned to node on a round-robin basis

 The scheduler monitor then assigns the SPID to the least loaded scheduler on that
node

 If SPID is moved to another scheduler, it stays on the same node

 A single processor or SMP machine will be treated as a machine with a single NUMA
node

 There is no hard mapping between schedulers and a CPU with NUMA

 So any scheduler on an individual node can run on any CPU on that node

 If Affinity Mask Configuration option, each scheduler on each node will be

fixed to run on a particular CPU

o Every NUMA node has its own lazywritter, own Resource Monitor, which are managed by
hidden scheduler

 Resource Monitor has its own SPID, can be query via sys.dm_exec_requests and
sys.dm_os_workers

o Every node has its own Scheduler Monitor, which can run on any SPID and runs on a
preemptive mode

 It checks the health of the other schedulers to help them balance their workload

o Every node also has its own I/O Completion Port (IOCP) which is the network listener

• Dynamic Affinity

o In SQL 2005 processor affinity can be controlled dynamically

o When SQL Server starts up, all scheduler tasks are started on server startup, so there is
one scheduler per CPU

o If affinity mask has been set, some of the schedulers are then marked offline, and no task
are assigned to them

o When affinity mask is changed to include additonal CPU, the new CPU is brought online

 The Scheduler Monitor notices an imbalance workload, and starts picking workers
to move to the new CPU

o When CPU is brought offline, the scheduler continues to run active workers

 But the scheduler itself is moved to noe of the other CPU that is not offline
  No new workers is given to this scheduler, and when all active workers finished
their tasks, the scheduler stops

• Binding Schedulers to CPU

o Normally schedulers are not bound to CPU in a strict one-to-one relationship

o The scheduler is bound to a CPU only when the affinity mask is set

 This is true even when you set the affinity mask to use all the CPUs which is the
default

o Default affinity mask value is 0, to use all CPUs with no hard binding of scheduler to CPU

o In some cases when there is a heavy load on the machine, Windows can run two
schedulers on one CPU

o Example

 For an eight processor machine, an affinity mask value of 3 (bit string 00000011)
means that only CPUs 0 and 1 will be used and two schedulers will be bound to the
two CPUs

 255 (bit string 11111111), all CPUs will be used, just like the default

 However with affinity mask set, the eight CPU will be bound to the eight
schedulers

o In some situation, you might want to limit the number of CPU available but not bind a
particular scheduler to a single CPU

 You can start SQL Server with traceflag 8002, lets CPU mapped to an instance, but
within the instance, the schedulers are not bound to a CPU

• Observing Scheduler Internals

o DMV that provides information about the scheduler, work, and tasks

o It requires a View Server State permission, by default only Administrator has the
permission

 sys.dm_os_schedulers

 Returns one row per scheduler, each scheduler is mapped to individual

processor

 Use this view to monitor the condition of a scheduler, or to identify runaway

tasks
  sys.dm_os_workers

 returns a row for every worker in the system

 sys.dm_os_threads

 list of all SQLOS threads running under the SQL Server process

 sys.dm_os_tasks

 returns one row for each tasks that is active in the instance of SQL Server

 sys.dm_os_waiting_tasks

 returns information about the queue of tasks that are waiting on some
resource

• DAC (Dedicated Administrator Connection)

o Under a complete lack of available resources, it is possible for SQL Server to enter an
abnormal state, in which no further connection can be made

 In SQL 2000, this means this situation means that an administrator cannot get in to
kill any troublesome connection or even begin to diagnose the possible cause of the
problem

o DAC is a special connection that is designed to be accessible even when no other access
can be made

 You can connect via SQLCMD /AÂ -- this method is recommended becuase it uses
fewer resources that GUI, but offers more functionality than other command line
tools, such as osql

 Through SSMS, you can specify connecting using DAC by preceeding the name of
your SQL Server with ADMIN:

 ADMIN:Server\SQL2005InstanceName

o DAC is a special-purpose connection designed for diagnosing problems in SQL Server,

possibly resolving them

o It is not meant to use as a regular user connection

o Any attempt to connect using DAC when there is already an existing DAC will result in an
error

-- to check whether a DAC is in use

SELECT t2.session_id
FROM sys.tcp_endpoints as t1

JOIN sys.dm_exec_sessions as t2 ON t1.endpoint_id = t2.endpoint_id

WHERE t1.name='Dedicated Admin Connection'

GO

o By default, DAC is available only locally

 an administrator can configure to allow remote connection by using the

configuration option, Remote Admin Connection

o User must be a member of SYSADMIN server role

o Few restrictions on the SQL statements that can be executed on the DAC

 Backup and Restore cannot be run in DAC

 It is recommended you do not run any resource-intensive queries to aggrevate the

problem

o DAC connection is created primarily for troubleshooting and diagnostic purposes

o In general, you use DAC to run DMV queries

o A special thread is assigned to the DAC that allows you to execute diagnostic functions or
queries on a separate scheduler.

o This thread cannot be terminated, you can kill only the DAC session if needed

o DAC scheduler always uses scheduler_id 255, and this thread has the highest priority

o There is no lazywriter thead for the DAC, but DAC has its own IOCP, a worker thread, and
an idle thread

Memory

• Determine whether memory is being managed well on your system

• Describe the aspects of memory management you can control over so you can understand when
to exert that control

• By default, SQL 2005 manages its memory resources almost completely dynamically

• When allocating memory, SQL communicate constantly with OS, thats why SQLOS layer of the
engine is so important

• Buffer Pool and the Data Cache

 o Main memory component in SQL Server is the buffer pool

o All memory not used by memory component remains in the buffer pool

o Used as a data cache for pages read in from the database files on disk

o Buffer Manager manages disk I/O functions for bringing data and index pages into the
data cache so data can be shared among users

o When other components require memory, they can requests a buffer from the buffer pool

 Buffer is a page in memory that is the same size as data or index pages

 You can think of it as a page frame that can hold one page from a database

o Most of buffer taken from the buffer pool for other memory components go to other kinds
of memory caches, largest of which typically the cache for procedure and query plans,
called procedure cache.

• Access to In-Memory Data Pages

o Access to pages in the data cache must be fast

 Even with real memory, it would be ridiculously inefficient to scan the whole data
cache for a page when you have gigabytes of data

o Pages in data cache are therefore hashed for fast access.

 Hashing is a technique that uniformly maps a key via hash function accross a set of
hash buckets.

 Hash table is a structure in memory that contains array of pointers (linked list) to
the buffer pages

 If all pionter to buffer pages do not fit a single hash page, a linked list chains to
additional hash pages.

 dbid-fileno-pageno identifier, hash function converts the key to hash bucket that
should be checked

 By using hashing, SQL Server can find a specific data page in cache with only a few
memory reads

 Similarly, it takes few memory reads for SQL to determine desired page is
not in cache and it must be read in from disk.

• Managing Pages in the Data Cache

o Keeping a supply of buffers available for immediate use is an important performance

 optimization

 If buffer isnt readily available, many memory pages might have to be searched to
locate a buffer to free up for use as a workspace

o You can use data page or index page only if it exists in memory

 Buffer in data cache must be available for the page to be read into

o SQL Server 2005 maintain a linked list of the addresses of free pages, and any worker
needing a buffer page uses the first page of this list

o Every buffer in the data cache maintains the last two times the page was referenced,
whether the page is dirty

 The reference information is used to implement a replacement policy of the data

cache page, algorithm called LRU-K (Least Recently Used)

o Dirty Page, paged in memory that has been changed since it was read from disk.

o Data cache is periodically scanned from the start to the end, these scans are quick, its all
in memory, and require no I/O

 Value is associated with each buffer on its usage history

 When usage is low, dirty page indicator is checked

 A write is scheduled to write the modification on disk

 Instance of SQL Server uses write-ahead log, so the write of the dirty data page is
blocked while the log page recording the modification is first written to disk.

 After the modified page has been flushed to disk, or page was not dirty, the
page is freed

 Association between buffer page and data page it contains is removed, and
buffer is put to the free list

o Buffer holding pages considered more valuable remain in the active buffer pool

 Buffer not referenced often enough eventually return to the free buffer list

o The work of scanning the buffer, writing dirty pages, and populating the free buffer lis is
primarly performed by the individual workers after they have scheduled an aynchronous
read, and before the read is complete.

o SQL Server also has the lazywriter thread for each NUMA node, that scans through the
buffer cache associated with that node
  Lazywriter threads sleeps for a specific interval of time

 It wakes up, it examines the size of the free buffer list, if below certain threshold,
depending on the size of the buffer pool, it scans and repopulates the free list.

 As the buffer are added to the free list, they are also written to disk if they are dirty

o SQL Server uses memory dynamically, it must constantly be aware of the amount of free
memory

 Lazywriter for each node queries system periodically to determine amount of free
physical memory available

 Lazywriter, expands or shrinks the data cache, to keep OS free memory at 5

Mb +/- 200 Kb to prevent paging, if less lazywriter releases memory to OS,
instead of adding it to the free list

 If more than 5 Mb, the lazywriter recommits memory to the buffer pool by
adding it to the free list

o SQL Server releases memory to OS if it detects that too much paging is taking place

 Pinning a table option of sp_tableoption has no effect to SQL 2005, no way to force
a table's page to stay in cache

• Checkpoints

o Checkpoint process also scans the buffer cache periodically, and writes any dirty page for
a particular database to disk

 Difference between checkpoint and lazywriter (or the worker thread's management
of pages)

 Checkpoint process never puts buffers on the free lists

 Purpose of checkpoint is only to ensure that pages written before a certain time are
written to disk, so the number of dirty pages memory is always kept to a minimum

 Ensures that the lenght of time SQL Server requires for recovery of a database after
a failure is kept to a minimum

o When checkpoint occurs, SQL Server writes a checkpoint record to the transaction log,
which list all the transaction that are active

 Allows the recovery process to build a table containing a list of all the potentially
dirty pages

o Checkpoints occur automatically at regular intervals but can also be requested manually
  A database owner explicitly trigger a checkpoint, using CHECKPOINT command

 Log is getting 70% capacity, and database is SIMPLE, it triggers to truncate the
transaction log and free up space

 If no space can be free up, due to long running transaction, no checkpoint

occurs

 A long recovery time is estimated, longer than "Recory Interval" configuration,

default to 1 min

 If checkpoint are taken at least as often as the recovery interval frequency,

recovery completes within the interval.Â

 A minimum amount of work must be done for the automatic checkpoint to

fire, currently 10 Mb of log per minute

 This way SQL doesn't waste time taking checkpoints on idle databases

 Default of 0 means SQL chooses an appropriate value, for current

version this is 1 minute

 An orderly shutdown of SQL Server is requested, without NOWAIT option. An

orderly shutdown occurs when you explicityly shut down SQL Server, or when the
service is stopped through Service Control Manager.

 sp_configure Recovery Interval influence checkpoint frequency, balancing the time

to recover vs. any impact on run-time performance

 Trace Flag 3502, writes SQL Server error log every time a checkpoint occur

o Checkpoint process goes through the buffer pool, scanning the pages non-sequentially,
and when it finds a dirty page, it looks to see whether any physical contiguous pages are
also dirty, so it can do a large block write.

 It might for example write buffers 14, 200, 260, 1000, if it sees buffer 14 is dirty,
the non-contiguous pages in the buffer pool can be written as a single operation,
called gather-write. Process continous to scan buffer pool until it gets to page
1000.Â

 In some cases, an already written page could potentially be dirty again, and it
might need to be written out to disk a second time

o The larger the buffer pool, the greater the chance that a buffer that has already be written
can be dirty again before the checkpoint is done.

 To avoid this, SQL uses its associated with each buffer called a generation number,
bits are toggle to same value 0 or 1, when a checkpoint come to a page that is
 already toggle, ti doesnt write that page.

 Any new page brought into cache during checkpoint get new generation number so
they won't be written during the checkpiont cycle.

• Managing Memory in Other Caches

o Buffer pool memory that isn't used for the data cache is used for other types of caches,
primarily the procedure cache, which holds plan for all types of queries, not just procedure
plan

o SQL Server introduces a new common caching framework that is leverage by all caches
except the data cache

 Resource Governor

 Three types of stores, both cache and user uses LRU mechanism, for page
replacement policy

 cache store - (procedure cache)

 user stores -Â (metadata cache)

 object stores - (pool of memory block that don't use LRU or costing, network
buffers)

o LRU mechanism variation of clock algorithm

 Clock hand sweeping through the store, looking at every entry, as it touches each
entry, it decreases the cost, when it reaches 0, entry can be removed from the
cache. Cost is reset whenever an entry is reused.

 Cost taking into account memory usage, I/O, CPU require to generate the entry
initially.

o Memory management take into account both Global and Local memory management
policies

 Global policies consider the total memory on the system and enable the running of
the clock algorithm accross all the caches. (External Clock Hand)

 Local policies involve looking at one store or cache in isolation, making sure it is not
using a disproportionate amoung of memory. (Internal Clock Hand)

 SQL Server stores implement two hands, external and internal. Each store has
two hands, you can observe it in sys.dm_os_memory_cache_clock_hands

 Resource Monitor is in charge of moving the external hands whenever it notices

 memory pressure.

 There are many types of memory pressure, you may take a look at
sys.dm_os_memory_cache_clock_hands, specifically the removed_last_round_count
column, larger value if increase dramaticaly is strong indication of memory
pressure.

 Internal clock moves whenever the individual cache needs to be trimmed. SQL
Server attempts to keep each cache reasonably sized compared to other caches.Â

 Internal clocks moves only in response to activity, if a worker running the

task that access the cache notices a high number of entries in the cache,
internal clock starts to free up memory for that cache.

o Memory Broker

 Microsoft introduces Memory Broker because memory is needed by so many

components in SQL Server, to make sure each component uses memory efficiently.

 Memory Broker analyze the behaviour of SQL Server with respect to memory
consumption and to improve dynamic memory distribution.

 It is a centralized mechanism that dynamically distribute memory between

buffer pool, query executor, query optimizer, and all various caches

 Adapts its distribution algorithm for different type of workloads

 Its a control mechanism with feedback loop

 It monitors memory demand and consumption by component, calculate

optimal distribution of memory accross all components.

 It can broadcast information to the component, which uses the information to

adapt its memory usage.

 /*

Ring Buffer is updated only when the Memory Broker

wants the behaviour of a given component to change

that is, to grow shrink, or remain stable

*/

SELECT * FROM sys.dm_os_ring_buffers

WHERE ring_buffer_type = 'RING_BUFFER_MEMORY_BROKER'

GO

• Sizing Memory

o SQL memory is more than just the buffer pool. It is organized into three sections, and
the buffer pool is usually the largest and most frequently used.

o Buffer pool is a set of 8-Kb buffers, so any memory needed in chunks larger than 8-Kb is
managed separately.

o If SQL instance is configure to use AWE, although measure as part of buffer pool, it must
be kept track of separately because only data cache pages can use AWE memory, non of
other memory components such as plan cache can use AWE memory.

 If AWE is enable, the only way to get information about SQL Server's actual memory
consumption is by using SQL Server specific DMV inside the server; you wont get
information from OS-level performance counter.

o
/*

the column multi_pages_kb that shows

how much space is used by a memory component

outside the buffer pool.

*/
SELECT type, sum(multi_pages_kb) sum_multi_pages_kb

FROM sys.dm_os_memory_clerks

WHERE multi_pages_kb != 0

GROUP BY type

ORDER BY sum(multi_pages_kb) DESC

GO
• Sizing the Buffer Pool

o When SQL starts up, it computes the size of VAS (virtual address space) of SQL Server
process

 Each process running on Windows has its own VAS

 VAS is a set of addresses available for process,

 On 32-bit can directly address 4 Gb by default, Windows reserves the top 2 Gb for
its own use, so only the remaining 2 Gb for any application, such as SQL Server,
you can increase by enabling /3GB in boot ini

 The only way a 32-bit to go beyond 2 Gb is by enabling AWE

 Memory allocated through AWE are considred locked pages and can never be
swapped.

 It is recommended not to enable Lock Pages in Memory policy if you are not
using AWE, in 32 bit, although SQL will ignore this option, other processes on
the system may be impacted.

 On 64 bit, AWE enabled but setting is ignored. However the Lock Pages in
Memory option is available, although disabled by default. This policy determines
which account can make use of a Windows feature to keep data in physical
memory, preventing paging to virtual memory disk.Â

 It is recommended to enable this policy on a 64 bit system

 In addition to VAS size, SQL also calculates Target Memory, which is the number of
 8-Kb pages it expects to be able to allocate.

 If Max Server Memory is set, and Target Memory is less, Target Memory is
recomputed periodically.

 A decrease in number of target pages on a normal load indicate a response

to external physical memory pressure.

o DMV sys.dm_os_sys_info, contains one row of general purpose SQL Server configuration.

o Â

/* ----------------------------------------------------------

physical_memory_in_bytes - Amount of physical Memory Available

----------------------------------------------------------

virtual_memory_in_bytes - amount of virtual memory available to

process in user mode. You can use this value whether SQL

is started in /3gb switch

----------------------------------------------------------

bpool_committed - total number of buffers with pages that have

associated in memory. This does not include virtual memory

----------------------------------------------------------

bpool_commit_target - optimum number of buffers in the buffer pool.

----------------------------------------------------------

bpool_visible - number of 8-Kb that are directly accessible in the process

virtual address space

When using AWE, when buffer pool obtain its memory target

bpool_commited = bpool_commit_target

When using AWE on 32-bit, bpool_visible represent the size of the

AWE mapping windows used to access physical memory allocated by buffer pool.

bpool_visible < bpool_commited, because the size of this mapping

window is bound by the process address space, and can further reduce

by internal component consuming memory for purposes other than

database pages.

If value bpool_visible is too low, you might receive

out of memory error.

*/

SELECT * FROM sys.dm_os_sys_info

GO

• Observing Memory Internals

o sdfsda

• NUMA and Memory

o asdf

• Read-Ahead