Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « How to get the processid that SQL Server is using if you have multiple instances of SQL Server runningTrusting Database Engine Tuning Advisor for Query Tuning »
    comments

    Everyone took all the good things already so I’m here with the leftovers but still things I call the pet peeves and I wouldn’t miss. So here is the big five that came to mind

    Default Configurations

    OK, defaults help everyone. Mostly they help them not actually think about what they are doing. My first call to the drop spree is roughly 90% of all the defaults. Make us think about it! Is making us enter something really that bad of a thing? Maybe it will catch another 1% of the installers if they actually have to think. They may actually say, “Hmm…wonder what that means. I’ll go find out before putting a 1MB in that growth box”. We have the ability to optimize our own default settings so leave it to us.

    MSDTC usage

    Can we please come up with something that is actually stable by now??? All I think I have to say about that. Really, all there is to say about it ;-)

    MAX Memory settings

    SQL Server is an intelligent beastly database server. I mean, smart! So why does SQL Server let people put 2TB into the max memory settings when they have 4GB of RAM? Drop that! And if I catch any of you leaving 2147483647 as the default, your DBA days are numbered. SQL Server will act as fast as a cookie monster with memory cookies if you let it.

    Everyone will hate me and disagree on this, but can we get rid of db_datareader and db_datawriter already?

    Security isn’t that complex. Really, it isn’t. They need SELECT on this so you bottle it role and they have it. How many times do you just click db_datareader when they “just” need read rights? The same thing goes for db_datawriter. Well, they need write access to the DB so give it to them. Do they need write to ALL of it? No one can give me the excuse that your security would simply be far too complex to setup or you have hundreds of thousands of users. Hey, if you use all the containers and roles in which you setup right, it actually makes it easier to maintain ;-) Really, if a db_datareader or db_datawriter is needed, then create it. Don’t leave it as a big red button to be pushed far too many times.

    Last but nowhere near least; xp_cmdshell.

    We have far too many good tools like CLR now to need that bugger. Let’s start to use them and just take this thing out for good. Bring back the blank SA passwords if you leave this thing open to people executing it.

    I'm tagging Wendy Pastrick (Twitter | Blog), Aaron Lowe (Twitter | Blog) and Jes Borland (Twitter | Blog)

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
    Social SitingsTwitterLinkedInLTD RSS Feed
    1088 views
    Instapaper

    6 comments

    Comment from: SQLDenis [Member] Email
    SQLDenis Here is when I like xp_cmdshell


    EXEC xp_cmdshell 'bcp master.dbo.spt_values out C:\Junkdraw\spt_values.txt -T -c'


    That is when I am too lazy to open a command shell :-)
    05/11/10 @ 12:41
    Comment from: Wendy [Visitor] · http://wendyverse.blogspot.com
    Wendy So am I like Madonna now? Just "Wendy"
    LOL
    Thanks, Ted :)
    05/11/10 @ 13:12
    Comment from: Mike Walsh [Visitor] Email · http://www.straightpathsql.com
    Mike Walsh No hating at all for wanting to remove db_datareader and db_datawriter. Maybe it is because I am a DBA (which means I am a paranoid, pessimistic control freak)? So perhaps my judgment is clouded by my desire to control the world (well alright... maybe just the stuff that gets deployed to my servers since I have no control anywhere else... Wait.. Weird tangent, sorry)...

    Seriously though, why bother with db_datareader or db_datawriter. In this sue happy, legislate our problems away, auditable, standardized society it's time to get granular baby. Grant the rights you need to the people who need them. Nothing more. Nothing less. And let the abolition of the crutch we know of as db_datareader and db_datawriter help us on that journey!
    05/11/10 @ 13:37
    Comment from: Paul Hunter [Visitor]
    Paul Hunter I could do without xp_cmdshell *IF* there was a rock-solid wrapper for BCP, a beter version of file/folder exists, a few file commands (copy, move, delete, rename) and a directory listing tool. OK, I know all of those can be accomplished thru CLR functions with the exception of the BCP wrapper. But I'd really like to have the BCP wrapper. I'm trying to write one but it's tough because you have to infer behavior base on running it about a million times -- oh, and you still have to shell out to run it.
    05/11/10 @ 18:02
    Comment from: alen [Visitor]
    alen we use dbreader a lot, especially on replicated copies of databases and OLTP systems. if you have a database of 300 or so tables and someone needs R/O access to 30 of them it's just easier to give dbreader role. the writer role is more controlled on master copies of the database and some tables have explicit permissions or deny delete
    05/14/10 @ 08:27
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Hi Alen,

    :-) Thanks for the comments and reading

    I respectfully disagree with you on the datareader use. I admin databases with 2000+ tables and still refuse to use it. With just a little work ahead of things with creating roles that suite the security model, you can really make things cleaner and safer for your data. Really the statement, “just easier to give dbreader role” is what gets DBAs into trouble in the long run and why I would love to see it gone. Forces the process of a true security model over the data being manged

    Think about it the next time you have a security review. I think it would be a good move for anyone that wants to really get their data down to a managed state in which you can feel secure in who can get to what.

    05/14/10 @ 08:47

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)