|
|
|
SSC Eights!
 
Group: General Forum Members
Last Login: Tuesday, February 16, 2010 7:42 AM
Points: 834,
Visits: 848
|
|
This reminds me of an infamous quote from current Cleveland mayor Frank Jackson:
"The problem is we have a problem. It's not that we don't know we have a problem, we've known it for years. It's not that we don't know what the solutions are, we've known those for years. The problem is we haven't done anything about it." 
Seriously though, I suppose the situation really depends on what type of system it is, and who the target audience is. A small internal system like the 4 user scenario described in the editorial could very easily be run on a single small server or virtual server setup, and with limmited planned maintenance could run fine for years. A larger system or a system intended to be used by external people, customers, clients, or partners faces a whole different level of expectations and needs.
An example of this where I currently work, we implement and host systems for external clients. Our production DBA has been doing alot of training on the job, and I've tried to help guide that both directly and indirectly. However, I still have problems trying to get across the importance of having failover capacity for the database. He keeps talking about plans to build a cluster, but they've been planning for a year and still no cluster exists, mostly now because of budget. So multiple times I've tried to discuss alternate means of failover capabilities, but he always has an excuse as to why we can't do it. I just hope we get something in place before we have a major problem and potentially loose a client because it took too long to get them back up and running.
|
|
|
|
|
SSCertifiable
Group: Moderators
Last Login: Thursday, March 11, 2010 10:33 AM
Points: 6,371,
Visits: 950
|
|
Steve, though this isn't perhaps a perfect reply to your post, my views are:
- Not everyone can afford a DBA, whether we think they should or not
- There is logic and value in buying a little more hardware than you need, especially if the problem goes away
- Buying excess hardware 'just in case' ties up valuable liquidity (capex) that the business could use better in other places
- We should encourage and teach anyone that will listen, but they have to be ready to hear the message
Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter
|
|
|
|
|
SSC Rookie
Group: General Forum Members
Last Login: Thursday, September 24, 2009 7:38 AM
Points: 33,
Visits: 88
|
|
jcrawf02 (5/21/2009)
Wow. Wag the Dog, anyone? Should our Army/Navy/Marines just let someone come take over the country, so that we value their services more?
Our Congress already does this. But you're correct, leadership within the Department of Energy is severly lacking. It's wonderful working for a real company now, where performance actually matters. (No kidding, it's extremely difficult to fire an exempt employee because it can't easily be demonstrated that performance failures of individuals has any impact on the performance of a government facility.) In the end, I'm sure he's much better off for having left -- for a multitude of reasons.
As for documentation, at a federal nuclear materials enrichment facility, you don't fart without filling out paperwork. He certainly did document, and in each annual review, he tried his damnest to explain why he spent so much time performing premptive scripting and what exactly that meant.
But who cares about all those fancy-shmancy scripts for a system that never shuts down? I'm not saying I condone allowing it to fail, I'm just pointing out the problem of working a technical job in an environment where no one understands what you do. And it's not that it wasn't a technical facility, there are a higher concentration of engineering employees there than in most industries.
Of course the fact that management referred to these control-system computers were referred to as "those damn ataries" by management spoke volumns. The tools for measuring his performance just don't exist, even to this day as technical jobs become ever more specialized, it's difficult to find acceptance of performance measures for invisible performance results.
Not to beat a dead horse, but this actually is a problem today between our soldiers and the mercenaries working along side them. Our soldiers work for almost food-stamp wages, while the guy standing next to them is getting paid outrages mercenary fees, and doesn't have to put up with nearly as much crap. So, if that soldier were only looking out for his best interests, he probably would allow things to fail. Of course, if he's politically minded, not in an obvious way, but in such a way as to allow minor failures to provide indication of just how overwhelmed he really is. They don't perform because they're valued, they don't succeed because their middle management (Congress) provides good leadership, but in spite of it. They do it because they have integrity, not because it's the best career choice.
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Tuesday, November 17, 2009 10:48 AM
Points: 6,
Visits: 38
|
|
I think that DBAs and database developers absolutely need to know their business --- not just well enough to keep our jobs, but well enough to be proactive as well. In the average enterprise, a large body of SQL code (well written or not) may survive thru multiple backend upgrades --- even across RDBMS platform changes --- while application frontends are revised, rewritten with new tools, or even completely replaced.
This longterm survivability of SQL code makes it more important than ever that we write it to be as effective, efficient, and durable as possible. This in turn requires a level of knowledge (and interest) that goes beyond simple competence.
I don't expect everyone to agree with me. Many DBAs function more as operations people, instead of development people, and may feel that their primary job function is to prevent/remedy failures. And many developers are frontend applications people, whose SQL knowledge is adequate to produce the correct result, but stops there.
I'd be interested to hear other opinions on this!
|
|
|
|
|
Valued Member
Group: General Forum Members
Last Login: Friday, October 02, 2009 6:43 AM
Points: 57,
Visits: 151
|
|
OK, during my god awful number of years in IT, I have never held the title of DBA. I have done a lot of tasks typical of a DBA, and lot that aren't.
In my current postion I have been forced to learn as much as I can about SQL server from the DBA perspective.
Why?
Because our ERP software has really flaky stuff happen. Seriously flaky stuff that cannot be explained by going through the ERP code.
What have I found? We have a company policy of not installing patches unless forced to by users, and then only the specific patch that is supposed to fix the problem. Another policy that says we won't ask our third party custom software coders whether a patch affects there code.
The question I have is "Why did our DBAs implement these policies?"
I think I know the answer based on all your posts. The answer is "Either they didn't know what they were doing, or didn't care."
Now, the rest of my questions...
Is there a certification for DBAs?
If so, is the testing process kept up to date? (Years ago I almost went for CDPM certification until I found out half the test was on setting up card sorters.)
Who decides the curriculum and testing content?
And, if there isn't a certification, what are/can you, as professional DBAs do about it?
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: 2 days ago @ 8:26 PM
Points: 23,166,
Visits: 6,925
|
|
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.
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: 2 days ago @ 8:26 PM
Points: 23,166,
Visits: 6,925
|
|
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.
|
|
|
|
|
SSChampion
Group: Administrators
Last Login: 2 days ago @ 8:26 PM
Points: 23,166,
Visits: 6,925
|
|
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.
|
|
|
|
|
SSChasing Mays
Group: General Forum Members
Last Login: 2 days ago @ 8:45 AM
Points: 644,
Visits: 1,258
|
|
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 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.
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
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: 2 days ago @ 9:04 AM
Points: 14,
Visits: 431
|
|
| 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.
|
|
|
|
