1. Establishing a Service Level Agreement SLA =tg= Thomas Grohser SQL Server MVP SQL Server Performance Engineering

2. select * from =tg= where topic = =tg= Thomas Grohser email: tg@grohser.com Web: www.grohser.com twitter: @tgrohser Focus on SQL Server Performance Engineering, Infrastructure and Architecture New Book coming in 2012 Close Relationship with SQLCAT (SQL Server Customer Advisory Team) SCAN (SQL Server Customer Advisory Network) TAP (Technology Adoption Program) Product Teams in Redmond Active PASS member and PASS Summit Speaker

3. Agenda Why & When? What & How? Q&A

4. Why do we need SLA’s Management and coworkers need to understand and agree to reality Help you to request and argue the resources you need Avoid lawsuits

5. Rule Number One! SLA first Solution later If you already have a solution don’t agree to a SLA the solution can’t support

6. What should be in a SLA? Everything –Operational requirements –Maintenance windows –Responsibilities –Dependencies –What happens if the SLA is not met

7. RPO – Recovery Point Objective In plain English: How much data can we lose? –Samples Your last log backup is from 12 minutes ago12 minutes Your last full backup is from last week1 week You do not have a backupall

8. RTO – Recovery Time Objective In plain English: How much time after a failure till we have to be available again Samples Your restore takes 6 hours 6+ hours Your last backup does not work you have to go to tape 24+ hours

9. Availability Time the database is available within a period of time divided by the length of the period of time. Don’t confuse luck with availability! –How fast to you think you can fix data corruption or human error in your database?

10. Availability 99.0 % 99.7 % 99.9 % 99.99 % 99.999 % the famous five nines 99.9999 %

11. Availability how long can I be offline Availability1 Year DaysHoursMinutesSeconds 1 Month DaysHoursMinutesSeconds 0% 365.2587665259603155760030.4375730.5438302629800 99.0 % 3.6587.6652603155760.307.3143826298 99.7 % 1.1026.301578946732.191317889 99.9 % 8.77526315580.73442630 99.99 % 0.885331564263 99.999% 531626 99.9999% 0.5323

12. Available Is a database available when –It is online in SSMS? –I can login? –I can select data? –I can update data? –I can insert data? –I can change the schema? –… you get the idea?

13. When is a database needed? Is the database used on the web 24x7 or just in the office from 9 to 5 or just once a month to process payroll? Do the availability requirements apply all the time or just during the periods its actually used?

14. Service Windows Specify times when you can service your system The more the better –Every night from 11pm till 5am, all day Saturday and Sunday, except the weekend before the year end results are due. –First Sunday every month from 2am till 4am

15. Planned versus Unplanned Big debate is planned maintenance part of the yearly downtime or not? Big difference between the two cases Make sure its clearly defined and understood

16. Monitoring availability 99.999% is equivalent to less than 5.2 minutes of outage per year or less than a 0.8 seconds per day This requires you to do an availability check at least every 0.4 seconds otherwise you waste valuable seconds.

17. Availability Having a certain availability vs. guaranteeing it. Easy to end up with 100% availability Hard to guarantee even 99.7

18. Differentiate between HA, DR and LR HA … High Availability DR … Disaster recovery LR … Last Resort Have different RPO and RTO values for all three cases. Define worst case scenarios each level has to deal with

19. HA … High Availability RTO: seconds to minutes RPO: Zero to seconds Automatic failover HA site usually close by (< 50 km) Well tested (maybe with each patch or release)

20. DR … Disaster recovery RTO: minutes to hours RPO: seconds to minutes (even hours) Manual failover into prepared environment DR site usually several hundred km away Tested from time to time

21. LR … Last Resort RTO: days to weeks RPO: minutes to hours (even a whole day) Rebuild system from scratch –Hardware has to be ordered –Floor space, connectivity to be rented LR site usually on different continent and jurisdiction Have a rough plan

22. Define worst case scenario for HA Failure of a single component Failure of two components (which are of a different kind) Failure of server Failure of multiple servers Failure of any two components That means you need everything at least three (3) times (not so easy for disks)

23. Define worst case scenario for DR Human error Failure of server Failure of multiple servers Partial failure of data center Full failure of data center Failure of multiple data centers

24. Define worst case scenario for LR Destruction / failure of multiple datacenters Natural disaster Sabotage Political incident (i.e. war, regime change) Destruction of planet earth …

25. Outside SQL Server Make sure you state that you depend on the underlying infrastructure and failures of that infrastructure don’t count for you! Make sure no processes are interfering –Example: async database mirroring + failover OK for loosing data. Only one person allowed to give the OK. 3 weeks vacation and availability is down to 94.2%

26. Dependencies Who needs this database/server What does this server need to operate –Power –Cooling –Network –Firewall rules –Domain Controller –Other servers (linked server) –…–…

27. Responsibilities Who can actually make a decision for a database/server Who owns the data Who needs to be notified if something is wrong

28. Backup retention and granularity How far must you be able to go back? –Hours, Days, Weeks, Months, Years –And how accurate must the restore be –I need the database restored to November 15, 2008 at 6:27… –How much time do you need for this historic restores –Test them from time to time (you need the resources and time)

29. Tips for keeping the SLA Make sure your monitoring and alerting works Monitor your Monitoring Test your HA, DR, LR solutions regular and especially after every change to your infrastructure.

30. DR and LR Instructions Keep printed copies in several places trust me your electronic documentation won’t be there when you are in a DR or LR situation

31. Summary Remember Rule Number one –SLA first –Solution later –If you already have a solution don’t agree to a SLA the solution can’t support –The laws of physics apply (even to the best DBA :-)

32. THANK YOU! For attending this session and PASS SQLRally Nordic 2011, Stockholm