11. to 12.

April 2007 | Zurich, Switzerland

Michael Epprecht Consultant Microsoft Switzerland

11. to 12. April 2007 | Zurich, Switzerland

I/O Sub-system (1/2)

Planning time spent in I/O Configuration would have significant payback Normal I/O Performance guidelines apply

Minimally, size for the sum of all work load being consolidated including growth Be careful

An misbehaving application might use up DB and Log space planned for other applications An upper limit specification might be appropriate for some DBs

Considerations

Isolation at physical disk level may not be practical Focus on ensuring healthy disk latency
1 - 5 ms for Log (Ideally 1 ms or better) 5 - 20 ms for Data (OLTP) (Ideally 10 ms or better) <=25-30 ms for Data (DSS)

Be aware of spindle sharing with other servers and, ideally, avoid if possible

I/O Sub-system (2/2)

Considerations
Raid 10 preferred
(continued)

Raid 5 is generally less costly

However, lower write performance But, may be acceptable for some workloads

Keep Backup Files on separate spindles Safeguard against Cache loss (battery back up) Particularly for Log Devices Watch cache read write usage settings Use multiple channels if available

Storage Top 10 Best Practices

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/stora

ge-top-10.mspx

Processors

Intel vs. AMD

x86 x64 N-cores IA 64 (Real 64 Bit) N-cores

Managing Memory Resources

Best Practice: Place a memory ceiling on each relational server instance To ensure a certain amount of memory resources set min server memory

Be aware that SQL does not acquire memory on startup, memory is acquired on demand (this is a behavior change from SQL 2000 64-bit)

Best Practice: Grant the SQL Server service account Lock pages in memory privilege
Prevents OS paging of SQL buffers pool memory under memory pressure

On 32-bit, required to utilize AWE memory

Best Practices apply to:

Single instance of SQL Server Multiple SQL Server instances sharing the server

When other components (AS, SSIS, RS) co-reside with the relational server

Managing Memory Resources

Managing SQL RDBMS memory consumption

Determine desired size of total RDBMS memory footprint for each

instance (Msql)
Ensure Msql < Total Server Memory ~1GB (per 8-16GB) for OS

Max memory required by other apps or instances

Reserve enough room outside of buffer pool for

SQL Threads
Threads will consume 4MB each on Itanium, 2MB on X64, 1MB on 32-Bit (= 1GB for 256 Worker Threads on Itanium)

XPs, In-Proc OleDB drivers, CLR GC heap

Calculate & set the resulting size of buffer pool desired

Bpool = Msql - Threads - XPs - CLR GC heap - etc Sp_configure Max Server Memory = Bpool Consider: Sp_configure Min Server Memory = min desired amount

NOTE: On 64-bit memory outside of Buffer Pool cannot be limited

(memtoleave on 32-bit system)

Taking Advantage of NUMA Systems

NUMA memory configurations are common on servers with > 4 cores

Some SQL Server 2005 OLTP workloads are 60% faster when using

NUMA instead of Interleaved memory

Many NUMA Enhancements in Relational SQL Server

Improved placement of objects in local cache Per-node lazywriter, free list and checkpointing Per-node resource management (threads) Per-node IO completion port

A SQL connection will remain on the same NUMA node for its lifetime
Potential for leveraging local cache for all of its tasks Soft NUMA provides the ability to direct specific connections to

specific nodes

NUMA: Be Careful

AS (prior to SP2) and SSIS are not NUMA aware

No assurance of evenly distributed memory allocation
Windows will tend to fill a single nodes CPUs with work before exercising

other CPUs
Common to see only one busy set of nodes and remainder of server idle

until a node saturates

SP2 for AS introduces (NUMA aware) new PreAlloc

configuration setting If on same physical server, consider

Using WSRM to manage CPU resource
Starting SQL Server and warming cache before launching AS

Avoids AS potentially grabbing all local memory for one node Avoids filesystem cache from stealing pages disproportionately from a single node which could create a SQL node starved of local pages

Deploy this configuration only after thorough testing

TempDB Usage

Be sure to tune TempDB for proper sizing as well as performance

TempDB usage is much more common in SS2005 (vs. SQL2000) See next slide

TempDB Usage in SQL Server 2005

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

DBCC CHECKDB - small change Internal objects: work file (hash join, SORT_IN_TEMPDB) - CTEs Internal objects: work table (cursor, spool) - small changes Large object (LOB) variables Service Broker Temporary objects: global/local temp table, table variables Temporary objects: SPs and cursors - small changes Version store: General Version store: MARS Version store: Online index, mapping index, sort operations Version store: Row version based isolation levels Version store: Triggers XML

Tempdb Isolation & Configuration

Tempdb placement (dedicated vs. shared physical disks)
Unless you understand Tempdb I/O characteristics it may be better to allocate Tempdb on spindles for data and indexes to utilize more cumulative disks

ROT: Tempdb 1 data file per CPU (core) on host server

Data files should be of equal size Pre-size data/log files do no rely on AUTOGROW
Exception: Testing to determine how much space will be needed

T1118 Disables mixed page allocations

Use if waitresource "2:1:1" (PFS Page) or "2:1:3" (SGAM Page) makes system appear unresponsive Refer to http://support.microsoft.com/kb/328551/ for problem description

Monitor and understand your own Tempdb usage

Sql Server:Transactions/FreeSpace in Tempdb (KB) Related DMVs
sys.dm_db_session_space_usage sys.dm_db_task_space_usage sys.dm_exec_requests

High Availability
Failover Clustering Database Mirroring Log Shipping

Replication is NOT supported

Log Shipping
Only User Databases can be Log Shipped Master DB

System Configuration

Logins

MSDB
SQL Agent Jobs

Backup History
DTS Packages saved in SQL Server

Log Shipping
Master Model

Databases Safe

MSDB
Only User Databases can be Log Shipped

AdventureWorks

TempDB

Failover Clustering

Pros

Very high availability Quick failover (5-90 seconds) Same IP Address All databases are safe. TempDb is cleared. Standard Edition can now be setup as a 2 node cluster. Enterprise Edition can now be setup as a 8 node cluster.

Cons

Hardware must be on Windows HCL Cost SAN is Point of Failure Can not protect against database Corruption Sensitive to Domain Controller outages SQL Server Service Pack application requires instance downtime Transactions in progress are rolled back Shared location

Failover Clustering
Master Model

Databases Safe

MSDB
TempDB is cleared on failover

AdventureWorks

TempDB

Database Mirroring

High availability operating mode

Synchronous with a witness Mirror acknowleges before commit to client Automatic Failover Mirror and Witness not reachable, DB goes offline

High protection operating mode

Synchronous without a witness Mirror acknowleges before commit to client Manual Failover

High performance operating mode

Asynchronous without a witness Manual Failover, possible data loss

Database Mirroring
Master Model

Databases Safe

MSDB
Only User Databases can be Mirrored

AdventureWorks

TempDB

Backup / Restore

SQL Server DB Level

DB Server Loss
DB Corruption DBA Error

STSADM.exe
Site Deleted (sites are not in Recyacvle Bin)
Backup/Resore to another Server Farm
STSADM.exe o backup directory \\moss\moss_backup -backupmethod full

Site
STSADM.exe -o backup -url http://intralot-portal -filename <filepath>.dat overwrite

All MySites
STSADM.exe -o backup -url http://mysites -filename c:\moss_backup\mysites.dat

overwrite

Microsoft System Center Data Protection Manager v2 (RTM Q4 2007)

Reporting Services
WSS 2007
Reporting Services Add-in

SQL Server 2005 SP2

SSRS Add-In Install

SSRS 2005
SP2 Report Server

Report Viewer Web Part

Report Management UI

Security Extension

Catalog Management

WSS Object Model

WSS Object Model

SharePoint Content DB

Report Server DB

RS Database Integration

WSS Content Database stores the master copy of SSRS items

Get Master Copy from WSS DB
NO ON

Run Report

Yes
Exists ?

Yes
Master ?

Schedules, caching, and subscriptions are stored in SSRS database only

No automated migration path from existing SSRS installations

RS - Security Mapping

SSRS security operations map to SharePoint Web or List rights.

CreateReport operation
Add Items

CreateReport( )

New Site permissions replace System permissions.

CreateSchedule( )

CreateSchedules operation

Manage Web Site

Model Item security is still managed by SSRS.

RS - Standard SharePoint Roles

SharePoint Role
Limited Access Read

Reporting Services Functionality

Can view shared schedules View/run reports, view data sources, models. Create and delete own subscriptions, view report history (snapshots). Create/edit/delete reports, data sources, models. Create/delete snapshots. Create/delete folders. Update properties? Create/edit/delete shared schedules. Create/edit/delete any subscription.

Contribute Design Full Control

Report Builder

Requires Use Remote Interfaces permission

RS - Security Modes

Windows Integrated & Trusted Account

Windows User

WSS Web Application with Windows Authentication

Windows User

NonWindows User

WSS Web Application (non-Kerberos or Custom Authentication)

Trusted Account &

SSRS SP2

SharePoint User token

Typical System DB growth - 4GB Content

Database Web Application Storage yr1 Storage yr3 Description

SharePoint_Admin_Content _{GUID} SharePoint_Config

SharePoint Central Administration v3 Writable from Central Administration, Read by all Web Applications SSP1 SSP1

60MB

100MB

Site Collection for Central Administration Web Site Hosts Configuration Information Common to all members of the Farm.

10MB

100MB

SSP1_DB SSP1_Search_DB

10MB 3MB

100MB 75GB

Shared Services Providing Content DB Responsible for storing search related data from indexing (Property Store, URL Maps) Content Database for SSP administration site. Crawl Database of SharePoint Help FIle

SSP1_WSS_Content

SSP1

14MB

100MB

WSS_Search_ServerName

Central Administration

60MB

100MB

The Search_DB also hosts the query log used for query reporting and analysis!

Microsoft IT
12TB of SharePoint data. 83GB index files (0.67 % of Content) 243GB Search database (1.97 % of Content)

Combined percentage for total index storage =

2.64%

Maximum single data DB size: 50Gb

Due to SLAs. 3.3GB/minute restore rate = 15 Minute downtime

More Information

SQLRAP - SQL Risk Assesment Program, delivered by Premier Support Services, ask your Technical Account Manager (TAM) SQL Server Customer Advisory Team: http://blogs.msdn.com/sqlcat Troubleshooting Performance Problems in SQL Server 2005 http://www.microsoft.com/technet/prodtechnol/sql/2005/tsp rfprb.mspx SQL Server User Group http://www.sqlpass-swiss.org/

11. to 12. April 2007 | Zurich, Switzerland

11. to 12. April 2007 | Zurich, Switzerland