Top Banner
SQL SERVER MANAGEMENT 2008 Sandra Shin [email protected]
29
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Sql Server

SQL SERVER

MANAGEMENT

2008

Sandra Shin

[email protected]

Page 2: Sql Server

1

SQL SERVER VS FRONT END APPLICATIONS

Page 3: Sql Server

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

Page 4: Sql Server

2

TRANSACTION

A unit of work containing several commands to access, manipulate,

store and extract data from a database..

Page 5: Sql Server

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

Page 6: Sql Server

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

Page 7: Sql Server

3

SERVER ARCHITECTURE

Page 8: Sql Server
Page 9: Sql Server

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

Page 10: Sql Server

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)

Page 11: Sql Server

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

Page 12: Sql Server

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

Page 13: Sql Server

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

Page 14: Sql Server

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

Page 15: Sql Server

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

Page 16: Sql Server

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..

Page 17: Sql Server

4

SELECT REQUEST

Page 18: Sql Server

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

Page 19: Sql Server

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

Page 20: Sql Server

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

Page 21: Sql Server

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

Page 22: Sql Server

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

Page 23: Sql Server

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)

Page 24: Sql Server

4

USING DYNAMIC MANAGEMENT VIEWS

Page 25: Sql Server

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..

Page 26: Sql Server

5

UPDATE REQUEST

Page 27: Sql Server

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

Page 28: Sql Server

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

Page 29: Sql Server

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