Bread and Butter of SQL Server DBA - Part 1

  • Can we please rise above the "grammar issues".

    I really enjoy hearing from the global community, and appreciate the effort everyone puts into volunteered articles.

    I look forward to more articles in the series.

  • It's plain grammar issues. There is no need to place the subject in quotes. The issues are real. Readers will distrust the technical content when the verbiage in the article is flawed.

    Just because the content is volunteered is not a good reason to look the other way when the prose is riddled with errors.

  • Steve Jones.

    Thanks for updating the article.


    Please check the article when you get a chance.

  • Carla Wilson (7/15/2008)

    Can we please rise above the "grammar issues".

    I really enjoy hearing from the global community, and appreciate the effort everyone puts into volunteered articles.

    I look forward to more articles in the series.

    Since we're here on this Internet seems to me that one's grammar comprises a very large part of how one presents oneself to the rest of the world. It actually is important. It actually says something.

    In any event, pointing out problems with the article's presentation is not mean. It is just plain fact. If my kid spells "cat" like K - A - T, I don't tell him he's 2/3rds right and pat him on the head. Some might, but woe be unto that child when faced with reality, later.

    I've actually refused to use software at times because either the accompanying literature or the interface, itself, was rife with horribly written prose. Why? Carelessness evident in what I can see only makes me distrust what I can't (i.e. the underlying code).

    Now, the upside for the article's author: I wouldn't even be able to write out [all 18 words of] Stallone's dialog from Rambo: First Blood in MAK's native language (whatever that is). Okay. Got it. English is his second language. That is what his grammar is telling us. Ain't nothing wrong with that. Knowing that, though, does not make the grammar right and didn't stop me from chuckling through bits of the article.

    And furthermore, all your base are belong to us. Make your time. Ha ha ha ha.

  • Great topic.

    I would add that you need to create a database before you can restore from your backup taken earlier.


  • There is no need to create a database before restoring a backup.

    However, I will discuss about creating a database first and restoring the backup is faster in later part of article.

  • MAK

    looking forward to the next part.. you have selected the very important topic for all dbas...

  • Well done article. Thank you. I initially anticipated discussing all 4 types of backups at the same time, but what is present is well done.

    Incidentally, for any but the smallest SQL Server installations, there are some very nice 3rd party tools which simplify the process. I use SQL Backup 5, but there are a few others out there as well.

    Timothy A Wiseman
    SQL Blog:

  • Is this article discussion thread or grammar discussion thread? Why all of a sudden people pay more attention to grammar and spelling than the content of the article?

  • For general practice about backing up the database, I want to know if majority DBAs do a full database backup everyday or every week?

    I do a full backup every week and everyday I do differential backup, is it alright? The database I am in charge is not changed much everyday and does not need to be up 24/7.

  • Loner, to me it really depends. You have to choose the backup/restore strategy which works best with your maintenance window, DR plan, db usage, etc... I manage roughly 20 separate instances at my current job and it's a mixed bag.

    On our highest use and most high-priority cluster I do a full backup on the weekends, differentials nightly and log backups throughout the day. We just didn't have the time to work in a full backup nightly, and our data storage expenses would've ballooned upward with the tape costs to store backups in compliance with our retention policy.

    However we have other servers where I just do one full backup of all databases per night and that's it. We've got databases that are only a gig or two in size, don't change that often, and we've determined that we can easily lose up to a single day's worth of data without issue (dev/qa servers usually).

  • @Loner

    It depends on the criticity of your database/application, and the number of dbs you have to manage.

    I manage to backup more than 200 sql dbs from some MB to several TB, and generally doing the following is a good basis.

    - 1 full backup weekly

    - 1 differential backup daily

    - 1 transaction log backup every hour / 2 hours

    To be adapted to your environment.

  • Sorry this is a bit off-topic, MAK...

    Hi Loner,

    Good advice from the other guys, but I would add that primarily the strategy you chose is should be based on business need for recovery. In other words, how much data can the business afford to lose and how quick they would need to be up-and-running again.

    As an example, for one set of 3 servers that we managed the business could afford to lose 1/2 an hours worth of data and would need to be up-and-running again within 24 hours. It was also critical to secure a full backup each 24 hour period as there was a daily cycle of data purging. These were 5 largish databases on the instance (one instance per server), approx 60 GB each, with approx 12 GB streaming in and 12 GB purged per database per day. The system was to run 24/7. So from this we developed the backup regime to achieve the business requirements.

    For other databases, there was less of a requirement and they had a window available of 12 hours. So here we created a different backup regime that was much different to the above.

    Its worth noting, too, that quite often the business don't know their requirements until you start putting the questions to them about 'how much data can you afford to lose if there was an issue?' or 'how long could you cope without access to xxx database?', etc. Once they start to think about it, it often surprises them at how reliant they are on these systems, and especially the data.


  • I Guys i would like to post an article about databases because i am managing an sql server 2005 so i will post the article in a moments and i would explain how to make a full backup, differential backup, transaction log backup and the possibilities to recover the databases.

    If you find any error in my grammatical just let me now.

    Luis F Guzman.


  • Looking forward to part 2, especially strategies on table backups/restores.

Viewing 15 posts - 16 through 30 (of 32 total)

You must be logged in to reply to this topic. Login to reply