November 11, 2007 at 10:47 pm
I hope I am bringing a nice Topic for debate.
Recently, I read an article here about things to consider when moving up from junior DBA, to senior. But, basically the article was about skills one needed to know. Things like backup, restore, profiling, DBCC, etc
The motives for this Topic arose at the heart of a controversy in a small company I was visiting. Basically, they said that because many tasks can be done with the help of Wizards, and Jobs, and that the load of work was not high, they did not need a DBA.
When is a DBA neccesary?
So, I'd like this opportunity to ask for your routines. Tasks you experienced, and not so experiences DBAs, do every single day. And if possible amount of time spent.
For instance,
ROUTINE WORK
Monitoring disk space....................5 minutes per server
Monitoring backups.....................10 minutes per server
Reading/Sending emails to upper mgmt, whatever?
etc
-----------------------------------------------
Total daily routinary work...............15 hours
PROGRAMMING AND DESIGN
Total programming work................6 hours
By programming I mean sprocs and views, triggers, etc
So, how much time and how do you spend your time as DBA?
November 12, 2007 at 2:49 pm
In our company, we have developed an in-house software, which monitors and displays the status of many of the items you mentioned:
- Jobs good/failed
- Backup problems
- Disk space/problems
and sends emails in case of problems. I believe there are also many types of commercial tools which do that. So, as DBAs, we usually spend time fixing or avoiding problems rather than first identifying them [i.e. identification part is done automatically].
Also, you might have a DBA and a person responsible for writing sps/views ... These need not be one and the same (although could be). DBA would be responsible for more serious activities and generally the health of the whole database system.
November 12, 2007 at 4:25 pm
hi,
I know three kinds of DBA:
- DBA for who all things are going well, so he spend all his time learning, preparing himself for certifications.
- DBA who is doing 24*7 supports, this one (generally is production DBA) spends a lot of time in front of rough situations (Disk fail, corrupted database, rebuild master, recover backups, reinstalling computer and SQL server from scratch, making replication between #RDBMS, transfering logins, upgrading systems, profiling, data migration, schema upgrade, developping backup and disaster recovery strategies and more)
- DBA who just check stored procedures and functions developped by developpers and excute them on production.
It depends on the the definition for this position in each firm.
Regards
Ahmed
November 12, 2007 at 4:31 pm
From experience, I usually spent about half an hour checking servers. That was after spending hours building automated systems that could roll up disk space, errors, jobs, etc. into a report that we could go through and verify.
Now on most days, something was broken, so we spent time fixing it, which could be from minutes to hours. Plus there is the ever present routine of tasks people ask you to do.
I'd say we spent a few hours a week restoring databases as well to be sure that worked, for test, etc. There was also a constant stream of permission requests, object changes, etc.
November 13, 2007 at 4:35 am
The first 15-30 minutes of my day are checking the jobs, making sure all of them ran correctly. This determines how the rest of my day goes.
If jobs failed or we got a disk space alert during the night, I spend the next 30 minutes to several hours (depending on how simple the issue is) identifying the problem, resolving the problem and re-running the job. If all the jobs were successful, I check my email for additional alerts, delete all the emails and go on to the next thing.
As I am both a production and development DBA, the "next thing" could be anything from a quick data change / fix to a more complicated data fix to the development of an SSIS package or SProc. I also move code for the Developers between environments as part of the SDLC (software development life cycle) process.
Unfortunately, because we have so many projects under development, I rarely have time to do database tuning / optimization and often have to squeeze it in amongst the other things I'm doing. Usually when I have a five minute break. Our backups & restores (down to our Dev/Test/QC environments) are mostly automated, but I still have to check them every couple of days to make sure everything's still working smoothly.
Right now, most of my days are spent with upsizing a couple of access databases, creating a data warehouse and learning SSAS so I can build a cube for some reports that I'm converting from manual to automatic.
Breakdown: Maintenance 5% of my work week. Development 85% of my work week. Programmer / Business Unit support 10% of my work week.
I can understand why a company would think they don't need a DBA. After all, why pay for an expensive contractor (or full time employee) if nothing is broken, right?
I think it's rather short sighted. Programmers don't know everything about SQL Server administration and giving someone SysAdmin access when they don't understand the consequences of the things they do is a *BAD* thing in any company. And when things break, it's often too late to apply preventive measures.
DBAs do things most people don't think of. Prevention is half our job. And by doing our jobs, we notice when things are going wrong well before something actually breaks. And we can fix it before anyone ever knows there was a problem. But this isn't what officers and managers and end users see. They only see problems when it brings down the system or corrupts their data. If things are going smoothly, they assume we're just sitting on our duffs and playing video games.
It's a shame, really, that there are companies out there with databases that assume as long as everything is working, they don't need a DBA. But you can rarely change their mind, unless you offer them other value while you're working for them. And at some point, that "other value" will take over your job description and you'll stop being able to do DBA work and the company is in the same boat it was before...
November 14, 2007 at 9:26 am
Brandie's job sounds like mine, sans the Access database upsizing [which I think would would enjoy].
We're upsizing our production sql servers to sql 2005 during this fiscal year, so add in pre-op and post-op for each server and the apps and extensive data integrations.
Our data warehouse was developed by a former staff member. I always pictured him as PigPen from Peanuts, but with chaos swirling madly about, instead of dust.
Looking at his work is like cracking open an attic owned by a serial data killer. Heaps of data dust. The horror!
November 15, 2007 at 10:46 pm
Thanks for your responses.
Thanks Steve Jones...so, it would be somewhat accurate to say, you spend about an hour. You said half hour. But lets include you send a couple of emails regarding any trouble, or writing down for another day.
Then, Brandie and Leslieo, if I was to say 5% Maintenance, that is mostly what I am thinking of, a 40 hours week (hardly hehe), then we get ...2 hours...coud it be 30 minutes daily (like Steve) ?
Then Bouzamondo, I would say let's check the DBA who is doing 24*7 supports, the others are not as important for this Topic.
Could we agree that a DBA, even for a small company, is a must for at least a 5 hour a week contract? Or should it be 10 hour? Even if that company only runs Wizards...because of the routinary stuff that those Wizards in MS SQL can't do.
So, the question could be now, how much time everyday of rutinary jobs would justify the hiring of a DBA?
Maybe our calculations should be broken down by amount of time per server. Maybe we could arrive, from experience, to a conclusion like 'if you have one ms sql then you should spend at least X amount of time daily checking this and that, if you have two, then..."
Thanks for your participation.
November 16, 2007 at 4:04 am
Xintanaka,
It sounds to me like you're trying to justify to this small company why they should hire you, correct?
In that case, don't take impersonal data and usethat as a justification. It'll never convince them. Make a list of all the things the company does right now and how they do it. What is their core business and how do they get that business into the database? How do they currently do maintenance and everything else?
Then make a list of the things they should be doing to maintain their servers. Items maybe they haven't thought of. Write up the consequences (in English, not technobabble) of what will happen if they don't do "X". Write up ways YOU can make their life easier. Yes, they use wizards, but wizards don't do everything. Besides, sometimes a wizard is not the best way to go. List some examples of value you can bring to them (make sure to attach a monetary amount to this value) by being their DBA (even if it's only part time).
Don't give them exact details on every single little task, because they might just take that information and pass it off to someone internal instead of hiring a DBA for it. Then you've just "consulted" for nothing.
Still, don't be pushy. If they don't want a DBA, even part time, they're not going to bite no matter what you do.
In that case, you can set yourself up as a On-Call-As-Needed DBA for this company, but if you're looking for a job because you're out of work, don't waste a lot of effort on this opportunity that isn't there. Look some place else.
There are a lot of companies in this world looking for a decent DBA. Try one of them. It's a lot less stressful then making the workers at this tiny shop resent you for trying to force your way in.
November 16, 2007 at 1:19 pm
Brandie Tarvin (11/16/2007)
Xintanaka,It sounds to me like you're trying to justify to this small company why they should hire you, correct?
Trying to justify a DBA. I am a developer. We are growing a team of 4 developers to about 12 in staff and a few more outsource. In total, around 20 developers.
I work mostly as software architecture. But, I have noticed many new developers embed their sql statements in their java, c# and php (specially this group and somewhat those java coders).
I am pushing for a full time DBA to administer and begin to set standards (like writing sprocs instead of those ugly ad-hoc queries)
Company has two productions MS SQL Servers, one Staging Server, and each developer have a copy of the DB they will be working in their development environment.
The thing is, besides lack of using good DB development and design practices, it seems like developers are messing things up when changing Production stuff.
So, as you can see we are in need of a hibrid DBA for Development and Design, but also for Administration. This DBA will manage Production DBs and those DBs in developers PCs (or servers), too.
I am expecting a lot of routinary tasks and have to come up with some number of hours for that. Of course, development hours are another story, no easy way to measure them.
November 16, 2007 at 2:10 pm
Then take what I said and reverse engineer it a little. Since you're already inside, you know what the weaknesses in the system are. Start documenting them.
One of the things you'll want to mention is how having a DBA Developer will prevent a Developer who doesn't know much about SQL Server from accidently taking the server down when he/she is trying to correct a SQL problem. Also, can any of the Dev group actually restore the server in case of emergency?
Document how much time it takes you and the team to recover from errors made in code or DOS attacks (due to SQL being in the code) or someone setting something wrong on the server. Also, how much time per week each developer spends out of his programming time doing SQL-only related tasks. Add that all up. I bet it comes up to a bigger number than you expect.
Lastly, document the dollar amount attached to all this wasted time. Hiring a DBA to manage it up front might be cheaper than letting the developers handle the issue.
November 16, 2007 at 8:58 pm
Andy Leonard (SQL Server MVP) and I have blogged about this... a lot. If you go back through the archives of either of our blogs, you should find the cross posts where we discuss the reasons that as you grow you need a DBA. Add this to what Brandie has posted and hopefully you have enough ammunition to justify the DBA position. However, if management isn't interested in increasing head count, you can have all the proof in the world and it will matter not.
K. Brian Kelley
@kbriankelley
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply