Background. Let s see what we prescribed.

Transcription

1 Background PatientB scustom application had slowed down as their data grew. They d tried several different relief efforts over time, but performance issues kept popping up especially deadlocks. They wanted a permanent cure. Let s see what we prescribed.

2 Patient B SQL Critical Care Part 1: Health Triage Findings AKA: Are we going to lose data? 2016 Brent Ozar Unlimited. All Rights Reserved. For details:

3 We re Brent Ozar Unlimited. RICHIE RUMP ANGELA WALKER DOUG LANE TARA KIZER BRENT OZAR JESSICA CONNORS ERIK DARLING

4 What instance did we look at? Instance: [REDACTED] Applications involved: Primary SQL Server for all client applications Total data size: 101GB Memory Size: 64GB Number of logical cores: 4 SQL Server version and edition: SQL Server 2012 SP2 Enterprise Edition (but licensed for Standard) Virtualized? Yes (Hyper V)

5 Getting ready to tune SQL Server

6 Here s why we re so careful Imagine: You change parallelism settings, then hit a new bug where parallelism causes incorrect results You change your index maintenance, but hit an issue where index rebuilds can corrupt your data You add a fully documented, supported query hint and hit a bug where it causes data to be incorrect We guide you around known bugs, but new issues are found all the time Rock-solid backups and maintenance are a prerequisite for tuning SQL Server

7 Executive Summary 1. RPO and RTO Get these signed off, then adjust recovery models accordingly 2. Next, implement Ola Hallengren s free suite of maintenance jobs and adjust related settings First up: Backups and recovery models Next: CHECKDB and page_verification Finally: Index and statistics maintenance (not urgent, but nice to have long term) 3. Implement other settings changes from your Action Plan 4. The harder change: your Edition mismatch You need to downgrade, which is a more complex change, so this will take some planning But there s no avoiding this in the long run.

8 Ready to get started? Download Ola Hallengren s maintenance solution and follow the steps from this document in your test environment today, tomorrow, or Wednesday If you ve got questions about how to set things up, we can talk through that on Thursday

9 Your maintenance prescription

10 RPO and RTO Recovery Point Objective (RPO): How many minutes of data can you lose in a worst case scenario? Recovery Time Objective (RTO): How many minutes can you be offlinein a worst case scenario? Minutes of data loss allowed Server Offline Corrupt data Oops deletes 15 minutes (24 hours for training and demo DBs) Datacenter offline? Minutes of downtime allowed 5 minutes?

11 Adjusting your recovery models You have a set of databases where you don t care as much about data loss, because you can recreate them from an older backup For databases where you can restore them from the last full backup: Set the recovery model to SIMPLE You don t need to run log backups Ola Hallengren s job will automatically skip them if they re in the SIMPLE recovery model Just be careful to not accidentally put a production / critical database into SIMPLE.

12 Your backup prescription Backups Full backups user and system databases. Set the jobs to use backup compression, run once nightly. Log backups user databases. Set the job to use backup compression. Run every 10 minutes around the clock (OK to overlap with all other maintenance jobs. Why we like Ola Hallengren s jobs: Easy to set up Option for removing old backups (set in hours) Jobs log history to text files for easy review Note that you must enable compression in the job!

13 Implementing Ola s jobs Example page: Tip: On each page, scroll to the bottom for example commands Note parameters for backup jobs are in hours, not days

14 CHECKDB and page verification CHECKDB Run this first in a low volume time. Based on your full backup runtimes and data sizes, it looks like this will take less than an hour, but test to make sure. Schedule this to run weekly for user and system databases using Ola Hallengren s maintenance jobs. CHECKDB should not overlap with full backups or index maintenance (covering that shortly). PAGE_VERIFICATION This is a database level setting. After you set this, SQL Server starts using checksums to provide more protection against corruption. We have a script to help you set this for each database without having to clock on each one:

15 Index Maintenance Strategies

16 Index maintenance matters You ve been hesitant to implement this, and that makes sense Long term you do want index maintenance: Fragmented indexes have empty space, which wastes memory when SQL Server calls the index. Reorganizing/rebuilding also updates statistics. The query optimizer needs accurate statistics in order to create good query plans. But you don t want to overdo it it s all about finding a balance

17 Fragmentation is a frequent straw man Fragmentation is often blamed when it s not the real root cause Rebuilding an index might seem to fix a problem when perhaps the problem was: Out of date statistics A bad query plan in cache Rebuilding indexes is NOT a lightweight way to handle either of those problems

18 Index rebuilds Rebuild is a heavy index operation that: Generates a new structure for the index Can apply new FILLFACTOR settings Takes the index offline* Runs in a single-threaded process* Requires rollback if canceled Also updates statistics associated with the index * Enterprise Edition allows for online and parallel-threaded rebuilds.

19 Index reorganize Reorganize is a lightweight index operation that: Compacts and reorders leaf-level pages in the index Applies existing FILLFACTOR settings Allows index to remain online during reorganize Does not require rollback if canceled.

20 Which operation and when? Microsoft s default thresholds are very aggressive Action Microsoft s default threshold Our default threshold Reorganize 5% 30% Rebuild 30% 70% Neither of these is perfect for every situation. In your case, offline rebuilds are sometimes a very bad thing, and you re only licensed for Standard Edition. Let s customize your recommendations.

21 Your index prescription EXECUTE = = = = = = = = 7200, /* seconds = 'Y'

22 Talking through the choices Reorganize only You re licensed for Standard Edition, and in some periods of time you need 24x7 uptime You need to tune indexes, and REBUILD has baggage Page count = 2000 This excludes smaller objects that aren t worth the effort Updating modified statistics = ALL Updates stats for columns as well as indexes Log to Table Helps you identify if there are frequent fliers Time Limit Keeps it from running too long (but review if it s hitting the limit)

23 ALTER INDEX REBUILD clears index usage / missing indexes This can make you crazy! Bug introduced in 2012 RTM blows away index usage stats whenever that index is rebuilt. Microsoft is aware of it. This has been marked as won t fix /details/739566/rebuilding-an-index-clears-statsfrom-sys-dm-db-index-usage-stats

24 How often should you run index maintenance? Start running it just once a week Don t let it overlap with full backups or CHECKDB Look at what the runtime is The first run is going to be longer since you haven t been running this regularly. Allow extra time for that one. Running it on a weekly basis is a good fit for your environment You can do it nightly, but just checking for the fragmentation requires a lot of IO, so this isn t ideal for those times of year when you have users who want to work late, particularly during the week

25 Be careful out there Don t demonize fragmentation Don t ignore it completely, and end up with 50% of your pages in memory sitting empty Take the middle road! Set up index maintenance that only works on fragmented indexes Start at a conservative / high level of fragmentation allowed and work your way down slowly Be especially careful if you have mirrors, replicas, or logshipping secondaries Monitor job performance Be aware of service packs and cumulative updates

26 More easy stuff: Settings changes

27 These are in your Action Plan More critical settings Creating alerts Fast, easy, and makes sure you get notified ASAP if there s data corruption Setting maintenance jobs to notify on failure You set this in the job properties for Ola s jobs fast and easy Less critical, but good to do Database and job owners Cleaning up msdb backup history Cleaning up jobs that are no longer needed

28 The harder change: SQL Edition downgrade

29 It s a bummer that this is hard If this was a version upgrade on your instance, it d be much simpler But version downgrade isn t made to be easy It requires uninstall and reinstall That s a little tricky, because I have never had good luck with: Scripting out every login, job, setting and making sure I don t miss anything Restoring system databases

30 The better way to go about this Virtualization has your back here Set up a whole new VM Follow our setup guide when configuring SQL Server everything from Instant File Initialization to the block size to format the drives BrentOzar.com/go/setup Set up all your maintenance and jobs on the new instance Cut over using logshipping or a backup / restore process to reduce downtime

31 This approach lowers risk You can keep the old SQL Server instance around for a month after the change Any questions about different settings / permissions? You have it there to check. Much more predictable downtime window And you end up with a list of all the setup steps you need for your production instance essentially a setup runbook.

32 Changing connection strings If this is a pain point, considering changing connection strings to a DNS friendly name All applications and reports point to this DNS name It points to the SQL Server Then, whenever you need to change everyone s connection string it s a simple DNS update This could come in very useful in the future for scenarios like VM OS drive is full

33 Tools, Links, and More Info

34 Get our free guides BrentOzar.com/go/setup Our SQL Server setup guide BrentOzar.com/go/perfmon Core performance counters for SQL Server BrentOzar.com/Responder Customizable starter process on what to do when downtime or performance problems strike

35 Get our free tools BrentOzar.com/Blitz sp_blitz finds dangerous configuration problems BrentOzar.com/AskBrent sp_askbrent answers What s slowing down your SQL Server right now? BrentOzar.com/BlitzCache sp_blitzcache finds the top queries killing your server BrentOzar.com/BlitzIndex sp_blitzindex diagnoses index insanity

36 Your Action Plan

37 Your Action Plan is a checklist! You get an editable checklist of items you need to do We ll switch over to it now If you re reading this later and don t have a copy, just us at help@brentozar.com (Don t worry, we ll make sure it s really OK to send it to anyone who asks for it.)

38 These steps are critical to reducing your risks of data loss. Which task will be the most difficult for you?