DBA database management checklist

Written By: Edgewood Solutions Engineers --

Problem For both old and new DBAs there are fundamental procedures that should be addressed and proper processes put in place to handle various areas of database management for S ! Server" Whether you are a full time DBA or this is one of many #ob roles that you perform the same basic steps should be implemented and adhered to in order to have some peace of mind that you are performing the correct procedures to ensure a healthy running S ! Server environment" For old DBAs these items should be a no-brainer$ but often a refresher is good reminder to ma%e sure everything is in place" For new DBAs some of these basic items are not all that apparent and often some of the most basic DBA &'& items are sometimes overloo%ed" So based on this$ what is a good plan to implement to ma%e sure the basic S ! Server DBA items are being addressed( Solution )he following is a chec%list of &' items that should be in place for all of your S ! Server database servers" Some of these items are pretty basic and easy to implement$ while others re*uire a higher level of effort to thin% through what is needed and then to implement the process" )hese items are not necessarily written in any priority order$ because not any one of these items is a complete database management plan it really re*uires all of these items to be thought about$ addressed and implemented" # Item Steps This is one of the most basic items to be addressed. Everyone knows that a good solid backup plan should be in place for all databases but time and time again I run across servers where the wrong or no backup plan is in place. To get started you need to ask yourself a few !uestions such as the following" #hat are you trying to recover from when a failure occurs$ %ow much data can be lost$ & day one hour a week none... #hat kind of processing occurs transaction based batch loading a combination$ 'an the data be easily recreated if there is a failure or is this the only source of this data$

Backups

This is (ust a short list of !uestions to ask but once these are addressed this will allow you to determine) 1* the recovery model for your database and +* the backup processing. ,epending on your needs your backup plan may look like one of the following" ,aily full backups only ,aily full backups and transaction log backups every hour ,aily full backups transaction log backups every 1- minutes and differential backups every . hours

/ote" If you are unsure what to do start with at least full backups on a daily basis. If your data is very important and you cannot easily recreate the data change your database recovery model to 0122 and implement both full and transaction log backups. + 3un Integrity 'hecks &nother area that should be addressed is the integrity of your data. S42 Server offers a few options to address this such as ,B'' '%E'5,B ,B'' '%E'5T&B2E ,B'' '%E'5&226' etc... These commands check the allocation structure and logical integrity of all ob(ects in your database. In addition to running these commands either through maintenance plans maintenance (obs or via a !uery window you also need to analy7e the data to look for any integrity issues that need to be addressed. This is another area that I see a lot of where the commands are run via maintenance (obs but no one ever reviews the reports to see if there are any issues that need to be addressed. 0or the most part these integrity issues pop up a lot less than they did with earlier versions of

S42 Server but this is still an area that should be part of your ,B& procedures. Inde:es are those helpful pointers that allow you !uick access to your data pages in your database. #hen inde:es are newly created the structure is nice and clean and everything works great by accessing your data via the inde: instead of having to scan the entire table. 6ver time these helpful inde:es become fragmented and take up unnecessary space and accessing your data pages is not as efficient as it was when the inde:es were first created. This is where inde: maintenance is a critical ,B& process that needs to be in place. In S42 Server +;;; you have the ability to run inde: rebuilds across the board for all tables when using maintenance plans. This was an all or nothing approach. In S42 Server +;;- you also have the ability to run inde: rebuilds as well as inde: defrags. In addition you can pick specific tables that you need to manage. &lthough this is not a perfect process for maintaining inde:es it is definitely better than not doing anything. To take this a step further you can manage your inde: maintenance table by table or inde: by inde:. Some inde:es will become fragmented while others may never have an issue based on how the inde: was created and how data is applied to the table<inde:. Based on this by doing the across the board method of inde: management you are spending unnecessary time addressing a problem that does not e:ist for some the tables. Therefore the best approach would be to use the tools that S42 Server offers such as ,B'' S%6#'6/TI= and sys.dm>db>inde:>physical>stats to identify where the real issues e:ist and then take steps to address these tables and inde:es instead of every table and inde: in your database. There are several areas where S42 Server logs information about processes that are occurring as well as errors that occur. The most used is probably the S42 Server Error 2og. This error log gives you startup information integrity check information backup information etc... as well as any S42 Server errors that occur. In addition to this log there is also a log for S42 Server &gent and now in S42 Server +;;- ,atabase 9ail. In addition to these internal S42 Server logs you should also use the #indows Event 2og to find other errors that may be occurring or possibly additional information that is not in the S42 Server logs. 3eviewing the logs should be part of your daily routine for checking the health of your system. The ideal way to handle this is to use some tool that automates the alert process when there is an error but either way you should keep these error logs on your radar list as something to review each day. S42 Server@s builtAin (ob scheduling tool is a great tool for automating your backups inde: rebuilds integrity checks etc... But in addition to this tool giving you the fle:ibility to run these (obs during off hours you also need to make sure you are monitoring (ob success and failure. This can be automated by setting up S42 9ail BS42 +;;;* or ,atabase 9ail BS42 +;;-* and having failures be sent out to operators that are configured. This is another area I see all the time where there are several (obs that fail not (ust once or twice but every single time they were run. Take the time on a daily basis to check out the (ob failures and address the issue so all of your (obs run successfully. & S42 Server backup is only good if the restore works. /o matter how many backups you take of your database if you cannot restore the file when needed there is no point in doing backups in the first place. The only way to determine if your backup<restore process will work is to periodically test on another server. This not only gives you peace of mind that the restore was successful but this also gives you an idea of how long the entire process will take if you ever need to do this on your production server. %aving this little insight and the time it will take to recover you database will go along way when you have people breathing down you neck. In addition to testing you should also use the 3EST63E DE3I0E option when creating your backups. It doesn@t necessarily tell you that the restore will not have any issues but it will at least prove that S42 Server can read the entire backup file without a problem. This is one area that should be a noAbrainer if you are responsible for monitoring your S42 Server environment. The database is usually the last thing people think about when they are working with an application but when the application is slow the database is usually the first thing that is blamed for the poor performance. The problem with performances monitoring is not that most people don@t do this it is that they are not sure how to do this. #indows and S42 Server offer built in tools such as Gerformance 9onitor Grofiler E:ecution Glans Inde: Tuning #i7ard ,atabase Engine Tuning &dvisor etc... In addition there are a whole bunch of third party tools that allow you to trend performance issues and be alerted when there are issues. #ithout good data it is very difficult to say when there really is a performance issue and also without this data it is difficult to know where to spend

9aintain Inde:es

3eview Error 2ogs

9anage S42 Server &gent ?obs

Test Backups

9onitor Gerformance

your time fi:ing issues that will have a big impact versus fi:ing something that will not have a very big impact. &nother thing that should be implemented is a documentation process to document procedures priority lists escalation lists production changes roll out procedures etc... & good set of procedures should be established so everyone that works on your S42 Servers understands the processes that you have put in place as well as to document all changes that occur so when a problem does arise you can pinpoint when a change was made. & simple te:t file could be used to track your changes or since we are all database developers<,B&s why not use S42 Server to document and track the changes. This should be one of the simplest things to implement and there is no reason you can start doing this today. ,isasters don@t strike all that often and because of this disaster recovery plans are usually not implemented. I am sure (ust about everyone has thought about this at one point in time but thinking about a disaster recovery plan and implementing a plan are two totally different things. &s a ,B& you need to take the time to determine what kind of issues may arise and how to resolve the problem when it does occur. Think about this from a server level database level and also down to a table level. 6nce you have determine what you need to do and how you are going to go about resolving the issue take the time to do some tests. Eou don@t need to test every single server in your environment but you should try to test each type of failure that you are trying to recover from. &nother thing to put in place is a priority list for your servers and your databases. This way if there are multiple failures that occur you already have a priority list of what needs to be addressed and the order that they need to be dealt with. Security is also another area that is the ,B&s responsibility to monitor. &s you probably know security levels e:ist at the #indows server level S42 Server server level database level ob(ect level etc... There are S42 Server server level roles database roles and user defined roles. Take the time to analy7e your permission structure and make the necessary ad(ustments to ensure people have the rights they need to work but not additional rights that may cause potential problems. In addition to securing your database servers make sure your database backups and any e:ternal programs are also secure so no one can gain backdoor access to your servers or your data.

,ocument

'reate and Test ,isaster 3ecovery Glan

1; 9anage Security

Next Steps +ow that you have a list of some basis items to address$ chec% off which items you have already implemented and start addressing the other items" ,f you are not sure where to begin$ start with some of the simpler items li%e$ bac%ups$ documenting changes$ reviewing error logs and testing bac%ups-restores" ,f there are other items that you feel should be on this list$ let us %now" Send your ideas to tips.mss*ltips"com"