Dba101
Download as PPTX, PDF0 likes334 views
Brad M. McGehee discussed SQL Server best practices for DBAs. He began by noting that DBAs can have varying levels of experience. The best practices presented are aimed at optimizing performance, availability, and reducing stress. Following the recommendations closely could boost SQL Server performance and availability by 20-50% or more. The presentation covered topics such as installation, configuration, backups, monitoring, and disaster recovery. McGehee emphasized that testing changes is critical and there may be exceptions to some rules depending on individual environments.
![ Create a SQL Server Event Alert for all events
with a severity of 11 and higher (or at least 19
[fatal] and higher).
Have alert sent to e-mail address, or to your
texting e-mail address.](https://image.slidesharecdn.com/dba101-12896307691598-phpapp02/85/Dba101-16-320.jpg)
Dba101
- 1. Brad M. McGehee SQL Server MVP Director of DBA Education Red Gate Software
- 2. You may be a part-time or full-time DBA You may be a DBA Administrator or DBA Developer You may have less than one year’s experience as a SQL Server DBA You may be an experienced DBA, but don’t mind spending a little time reviewing DBA fundamentals, because you may learn something new, or remind you of something you forgot.
- 3. Helps to optimize SQL Server performance Helps to maximum SQL Server availability Helps you to be proactive, not reactive Helps you to reduce being in “crisis” mode Reduces your stress levels Makes your manager happier Give you more time to focus on what really interests you
- 4. While each best practice I discuss today might seem small, the total effect of following each and every recommendation can be huge. By closely following each of these best practices, SQL Server performance and availability can be boosted by 20%, 50%, or even more.
- 5. Check &Verify One-time checks to verify proper SQL Server instance configuration On-GoingTasks Daily, weekly, monthly tasks that need on-going attention 1. Our focus today is on what to do, not how to do it. 2. Best practices are based on the biggest mistakes I see DBAs make. 3. These best practices are just the basics, there are a lot more to learn. 4. There are always exceptions to every rule, and not every recommendation discussed here may fit your environment.
- 6. Installing & Upgrading SQL Server General Configuration Memory Configuration User Data and Log File Management Tempdb Management Database Configuration Settings Configuring Jobs—General Create Index Rebuilding/Reorganize Job Create Data Corruption Detection Job Set Up Alerts for Critical Errors Security Basics Implement a Backup Strategy Create a Disaster Recovery Plan Test Everything
- 7. When installing a new SQL Server instance: Use the newest OS version with latest SP Use the newest SQL Server version with latest SP Use the 64-bit version of the OS and SQL Server When upgrading, it is always safer to upgrade to a new server with a fresh installation of the OS and SQL Server than to upgrade in place.This allows you to test more effectively, and also gives you a backout option.
- 8. Is the OS configured to optimize background applications? Need to have at least 20% free disk space on all disk drives. Important for NTFS performance. SQL Server instance should be a stand-alone server with no other apps running on it. Unnecessary services should be turned off. Don’t run antivirus software locally.
- 9. Ideally, use 64-bit hardware and the 64-bit version of SQL Server. If using 32-bit version, and if using 4 GB or more of RAM, ensure than AWE memory is correctly configured.
- 10. Remove physical file fragmentation before adding new MDF or LDF files The OS and SQL Server binaries should be on their own volume MDF files should be located on their own volume LDF files should be located on their own volume Pre-size MDFs and LDFs to minimize autogrowth Use Instant File Initialization
- 11. Locate on its own volume Keep recovery model to SIMPLE Pre-size so autogrowth doesn’t have to happen Set autogrowth to avoid many growth spurts, use fixed amount. Divide the tempdb into multiple files, so that the number of files is about 50% to 100% of the number of CPU cores your server has. Each file should be the same size.
- 12. Auto Create Statistics: On Auto Update Statistics: On Auto Shrink: Off PageVerify: Checksum (2005/2008) Autogrowth: Use mainly for catching mistakes. File growth should be managed manually. Use fixed amount, not percentage growth. Production databases should be set to FULL RECOVERY.
- 13. Schedule jobs so they don’t interfere with production. Ensure that jobs don’t overlap. Don’t ever schedule automatic shrinking of databases. If you must shrink a file, do it manually and off hours, then rebuild indexes. Don’t schedule an UPDATE STATISTICS job before or after an INDEX REBUILD/REORGANIZE job. It is redundant, and can actually reduce the quality of the statistics (if run after).
- 14. Rebuild an index if it is heavily fragmented (>30%). In Enterprise Edition, can perform online. If Standard Edition, can cause blocking, and should ideally be done during slow/down times. Reorganize an index if it is not heavily fragmented (>5% and <= 30%).This is an online operation and doesn’t use a lot of resources. Use a fill factor large enough to prevent page splitting, but small enough to prevent wasted space on disk and in memory. Use 100 for read-only tables, try 95 as a starting point for OLTP tables. Ideally, you should only rebuild or reorganize indexes that need rebuilding, especially for very large databases. Use sys.dm_db_index_physical_stats to identify fragmentation. If databases are small, or you don’t know how to identify which indexes are fragmented, then consider running a nightly or weekly job to rebuild or reorganize indexes in all of your user databases.
- 15. Run DBCCCHECKDB as often as you run full backups, which is probably daily. Create an appropriate job to run this command: DBCC CHECKDB (‘DATABASE_NAME') WITH NO_INFOMSGS, ALL_ERRORMSGS; Note: Use PHYSICAL_ONLY option for large or busy production servers. Review results to look for problems. If you have a problem, you want to find it as soon as possible to reduce the risk of data loss. A restore is often the only way to fix many data corruption problems.
- 16. Create a SQL Server Event Alert for all events with a severity of 11 and higher (or at least 19 [fatal] and higher). Have alert sent to e-mail address, or to your texting e-mail address.
- 17. Don’t use the SA account for anything. UseWindows Authentication security whenever possible. Don’t give users more permissions than they need to perform their job. Only log onto a SQL Server as a sysadmin if you need to perform sysadmin tasks, otherwise use a different account to log onto SQL Server. Log off your SQL Server when done.
- 18. Create a job to perform full backups daily on all system and user production databases, plus log backups hourly (or similar variation). Always backup using RESTORE WITHVERIFYONLY to help verify backup integrity. Keep full backup for at least several days, 7 or more days is ideal. Store backups securely and off-site. If you have a limited backup window, or have limited disk space, consider a third-party backup program that does compression. Can be a big time saver.
- 19. You must create a document that outlines, step- by-step, in great detail, how you will recover your SQL Servers in the case of any problem, small or large. You need to practice using the plan so you are familiar with it and can implement it without requiring any further research. Keep Microsoft SQL Server’s Product Support phone number handily available.
- 20. Before you make any change in a production SQL Server, be sure you test it first in a test environment. NO EXCEPTIONS! I mean it! Really!
- 21. Monitor MDF and LDF file growth Monitor Free Space Monitor SQL Server and OS Logs Monitor Jobs Monitor Alerts Test Backups Monitor Performance Analyze Indexes Document All Changes
- 22. MDF and LDF files should be managed manually. To do this well, you must monitor file growth and be aware of how much data is being added. Be proactive. Plan early to add more space if needed, don’t wait until it’s too late. In SQL Server 2005, use “Standard Reports” to help you monitor this. In SQL Server 2008, use Performance Data Collector to monitor this.
- 23. No disk should ever exceed 80% capacity.When it does, performance drops, and you risk running out of disk space. Check this manually and record results Use Performance Monitor and setup an alert Use a third-party tool Write your own tool
- 24. Daily, review SQL Server Event Logs Application System Security Daily, review SQL Server Logs How to perform: Manual check using EventViewer or SSMS Have “Errors” e-mailed to you from EventViewer Use third-party tool Write your own tool
- 25. Daily, verify that all jobs have run successfully. Keep in mind that sometimes, a job may claim to be successful, but it failed in part or whole. How to perform: Manually check Have SQL ServerAgent send you a message Use third-party tool Write your own tool
- 26. If you do set up any of the many available alerts, be sure you look at them. Sometimes, it is easy to be complacent and to ignore alerts. The secret is to keep alerts to a minimum by carefully creating the alerts, setting them up so that only the most critical alerts are sent.
- 27. At the very minimum, perform a test restore on at least one key production database, per SQL Server instance, weekly. The restore is best done on a test server, but if not available, restore on production server using different name. When restore is done, then remove.
- 28. Monitor performance regularly, daily if necessary. Identify potential problems early before they become critical problems. How to monitor: Performance Monitor Profiler SQL Server 2005 Performance Dashboard SQL Server 2008 Performance Data Collector Third-PartyTools
- 29. Indexing needs of a database can change over time as data changes, and as how data is queried changes. Every 1-3 months, perform a default Profiler trace on your production servers, then use the trace as the source for the Database EngineTuning Advisor to help you identify missing indexes. Remove unused indexes. Identify by using the sys.dm_db_index_usage_stats DMV Using correct indexes is one of the key ways to get better SQL Server performance.
- 30. Whether you are the only DBA, or one of many, all SQL Server changes needs to be documented. Acts as an audit trail (often required by many organizations). Documentation helps you to troubleshoot problems, and also acts as a repository of information for future use. Ideally, put documentation where is can be easily accessed by all interested parties.
- 31. By focusing on the basics, you gain the following: Better SQL Server performance Higher SQL Server availability Being proactive helps to you prevent being in a “crisis” mode all the time More time to focus on what is important to you You become a better, more professional DBA The total effect of following each and every recommendation made today can be huge.
- 32. Time for your questions
- 33. CheckThese Out: www.SQLServerCentral.com www.Simple-Talk.com www.ExceptionalDBA.com www.SQL-Server-Performance.com Contact me at: bradmcgehee@hotmail.com