May 21, 2009 at 9:03 am
What's a DBA? I think that's another editorial, but I do believe there are pretty good definitions for someone that functions in that role. They administer the database. They might also write code, model, architect, but they care for the database. What's a programmer? That's just as generic. The problem, I think, is that working on a database does things that are somewhere hard to see and understand.
Only big changes tend to show up, or big failures, to justify jobs. Other than that, you need to be sure that you are showing management what value you bring. If you don't, that's your fault. If they don't want to hear about it, you need to move on.
May 21, 2009 at 9:10 am
Andy Warren (5/21/2009)
- Not everyone can afford a DBA, whether we think they should or not
I agree. Not everyone needs a DBA. I wish there were a better way to match up people and jobs since I think many companies would benefit from a part time DBA. A person that works 2 days a week, draws 2/5 a DBA salary (maybe slightly more) and is there for things that are needed.
I was about to try this with one of my companies. I didn't think they needed me full time and I was taking on other duties to keep busy, some development, some sysadmin stuff, but really I'd have rather been paid less, and just done that job.
Remote DBA services are out there, but I think they tend to be a bit overpriced now. If we could find a way to match people to jobs better, I think this is a good solution.
you can get a DBA that does other work, but I think it's hard to balance that. The person ends up doing too much of one job or the other, and neglecting one side.
May 21, 2009 at 9:19 am
Andy Warren (5/21/2009)
- There is logic and value in buying a little more hardware than you need, especially if the problem goes away
Absolutely. We did the calculation one time when faced with a tuning issue. We had spent a few days trying to tune something, and we thought we had an idea of what was wrong. However we weren't sure. And with the time we'd spent going through things, and the time we estimated (which is almost always low) to fix, we could easily have purchased a much larger DB server and a couple more web servers to spread the load.
I think that it pays to tune code to a point, though I'm not sure how you figure that out. But with what you pay people, and if you have other work to do, especially work that can potentially allow for scale out, I think it pays to buy hardware.
The issue is that you can go too crazy with this. When I arrived at JD Edwards, we literally had over a thousand Windows servers. Of those, we had SQL Server (standard or enterprise) on about 300 servers. We didn't need all those servers and I consolidated a hundred instances down by combining databases onto other servers.
You need to balance your hardware with load better. If something has a load and needs more, I think you throw hardware at it, but if it's overbuilt, you might need to take some away.
May 21, 2009 at 9:54 am
Steve Jones - Editor (5/21/2009)
Andy Warren (5/21/2009)
- There is logic and value in buying a little more hardware than you need, especially if the problem goes awayAbsolutely. We did the calculation one time when faced with a tuning issue. We had spent a few days trying to tune something, and we thought we had an idea of what was wrong. However we weren't sure. And with the time we'd spent going through things, and the time we estimated (which is almost always low) to fix, we could easily have purchased a much larger DB server and a couple more web servers to spread the load.
I think that it pays to tune code to a point, though I'm not sure how you figure that out. But with what you pay people, and if you have other work to do, especially work that can potentially allow for scale out, I think it pays to buy hardware.
The issue is that you can go too crazy with this. When I arrived at JD Edwards, we literally had over a thousand Windows servers. Of those, we had SQL Server (standard or enterprise) on about 300 servers. We didn't need all those servers and I consolidated a hundred instances down by combining databases onto other servers.
You need to balance your hardware with load better. If something has a load and needs more, I think you throw hardware at it, but if it's overbuilt, you might need to take some away.
If you can adopt general best practice guidelines, from BOL, Microsoft whitepapers, and general education on blogs and sites like this, nine times out of ten, you'll have "tuned" your database to an optimal enough point before the law of diminishing returns takes over. After that, the next step is better hardware.
If you have some horrible RBAR code going on for example, a faster processor or more ram may only give you marginal improvement. But optimize the database from the beginning, and you won't upset your managers who spent the extra money on a system but no significant improvement in SQL Server performance is detected.
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
May 21, 2009 at 9:57 am
In our DBA unit, we have three dedicated SQL Server DBAs. Our employer has invested in tools to help with monitoring performance and these tools have provided critical information for resolving problems a number of times. First they keep a repository to show what normal looks like and alert us to something out of bounds. We are also able to go back in time and see what was happening if users report that they had a problem in the past. When new features are implemented in production and performance goes south, they will pin point for us the code that is causing the issue. We can relay this to the development team and this allows them to provide a solution to their business unit customers in a more timely fashion. The dollars that are spent on the tools has paid us back many times over in providing improved customer service. There have been many times during our routine monitoring that we have been able to identify code issues and bring them to the developers. Users had been just living with these issues and were appreciative of the improvements resulting in a more positive image for the IT group. So to answer the original question as to whether there is value in spending money for monitoring and performance tools: in our shop it has definitely been worthwhile.
May 21, 2009 at 12:54 pm
I was a developer who turned DBA by accident 14 years ago (my boss had a drink too many and dropped a critical database and was fired) and have been a DBA since. I strongly believe most companies, small medium or large need someone doing DBA duties if not a full time DBA. Throwing strong hardware or software at a problem is very common even in large places having DBA teams but it only masks the problem does not resolve it. If a company wants to work like that on a continues basis (mask their problems instead of resolve) - it is not limited to hardware or software. If you have problems with people get rid of them. If you have problems with customer try to take the guy there to lunch or do something similar. It is a general mindset more often than not. I have learnt one thing the hard way - dont' work anywhere where there is no commitment to excellence to some degree atleast. Do people care about doing things right? Things can be done any way or not done at all but if they dont' care about excellence it is extremely rare a person doing DBA work will be happy. DBA work is all about getting recognized for keeping systems up pro actively and maintaining trust. Thanks Steve for letting me ramble :))
May 21, 2009 at 7:12 pm
Interesting to see the wide range of DBA skill levels described. Reminds me of that week of "Cloud Computing" editorials Steve posted not too long ago.
It's not too hard to see why many companies, especially smaller ones, take the opportunity to outsource their DBA and other IT functions to cloud computing companies, where (presumably) the DBAs are full-time, highly trained, and totally focused on being a DBA. At least one would think they would be since their entire business model, reputation, and success depends on reliable systems.
Or to put it another way, if one of these cloud/SaaS companies "has a problem", then they REALLY have a problem.
May 21, 2009 at 8:23 pm
Gaby Abed (5/21/2009)
If you have some horrible RBAR code going on for example, a faster processor or more ram may only give you marginal improvement. But optimize the database from the beginning, and you won't upset your managers who spent the extra money on a system but no significant improvement in SQL Server performance is detected.
Absolutely spot on, Gaby. And I'll throw in that people in the front offices only think about what they can see, the GUI. They don't understand that there's the bright flashy world of a GUI driven interface with the data base and a much more demanding set of backend processes that are most frequently driven by massive, complicated batch processes.
Like many companies, we had both at my previous company. No one cared that things like the General Ledger and Billing runs that had to be executed every single day were creeping up on the 24 hour mark until the GUI slowed down in response times. They upgraded from Standard Edition to the Enterprise Edition and went from a 4 CPU toy to an 8 CPU fire breathing monster with an all new SAN and a garden hose to supply enough water to keep it all cool enough to run.
It didn't help because of the horrible way the code was written. Sure, some of the batch jobs speeded up a bit, but they went right back into the same performance toilet after only 4 weeks when the new "tipping point" was hit and the GUI performance went with it.
I'm amazed at the casual attitude some companies have about their life blood... data. No money spent on backups or temporarily hiring a consultant for a health check if they don't have their own real DBA, but they have that nice new server and some really nice GUI's. In the vein of "if it's not broke, don't fix it", at least change the bloody oil and check the tires once in a while. 😀
I'd have to say that the answer to "Do you have a problem" is... only if you don't think so. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2009 at 12:58 am
Too often we find people acting as a DBA, even having that title, without the experience to really understand if they have a problem. They don't have monitoring, they don't proactively look for problems. They are in many cases just hoping that everything functions as it should, and that they won't encounter any issues that upset the balance of their daily workload.
You're right Steve, and that is me. I am a developer and one day I was thrown in the deep end and told: "There is your server, your database and what else you need. Carry on!" I learnt a lot and actually started making check lists to check the database on a daily basis and one day I thought to myself: "Wow, I am a DBA now!" until I came smack down on my face and realised that I still had a lot to learn. You guys should know from my posts that I am a great pro-developer, anti-arrogant-DBA person but I have to give it to the DBA's that they have a tough job. Our company (actually the client's) are just not big enough to warrant a DBA as well as a developer but what they should do is dish out some training and the developers can just as well be DBAs.
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
May 22, 2009 at 1:08 am
My thoughts are with the proper training you can get excellent DBAs.In my case I'm from Africa I started using SQL server last year and i have learned a lot but,I still need the training to be come a good DBA.The SQL server courses in Africa are expensive and slow down one's progress in this field.:-)
May 22, 2009 at 3:24 am
dlozi (5/22/2009)
In my case I'm from Africa I started using SQL server last year and i have learned a lot but,I still need the training to be come a good DBA.
Whereabouts in Africa?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 22, 2009 at 4:14 am
I'm from South Africa(Johannesburg):-)
May 22, 2009 at 4:18 am
South Africa (johannesburg).
May 22, 2009 at 7:09 am
Manie, I am in the same boat with you. I am a SQL Developer pushing to be a DBA since no company is willing to hire a 'real' SQL Server DBA. As one of my former boss pointed out: 'SQL Server is too easy, you don't need to hire a DBA to manage it'. That is not true. However it happened in the last 3 companies where I worked.
By all mean, I don't want to be a DBA, I want to be a developer.
May 22, 2009 at 10:53 am
Loner (5/22/2009)
Manie, I am in the same boat with you. I am a SQL Developer pushing to be a DBA since no company is willing to hire a 'real' SQL Server DBA. As one of my former boss pointed out: 'SQL Server is too easy, you don't need to hire a DBA to manage it'. That is not true. However it happened in the last 3 companies where I worked.By all mean, I don't want to be a DBA, I want to be a developer.
You know, at one stage I wanted to be a DBA with a passion but that has changed. I am a developer at heart and nothing gives me more pleasure than to see a system that I developed or helped to develop run at a client.
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply