June 8, 2011 at 9:20 pm
Comments posted to this topic are about the item SQL Safety Nets
June 8, 2011 at 11:35 pm
"Or do you think that SQL should remain in the hands of only those who know what needs to be done and how to do it?"
Installing and configuring SQL Server is a royal PITA. I wish it was simpler and automatic.
June 9, 2011 at 12:40 am
Getting a basic install of SQL Server is still pretty much a no-brainer. This should still account for the small, low transaction volume databases (and a large number of 3rd party application databases that still come without referential integrity built in) without needing any additiona maintenance.
The Maintenance Plans can take care of any basic maintenance needs (assuming that the installer has read some part of BOL).
All of this is without adding any extra bells and whistles ........ and I don't really think that adding more options would add value at this level.
However, should a novice be installing, configuring and maintaining your mission-critical high-performance SQL Server system? Well, I know what my answer would be to that. In this case I am going to get an expert in to make sure that the correct boxes are ticked and the maintenance set accordingly and the last possible performance gain tweaked, and I sure as hell don't expect to see them running through a wizard clicking Next all the time.
June 9, 2011 at 2:03 am
I think given the number of self-confessed 'accidental DBAs' I have come across on here, the more safety nets, the better. That's not to imply they necessarily need them but not everyone jumps into SQL Server with much, or any, experience and not everyone only wears the DBA hat. I think it's more a case that the more SQL Server can do for you to save you having to spend a week fixing it again or having to explain to your boss why all the data is gone when really, you don't know too much about it anyway, is a really good thing and it should be encouraged, with the ability as stated in the editorial that it can be turned off or amended if need be
June 9, 2011 at 3:44 am
I'm one of those people who have to be able to set up & configure SQL as an incidental part of my "real job", and personally I'm all for safety nets. However ...
The issue isn't really being able to access any specific toggle option, but of having the knowledge to be able to judge when to use it. I find it realitively easy to research different "options", but rarely does that research give a clear and unambiguous answer at to what choices should be made in any specific situation. This type of judgement only comes with experience. I think anyone who doesn't do SQL DBA as his or her main occupation should rather call in more experienced help for anything other than a sandbox installation.
June 9, 2011 at 7:04 am
I started as an accidental DBA on MSSQL about 8 years ago, and I made a lot of the classic mistakes surrounding maintenance. Some of my mistakes led to time and data loss, easily prevented with an educated backup plan. I knew how to properly maintain Access and Foxpro, filesystems, and worked in the IT world, but didn't know MSSQL's particular way of doing things. It would have been ideal for me to go in with training, but the company at the time expected everything with zero investment (not even books). For 5 years I was "That SQL boy" and learned at my own pace, on my own dime ... nickle, really.
All that said, I think safety nets are good for business, good for the product image, but should not always be defaulted on. The installer shouldn't have to ask 20 questions to determine if this is a personal install or mission-critical cluster, but if it can offer a maintenance setup page with very few defaults enabled, that would help the novices.
It's common for someone without experience to run out of space on the backup drive and have transaction logs fill up, or worse yet not have a backup in the first place. OK, maybe the worst is backing up to the data drive.
Back in the Windows 3.1 days we had printed manuals to flip through, with basic starting instructions. Software was easier back then because computers didn't do as much. I forget - does the SQL08 installer have any form of "Welcome to SQL, here are your first steps" documentation readily available? Is that even necessary or am I dumbing it down too far?
June 9, 2011 at 7:09 am
Hmmm tricky one. Do I want enhancements made to the product that could potentially do me out of a job/career, but that could be of real benefit in the wider world? I doubt it would ever come to the stage where DBA's are no longer needed because the solution "thinks for and manages itself", but perhaps for smaller businesses such features could be a real lifesaver (you mention backups - although I suspect someone is going to have to learn how to do restores).
In that respect I think such things are a good addition to an already excellent product, but that you still require that personal expertise that takes the product on to the next level.
June 9, 2011 at 7:25 am
Right, it's never good to keep a career or industry dependent on someone else not learning the basic secrets. When being a DBA becomes an art form, that's when the best people shine.
And I forgot about restores - that's the other #1 biggest problem with newbies. I once ran into a basic restore problem: 200G free disk and the restore needed 300 (50 data, 250 log - never truncated). Nobody thought to test the restore before someone dropped a table.
Part of the question I have is who is the target market for MSSQL ? Novice users or experts? People coming from Foxpro/Access or Oracle? (I'd suggest Teradata if I knew anything more than its name)
June 9, 2011 at 7:41 am
I think it would be hard to add some of this stuff and do it well. How do you know where to back the data up to? If you default to the data drive there's a chance you'll take the DB down because you run out of space. Some other stuff, like defaulting an integrity check, is probably a good idea since there's less configuring with that one. Making SQL easier to use is a good thing since it'll mean we have better setups out there in general but playing to the lowest common denominator can backfire if you're alienating more advanced users and making them rip out configuration after an install because it's not the way they want it. Maybe the best thing would be a single checkbox in the install asking if you want SQL to help you configure a maintenance job and then if you say yes prompting you for each of the crucial parts.
June 9, 2011 at 8:27 am
I'm a huge fan of sensible defaults and basic performance-related reporting. Rightly or wrongly, I assume that a plain default install is suitable for the normal use case whether we're talking about some small third-party utility, Microsoft Office, or SQL Server. I have to assume that, because my role as jack-of-all-trades means that I can't possibly know enough about everything to effectively tune an install. I can adjust settings as I learn more or discover problems, but I think the vendor has failed if they don't provide sensible defaults and post-install tuning recommendations that cover the basics.
June 9, 2011 at 8:52 am
I see no problem with more safety nets. Honestly, it's not that hard for wizards to provide more contextual information about how you might want to configure different options. (E.g. when setting up a backup, *recommending* that the backup be on a different drive or, if the server is in full mode and no transaction backup is scheduled, providing some kind of warning about that).
Sure, the recommendations aren't going to be appropriate for experienced DBAs, just like the paperclip in Word that most of us ignore. But some basic initial questions (how many users, how heavily are users dependent on the system to do their job, etc) would give SQL server the ability to make determinations like Full vs Simple.
At the end of the day, people who don't know what they're doing need to make a series of decisions. If there's more contextual help in SQL Server, at least it might prompt people to realize there are decisions to be made.
The question boils down to "is a 6-size fits all default better than a 1-size fits all default". I say a 6-size fits all default isn't ideal, but it's better than a 1-size fits all default.
Leonard
Madison, WI
June 9, 2011 at 10:53 am
Martin Cairney (6/9/2011)
However, should a novice be installing, configuring and maintaining your mission-critical high-performance SQL Server system? Well, I know what my answer would be to that. In this case I am going to get an expert in to make sure that the correct boxes are ticked and the maintenance set accordingly and the last possible performance gain tweaked, and I sure as hell don't expect to see them running through a wizard clicking Next all the time.
Of course they shouldn't, but it always seems to happen. We (DBAs)recently started getting phone calls about a SQL Server not working, that was affecting the whole company's blackberry service. We had no idea that the server even existed, but it was on us to fix it, and fast. The whole problem ended up being that the transaction logs weren't backing up (nor the actual databases), so the server ran out of disk space. Although I'm glad the server came to our attention and is being properly maintained now, it would have prevented the problems for all users if there had been some default database/tran log backups in the out-of-box install.
We see this quite often, so I do think it would be nice to have some sort of default install options of this nature that can later be changed by someone knowledgeable.
June 9, 2011 at 11:09 am
I think offering more defaults would be a good idea. It would be nice if when other products (Cognos, Blackberries, etc.) go through set-up that they be required to make some default decisions as to how they will be using the SQL server so we aren't surprised when accounting calls and asks how come my budget isn't backed up or sales calls and asks where are my phone messages.
It would also be nice to force developers to use a PRIMARY KEY when creating a table.
June 9, 2011 at 11:15 am
Alan Vogan (6/9/2011)
It would be nice if when other products (Cognos, Blackberries, etc.) go through set-up that they be required to make some default decisions as to how they will be using the SQL server so we aren't surprised when accounting calls and asks how come my budget isn't backed up or sales calls and asks where are my phone messages.
I'm not sure what I feel about with this one. We have a few applications with pretty poor maintenance plans delivered by the vendor. If they're willing to be flexible with us putting our own on then I'm fine but I know how prickly some vendors can get.
June 9, 2011 at 11:25 am
Yes more safety nets. Two that I think should be fairly simple are not allowing DELETEs or UPDATEs without a WHERE clause. Another one that my co-worker constantly complains about is why isn't an index automatically created when you create a foreign key. They initially designed the entire database (83 tables) under the impression that a foreign key (constraint) was also an index. A couple years down the road, the system nearly ground to a halt.
Viewing 15 posts - 1 through 15 (of 36 total)
You must be logged in to reply to this topic. Login to reply