SPR301 The Accidental DBA Survival Tips, Tricks, and Techniques Microsoft ASP.NET Connections SPR301 The Accidental DBA Survival Tips, Tricks, and Techniques Kimberly L. Tripp & Paul S. Randal SQLskills.com Kimberly@SQLskills.com Paul@SQLskills.com Updates will be available at http://www.devconnections.com/updates/LasVegas _06/ASP_Connections

Microsoft ASP.NET Connections About Paul Consultant/Trainer/Speaker/Writer Managing Director, SYSolutions, Inc. (www.SQLskills.com) E-mail: Paul@SQLskills.com Blog: http://www.SQLskills.com/blogs/Paul SQL Server MVP and writer for TechNet Magazine 5 years at DEC responsible for the VMS file-system and check/repair Almost 9 years in the SQL Storage Engine team through Summer 2007, ultimately responsible for all the Core Storage Engine SQL Server 2000: wrote DBCC INDEXDEFRAG, DBCC SHOWCONTIG and parts of DBCC CHECKDB SQL Server 2005: rewrote DBCC CHECKDB and repair. Managed one of the core Storage Engine development teams SQL Server 2008: responsible for all the Core Storage Engine Since August 2007, running SQLskills.com with his wife, Kimberly Tripp Top-rated presenter at worldwide Tech·Eds and other conferences on disaster recovery, HA, maintenance, and internals Wrote and presented SQL Server 2008 training for Microsoft Updates will be available at http://www.devconnections.com/updates/LasVegas _06/ASP_Connections

About Kimberly Consultant/Trainer/Speaker/Writer Founder, SYSolutions, Inc. (www.SQLskills.com) e-mail: Kimberly@SQLskills.com blog: http://www.SQLskills.com/blogs/Kimberly Microsoft Regional Director and SQL Server MVP Writer/Editor for SQL Magazine www.sqlmag.com Author/Creator of the Always On VPC and most of the labs Author of several SQL Server 2005 Whitepapers on MSDN/TechNet – Table and Index Partitioning, Snapshot Isolation, .NET SQLCLR for DBAs, SQL Server 2005 Manageability Tools Author/Presenter for more than 25 online webcasts on MSDN and TechNet (two series, plus other individual webcasts) Coauthor MSPress Title: SQL Server 2000 High Availability Top-rated presenter at world-wide TechEds and ITForum on indexing, performance, and high-availability I (we) still love this stuff… Feel free to ask questions!

So What Do We Mean – ‘Accidental’? No, it’s not that you have accidents… An ‘accidental’ DBA is someone who didn’t set out to be a DBA You happened to know the most about SQL Server in your office You’re a Windows admin/developer who’s been asked to watch some databases You’re a business owner who bought some software that uses SQL Server under the covers So suddenly you’re a DBA – now what?

Knowledge is the Key to Success The old adage ‘you don’t know what you don’t know’ can cause you problems when being a DBA There are a few key things you need to do to help keep your database healthy and resilient to disasters It also helps if you know a bit about how a database is structured and how SQL Server works Key point: you (usually) can’t just leave a database alone and ignore it and expect it to always be there and always perform well

About This Workshop We’re covering the basics of being a DBA There’s obviously more nitty-gritty on each of these than we can cover in a day… check out the resources if there’s more detail you need We can’t go to 400-level during the lectures - we’d be here for a month! We *can* discuss anything here to any depth during breaks, etc. We may not discuss every bullet on every slide We sometimes get side-tracked…  We’d like this workshop to be INTERACTIVE Ask questions, share stories, join in! There are no ‘demo’ slides but we’ll do quite a few

Two Approaches to Being a DBA Build a system from the ground up – strategically controlling each option and setting at every level Not always possible An absolute requirement for highly scalable systems Take over an existing system and put it into a more manageable state What most folks here are facing An absolute requirement to minimize the problems that are currently plaguing your system

If You Could Start From the Beginning… Installation/Configuration/Security Hardware choices (RAID, memory, CPU) Installation choices (defaults/changes?) Servername dependencies Logon Security and Security groups Tools – Finding the Right Tool for the Job SQL Agent, SSMS, SQLCMD, Profiler, DTA Creating a database (logging & recovery) Structures (optimizing the data portion v. the log portion) Choosing an appropriate recovery model Creating a recovery strategy

If You Could Start From the Beginning… Creating tables/schema (consistent & deliberate) Base table (row structure, data types and nullability) Vertical partitioning (isolating to leverage features) Constraints (benefits, default indexes created) Effective Queries (accessing only the data you need) Processing data (caching, access patterns & indexes) Creating procedural objects Procedures, functions, triggers, views, oh my! Control, recompilation/caching, performance/scalability Maintaining databases Data usage patterns that lead to fragmentation Early warning/detection of disk errors

What We’re Not Covering… Relational theory Database design Physical server layout Setup/upgrade In-depth: Troubleshooting Performance tuning Disaster recovery Basically, we assume you have (or soon will have) a database to look after

Workshop Overview Module 1: Database Creation Module 2: Data Structures Module 3: Fragmentation and Corruption Wrap-up: Sample Problem Scenarios and Solutions Focus throughout the day on specific details about: What you need to care about Common problems and their solutions

Workshop BUILD (animated) slides These slides are ONLY the build slides shown during the session… for “all” slides only the printed version has everything! Enjoy the build slides here so that you can use them interactively!

Clearing the Log What? Lots of confusion around this term – as well as why/when to do it… Clearing the log means – removing the inactive portion of the log. “Inactive portion of the log” means: the part of the log where all transactions are completed AND their data has been checkpointed. Does the entire log get cleared? NO… Inactive Virtual Log File Active Virtual Log File Inactive/Unused Virtual Log File Virtual Log File 1 Virtual Log File 2 Virtual Log File 3 Virtual Log File 4 Virtual Log File 5 Min LSN (first open transaction) Start Logical Log End Max LSN (currently processing transactions)

hidden slide w/extra details Log Backups Over Time… Remember the active and inactive portions of the log… On a transaction log backup everything that’s occurred since the last log backup is backed up BUT only the inactive portion of the log is cleared… The transaction log size does not shrink at transaction log backup… Used/Inactive portion of the log Active portion of the log Unused portion of the log Portion of the log that’s cleared when a transaction log backup is performed Portion of the log that’s backed up when a transaction log backup is performed USED amount of Transaction Log Defined Size of Transaction Log

hidden slide w/extra details Log Backups Over Time… If the transactional activity has moved forward (as it should in well-designed/programmed databases) then the previously active (and long running) transaction is now inactive and that portion (since the entire VLF was backed up) can be cleared The next log backup will backup all of the activity since the last log backup and then clear the inactive portion of the log… Unused portion of the log Used/Inactive portion of the log Active portion of the log Unused portion of the log Portion of the log that’s cleared when a transaction log backup is performed Portion of the log that’s backed up when the next transaction log backup is performed Cleared portion of the Log Last Transaction Log Backup USED amount of Transaction Log Defined Size of Transaction Log

Unused portion of the log hidden slide w/extra details Log Backups Over Time… Finally, the log wraps and is circular It’s circular nature is why it does not support Instant Initialization and must be zero initialized If defined at a proper size it should not require significant auto-growth Used/Inactive Active Unused portion of the log Used/Inactive CLEARED BACKUP CLEARED BACKUP USED amount of Transaction Log Last Transaction Log Backup Defined Size of Transaction Log