Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Best Database Administrators Automate Everything


The Best Database Administrators Automate Everything

Author
Message
Greg.Jackson
Greg.Jackson
SSCrazy
SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)

Group: General Forum Members
Points: 2174 Visits: 385
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.
John.Sansom
John.Sansom
SSC-Addicted
SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)

Group: General Forum Members
Points: 433 Visits: 1558
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.


John Sansom (@sqlBrit) | www.johnsansom.com
jswong05
jswong05
Valued Member
Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)Valued Member (59 reputation)

Group: General Forum Members
Points: 59 Visits: 476
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
http://dbace.us

Jason
http://dbace.us
:-P
dlineberry
dlineberry
SSC Rookie
SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)

Group: General Forum Members
Points: 43 Visits: 246
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.



ryan.mcatee
ryan.mcatee
Valued Member
Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)

Group: General Forum Members
Points: 57 Visits: 134
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.
John.Sansom
John.Sansom
SSC-Addicted
SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)

Group: General Forum Members
Points: 433 Visits: 1558
Hi Ryan,

Consider that the article theme is to encourage the development of a mind set that looks to automate all processes, where applicable. It is not the aim of the article to explicitly identify what those processes are, as these are too varied from one Data Professional role to another i.e. the processes are often context specific.

How would you suggest that the article could provide what you would consider to be sufficient depth, whilst at the same time not being process/scenario specific?

Thanks for your comments.


John Sansom (@sqlBrit) | www.johnsansom.com
John.Sansom
John.Sansom
SSC-Addicted
SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)

Group: General Forum Members
Points: 433 Visits: 1558
dlineberry, thanks for your comments sir.

It sounds as though you are well versed in the art of automation and I imagine you probably have some great code/advice you could share with us.


John Sansom (@sqlBrit) | www.johnsansom.com
slim.richard
slim.richard
SSC Rookie
SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)

Group: General Forum Members
Points: 25 Visits: 355
I'm not sure if I agree with the automate 'everything' fanaticism. Some things just add to your technical debt as you are creating code that needs to be managed and updated. My last job I spent 90% of the time fixing the hundreds of legacy automation scripts dozens of dba's had created over the 20 or so years the systems had been operational (all using there own styles and preferred tools). Every time we patched an instance there were hundreds of scripts that needed testing to make sure they still worked!

Not saying automation is bad just that you have to be careful to not overdo it and to have a good clean out periodically where you review a scripts usefulness and if any in built sql tools would be better utilised instead of a roll your own solution. For example they had written a log shipping solution (as in built log shipping wasn't very good when they wanted it) so you could easily get rid of that for the in built log shipping.

Overall I agree that automation is king but due to my experiences I am choosy about what I automate and especially the tools I use.
SQL-Expat
SQL-Expat
Forum Newbie
Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)

Group: General Forum Members
Points: 8 Visits: 57
yes. I agree...

I like this I recently saw on a job description for a mySQL DBA for Facebook:

"Candidates should have extensive experience in writing efficient automation software and a visceral aversion to doing the same task twice"
John.Sansom
John.Sansom
SSC-Addicted
SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)SSC-Addicted (433 reputation)

Group: General Forum Members
Points: 433 Visits: 1558
slim.richard (4/9/2012)
....
Not saying automation is bad just that you have to be careful to not overdo it and to have a good clean out periodically where you review a scripts usefulness and if any in built sql tools would be better utilised instead of a roll your own solution. For example they had written a log shipping solution (as in built log shipping wasn't very good when they wanted it) so you could easily get rid of that for the in built log shipping.

....


Well said, automation is most certainly not "deploy and forget". It's about working more efficiently and maximising your resource (time) as a Data Professional, and a key part of that involves reviewing your existing automated solutions in light of technology developments and changing business requirements.


John Sansom (@sqlBrit) | www.johnsansom.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search