[Note from Pinal]: This is a 35th episode of Notes from the Field series. Doing this faster and easier is always our goal. We all want to do things which generates maximum return of investment with least efforts. This is a catch 22 situation quite often when it is about database administrators.
In this episode of the Notes from the Field series database expert Brian Kelley explains a how to automate various database administrator tasks for success of business and our efforts. Read the experience of Brian in his own words.
In the Linchpin People mindset, it’s not about how busy you are, but how valuable you are. You don’t increase your value to your organization by your busyness. You do so by accomplishing the work. There are two parts to this:
- Accomplish more work.
- Accomplish more important work.
Initially, if your path follows most people, you’ll be asked to do more. This is your opportunity to accomplish more work. As you succeed with the additional work that you receive, you will likely be given opportunities to take on more important work. If this never happens, you’re probably at the wrong organization. Let’s assume you are at a good one and you’re given more important tasks. Obviously, if you succeed at the more important work, you’ll continue to be given more opportunities. And you’ll likely be given tasks and projects that are more and more important to your organization. This is how you become a linchpin.
So how do you complete more work? One part of the answer is automation. Since we’re IT professionals, automation should be near and dear to us. I recently wrote about being a “lazy” DBA. I used the word lazy was to indicate there are some manual tasks we don’t want to repeat. A “lazy” engineer or IT pro tries to automate these tasks in order to reduce the time spent with these tasks. That frees up the IT pro to have more time for the more important work.
Let’s look at some things that we should automate as DB Pros:
Build scripts that can do the following:
- Check disk space on servers.
- Check database available space.
- Check security on key servers and databases.
- Verify backups were taken properly.
- Perform test restores of key backups.
- Parse the SQL error log on each SQL Server for important information (failed logins, use of sp_configure, etc.).
For instance, if I want to check backups to ensure a full backup has run on every database within the last 24 hours, I might automate running the following query to report back the datbases where I do not have the proper backup:
Isnull(CONVERT(VARCHAR, BS.lastbackup, 106), ‘No recent backup’) AS
FROM master.sys.databases AS D
LEFT JOIN (SELECT database_name,
Max(backup_finish_date) AS LastBackup
WHERE type = ‘D’
GROUP BY database_name) ASBS
ON D.name = BS.database_name
WHERE BS.database_name IS NULL
OR BS.lastbackup < ( Dateadd(hour, –24, Getdate()))
ORDER BY D.name;
We should also use automation like policy based management or custom scripts to enforce settings. Some examples that we should consider:
- database ownership
- recovery models
- membership in key roles (sysadmin, securityadmin, db_owner, etc.)
And here if I knew every user database on a given server should be in full recovery mode, I can ensure that if I schedule the following script:
DECLARE cursdbs CURSOR fast_forward FOR
WHERE state_desc = ‘ONLINE’
AND recovery_model_desc <> ‘FULL’
AND name NOT IN ( ‘master’, ‘tempdb‘, ‘msdb‘, ‘model’);
DECLARE @DBName SYSNAME;
DECLARE @SQL NVARCHAR(max);
FETCH next FROM cursdbs INTO @DBName;
WHILE ( @@FETCH_STATUS = 0)
PRINT ‘ALTERING DATABASE: ‘ + @DBName;
SET @SQL = ‘ALTER DATABASE [‘ + @DBName
+ ‘] SET RECOVERY FULL;’;
FETCH next FROM cursdbs INTO @DBName;
You do want to review that output. After all, if you just switched the DB to full recovery mode, you want to ensure you restart the log backup chain with a full or differential database backup.
Encourage continuous integration methods to include database code. This will require tests to validate no new code “breaks the build.” Make sure that these builds come directly from source control.
If you are doing tests that require restores of databases and the application of scripts, write the automation to do these tasks. It makes the tasks repeatable, it reduces the possibility of error, and it frees you up so you don’t have to manually run each step.
With that said, write scripts for anything you will have to repeat when developing a solution. For instance, you might need scripts to:
- Add, delete, or change data.
- Change security on a database or server.
- Encrypt / decrypt setup data.
Can you automate too much?
Yes, you can. Note that in both cases I did include some reporting. If you build automation where you’re not doing any checking, that’s wrong. Automation eliminates you from having to do tedious steps. It doesn’t remove your responsibility/accountability. If you don’t have anything to check, you don’t actually know if the work was completed successfully. Don’t assume. Check.
If you want to get started with performance tuning and database security with the help of experts, read more over at Fix Your SQL Server.
Reference: Pinal Dave (http://blog.sqlauthority.com)