Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

The Best Database Administrators Automate Everything Expand / Collapse
Author
Message
Posted Friday, April 06, 2012 9:46 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, April 11, 2014 8:03 AM
Points: 1,149, Visits: 231
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.
Post #1279554
Posted Friday, April 06, 2012 9:57 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
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
Post #1279559
Posted Friday, April 06, 2012 10:38 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Today @ 8:35 AM
Points: 27, Visits: 454
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
Post #1279583
Posted Monday, April 09, 2012 10:20 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, April 08, 2014 11:58 AM
Points: 38, Visits: 179
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.



Post #1280243
Posted Monday, April 09, 2012 2:22 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, October 07, 2013 6:39 AM
Points: 47, Visits: 133
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.
Post #1280444
Posted Monday, April 09, 2012 2:45 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
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
Post #1280453
Posted Monday, April 09, 2012 2:55 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
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
Post #1280455
Posted Monday, April 09, 2012 8:07 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Today @ 3:05 AM
Points: 12, Visits: 253
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.
Post #1280564
Posted Monday, April 09, 2012 8:19 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, March 24, 2014 12:12 PM
Points: 4, Visits: 53
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"
Post #1280567
Posted Monday, April 09, 2012 11:57 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
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
Post #1280615
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse