October 24, 2012 at 6:22 pm
bugg (10/18/2012)
SQLRNNR (10/18/2012)
I've done the 24x7 oncall on my own. Even if they promise you the vacation and that so and so can cover that week - don't hold your breath.
It meant 70+hr weeks regularly (and 90 typically) and no vacations. Are you ready to work that much?
Okay, you guys are starting to scare the sh*te out of me :unsure: . Why are you DBA's willing to sacrifice so much of your "free" time, a 90 hour week ! Id leave in heartbeat after that, unless my palms were properly greased 😀
There is 1 database, so yes its mission critical this thing hums all year round.
Size of database: Don't know but will find out.
Backup/recovery plan: Principal Database is mirrored, as far as i know that's it!
on call 24/7 yes that's me. If i can't be contacted/reached they'll have to make a plan, end of, and when I'm on holiday I wont be reached especially where i normally take my holidays, backpacking through jungles or up some mountain.
They know I don't have any production DBA experience , and they don't have a DBA so they must be ticking along somehow without me.
Worst case scenario, its to hectic, I hand in my notice and leave.
Firstly, don't get put off by SQLRNNR's 90 hour weeks - he comes from New Zealand and works in the Mines of Moria. 😉
Like you, I hailed from a developer background before discovering I had a preference for database work, particularly set-based logic. Why do 100 laps for a Grand Prix when you can win it in 1? But there are reasons why you wouldn't work as a DBA:
- when you walk into a room no-one shouts "DBA on deck!" and everyone else drops whatever they're doing, stands to attention and salutes
- you won't get first pick of the choicest bit of office real estate
- you won't get presented with one of those giant cheques at the annual company party for your bonus
However there are some things I've found when taking on a role as a DBA when there wasn't a DBA before:
- backups not complete: databases missing from the backup plan (your server *does* have more than one database); backups are to local disks and/or tape backups are 'stored' on top of the server; databases are all Simple mode; transaction logs aren't backed up.... You *need* to get on top of backups and you *need* to practice restores. This isn't DBA 101, it's more like DBA 000.
- there's a "god" account - this is one login, often with sysadmin rights, that all the apps, services, staff use for everything. Often it's been around so long that half the staff which have already left the company still have the password. And you can never change the password, even if it's compromised, coz then goodness-knows what will start to fail.
- everyone else is an expert: mostly Network dudes who often feel that DBA's don't need access to the servers, or Developers (remember you're a DBA now) who want access to the Production databases. The latter are usually the most problematic, especially if they have the "god" account; the former are usually kindred spirits in that they want stable, dependable systems and just haven't realised you also want that. Both groups are cool guys, but if a Dev runs code that brings the production systems down it's you that'll get called and you may need access to the servers to fix it.
October 24, 2012 at 11:51 pm
Convince your management of paying for a "first - line support" - someone who works out of hrs - can pick up all the monitoring , deal with failed backups, work from documentation depending on nature of problem, storage management , basic housecleaning. That way , you can focus on data modelling,SQL query tuning, performance level monitoring, data management, user management, application level expertise - the more interesting , high value activities
Jack Vamvas
sqlserver-dba.com
October 25, 2012 at 2:41 am
Many thanks for all your comments they are much appreciated! This thread has been a wealth of knowledge for me. I have a lot to learn and although it feels daunting I am pretty excited about it. I'm sure ill be an active member on this forum asking loads of questions, hopefully someday I will be able to give back to this community.
October 25, 2012 at 9:22 pm
Fal (10/24/2012)
bugg (10/18/2012)
SQLRNNR (10/18/2012)
I've done the 24x7 oncall on my own. Even if they promise you the vacation and that so and so can cover that week - don't hold your breath.
It meant 70+hr weeks regularly (and 90 typically) and no vacations. Are you ready to work that much?
Okay, you guys are starting to scare the sh*te out of me :unsure: . Why are you DBA's willing to sacrifice so much of your "free" time, a 90 hour week ! Id leave in heartbeat after that, unless my palms were properly greased 😀
There is 1 database, so yes its mission critical this thing hums all year round.
Size of database: Don't know but will find out.
Backup/recovery plan: Principal Database is mirrored, as far as i know that's it!
on call 24/7 yes that's me. If i can't be contacted/reached they'll have to make a plan, end of, and when I'm on holiday I wont be reached especially where i normally take my holidays, backpacking through jungles or up some mountain.
They know I don't have any production DBA experience , and they don't have a DBA so they must be ticking along somehow without me.
Worst case scenario, its to hectic, I hand in my notice and leave.
Firstly, don't get put off by SQLRNNR's 90 hour weeks - he comes from New Zealand and works in the Mines of Moria. 😉
Ha, and if you do get put out by those kind of hours - it's ok. I didn't like it either and now don't do that anymore:-D
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 4 posts - 31 through 33 (of 33 total)
You must be logged in to reply to this topic. Login to reply