April 5, 2012 at 10:19 pm
Comments posted to this topic are about the item The Best Database Administrators Automate Everything
April 6, 2012 at 1:04 am
Hi,
very nice article.
There's a chapter on the same topic (called the Self-healing database) in the book SQL Server DMVs in Action http://www.amazon.com/SQL-Server-DMVs-Action-Management/dp/1935182730/.
It contains SQL code for automatically: recompiling slow routines, rebuilding/reorganizing indexes, intelligently updating statistics, implementing missing indexes, and much more.
Chapters 1 and 3 are available for free at http://www.manning.com/stirk/
Enjoy
Ian
April 6, 2012 at 1:57 am
agree... but I still have not reached the holy grail of automating the patching, database failovers, reboots and failbacks of SQL servers in a 24x7 online environment. Has anyone?
April 6, 2012 at 5:10 am
I got to the point where I was constantly fighting fires and never really getting anything "useful" done. So, I decided that I would stop fighting the fires. Instead, I decided that they would eventually burn themselves out whilst I was getting on with getting things in good shape (i.e. fixing the underlying causes of those fires). To my surprise, the decision did not cause as big a problem as you would think. As I fixed the causes, my life got easier and easier. It became easier to do everything I needed to do (in the end, I was the only SQL DBA, managing 40 SQL Server installation (all quite similar installations) and about 10 other SQL Server installations that were unique).
So, get the right level of automation in place and you really can do some amazing things (and go home at a reasonable time of day, every day)
April 6, 2012 at 6:09 am
SQL-Expat, PowerShell can certainly help you with some of these tasks.
April 6, 2012 at 6:12 am
happycat59, Well said sir!
You're not ignoring the problem by working towards actually fixing it for good. It's called paying down Technical Debt.
Thanks for sharing your story.
April 6, 2012 at 7:06 am
John.Sansom (4/6/2012)
SQL-Expat, PowerShell can certainly help you with some of these tasks.
Agreed, I only picked up PowerShell a few months back, but it has been a life saver.
It has allowed me to:
- Populate a central repository of completed backups from all remote servers to watch for failures using SSRS.
- Script a remote start up and shut down of all SAP services on SQL clusters for monthly patching.
- Script the remote startup and shutdown of SQL services and bouncing of servers.
- Push SQL Alerts to all SQL servers to create some standards across our global infrastructure.
If you haven't used it yet, I would begin reading. Very easy to pick up.
April 6, 2012 at 7:40 am
Still on the topic of automating maintenance tasks.. consider the following monthly security patch maintenance steps on 100+ SQL Servers with 500+ databases:
1. install monthly security patches on all mirror servers (automated tool)
2. monitor mirror servers for any security patch related issues... (semi manual)
3. reboot all mirror servers (automated/scripted)
4. confirm successfull reboot and QA mirror servers (semi automated...)
5. failover all principals to mirrors (automated/scripted)
6. monitor mirrors (new principals) for any security patch related issue (semi automated...but requires manual checks)
7. ensure applications have redirected to mirrors
8. patch and reboot principals
9. confirm successfull reboot and QA principal servers
10. failback all databases to principals
11. QA - replication, mirroring, log shipping, application connections etc, etc
Now, most of the individual steps are scripted/automated. The tough part is having a master script or control that coordinates it all - something that poll all servers and only continue the sequence when required.. Curious if anyone has reached full automation on the above...
In some cases servers require 2/3 reboots.
Sometimes servers are in pending reboot state so require additional reboot before patching.
Some servers can take 30+ minutes to reboot...
Also, there's the suppressing of monitoring alerts during the maintenance too for things like Replication errors, log shipping latency, mirroring alerts etc.
thanks
SQL_EXPAT
April 6, 2012 at 8:05 am
Thanks for posting this article, it describes my main drive in my work.
In the past I used vbscript a lot, but became a convert of powershell and have never looked back since. I have noticed that I use SSIS a lot less since my powershell conversion 🙂
Powershell has even displaced my favorite scripting language, the mighty Python (may it live forever).
April 6, 2012 at 8:13 am
artilugio, my pleasure sir, I'm glad you enjoyed it.
Wait, do people even still use Python? 😉
April 6, 2012 at 9:46 am
John,
Thanks for posting. I've automated as many tasks as possible using a combination of TSQL, Powershell and VBscripts. One thing I have done is built a template and rolled it out to every instance (2005 and higher) that I administer. As a DBA who supports about 100 different instances (from version 2000 to 2008 R2 and everything in between.) this became absolutely necessary.
When I build an instance, I create a database on it used to gather performance statistics. It typically contains retention on the performance data of about 2 weeks. I then have a a template of queries used to analyze the data to obtain the typical load the server is incurring. Which really simplifies the process and frees up my time.
April 6, 2012 at 9:57 am
Hi Greg, it sounds like you're on the right track sir!
Using a "DBA" database on each instance in order to manage your environment, store your scripts etc. is a great idea. Thankfully, the performance monitoring aspect of things was given a helping hand with the arrival of the Performance Data Warehouse (PDW) feature of SQL Server.
Thanks for your comments.
April 6, 2012 at 10:38 am
Definitely. I agreed 100%. That is why I titled my web site "DBA Automation". Once you see the value, you will never go back.
Not only you automate your tasks, you also hand over the lower level support effort to the helpdesk 1st level support. Some people could not connect only because user errors. DBAs should not have to deal with those cases.
Some scenarios take more effort to test the automated scripts, for example, in a blocking production environment that blocking cannot be re-produced by will. But it can be done.
Ian, I love your book.
Jason
Jason
http://dbace.us
😛
April 9, 2012 at 10:20 am
I completely agree with automating everything and have been doing that since day one. I automate everything from data loading processes, I probably have about 200 daily and monthly, to file management to ftp using primarily tsql and dos commands and am just now getting into powershell.
Due to errors which occurred when I first started, I always include steps in my jobs to make sure the data is available, make sure it is the current days' data and make sure it is not in the process of being loaded as well as other similar verification processes. I do everything I can to not only automate but make sure they run reliably without error regardless of what the source has done, at least the best we can.
I love the ideas listed for other automation purposes sql_expat listed. If you have scripts to share for some of those I'd love to see them.
I am also in the process of doing exactly what blackheartbilly suggested, creating a central repository of sql backups. I have plans on implementing a process to schedule automated periodic restores, logging those, and providing them via sql reporting to management and business continuance for disaster recovery verification as well as meeting the needs of auditors. Black, if you don't mind sharing your script I'd love to see that as well. I already have a plan for how I intend on implementing this but would be interesting in comparing.
Good article by the way. This is something I truly believe in and would have 10 people working for me otherwise or be coming in at 3:00am to make sure data was available and being processing data. I don't even know how I would do my job without automating; it is normally one of the first things on my mind the second a new data request comes in.
April 9, 2012 at 2:22 pm
SQL_EXPAT (4/6/2012)
Still on the topic of automating maintenance tasks.. consider the following monthly security patch maintenance steps on 100+ SQL Servers with 500+ databases:1. install monthly security patches on all mirror servers (automated tool)
2. monitor mirror servers for any security patch related issues... (semi manual)
3. reboot all mirror servers (automated/scripted)
4. confirm successfull reboot and QA mirror servers (semi automated...)
5. failover all principals to mirrors (automated/scripted)
6. monitor mirrors (new principals) for any security patch related issue (semi automated...but requires manual checks)
7. ensure applications have redirected to mirrors
8. patch and reboot principals
9. confirm successfull reboot and QA principal servers
10. failback all databases to principals
11. QA - replication, mirroring, log shipping, application connections etc, etc
Now, most of the individual steps are scripted/automated. The tough part is having a master script or control that coordinates it all - something that poll all servers and only continue the sequence when required.. Curious if anyone has reached full automation on the above...
In some cases servers require 2/3 reboots.
Sometimes servers are in pending reboot state so require additional reboot before patching.
Some servers can take 30+ minutes to reboot...
Also, there's the suppressing of monitoring alerts during the maintenance too for things like Replication errors, log shipping latency, mirroring alerts etc.
Good concept but the article was really thin and didn't really go into examples and depth. I like this comment because it dives a bit deeper into what "automate everything" means.
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply