Your Role Is Changing

  • stakes

    Ten Centuries

    Points: 1376

    Comments posted to this topic are about the item Your Role Is Changing

  • akljfhnlaflkj

    SSC Guru

    Points: 76202

    We're so small our DBA is also a developer. Our collaboration is just fine.

  • Bill Talada

    SSChampion

    Points: 11956

    I had to read this to understand what a DevOp is:

    http://en.wikipedia.org/wiki/DevOps

    I've consulted at many corporate headquarters and found most of their databases designed at a kindergarten quality level. The DevOps article seems to focus on stepping up that level of quality of delivered code while the editorial here seems to focus on collaboration. Both are necessary for a DBA to stand out today. In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details. Also I believe the Information Age is gone and we have been in a collaboration age for many years already. A DBA should be half individual and half team focused in order to maintain responsibility yet give some freedom to allow the team to evolve.

  • Patrick Cahill

    SSCertifiable

    Points: 5727

    Bill Talada (4/23/2015)


    In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details.

    I couldn't disagree more. Our developers are perfectly capable of writing stored procedures. I am more than happy to help them tune them, but they can write there own. As a DBA I have more important things to do than spending even 10% of my time writing procedures. I have spend a lot of time automating tasks, but even when things are automated there are still a lot of things to look at.

  • Sigerson

    Hall of Fame

    Points: 3697

    Patrick Cahill (4/23/2015)


    Bill Talada (4/23/2015)


    In my opinion, a DBA that isn't generating most stored procedures is wasting their life on ugly details.

    I couldn't disagree more. Our developers are perfectly capable of writing stored procedures. I am more than happy to help them tune them, but they can write there own. As a DBA I have more important things to do than spending even 10% of my time writing procedures. I have spend a lot of time automating tasks, but even when things are automated there are still a lot of things to look at.

    IMHO, I think Bill may have been saying that a DBA should write a lot of stored procs FOR automation, to automate all possible DBA jobs in order to give himself more time for the real, proactive problem-solving.

    Sigerson

    "No pressure, no diamonds." - Thomas Carlyle

  • Eric M Russell

    SSC Guru

    Points: 125114

    For many of us, the role hasn't changed, it's just been defined using a new acronym, which makes it a lot easier if someone asked what we do.

    DevOps, I do that.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Steve JP

    Ten Centuries

    Points: 1069

    Either way, as a DBA, you have to adapt. So how can you start changing? Go to one of your developers, or heck, attend one of their meetings and ask them: "How would you like me to collaborate with you?"..

    Did that once and they all wanted SA privs! Yeah,a s if that was going to happen!

  • stakes

    Ten Centuries

    Points: 1376

    And did you ask what they want to be able to do?

  • Steve JP

    Ten Centuries

    Points: 1069

    stakes (4/23/2015)


    And did you ask what they want to be able to do?

    "just in case we need it!"

    Where/when would you let developers have SA privs?

  • Eric M Russell

    SSC Guru

    Points: 125114

    stakes (4/23/2015)


    And did you ask what they want to be able to do?

    I think every DBA should sit down with the application development team at least once a year and ask this question... just for kicks. 😛

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell

    SSC Guru

    Points: 125114

    If a database architect, IT support, executive, or BI developer needs eleveated permissions to troubleshoot performance issues or run ah-hoc queries in production, you can setup something like a power user role, but NEVER grant them SYSADMIN or DBO membership.

    use SpecificDatabase;

    -- grant select on any table or view:

    exec sp_addrolemember db_datareader, 'DBPowerUsers';

    -- grant user permission to view execution plans:

    grant showplan to 'DBPowerUsers';

    -- server level permissions require that context be changed to [master] database.

    use master

    -- grant user permission to view object schemas:

    grant view any definition to 'DBPowerUsers';

    -- grant user permission to view system tables and views:

    grant view server state to 'DBPowerUsers';

    -- grant user permission to start sql profiler traces:

    grant alter trace to 'DBPowerUsers';

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • stakes

    Ten Centuries

    Points: 1376

    Steve JP (4/23/2015)


    stakes (4/23/2015)


    And did you ask what they want to be able to do?

    "just in case we need it!"

    Where/when would you let developers have SA privs?

    Nowhere/never. "just in case we need it!" is obviously no answer. You could have aswered something like "let me know when you have a case where you need sa privs and I'll grant them" in return. I'll bet they come up with whatever they can think of and you can then grant them the specific permissions they need for what they want to do.

    In which environment(s) do they want sa privs?

  • stakes

    Ten Centuries

    Points: 1376

    Eric M Russell (4/23/2015)


    If a database architect, IT support, executive, or BI developer needs eleveated permissions to troubleshoot performance issues or run ah-hoc queries in production, you can setup something like a power user role, but NEVER grant them SYSADMIN or DBO membership.

    use SpecificDatabase;

    -- grant select on any table or view:

    exec sp_addrolemember db_datareader, 'DBPowerUsers';

    -- grant user permission to view execution plans:

    grant showplan to 'DBPowerUsers';

    -- server level permissions require that context be changed to [master] database.

    use master

    -- grant user permission to view object schemas:

    grant view any definition to 'DBPowerUsers';

    -- grant user permission to view system tables and views:

    grant view server state to 'DBPowerUsers';

    -- grant user permission to start sql profiler traces:

    grant alter trace to 'DBPowerUsers';

    Good point and thanks for sharing the script! Granting them access to a readable secondary can also work.

  • Eric M Russell

    SSC Guru

    Points: 125114

    If users demand access to the 'SA' account, then give it to them.

    But first get rid of the default 'SA' and then create a new one having only the permissions you're willing to delegate. In the example below, we're renaming 'SA' to 'SA_BAK', and then re-creating 'SA' as a member of the 'DBPowerUsers' role.

    They can now login using their vanity 'SA' account and feel important. Unless they attempt to create, drop, or update objects, they won't know the difference.

    use MASTER

    go

    alter login sa DISABLE;

    go

    alter login sa with name = [sa_bak];

    go

    create login sa

    with PASSWORD = 'F5G8T9V0K1'

    , DEFAULT_DATABASE = master;

    go

    use Accounting;

    go

    drop user sa;

    go

    create USER sa for login sa;

    go

    exec sp_addrolemember 'DBPowerUsers', 'sa';

    go

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Gail Wanabee

    SSCrazy Eights

    Points: 8378

    My last DBA position was in the Operations part of a DevOps shop.

    The company's implementation of DevOps was a colossal failure in several respects:

    1. The ROI for the huge expansion of communication between departments was low,

    2. The amount of energy expended on communicating was high (and mostly wasted), and

    3. In general, the DevOps environment produced much frustration and hand wringing because real progress occurred at a snail's pace. We could talk much faster and farther then we could execute.

    The shop claimed it was Agile, but only in name. Development was Agile, but nothing else. (But which version of Agile? That's a discussion in its own right.)

    It had a CMS (Change Management System) in place that moved very slowly while the level of communication far outpaced it.

    The email flood was unbelievable. With every new employee added, the explosion of emails increased exponentially because increased communication is a core tenant of the DevOps "model", and everyone communicated like they "were supposed to".

    In summary, talking, writing, and hand wringing were substitutes and energy consumers for real progress. Communication was out of balance with other processes to meet objectives.

    There are optimal levels of communication to accomplish real work. Communication for its own sake is not progress and ultimately, counter productive.

    There may be other shops that have implemented DevOps successfully, but my last experience with it has left me very wary of it.

    Like Agile, DevOps sounds good, but since it is poorly defined (like Agile), people make it up as they go (like Agile).

    IMHO, both Agile and DevOps are good ways to avoid real planning which is hard work. Everyone is busy, busy, happy, happy, but doing what? Just busy.

    In 30+ years in IT, I've seen many ideas come and go. Like a lot of things in I.T., I predict DevOps is a fad that will come and go, mostly go.

Viewing 15 posts - 1 through 15 (of 32 total)

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