1. 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
Updates will be available at _06/ASP_Connections

2. Microsoft ASP.NET Connections
About Paul
Consultant/Trainer/Speaker/Writer
Managing Director, SYSolutions, Inc. (
Blog:
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 _06/ASP_Connections

3. About Kimberly Consultant/Trainer/Speaker/Writer
Founder, SYSolutions, Inc. (
blog:
Microsoft Regional Director and SQL Server MVP
Writer/Editor for SQL Magazine
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 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!

4. 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?

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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!

13. 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)

14. 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

15. 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

16. 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