SQL SERVER 

ARCHITECTURE
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
PAGES AND EXTENTS 
ARCHITECTURE
The  page  is  the  fundamental  unit  of  data  storage  in 
SQL Server. 

An extent is a collection of eight physically continuous  
pages. Extents help efficiently manage pages.
 TOPICS NEEDS TO BE COVERED

 Understanding pages and extents
 Managing Extent Allocations and Free Space

 Tracking Modified Extents
UNDERSTANDING PAGES AND EXTENTS
 PAGES
 In SQL Server, the page size is 8 KB. 
 SQL  Server  databases  have  128  pages  per 
megabyte. 
 Each  page  begins  with  a  96­byte  header  that  is 
used to store system information about the page. 
 This information includes the page number, page 
type,  the  amount  of  free  space  on  the  page,  and 
the allocation unit ID of the object that owns the 
page
 EXTENTS
Extents are the basic unit in which space is managed. An 
extent  is  eight  physically  continuous    pages,  or  64  KB. 
This means SQL Server databases have 16 extents per 
megabyte.
To  make  its  space  allocation  efficient,  SQL  Server  does 
not allocate whole extents to tables with small amounts 
of data. SQL Server has two types of extents: 
 Uniform extents are owned by a single object; all eight 
pages  in  the  extent  can  only  be  used  by  the  owning 
object.
 Mixed extents are shared by up to eight objects. Each of 
the  eight  pages  in  the  extent  can  be  owned  by  a 
different object.
 MANAGING EXTENT ALLOCATIONS 
AND FREE SPACE 
 GLOBAL APPLICATION MAP (GAM)

GAM  pages  record  what  extents  have  been 

allocated.  Each  GAM  covers  64,000  extents,  or 
almost  4  GB  of  data.  The  GAM  has  one  bit  for 
each extent in the interval it covers. If the bit is 
1,  the  extent  is  free;  if  the  bit  is  0,  the  extent  is 
allocated.
 SHARED GLOBAL APPLICATION MAP 
(SGAM)

SGAM  pages  record  which  extents  are  currently  being 

used  as  mixed  extents  and  also  have  at  least  one 
unused  page.  Each  SGAM  covers  64,000  extents,  or 
almost  4  GB  of  data.  The  SGAM  has  one  bit  for  each 
extent in the interval it covers. If the bit is 1, the extent 
is being used as a mixed extent and has a free page. If 
the bit is 0, the extent is not used as a mixed extent, or 
it is a mixed extent and all its pages are being used. 
 TRACKING FREE SPACE

A PFS page is the first page after the file header page in a 
data file (page number 1). This is followed by a GAM 
page (page number 2), and then an SGAM page (page 3). 
There is a PFS page approximately 8,000 pages in size 
after the first PFS page. There is another GAM page 
64,000 extents after the first GAM page on page 2, and 
another SGAM page 64,000 extents after the first 
SGAM page on page 3. The following illustration shows 
the sequence of pages used by the Database Engine to 
allocate and manage extents.
TRACKING MODIFIED EXTENTS
SQL  Server  uses  two  internal  data  structures  to 
track  extents  modified  by  bulk  copy  operations 
and extents modified since the last full backup. 

 Differential Changed Map (DCM)

 Bulk Changed Map (BCM)
 DIFFERENTIAL CHANGED MAP 
(DCM)
 This tracks the extents that have changed since the last 
BACKUP DATABASE statement. 
 If  the  bit  for  an  extent  is  1,  the  extent  has  been 
modified  since  the  last  BACKUP  DATABASE 
statement. 
 If the bit is 0, the extent has not been modified. 

 Differential  backups  read  just  the  DCM  pages  to 

determine which extents have been modified. 
 The  length  of  time  that  a  differential  backup  runs  is 
proportional  to  the  number  of  extents  modified  since 
the  last  BACKUP  DATABASE  statement  and  not  the 
overall size of the database.
 BULK CHANGED MAP (BCM) 
 This  tracks  the  extents  that  have  been  modified  by  bulk  logged 
operations since the last BACKUP LOG statement. 
 If the bit for an extent is 1, the extent has been modified by a bulk 
logged operation after the last BACKUP LOG statement. 
 If  the  bit  is  0,  the  extent  has  not  been  modified  by  bulk  logged 
operations. 
 In  this  recovery  model,  when  a  BACKUP  LOG  is  performed,  the 
backup process scans the BCMs for extents that have been modified. 
It then includes those extents in the log backup. 
 BCM  pages  are  not  relevant  in  a  database  that  is  using  the  simple 
recovery model, because no bulk logged operations are logged. 
 They  are  not  relevant  in  a  database  that  is  using  the  full  recovery 
model, because that recovery model treats bulk logged operations as 
fully logged operations. 
The  interval  between  DCM  pages  and  BCM  pages  is  the 
same  as  the  interval  between  GAM  and  SGAM  page, 
64,000  extents.  The  DCM  and  BCM  pages  are  located 
behind the GAM and SGAM pages in a physical file:
PAGES AND EXTENTS 
ARCHITECTURE

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
FILES AND FILEGROUPS 
ARCHITECTURE
 DATABASE FILES
 Primary data files: The primary data file is the 
starting point of the database and points to the other 
files in the database.. The recommended file name 
extension for primary data files is .mdf. 
 Secondary data files: Secondary data files make up 
all the data files, other than the primary data file. The 
recommended file name extension for secondary data 
files is .ndf. 
 Log files: Log files hold all the log information that is 
used to recover the database. The recommended file 
name extension for log files is .ldf. 
FILES AND FILEGROUPS 
ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
TRANSACTION LOG ARCHITECTURE
 TOPICS NEEDS TO BE COVERED

 Transaction Log Logical Architecture
 Transaction Log Physical Architecture

 Checkpoints and the Active Portion of the Log

 Write­Ahead Transaction Log
TRANSACTION LOG LOGICAL 
ARCHITECTURE
 Each  log  record  is  identified  by  a  log  sequence  number 
(LSN). 
 Log  records  are  stored  in  a  serial  sequence  as  they  are 
created
 Each  log  record  contains  the  ID  of  the  transaction  that  it 
belongs to
 Log  records  for  data  modifications  record  either  the  logical 
operation  performed  or  they  record  the  before  and  after 
images of the modified data. 
 Rollback operations are also logged

 Each  transaction  reserves  space  on  the  transaction  log  to 

make sure that enough log space exists to support a rollback 
that  is  caused  by  either  an  explicit  rollback  statement  or  if 
an error is encountered.
TRANSACTION LOG PHYSICAL 
ARCHITECTURE
 The  transaction  log  is  used  to  guarantee  the  data 
integrity of the database and for data recovery.
 The transaction log in a database maps over one or more 
physical  files.  Physically,  the  sequence  of  log  records  is 
stored  efficiently  in  the  set  of  physical  files  that 
implement the transaction log.
 The SQL Server Database Engine divides each physical 
log file internally into a number of virtual log files.
 The only time virtual log files affect system performance 
is  if  the  log  files  are  defined  by  small  size  and 
growth_increment values.
 The transaction log is a wrap­around file.
CHECKPOINTS AND THE ACTIVE PORTION 
OF THE LOG
Checkpoints flush dirty data pages from the buffer cache 
of  the  current  database  to  disk.  This  minimizes  the 
active portion of the log that must be processed during 
a  full  recovery  of  a  database.  During  a  full  recovery, 
the following types of actions are performed:

 The  log  records  of  modifications  not  flushed  to  disk 

before the system stopped are rolled forward.

 All  modifications  associated  with  incomplete 

transactions,  such  as  transactions  for  which  there  is 
no  COMMIT  or  ROLLBACK  log  record,  are  rolled 
back.
 ACTIVE LOG

The  section  of  the  log  file  from  the  MinLSN  (Minimum 
Recovery  LSN)  to  the  last­written  log  record  is  called 
the active portion of the log, or the active log. This is the 
section  of  the  log  required  to  do  a  full  recovery  of  the 
database.  No  part  of  the  active  log  can  ever  be 
truncated.  All  log  records  must  be  truncated  from  the 
parts of the log before the MinLSN.
 LONG­RUNNING TRANSACTIONS 
The  active  log  must  include  every  part  of  all 
uncommitted transactions. An application that starts a 
transaction  and  does  not  commit  it  or  roll  it  back 
prevents  the  Database  Engine  from  advancing  the 
MinLSN. This can cause two types of problems:

 If  the  system  is  shut  down  after  the  transaction  has  performed 
many  uncommitted  modifications,  the  recovery  phase  of  the 
subsequent  restart  can  take  much  longer  than  the  time  specified 
in the recovery interval option.

 The  log  might  grow  very  large,  because  the  log  cannot  be 
truncated  past  the  MinLSN.  This  occurs  even  if  the  database  is 
using  the  simple  recovery  model,  in  which  the  transaction  log  is 
generally truncated on each automatic checkpoint.
 REPLICATION TRANSACTIONS
The  Log  Reader  Agent  monitors  the  transaction  log  of 
each  database  configured  for  transactional  replication, 
and  it  copies  the  transactions  marked  for  replication 
from the transaction log into the distribution database. 
The  active  log  must  contain  all  transactions  that  are 
marked  for  replication,  but  that  have  not  yet  been 
delivered  to  the  distribution  database.  If  these 
transactions  are  not  replicated  in  a  timely  manner, 
they can prevent the truncation of the log. 
WRITE­AHEAD TRANSACTION LOG
SQL  Server  uses  a  write­ahead  log  (WAL),  which 
guarantees  that  no  data  modifications  are  written  to 
disk before the associated log record is written to disk. 
This maintains the ACID properties for a transaction.
To understand how the write­ahead log works, it is important for you to 
know how modified data is written to disk. SQL Server maintains a 
buffer  cache  into  which  it  reads  data  pages  when  data  must  be 
retrieved.  Data  modifications  are  not  made  directly  to  disk,  but  are 
made to the copy of the page in the buffer cache. The modification is 
not written to  disk until a checkpoint  occurs in the database, or the 
modification must be written to disk so the buffer can be used to hold 
a  new  page.  Writing  a  modified  data  page  from  the  buffer  cache  to 
disk is called flushing the page. A page modified in the cache, but not 
yet written to disk, is called a dirty page.
At the time a modification is made to a page in the buffer, a log record 
is built in the log cache that records the modification. This log record 
must  be  written  to  disk  before  the  associated  dirty  page  is  flushed 
from  the  buffer  cache  to  disk.  If  the  dirty  page  is  flushed  before  the 
log record is written, the dirty page creates a modification on the disk 
that  cannot  be  rolled  back  if  the  server  fails  before  the  log  record  is 
written to disk. SQL Server has logic that prevents a dirty page from 
being flushed before the associated log record is written. Log records 
are written to disk when the transactions are committed.
TRANSACTION LOG ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
 TABLE AND INDEX DATA 
STRUCTURES ARCHITECTURE 
       
 TOPICS NEEDS TO BE COVERED

 Table and Index Organization
 Heap Structures

 Clustered Index Structure

 Non­Clustered Index Structure
 Table and Index Organization

 A table is contained in one or more partitions and each partition contains data rows in
either a heap or a clustered index structure.
 Table and index pages are contained in one or more partitions. A partition is a user-
defined unit of data organization. By default, a table or index has only one partition that
contains all the table or index pages. The partition resides in a single filegroup.
 Clustered tables are tables that have a clustered index.
 Heaps are tables that have no clustered index.
 Nonclustered indexes have a B-tree index structure similar to the one in clustered
indexes.
 Heap Structures

 A  heap  is  a  table  without  a  clustered  index. 

Heaps  have  one  row  in  sys.partitions,  with 
index_id = 0 for each partition used by the heap
 Depending  on  the  data  types  in  the  heap,  each 
heap  structure  will  have  one  or  more  allocation 
units to store and manage the data for a specific 
partition
 Clustered Index Structure

 Indexes are organized as B­trees. Each page in an index B­tree is 
called an index node
 The top node of the B­tree is called the root node.
 The bottom level of nodes in the index is called the leaf nodes.
 Clustered  indexes  have  one  row  in  sys.partitions,  with  index_id 
=  1  for  each  partition  used  by  the  index.  By  default,  a  clustered 
index has a single partition. 
 Depending  on  the  data  types  in  the  clustered  index,  each 
clustered index structure will have one or more allocation units in 
which to store and manage the data for a specific partition. 
 The pages in the data chain and the rows in them are ordered on 
the value of the clustered index key.
 NON­CLUSTERED INDEX 
STRUCTURE
 Nonclustered indexes have the same B­tree structure as clustered indexes, 
except for the following significant differences: 
 The data rows of the underlying table are not sorted and stored in order 
based on their nonclustered keys.

 The leaf layer of a nonclustered index is made up of index pages instead 
of data pages.

 Nonclustered indexes have one row in sys.partitions with index_id >0 for 
each partition used by the index.
  By default, a nonclustered index has a single partition. 
 Depending on the data types in the nonclustered index, each nonclustered 
index structure will have one or more allocation units in which to store and 
manage the data for a specific partition.
TABLE AND INDEX DATA STRUCTURES 
ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
QUERY PROCESSING 
ARCHITECTURE 
 TOPICS NEEDS TO BE COVERED

 SQL Statement Processing
 Stored Procedure and Trigger Execution

 Execution Plan Caching and Reuse 
 SQL Statement Processing

 Processing a Select Statement
 Processing Other Statements
 PROCESSING A SELECT STATEMENT

 The parser scans the SELECT statement and breaks it into logical 
units such as keywords, expressions, operators, and identifiers.
 A  query  tree,  sometimes  referred  to  as  a  sequence  tree,  is  built 
describing  the  logical  steps  needed  to  transform  the  source  data 
into the format required by the result set.
 The query optimizer analyzes different ways the source tables can 
be  accessed.  It  then  selects  the  series  of  steps  that  returns  the 
results  fastest  while  using  fewer  resources.  The  final,  optimized 
version of the query tree is called the execution plan.
 The relational engine starts executing the execution plan. 
 The relational engine processes the data returned from the storage 
engine  into  the  format  defined  for  the  result  set  and  returns  the 
result set to the client.
 PROCESSING OTHER STATEMENT
 The basic steps described for processing a SELECT statement apply 
to other SQL statements. 
 The  process  of  identifying  these  rows  is  the  same  process  used  to 
identify  the  source  rows  that  contribute  to  the  result  set  of  a 
SELECT statement. 
 The UPDATE and INSERT statements may both contain embedded 
SELECT  statements  that  provide  the  data  values  to  be  updated  or 
inserted.
 Even  Data  Definition  Language  (DDL)  statements,  such  as 
CREATE PROCEDURE or ALTER TABLE, are ultimately resolved 
to a series of relational operations on the system catalog tables and 
sometimes  (such  as  ALTER  TABLE  ADD  COLUMN)  against  the 
data tables.
 Stored Procedure and Trigger Execution
 SQL Server stores only the source for stored procedures 
and triggers
 Source is compiled into an execution plan

 Source executed before the execution plan is aged from 
memory, the relational engine detects the existing plan 
and reuses it. 
 If the plan has aged out of memory, a new plan is built. 

 The execution plan for stored procedures and triggers is 
executed  separately  from  the  execution  plan  for  the 
batch calling the stored procedure or firing the trigger.
 This  allows  for  greater  reuse  of  the  stored  procedure 
and trigger execution plans.
 Execution Plan Caching and Reuse

SQL  Server  has  a  pool  of  memory  that  is  used  to  store 
both execution plans and data buffers. The percentage 
of the pool allocated to either execution plans or data 
buffers fluctuates dynamically, depending on the state 
of  the  system.  The  part  of  the  memory  pool  that  is 
used  to  store  execution  plans  is  referred  to  as  the 
procedure cache
QUERY PROCESSING 
ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
MEMORY MANAGEMENT 
ARCHITECTURE 
TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects Specifications

 Buffer Management 
 MEMORY ARCHITECTURE 

 SQL  Server  dynamically  acquires  and  frees 

memory as required
 Instances  of  SQL  Server  that  are  running  on 
Microsoft  Windows  2000  use  static  AWE  memory 
allocation
 Instances  that  are  running  on  Microsoft  Windows 
Server 2003 use dynamic AWE memory allocation.
 Minimize disk I/O

 SQL Server builds a buffer pool in memory to hold 
pages read from the database.
 SQL  Server  is  dedicated  to  minimizing  the  number  of 
physical  reads  and  writes  between  the  disk  and  the 
buffer pool

 SQL Server tries to reach a balance between two goals:
 Keep  the  buffer  pool  from  becoming  so  big  that  the  entire 
system is low on memory.
 Minimize physical I/O to the database files by maximizing the 
size of the buffer pool.

 By using AWE and the Locked Pages in Memory 
privilege, you can provide the following amounts of 
memory to the SQL Server Database Engine. 
 32-bit 64-bit
Conventional memory All SQL Server editions: Up All SQL Server editions: Up to
to process virtual address process virtual address space
space limit: limit:
 2 GB 7 terabytes on IA64


 3 GB with /3gb boot architecture

parameter1 8 terabytes on x64


 4 GB on WOW642 architecture
Note:
On Windows Server 2003, the
limitation is 512 GB; and on
Windows Server 2003 Service
Pack 1, the limitation is 1
terabyte. When Windows
supports additional memory,
SQL Server can reach the
limits listed.
AWE mechanism (Allows SQL SQL Server Standard, Not applicable3
Server to go beyond the process Enterprise, and Developer
virtual address space limit on 32- editions: Buffer pool is
bit platform.) capable of accessing up to
64 GB of memory.
 32-bit 64-bit
Locked pages in memory SQL Server Standard, SQL Server Enterprise and
operating system (OS) privilege Enterprise, and Developer Developer editions:
(Allows locking physical memory, editions: Required for SQL Recommended, to avoid
preventing OS paging of the Server process to use AWE operating system paging.
locked memory.)4 mechanism. Memory Might provide a performance
allocated through AWE benefit depending on the
mechanism cannot be workload. The amount of
paged out. memory accessible is similar
Granting this privilege to conventional memory case.
without enabling AWE has
no effect on the server.

In  a  heavily  loaded  system,  some  large  queries  that 

require  a  large  amount  of  memory  to  run  cannot  get  the 
minimum  amount  of  requested  memory  and  receive  a 
time­out  error  while  waiting  for  memory  resources.  To 
resolve this, increase the query wait Option. For a parallel 
query,  consider  reducing  the 
max degree of parallelism Option. 
 OPTIMIZING TEMPDB 
PERFORMANCE

 The  size  and  physical  placement  of  the  tempdb 

database can affect the performance of a system. 
 If  the  size  that is  defined for tempdb is too small, part 
of  the  system­processing  load  may  be  taken  up  with 
autogrowing tempdb to the size required to support the 
workload  every  time  you  restart  the  instance  of  SQL 
Server.
 You  can  avoid  this  overhead  by  increasing  the  sizes  of 
the tempdb data and log file.
TEMPDB SIZE AND PLACEMENT 
RECOMMENDATIONS
 To achieve optimal tempdb performance, we recommend the following 
configuration for tempdb in a production environment: 
 Set the recovery model of tempdb to SIMPLE. This model automatically 
reclaims log space to keep space requirements small.
 Allow for tempdb files to automatically grow as required. This allows for 
the file to grow until the disk is full.
 Set the file growth increment to a reasonable size to avoid the tempdb 
database files from growing by too small a value. If the file growth is too 
small, compared to the amount of data that is being written to tempdb, 
tempdb may have to constantly expand. This will affect performance. We 
recommend the following general guidelines for setting the FILEGROWTH 
increment for tempdb files.
 Put  the  tempdb  database  on  a  fast  I/O  subsystem.  Use  disk  striping  if 
there are many directly attached disks.
 Put the tempdb database on disks that differ from those that are used by 
user databases.
 Preallocate  space  for  all  tempdb  files  by  setting  the  file  size  to  a 
value  large  enough  to  accommodate  the  typical  workload  in  the 
environment. This prevents tempdb from expanding too frequently, 
which  can  affect  performance.  The  tempdb  database  should  be  set 
to  autogrow,  but  this  should  be  used  to  increase  disk  space  for 
unplanned exceptions. 

 Create as many files as needed to maximize disk bandwidth. Using 
multiple  files  reduces  tempdb  storage  contention  and  yields 
significantly  better  scalability.  However,  do  not  create  too  many 
files  because  this  can  reduce  performance  and  increase 
management overhead. As a general guideline, create one data file 
for  each  CPU  on  the  server  (accounting  for  any  affinity  mask 
settings)  and  then  adjust  the  number  of  files  up  or  down  as 
necessary. Note that a dual­core CPU is considered to be two CPUs.

 Make  each  data  file  the  same  size;  this  allows  for  optimal 
proportional­fill performance.
VIEWING TEMPDB SIZE AND GROWTH 
PARAMETERS
SELECT 
    name AS FileName, 
    size*1.0/128 AS FileSizeinMB,
    CASE max_size 
        WHEN 0 THEN 'Autogrowth is off.'
        WHEN ­1 THEN 'Autogrowth is on.'
        ELSE 'Log file will grow to a maximum size of 2 TB.'
    END,
    growth AS 'GrowthValue',
    'GrowthIncrement' = 
        CASE
            WHEN growth = 0 THEN 'Size is fixed and will not grow.'
            WHEN growth > 0 AND is_percent_growth = 0 
                THEN 'Growth value is in 8­KB pages.'
            ELSE 'Growth value is a percentage.'
        END
FROM tempdb.sys.database_files;
GO
MEMORY ARCHITECTURE 

 END………
 

QUESTIONS
TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects Specifications

 Buffer Management 
 PROCESS ADDRESS SPACE

 All  32­bit  applications  have  a  4­gigabyte  (GB)  process  address 

space (32­bit addresses can map a maximum of 4 GB of memory).
 Microsoft  Windows  operating  systems  provide  applications  with 
access to 2 GB of process address space, specifically known as user 
mode virtual address space.
 All  threads  owned  by  an  application  share  the  same  user  mode 
virtual address space.
 The  remaining  2 GB  are  reserved  for  the  operating  system  (also 
known as kernel mode address space).
 All operating system editions starting with Windows 2000 Server, 
including  Windows Server 2003,  have  a  boot.ini  switch  that  can 
provide applications with access to 3 GB of process address space, 
limiting the kernel mode address space to 1 GB.
 Address Windowing Extensions (AWE) extend the 
capabilities of 32­bit applications by allowing access to as 
much physical memory as the operating system 
supports.
 AWE accomplishes this by mapping a subset of up to 64 
GB into the user address space. Mapping between the 
application buffer pool and AWE­mapped memory is 
handled through manipulation of the Windows virtual 
memory tables.
 To enable support for 3 GB of user mode process space, 
you must add the /3gb parameter to the boot.ini file and 
reboot the computer, allowing the /3gb parameter to 
take effect.
 Setting this parameter allows user application threads to 
address 3 GB of process address space, and reserves 
1 GB of process address space for the operating system.
PROCESS ADDRESS SPACE

 END………
 

QUESTIONS
TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects Specifications

 Buffer Management 
 DYNAMIC MEMORY MANAGEMENT

 The Database Engine does this by using the Memory Notification 
APIs in Microsoft Windows.

 Virtual address space of SQL Server can be divided into two 
distinct regions: space occupied by the buffer pool and the rest. If 
AWE mechanism is enabled, the buffer pool may reside in AWE 
mapped memory, providing additional space for database pages. 

 The buffer pool serves as a primary memory allocation source of 
SQL Server. External components that reside inside SQL Server 
process, such as COM objects, and not aware of the SQL Server 
memory management facilities, use memory outside of the virtual 
address space occupied by the buffer pool.
 When  SQL  Server  starts,  it  computes  the  size  of  virtual  address 
space for the buffer pool based on a number of parameters such as 
amount  of  physical  memory  on  the  system,  number  of  server 
threads and various startup parameters. SQL Server reserves the 
computed amount of its process virtual address space for the buffer 
pool,  but  it  acquires  (commits)  only  the  required  amount  of 
physical memory for the current load.

 The  instance  then  continues  to  acquire  memory  as  needed  to 
support the workload. As more users connect and run queries, SQL 
Server acquires the additional physical memory on demand. A SQL 
Server  instance  continues  to  acquire  physical  memory  until  it 
either reaches its max server memory allocation target or Windows 
indicates  there  is  no  longer  an  excess  of  free  memory;  it  frees 
memory  when  it  has  more  than  the  min  server  memory  setting, 
and Windows indicates that there is a shortage of free memory.
DYNAMIC MEMORY MANAGEMENT 

 END………
 

QUESTIONS
TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects Specifications

 Buffer Management 
 EFFECTS OF MIN AND MAX SERVER 
MEMORY
 The min server memory and max server memory 
configuration options establish upper and lower limits 
to the amount of memory used by the buffer pool of the 
SQL Server Database Engine.
 The buffer pool does not immediately acquire the 
amount of memory specified in min server memory.
 The buffer pool starts with only the memory required to 
initialize.
 The buffer pool does not free any of the acquired 
memory until it reaches the amount specified in min 
server memory.
 Once  min  server  memory  is  reached,  the  buffer  pool 
then  uses  the  standard  algorithm  to  acquire  and  free 
memory as needed.

 The  only  difference  is  that  the  buffer  pool  never  drops 
its  memory  allocation  below  the  level  specified  in  min 
server  memory,  and  never  acquires  more  memory 
than the level specified in max server memory.

 The  amount  of  memory  acquired  by  the  Database 

Engine is entirely dependent on the workload placed on 
the  instance.  A  SQL  Server  instance  that  is  not 
processing many requests may never reach min server 
memory.
 If the same value is specified for both min server memory and 
max server memory, then once the memory allocated to the 
Database Engine reaches that value, the Database Engine stops 
dynamically freeing and acquiring memory for the buffer pool.

 If an instance of SQL Server is running on a computer where other 
applications are frequently stopped or started, the allocation and 
deallocation of memory by the instance of SQL Server may slow 
the startup times of other applications.

 if SQL Server is one of several server applications running on a 
single computer, the system administrators may need to control 
the amount of memory allocated to SQL Server. In these cases, you 
can use the min server memory and max server memory 
options to control how much memory SQL Server can use.
EFFECTS OF MIN AND MAX SERVER 
MEMORY 

 END………
 

QUESTIONS
TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects Specifications

 Buffer Management 
MEMORY USED BY SQL SERVER OBJECTS 
SPECIFICATIONS
SQL Server 7.0 SQL Server 2000 SQL Server 2005
Lock About 96 bytes 64 bytes + 32 bytes 64 bytes + 32 bytes
per owner per owner

Open database 2,880 bytes 3924 bytes + 1640 Not applicable to SQL
bytes per file and 336 Server 2005
bytes per filegroup

Open object 276 bytes 256 bytes + 1724 Not applicable to SQL
bytes per index Server 2005
opened on the object

User connection 12 KB + (3 * 12 KB + (3 * Approximately (3 *

network_packet_size) network_packet_size) network_packet_size
+ 94 KB)
MEMORY USED BY SQL SERVER 
OBJECTS SPECIFICATIONS

 END………
 

QUESTIONS
 TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects 
Specifications
 Buffer Management 
 BUFFER MANAGEMENT

 Buffer management is a key component in achieving 
this efficiency. The buffer management component 
consists of two mechanisms: 
 The buffer manager to access and update database pages, 
and 
 The buffer cache (also called the buffer pool), to reduce 
database file I/O. 
 HOW BUFFER MANAGEMENT WORKS

 A buffer is an 8­KB page in memory, the same size 
as a data or index page.
 Thus, the buffer cache is divided into 8­KB pages. 

 The  buffer  manager  manages  the  functions  for 

reading data or index pages from the database disk 
files  into  the  buffer  cache  and  writing  modified 
pages back to disk.
 A page remains in the buffer cache until the buffer 
manager needs the buffer area to read in more data.
 Data  is  written  back  to  disk  only  if  it  is  modified. 
Data  in  the  buffer  cache  can  be  modified  multiple 
times before being written back to disk.
 When  SQL  Server  starts,  it  computes  the  size  of 
virtual  address  space  for  the  buffer  cache  based  on  a 
number of parameters such as 
 The amount of physical memory on the system, 
 The  configured number  of  maximum  server  threads,  and 
various startup parameters.
 SQL  Server  reserves  this  computed  amount  of  its 
process  virtual  address  space  (called  the  memory 
target)  for  the  buffer  cache,  but  it  acquires  (commits) 
only  the  required  amount  of  physical  memory  for  the 
current load. 
 You  can  query  the  bpool_commit_target  and 
bpool_committed columns in the  sys.dm_os_sys_info 
catalog view to return the number of pages reserved as 
the memory target and the number of pages currently 
committed in the buffer cache, respectively.
 The interval between SQL Server startup and when 
the buffer cache obtains its memory target is called 
ramp­up. 
 Because the buffer manager uses most of the memory 
in the SQL Server process, it cooperates with the 
memory manager to allow other components to use its 
buffers. 
 The buffer manager interacts primarily with the 
following components:
 Resource manager to control overall memory usage and, in 
32­bit platforms, to control address space usage.
 Database manager and the SQL Server Operating System 
(SQLOS) for low­level file I/O operations.
 Log manager for write­ahead logging.
 DISK I/O AND BUFFER MANAGER

 The buffer manager only performs reads and writes to 
the database. Other file and database operations such 
as open, close, extend, and shrink are performed by the 
database manager and file manager components. 
 Disk I/O operations by the buffer manager have the 
following characteristics:
 All I/Os are performed asynchronously, which allows the 
calling thread to continue processing while the I/O operation 
takes place in the background.
 All  I/Os  are  issued  in  the  calling  threads  unless  the 
affinity I/O option  is  in  use.  The  affinity  I/O  mask  option 
binds SQL Server disk I/O to a specified subset of CPUs. In 
high­end  SQL  Server  online  transactional  processing 
(OLTP)  environments,  this  extension  can  enhance  the 
performance of SQL Server threads issuing I/Os.

 Multiple  page  I/Os  are  accomplished  with  scatter­gather 

I/O,  which  allows  data  to  be  transferred  into  or  out  of 
noncontiguous  areas  of  memory.  This  means  that  SQL 
Server  can  quickly  fill  or  flush  the  buffer  cache  while 
avoiding multiple physical I/O requests. 
 LONG I/O REQUESTS AND BUFFER 
MANAGER
 The buffer manager reports on any I/O request that has 
been outstanding for at least 15 seconds. This helps the 
system  administrator  distinguish  between  SQL  Server 
problems  and  I/O  subsystem  problems. 
Error message 833  is  reported  and  appears  in  the  SQL 
Server error log as follows:
 SQL Server has encountered %d occurrence(s) of I/O requests taking longer than %d 
seconds to complete on file [%ls] in database [%ls] (%d). The OS file handle is 0x%p. 
The offset of the latest long I/O is: %#016I64x.
 Long­I/O  messages  are  warnings,  not  errors.  They  do 
not indicate problems with SQL Server.
 The  messages  are  reported  to  help  the  system 
administrator  find  the  cause  of  poor  SQL  Server 
response  times  more  quickly,  and  to  distinguish 
problems that are outside the control of SQL Server. 
 CAUSES OF LONG­I/O REQUESTS
 A  long­I/O  message  may  indicate  that  an  I/O  is  permanently 
blocked  and  will  never  complete  (known  as  lost  I/O),  or  merely 
that it just has not completed yet. 
 Long I/Os often indicate a SQL Server workload that is too intense 
for the disk subsystem. 
 An inadequate disk subsystem may be indicated when:
 Multiple  long  I/O  messages  appear  in  the  error  log  during  a 
heavy SQL Server workload.
 Perfmon counters show long disk latencies, long disk queues, or 
no disk idle time.
 Long  I/O  requests  can  be  aggravated  by  workloads  that  perform 
large amounts of sequential I/O, such as backup and restore, table 
scans, sorting, creating indexes, bulk loads, and zeroing out files.
 Isolated long I/Os that do not appear related to any of the previous 
conditions  may  be  caused  by  a  hardware  or  driver  problem.  The 
system  event  log  may  contain  a  related  event  that  helps  to 
diagnose the problem.
 ERROR DETECTION
 Database pages can use one of two optional mechanisms 
that help insure the integrity of the page from the time 
it  is  written  to  disk  until  it  is  read  again:  torn  page 
protection and checksum protection. 

 These  mechanisms  allow  an  independent  method  of 

