Go to Top

Another dropped table? SQL DBA to the rescue!

Anyone in an IT role has two kinds of work days. Good days are defined by no one bothering them and they get to work on the strategic business initiatives they’ve been assigned to enhance the functioning of their business. Bad days are plagued with a long list of interruptions in the form of “tickets” or requests from development, legal or other departments that urgently require your genius to get them back up and running. Every good Database Administrator (DBA) has far more bad days than good because SQL table/row restores are a weekly, if not daily occurrence.

Why does this happen? The reasons are countless… The finance team started using the wrong currency or conversion rate on a report at some point and needs to get it corrected. A developer deleted a table. During a routine update of the business system, an admin deleted rows they thought weren’t important – turns out they were used by many other tables and caused the system to fail. The list goes on and on.

Once a problem is identified, you are called to resolve the issue. I bet your approach goes a little something like this… First, you determine when in time the data was good. Next, you find a backup that contains the database with the table(s) with the “good” data. The full database will need to be restored. This process requires finding a SQL server and sufficient storage space. Restoring a database can take many minutes, but you know all too well that this often takes an hour or many hours depending on the size of the database. The process requires frequent monitoring and you cost a lot per hour! After the database has been restored, you examine it to determine if the desired table is present. If not, you continue restoring databases until the table is found right? Once the desired table has been found, you copy it to the production environment using scripts. And when a critical revenue application is down, all of this is happening with the CIO standing behind you looking over your shoulder.

Are you tired yet? I am. We are interested in learning more about how often this happens to you. Share your experience by taking this short poll: https://www.surveymonkey.com/s/NGPJZQQ.

, ,

One Response to "Another dropped table? SQL DBA to the rescue!"

  • Rich P
    13th August 2014 - 9:20 am Reply

    You present quite a dilemma. Backups are nice, but it is even more powerful when coupled with well thought restrictions, guidelines and procedures to manage the flow of data as well as the ongoing structure changes to the schema itself.

    Do yourself a small favor and set up at least a developer tier outside of the production system. Get your ad hoc DML scripts done right and tested there first, *save* it there and migrate the SQL snippet or whatever code appropriately.

    The only command line stuff run on *PRODUCTION* should be existing/tested database api calls or blocks of tested scripts.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current ye@r *