February 15, 2013 at 9:52 am
Jeff Moden (2/14/2013)
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!
Cheers buddy. I figured the money will come with time. Get the DBA experience and then go for better paid jobs when the time is right.
---------------------------------------------------------
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
February 15, 2013 at 9:58 am
Jeff Moden (2/15/2013)
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.
Those people aren't DBAs. If you're a DBA, it is absolutely self evident to you that you need backups.
But typically the DBA is not in direct charge of the physical storage itself. So when you work somewhere as a DBA, you follow their existing guidelines for how backups are preserved to insure that they are available. Some places use replication, some use Tivoli, there are dozens of possibilities.
My idea is to prevent the need to do recoveries if at all possible. You do that by tuning the system, in particular to avoid deadlocks. You want to prevent the need for point-in-time recoveries, not just become adept at doing them.
Of course you can't prevent hardware/controller-related failures. But much of the time the problem originates with db issues or foreseeable issues, such as disk space shortage. Much better to alert yourself in advance to potential failures and prevent them than become adept at damage recovery afterward.
As an analogy, fire suppression is vastly better than being an expert at reworking charred wood.
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".
February 15, 2013 at 10:11 am
I've got scripts that will generate point-in-time recovery scripts. And generate and execute tail log backups.
I suspect you could get a script(s) from the web for that and modify it(them). True, finding good script(s) online may be difficult, but over time, as you learn more, you can refine the script.
That stuff is purely mechanical. Yes, it's not something you would want to do w/o practice beforehand, but you should be able to get through it. For a basic point-in-time recovery, MS has literally made it a point and click operation!
But it takes knowledge and experience to tune indexes, PERIOD! There are very, very few scripts that even purport to recommend best indexes, and none of them are really trustworthy. You simply must have a knowledgeable person to review and implement index changes.
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".
February 15, 2013 at 10:13 am
The biggest difference between being a database developer and a DBA is one of mind set.
The DBA must take ownership of his environment.
You have to monitor everything and make sure the monitoring works (especially if you are using SCOM or third party tools).
You have to try to understand what the risks are in your environment and find ways to mitigate them.
My son once asked me a few years a go what I really did at work, and my answer was "mainly I worry a lot!".
February 15, 2013 at 10:44 am
From my point of view walking into a new company as a "new" DBA is a intimidating task. As you can tell from the answers (good ones) provided here, everyone has a similar yet different point of view. Because I don't want to virtual reiterate all of the good points mentioned already I'll just say:
Get comfortable with your environment as soon as possible, learn about your servers!
If you're the only DBA (or one of a very small team) there's going to be a lot of things you'll find yourself worrying about, the faster you can isolate the things that are problems (or will become problems) over things that aren't major fires, the more quickly you will gain some confidence in your role. Then as you get one thing at a time under your belt, start learning the stuff you aren't so knowledgeable of.
Don't try to tackle everything at once (because there will be undoubtedly too many), just pick a few at a time and work through them in chunks. When faced with tough situations don't be afraid to ask questions! or rely on your friends here @ SSC 😀
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
February 15, 2013 at 11:38 am
ScottPletcher (2/15/2013)
I've got scripts that will generate point-in-time recovery scripts. And generate and execute tail log backups.I suspect you could get a script(s) from the web for that and modify it(them). True, finding good script(s) online may be difficult, but over time, as you learn more, you can refine the script.
That stuff is purely mechanical. Yes, it's not something you would want to do w/o practice beforehand, but you should be able to get through it. For a basic point-in-time recovery, MS has literally made it a point and click operation!
But it takes knowledge and experience to tune indexes, PERIOD! There are very, very few scripts that even purport to recommend best indexes, and none of them are really trustworthy. You simply must have a knowledgeable person to review and implement index changes.
I absolutely agree that it takes knowledge and experience to tune indexes. That's not, however, the primary job of a DBA. In theory, a systems DBA doesn't even need to know how to do such a thng although I agree that good DBAs should know how to tune indexes.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 15, 2013 at 11:40 am
ScottPletcher (2/15/2013)
Those people aren't DBAs. If you're a DBA, it is absolutely self evident to you that you need backups.
That's why I raised the flag on this. The OP wants to become a DBA. Since he's new, it may not be self evident.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply