Microsoft SQL Server:
Best Practices and Design
Guidelines for EMC Storage
EMC VNX Family, EMC Symmetrix VMAX Systems, and
EMC Xtrem Server Products
EMC Solutions
© Copyright 2013 EMC Corporation. All rights reserved.
1
Agenda
 Challenges of SQL Server environments today
 SQL Server
–
–
–
–
–
Architecture overview
Bandwidth characteristics
Storage sizing and provisioning best practices
Protection
Performance and load generation tools
 Summary
© Copyright 2013 EMC Corporation. All rights reserved.
2
Challenges of SQL Server Environments Today
 Maximizing performance
 Simplifying management and
provisioning
 Ensuring protection and recovery
 Optimizing SQL Server in data
warehouse configurations
 High-speed data analytics
 Best practices and expertise for SQL
Server with private and public cloud
© Copyright 2013 EMC Corporation. All rights reserved.
3
SQL Server Architecture Overview
Protocol layer
↑
Database engine
– Storage engine
– Query processor
▪ Query optimizer
▪ Query executor
↑
SQL OS
© Copyright 2013 EMC Corporation. All rights reserved.
4
SQL Server Versions and Features
Version
Product highlights
SQL
Server
2005
•
•
•
•
•
•
SQL
Server
2008 R2
• CPU can be added dynamically
• Resource governor
• Scale-out servers: Large-scale data
center/data warehouse support
SQL
Server
2012
•
•
•
•
Full text search
Failover clustering
Database mirroring
Log shipping
Database snapshot
Hot add memory
AlwaysOn High Availability
Blazing-fast performance
Optimized for private cloud
Multi-server manageability
© Copyright 2013 EMC Corporation. All rights reserved.
Licensing models
Standard
Server/CAL or per processor
Enterprise
Server/CAL or per processor
Datacenter
Per processor
Standard
Server/CAL or per core
BI
Server/CAL
Enterprise
Per core
Virtualization
Standard
Single virtual machine per license
Enterprise
Up to four virtual machines per
license
Data center
Unlimited virtual machine per
license
Enterprise
All physical hardware cores
Unlimited virtual machine per
license
Standard/Enterprise
License a single virtual machine
based on virtual processors used
5
SQL Server I/O and Bandwidth Characteristics
I/O types and
characteristics
User database
data files
Tempdb
data file
Database
log files
Online Transaction Processing (OLTP)
• Smaller and random I/Os ( 8 -64 KB)
• High read/write ratio ( typically 90/10 ~ 70/30)
• High IOPS/low latency and high protection
requirements
Decision support system
(data warehouse, OLAP)
• Larger sequential I/Os (>= 64 KB, >256 KB with
columnstore index)
• High read/write ratio, sometimes read-only
• High bandwidth/low latency and high capacity
requirements
• Varying size depending on usage (usually larger I/Os, typically does not exceed 64 KB)
• Serial or random I/Os, concurrent sequential workload may give random I/O appearance
• Usually near 50/50 read/write
• Usually not very active with low performance
demand
• Can be very active for frequent reporting and
large table joins
•
•
•
•
•
• Can have high performance demand and may
warrant flash storage
Small, highly sequential I/Os (multiple of 512 bytes up to a max of 61 KB). Typically 8-9.5KB I/Os.
Almost exclusively writes, with occasional reads for large rollbacks or log backups and replications.
RAID 1/0 is the recommended standard. RAID 5 may provide adequate performance.
Being sequential, expect a 2+2 RAID 1/0 SAS 10K configuration to sustain up to 1,500 IOPS.
Write coalescing is expected.
© Copyright 2013 EMC Corporation. All rights reserved.
6
SQL Server Design Best Practices
• SQL Server design considerations:
–
–
–
–
–
–
–
Workload characteristics -OLTP, DW, and OLAP (mixed)
Deployment scenario (SQL Server consolidation, virtualization)
High Availability (Virtualization HA, SQL Server Cluster HA)
Scale of deployment - database size
Performance requirements
Array architecture (RAID, storage pools, thin LUNs, etc.)
Backup/restore, disaster recovery requirements, etc.
© Copyright 2013 EMC Corporation. All rights reserved.
7
Storage Sizing and Provisioning – Performance Layout
 Five types of LUNs for SQL Server
–
–
–
–
–
OS LUN
System database LUN
User database LUN(s)
Log LUN
Tempdb LUN(s)
 Three types of pools*
– OS pool
– Database pool
– Log/Tempdb pool
 Design for database profiles
– OLTP
– OLAP
* Best-performance deployment scenario for midrange environment.
In newer EMC storage arrays with FAST technology enabling efficient use of flash drives, it is
possible to deploy the user database and log/Tempdb LUNs to the same pool, and pin the
log/Tempdb LUNs to the SAS/Fibre Channel (FC) tier of that pool.
© Copyright 2013 EMC Corporation. All rights reserved.
8
SQL Server Disks Options
Drive types
8 KB IOPS per disk
SSD flash
3,500
15k rpm FC/SAS
180
10k rpm FC/SAS
140
7.2k rpm SATA/NL-SAS
70
• Deploy SQL Server on:
– Flash and SAS/FC drives for better
performance
– SATA/NL-SAS drives for lower cost
EMC XtremSF performance information
Random
8K IOPS
XSF550
MLC *
Read
only
Write
only
R/W
70/30
XSF550
MLC *
• All disk types are supported for
SQL Server
XSF2200
MLC *
XSF2200
MLC *
XSF320
SLC
XSF700
SLC
131,795 128,207
258,838
256,887
376,072
395,906
23,592
16,235
53,713
35,654
67,635
133,593
56,255
42,471
120,162
93,848
171,666
191,169
• Utilize storage virtual
provisioning as much as
possible:
– FAST VP automatically tiers data
on storage with various drive
types.
– Thin LUNs can be extended as
needed.
* In performance mode, IOPS will be lower when configured in default
capacity mode.
© Copyright 2013 EMC Corporation. All rights reserved.
9
Storage Pools and RAID Groups
 Use storage pools for options such as FAST VP, compression, and
deduplication.
– Use thin LUNs with pools for:
▪ Easy management
▪ Best space efficiency
▪ Energy and capital savings
▪ Databases with changing space consumption over time
– VNX - Use thick LUNs in storage pools for:
▪ Databases with predictable space and high performance requirements
 VNX — On exception, use RAID groups and traditional LUNs for:
–
–
–
–
Databases with fixed size and performance requirements
Precise placement of logical data objects on physical drives
Physical separation of data
Absolute maximum performance instead of taking the advantages of pools
© Copyright 2013 EMC Corporation. All rights reserved.
10
I/O Characteristics for Various RAID Types
I/O characteristics
RAID 1/0
RAID 5
RAID 6
Read
Excellent
Excellent
Excellent
Write
Excellent
Moderate
Poor
Read
Excellent
Good
Good
Write
Excellent
Moderate
Moderate
RAID write overhead
2
4
6
Disk capacity utilization1
1/2
4/5 (in 4+1 R5)
4/6 (in 4+ 2 R6)
Minimal drives required2
4
3
6
Random I/O
Sequential I/O
1
2
Depends on the size of RAID group
Depends on the array
© Copyright 2013 EMC Corporation. All rights reserved.
11
SQL Server Best Practices:
Basic Best Practices for SQL Server
 Select “Lock pages in memory” policy for SQL Server start account to prevent SQL
Server memory swap.
 Enable the advanced privilege of “Perform Volume Maintenance Tasks” to the SQL
Server Service account to enable instant initialization of database data files.
 Avoid Autogrow by pre-allocate data files.
 Grow all files in a single filegroup together when possible.
 Set Autoshrink to “off” for data and log files.
 Make data files with equal size in the same filegroup.
 Perform routine maintenance with index rebuild or reorganization with dbcc checkdb.
 Format NTFS volumes with 64K allocation unit for SQL Server LUNs.
Volume partition
Disk
Volume
Allocation size
Formatting options
MBR
Basic
NTFS
64 KB
Quick format*
© Copyright 2013 EMC Corporation. All rights reserved.
*
Required for
thin LUN
12
SQL Server Design Best Practices
Filegroup Consideration
 Performance
– Use filegroups to separate tables/indexes — at the disk level (use with caution)
– Separate objects requiring more data files because of the high page allocation
rate
 Administration considerations
– Backup can be performed at the filegroup or file level
– Partial availability
▪ When the primary filegroup is available, other filegroups can be offline.
▪ A filegroup is available if all its files are available.
– Tables and indexes
▪ Can use separate filegroups for in-row data and large-object data.
– Partitioned tables
▪ Each partition can be in its own filegroup.
▪ Partitions can be switched in and out of the table for better archiving strategy.
© Copyright 2013 EMC Corporation. All rights reserved.
13
SQL Server Best Practices:
Filegroup and File Considerations
 Put data files with similar performance and protection needs to the
same filegroup.
 Grow the databases equally to ensure proportional fill.
 Filegroups can be accessed in parallel.
– Can use different set of disk and storage pool for performance.
 Create 0.25-1 data file per filegroup for each CPU to allocate intensive
databases such as Tempdb.
 Start with a small number of data files. Increase when needed.
 Only one log file can be available for the entire database.
© Copyright 2013 EMC Corporation. All rights reserved.
14
SQL Server Best Practices:
Storage Consideration
 Check the EMC Support Matrix
– Use up-to-date manufacture recommended HBA drivers.
– Ensure storage array firmware is up to date.




Use multipath software such as PowerPath.
Do not exceed 80 percent capacity of LUNs for the database file.
Put Tempdb, user database, and log files on separate LUNs for recovery considerations.
For optimal performance, put
– User database LUNs on faster drives or pools with auto-tiering.
– Log/Tempdb LUNs on FC/SAS drives or pools without auto-tiering.
 For easy management with acceptable performance,
– Database LUNs and log, and Tempdb LUNs can share the same storage pools (pin the log
LUNs and Tempdb LUNs in the FC/SAS tier if needed).
© Copyright 2013 EMC Corporation. All rights reserved.
15
SQL Server Best Practices:
Storage Sizing (OLTP Databases)
 Sizing for performance — Calculate disk numbers for IOPS with:
𝑅𝑒𝑎𝑑 𝐼𝑂𝑃𝑆 + 𝑊𝑟𝑖𝑡𝑒 𝐼𝑂𝑃𝑆 × 𝑅𝐴𝐼𝐷 𝑝𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 disks =
𝐼𝑂𝑃𝑆 𝑝𝑒𝑟 𝐷𝑖𝑠𝑘
 Sizing for capacity — Calculate disk numbers for capacity with:
𝑇𝑜𝑡𝑎𝑙 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑛𝑒𝑒𝑑
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 =
𝑅𝐴𝐼𝐷 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦
 Final design:
– Choose the number of disks meeting both performance and capacity requirements.
– Round up to the next logical drive count with its specific RAID type.
– Meet the minimum disk requirement for the RAID type.
© Copyright 2013 EMC Corporation. All rights reserved.
16
SQL Server Best Practices:
OLAP Database Design Considerations
 For predictable bandwidth and performance, EMC recommends a
building-block approach considering the following:
–
–
–
–
–
Targeted bandwidth
Memory consumption
CPU number
Tempdb sizing
Database sizing
Sample building blocks
Configuration
500 GB building block
1 TB building block
2 TB building block
Database size
500 GB
1 TB
2 TB
Target bandwidth
(MB/s)
Database LUN
design
100
200
400
1 x 2 TB data LUN
2 x 2 TB data LUN
4x 2 TB data LUN
8x80 GB data file
8x126 GB data file
16x126 GB data file
Log design
1 log LUN
1 log LUN
1 log LUN
Log file: 5 GB
1(1x100 GB data file)
Log file: 12 GB
1 (2x 100 GB data file)
Log file: 12 GB
1 (4x 100 GB data file)
1(1X2 GB log file )
1 (1X 2 GB log file)
1 (1X 2 GB log file)
5 SAS disks
8
2
10 SAS disks
16
4
20 SAS disks
32
8
Tempdb
design
Data
LUN
Log
LUN
Disk configuration
Memory (GB)
CPU (2.4 GHz)
© Copyright 2013 EMC Corporation. All rights reserved.
17
SQL Server Best Practices:
Storage Sizing (OLAP Databases)
 Calculate the number of disks needed for performance with the
following:
𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑏𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠𝑓𝑜𝑟 𝑝𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 =
𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ 𝑝𝑒𝑟 𝑑𝑖𝑠𝑘
 Calculate the number of disks needed for capacity with the following:
𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 =
𝑅𝐴𝐼𝐷 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦
 Final design:
– Choose the number of disks meeting both performance and capacity requirements.
– Round up to the next logical drive count with its specific RAID type.
– Meet the minimum disk requirement for the RAID type.
© Copyright 2013 EMC Corporation. All rights reserved.
18
VMAX Considerations
 Create fewer larger hypervolumes within metavolumes to improve
performance.
 Use a minimum of two HBAs/servers; each HBA connects to at least
two direct ports (across multiple VMAX engines, if possible).
 Use striped metavolumes for thick and thin LUNs.
 Use Virtual Provisioning with thin LUNs when:
– Storage over-allocation is needed.
– Rapid growth over time is expected but downtime is limited.
 Monitor pools to avoid running out of space.
 As an exception, use traditional devices where:
– Shared allocations from a common pool are not desired.
– Large amount of deleted space cannot be reclaimed.
– An occasional response time increase of approximately 1 millisecond is not
tolerable, because of writes to uninitialized blocks.
© Copyright 2013 EMC Corporation. All rights reserved.
19
FAST VP and FAST Cache
Virtual Server
SQL Server
Virtual Server
Virtual Server
SQL Server
SharePoint
F
C
Virtual Server Virtual Server Virtual Server
SQL Server
FAST VP
FAST Cache
A VMAX and VNX feature
that automates the
identification of data for
allocating or reallocating
across various
performance and
capacity tiers within the
storage array
A VNX performance
optimization feature that
provides performance
boost to frequently
accessed data by
leveraging the use of
flash drives to extend
cache capacities
© Copyright 2013 EMC Corporation. All rights reserved.
SQL Server
SharePoint
FAST Cache
Flash
SAS
NL
SAS
20
FAST VP Tiering Considerations
 Size the top tier in FAST VP to ensure the hot areas of the working set(s) can be
accommodated in the highest performance tier.
 Use at least a small amount of flash rather than no flash in Virtual Provisioning pools
to handle wide spectrum of I/O profiles in VNX environment.
 Use high capacity drives to optimize total cost of ownership (TCO) where there are
large datasets with high skews.
 Determine the I/O skew before sizing FAST VP tiers.
 The Symmetrix VMAX storage arrays support up to four tiers.
 When using FAST VP with AlwaysOn Availability Groups, place Availability Group
copies of the database in different pools for better availability.
© Copyright 2013 EMC Corporation. All rights reserved.
21
FAST VP Configuration Recommendations
 Thin LUNs can be used on VMAX and the latest VNX to provide desired performance.
 Data
– OLTP random workloads with high skew. High FAST VP benefit.
▪ Typically a 15/85 (hot/cold) or 10/15/75 (hot/warm/code) data skew.
– In OLAP, sequential read-only data without skew. Low FAST VP benefit.
▪ Can be in a FC/SAS-only tier without FAST VP or pinned to the tier.
 Logs – Sequential data without skew. No FAST VP benefit.
– Can be in a separate pool or pinned to the FC/SAS tier.
 Tempdb – Mostly sequential data without skew. No FAST VP benefit.
– In OLTP, it can be pinned in the FC or SAS tier.
– In OLAP, it might need to be in the flash or FC/SAS tier for better performance.
 Use dedicated pools for database LUNs for better service-level agreement (SLA)
guarantee, fault domain, and most deterministic behavior.
© Copyright 2013 EMC Corporation. All rights reserved.
22
Tools for FAST VP
 Tier Advisor for sizing
– Historical performance data is needed from storage arrays.
 Workload Performance Assessment Tool
– It shows FAST VP heat map. For more information, refer to
https://emc.mitrend.com.
 VSPEX Sizing Tool (for VNX)
– For more information, refer to http://www.emc.com/microsites/vspexebook/vspex-solutions.htm.
 EMC Professional Services and qualified partners can assist in properly
sizing tiers and pools to maximize investment.
© Copyright 2013 EMC Corporation. All rights reserved.
23
FAST VP versus FAST Cache on EMC VNX Storage
FAST VP
FAST Cache
Leverages pools to provide sub-LUN tiering,
enabling the utilization of multiple tiers of storage
Simultaneously.
Enables flash drives to extend the
existing caching capacity of the storage system.
Use 1 GB chunks (256 MB in Rockies).
Use 64 KB chunks.
Local feature – per storage pool.
Assured performance per pool.
Global feature – per storage array. Shared resource,
performance for one pool is not guaranteed under
FAST Cache performance contention.
Moves data between different storage tiers based
on a weighted average of access statistics collected
over a period of time.
Copies data from hard disks to flash disks when
accessed frequently.
Uses a relocation window to periodically make
storage tiering adjustments. Default setting is an 8hour relocation window each day.
Adapts continuously to changes in workload.
While it can improve performance, it is primarily
designed to improve usability and reduce TCO.
Designed primarily to improve performance.
© Copyright 2013 EMC Corporation. All rights reserved.
24
VNX Considerations for FAST VP and FAST Cache
 When the number of flash drives is limited, use flash drives to create
FAST Cache first.
– FAST Cache can benefit multiple pools in the storage system.
– FAST Cache uses 64 KB chunks, smaller than 1 GB or 256 MB chunks in FAST VP,
which results in higher performance benefits and faster reaction time for
changing usage patterns.
 Use flash drives to create the FAST VP performance tier for a specific
pool. This ensures the performance of certain mission-critical data.
– The FAST VP tier is dedicated to a storage pool and cannot be shared with other
storage pools in the same storage array.
© Copyright 2013 EMC Corporation. All rights reserved.
25
VNX Considerations for FAST VP
 Control the relocation window for FAST VP to prevent any impact on
host I/O requests during known periods of high system usage.
 Database LUNs:
– Apply FAST VP to all pool-based database LUNs.
– Use default FAST policy “Start High then Auto Tier.”
 For log LUNs:
– Pin to the SAS tier logs (lowest available tier in a flash/SAS pool).
 For Tempdb:
– In OLTP workloads, pin to the SAS tier and do not allow data relocation for these
LUNs.
– In OLAP workloads, put Tempdb in a faster tier.
© Copyright 2013 EMC Corporation. All rights reserved.
26
Server Flash – XtremSF Considerations
 Use eMLC NAND XtremSF where
– High performance is required at an attractive cost per bit
 Use SLC NAND XtremSF where
– It is less cost sensitive, seeking higher performance over time
 In the OLAP/data warehouse environment,
– XtremSF can be used as Tempdb storage with high demand to reduce the
contention of Tempdb, which improves the bandwidth
 XtremSF is a good choice for environments with
– Extreme performance requirements
– Current SAN latency issues
– SQL Server databases with high read ratio
© Copyright 2013 EMC Corporation. All rights reserved.
27
Server Flash - EMC XtremSW Cache Considerations
 Use XtremSW Cache predictor tool
– For initial benefit analysis of the SQL Server database with XtremSW Cache
 Use XtremSW Cache for
– Read acceleration
– Smaller working sets (higher skews)
 Set the page size to 64 KB or higher in the XtremSW Cache
– To accommodate the I/O sizes achieved for the SQL Server data file reads
 In the OLTP database environment:
– Use XtremSW Cache for read-intensive user data LUNs with heavy workload
– XtremSW Cache is not beneficial for write-intensive log and Tempdb LUNs
© Copyright 2013 EMC Corporation. All rights reserved.
28
Server Flash - EMC XtremSW Cache (Continued)
 Secondary databases need to be accelerated on AlwaysOn Availability
Groups only when required performance is desired.
– Example: Secondary databases used for OLAP (read-only) workloads
 If the workload is not expected to be increased, additional system
resources such as memory or CPU are not needed.
 Have at least two XtremSF cards within the server infrastructure when
redundancy is required.
 XtremSW Cache deduplication is generally not beneficial to the I/O
pattern of SQL Server.
© Copyright 2013 EMC Corporation. All rights reserved.
29
Server Flash - Sizing
Application
Database
workload type
Read-to-write
ratio
Recommended XtremSW
Cache-to-storage ratio
SQL Server
OLTP
90:10
1:10
SQL Server
OLTP
70:30
1:5
SQL Server
OLAP
100% read
1:5 (Tempdb on XtremSF: database
size)
SharePoint
Content/crawl
100% read
1:5
© Copyright 2013 EMC Corporation. All rights reserved.
30
Server Flash - Virtual Environment Considerations
 Use at least two XtremSF cards within the hypervisor server
infrastructure for redundancy if required (one per server).
 Calculate the XtremSF capacity and placement for VMware vMotion
support.
– The remaining server and XtremSF capacity is still able to serve the configured
XtremSW Cache settings of all virtual machines when vMotion occurs.
 Share XtremSF card among virtual machines on the same host.
– On exception for extreme performance, the option to dedicate the card to a single
virtual machine is possible.
 On exception, it is possible to install multiple XtremSF cards on the same
server.
© Copyright 2013 EMC Corporation. All rights reserved.
31
Storage Consideration for Protection Need
 Sizing for protection — Calculate disk needs for clone or snapshot
– Clone needs to have the same size of the production LUN, but they can be on the
storage pool with a different RAID group and disk type.
– The snapshot size depends on the change rate of the database, which is usually
much smaller.
 SQL Server AlwaysOn Availability Group requires separate storage for secondary copy
of the database.
© Copyright 2013 EMC Corporation. All rights reserved.
32
SQL Server Data Protection
Continuous Availability
Tool/System
RecoverPoint
Features
CDP
Description
 Synchronous
CRR
 Local recovery protection
 Asynchronous
CLR
 Continuous remote replication
 Concurrent local and remote data
 Combines CDP and CRR
VMAX/VNX with
RecoverPoint
splitter build-in
CDP/CRR/CLR
Both VMAX and VNX arrays have options with
built-in RecoverPoint splitter that can function as
native continuous availability
VMAX
SRDF
Continuous replication
© Copyright 2013 EMC Corporation. All rights reserved.
33
SQL Server Data Protection
Point-in-time Rapid Replication Recovery
Tool/System
AppSync
Replication
Manager
VMAX
TimeFinder
Features
Snapshot only
replication on
VNX
Snapshot/clone,
SAN copy for
VMAX and VNX
Mirror
Description
A simple, SLA-driven, self-service data protection, and storage
management for SQL Server. No agent is needed.
Clone
Clone sessions generally consume the same size of production LUNs, but
do not have any impact once created.
Snapshot sessions consume less space than clone and have more impact
on production LUNs if the data changes frequently on production LUNs.
Clone sessions generally consume the same size of production LUNs, but
do not have any impact once created.
Snapshot sessions consume less space than clone and have more impact
on production LUNs if the data changes frequently on production LUNs.
Snap
VNX
Clone
Snap
© Copyright 2013 EMC Corporation. All rights reserved.
A comprehensive data protection software. An agent on SQL Server is
needed.
BCV monitors and controls operations for business continuance volumes.
34
SQL Server Data Protection
Point-in-time Efficient Backup and Restore
Tool/System
Features
EMC Networker
Traditional backup and
restore software
EMC Avamar
Complete software and
hardware solution
Description
Variable-length deduplication significantly reduces
the backup time by only storing unique daily changes
while maintaining daily full backups for immediate,
single-step restore.
Centralizes, automates, and accelerates data backup
and recovery. A wide range of data protection
options.
 With medium to high workloads, do not take backups directly from the
production SQL Server.
– Mount a point-in-time snapshot or clone with replication manager on a different
server and take the backup from that server.
– Take a backup with a secondary copy in an AlwaysOn Availability Group.
 Schedule backups to take place during off hours, whenever possible.
© Copyright 2013 EMC Corporation. All rights reserved.
35
SQL Server Data Protection
Disaster Recovery Offerings for SQL Server
Offering
AlwaysOn Availability
Groups
Database portability
Server/site move
Replication
method
Description
SQL Server native
continuous replication
Built into SQL Server 2012 for high availability
and disaster recovery.
EMC RecoverPoint
Only SQL Server data is replicated. Requires
DNS changes when it is failed over to the
secondary replica.
SQL Server data (some time OS data too) are
replicated. Failover includes server start, IP
change, and DNS update.
EMC
EMC
EMC
EMC
EMC
VPLEX
RecoverPoint*
VPLEX
Cluster Enabler
Replicator
*RecoverPoint can also work with Cluster Enabler for automatic failover.
 For the VMware environment, vCenter Site Recovery Manager (SRM) provides automated
disaster recovery for fast and efficient recovery of critical applications such as SQL Server.
© Copyright 2013 EMC Corporation. All rights reserved.
36
ESI Considerations
 Use EMC Storage Integrator (ESI) for storage provisioning and monitoring
whenever possible.
 ESI
– Simplifies the storage management for Windows.
– Automatically applies some best practices with the storage configuration.
– Simplifies the storage deployment for Windows.
© Copyright 2013 EMC Corporation. All rights reserved.
37
SQL Server Performance Tools for Monitoring, Tuning,
and Sizing — Application Level
Tool
DBclassify
Perfcollect
Source/Links
EMC
http://www.emc.com/do
mains/zettapoint/index.h
tm
EMC
http://emc.ms/Perfcollect
Description
Open source
http://www.codeplex.co
m/PAL
Performance Analyzer of Logs. Useful for
troubleshooting performance issues.
Constantly monitors data, learns its patterns and
past behavior, and then classifies and moves it
according to business priorities.
Automates SQL Server related performance data
collection. Mainly used for storage and virtual
environment sizing.
Also known as “Mitrend.” An automated online
EMC
EMC
https://emc.mitrend.com workload performance assessment tool, which
Workload
correlates and displays key performance
Performance
information related to sizing.
Assessment
PAL
© Copyright 2013 EMC Corporation. All rights reserved.
38
SQL Server Performance Tools for Monitoring, Tuning,
and Sizing — SQL Server Level
Tool
Source/Links
VSPEX SQL EMC
sizing tool http://express.salire
.com/go/emc
Microsoft SQL server
T-SQL
SQL Server Microsoft SQL Server
analysis Services
profiler
Description
Can be used to determine the recommended VSPEX
Proven Infrastructure for virtualized SQL Server based on
the user requirements.
Provides stored procedures to create traces on SQL
Server instance.
Provides SQL Trace capture and replay in a graphic user
interface.
DTA
Microsoft SQL Server
analysis Services
SQL Database Tuning Advisor provides SQL Server tuning
suggestion such as indexing and partitioning.
DMVs
Microsoft SQL Server
analysis Services
Dynamic Management Views are query structures that
expose information about local server operations and
server health.
© Copyright 2013 EMC Corporation. All rights reserved.
39
SQL Server Performance Tools for Monitoring, Tuning,
and Sizing — Host/Hypervisor Level
Level
Tool
Source/Links
Description
vSphere client
GUI interface
VSphere client
GUI
The primary tool for observing
performance and configuring data for
one or more ESX/ESXi hosts.
Resxtop/Esxtop
ESX/ESXi
Provides more performance matrix,
but needs root access.
Perfmon
Windows
performance
monitor
Provides both hyper-V and virtual
machine level performance matrix.
Perfmon
Windows host
VMware
Windows server
installation
Hyper
visor
Hyper-V
© Copyright 2013 EMC Corporation. All rights reserved.
Windows Performance monitor can
track the performance characteristics
of SQL Server workloads.
40
SQL Server Performance Tools for Monitoring, Tuning,
and Sizing — Storage Level
Tool
Source/Links
Unisphere Analyzer Comes with EMC
storage array
Description
Performance monitoring tool for EMC storage arrays.
XtremSW Cache
performance
predictor tool
https://support.e
Performance predictor tool for EMC XtremSW Cache;
mc.com/search/?p can be used to assess and evaluate the SQL Server
roduct_id=25208& environment for the XtremSW Cache.
text=predictor
EMC Storage
Configuration
Advisor
Available through
EMC pre- and
post-sales
© Copyright 2013 EMC Corporation. All rights reserved.
Assists in defining tiering policies for an existing
environment. Tier Advisor monitors your I/O and
recommends tiering policy settings.
41
Perfmon in Details
Key counters to monitor for OLTP database
SAN environment
Average disk
second/transfer
Average disk second/read
Average disk second/write
Average disk bytes/transfer
Disk bytes/second
Disk reads/second
Disk writes/second
© Copyright 2013 EMC Corporation. All rights reserved.
NAS environment
Average second/data
request
Average second/read
Average second/write
Avg data bytes/request
Data requests/second
Read requests/second
Write requests/second
Measured feature
Overall storage latency
Read latency
Write latency
I/O size
Throughput
Read I/O/second
Write I/O/second
42
Perfmon in Details (Continued)
Guide line latency for OLTP database
Ideal
<10ms
Average latency
5-20ms read
Peak latency
<50ms read
<=25ms
25-30ms read
<50ms read
Transaction logs
<1ms
1-5ms write
<50ms write
System/Page
partition
<10ms
<10ms read/write
<10ms read/write
Workload
OLTP
Database DSS/DW
OLAP
© Copyright 2013 EMC Corporation. All rights reserved.
43
Summary
 Because storage technologies are evolving rapidly, traditional
best practices may not apply to all configurations.
 Understand the I/O and bandwidth characteristics of SQL Server;
use proper tools to determine the workloads.
 Apply best practices for SQL Server with VNX family, VMAX series
storage, and Xtrem Server flash products.
 Utilize SQL Server storage building blocks if possible.
 Calculate storage I/O, capacity, and bandwidth requirements.
 Validate your overall storage design.
 Become familiar with various data protection options for SQL
Server.
© Copyright 2013 EMC Corporation. All rights reserved.
44
Q&A
© Copyright 2013 EMC Corporation. All rights reserved.
45
THANK YOU
© Copyright 2013 EMC Corporation. All rights reserved.
46