October 1, 2009 at 8:57 pm
Comments posted to this topic are about the item The Incidental DBA
October 2, 2009 at 5:11 am
If the second person wasn't interested, what was the guy doing at a user's conference? I would suspect that he was interested, just presenting a diverging viewpoint, playing devil's advocate I guess.
Your analogy to driving a car is good. How about, we all use computers, but if the X starts happening, I'm not a computer engineer (though that's what college tried to do), so I cant tell you that there's a feed back loop due to some quirky property of Kirchhoff's law. (Or any of the other's that I've forgotten.)
I guess this also can be applied to the idea that some business's are using SQL7 (hell 6.5), and are quite happy with it.
Honor Super Omnia-
Jason Miller
October 2, 2009 at 7:24 am
Great editorial today Andy. I think you presented a point of view that serves to help our fellow
DBA's understand clients and their decisions to use SQL Server when they appear to have no interst in administering or maintaining their installation.
Not everyone has a choice in RDBMS products, sometimes it is vendor driven for their line of business software or website.
October 2, 2009 at 7:52 am
It's the same point I've been making for over a decade, that most people don't need the latest and greatest in high-power computers. I know lots of people for whom a netbook is all the computer they need for what they want to do. Take that concept into the land of databases, and you get this article.
Overkill is overkill. It has a cost, but no return.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 2, 2009 at 7:57 am
Jason, the person at the meeting was a developer and my take was that he had a real interest in learning things that would help him at work, didn't feel like arguing for the sake of arguing.
October 2, 2009 at 8:36 am
I agree with both Andy and GSquared. A good article, but "incidental dbas" can provide an opportunity for those of us that may want to undertake a bit of overtime work, possibly as a consultant to this inci-dba to help them. Providing a "leg up" for anyone who has questions is part of being a good dba in your own right. I wish I had time to learn more about VB .NET and even web data base processing, but who has the time? I go to someone who knows and that is basically what this individual did at the conference when they commented on the discussion. {From an earlier article, this is where previous networking with your peers comes in handy....}
October 2, 2009 at 10:19 am
I think the way Microsoft has positioned SQL Server in the market place has a lot to do with this. The idea is to make a full featured database that is easy to manage or manages itself.
There are things they could do for the “incidental DBAs” to make life easier. Why not have a “New Database Wizard” that creates database with best practices for the user who knows almost nothing? Pick the best drive to put the database on, configure the best recovery level, setup a complete set of backups, setup re-indexing or defrag jobs, integrity checks, set the db file growth to a reasonable amount, set the db to read_committed_snapshot, grant user access, etc.
A ‘SQL Server for incidental DBAs Installation Wizard” would also be good: pick the best default drive locations, configure tempdb to a reasonable size, setup Database Mail, setup the SQL Agent, configure Agent Operators, setup agent jobs to have default notifications on failure, setup system DB backups, setup user logins, etc. A streamlined set of “SQL Server Books online for incidental DBAs” documentation would also be good.
That would go a long ways towards eliminating many of the common problems that we see people posting all the time:
“My database file is 1 GB, but my transaction log file is 200 GB. What do I do?”
“I deleted my database and I don’t have a backup. How do I recover it?”
October 2, 2009 at 12:29 pm
I started as an incidental DBA, we used SQL 2000 for MS Dynamics and just left things alone. Now I've become the accidental DBA responsible for 3 instances as well as network, web design, help desk, etc. Sometimes you just have to take things slowly, especially at a not-for-profit company. Not everyone needs all the bells and whistles.
I've moved our databases to SQL 2008 and am doing my best to learn it.
Also I'll be going to PASS Summit in November and hope to see some of you there!
October 2, 2009 at 1:06 pm
Michael Valentine Jones (10/2/2009)
I think the way Microsoft has positioned SQL Server in the market place has a lot to do with this. The idea is to make a full featured database that is easy to manage or manages itself.There are things they could do for the “incidental DBAs” to make life easier. Why not have a “New Database Wizard” that creates database with best practices for the user who knows almost nothing? Pick the best drive to put the database on, configure the best recovery level, setup a complete set of backups, setup re-indexing or defrag jobs, integrity checks, set the db file growth to a reasonable amount, set the db to read_committed_snapshot, grant user access, etc.
A ‘SQL Server for incidental DBAs Installation Wizard” would also be good: pick the best default drive locations, configure tempdb to a reasonable size, setup Database Mail, setup the SQL Agent, configure Agent Operators, setup agent jobs to have default notifications on failure, setup system DB backups, setup user logins, etc. A streamlined set of “SQL Server Books online for incidental DBAs” documentation would also be good.
That would go a long ways towards eliminating many of the common problems that we see people posting all the time:
“My database file is 1 GB, but my transaction log file is 200 GB. What do I do?”
“I deleted my database and I don’t have a backup. How do I recover it?”
The problem with that is "define 'best'". Even with experienced devs who have SQL experience, when I start asking questions like, "how big will the database be when it goes live?" and "how much do you expect it to grow in the first six months?", I usually get answers like, "you're the DBA, you figure it out". Without data on expected use-volume, it's just as impossible for them as it is for me. So, without knowing how big the database will be, or how many transactions per day/hour/minute/second/whatever to expect, how do you pick the best size for the data and log files? Without that data, how do you pick "the best" drive? How do you know how big and how frequent the backups will need to be?
I would love to be able to know that kind of thing when the database is first created, but I honestly don't think it's something that can be automated very well. Too much of it requires ongoing review after inception.
However, you have given me an idea for an article or whatever. "Checklist for creating a database" or something like that. I have policies on the subject, might be worthwhile to publish them.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 2, 2009 at 2:27 pm
In terms of incidental DBA, I would define best practices in terms of what is least likely to let them shoot themselves in the foot and most likely to have happy users. Call it a "fail-safe" installation.
It doesn’t have to be perfect, just a solid installation that is likely to run well without much in the way of intervention for most applications that are not managed by very knowledgeable users. I think good defaults for the items I mentioned would go a long way towards this. Obviously, the details can be argued, but I think we could have better defaults for tempdb than 8 MB data, 1 MB log with 10% growth.
As far as items like "how big will the database be when it goes live?" and "how much do you expect it to grow in the first six months?", they probably don't know the answer, so why not just set the DB with a reasonable initial size and set the DB files to autogrow by reasonable amounts? That probably won't get them in too much trouble. And based on the recovery model, just setup a reasonable backup maintenance plan that won't get them in too much trouble.
I also have an installation checklist that I follow, but it would be nice if all these items were asked by the installation dialog boxes, or at there was at least an optional detailed installation dialog for a simple one server default instance installation.
Put in another context, an expert mechanic might be able to tune a car for maximum performance, but it would be nice if the average driver could manage to commute to work without knowing what a spark plug was. “Just put gas in here and take it to the dealer for maintenance once in a while.” :satisfied:
October 2, 2009 at 2:50 pm
Michael, I agree with most of that. I think MS would be smart to add one step to the install where they prompt the person installing to activate a default maintenance plan. Experienced DBA's might even find it useful, but just having a backup/dbcc/rebuild on a regular basis would make life a lot better for many incidental users.
October 2, 2009 at 4:20 pm
Haven't read thru all previous replies yet, but here's my take:
1. Everything was installed and configured properly, database design and layout was optimized for business unit's needs and to prevent an 'incidental' (read unauthorized) DBA from causing a work stopage after asking "What's this button thingy do?", defrags were scheduled to run on off hours.
2. The database was small with few tables.
3. The database had no indexes.
4. He was running Pervasive SQL and was never told it wasn't MS SQL.
October 3, 2009 at 11:22 am
To continue the car analogy... one should at least know which side of the road to drive on and maybe how to put the car in "drive".
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2009 at 12:07 pm
However, you have given me an idea for an article or whatever. "Checklist for creating a database" or something like that. I have policies on the subject, might be worthwhile to publish them.
- GSquared
Hope your article would highlight or explain how the incidental DBA could create what you recommend in the Model DB. Then how to use SSMS, right click on Databases and all they would have to do then is supply the database name, logical name, log file name.
Heck Jeff might even agree to have you show them his Tally table scripts and you could include those in the Model.
It might give them the head start they need.
October 3, 2009 at 1:49 pm
To the point of this article, incidental DBA's probably wouldn't use a Tally table even if they knew what it was. The only thing most IDBA's are likely using the DB for is just a place to store data "incidental" data.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply