About John Sansom

I’m a Microsoft Certified Master(MCM) of SQL Server. I’ve been working with database technology in a variety of flavors for over fifteen years. I absolutely love what I do and genuinely feel privileged to be a part of our tremendous technology community. Got a question about SQL Server or being a DBA? Ask me!


Comments

  1. Excellent article.
    Concise and to the point.

    Thanks John.

  2. Darren McCarthy says:

    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

  3. 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.

  4. great article

  5. Santhakumar says:

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

  6. Swati Madan says:

    Really nice and easily understandable!!

  7. Nic Neufeld says:

    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

  8. 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

  9. Awesome article

Leave a comment

*