SQL Server Webcast 5 COMMON HIGH AVAILABILITY MISTAKES · SQL Server Webcast Michael K. Campbell ....

5 COMMON HIGH AVAILABILITY MISTAKES

SQL Server Webcast

Michael K. Campbell

Michael K. Campbell Independent Consultant

Former DBA and Database Developer

Author, Contributing Editor, Presenter

Contact web: http://www.overachiever.net

email: mike@overachiever.net

twitter: AngryPets

5 Common HA Mistakes

In this Webcast

High Availability

Common HA Mistakes

Goal / Take-Away:

What you can do to avoid mistakes.

High Availability

High Availability Defined: Pro-Active Disaster Recovery

HA Options / Technologies: Log Shipping / Mirroring

Replication / SAN Replication

Clustering / Virtualized Nodes

Etc.

Which Option is Best? ANSWER: Success is NOT a function of which

technology you use.

5 Common HA Mistakes

1. Confusing HA and DR

2. ‘House-Boating’

3. Thinking Only of Data

4.

5.

HA = Highly Available Data

But what if your data is bad?

How quickly does it become bad ‘everywhere’?

Once it’s bad everywhere, then what?

HA is useless without GOOD data.

HA doesn’t usually address data quality.

It can even HINDER restoring data quality.

Common High Availability Mistake #1

MISTAKING HA as a Replacement for DR

Example

Juggling Flaming Chainsaws, Kittens, and Loaded (Sawed-Off) Shotguns.

Widgets Database

Mission Critical System.

Highly-Available – using Clustering and Log Shipping.

Tracks Inventory Levels for Products.

Products Sold Online OR through Call Center.

Not ready for Developers A and B.

Developers

Dude. Don’t stress. I read about this

once. We just need to run a ROLLBACK

or something...

!!!!

Developers

HA Location

Call Center

Web Site

Rollback?!?

HA Location

Safe Data

Developers

HA Location

Call Center Inventory = 0

Web Site Inventory = 0

Receiving +3,312 different

products

Dude?!? DBA

HA Location

Recovery Options Failover the Cluster?

Pointless.

Failover to an HA Location? Pointless, unless:

Synchronization Delay? Data Loss.

Recover Database? Point In Time Restore?

Data Loss – All operations AFTER the UPDATE.

Recover a Copy of the DB? Headache

Potential for Data Loss

http://www.flickr.com/photos/lastbeats/473632210/

Common High Availability Mistake #2

HOUSE-BOATING

High Availability and House-Boats

Example: Secondary Reporting Servers Commonly needed.

Commonly ‘bundled’ with HA Solutions.

Example: Log Shipping Highly Versatile HA Solution.

Can Delay Application of Log Files/Updates.

STANDBY.

Read Only / Reporting Databases Seems like the best of both worlds…

The Problem with House-Boats

http://www.flickr.com/photos/salim/2183984577/

There’s More to High Availability than DATA Making data available is core to HA But you NEED a viable environment

Otherwise, data is inaccessible / non-available

Considerations Hardware Capacity / Capability Server Services, SPNs, Access to Resources Encryption Keys, Custom Errors, Maintenance Plans Connection Strings, Ports, and Firewalls Application Security, Delegation, and Access User Permissions / Logins, Authorization Configuration / Settings, Performance Tweaks

Common High Availability Mistake #3

THINKING ONLY OF DATA

Common High Availability Mistake #4

FAILURE TO TEST REGULARLY

Not Testing Regularly

Don’t LOOK like an idiot

Don’t BE an idiot.

Regular Testing

Ensures that HA systems actually WORK.

Ensures that your environment hasn’t hosed you.

Ensures that you have the skills to ‘fail over’.

Common High Availability Mistake #5

FAILURE TO DOCUMENT

Documentation IMPLIES Testing

Viable Documentation only comes with testing

Viable Documentation only STAYS viable with continued testing.

Documentation IMPLIES Skills / Knowledge

Viable documentation REQUIRES understanding and skills need to recover from an emergency.

Documentation = Bus Factor You won’t always be there

With GOOD documentation, you won’t NEED to be there

Good Documentation

Good Documentation Starts with SLAs: Acceptable Down-Time Acceptable Data Loss

Documents More than Just Processes Includes Environmental Details / Credentials

Sealed Envelope Approach (Built-In Post Mortem)

Outlines / Defines Escalation Plans Provides Contact Information:

Management Vendors Other Admins / Resources

Avoiding Mistakes / Disasters

Take-Away / Things You Can Do:

Test Regularly

Keep Documentation Up to Date

Conclusion

Links / Resources at: http://updates.sqlservervideos.com/

email: mike@overachiever.net