Automatic DBA

In a previous life, I spent countless hours watching gauges, taking logs and answering the bells on an engine order telegraph a couple hundred feet underwater: Life on a submarine can be quite boring. Six hours of every 18 were spent standing watch on the throttles (big chrome wheels on the left). It was boring…very boring…mind-numbing, like watching paint dry boring. And it was one of the most important jobs on the boat, because if you did not pay attention, if you didn’t follow the proper procedure and documentation, if you did not give the proper turnover to your relief then a catastrophic accident could occur. So it was vitally important to give a proper turnover.

I can hear it already, “What’s a turnover?” A turnover in the Navy, what we would call a transition in in Corporate America, is a process by where you provide information to your relief (replacement) for the watch station (position) that you currently hold. Kind of sounds mysterious, but is conceptually quite simple:

• You outline the current state of the system(s) that you are transitioning.
• You detail any anomalies that has occurred since you took over (or a sufficient period such that any relevant events can be considered).
• You review any existing documentation.
• You review most important standard operating procedures.

Once you have covered this information, you ask, “Is there anything else you wish to cover?” If there are additional questions you answer them. If not, “I stand relieved of the watch.” Sounds easy, but the details can get quite messy. For example, before I moved to the Data Warehouse group I created this transition document that outlined those items my replacement would need to know to be productive:

Application DBA – Transition Plan

1. Database Server Management
   1. Disk Space Management
      1. CA Tickets
      2. Database Growth Estimation
   2. Performance Monitoring
2. Database Build Management
   1. Data Refresh
      1. Redgate
         1. SQL Data Compare Projects
         2. SQL Package Projects
      2. Final Builder Project and Schedule
   2. SQL Auto-builds
      1. Final Builder Project and Schedule
   3. TCW Builds
      1. QA Build Process
      2. Prod Build Process
   4. Metadata Environment
      1. DDL-only Build
3. Turn Process
   1. Pre-Turn Validation
   2. Post-Turn Validation
   3. Damage Control – Turn Gone Wrong
      1. Discovery
      2. Correction
      3. Cleanup
4. Database Construction
   1. SQL
      1. “Do No Harm” Scripts
      2. True One-shots
   2. SSIS
      1. Construction
      2. Operation
         1. Database Server
         2. App Server
5. Control/Meta Data/Source Code Management
   1. SQL
      1. TFS Management
   2. SSIS
      1. Construction
      2. Operation & Management
   3. Configuration Data
      1. ORCA Files
      2. CMD Files
      3. CONFIG Files
   4. Control/Meta Data
6. Database Consultation
   1. Strategy
      1. Technical Roadmap
   2. Tactics
      1. Database Design
      2. Query Optimization
7. Environmental Management
   1. General Server Health Monitoring and Management
      1. Architecture Database
         1. dbo.SQLPerfMon – Stores the aggregated historical data from the query cache; captured every hour.
   2. Technical Story Creation
      1. General System Improvement
      2. Database Specific Improvement

Environment Management Team – Transition Plan

1. New FTP Server Migration
   1. FTPNEWPRODSERVER – Production
      1. Replaces FTPPRODSERVER
      2. DNS – FTPProd
   2. FTPNEWTESTSERVER – Lower Environments
      1. Replaces FTPTESTSERVER
      2. DNS – FTPProof, FTPQA, FTPTest, FTPDev
2. General Monitoring
   1. Messaging
   2. ISO Listener
   3. Process Tracker
3. Environment CA Ticket Resolution
   1. Research
   2. Procedural Resolution    
4. Metavante Management
   1. Password Reset
   2. Outage Management

Needless to say that is quite a bit of information….and this is just the outline. Almost all this information was held in a multitude of documents in the document repository. It was necessary to understand all of this information to properly manage the SQL Server environments. Really, this was the MINIMUM NECESSARY INFORMATION to transfer. I could have dumbed it down, but then I’d be doing a disservice to my fellow associate and not leading them toward perfect service.

And that is the crux of this discussion: Leadership….Anyone at any time has the ability, and responsibility, to lead. And it is when you exhibit leadership that everyone benefits; management, customers, fellow associates and shareholders.

Many lose site that leadership is an exhibited attribute of a person, not the authority of a position. They similarly confuse the action of leading with the act of dictating. This can’t be further from the truth. In the simplest term a leader is someone who is followed by others. So if you are responsible for handing off a system(s) to another person (group, unit, etc.) you are a leader…Act accordingly.