July 3, 2014 at 3:18 am
Im in my new role 1 week now. I know this is not nearly enough time to judge a position, but id like to get a feel for what people think.
Previous role was as a sql consultant. Pretty high pressure at times, expected to hit the ground running, know your stuff and be highly productive all the time. I spent the last 10 months of consultancy with one client, as DBA & DB Developer for a company with 200+ sql servers from SQL 2005 to SQL 2014, SQL, SSAS, SSRS etc. Never a dull moment, super busy all the time, all the work hours you could want!
For a change of atmosphere i just took a new job with an educational institution. Its as close to green fields as ive come, i.e. all systems are vendor managed so my job is to see what data is there, with the long term goal of designing and implementing a large DWH so they can actually use their data.
After a week I have had almost nothing to do. No fires, no support calls, no analysts screaming about poor report performance etc. I have a few meetings with business staff to help them streamline creation of a few reports but that's it.
The IT Manager says to relax into the role, it will take time to get moving, but im not used to not being busy and its disconcerting. I think he is correct, a big change in direction for the IT Dept will take time, and he has to hire a handful more people to get the team moving. Its also a very different role being DWH Developer and not a Production support DBA.
My question is how long do i give it? Is 6 months a fair amount of time, after which it shows significant signs of improvement or i find something more to my liking?
Has anyone else made such a drastic change?
Is it wrong to feel need to be busy all the time?
July 3, 2014 at 3:44 am
Whoah whoah, big difference between stressy Production DBA and the relaxed life of a Business Intelligence developer 🙂
I believe it is normal that you have to work yourself in into your new job, especially if things still have to get moving.
As a consultant you probably were thrown right into the action of an already running machine, which is not the same as the thing you have going on right now.
Even if things pick up, I think there will still be less pressure than in your previous role. You have to decide for yourself if you are comfortable with that. The import thing right now is to not get bored, because that will kill your motivation and desire to come to work. Maybe you can start on an analysis of the source systems and think about how you are going to build a dimensional model on top of that.
If you are not familiar with dimensional modelling, you can do some research for example.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 3, 2014 at 4:00 am
Koen Verbeeck (7/3/2014)
Whoah whoah, big difference between stressy Production DBA and the relaxed life of a Business Intelligence developer 🙂
Apologies if I offended, Im not saying BI guys dont work very hard or Production DBA's are better in any way, Just trying to articulate the differences between the roles as i see them at present.
Appreciate the feedback, it will take time to see if the job fits. I will defo give it 6 months and reassess after that.
Currently waiting on access to a number of systems before i can really start digging into data. pace of life in a non profit educational institution is very different from that of a private sector billion dollar generating financial institution! Right now Im certainly not comfortable with the slower pace but maybe it will grow on me!
July 3, 2014 at 4:17 am
winston Smith (7/3/2014)
Koen Verbeeck (7/3/2014)
Whoah whoah, big difference between stressy Production DBA and the relaxed life of a Business Intelligence developer 🙂Apologies if I offended, Im not saying BI guys dont work very hard or Production DBA's are better in any way, Just trying to articulate the differences between the roles as i see them at present.
Certainly no apologies needed! I believe that in general the life of a BI developer is less stressful than that of a DBA. No fires to put out (unless a report is running slow), no being on-call, no long deployment weekends. We have the good life sir 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 3, 2014 at 11:06 am
Of course if you're a good DBA, not only will put out the fires, you will put processes in place to prevent fires from occurring, and eventually the late night & weekend calls will stop and your job will be mostly checking your email periodically for performance alerts, which become less frequent until your employer has a new project.
July 3, 2014 at 1:21 pm
dan-572483 (7/3/2014)
Of course if you're a good DBA, not only will put out the fires, you will put processes in place to prevent fires from occurring, and eventually the late night & weekend calls will stop and your job will be mostly checking your email periodically for performance alerts, which become less frequent until your employer has a new project.
This reads like an accusation that i am not a good DBA...Someone needs to work on their written communication skills!;-)
July 3, 2014 at 1:41 pm
winston Smith (7/3/2014)
dan-572483 (7/3/2014)
Of course if you're a good DBA, not only will put out the fires, you will put processes in place to prevent fires from occurring, and eventually the late night & weekend calls will stop and your job will be mostly checking your email periodically for performance alerts, which become less frequent until your employer has a new project.This reads like an accusation that i am not a good DBA...Someone needs to work on their written communication skills!;-)
No, I'd say that's pretty accurate for a good prod DBA. If you're not doing that, well, you've reached your own conclusion.
And no, that's not meant to be funny.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
July 3, 2014 at 2:00 pm
I think one year is enough time. Six months may not be enough time. Although, if after six months there is no movement in hiring the new staff and getting your role defined, you need to begin pushing a little. Educational institutions have their own rythm and flow. They tend to be a bit more relaxed. Coming from a high stress environment can be a little disconcerting.
Tom
July 3, 2014 at 2:14 pm
Evil Kraig F (7/3/2014)
winston Smith (7/3/2014)
dan-572483 (7/3/2014)
Of course if you're a good DBA, not only will put out the fires, you will put processes in place to prevent fires from occurring, and eventually the late night & weekend calls will stop and your job will be mostly checking your email periodically for performance alerts, which become less frequent until your employer has a new project.This reads like an accusation that i am not a good DBA...Someone needs to work on their written communication skills!;-)
No, I'd say that's pretty accurate for a good prod DBA. If you're not doing that, well, you've reached your own conclusion.
And no, that's not meant to be funny.
I'd say that it depends. A good prod DBA shouldn't be busy putting out fires and should reduce emergency calls to become almost inexistent. However, that doesn't mean that there should be no work. New projects can come every day and if you already implemented 2014, then it means that the company is in constant improvement. Preventing fires from occurring might take longer in some companies than others.
So, it's not a direct accusation of not being a good DBA, but you might want to evaluate if it applies or not.
July 3, 2014 at 2:42 pm
Fine, Il bite. In my day to day work as a production DBA a typical day looked like:
-Reiew alerts in monitoring tool, and act upon any that may signal potential issues ( low disk space, unuaually low PLE, high mirroring latency etc etc). This is both preventative and firefighting.
-Work with Dev's on new projects to ensure query performance, proper environment configuration.
-Plan/Design DR & Backup strategies for Prod, Dev & UAT Environments.
-Review nightly backups to ensure all critical systems have been backed up by the 3rd party backup tool. If not, investigate what the issue is.
-Fires, e.g. report used to run in 1 min now running in 20 mins. fix it now, hardware failure, issues due to OS patching,
-testing failover
-Dev Ops work ( to speed up deployment and redeployment in Dev/UAT environments)
-Replication monitoring, troubleshooting, debugging.
the majority of that work is not firefighing. There are always issues that crop up, you fix, and prevent from occurring again. the vast majority of work is preventing these issues in the firstplace and staying ahead of potential problems. This all still means a busy day, without much firefighting.
July 3, 2014 at 4:33 pm
I know we're derailing this thread, but I'll respond to your final bit first:
the majority of that work is not firefighing. There are always issues that crop up, you fix, and prevent from occurring again. the vast majority of work is preventing these issues in the firstplace and staying ahead of potential problems. This all still means a busy day, without much firefighting.
Same plan then, but you're involved in the process earlier than the majority of DBAs I know. This comes down to your definition of a DBA. My current DBAs only look at code when it takes out the prod server due to concurrency issues which I simply can't troubleshoot. I've worked their side of the fence too though.
winston Smith (7/3/2014)
Fine, Il bite. In my day to day work as a production DBA a typical day looked like:-Reiew alerts in monitoring tool, and act upon any that may signal potential issues ( low disk space, unuaually low PLE, high mirroring latency etc etc). This is both preventative and firefighting.
-Fires, e.g. report used to run in 1 min now running in 20 mins. fix it now, hardware failure, issues due to OS patching,
-Plan/Design DR & Backup strategies for Prod, Dev & UAT Environments.
-Review nightly backups to ensure all critical systems have been backed up by the 3rd party backup tool. If not, investigate what the issue is.
-testing failover
-Replication monitoring, troubleshooting, debugging.
These I would say are typical DBA tasks. You've jumped ahead of firefighting and gone to monitoring and prevention. This, in response to what was said above, is how you've gone towards preventing the fires and 3 AM phone calls in the first place. Some of this might be automated, but yes, I (and I'm sure many others) agree this is good DBA practice. You're just now ahead of how a good DBA usually finds the smoldering cratered remains at a new location where they have to put things back together on arrival. :w00t:
-Work with Dev's on new projects to ensure query performance, proper environment configuration.
-Dev Ops work ( to speed up deployment and redeployment in Dev/UAT environments)
These are typically not part of a DBA's duties in larger corporations, as the auditing requirements have become more stratified due to a number of things. Not that it's a bad thing to do (lord knows I'm usually trying to get the bandwidth to do that when I admin) but the devs are typically on their own unless they have an environmental concern.
to the OP: I give 'em a month, usually, but I usually get the other end of the spectrum. They see my resume, and I'm being hired for 'filler' work. Some little 3 month cheapo contract to be a code monkey while I wait for the market to get out of a dead spot. Then they expect me to start architecting... at which point we renegotiate or I walk.
I will be ANYONE'S million dollar a year janitor. Just don't whine at me while I finish my crossword.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply