SQL Server Architecture

MS SQL SERVER

Standard Operating Procedures

(SOP)

SQL Server Architecture

Submitted to

By

CIS, Wipro Limited

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 1 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

Document Details

Project Name Innogy SE

Account CIS

IT Component/Application Title SQL Server Architecture

Current Version 1.5

List of Contributors Pradipkumar Kansara, Kiran Bhalekar, Ayushi Gautam,

Sivakumar Goud, Ayushi Srivastava

Customer Contact Information

Version History

(All revisions made to this document must be listed in chronological order. All revisions
must be approved. Review and Approval can be done by an internal source or by the
customer)

Version Date of Revision Description Author Reviewed By Approved By

Pradipkumar Mahesh
1.0  29-08-2015 Intial Draft Kiran Bhalekar
Kansara Keshatwar
04-09-2015   Document Kiran Bhalekar Pradipkumar Mahesh
1.1
Completed Kansara Keshatwar
21-08-2016 Updated document to Ayushi Gautam Pradipkumar Mahesh
1.2
standard format Kansara Keshatwar
17-05-2017 Wipro and Innogy Ayushi Gautam Pradipkumar Mahesh
1.3
Logo changed Kansara Keshatwar
Updated document to
1.4
18-08-2017 Wipro Standard Kiran Bhalekar Pradipkumar Mahesh
format with header Kansara Keshatwar
and footer
19-12-2018 Updated the content Ayushi Pradipkumar
1.5 Santosh Badiger
Srivastava Kansara
 

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 2 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

Document Distribution List

S.No Name and Company Purpose

1 RWEIT-SQLDBA This document is useful to understand
SQL server architecture
2

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 3 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

Table of contents

1. Purpose...........................................................................................................................2
2. Page and Extends..........................................................................................................2
2.1. Pages........................................................................................................................2
2.2. Extents.....................................................................................................................4
3. File and File Group Architecture................................................................................4
3.1. Database Files.........................................................................................................4
3.2. Database Filegroups..............................................................................................6
4. Transaction Log file Architecture....................................................................................7
4.1. Transaction Log Logical Architecture.................................................................7
4.2. Transaction Log physical Architecture...............................................................8
5. Memory Architecture...................................................................................................9

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 4 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

1. Purpose

The purpose of the document gives an idea about SQL Server Architecture and its
elements like pages, memory etc.

2. Page and Extends

The page is the fundamental unit of data storage in SQL Server.

An extent is a collection of eight physically contiguous pages. Extents help efficiently

manage pages.

The fundamental unit of data storage in SQL Server is the page. The disk space allocated
to a data file (.mdf or .ndf) in a database is logically divided into pages numbered contiguously
from 0 to n. Disk I/O operations are performed at the page level. That is, SQL Server reads or
writes whole data pages.

Extents are a collection of eight physically contiguous pages and are used to efficiently
manage the pages. All pages are stored in extents.

2.1. Pages

In SQL Server, the page size is 8 KB. This means 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.

The following table shows the page types used in the data files of a SQL Server database.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 5 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

Page type Contents

Data Data rows with all data, except text, ntext, image, nvarchar(max),
varchar(max), varbinary(max), and xml data, when text in row is
set to ON.

Index Index entries.

Large object data types:

Text/Image
 text , ntext, image, nvarchar(max), varchar(max),
varbinary(max), and xml data

Variable length columns when the data row exceeds 8 KB:

 varchar , nvarchar, varbinary, and sql_variant

Global Allocation Map, Information about whether extents are allocated.

Shared Global Allocation
Map

Page Free Space Information about page allocation and free space available on
pages.

Index Allocation Map Information about extents used by a table or index per allocation
unit.

Bulk Changed Map Information about extents modified by bulk operations since the
last BACKUP LOG statement per allocation unit.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 6 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

Differential Changed Map Information about extents that have changed since the last
BACKUP DATABASE statement per allocation unit.

2.2. Extents

Extents are the basic unit in which space is managed. An extent is eight physically
contiguous 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.

A new table or index is generally allocated pages from mixed extents. When the table or
index grows to the point that it has eight pages, it then switches to use uniform extents for
subsequent allocations. If you create an index on an existing table that has enough rows
to generate eight pages in the index, all allocations to the index are in uniform extents.

3. File and File Group Architecture

SQL Server maps a database over a set of operating-system files. Data and log
information are never mixed in the same file, and individual files are used only by one database.
Filegroups are named collections of files and are used to help with data placement and
administrative tasks such as backup and restore operations.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 7 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

3.1. Database Files

SQL Server databases have three types of files:

 Primary data files

The primary data file is the starting point of the database and points to the other files in
the database. Every database has one primary data file. 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. Some
databases may not have any secondary data files, while others have several secondary
data files. 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. There must be at
least one log file for each database, although there can be more than one. The
recommended file name extension for log files is .ldf.

SQL Server does not enforce the .mdf, .ndf, and .ldf file name extensions, but these
extensions help you identify the different kinds of files and their use.

In SQL Server, the locations of all the files in a database are recorded in the primary file of
the database and in the master database. The SQL Server Database Engine uses the file location
information from the master database most of the time.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 8 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

However, the Database Engine uses the file location information from the primary file to
initialize the file location entries in the master database in the following situations:

 When attaching a database using the CREATE DATABASE statement with either the
