Charley Hanania discusses logically partitioning databases to improve performance and availability. Logically partitioning involves separating database objects into different filegroups and files based on criticality and usage. This allows placing high performance objects on faster storage. It also enables partial database availability so that core functions can still operate if a disk fails without affecting unrelated objects. The presentation provides examples to incorporate logical partitioning into application database designs for better performance, management, and disaster recovery.

1. Charley Hanania ::QS2AG–QualitySoftware Solutions
B.Sc(Computing),MCP,MCDBA,MCITP,MCTS,MCT,MicrosoftMVP:SQLServer
PrincipalConsultant-SeniorDatabaseSpecialist
Partitioning for Database Availability

2. About Charley Hanania
Now:
Microsoft MVP: SQL Server
Database Consultant at QS2 AG
Formerly:
Production Product Owner of MS SQL Server Platform at UBS Investment Bank
Consultant
DB Team Leader at Other Banks
ITIL v3 Certified
SQL Server Certified since 1998
On SQL Server since 1995
Version 4 on OS/2
IT Professional since 1992
PASS
Chapter Leader – Switzerland
Regional Mentor – Europe
24 Hours of PASS Committee Member
Event Speaker

3. Presentation Summary
DBA's will give you reasons and methods for achieving database availability
for your application, but not many can broach the concept of keeping parts
of your application running during an outage from the development
perspective through partitioning your application database logically
into levels of criticality.
Adding this logical Layer to your database design and development allows
you to bring your core application functionality online faster and
more simply during failures and in disaster scenarios decide which
areas of your application should come online first to maintain basic
application operations. It also allows you to place your data better to
cater for space and performance for an overall better performing system.
This presentation will drill into this conceptually as well as provide some
examples you can take back to the workplace to incorporate into your next
evolutionary changes.

4. Design Patterns by any Other Name…

5. Design Patterns are template-like methodologies.
Focussed on particular goals.
Architect-level focussed, but with follow-on
implementation considerations.
Design Patterns by any Other Name…

6. Evolutionary Growth of Features and Functions
Industry “norms” in Using Databases

7. Logically Partitioning your DB for Performance

8. Logically Partitioning your DB for Performance
Performance-related issues:
Disk I/O is the one most critical element to improving
performance for data intensive workloads.
When data objects are created in the default filegroup
they share space and allocate more as needed.
Extent fragmentation occurs as data from objects with
differing “personalities” are persisted.
Hotspots can occur on system pages that track the
allocation and use of pages in the file.
Read-ahead is affected as the data you’re retrieving is
not laid out contiguously.

9. Logically Partitioning your DB for Performance
Resolutions:
Creating additional files and filegroups helps to isolate
where the objects are written to and lowers
fragmentation.
System pages are spread out per file, lowering contention.
With Trace Flag 1117 and correct sizing of your data
files, “Round-Robin” writes are possible, giving higher
throughput on insert intensive workloads.*
Performance Critical data can be placed on LUNS/Disk
Arrays that have more spindles (eg RAID 1+0 mirrored)
or on mirrored Solid State Drives. Conversely, archive
data can be placed on inexpensive (eg. slower) disks.
*Note: Recommendation valid for systems that have >1 CPU/Core and >1 Disk Spindle
otherwise zero or detrimental performance may be experienced. Test First!

10. Step 2 - Filegroup Separation
Separating out objects into filegroups for
isolation, placing them according to granular
performance needs.

11. Logically Partitioning your DB for Availability

12. Logically Partitioning your DB for Availability
Major Points to availability when focussed on Logical
Partitioning
Time taken to open the database on restart, to start
taking connections.
Decreasing the size of the backup to restore through
differential backups of read/write filegroups.
Partial Database availability: a file/disk can go offline
without it affected unrelated objects in the same
database
If architected/implemented correctly, most subsystems
can run unaffected until non peak period for outage
Management & Operations staff can decide which
filegroups & subsystems to bring online first when
recovering from disaster.

13. Step 3 – Partial Database Availability
What happens when a file or disk goes offline? How are
other running subsystems affected?

14. Links and Resources
AdventureWorks Database Diagram
http://www.microsoft.com/downloads/details.aspx?FamilyID=0f6e0bcf-a1b5-4760-8d79-
67970f93d5ff&DisplayLang=en
Whitepaper: “Partial Database Availability” (Danny Tambs, May 2007)
http://technet.microsoft.com
Whitepaper: “Partitioned Table and Index Strategies Using SQL Server 2008” (Ron
Talmage, March 2009)
http://technet.microsoft.com
Kimberly Tripp’s Scripts for Creating and Partitioning SalesDB
www.sqlskills.com
Allen White’s Service Broker Session at the PASS Summit 2011
www.sqlpass.org