SQL Developer to SQL DBA

  • Any tips on making this career change?

    Has anyone done this?

    Many thanks,

  • Must read "How to become an Exceptional DBA" by Brad McGehee

  • Suresh B. (2/14/2013)


    Must read "How to become an Exceptional DBA" by Brad McGehee

    Not a bad read, here's a link to my copy of the ebook (pdf format): https://dl.dropbox.com/u/52486810/How_To_Become_An_Exceptional_DBA_Ebook.pdf


    MCITP
    MCTS - E-Business Card
    Twitter: WWDMark

    Try not! Do or do not, there is no try

    email: info@weekendwebdesign.co.uk
    Personal Website: http://markallen.co.uk/
    Business Website: https://www.weekendwebdesign.co.uk

  • WWDMark (2/14/2013)


    Suresh B. (2/14/2013)


    Must read "How to become an Exceptional DBA" by Brad McGehee

    Not a bad read, here's a link to my copy of the ebook (pdf format): https://dl.dropbox.com/u/52486810/How_To_Become_An_Exceptional_DBA_Ebook.pdf

    Also available from the books section http://www.sqlservercentral.com/Books/

  • Also worth a read is this http://www.red-gate.com/community/books/accidental-dba or you can buy it from amazon, just follow the amazon link.

    Edit : Also on that link that Anthony sent

    _________________________________________________________________________
    SSC Guide to Posting and Best Practices

  • mr.neil.bryan (2/14/2013)


    Any tips on making this career change?

    Has anyone done this?

    Many thanks,

    Yup, I made this decision in July last year however, as hard as I tired I couldn't secure a full on DBA job so I took a 15k paycut and settled for a 50% DEV 50% DBA job. Now 6 months into my new role and I've learnt more about SQL Server than I did in 4 years in my previous role!

    I am now given the opportunity to work with SQL Server 2005, 2008, 2008R2 and 2012. I do backups, restores, server installation/configuration etc.. I built my own DBA repository and was given the opportunity to invest in some great third part tools to monitory our SQL Server environments. All in all I feel like I made the right choice.

    I love it... some days lunch time comes and goes and I don't even know about it that's how much fun it is.

    The only thing I'm not working on is stuff like replication, clustering etc... That I guess will be for another adventure.

    Good luck!

    ---------------------------------------------------------

    It takes a minimal capacity for rational thought to see that the corporate 'free press' is a structurally irrational and biased, and extremely violent, system of elite propaganda.
    David Edwards - Media lens[/url]

    Society has varying and conflicting interests; what is called objectivity is the disguise of one of these interests - that of neutrality. But neutrality is a fiction in an unneutral world. There are victims, there are executioners, and there are bystanders... and the 'objectivity' of the bystander calls for inaction while other heads fall.
    Howard Zinn

  • Brad's books is extremely good. You should also check out Thomas LaRock's book DBA Survivor. It covers the job from a different point of view.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • That's a significant change!

    In order, here's a quick list of the most important things to do first:

    1) Make sure the DBA role will fit you. As a developer, you get to see things through to production; often as a DBA you don't get those 'payoff' moment(s). Can you be happy in the new role?

    2) Study indexes: how they work, and how they're built, particularly clustered indexes since they are the most critical aspect of db performance. You can have a big impact immediately as a DBA by tuning indexes, esp. getting rid of dopey clus indexes on identities and replacing them with clustered indexes on the join column(s) when appropriate (which it very often is).

    3) Starting learing the Dynamic Management views and functions. They are the life blood now behind most DBA activities. This one alone will take quite a bit of time, so it will overlap other tasks.

    4) Learn to use Profiler. Not used as much now as it used to be, because of the DM views and functions, but anyone will expect a DBA to know how to use it, and it is still necessary at times.

    5) Learn how to add simple "Severity Level" alerts in SQL. They are easy to set up and can provide a quick heads up of issues when you're getting started. Since you'll want to use email for these, it also gives you a lead into learning how to set up db mail, operators, etc., which you do in conjunction with setting up the Alerts.

    SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

  • ScottPletcher (2/14/2013)


    That's a significant change!

    In order, here's a quick list of the most important things to do first:

    1) Make sure the DBA role will fit you. As a developer, you get to see things through to production; often as a DBA you don't get those 'payoff' moment(s). Can you be happy in the new role?

    2) Study indexes: how they work, and how they're built, particularly clustered indexes since they are the most critical aspect of db performance. You can have a big impact immediately as a DBA by tuning indexes, esp. getting rid of dopey clus indexes on identities and replacing them with clustered indexes on the join column(s) when appropriate (which it very often is).

    3) Starting learing the Dynamic Management views and functions. They are the life blood now behind most DBA activities. This one alone will take quite a bit of time, so it will overlap other tasks.

    4) Learn to use Profiler. Not used as much now as it used to be, because of the DM views and functions, but anyone will expect a DBA to know how to use it, and it is still necessary at times.

    5) Learn how to add simple "Severity Level" alerts in SQL. They are easy to set up and can provide a quick heads up of issues when you're getting started. Since you'll want to use email for these, it also gives you a lead into learning how to set up db mail, operators, etc., which you do in conjunction with setting up the Alerts.

    Careful changing clustered indexes on tables. There may be significant reasons for their selection (or possibily not). Be sure if you do this that you have researched all the possibile implications of such changes. You don't want to get bit.

  • ScottPletcher (2/14/2013)


    That's a significant change!

    In order, here's a quick list of the most important things to do first:

    1) Make sure the DBA role will fit you. As a developer, you get to see things through to production; often as a DBA you don't get those 'payoff' moment(s). Can you be happy in the new role?

    2) Study indexes: how they work, and how they're built, particularly clustered indexes since they are the most critical aspect of db performance. You can have a big impact immediately as a DBA by tuning indexes, esp. getting rid of dopey clus indexes on identities and replacing them with clustered indexes on the join column(s) when appropriate (which it very often is).

    3) Starting learing the Dynamic Management views and functions. They are the life blood now behind most DBA activities. This one alone will take quite a bit of time, so it will overlap other tasks.

    4) Learn to use Profiler. Not used as much now as it used to be, because of the DM views and functions, but anyone will expect a DBA to know how to use it, and it is still necessary at times.

    5) Learn how to add simple "Severity Level" alerts in SQL. They are easy to set up and can provide a quick heads up of issues when you're getting started. Since you'll want to use email for these, it also gives you a lead into learning how to set up db mail, operators, etc., which you do in conjunction with setting up the Alerts.

    Oh, be careful now. All of that stuff is really nice to know but, if they know nothing else, these are the two things all DBAs MUST absolutely know.

    1. Learn how to do Point-in-Time Backups,Tail-Log Backups, and Point-In-Time Restores. Buy a copy of the SQL Server Developer's Edition and practice for hours every day for a month until you can do both in your sleep or when you have the worst hangover ever. You'll someday be required to do these tasks at 3 in the morning when you're both asleep and hungover. 😉

    2. Learn how to control all aspects of security. Don't forget to protect your backups. They ARE at risk and someone can rip off everything you have stored in your databases if they can get to your backups. Same thing here. Practice it until you puke.

    The primary jobs of a DBA are to protect the data and protect the server. [font="Arial Black"]EVERYTHING [/font]else is secondary.

    mr.neil.bryan (2/14/2013)


    Any tips on making this career change?

    Has anyone done this?

    Many thanks,

    Yes. See above. The true test of your metal will be 1) can you recover from a disaster and 2) can you keep the bad guys out even if the come from within.

    The DBA is the "Gate Keeper". Protect the data, protect the server.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Abu Dina (2/14/2013)


    mr.neil.bryan (2/14/2013)


    Any tips on making this career change?

    Has anyone done this?

    Many thanks,

    Yup, I made this decision in July last year however, as hard as I tired I couldn't secure a full on DBA job so I took a 15k paycut and settled for a 50% DEV 50% DBA job. Now 6 months into my new role and I've learnt more about SQL Server than I did in 4 years in my previous role!

    I am now given the opportunity to work with SQL Server 2005, 2008, 2008R2 and 2012. I do backups, restores, server installation/configuration etc.. I built my own DBA repository and was given the opportunity to invest in some great third part tools to monitory our SQL Server environments. All in all I feel like I made the right choice.

    I love it... some days lunch time comes and goes and I don't even know about it that's how much fun it is.

    The only thing I'm not working on is stuff like replication, clustering etc... That I guess will be for another adventure.

    Good luck!

    Very well done! I love these types of success stories!

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (2/14/2013)


    ScottPletcher (2/14/2013)


    That's a significant change!

    In order, here's a quick list of the most important things to do first:

    1) Make sure the DBA role will fit you. As a developer, you get to see things through to production; often as a DBA you don't get those 'payoff' moment(s). Can you be happy in the new role?

    2) Study indexes: how they work, and how they're built, particularly clustered indexes since they are the most critical aspect of db performance. You can have a big impact immediately as a DBA by tuning indexes, esp. getting rid of dopey clus indexes on identities and replacing them with clustered indexes on the join column(s) when appropriate (which it very often is).

    3) Starting learing the Dynamic Management views and functions. They are the life blood now behind most DBA activities. This one alone will take quite a bit of time, so it will overlap other tasks.

    4) Learn to use Profiler. Not used as much now as it used to be, because of the DM views and functions, but anyone will expect a DBA to know how to use it, and it is still necessary at times.

    5) Learn how to add simple "Severity Level" alerts in SQL. They are easy to set up and can provide a quick heads up of issues when you're getting started. Since you'll want to use email for these, it also gives you a lead into learning how to set up db mail, operators, etc., which you do in conjunction with setting up the Alerts.

    Oh, be careful now. All of that stuff is really nice to know but, if they know nothing else, these are the two things all DBAs MUST absolutely know.

    1. Learn how to do Point-in-Time Backups,Tail-Log Backups, and Point-In-Time Restores. Buy a copy of the SQL Server Developer's Edition and practice for hours every day for a month until you can do both in your sleep or when you have the worst hangover ever. You'll someday be required to do these tasks at 3 in the morning when you're both asleep and hungover. 😉

    2. Learn how to control all aspects of security. Don't forget to protect your backups. They ARE at risk and someone can rip off everything you have stored in your databases if they can get to your backups. Same thing here. Practice it until you puke.

    The primary jobs of a DBA are to protect the data and protect the server. [font="Arial Black"]EVERYTHING [/font]else is secondary.

    mr.neil.bryan (2/14/2013)


    Any tips on making this career change?

    Has anyone done this?

    Many thanks,

    Yes. See above. The true test of your metal will be 1) can you recover from a disaster and 2) can you keep the bad guys out even if the come from within.

    The DBA is the "Gate Keeper". Protect the data, protect the server.

    I haven't been required to do a point-in-time recovery or tail-log backup for MONTHS. Depending on the environment, that may never be required of your job as DBA.

    Certainly backups should be protected, that's self-evident and presumably wouldn't require separate training, at least at first, since the job you're at should have some mechanisms already in place for that.

    I'm trying to point out knowledge that will be useful immediately and often.

    SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

  • ScottPletcher (2/15/2013)


    I haven't been required to do a point-in-time recovery or tail-log backup for MONTHS. Depending on the environment, that may never be required of your job as DBA.

    Certainly backups should be protected, that's self-evident and presumably wouldn't require separate training, at least at first, since the job you're at should have some mechanisms already in place for that.

    I'm trying to point out knowledge that will be useful immediately and often.

    I'm with Jeff on this one. Getting good backups in place and then knowing exactly how to recover them is vital. Yeah, you won't recover to a point in time on a production system more than once or twice a year (at most, hopefully). But those will usually be screaming emergencies with your cube filled with management all watching your every keystroke. I think suggesting a high degree of confidence in your abilities in that area is absolutely a must for a DBA. Backup & Restore are the most fundamental skills and they really should be practiced and reinforced on a regular basis so that you, as the person who's going to recover an offline system at 3AM, is ready.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Just a thought.........does your company already have an existing DBA? If so, do you think they would be adverse to you shadowing them once or twice a week (time permitting of course)?

    I've always found that the best way to learn something new is to actually experience it with the helping hand and guidance of someone 'in the know' while supplementing that experience with theoretical knowledge from the literary sources that have been previously mentioned in this thread.

    I'm sure that if you asked your DBA they would take you through some of the daily routine tasks/checks etc as a starting point - this would at least give you an idea of what the job would/could be like on a day to day basis.

    If you have the resources available (i.e. cash and time) then the SQL Server 2008 and 2012 Microsoft courses ( (http://goo.gl/0Rh2t%5B/url%5D) may be of use.


    MCITP
    MCTS - E-Business Card
    Twitter: WWDMark

    Try not! Do or do not, there is no try

    email: info@weekendwebdesign.co.uk
    Personal Website: http://markallen.co.uk/
    Business Website: https://www.weekendwebdesign.co.uk

  • ScottPletcher (2/15/2013)


    Jeff Moden (2/14/2013)


    ScottPletcher (2/14/2013)


    That's a significant change!

    In order, here's a quick list of the most important things to do first:

    1) Make sure the DBA role will fit you. As a developer, you get to see things through to production; often as a DBA you don't get those 'payoff' moment(s). Can you be happy in the new role?

    2) Study indexes: how they work, and how they're built, particularly clustered indexes since they are the most critical aspect of db performance. You can have a big impact immediately as a DBA by tuning indexes, esp. getting rid of dopey clus indexes on identities and replacing them with clustered indexes on the join column(s) when appropriate (which it very often is).

    3) Starting learing the Dynamic Management views and functions. They are the life blood now behind most DBA activities. This one alone will take quite a bit of time, so it will overlap other tasks.

    4) Learn to use Profiler. Not used as much now as it used to be, because of the DM views and functions, but anyone will expect a DBA to know how to use it, and it is still necessary at times.

    5) Learn how to add simple "Severity Level" alerts in SQL. They are easy to set up and can provide a quick heads up of issues when you're getting started. Since you'll want to use email for these, it also gives you a lead into learning how to set up db mail, operators, etc., which you do in conjunction with setting up the Alerts.

    Oh, be careful now. All of that stuff is really nice to know but, if they know nothing else, these are the two things all DBAs MUST absolutely know.

    1. Learn how to do Point-in-Time Backups,Tail-Log Backups, and Point-In-Time Restores. Buy a copy of the SQL Server Developer's Edition and practice for hours every day for a month until you can do both in your sleep or when you have the worst hangover ever. You'll someday be required to do these tasks at 3 in the morning when you're both asleep and hungover. 😉

    2. Learn how to control all aspects of security. Don't forget to protect your backups. They ARE at risk and someone can rip off everything you have stored in your databases if they can get to your backups. Same thing here. Practice it until you puke.

    The primary jobs of a DBA are to protect the data and protect the server. [font="Arial Black"]EVERYTHING [/font]else is secondary.

    mr.neil.bryan (2/14/2013)


    Any tips on making this career change?

    Has anyone done this?

    Many thanks,

    Yes. See above. The true test of your metal will be 1) can you recover from a disaster and 2) can you keep the bad guys out even if the come from within.

    The DBA is the "Gate Keeper". Protect the data, protect the server.

    I haven't been required to do a point-in-time recovery or tail-log backup for MONTHS. Depending on the environment, that may never be required of your job as DBA.

    Certainly backups should be protected, that's self-evident and presumably wouldn't require separate training, at least at first, since the job you're at should have some mechanisms already in place for that.

    I'm trying to point out knowledge that will be useful immediately and often.

    According to all the posts of people crying about needing to recover data but not having a backup, I say that it's not "self evident" at all. And just because you haven't needed to do a PIT Restore in months doesn't mean that it's not one of the most important things that a DBA needs to do because, when the time comes that you do, it'll make the difference.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

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

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