FOR ATTACH or FOR ATTACH_REBUILD_LOG options.
 When upgrading from SQL Server version 2000 or version 7.0.

 When restoring the master database.

Logical and Physical File Names

SQL Server files have two names:

logical_file_name

The logical_file_name is the name used to refer to the physical file in all Transact-SQL
statements. The logical file name must comply with the rules for SQL Server identifiers and must
be unique among logical file names in the database.

os_file_name

The os_file_name is the name of the physical file including the directory path. It must
follow the rules for the operating system file names.

SQL Server data and log files can be put on either FAT or NTFS file systems. We
recommend using the NTFS file system because the security aspects of NTFS. Read/write data
filegroups and log files cannot be placed on an NTFS compressed file system. Only read-only
databases and read-only secondary filegroups can be put on an NTFS compressed file system.

When multiple instances of SQL Server are run on a single computer, each instance
receives a different default directory to hold the files for the databases created in the instance.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 9 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

3.2. Database Filegroups

Database objects and files can be grouped together in filegroups for allocation and administration
purposes. There are two types of filegroups:

Primary

The primary filegroup contains the primary data file and any other files not specifically assigned
to another filegroup. All pages for the system tables are allocated in the primary filegroup.

User-defined

User-defined filegroups are any filegroups that are specified by using the FILEGROUP
keyword in a CREATE DATABASE or ALTER DATABASE statement.

Log files are never part of a filegroup. Log space is managed separately from data space.

No file can be a member of more than one filegroup. Tables, indexes, and large object
data can be associated with a specified filegroup. In this case, all their pages will be allocated in
that filegroup, or the tables and indexes can be partitioned. The data of partitioned tables and
indexes is divided into units each of which can be placed in a separate filegroup in a database.
For more information about partitioned tables and indexes, see Partitioned Tables and Indexes.

One filegroup in each database is designated the default filegroup. When a table or index
is created without specifying a filegroup, it is assumed all pages will be allocated from the default
filegroup. Only one filegroup at a time can be the default filegroup. Members of the db_owner
fixed database role can switch the default filegroup from one filegroup to another. If no default
filegroup is specified, the primary filegroup is the default filegroup.

4. Transaction Log file Architecture

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 10 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

4.1. Transaction Log Logical Architecture

The SQL Server transaction log operates logically as if the transaction log is a string of log
records. Each log record is identified by a log sequence number (LSN). Each new log record is
written to the logical end of the log with an LSN that is higher than the LSN of the record before
it.

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. For each transaction, all log records associated with
the transaction are individually linked in a chain using backward pointers that speed the rollback
of the transaction.

Log records for data modifications record either the logical operation performed or they
record the before and after images of the modified data. The before image is a copy of the data
before the operation is performed; the after image is a copy of the data after the operation has
been performed.

The steps to recover an operation depend on the type of log record:

 Logical operation logged

 To roll the logical operation forward, the operation is performed again.

 To roll the logical operation back, the reverse logical operation is performed.

 Before and after image logged

 To roll the operation forward, the after image is applied.

 To roll the operation back, the before image is applied.

Many types of operations are recorded in the transaction log. These operations include:

 The start and end of each transaction.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 11 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

 Every data modification (insert, update, or delete). This includes changes by system
stored procedures or data definition language (DDL) statements to any table, including
system tables.

 Every extent and page allocation or deallocation.

 Creating or dropping a table or index.

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. The amount of space reserved depends on the
operations performed in the transaction, but generally is equal to the amount of space used to log
each operation. This reserved space is freed when the transaction is completed.

The section of the log file from the first log record that must be present for a successful
database-wide rollback to the last-written log record is called the active part 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.

4.2. Transaction Log physical Architecture

The transaction log is used to guarantee the data integrity of the database and for data
recovery. The topics in this section provide the information about the physical architecture of the
transaction log. Understanding the physical architecture can improve your effectiveness in
managing transaction logs.

The transaction log in a database maps over one or more physical files. Conceptually, the
log file is a string of log records. 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. Virtual log files have no fixed size, and there is no fixed number of virtual log
files for a physical log file. The Database Engine chooses the size of the virtual log files
dynamically while it is creating or extending log files. The Database Engine tries to maintain a
<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 12 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted

 SQL Server Architecture

small number of virtual files. The size of the virtual files after a log file has been extended is the
sum of the size of the existing log and the size of the new file increment. The size or number of
virtual log files cannot be configured or set by administrators.

5. Memory Architecture
SQL Server dynamically acquires and frees memory as required. Typically, an
administrator does not have to specify how much memory should be allocated to SQL Server,
although the option still exists and is required in some environments.

SQL Server supports Address Windowing Extensions (AWE) allowing use of physical
memory over 4 gigabytes (GB) on 32-bit versions of Microsoft Windows operating systems. Up to
64 GB of physical memory is supported. Instances of SQL Server that are running on
Microsoft Windows 2000 use static AWE memory allocation, and instances that are running on
Microsoft Windows Server 2003 use dynamic AWE memory allocation. 

One of the primary design goals of all database software is to minimize disk I/O because disk
reads and writes are among the most resource-intensive operations. SQL Server builds a buffer
pool in memory to hold pages read from the database. Much of the code in 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.

<Version 1.0> Wipro – <Innogy> CONFIDENTIAL

Document Status: Page 13 of 13

Internal Client
Template version 2.0 Review
Approval Approval
Reviewed Not reviewed

Sensitivity: Internal & Restricted