verifying  the  correctness  of  not  only  the  data  storage, 
but  hardware  components  such  as  controllers,  drivers, 
cables, and even the operating system. The protection is 
added  to  the  page  just  before  writing  it  to  disk,  and 
verified after it is read from disk.
 TORN PAGE PROTECTION

 Torn page protection, introduced in SQL Server 2000, is primarily 
a way of detecting page corruptions due to power failures.
 When torn page protection is used, a 2­bit signature is placed at 
the end of each 512­byte sector in the page (after having copied the 
original two bits into the page header).
 The signature alternates between binary 01 and 10 with every 
write, so it is always possible to tell when only a portion of the 
sectors made it to disk
 If a bit is in the wrong state when the page is later read, the page 
was written incorrectly and a torn page is detected.
 Torn page detection uses minimal resources; however, it does not 
detect all errors caused by disk hardware failures.
 CHECKSUM PROTECTION
 Checksum  protection,  introduced  in  SQL  Server  2005,  provides 
stronger data integrity checking.
 A checksum is calculated for the data in each page that is written, 
and stored in the page header. 
 Whenever  a  page  with  a  stored  checksum  is  read  from  disk,  the 
database engine recalculates the checksum for the data in the page 
and  raises  error  824  if  the  new  checksum  is  different  from  the 
stored checksum.
 Checksum  protection  can  catch  more  errors  than  torn  page 
protection because it is affected by every byte of the page, however, 
it is moderately resource intensive. 
 When  checksum  is  enabled,  errors  caused  by  power  failures  and 
flawed  hardware or firmware can be detected  any time  the buffer 
manager reads a page from disk.
 The  kind  of  page  protection  used  is  an  attribute  of  the  database 
containing the page. 
 Checksum  protection  is  the  default  protection  for  databases 
created in SQL Server 2005 and later. 
 The  page  protection  mechanism  is  specified  at  database  creation 
time, and may be altered by using ALTER DATABASE. 
 The  current  page  protection  setting  by  querying  the 
page_verify_option  column  in  the  sys.databases  catalog  view  or 
the  IsTornPageDetectionEnabled  property  of  the 
DATABASEPROPERTYEX function.
 If the page protection setting is changed, the new setting does not 
immediately affect the entire database. 
 Instead,  pages  adopt  the  current  protection  level  of  the  database 
whenever  they  are  written  next.  This  means  that  the  database 
may be composed of pages with different kinds of protection. 
BUFFER MANAGEMENT 

 END………
 

QUESTIONS
 TOPICS NEEDS TO BE COVERED

 Memory Architecture 
 Process Address Space

 Dynamic Memory Management 

 Effects of min and max server memory 

 Memory Used by SQL Server Objects 
Specifications
 Buffer Management 
MEMORY MANAGEMENT 
ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
THREAD TASK ARCHITECTURE 
 Threads are an operating system feature that lets application logic 
be separated  into several concurrent execution paths. This feature 
is  useful  when  complex  applications  have  many  tasks  that  can  be 
performed at the same time. 
 When  an  operating  system  executes  an  instance  of  an  application, 
it  creates  a  unit  called  a  process  to  manage  the  instance.  The 
process has a thread of execution. This is the series of programming 
instructions performed by the application code.
 Threads allow complex applications to make more effective use of a 
CPU,  even  on  computers  that  have  a  single  CPU.  With  one  CPU, 
only  one  thread  can  execute  at  a  time.  If  one  thread  executes  a 
long­running  operation  that  does  not  use  the  CPU,  such  as  a  disk 
read or write, another one of the threads can execute until the first 
operation is completed.
 USING THE LIGHTWEIGHT POOLING 
OPTION

The overhead involved in switching thread contexts is not very large. 
Most  instances  of  SQL  Server  will  not  see  any  performance 
differences between setting the lightweight pooling option to 0 or 1. 
The  only  instances  of  SQL  Server  that  might  benefit  from 
lightweight pooling are those that run on a computer having the 
following characteristics: 
 A large multi­CPU server.
 All the CPUs are running near maximum capacity.
 There is a high level of context switching.

These  systems  may  see  a  small  increase  in  performance  if  the 
lightweight pooling value is set to 1.
 HOT ADD CPU

Hot add CPU is the ability to dynamically add CPUs to a 
running  system.  Adding  CPUs  can  occur  physically  by 
adding  new  hardware,  logically  by  online  hardware 
partitioning, or virtually through a virtualization layer. 
Starting  with  SQL  Server  2008,  SQL  Server  supports 
hot add CPU.
THREAD TASK ARCHITECTURE 

END………
 

QUESTIONS
 TOPICS
 Pages and Extents Architecture
 Files and Filegroups Architecture

 Transaction Log Architecture

 Tables and Index Data Structures Architecture

 Query Processing Architecture

 Memory Management Architecture

 Thread and Task Architecture
  THE END  