[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
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
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.
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
Step 1 - User Schema SeparationSeparating out objects into schemas to help definebusiness use and Criticality
Logically Partitioning your DB for Performance
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.
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!
Step 2 - Filegroup SeparationSeparating out objects into filegroups for isolation,placing them according to granular performanceneeds.
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.
Logically Partitioning your DB for Availability
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.
Step 3 – Partial Database AvailabilityWhat happens when a file or disk goes offline? How areother running subsystems affected?
Step 5 – Service Broker QueuesWriting messages to an asynchronous queue ratherthan directly to a table
Links and ResourcesAdventureWorks Database Diagramhttp://www.microsoft.com/downloads/details.aspx?FamilyID=0f6e0bcf-a1b5-4760-8d79-67970f93d5ff&DisplayLang=enWhitepaper: “Partial Database Availability” (Danny Tambs, May 2007)http://technet.microsoft.comWhitepaper: “Partitioned Table and Index Strategies Using SQL Server 2008” (RonTalmage, March 2009)http://technet.microsoft.comKimberly Tripp’s Scripts for Creating and Partitioning SalesDBwww.sqlskills.comAllen White’s Service Broker Session at the PASS Summit 2011www.sqlpass.org
Please help us make TechDays even betterby Evaluating this Session. Thank you!Give us your feedback!