Module 2

Preparing Systems for

SQL Server 2008 R2

Module Overview
Overview of SQL Server Architecture
Planning Server Resource Requirements
Pre-installation Testing for SQL Server

Lesson 1: Overview of SQL Server Architecture

SQL Server Architecture
CPU Usage by SQL Server
Parallelism
32 bit vs. 64 bit Servers
Overview of SQL Server Memory
Physical vs. Logical I/O
Demonstration 1A: CPU and Memory Configurations in

SSMS

SQL Server Architecture

Users

Query Execution Layer

Configuration

Query Execution

Storage Engine
SQL OS

Parses and optimizes the

queries, and manages the
caching and execution of
query execution plans

Storage Engine Layer

Manages buffer pages, I/O

to the physical files, locking,
and transactions

SQL OS Layer

Provides an abstraction layer

over common OS functions,
providing task and memory
management

CPU Usage by SQL Server

Windows uses preemptive scheduling of threads
One scheduler for every logical CPU created in SQL OS

Manages the threads retrieved from Windows and assigns

tasks to threads

Minimizes context switches through cooperative scheduling

CPU availability can be configured without restart

Schedulers can be enabled or disabled

CPU affinity mask can be set

Tasks waiting on a resource are moved to a waiting list

Wait type and time are recorded

Details are useful for monitoring and troubleshooting

Parallelism
Parallelism
Parallelism refers
refers to
to multiple
multiple processors
processors cooperating
cooperating to
to execute
execute
a
a single
single query
query at
at the
the same
same time.
time.
SQL Server can decide to distribute queries to more than

one task

Tasks can run in parallel

Overall execution is faster

Synchronization overhead is incurred

Parallelism is only considered for expensive plans

Max degree of parallelism defines how many CPUs can

be used for execution of a parallel query

Can be overridden using the MAXDOP query hint

Cost threshold for parallelism defines minimal cost for

considering parallel plans

32 bit vs. 64 bit Servers

Virtual Address Space is the memory that can be allocated

to applications such as SQL Server

4GB on 32 bit systems (2-3GB available for the application)

8TB on X64 systems and 7TB on IA64 systems

4GB for 32 bit applications running on WOW on 64bit OS

AWE extension can be used to access additional memory

on 32bit systems

Additional memory can only be used for data page caching

SQL Server performance strongly depends on memory

Installing 64 bit versions is preferred

64 bit options available for all editions of SQL Server

Overview of SQL Server Memory

Buffer Pool is the main memory object of SQL Server

Holds data cache

Provides memory for other SQL Server components

Is divided into 8K pages

Components can request memory from VAS directly

Occurs when more than 8KB of continuous memory is required

SQL OS automatically allocates as much memory as needed

Has a mechanism to prevent memory shortage on the system

Can be configured using min and max server memory options

Physical vs. Logical I/O

I/O Type

Description

Physical I/O

Physical I/O occurs when the requested page

is not available in Buffer Cache and must be
read from the data file into the Buffer Cache
before the requested page can be supplied or
when a changed page is written to the data
file

Logical I/O

Logical I/O occurs when the requested page

is available in the Buffer Cache

Demonstration 1A: CPU and Memory Configurations

in SSMS
In this demonstration, you will see:

How to configure SQL Server CPU and Memory using SSMS

How to review configuration options using T-SQL

Lesson 2: Planning Server Resource Requirements

Introduction to Planning Server Resource Requirements
Discussion: Previous Exposure to Resource Planning
Planning CPU Requirements
Planning Memory Requirements
Planning Network Requirements
Planning Storage and I/O Requirements

Introduction to Planning Server Resource Requirements

No easy formula for calculating resource requirements exists
Planning involves

Checking with ISV or developers

Ask for reference installations and case studies

Request details of previous experiences with the application

Performing tests with real live workloads

Setting goals and evaluating results against them

Planning and predicting further grow of the workload and database

Monitor the outcome after release into production

Discussion: Previous Exposure to Resource Planning

Resource Planning is an important part of new

installations

What is your previous experience with planning of new

systems?

How successful was the planning?

Planning CPU Requirements

Processor planning is relatively straightforward
Test on a typical workload and monitor CPU usage

CPU should be below 30 percent in average

Peaks can occur but should not last too long

More processors provide better parallelism options

Assists with large numbers of concurrent connections

Assists with high data warehouse loads

Dedicated database server should use all available CPUs

Many new systems use NUMA architecture

Check with hardware vendor for optimal SQL Server configuration

Planning Memory Requirements

SQL Server is highly dependent on memory

Caches help to reduce I/O and CPU

Data cache reduces I/O

Plan cache reduces the need for recompiling queries

Memory to store and process data is required during query

execution

Memory shortage can lead to CPU and I/O pressure

Plan to have enough memory

Able to cache frequently accessed data

Consider memory consumption of other services running on

the system

Planning Network Requirements

Plan and test the throughput needed for the application

Consider using several network adapters

Consider dedicating a network connection to administrative

purposes

Writing Backups to network devices

Transferring data to other instances using SSIS

Use a dedicated network connection when using database

mirroring

Choose and configure the network protocols used

Check firewall configurations

Test in a network environment similar to the target production

system

Planning Storage and I/O Requirements

I/O requirements need to be determined and tested
Considerations for storage

Dedicated vs. SAN based storage

RAID systems used

Number of spindles involved (often more important than disk

size)

I/O caching configuration (disk and write caching)

Lesson 3: Pre-installation Testing for SQL Server

Overview of Pre-installation Testing
Perform Pre-checks of I/O subsystems
Introducing SQLIOSIM
Introducing SQLIO
Demonstration 3A: Using SQLIOSIM & SQLIO

Overview of Pre-installation Testing

Planning and testing is strongly coupled
After the first planning phase tests must be performed

Check if the predictions made are met

Change the predictions based on the results

Check if the goals set in the planning phase are fulfilled

Test different configurations involving

Storage and I/O layout

Memory, CPU and Network configurations

Document every test run for later use

Perform Pre-checks of I/O subsystems

Test different I/O types and sizes

Small random reads and write on data files for OLTP systems

Larger sequential reads and writes for OLAP systems

Sequential writes for log storage

Test with different numbers of files involved

Use test files that are similar to your target configuration

Determine the saturation point of an I/O subsystem by gradually

increasing the load

Validate results against expected outcome

Based on the goals you set

Checked against the potential I/O capabilities of the system

Introducing SQLIOSIM
Unsupported tool provided by Microsoft to test the functional

correctness of storage systems.

Can be run through command line and and GUI

Introducing SQLIO
Unsupported tool provided by Microsoft to test the performance

of storage systems.

Command line tool that can be configured to specific I/O Pattern

Demonstration 3A: Using SQLIOSIM & SQLIO

In this demonstration, you will see how to:

Configure SQLIOSim to stress test a server

Test different I/O patterns using the SQLIO utility

Lab 2: Preparing Systems for SQL Server

Exercise 1: Adjust memory configuration
Exercise 2: Perform Pre-installation Stress Testing
Challenge Exercise 3: Check Specific I/O Operations (Only

if time permits)

Logon information

Virtual machine

623XB-MIA-SQL

User name

AdventureWorks\Administrator

Password

Pa$$w0rd

Estimated time: 45 minutes

Lab Scenario
You have reviewed the additional instance of SQL Server. A
system administrator at AdventureWorks has expressed
some concerns that the existing server may not have
enough memory or I/O capacity to support this new SQL
Server instance and is reviewing a new I/O subsystem. As
the database administrator, you need to review the
available server memory and the memory allocated to each
of the existing SQL Server instances. You need to ensure
that the I/O subsystem of the new server is capable of
running SQL Server and the required workload correctly.

Lab Review
Why is running SQLIOSim on the VM difficult?
Should you use SQLIOSIM or SQLIO to test the

performance of a system with 8KB random reads?

Module Review and Takeaways

Review Questions
Best Practices