FRONT END (CLIENT) SERVER SIDE
ACCESS SQL SERVERPowerful RDBMS
Features Interactive Forms
to display and manipulate data
Supports ODBC connectivity
Has basic security features
Does not provide transactional functionality
Very basic backup functionality
Does not support multi-user operation
Works with 1 database at a time
Extremely powerful RDBMS
No client-usable Forms
Supports ODBC connectivity
Has robust, layered security features
Provides transactional functionality
Comprehensive backup functionality
Supports multi-user operation
Oversees multiple databases at a
time
2
TRANSACTION
A unit of work containing several commands to access, manipulate,
store and extract data from a database..
TRANSACTION ACID REQUIREMENTS
Durability - The results of a committed transaction must persist
even if there's a system failure
Atomicity - The transaction must complete all of the commands in their entirety or none of them.
Consistency - The transaction cannot break the integrity rules
of the database
Isolation - The transaction must be entirely self-contained,
changes it makes must not be readable by any other
transaction
TYPES OF TRANSACTIONS
IMPLICIT – an action code block which runs completely when executed (SQL default) – cannot be rolled backensuring atomicity
EXPLICIT– code within a transaction block which contains code to CONTROL rollback and COMMIT
BEGIN TRANSACTION
T SQL commands
Insert SAVEPOINT, if needed, to mark a rollback stop point
Either COMMIT TRANSACTION
or ROLLBACK TRANSACTION
Atomicity is ensured by the requirement that all commands withing th code block be completed before thr changes are committed
SQL SERVER NETWORK INTERFACE (SNI)
SNI is a protocol layer that establishes
network connection between the client and
the server containing a set of APIs that are
used by both the database engine and the
SQL Server Native Client (SNAC) .
Shared memory - the default protocol is to connect from a client running on the same computer as SQL Server.
TCP/IP - the most common access protocol enables connection using an IP address and port number
Named pipes - were developed for local area networks and can be inefficient across slower networks such WANs
VIA - Virtual Interface Adapter enables high-performance communication between two systems require specialized hardware at both ends and a dedicated connection
SQL SERVER SUPPORTS THE FOLLOWING PROTOCOLS
PROTOCOL LAYERS ESTABLISH CONNECTION
Regardless of the protocol. Once a connection
is established , SNI creates a secure connection
to a Tabular Data Stream (TDS) end point on
the server which is used to send requests and
receive data.
There is one TDS endpoint for each protocol
and one reserved for the use by the Dedicated
Administrator Connection (DAC)
SELECT REQUEST - PROTOCOL LAYER
The SQL Server ‘s protocol layer
Receives a TDS packet
Unwraps the package Reversing the SNI’s client packet
preparation process)
Determines the request contents.
When the requested READ is complete,
Packages the results and status messages to send
back to the client as TDS messages
TDS
SQL SERVER COMPONENTS
Relational Engine (Query Processor) Primary function: to optimize queries and execution.
Command Parser Checks query syntax and
prepares query tree
Query Optimizer Determines the execution plan
Query Executor Runs the code
SQL SERVER COMPONENTS
Storage engine Responsible for managing all I/O to the data
Access Method
Handles I/O requests for rows, indexes, pages, allocations and row versions
Buffer Manager
Deals with SQL’s main memory consumer, the Buffer Pool
Transaction Manager
Handles locking of data to ensure ACID properties and manages the transactions law
SQL SERVER COMPONENTS
Buffer Pool
Plan Cache Stores execution plans for reuse
Data cacheUsually the largest part of the Buffer Pool
Stores clean pages retrieved from the Database files
Stores(between checkpoints) dirty pages containing changed dataCode to see how much room (in MB) Buffer Pool is using:
SELECT count(*)*8/1024 AS 'Cached Size (MB). .CASE database_id
WHEN 32767 THEN 'ResourceDb'
ELSE db_name(database_id)
END AS 'Database'
FROM sys.dm_os_buffer_descriptors
CROUP BY db_name(database_id) ,database_id ORDER BY 'Cached Size (MB)' DESC
SQL SERVER - FLUSHING THE DATA CACHE
Pages with least activity flushed first- The header of each page in cache stores details
about the last 2 times it was accessed, a periodic scan of the cache checks the values. A
counter is maintained that is decremented if the page hasn't been accessed recently; and,
when SQL Server needs to free up some cache, the pages with the lowest counter are
flushed first.
The process of aging out pages from cache and maintaining an available amount of
free cache pages for subsequent use can be done by any worker thread after
scheduling its own I/O or by the lazywriter process.
It’s possible to view how long SQL Server expects to be able to keep a page in cache by
looking at the MSSQL$<Instance>:Buffer Manager\Page Life Expectancy counter in
Performance Monitor.
Page life expectancy (PLE) is the amount of time, in seconds, that SQL Server
expects to be able to keep a page in cache.
Under memory pressure, data pages are flushed from cache far more frequently.
Microsoft recommends a minimum of 300 seconds for a good PLE, but for systems
with plenty of physical memory this will easily reach thousands of seconds.l
SQL SERVER - FLUSHING THE DATA CACHE
LAZYWRITER
A thread which periodically checks the size of the Free Buffer List when it's low and scans the whole data cache to age-out any pages that have been used for a while. .
Monitors the free physical memory on the server and will release memory from the Free Buffer List back to Windows in very low memory conditions
When SQL Server is busy. It will grow the size of the font Free Buffer List to meet demand. when there is physical memory and the configured Max Server Memory Threshold hasn't been reached
CHECKPOINT
A point in time created by the Checkpoint Process where SQL Server can be sure that any committed transactions have had all their changes written to disk. Becomes a marker from which database recovery can start.
The checkpoint process ensures that any dirty pages associated with committed transactions will be flushed to disk. Unlike the lazy writer. However a checkpoint does not remove the page from cache it. Make sure the dirty page is written to disk and then marks the cache page as clean in the page header.
By default on a busy server, SQL Server will issue a checkpoint roughly every minute, which is marked in the transaction log. If the SQL Server instance or the database is restarted to the recovery process reading the log knows that it doesn't need to do anything with log records prior to the checkpoint..
SELECT REQUEST – COMMAND PARCER
Handles I/O
Checks syntax and returns any errors back to the protocol layer to send the client.
If the syntax is valid, either generates a query plan (execution plan contains details about
how SQL Server is to execute a piece of code ) or finds an existing plan (in the plan cache
TDS
If no cashed plan is found, then the
command parser generates a Query
Tree (an internal structure where each
node in the tree represents an operation in
the query that needs to be performed)
based on the T SQL.
The tree is then passed to the
QueryOptimizer to process
LANGUAGE EVENT
SELECT REQUEST – QUERY OPTIMIZER
The Optimizer is cost-based, evaluating multiple ways to execute a query and
choosing the method that will have the lowest cost (most efficient, not necessarily
the best) execution.
The execution method is implemented as a query plan and is output from the
optimizer.
TDS
LANGUAGE EVENTQUERY TREE
MULTISTAGE OPTIMIZATION
During Optimization, number of pages available increases allowing the selection of a good plan at each stage
PRE-OPTIMIZATION - SIMPLE QUERIES (single tables/no joins) can drop out at this point
PHASE 0 - Looks at nested loop joins and will not consider parallel operators (executing across multiple processors)
TRANSACTION PROCESSING (TP) PLAN
If the cost of the plan is found it is found is < .02 ,the optimizer will stop here.
PHASE 1 - uses a subset of the possible opposite optimization rules and looks for pattern for which it already has a plan
QUICK PLAN
If the cost of the plan is found it is found is < .01 the optimizer will stop here.
PHASE 2 uses all of the optimization rules and looks at parallelism and indexed views . If running an enterprise edition generates a full plan
NOTE: Cost does not refer to time. It's an arbitrary measure, assigned a value representing the response cop cost for a plan
SELECT REQUEST – QUERY EXECUTOR
Executes the query plan by
working through each step
and interacting with the
Storage Engine to retrieve
or modify data. Query Plan
OLE DB
SELECT REQUEST – STORAGE ENGINE
Access Methods - Provides the storage structure for
data and indexes used to retrieve and modify .
It doesn't really perform the operation itself, passing the request to the Buffer Manager
Buffer Manager If the data is not already there,
retrieves data and stores it in the buffer pool .
All operations are performed on data in memory and returns a result set
TDS
SELECT REQUEST – RETURN RESULT SET
The result set for thr SELECT query is now in the
Buffer Pool ‘s Data Cache and will have an entry in the
sys.dm_os_buffer_descriptors Dynamic
Management View (DMV).
The result set is passed back to the Access Methods to
make its way to the (green arrow)
Dynamic Management Views (DMV). start with sys.dm_os_ and provide an insight
into the workings of SQLOS. For example:
sys.dm_os_schedulers: Returns one row per scheduler (there is one user
scheduler per core) and shows information on scheduler load and health.
sys.dm_os_waiting_tasks: Returns one row for every executing task that
is currently waiting for a resource as well as the wait type.
sys.dm_os_memory_clerks: Memory clerks are used by SQL Server to
allocate memory. Significant components within SQL Server have their own
memory clerk. This DMV shows all the memory clerks and how much memory
each one is using..
UPDATE REQUEST – ACCESS METHODS
The initial steps are exactly
the same as a READ request
until the step returning the
result set.
Since the execution plan
calls for data modification,
so,before the I/O request is
passed on by the Access
Methods , the details of the
change need to be persisted
to disk by the Transaction
Manager.
Query Plan
OLE DB
UPDATE REQUEST – TRANSACTION MANAGER
COMPONENTS
LOCK MANAGER - responsible
for providing concurrency to the
data and delivers a configured
level of isolation
LOG MANAGER - uses write-
ahead logging , recording the
proposed page modification
statements to the transaction
log. Up to this time, this is the
only write performed.
Query Plan
OLE DB
The actual data modification
is performed only when the Access
Manager receives confirmation that the
operation has been physically written to
the transaction log.
c
UPDATE REQUEST – BUFFER MANAGER
Once the Access Methods has received logging confirmation, the update request is passed to the buffer manager to complete.
NOTE The page to be modified is already in cash
Buffer Manager
Modifies data in the cacheas requested
When the modifications are completed, sends confirmation to the Access Methods
Query Plan
OLE DB
c
TDS