Developers: You Don’t Need a DBA. I’ll Prove It.

#SQLPass, SQL Server
11 Comments

That’s right, you heard me, and I’ll prove it on a really big stage. I’m honored to announce that I’ll be the first speaker at this year’s 24 Hours of PASS: Summit Preview Edition.

On Tuesday, September 9th, join me for my newest session: “Developers: Who Needs a DBA?” Here’s the abstract:

You store data in SQL Server, but you don’t have enough work to keep a full-time DBA busy.

In just one hour, you’ll learn the basics of performance troubleshooting and index tuning. I’m a recovering developer, and I’ll teach you the basic care and feeding of a Microsoft SQL Server 2005, 2008, 2012, or 2014 instance, plus give you scripts to keep you out of trouble.

Register now for free. While you’re there, check the boxes for some of the other 24 back-to-back SQL Server training sessions from community volunteers who’d love to share their knowledge with you. See you there!

Previous Post
Generating Identities
Next Post
Watch This Week’s Webcast Today (and Win a Prize Tomorrow)

11 Comments. Leave new

  • You’re outsourcing our jobs to developers???
    This sounds like a fun session! I’ve always been a fan of Devs knowing DBA work and DBAs knowing Dev work.

    Reply
  • EXEC sp_addsrvrolemember ‘domain\Developers’, ‘sysadmin’;

    What could possibly go wrong? 😀

    Sounds like a cool session, kind of a fresh (controversially worded!) take on the kind of overdone “Accidental DBA” angle.

    Reply
  • How would one reconcile this with separation of duties under Dodd/Frank, SOX, Basel, GLBA, etc.? Additionally, what of the necessities under PCI/DSS compliance?

    Reply
    • Keith – I’m not entirely sure what you’re asking. Are you saying that if you simply have a DBA, your separation of duties concerns disappear?

      Reply
      • Having a DBA is integral to separation of duties. For example, you cannot have a developer in a production environment under these regulatory schemes. Further, as an organization scales, the separation of duties will further separate for database and DBMS architecture, build, project development, security and production support.

        Without this plan, the chance of failure of audit increases. This applies in the accounting firm, the bank, and anyone who needs to process credit cards (to start).

        Reply
        • Keith – again, you’re implying that having a DBA with sysadmin rights in production, able to query data and get it out of the database, is somehow magically safe from audits. That’s just not true.

          You don’t fix separation of duties by adding a job role. You add it by separating the duties between staff members. Simply moving all of the tasks over to the DBA doesn’t mean they’re separate – you just have a new way to fail the audits.

          Reply
          • You have the right string but the wrong yo-yo in reading this. A DBA is integral… if you have developers in the appropriate roles with regard to separation of duties, they end up becoming DBA’s in all but name. It would be wise to consult COBIT/ITIL in these cases.

            I am not saying that it is ‘magically’ safe from audit. I am saying that the roles are attuned to maintaining safety in compliance and facilitating the success of audit.

            There are further duties of a DBA that also lend in such as monitoring and capacity planning that while there are scripts to help perform the task, they are not the sum total of the task.

            It is wise to at the very least have an experienced DBA on retainer for consultation and the emergent situation for these deep knowledge subjects.

          • Keith – we’re just going to have to agree to disagree. Thanks for stopping by though!

          • FYI – In this day, DBA’s in production do not all have SA authority any longer and are granted such authority during restricted hours or for production moves and are only allowed to query data during non-production hours so not to impact production.

          • Keith – again, I respect what you’re saying, but it just doesn’t map up to what I usually see. In the vast, vast majority of shops I see (non-Fortune-100 type shops), the DBA is SA. But I’m glad to hear you’re one of the exceptions, and sounds like you’ve got it all under control in your shop. (Or rather, it’s out of your control, heh!)

      • Brent, actually I am the guy in control and the architect who has had to analyze and react to this new reality. I am not approaching this from the standpoint of doing what all others do in the vast amount of shops but being the guy referenced in protecting and being proactive… this is the new reality and not just the Fortune 500. This is especially true as we see more data breaches. PCI/DSS 3.0 is about to hit and we shall see more of this scheme hitting the mom and pop shop, the local accounting and legal LLC, etc.

        Reply

Leave a Reply

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

Fill out this field
Fill out this field
Please enter a valid email address.