• Pingback: SQL Server Essentials – Part 1: The Database Administrator’s Primary Responsibility | John Sansom - SQL Server DBA in the UK()

  • Pingback: DBA Survival Skills – Think Defensively | John Sansom - SQL Server DBA in the UK()

  • Pingback: Too Many Disasters To Choose From (T-SQLTuesday)()

  • Tahir

    Excellent article.
    Concise and to the point.

    Thanks John.

  • Darren McCarthy

    John,

    I am pursuing a CIS degree, and came upon your site and found your information to be very interesting reading. Thanks for all of your knowledge and input.

    Darren McCarthy

  • Pingback: Simplify Your DBCC CHECKDB Output - John Sansom SQL Server DBA in the UK()

  • Vivien

    Hey John,

    Thanks for this. Must-read for those who are just starting or thinking of starting a career in the world of DBA. Your article is easy to understand and to the point.

    • http://www.johnsansom.com John Sansom

      Thanks Vivien, glad you enjoyed it.

  • clare

    great article

  • Santhakumar

    Really a Great article for sql beginners.. Very easily understandable.. Thanks John

    • http://www.johnsansom.com John Sansom

      Thanks, glad you enjoyed it!

  • Swati Madan

    Really nice and easily understandable!!

  • Nic Neufeld

    I would add a few points garnered from my own experience. First, your business’s expectations of RPO are critical to be aware of. In a good-sized multi-server environment with lots of diverse databases (we’re clocking in just under 1400 databases on 80 something instances now), there are a lot of databases that are non-transactional in nature that simple recovery model is more appropriate for. When we consider our non-production tiers, none of which require anything more than full backups, our general approach is to start with Simple and switch to Full when the business needs it, which is mostly our transactional databases in the production tier.

    Full Recovery Model is a twin-edged sword, also. If improperly implemented (it is the default setting for Model, so very often people create new databases in Full Recovery without thinking about the ramifications) without also configuring regular transaction log backups, you are sitting on a timebomb. I’ve come into more than one company where I’ve seen this issue…the transaction log just grows and grows until it fills the drive. And plenty of people don’t create a separate volume for the transaction log file, too, so you can have a pretty ugly potential failure, as if your database shutting down wasn’t ugly enough. Even if you do have transaction log backups going, we’ve seen some funny issues…for instance, when we had a massive SSIS job running against a server, and we had improved our storage speed using SSDs, we actually filled up our transaction log drive in between the 15 minute increments for the transaction log backups! An amusing instance of fixing one thing (storage latency) creating a new, unexpected problem.

    My point being that full recovery model has some things people should be aware of…chiefly, whenever you set something to Full, make doubly sure you are backing up the transaction log!! And talk with the business about RPO…if your expectations and theirs aren’t in sync that can make for an unpleasant post-failure conversation… :D

  • Med

    I just want to say a big thanks because i have finally found what i was hoping for. Somebody who can give me the confidence and trust in becoming a Database Administrator. I think i have found that person and it’s you. Good articles , straight and simple. Thanks

    • http://www.johnsansom.com John Sansom

      Thank you for your kind words. Delighted you found the blog. You should check out the Community Forum too. It’s packed full of ambitious Data Professionals sharing and learning together.

  • Mahesh

    Awesome article