DAT203: Managing Microsoft SQL Server:For the “Reluctant” DBA

Don Jones

Senior Partner and Technologist

Concentrated Technology, LLC

SESSION CODE: DAT203

Me: Don Jones, Concentrated Technology
Microsoft MVP Award recipient
Contributing Editor, TechNet Magazine
Author of 45+ IT books
Blogger at http://ConcentratedTech.com
You: The “Microsoft Person” in your environment
Not primarily concerned with supporting Microsoft SQL Server…
…but more or less forced to do so anyway

Peeking Under the Hood: How SQL Server Works
Backup and Restore Operations
About the Query Optimizer
Index Maintenance and Tuning
Key Database Configuration Options
SQL Server Security Model
Key Server Configuration Options
High Availability and Replication Options

SQL Server stores data in 8KB chunks called “pages”
It always deals with data in these 8KB chunks
Generally speaking, all data for a single table row must fit onto a single page
It’s actually possible for certain types of data to spread across multiple pages
Sometimes, the page can contain a pointer to a file on disk – the FILESTREAM data type
The pages live in one or more files (.MDF, .NDF) on disk, but are always read or written in 8KB units

When a query is issued that results in data being changed, added, or deleted:
SQL Server makes a note of the query in its transaction log
The database engine determines what page(s) are affected by the change
The affected pages are loaded into server memory
The changes are made in memory
At this stage, the changes have been completed only in RAM.
If something else reads those pages, they’re already handy in memory.

Eventually, the modified pages are written to disk.
When this happens, SQL Server “checks off” the associated query in the transaction log.
In the event of a sudden failure:
When SQL Server restarts, it looks to see if any “un-checked” queries are in the log.
If so, it “re-plays” those queries to bring the database up to speed.
If you have the transaction log, you can recover the data!

Three types:
Full – Backs up the entire database and removes (“truncates”) all “checked” entries from the transaction log
Differential: Only what’s changed since the last Full; also truncates the log
Transaction log: Only grabs the current transaction log; truncates the active log afterward

Start with the most recent Full backup
Leave the database in “restore mode” if you have other files
Apply the most recent differential
Stay in “restore mode” if you have more files
Apply any transaction logs since the differential was made
When finished, allow recovery to begin

Maximum amount of data at-risk: Any changes made since the most recent transaction log backup
Moral: Frequent T-Log backups!

Two types:
Clustered
Every table has one, even if it’s just on the row ID number.
Governs the order in which data is logically stored
Should be on whatever column is used most for lookups or table joins
Non-Clustered
Every table can have zero or more
Acts as a literal index, keeping entries in order by the indexed column and pointing to the full data row
A “covering” index is one that contains entries for every column being queried

Pros
Indexes can speed up the time it takes to find data
Also speed up sort times
Ideally, index on all columns that are frequently used in a WHERE or ORDER BY clause
Cons
Indexes slow down data add/change/delete operations, because indexes must also be updated
Ideally, index nothing
The reality is a balancing act: Building indexes on columns that deliver the most benefit, with the least downside

Occurs when index pages become full and data needs to be inserted into the middle
A “page split” occurs to make room for the new entry, causing the pages to be “out of order” – this decreases performance

Andrew

Andrews

Batista

Barbara

Charles

Charlie

Frank

Gary

Grossman

Hugh

Ina

Jack

Jackson

Jones

Kimberly

Donavan

Eric

Erin

NEW!

Reorganizing or Rebuilding the index will put the entries and pages back into the correct order, improving performance
You can specify a “fill factor” that leaves empty space for new entries without splitting pages as often
However, emptier pages mean SQL Server has to work harder to read the same amount of data – so this is a balancing act

The indexes that made sense for a database on day 1 might not make sense after it has been in use for some time
You can use SQL Profiler to capture real-world, representative query traffic…
…and feed that to the Database Engine Tuning Advisor to get recommendations on index improvements
The Advisor can even help you implement those changes that you decide to proceed with

Allow statistics to Auto-Create/Update
This makes sure the Query Optimizer knows which indexes exist and what kind of condition they are in
Consider disabling auto-growth, or at least monitor it
Auto-Grow can consume time; better to manually size the database files appropriately
Disable Auto Close except on infrequently-used databases
Closed databases incur a performance hit when someone queries them since SQL Server has to open the file

Login: Map to a Windows user/group, or an in-server credential; gets you access to the server
Server Role: Contains logins, and defines server-wide privileges
Database user: Maps to a login, and gets you into a database
Database Role: Contains database users, and defines in-database privileges
Custom Database Role: Same as the built-in ones, but you define the permissions
App Role: Shortcut login+database user+permissions designed to be activated by an application that defines its own security layer for the data.

$Authentication Mode: “Windows” or “Windows+SQL Server” Memory and Processor options (typically, leave alone) Instances Each “instance” is an independent installation of SQL Server Has its own “server-wide” options (“instance-wide” is a better term) Default instance: Connect using server name Other instances: Connect using SERVER\INSTANCE format Review list of services to see instances – each instance has its own SQL Server service$