April 23, 2008 at 7:50 am
Hello,
I evolved into a DBA from a programmer a year ago. I've enjoyed my work as a DBA, but now my boss wants me to start doing some administration work, like looking after the accounts system, and a new content management system. I'm not 100% happy with this, because it's not what I signed up for, but my boss says it would the same in any other DBA job. Not having ever had another DBA job I don't know if I can counter his argument.
Could other DBAs let me know how much time they are expected to do non-DBA work?
Thanks
James
April 23, 2008 at 8:05 am
Hi
The reality of being a DBA in a small to medium sized company is that the company usually does not want to spend money on additional resources if they do not have to - hence DBA come system administrator.
The fact that a Database by itself is just a storage engine with data in it.
Systems run on databases - such as ERP, Payroll, HR and Sales.
If a company can get away with a DBA that doubles as a system administrator in some way it may just do that.
In my experience I too have been employed as a DBA - yet done code rollouts for our ERP system, Intranet systems and custom applications - because either:
* You are the only one in the department capable
* You are the only one who likes the technologies used and wants to help
* you are the only one that can
* it is cheaper to have one staff member do the work of 2 or 3
* the may not be enough work for a full-time administrator
I feel that it is very rare to only do pure DBA functions if your company is deemed to be small to medium and has a lot of varied systems that need looking after - but would not make sense to employ 1 person for each system.
Hope this info helps
Thanks
Kevin
April 23, 2008 at 8:29 am
Thanks, that does help quite a lot. I think that as they want me to carry out more duties, I'll demand more responsibilities in return. 🙂
April 23, 2008 at 8:42 am
It really depends on the shop. I've worked where I was the System Administrator, DBA and Developer. Now I work for a largish company where we have 14 DBA's. I still do work that stretches past the direct "manage the database and the SQL Server instance" type of role. The more you can do to make yourself valuable to the company as long as you're not seriously impacting core functionality and core responsibilities the better. ("Yeah, I couldn't get the new backup script in place because Peggy-Sue was having trouble logging into her laptop" probably wouldn't fly).
"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
April 23, 2008 at 10:47 am
Note: try to avoid a DBA job for a company that has an extreemly small SQL Server database that requires no maintenance or projects around the SQL Server. Let me explain:
If you are a DBA that wants to do very little and "loaf" then the above situation may be perfect for you, but...
If you want to learn and grow, by all means start at the small company with a 100MB SQL DB - but do not get stuck with a database that is never a problem and there are zero challenges.
When you as a DBA are ready for new challenges then set your sights on larger SQL Server environments, this way you will:
* gain more experience in SQL Server
* come across more problems to solve, encouraging you to learn
* potentially have performance issues to solve - again gaining experience
* learn how large systems work/don't work & behave on SQL Server
* learn what high transaction volume means and how this affects SQL systems
* are exposed to more users and user issues around security, rights and performance
* reporting off data usually is a normal requirement (sometimes from DB level)
* sometimes can afford the latest software and hardware
... I think you get the idea
I often feel sorry for DBA's who are still stuck on SQL 7.0 and running a 400MB database and have time to fool around playing games most of the day!
What type of DBA do you prefer to be?
Thanks
Kevin
April 23, 2008 at 1:53 pm
Thanks Kevin. I'm definitely the type of DBA that wants to learn and grow, but I'm stuck in the environment where the databases all behave themselves and none are larger than 2GB.
I think you've made up my mind about leaving, but I have another question:
When going for a job interview how do I know what type of environment I would be entering? I've thought about getting the employer to answer the following:
How many production databases on how many servers?
How many clusters?
Hits per day for each database
Required uptime for each database
Database versions
Does this sound sensible, and can anyone think of more questions that could be asked?
Thanks
April 24, 2008 at 1:00 am
There are a few things that you should do:
* Find out the company's name - do research on the company - also check the field the company is in
* Ask what systems they use (Microsoft, SAP, home-grown, ERP, CRM etc...)
* How many users (important)
* Branches - located in different cities? - how do they link and line speeds
* Change Control Process
* Development environment versus live - do they have 2 environments
* Size and number of Databases are important
* Do they have a SAN
* On the cluster - this is not usually the norm unless a med/large company
* Transations through the system rather than hits (we use orders as a counter)
* Uptime will always be 99.9% or should be - but ask when can there be downtime (after hours work question)
* Yes - version of SQL and edition and plans on next version (future projects for you)
* Type of DBA functions that are currently being done
* Size of team and each members role (you may get stuck as a report writer!)
* Current documentation in place
* Future system changes coming up (new ERP etc)
* Training opportunities (to keep your skills relevant and up to date)
* Backup for when you are on leave
* Ask a question about current stability and reliability of systems
* Maybe a question about the current hardware and OS
* Integration with other systems & what technologies are involved
There are many more - but once you are in the interview - you need to determine if the interview person is technical in nature - if not most of the above questions will not be answered correctly.
Maybe ask if you can call the technical person at the company and pose some of these questions, it is usually better to speak to someone who is in the environment doing the work.
All the best
Thanks
Kevin
April 25, 2008 at 5:54 pm
I like Kevin's advice, but most importantly, try to talk to the DBAs or whoever is working on the systems at the new company and find out what they do. Constant firefighting is not fun, but it's the best way to learn if you can handle the stress.
Stable environments make it hard to learn and you have to really dig in.
Personally, at this point, if you cut the check, I'll change printer paper if that's what you want. At small companies I liked being in charge of lots of systems and learning about different things.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply