SQL Server Club - SQL Server Enterprise Consolidation - charley hanania

06 May 2008 SQL Club Meeting – Lausanne, Switzerland
SQL Server Club
6th of May 2008
Lausanne, Switzerland

Consolidation Strategies for MS SQL Server
for Manageability and Efficiency of Enterprise Platforms
Charley Hanania
B.Sc (Computing Science), MCP, MCDBA, MCITP, MCTS, MCT
UBS Investment Bank
Charley.Hanania@gmail.com

General Overview
 Manageability and efficiency of platforms through
consolidation are key drivers in IT strategy.
 This session focuses on reviewing some of the guiding
principles of these drivers, as well as looking at what
things should be taken into account when looking at a
SQL Server consolidation strategy.

Agenda
 Enterprise Rationalisation
 Keys Drivers to Success
 Technology Considerations
 Recap
 Questions

Enterprise Rationalisation
 What are your drivers to Rationalisation?
 Service Delivery Quality Improvements
 Mergers and Acquisitions
 Business Model Design / Redesign
 Total Cost of Ownership (TCO) Reductions
 .
 .
 .
 General Business Profitability…
The Triggers…

 Server Utilisation Rates
 5-10%
 10-15%
 15-20%
 Service Level Agreements not being met
 Active Directory reaching Capacity
 Monitoring Infrastructure Overloaded
 Resource (human) to Component ratio not optimal.
 Platform Stability & Standards a thing of Myth and Legend
 Root Cause Analysis
 Change Management
 Application Availability
Truth be told…

Bad
Operational Habits
To sum it up

Key Drivers to Success
 Long Term Strategies
 What are the key drivers of your organisation?
 What’s the Utopia of Operations for you?
 Don’t treat the rationalisation as a Project
 Turn it into a strategy
○ If your operations are healthy then your business will have a very
good chance at being guided by solid reasoning.
 Look at what IT needs to achieve, and architect the solutions
around what the technologies of the time can afford.
Lies not in the technologies…

This won’t be easy…
The Strategy:
…But it is possible.

Gartner Inc:
“…Poll Confirms Internal Politics is the Major
Problem Area for Server Consolidation
Rationalisation…”
John R Phelps, 1 Feb 2007
The Strategy:
“Train up a child in the way he should go and
when he is old, he will not depart from it.”
(Proverbs 22:6)

Technology Considerations
Overriding approaches available currently…
Do Nothing
Server
Farms
Virtualise

Don’t Consolidate…
Do Nothing
Server
Farms
Virtualise
 System too:
○ Critical
○ Complex
○ Badly Written
 System is:
○ Managed Externally (3rd Party)
○ Legacy
○ High Risk
 User Base is too Broad
○ Measuring true utilisation and risk is too difficult

Virtualise…
Do Nothing
Server
Farms
Virtualise
 Why:
○ If CPU / Memory etc metrics show that you severely
underutilise hardware, then co-existence in VM's might
be slower but a viable approach.
 eg: if 8% CPU and 10% memory used on a server, then
going for an 8:1 consolidation ratio may be viable.
 Why Not:
○ OS Disk Space and Memory overhead,
abstraction/obfuscation of performance indicators.

Server Farms… (“Databases as a Service”)
Do Nothing
Server
Farms
Virtualise
 Why:
○ Great Consolidation Ratios
○ SQL server manages its memory space well
 x64: a good option to better utilise memory and resources.
○ Pushes for simpler/better coded DB objects
○ Organisational discipline
 Long Term Benefit…

Do Nothing
Server
Farms
Virtualise
 Why Not:
○ instance suffers from lowest common denominator, so if
a third party or legacy application needs to use SA,
you'll open up SA exposing all databases within the
instance.
 Other lockdown areas; xp_cmdshell, DAC, CLR etc
○ Object clashes within the instance scope; logins with
default databases, logins, database names, SSIS
packages
○ Database profile - OLTP, DSS, data warehouse, batch
jobs, etc.

Do Nothing
Server
Farms
Virtualise
 Additional options:
○ Many DB's to one instance
○ Many instances per machine.
 Allows logical and configuration isolation for databases
within the instance
 if a hot fix is needed, then that hot fix can be focussed to
affect the smallest subset of databases.
 Why not:
○ slight capacity planning overhead on memory side.
 General Rule of Thumb is (memory - OS pool)/(x instances)
 Note: needs more detailed planning than general RoT

Other Considerations
 Infrastructure
○ Many AD computer objects
○ SNMP traps or MOM/SCOM/Foglight events per server etc raise many more informational alerts
per OS than if all just on one.
○ Simpler view on scope of capacity issues or performance but many more to shift focus to.
○ Server racks, data centre space, etc, (licences, hardware, electricity, rental, sight rental etc)
 Operational
○ Patching
○ Tracking permission breaches or security vulnerabilities
○ Number of DBA's per server decreases or more DBA's / Operations Staff to handle many
servers
○ Difficult to maintain consistency plus control over the environment
○ Higher risk of component failure/ lower scope of impact
 Financial
○ DBA costs (MS DBA's cost as much as Oracle DBA's now!!)
○ Licensing costs-SQL/windows
○ hardware costs and maintenance agreements
○ Redundant hardware component costs
○ Server room space etc
Overhead of Many Servers…

Other Considerations
 Infrastructure
○ Well… None!
 Operational
○ Structured approach to operations support
○ Stringent change control policies and communications
○ Concentration risk for outages on:
 Number of DB's within scope
 Instance
 Server
 Data Centre
○ Monitoring tools need to be well configured (thresholds and filters)
○ Adequate capacity planning tools and capacity management procedures
○ Application teams following a development framework (including induction process)
 Financial
○ Larger capacity servers to handle federated approach (CPU's, network cards, disks and disk arrays)
○ Possible investment in DR technologies (GEO clusters, SAN replication)
○ Investment in network abstraction technologies (Big IP/F5, DNS etc for failover or re-placement of DB's
○ Training
 Developer inductions on standards, best practices and procedures
 Admin inductions on procedures, policies and standards
Overhead of Fewer Servers…

“Core” Technical Considerations
 Server Level
○ SSIS packages
○ SQL Version
○ I/O Utilisation
○ Network Utilisation
 In / Out
○ Memory Utilisation
 Per Instance
○ Availability Needs
 Clustering
SQL Server Specific…
 Instance Level
○ Patch Levels
○ Collations
○ DB Names
○ Login Types
○ Linked Servers
○ Login Names
○ Login/User Privileges
○ Instance Options (Configuration Settings)
○ SQL Version
○ Number Of Users Connected
 Clustering
 Replication
 Mirroring
 Inter-database Synchronisation

“Core” Technical Considerations
 Database Level
○ I/O Utilisation
 Temp DB
 Data
 Log
 Partitioning
 Replication
 Log Shipping
 Mirroring
 Inter-database Synchronisation
○ DB Importance
 Recovery Priority/Sequence
SQL Server Specific…
 Operations
○ Provisioning Process (Provisioning Tool)
○ Database
○ Login / User Creation
○ Capacity Planning
○ Exceptional Feature Requests
○ Change Windows
○ Largest Tables
○ Special Needs eg: Partitioning
○ System Profile
○ Batched Runs
○ OLTP
○ Execution Times

Performance Counters
Object Counter Instance
LogicalDisk % Disk Time _Total
LogicalDisk % Disk Time …Each Disk…
LogicalDisk Avg. Disk Queue Length _Total
LogicalDisk Avg. Disk Queue Length …Each Disk…
LogicalDisk
Current Disk Queue
Length
_Total
LogicalDisk
Current Disk Queue
Length
…Each Disk…
Memory Available Bytes
Memory Page Faults/sec
Memory Pages/sec
Network Interface Bytes Received/sec …Each Card…
Network Interface Bytes Sent/sec …Each Card…
Network Interface Output Queue Length …Each Card…
PhysicalDisk Avg. Disk Queue Length _Total
PhysicalDisk Avg. Disk Queue Length …Each Disk…
Process % Processor Time _Total
Process % Processor Time MsDtsSrvr
Process % Processor Time msftesql
Process % Processor Time SQLAGENT90
Process % Processor Time sqlbrowser
Process % Processor Time sqlservr
Process % Processor Time SqlWb
Process % Processor Time sqlwriter
Processor % Processor Time _Total
Processor % Processor Time …Each Processor…
Object Counter Instance
Processor % User Time _Total
Processor % User Time …Each Processor…
SQLServer:Buffer
Manager
Buffer cache hit ratio
SQLServer:Buffer
Manager
Page life expectancy
SQLServer:Buffer
Manager
Page reads/sec
SQLServer:Buffer
Manager
Page writes/sec
SQLServer:Gener
al Statistics
User Connections
SQLServer:Locks Lock Wait Time (ms) _Total
SQLServer:Locks Lock Waits/sec _Total
SQLServer:Memo
ry Manager
Connection Memory
(KB)
SQLServer:Memo
ry Manager
Memory Grants
Outstanding
SQLServer:Memo
ry Manager
Memory Grants Pending
SQLServer:Wait
Statistics
Log write waits Waits in progress
SQLServer:Wait
Statistics
Memory grant queue
waits
Waits in progress
SQLServer:Wait
Statistics
Page IO latch waits Waits in progress
System
Processor Queue
Length
Use the following Counters to baseline application workload profile
and measure ongoing capacity thresholds

Recap
 Rationalising Server Estate is a key issue in most medium to large organisations.
 Generally, the issue isn’t Rationalisation itself, but why, and which tools and technologies
are suitable
 Using a mix of Virtualisation, Server Farms and bare metal Servers, SQL Server within
the enterprise can be managed effectively and efficiently.
 Operational efficiency and good operational habits are far more important in the SQL
Server Enterprise environment.
 Once good operational habits have been formed and engrained into the business model,
issues around SQL Server technologies, including rampant deployments will decrease,
and operations will be able to focus more on adding core technological value to the
business rather than meeting operational stability and Service Level metrics.
 When looking at reducing an SQL Server Estate, base lining, planning and monitoring for
capacity, performance and fault tolerance are the key technological focuses' that should
be built into the toolset for day to day operations.

Topic Resources
 Whitepaper:
 Optimizing HP Servers with Microsoft SQL Server 2008.
 HP
 SQL Server Technical Article
 Server Consolidation with SQL Server 2008.
 Microsoft
 Whitepaper:
 A Pragmatic Approach to Server and Data Center Consolidation.
 Platespin

Community
 Swiss PASS Chapter
 www.sqlpass-swiss.org
 Swiss IT Pro user group
 www.swissitpro.ch
 Monthly sessions in Zurich and Geneva

Thank you…

SQL Server Club - SQL Server Enterprise Consolidation - charley hanania

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to SQL Server Club - SQL Server Enterprise Consolidation - charley hanania (20)

More from Charley Hanania (7)

Recently uploaded (20)

SQL Server Club - SQL Server Enterprise Consolidation - charley hanania