Tech days 2011 - database design patterns for keeping your database applications available and performing well - charley hanania


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • [Tambs]While the database is in a state of partial availability, the filegroups that remain online can support queries. However, queries that depend on data that resides in filegroups that are offline return error 8653:Msg 8653, Level 16, State 1, Line 3The query processor is unable to produce a plan for the table or view 'X' because the table resides in a filegroup which is not online.
  • Tech days 2011 - database design patterns for keeping your database applications available and performing well - charley hanania

    1. 1. Charley Hanania :: QS2 AG – Quality Software SolutionsB.Sc (Computing), MCP, MCDBA, MCITP, MCTS, MCT, Microsoft MVP: SQL ServerPrincipal Consultant - Senior Database SpecialistDatabase Design Patterns forKeeping Database ApplicationsAvailable and Performing Well.
    2. 2. About Charley HananiaNow:Microsoft MVP: SQL ServerDatabase Consultant at QS2 AGFormerly:Production Product Owner of MS SQL Server Platform at UBS Investment BankConsultantDB Team Leader at Other BanksITIL v3 CertifiedSQL Server Certified since 1998On SQL Server since 1995Version 4 on OS/2IT Professional since 1992PASSChapter Leader – SwitzerlandRegional Mentor – Europe24 Hours of PASS Committee MemberEvent Speaker
    3. 3. Presentation SummaryDBAs will give you reasons and methods for achieving database availabilityfor your application, but not many can broach the concept of keeping partsof your application running during an outage from the developmentperspective through partitioning your application database logicallyinto levels of criticality.Adding this logical Layer to your database design and development allowsyou to bring your core application functionality online faster andmore simply during failures and in disaster scenarios decide whichareas of your application should come online first to maintain basicapplication operations. It also allows you to place your data better tocater for space and performance for an overall better performing system.This presentation will drill into this conceptually as well as provide someexamples you can take back to the workplace to incorporate into your nextevolutionary changes.
    4. 4. Agenda
    5. 5. Design Patterns by any Other Name…Industry “norms” in using databasesLogically Partitioning your DB for ClarityLogically Partitioning your DB for PerformanceLogically Partitioning your DB for AvailabilityAppendixes (time permitting):Partitioned Tables and ViewsAsynchronous QueuesAgenda
    6. 6. Design Patterns by any Other Name…
    7. 7. Design Patterns are template-like methodologies.Focussed on particular goals.Architect-level focussed, but with follow-onimplementation considerations.Design Patterns by any Other Name…
    8. 8. Evolutionary Growth of Features and FunctionsIndustry “norms” in Using Databases
    9. 9. Industry “norms” in Using Databases
    10. 10. Industry “norms” in Using Databases
    11. 11. Logically Partitioning your DB for Clarity
    12. 12. Interdependent ObjectsDiffering schema complexitiesDiffering CriticalitiesDiffering InterfacesDiffering “Personalities”Logically Partitioning your DB for Clarity
    13. 13. Logically Partitioning your DB for Clarity
    14. 14. Step 1 - User Schema SeparationSeparating out objects into schemas to help definebusiness use and Criticality
    15. 15. Logically Partitioning your DB for Performance
    16. 16. Logically Partitioning your DB for PerformancePerformance-related issues:Disk I/O is the one most critical element to improvingperformance for data intensive workloads.When data objects are created in the default filegroupthey share space and allocate more as needed.Extent fragmentation occurs as data from objects withdiffering “personalities” are persisted.Hotspots can occur on system pages that track theallocation and use of pages in the file.Read-ahead is affected as the data you’re retrieving isnot laid out contiguously.User Schema Separation is done, now to look at the next layer down.
    17. 17. Logically Partitioning your DB for PerformanceResolutions:Creating additional files and filegroups helps to isolatewhere the objects are written to and lowersfragmentation.System pages are spread out per file, lowering contention.With Trace Flag 1117 and correct sizing of your datafiles, “Round-Robin” writes are possible, giving higherthroughput on insert intensive workloads.*Performance Critical data can be placed on LUNS/DiskArrays that have more spindles (eg RAID 1+0 mirrored)or on mirrored Solid State Drives. Conversely, archivedata can be placed on inexpensive (eg. slower) disks.*Note: Recommendation valid for systems that have >1 CPU/Core and >1 Disk Spindleotherwise zero or detrimental performance may be experienced. Test First!
    18. 18. Step 2 - Filegroup SeparationSeparating out objects into filegroups for isolation,placing them according to granular performanceneeds.
    19. 19. Quick Recap – So Far1. Don’t put user defined objects in the Primary Filegroupi. Allows the Primary Filegroup to load faster2. Schema Separate user defined objectsi. For clarity of purpose and operational useii. Try not to use dbo schema (good design/operational practice)iii. DBA’s will schematize objects in a similar fashion to what was inthe Adventureworks sample. You should look to map yourschema’s around your application’s core functionality / use cases/ criticality3. Create Filegroups for each Schemai. Multiple if you want to partition historical data horizontally etcii. Name them in a fashion that allows easy understanding of whatis in them, or how they should be used.
    20. 20. Logically Partitioning your DB for Availability
    21. 21. Logically Partitioning your DB for AvailabilityMajor Points to availability when focussed on LogicalPartitioningTime taken to open the database on restart, to starttaking connections.Decreasing the size of the backup to restore throughdifferential backups of read/write filegroups.Partial Database availability: a file/disk can go offlinewithout it affected unrelated objects in the samedatabaseIf architected/implemented correctly, most subsystemscan run unaffected until non peak period for outageManagement & Operations staff can decide whichfilegroups & subsystems to bring online first whenrecovering from disaster.
    22. 22. Step 3 – Partial Database AvailabilityWhat happens when a file or disk goes offline? How areother running subsystems affected?
    23. 23. Appendices - 1Partitioned Tables and Views
    24. 24. Step 4 – Partitioning TablesPartitioning the Sales Table into smaller, manageableobjects
    25. 25. Appendices - 2Asynchronous Queues
    26. 26. Step 5 – Service Broker QueuesWriting messages to an asynchronous queue ratherthan directly to a table
    27. 27. Links and ResourcesAdventureWorks Database Diagram “Partial Database Availability” (Danny Tambs, May 2007) “Partitioned Table and Index Strategies Using SQL Server 2008” (RonTalmage, March 2009) Tripp’s Scripts for Creating and Partitioning SalesDBwww.sqlskills.comAllen White’s Service Broker Session at the PASS Summit
    28. 28. Please help us make TechDays even betterby Evaluating this Session. Thank you!Give us your feedback!
    29. 29. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing marketconditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.