Which would you rather do, wade through the nuances of SQL Server licensing or a typical tax form?  Some days, I think the latter would be a welcome respite. Let’s just put it this way, I bet Brent Ozar (BrentO on twitter) is happy that licensing wasn’t the biggest part of the MCM grade. (I don’t know this, I just presume it because people actually pass the MCM every once in a while).

Common SQL Server Licensing Myths

The people in this maze might be better off than us.

I am going to talk about some of the more common myths I’ve encountered with licensing throughout my career and consulting. Microsoft has some decent SQL Server licensing resources including some PDFs (some short and some nearing legislation size with flowcharts abound). This quick guide is a good start to look at. Which brings me to a disclaimer:

This blog post does not replace your own research and understanding of licensing guidelines from Microsoft.  The thoughts presented here are my own and represent my views of Microsoft licensing guidelines and my interpretations thereof. My perspective has the potential to be wrong (I’m a husband, so I’m likely wrong, come to think of it ) and could become outdated with future changes. Check with Microsoft and your licensing representative to make any final decisions.

On to the myths I encounter…

You Need Enterprise

Look at the edition feature matrix for your version (2008, 2008 R2, 2005) and see what you need and anticipate needing – it can save you around $15k + per CPU to go with Standard over Enterprise. I have commonly bumped into people believing that they need enterprise licenses when they don’t when it comes to things like:

• Log Shipping (Standard is fine)
• Clustering (You can have a single instance two node cluster on Standard)
• Mirroring (Some types are allowed in Standard)

In fact, this post was inspired recently when I was able to see a project at a company to roll out Enterprise Edition simply because of Log Shipping. No other enterprise features needed. This company had great pricing on Standard and I was able to save them almost $60,000 in Enterprise licenses they didn’t need. Wait. There’s more! Act now and you can save even more because another myth sounds like this:

You Need To License Your Mirrored Copy Also

In most situations (yours may be different, double check), a DR standby (For mirroring or log shipping) doesn’t need to be licensed by default. Now there are certain triggers (pardon me) that will hit you with a license cost (Being failed over to it for more than 30 days or reporting off of a snapshot of the mirror, for a couple examples) but by default, many simple options don’t. This same company had an Enterprise License purchase (single CPU) for the fail over site. Another $19,000 saved with no standard license even needed because that instance can sit there “unlicensed”.

I Can Put SSAS, SSRS and the DB Engine anywhere…

You can. And, as a best practice in busier environments I’d say you should. But you can’t do it for nothing. You can put them all on the same box and they will be licensed as though you just had one (under most circumstances). The moment you split them out (again, generally a best practice for performance) you must license each component separately. While I’ve saved some companies money, here I’ve cost some money… Sorry. I don’t like it either but it is what it is.

Multiple Instances Still Means Multiple Licenses

I hate typing this because just as soon as I do, I am sure some pointy headed boss someplace will say, let’s consolidate every instance onto one machine! Don’t do that. But this myth isn’t true – you pay by the CPU by the machine. If you have two instances on one machine each using 2 CPUs, you only need one 2 CPU license. Add another instance to it? Same thing, no new license, you pay by the machine not the instance. This is great and can really help save some license expenses at smaller shops but just do so carefully as I wrote when I first drafted this SQLServerPedia wiki article on multiple instance decision making.

SQL Server Licenses Are By Core, Like Oracle

Or at least like Oracle was last time I checked… SQL Server (today.. I don’t know of anything changing, but you never know) licenses by the socket. By the actual die that goes into the socket. Not by the core or thread. So you can have a Quad core proc with hyperthreading that looks like 8 CPUs in perfmon but you are paying for a single CPU license. This is good to know. Might make that hardware upgrade more worthwhile. Who knows how long this will last and, for all I know, maybe it is gone by the time you read this, so double check yourself.

Virtual Server Licensing Works Just Like Physical

I’m not going to say anything except to say this isn’t necessarily true. There are all sorts of scenarios and differences depending on if you are using standard or enterprise. The IRS has a hotline (800-829-1040). So does Microsoft, if you aren’t sure it may be worth a call or e-mail.

Developer Edition Works for All Developers

Well that may be true most of the time. Your developers could probably use developer edition but keep a few things in mind: 1.) Did you pay for it? Or is it just a download everyone shares? If you are covered by MSDN (For each developer who touches the instance) or some sort of enterprise agreement then you may be fine. If you paid for the product and a proper license you are fine for the intended use in the agreement. If not, you aren’t. But also – consider this: What is production going to be? If your production environment is standard, do you necessarily want the product developed and tested on developer edition, which is Enterprise Edition by features, Developer edition only be price tag and EULA?? There may be a reason (especially if you have MSDN licenses for each developer, a good investment typically) to make sure an app is developed and tested in something other than Enterprise. Consider the end goal and end edition. It would stink to see Dev and QA using Developer and relying on some enterprise feature that never failed a test only to find a deploy gone wild.

Licensing, Just Like SQL Server, Is Set-It-And-Forget-It

No. No to both. Depending on your agreement with Microsoft the day may come when they come to do a true up of your environment. They will discover your SQL instances with you and verify you are using what you purchased. If you haven’t you’ll be buying more licenses and you are in violation of laws and software agreements. You could face fines as a company or a individual, potentially. An answer? Do your own True Ups. Awhile ago I blogged about using the Microsoft Assessment and Planning Toolkit (MAP) to discover your SQL instances. The report it spits out shows you all sorts of great details (server name, edition, version, CPU count, etc). Do your own true up, no reason you can’t. Are you in line? If not fix it by adding licenses or consolidating and saving the company hard earned cash (“Hey, boss, I just want 1%…”)

Summing It Up

A simple look at a few of the more common myths I bump into around licensing. They can all be summed up with the same advice, do your homework, understand the license agreements with factual information (not someones recollection or interpretation) and always double check. Even if the information comes from a trusted vendor (you know how I feel about that), you could be breaking the law or throwing away company money. Neither are great career advancement moves.

What about you? Do you have a licensing horror story? A tip for someone else out here. Leave it in the comments or blog about it and let us know when your post goes up, I’ll be more than happy to link to any tips to help folks avoid making a mistake up front.

Why on earth would anyone hire a Database Administrator? Your Windows Admin can install SQL Server with just a few clicks – It only takes a few more clicks to put a database there and grant permissions. Most of your vendors have simple setup scripts including database deploys… Why spend all that money on a DBA’s salary?

I’m glad you asked, I can think of a few reasons…

DBAs Are Mean Care About Your Data

Your developers hopefully care about the data. Your vendors care about their bottom line may even care about your

I'm sure they are great at their intended process but do you hire your developers from them? You might need a DBA

data as well.  Your system administrators like things to run smoothly also; no one likes a failure.  Your database administrators, however, have a vested interest in keeping your data clean and healthy. A good DBA will say “no” quite often (or, more accurately, “not yet”; “not deployed like that” or “no until security is cleaned up”) if something is being done without concern for security or performance best practices in mind.

Sure we can come across as tough sometimes but when you stop and ask why, it is usually because we care about the data. Maybe it’s not so altruistic and we just don’t like being woken up after hours. Either way, we are going to do all we can to fight silliness at every stage of a database’s life.

Sometimes it is appreciated and understood. A development manager at one point in my career sent me a note around review time that included this statement, “Our developers are very appreciative that, while you can be one tough and principled SOB, you are usually right in the end!!” That isn’t to gloat, it’s to say that a DBA who cares to do the job right and wants things right the first time can make a difference in the long run.

So Reason 1: A DBA cares about the database. It’s a myopic concern. Yes we care about the other facets of an application but it all stems from our desire to make the databases be all they can be. The other roles? They have their primary focus on something else (as they should!)

DBAs Like Best Practices

I’m talking about experienced and effective DBAs here. What I mean by the heading is that a database administrator knows what is beneath the set-it-and-forget-it installation options and deployment steps. We read books like Professional SQL Server 2008: Internals And Troubleshooting (some of us even read them on personal time!). We study up on the database engine we support. We want to first understand why a best practice exists and then implement the ones that make sense for our organization. We aren’t going to accept defaults, we aren’t going to ignore empirical evidence and try the first thing that a search engine shows us in production (hopefully). We may not just accept a hand me down server for that huge production ERP deployment. We might discuss SAN optimization with the storage team. When we look at a backup solution for the enterprise we will ask questions that are relevant to SQL Server and the recovery needs we support. We won’t let a vendor do something dumb without a lot of whining and attempts to correct.

Reason 2: A DBA cares to do the right job the first time. Again, you can even let it boil down to the self serving desire to not let the database be the cause for blame of a production outage. I don’t care, I’m still going to make sure that the database environment I support is running as well as it should and that we aren’t sacrificing best practices and performance (at least not always!) for the sake of “We’ll fix it later…”

DBAs Can Make Users Happy

How well are your systems running? Performance complaints? Do you have a DBA? If you don’t and the systems have a database back end it is incredibly likely that you are suffering from a lack of database TLC. I don’t know how many times I have been asked to consult on an engagement to “just make it faster!” or inherited horrible performing environments that were easily fixed with DBA 101 stuff (updating statistics, rebuilding indexes, the right settings, etc.). I know that because I do some consulting on the side, I might be eating into some billable time here but that’s fine, I have a busy life with the family, church and full time work. As a DBA, I usually know where to start looking for database performance problems. As a DBA, I usually know what planned maintenance to do on the database server and databases to keep things running smoothly. If you had a DBA, you would have less performance related fires; you wouldn’t have to pay an invoice to a consultant to come in and save the day. Your Sys Admin could help figure out an issue but, if they don’t have a lot of hands on – and academic – knowledge of database performance tuning and troubleshooting, it is going to take longer and could potentially include painful results if guesses/blind stabs are made. They specialize in a different skill set.

Reason 3: Database Administrators can prevent (or more easily resolve) performance issues or troubleshooting situations.

Oh No!!! Everything is down!

Picture a disaster scenario. System is belly up, drives are burned, whatever. How quickly do you want to be up? Your director, VP or CIO wants it yesterday and they want to know why your people are running around in panic mode looking stuff up on search engines.

A good Database Administrator (again, hopefully) is practicing restores or devising clever ways to sample for restore failure possibilities. They are thinking about disaster scenarios and possible responses to them. They have done restores before and have likely dealt with strange errors, corruption or common failure scenarios. Hopefully they are familiar with forums and know where to help find (and test) information. They can think on their feet about the ramifications of various recovery options or settings changes in a time of crisis.

Reason 4: Even if you stuffed your DBA in a closet on moth balls and only opened the door when danger strikes the time saved in that disaster and the possible data saved during that disaster justifies a DBA role in a lot of companies.

Your Data Is Your Business

How much do you rely on your data? Analysis of trends. Sales Forecasts. Payroll data. Sales data. Customer lists. Partner lists. Inventory. Shipping and Tracking information. You name the piece of your business, it is highly likely that you can’t name 2 or 3 that don’t have data stored in a database. What happens if you lose that? What happens if you can’t get to it fast enough? What happens if you can’t trust it to be accurate?

Reason 5: Your data is pretty important. You might have hired a Microsoft Exchange experienced system administrator because you realize how important e-mail is to your company. How useful is that e-mail system without your core systems described above? How much does your organization spend on various forms of insurance?

How Can I Get a DBA?

I could go on with more reasons. I could give you horror stories. I could tell you about the strange things vendors have requested (and the responses I’ve gotten when questioning those requests… Things like “look.. no one ever complained about that before”). I could go out and find statistics that talk about companies closing their doors because of data loss. I think you get the point though.

If you have database instances and applications running,  the simple truth is that you probably have enough work to keep a DBA busy. Maybe you could start smaller and get someone on retainer. I do that with some companies as an advisor/mentor. There are plenty of other people offering the same types of services, some larger companies dedicated to providing remote DBA or DBA Advisory services. Maybe you can hire someone with a good DBA background who has other interests and could wear a second hat for you.

I would say that in the New England job market, this must be a known fact – It seems like database roles are always being advertised or actively recruited, even in the down economy. So I would say get your DBA search on and fill that role already! Do it quick before the most experienced DBAs are gobbled up.

What do you think? Why do you (or don’t you) have a DBA? Any horror stories from when you’ve been burned by not having that role filled?

When I picture Paul Randal, I picture a guy who likes to run up to a bees nest at a crowded picnic and give it a good couple whacks. You know what I mean, it’s that laughing picture in his twitter profile. Or maybe it’s the devil’s advocate style he has. Maybe it’s his controversial facebook thoughts? Either way, he likes to call things out and make people think. That’s a great trait, all kidding aside. He started a blog meme asking what 5 “features” you’d like to see retired in SQL Server. His responses were great and he tagged some folks. I’ve looked at Brent Ozar’s response and was then tagged by Aaron Bertrand.

After reading those three responses so far, I have to say I am not going to be that original so most of these will be a hearty “Amen!” to earlier sentiments.

Auto Shrink

I made my entrance into SQL Blogging with a series of rants about shrinking databases. I still get hits to articles like “Don’t Touch That Shrink Button!” from web searches or forums. The simple fact of the matter is.. Well to put it simply, “raise your hand if you think regular shrinking of production databases is a good idea.” Okay. Look around. Any hands raised? Not many. So why, on earth, would Microsoft make that a stinking setting option?

I would like to see this retired, and doing it in a Service Pack would be alright with me. Or at least rename it to “I’m not dangerous enough by myself, please automatically add to performance frustrations and index fragmentation while keeping my database size tidy, even though it will grow again right after the shrink but then again I never liked right sizing databases that requires too much work – Yes/No” (Yeah, I know… Not the best grammar there, Jeremiah, but…) This was already suggested by Paul and Brent.

Full Recovery by Default (Or something…)

Again I’m stealing ideas (but I’m doing it to help people!) – Brent and Paul both also suggested this. This has been like this for a long time. It still trips countless people up each day. Another hand raising question – how many of you have experienced, helped someone with or laughed at someone experiencing uncontrolled transaction log growth caused by a lack of log backups in full recovery model? All of the hands that were down in the earlier question were just up. We’ve all seen it, hopefully we haven’t really laughed though. It happens All. The. Time.

A good tactical move would be to remove this as a default. Start folks out in Simple.  Or perhaps a strategic option would be a “Recovery Model Wizard” as a required step of installations? It would be nice to not need it but I think a lot of folks could benefit. As long as there was some way to override it with an advanced configuration, I wouldn’t mind a tutorial explaining pros/cons and costs of settings so people could make <gasp> informed decisions about their recovery models. Or maybe that is enabling companies to not hire experienced DBAs? I don’t know, what do you think?

No Simple Way to Truncate Backup History

Why make someone write a script or know to go look in a maintenance plan to find this option? Backup history isn’t critical to restores, sure it makes GUI based restores easier but how many GUI based restores are done going past 30 days? Why not make a default rolling window and let SQL cleanup that history. Provide a configuration option to change this window, even a configuration screen during setup asking other questions that should be asked but never get looked at by a lot of the SQL Server installations out there (backup history, recovery modes, heck even error log recycles)

Auditing – Enterprise Only?

Aaron talked about licensing models and I agree. One area is Auditing. Nowadays, even smaller companies with smaller budgets are being subject to increasing scrutiny and audit standards. In some ways, this can help a larger company that has a budget for Enterprise edition everything and an audit staff. What about the smaller company that is cash strapped? They can get most of the performance they need out of Standard and handle most questions/problems just fine, a $15k difference (or so) in per CPU licensing is a lot to ask for to better handle some of the auditing abilities in SQL Server.

Next, Next, Next, Finish

Aaron talked about the installation process in his response. He was talking about some of the bad defaults like I mentioned when talking about cleaning up backup history. This is perhaps more of a tongue-in-cheek response but it has some sort of a serious underpinning. I’ve always complained (raise your hand one last time if you’ve shared this complaint) that SQL Server is too easy to install. Accepting defaults and clicking next, next, finish gives folks a SQL Server instance that they put all of their most sensitive and important data. It also gives them:

• No backups
  

  Brings back memories of 386DX, "Boost Priority" is not a turbo button

• Full Recovery mode with no log backups
• No thought of DR
• No thought of right sizing a database
• Options that look tempting to select like “boost SQL priority”
• Data and Logs on the same drive (performance concern and recoverability concern)
• False confidence that everything is fine

That list could go on but the point is maybe SQL Server is a little too easy to install? I’ve heard it in a joking manner before like, “why do we need a SQL Server DBA? Any moron can install it!” I’ve seen the results of any old IT person (or business person) installing SQL. It inspired a series of posts on thinking about SQL installations.

I am going to take a cue from Brent and not tag anyone but welcome you to respond in your own post, leave a comment arguing with me (or agreeing) below or leave a comment on any of the blog posts that are sparked from the original post by Paul. I’d love to hear your thoughts, maybe I’ve gone too far? Maybe I missed something critical. I’d love to hear your thoughts. Also feel free to subscribe to the feed here for more posts like this.

Related Posts At StraightpathSQL.Com

• Why I think you focus too much on your backups – As discussed in the presentation, the focus should be on restores. May seem like semantics, but the focus on restore means you are thinking of more questions.
• How Do You Install SQL Server? – The first of a 3 part series where we discuss some tips for installing SQL Server and planning for a successful implementation.
• SQL Server Benchmarking Tips – I introduced the Performance Analysis For Logs tool in this presentation, this post talks about that tool.
• Find All SQL Server Instances On Your Network – I talk about using the Microsoft Assessment and Planning toolkit to locate all of your SQL Server instances. This post describes my discovery and use of this great (and free) tool.

Some neat (and free) tools to help you out with SQL Server. This is my second contribution to the SQL University “Tools of The Trade” week series.

In part one we had a quick chat about why to look at using various tools to help you out working with SQL Server. In this post, we’ll talk about some neat free tools I’ve encountered (or plan on encountering) in my career. This has a DBA bent to it since that is what I primarily am. Please do check out the post from DBA Coach, Tom LaRock, where he goes through all types of SQL Server tools. His post is great and covers a lot of information and he brings up a good point on rolling your own (I was originally going to say, “Don’t, plenty of tools already exist”. His post reminded me of what I learned through rolling my own tools early on and it reminded me that a lot of companies started out that way).

Enough introduction, on to some tools…

Performance Analysis Of Logs (PAL)

Great Tool! I was introduced to this tool from a SQL Server premiere field engineer working on a case at my full time position. I originally blogged about using PAL with SQL Server last year and have remained smitten with this tool. You can download it from codeplex here. Check it out, it is free and easy to install. In a nutshell this tool takes perfmon log files (even tells you what counters and objects to watch) and it creates pretty reports that show you potential issues. Great for troubleshooting general performance issues. Great for taking baselines.

Microsoft Assessment And Planning Toolkit (MAP)

Put down your pencil. Put down your notebook. Pop Quiz Time! Ready? How many instances do you support? How many instances of SQL Server are installed in your network? What version are they? How did you do? Put your shoes and socks back on please, it won’t help.

I don’t know a bout you but at most environments I walk into, that is not a readily answerable question. There are hidden SQL Server instances everywhere, it would seem. This is a tool that is also free and you can download it from Microsoft here. I blogged about this tool last year talking about how to find your SQL Server instances, but it really has other uses. Not only can it find your instances, it gives you a simple excel spreadsheet with good information (Server Name, Instance Name, Version and Edition of SQL Installed to name just a few) and you can use this spreadsheet as the start of a total environment documentation. Add columns for application owners, support people, etc. Import it into a database of database instances.

Enterprise Policy Management Framework

This great tool is another tool you can download from Codeplex. It is a neat framework that sits on top of Policy Based Management. It can take your existing policies and check them against all of your SQL Server 2000,2005 or 2008 instances that you discovered with the MAP tool above. It evaluates the policies and presents some excellent reports that can give you a good glance of how you are looking with compliance. This is a great tool to allow you to quickly find potential higher priority policy failures and drill into more details about what the failures are. If you are still doing homework from our meeting on knowledge sharing, this would be one great way to open up info about your environment. Publish the reports and let people see how compliant the environments are with the policies you setup.

SQL Nexus

SQL Nexus should be in your troubleshooting arsenal. It collects data from various sources and gives you some good diagnostics information and detailed reports outlining potential areas of concern. This is, yet another, free tool you can download from Codeplex (Sensing a pattern? Perhaps you can do some searching/playing on Codeplex and find some new tools in the process )

Three Books

There are plenty of other good free tools around. Checking out Tom’s post above or  following a blog syndication feed like SQLServerpedia will get you some tips for SQL Server tools as folks blog about tools they like. One of the books below actually goes into some details on tools like SQL Nexus. These books are three books I think should belong in every SQL Server person’s library. (There are others but these three are a good start).

In No specific order:

• Inside SQL Server T-SQL Querying. This book, by Itzik Ben-Gan, exists for SQL Server 2005 and for 2008. Perfect book for anyone who has to write SQL code or advise those that do. It covers the how and why behind how SQL processes a query. It covers set based theory and helps you think logically.
• SQL Server MVP Deep Dives – 53 MVPs got together to write this book. Tips and Tricks, advice and commentary on a huge range of topics. All easy reads, all written from the folks who give much to the SQL community. Proceeds of book sales help out a worthy cause as well.
• Professional SQL Server 2008 Internals and Troubleshooting – I just read 80% of this book ( have one more chapter to finish for an upcoming review). So far? This book is a great balance of academic knowledge going into the “how and why?” behind the topics and practical information (putting it together for the real world). The last few chapters of this book also talk about using a few free tools and reporting components to better tune and work with your environment.

I may make a part 3 to this in the future and add some more free tools that I missed in the interest of not over burdening you in this one post. If I do, I’ll link it here and it will be published to my feed.

SQL University Survey

If you would like to participate, SQL University is running a survey to seek feedback on all sessions provided this semester. If you have a few moments please check out the survey. The results will help us blog more relevant content and improve SQLU next semester!

I don’t know about you, but I’m too busy to do it all. I use tools to help me do my job as a DBA. Let’s talk about some of the tools or types of tools that might help you do your job.

This is Week 4 of the Spring 2010 semester of SQL University – Tools Of The Trade Week. Thanks, Jorge for setting this up! I’m your official instructor for this week but if you check out the SQL University site there may be some guest instructors adding their thoughts as well. We’ll divide this up into a couple posts. You are at the first post, a general discussion. In Part 2, I share some free SQL Server tools that have helped me.

Why Use Tools?

Do you have a full staff of production DBAs backing you up? Do all of your jobs and servers run as they are expected? Do you hate writing your own environment documentation from scratch? Get confused when there are performance issues?

Well, those are some great reasons to look at SQL Server help from some source. Be it reporting add-ons to Management Studio, a third party vendor’s product for monitoring your environment, some PowerShell scripts you wrote or even a SQL Script you found (and tested!) from a trusted resource, there are tons of tools out there to help you.

My goal in this post is to get you to think about looking beyond the tools that ship with SQL Server and consider your needs. Look at ways to get a force multiplier for your environment.

Isn’t SSMS Enough?

SQL Server Management Studio is a great tool. From it you can do just about every task that you would need to do to manage day to day DBA duties. Developers can bang out SQL code in it. Access can be granted or revoked. You can view built-in reports or add performance dashboard reports.

It isn’t enough, though. There are great tools out there from vendors. There are ways for you to fill your own specific needs with custom scripts or even your own applications. There are some great SQL Server vendors that come to mind who started because someone saw a need and developed a tool.

So What Do We Need?

Well I was going to go through a list of some types of tools in this first post but Tom LaRock actually beat me to the punch with his DBA coach contribution to the SQL University topic. Rather than do it here, go check out his blog and look at some of the tips and thoughts in his great post on SQL Server Tools.

We’ll come back inPart 2 and revisit some neat tools I’ve liked and used or liked and plan on using from codeplex (free).

SQL University Survey

If you would like to participate, SQL University is running a survey to seek feedback on all sessions provided this semester. If you have a few moments please check out the survey. The results will help us blog more relevant content and improve SQLU next semester!

So you have a plan to apply service packs to your SQL instances. You test them out and try to keep a regular schedule to ensure they are up to date. That is great.

What About SQL Server Management Studio?

What about the copy of SSMS that a developer is using to create scripts? This is spring of 2010 so perhaps I shouldn’t have to be inspired by this story but either I am alone and you can laugh at me or maybe you’ll double check and avoid the same issue. Some indexes recently worked their way into production in an environment that I am starting to put controls over, but hadn’t at the time. I use Michelle Ufford’s (SQLFool on twitter) index defrag script to programatically handle my index rebuilding/reorganizing and the script yelled at me and failed for a couple indexes. Apparently they were set to disable page level locking. What? This is a pretty advanced option that you’d want to only use if you suspect page level locks are causing issues and want to force SQL to maintain row level locks. In this case it was for a few columns in some very (for my organization) large dimension tables. It didn’t make sense. I asked the developer and he had no clue what I was talking about. Come to find out, he is using SSMS 2005 RTM against this SQL Server 2005 SP3 environment. Well there is a bug in the SSMS 2005 RTM version that automatically unchecks the “enable page level locks” option.

How Can I Check?

This is something you should be doing anyway. There are also other differences between versions and it is generally best to try and match (as best as possible) the versions you are using. I would say that the client tools can generally be at the latest even if you have several variations of SP/CU levels on your instances.

• E-Mail - You can try the “Please check your SQL Server Management Studio Version” e-mail option. Explain to folks how to check (Help –> About and look at the version number). You can even ask/require that everyone send you a screen shot of their findings. That might work, that might be a pain to manage unless you are in a smaller environment.
• SMS – I am not an SMS/SCCM knowledgeable person but I know these packages can inventory software on desktops and many companies use these to push software compliance. Well work with whatever team manages SMS/SCCM and have them look at this. Perhaps they can at least do reporting at first. You can work with the one offs and see if any edge cases exist. If not, perhaps an upgrade of the client tools automatically is in order, perhaps warnings/e-mails and a process to prevent connections if folks fail to change/etc.
• Programatically? – PowerShell is still on my list of technologies to get a lot more familiar with and I bet it could help here, perhaps. I can’t give you a neat script but the version of the ssms.exe file  will give you an even more detailed look at what version you are running. You’ll see the CUs as well as this post by Bob Ward at Microsoft explains.
• How do you check and enforce? I’d love to hear what other people do in their case to ensure compliance to the standard version/service pack (if you set a standard) and to ensure folks are upgrading client tools appropriately.

The Bottom Line

A code check/review would have potentially turned this up so one should have been done, they are now that this environment is more tightly controlled but perhaps that one option could have slipped through the cracks if we hadn’t already bumped into it. The bottom line here is that we may not be desktop technicians, SMS administrators, etc. but we should be aware of what tools our connections are coming from and we should get a voice in the process of determining that that is set in stone. Otherwise we risk strange issues and rat holes.

I’ll make a part two to this post and blog about various SET options and checking those periodically, setting standards. Sounds silly and nit picky but it can affect plan reuse and recompilations. Check back here or subscribe to the feed for the part two post.

Aaron Nelson is hosting this week’s T-SQL Tuesday. His topic, like mine from last week, has a lot of ways I could go. He basically said to talk about something that has to do with reporting. I decided to take the hodgepodge approach and talk about a couple things.

Disclaimer  – I am not syndicating this post because I am talking about a vendor’s product. I make no money from said vendor but enjoy working with their tools and have a complimentary license from them for use in consulting (mainly because when clients see the tool they want to buy it anyway). I also was invited to, and participated in, their first ever Product Advisory Board meeting, got some free food out of the deal (but not enough to leave my integrity at home). At the end of the day I like their product and get nothing if you select them and nothing less if you don’t but I think it is at least worth a side by side test drive with other such products.

SQL Sentry 5.5 And Letting Reports Save You

I have known about SQL Sentry for a long time, since hearing about them from a former manager of mine who happens to be a SQL MVP (regular readers already know who I am referring to). I have used their products at a couple of places I’ve worked and have enjoyed the experience. One thing I thought was lacking on the performance side was some underdeveloped reporting functionality but that has just changed. I downloaded their new version 5.5 when it was in Beta and I have loved their reports, even saved my bacon a couple of times.

Well, SQL Sentry 5.5 is in general release now and you can download a trial here. You can read about 5.5′s features in a blog post by Greg Gonzalez, their President and CEO.  I am not going to send screen shots of my environment’s reports because I don’t have a dummy environment setup and it would require too much Photoshop cleaning server names/etc but I’ll steal some of the screen shots Greg used in his post. I’ll also describe the importance of these reports in my environment.

While I think SQL Sentry is a great tool and would recommend it to anyone, I don’t really care what tool you use as long as you track history and can report off of it. It can save your butt, show negative trends and make life easier for you. There are lots of tools that can do this for you. You can buy a 3rd party product to handle monitoring, alerting and the reporting. You can play with the Management Data Warehouse and Data Collectors that Microsoft provides with SQL Server 2008 also.

Anyway… What are some questions that I have recently used these reports to answer?

Our New SAP GL system has been growing, we think. Can you tell us how much the SQL Server database grew since last Friday? So before I had SQL Sentry 5.5 I could have prepared for this question in advance by setting up jobs to track the data, configuring a SCOM SQL management pack to collect that data, etc. I didn’t have those things setup and the question caught me off guard, to be honest. I could go back and look at backup sizes and get a decent idea but I had SQL Sentry Eevent Manager/Performance Advisor running and had just recently installed 5.5 at the time. I clicked the Reports drop down knowing new reports were added when I upgraded to the beta version and saw a menu that looked a bit like this:

Some of the new Performance Reports

Nice! I saw one for SQL Server File Utilization – By Database… What the heck, I gave it a shot and sure enough. I selected the database I wanted, the date range I wanted (Friday to the Tuesday they were asking on) and poof! A pretty report showing the growth of used space in each data file in the SAP ECC database and a great graphical representation of how much free space remained. I was able to quickly tell them that each file had grown by about 12GB in that 5 day process. Graphical representation helped me explain the free space/used space concepts, the beginning/end text data helped me do a quick calculation. (The report had a percent change but they wanted the GB changed so I still had to do a little simple math. Maybe an enhancement request to put the MB changed also? Saves me from having to type calc ;-0 )

Database Growth Over Time

“The database server wasn’t running right last night!”

Another use of another report while still in beta mode. Came in to work and folks were complaining about performance the night before in the database server. Application team indicated it was probably a database issue and we should consider ways to improve that. It was an area we have had discussion in the past and there had been some DB issues but I got no alerts from SQL Sentry the night before, no alerts from SCOM and when talking it didn’t make sense that there was any DB issues.

Well before these reports, I could gather the data from a few sources. I could look at SCOM as we are tracking several performance counters, I could look at SQL Sentry’s Performance Advisor tool for that time frame and see the disk activity, TOP SQL commands issued, memory/CPU graphs, etc.

I decided to play with the Reporting menu again and discovered the Windows & SQL Server Performance report. Figured that might be a good way to quickly rule in or out DB server issues for further investigation. Ran the report and pretty much saw a quiet server that had a few spikes that were not correlated. Nice! I exported this report (like I did with the DB file growth report) to .pdf and sent it off with some thoughts. Turns out there were no issues at all (in any portion), just a bit of overreacting..

What’s the Moral?

As fun as it is when first starting out to build your own reports and monitoring processes, there is something nice about having everything you need a few clicks away. Consider looking at collecting your performance data in some form with some tool and have some reports ready to use to save you time in the rabbit hole later.

Mini Rant

I said it was a hodgepodge. This one is about SQL Server Reporting Services (full disclosure: I am in a SSRS 2005 environment, but I don’t believe this was changed for 2008). Now maybe it is only the environment I am in with some reports that need “help” and tuning work (some of which is in progress as time allows the development teams). Why can’t SQL Server write a permanent entry every time a report starts?! Sure there is some data in the Reporting Services TEMPDB but it is difficult, if not impossible, to make usable sense out of the data. Yes, if the report aborts or finishes a record is written to the Execution Log.

That being said, we occasionally have a report execution of one or a couple of our 300-450 reports that just brings the well provisioned SSRS box to its knees. We have no choice but to resort to service restart/iis reset/etc. Mixture of cube and Stored Procedure reports and it could be either. When trying to figure out what is causing the issue and seeing if we can just isolate the responsible dashboard, queries, etc. we can’t see anything. Why? Because there is no execution log entry until the report is done (with success or not).

I should (and will now that I am thinking of it) open a Connect item to suggest that possibly an Execution Log entry with a status of “in progress” be written when a report is FIRST requested. Then when it completes the status can change to completed,aborted,etc.

Is that so wrong? Do you bump into similar issues ever?

We have a plan to get moving to 2008 and that may even reduce the need for this functionality as SQL Server 2008 renders reports much more efficiently than 2005 and we likely won’t have these restart requiring incidents, hopefully.

I am sitting in the terminal at Charlotte’s airport waiting for my flight back, it’s a bit delayed so I have time to reflect on a great SQL Saturday. This was my second SQLSaturday and it was a fantastic event. Boston was also great, as I blogged about but I was here a bit longer and had more time to interact with a lot of great speakers and attendees. I also had a great time hanging out wit the folks at SQL Sentry for their first Product Advisory Council meeting.

I am excited to be heading home to my family but it is actually a bit sad leaving some of the great people I got to hang out with. Once again, there were some great speakers (It is intimidating to be speaking at an event with the names who spoke today).

I’m going to take a walk through my weekend with a few lenses. If you are interested, come along for the journey…

Product Advisory Council Meeting

Wow. A great time. I felt a little odd being there with crowd of gurus and MVPs that they had assembled but I wasn’t lost in the conversations. I’ll blog about this a bit more in a separate non-syndicated post since it is related to a product. Suffice it to say, I learned a lot and was able to provide (hopefully meaningful) input. I had a great time hanging out with the team and hitting the speaker party on Friday. What a great time put on by the platinum sponsor of this SQL Saturday – SQL Sentry. Great food and some awesome conversations with some familiar faces from PASS and the blogosphere.

SQL Saturday Presenter

I am balding faster than I realized...

So last month was my first time speaking at a community event and I was a lot more nervous and a bit more rigid then than I was today. I had a really fun time presenting both sessions today. A bit more fun in the first talk (more on that in a second) but the audience was great, the atmosphere was relaxed, I had laughs where I was hoping to, had some good interaction back from all y’alls in the audience.

I know what I need to improve on and am hoping to get some feedback to know what I don’t know I need to improve on but I really want to speak some more, it is a great next step in the learning continuum (I learned preparing, learned through the questions during and after the talks,etc)

First Talk – “As a DBA, Where Do I start?”

If I had to rate myself, I’d say this was the better of the two. I was in a 20 capacity room and the chairs filled up with some folks standing around in the back and sitting on the floor/tables. I liked the smaller room, the fuller feeling room and being closer to the audience made it flow better, I think.

The questions from this talk told me that I was heading in the right direction. I think I might tweak it to include some more demos and perhaps better show a priority of steps. I want to keep doing this chat, there are a lot of accidental DBAs out there.

I need to work on my slide design. I like the minimalist approach and the images I use in this deck to provide some levity (the waterboarding of vendors seemed to be a universally well accepted practice down here) but I want to link back to more points (Like Buck Woody’s checklist for DBAs) and maybe spend some more time on practical aspects, perhaps as a follow on to that conversation. Maybe a screen cast to make.

Second Talk – “You Can Tune Your Own SQL Code”

I saw a fair number of familiar faces in this talk from my first talk. That was nice, made me feel that much better about the first talk and inspire some confidence. That and all the sweet tea cursing through my system (I discovered and fell in love with the stuff down here… Did I mention I don’t get out of New England a whole lot?) made me definitely energetic for this talk. This talk was really crowded, I was a bit late getting over there because of the previous session and I had to fight a crowd to get in. It was a 20 person room but the tables and aisles were well filled. Hoping folks found what they were expecting.

It started out well. I feel like I had some good audience interaction and some good laughter (where I was alright hearing laughter, mind you) and some fun with the crowd. I need to rework and re-rehearse this presentation more, though. My timing of the slides to demos was off, I was too rushed in the demo. I also need to better tweak what I talk about, I only have 60 minutes and I can’t get into every single detail (like the side track on the whiteboard of B-Trees, those kind of discussions can happen later). I think the Phone Book trick worked to help illustrate SARGable queries and I’ll keep that. I will, however, re-time everything and make a better flow. All in all, I don’t think I outright bombed (please leave a comment if I did! It can be anonymous, My speaker rate account is completely anonymous if you prefer- Mike Walsh speaker rate). I had some questions afterwards, requests for cards, etc. but I didn’t feel as good about this one as the first talk. I want to give a better experience for the next time I deliver this talk.

SQL Saturday Attendee

I went to the following sessions:

Kendal Van Dyke (@SQLDBA on twitter) – He gave a talk on an introduction to Blogging and Speaking. He asked me if I would help on the panel but it was all his presentation. It was a great presentation, really shows what our community is about – Community. We don’t want to exclude speakers or bloggers, we want more! I blogged about that in the post series on blogging. A few people in the audience said they would start blogging or speaking. I really hope they do. Great presentation!

Tim Ford (@SQLAgentMan on twitter) – He said he was off because he was sick but he gave a good presentation anyway. He talked about tips for harnessing the power of Lazy as a DBA. Some good tips (including using templates for a baseline server installation process. That is awesome and I have a huge need for that in my day job, I’ll be implementing his idea very soon)

Kendal Van Dyke (again) – He gave a great presentation on SSD storage options with pros/cons and honest feedback/caveats. I haven’t yet played with it and his talk gave me some great food for thought. I was very impressed by his cold reboot mid-presentation. I have never seen a Windows laptop reboot so quick. One thing I may do is change my laptop drive real soon

Jeffry Schwartz – I met Jeffry at the PAC meeting. He is a really thoughtful, intelligent and in tune with performance kind of guy. His talk was great. He didn’t talk a lot about SQL Server but he talked about “performance outside the box”. He got into counters I don’t play with much in perfmon (DPCs, Processor interrupts) and talked about a lot of really good, geeky hardware and OS information. I am used to SQL Server sessions devoted a lot more to performance counters within SQL and SQL performance. Jeffry reminded us of something that should be common sense (but not always is a first instinct for folks) –> sometimes performance problems have nothing to do with SQL. He showed us some tools and tips to help see when someone else on your SAN is the blame, or when the system is to blame or even a driver/NIC configuration. I really hope to see Jeffry speak at the PASS Summit for a longer session.

Going Home Mike

Well that’s it. Going home Mike is tired (the sugar rush from the sweet tea is wearing off), filled with knowledge and excited to speak again. I won’t be doing any SQL Saturday’s until at least fall with baby number 3 (Sam) coming sometime around the end of May. I pay my own way and have a family to support. Plus my time will be devoted to getting the Seacoast NH/ME/MA SQL chapter working with our first meeting coming in April.

I may even to submit a Professional Development chat to PASS or perhaps even a variation of my DBA talk from SQL Saturday.

Again, thanks to the sponsors, this was a memorable time! I stole my picture from this stream: http://sqlsentry.smugmug.com/Events/2010-03-SQLsaturday33/11432245_nDzgG I am hoping they don’t mind

Did you go? What did you go listen to? What did you take away? Let us know in the comments or a post of your own.

Do you live in a town with a dump? I do (well, transfer station). On any given weekend you can find people looking for treasure in the scrap metal or electronics bins.

I never thought I’d say it, but over the past couple weeks of visiting the dump, I have found an amazing treasure that will help my career. Maybe yours?

“What’s the Treasure, Mike?”

No, it's not a new computer or developer attack broom

A story of two attitudes

Alright, I tricked you. There is no physical treasure to claim. Instead I found another story to add to my life lessons category to apply to my day job.

When I visit the dump I see what I would imagine are common dump frustrations – Grumpy staff working on cold (or hot) mornings getting yelled at by customers mad about fees for larger items.  People ignoring the rules about what goes where – “forgetting” to recycle, machinery breaking down, etc.

It’s a thankless job -  A lot of standing or sitting around, some yelling and every so often you find the staff going a bit over the top with the rules and empowerment. I can’t blame them, they probably get in trouble when the town racks up too much in fees from the next stop of our trash because of bad sorting.

This authoritarian type of employee can be found pretty easily. He is there to look at what you are doing and you know it and he wants you to know it. Forget that piece of plastic in the regular trash and you are getting chewed out. He was given some power, he likes it and he is going to demand your “respect” by making sure he points out your mistakes as loud as possible. He works there, you don’t, “don’t forget it”. We had this guy in my town. It appears as though he was replaced. Contrast that with…

A Newer, More Improved Attitude

A few weeks ago I noticed a new employee up at the compactor. I saw an unfamiliar sight when I saw him – he was unloading the trash from the vehicle in front of me. When I pulled up and got out, he was taking my trash bags and heaving them into the compactor as I walked to the back.

When I saw this I said, “Hey thanks for the help! You don’t have to do that though, I can get it!” His reply, “What else am I going to do out here? Helping folks out makes the day go by faster and keeps traffic moving better. Keeps me young” shocked me. What a response, what a lesson. We chatted about the job and his motivation a bit. He was smiling, seemed to enjoy his job and helping.

Every week since, I’ve been greeted the same way. Pleasant conversation and smiling help with my trash. Today was a cold, windy day. Normally the authoritarian dump guy would spend the colder days in the “office” trailer (unless someone was breaking a big rule). He was still out there helping unload the trash. I told him I appreciated it and was surprised by the consistent help. His answer was simple, “Nah, what else am I going to do? Why sit back there and let the day drag on?” His partner, a familiar face at the dump, has also been helping lately; it seems as though he’s started a new trend. new paint is everywhere and when asked the new guy indicated it was time to make it look nicer around there.

I am sure he still charges money to unload a couch. I am sure he even notices the “bang!” of a glass jar in regular trash bags and has to say something. I bet his approach is different, though. I’d imagine some folks recycle just because of the help they get now (and knowing he is seeing their trash bags up close).

What does this mean to a DBA?

To me, I Have experienced a real life moral story with implications to put into practice right now.

What’s the Moral?

In a sentence:It doesn’t matter what your job is, enjoy it and think about what you can do to make it a better experience for you and your customers.

Expanded:

• As DBAs we can come across as the authoritarian dump guy – The developers are our customers. They have deadlines and issues just like we do. We make mistakes. They make mistakes. Let’s cut them some slack and lift up a trash bag with them, have a conversation and figure out how we can help each other.

• Regardless of our task or assignment, we can have fun - This morning at the dump, I was greeted with a great attitude and smile. This was in spite of a pair of bright red ears in the cold.

• Building up people builds allies – What have you done for others lately? As DBAs we are under pressure (who isn’t?) from a few directions. When problems happen the Database is often blamed. When we are brought into the loop it is often way too late. When the network or disks aren’t cooperating, we sometimes aren’t believed. So? We can get bitter, take it out on the first code review we get invited to (or experience during a production performance problem) or we can smile and have a, “how can I help” attitude. We can help others out and focus on what we can be doing better while still holding firm to the right way. This keeps us in the data advocate role but does it with honey instead of bees.

My own trash became my treasure here.  I was reminded of some important lessons. I was given a thought process to take back to apply to my day job and I was shown one way that I can work harder at living out that Bible verse I claim on my business cards. (Col 3:23-24  And whatsoever ye do, do it heartily, as to the Lord, and not unto men; Knowing that of the Lord ye shall receive the reward of the inheritance: for ye serve the Lord Christ.)

I was recently tagged in an interesting blog post by A Misplaced New Englander, David Taylor. (dyfhid on twitter). The question sounds simple enough, “How do you use SQL Server where you work?” Of course the answer is not simple. I echo Grant Fritchey’s response in his blog post that it would be easier to post about how it’s not used. That being said we’ll see what we can do…

What’s my day job Vertical?

As a consultant part time nights/weekends I get to experience a lot of different environments and uses of SQL Server. Rather than talk about those, I’ll talk about the day job in general terms. I work for a large, global property and casualty insurer. We don’t write a ton of policies in the subsidiary I work at, but we write some very expensive and interesting policies. From oil rigs to directors and officers insurance to specialty cargo lines we insure it. That means we have to be quite adaptive to very different data sources with widely varying pertinent information about each of a multitude of lines. We don’t have huge databases but they are complex databases as a result.

Our primary claims system is built on DB2 and it feeds several systems that utilize SQL Server as a back end.

How Is SQL Server Used?

Some key uses:

• SharePoint - We use a global SharePoint (MOSS 2007) release to share information between regional teams and business functions. A few hundred GB of content databases so far in a relatively young implementation. As DBA I work closely with the SharePoint team in making sure performance is right, maintenance is right and things are working smoothly. SQL 2005 back-end but currently in the process of migrating to a SQL Server 2008 cluster on Windows 2008 we are building out in the coming weeks.
• Data Warehouses - There are several key data warehouses in SQL Server 2005. These warehouses track information about past claims, customers, financials, etc. These warehouses feed reports (in Reporting Services 2005 currently) and Cubes (analysis services 2005) which also feed those reports. As DBA I work closely with the warehouse teams in analyzing performance concerns, suggesting architecture and query improvements for performance and help with troubleshooting, availability and reliability decisions.
• Enterprise Service Bus - We have several applications built either on SharePoint web parts or .net web services. Lots of work with Biz Talk as our service bus. Data flows through to SQL Server and a lot of xml passing into and out of SharePoint. As DBA, I work closely with the dev teams in getting deployments done, performing code reviews and helping them write better performing code.
• Various ISV Provided apps – SAP is the financial suite we are in the middle of deploying (on SQL 2005) to replace Great Plains. We also support several ISV applications that perform various business back office functions or IT functions.

What do I do?

I am the sole production DBA. There are roughly 20 production SQL instances I manage and at least double that number of dev/test/uat instances I manage. Following the philosophy that the DBA is the data advocate at a company, I perform normal DBA duties but also spend a lot of time working with developers in understanding impacts of coding and design decisions. I also spend a lot of time in meetings discussing future plans, time lobbying the infrastructure team for improved hardware needs and helping to change the way folks access environment for deploys and development support.

My primary duty is to keep the lights on and make sure I am invisible to the end end users (the customers of IT as a whole.. I try to be very visible to developers as needed, but not to the end users clicking on reports, using the Operational Data Store through the ESB. Not invisible in a “not gonna help you” point of view. Invisible in the sense of, you shouldnt’ experience any issues that are database related so you shouldn’t have to know there is a such role as DBA, in a way. Does that make sense?

I help analyze new technology with the architecture teams and try to have a say in balancing technology to solve real business problems or technology for technology’s sake (tough line to tow sometimes at most places with geeky architecture teams… who doesn’t love new stuff?)

I give impromptu courses to developers on performance tuning their own code, spend time hand holding some folks through indexing and design considerations and try to share my knowledge wherever and whenever possible.

What Technologies do I use?

Besides the normal SQL Server tools and other free tools I’ve blogged about (Microsoft Assessment and Planning tool to enumerate all SQL instances on our network or Performance Analysis for Logs for performing benchmarks and tuning) I use several tools day to day…

• Monitoring Tools – We use Systems Center and Operations Manager (SCOM) for a large portion of our monitoring needs.  I also use a few vendor provided SQL Server specific tools to keep track on my environment.
• Development/Comparison/Etc Tools
  
• Word – Documentation is important, I blogged about my thoughts there. I try to use this when possible to at least do screenshots of installation processes but hopefully create more detailed documentation.
• E-Mail - A lot of folks wish I didn’t use it so much. I wish I didn’t. Something to work on in 2010 is improving conciseness and taking things out of e-mail (where it’s too easy to be misunderstood or escalate needlessly) and into in person/on phone meetings.
• Change Data Capture – We are playing with a really neat tool from a vendor (found out about them at a User Group meeting they sponsored.) This tool captures data changes from our source claims system in real time rather than through triggers and offers a huge performance improvement over DB2 OLEDB open queries across a Linked Server.

What are some Challenges I face?

Query performance. A lot of room for improvement and working with developers there. SQL Sprawl – Not multiple servers but “over instancing”, fewer servers  (saves on licensing) but many instances leading to some performance issues. We are going through a process of separating what should be separated and bulking up with either multiple instances (or single instance used for multiple purposes) for the applications that can handle it.

Reporting performance and a “self service” MS Excel culture in the end user community. A lot of the warehouse reports are high row count reports as a result. Lots of rows returned simply to be exported into, and massaged by, Excel. This creates some performance issues with the way that SQL Server 2005 Reporting Services renders reports. There is a plan to investigate SSRS 2008 as some key changes will provide some relief. It’s just tough to find the time with a single DBA Q1 2010 at this point. In the meantime, the self service aspect seems to really bode well for Power Pivot. I hope to create some demos in my spare time (I really want to learn Power Pivot and really feel it will be a huge win for my company) to show how cutting out the “middle man” of Reporting Services and giving richer tools for pivoting, formatting and massaging data will improve performance, reduce server load and make our users happier.

Rolling out new policies/procedures. Before me there was no official DBA, just reluctant DBAs from the team of sysadmins. As a result some of the best practices I enjoy seeing with SQL Security and deployment processes aren’t rolled out everywhere. It’s a slow process to go through proper channels but we are getting there. For instance, most environments have finally had their [Full Recovery Model, No Log Backup, Nightly Shrink Job] pattern fixed now.

The Final Verdict?

SQL is working well for our needs. Where there are challenges, I would imagine we would face them regardless of our DBMS. Most problems faced by most companies don’t seem to be specific technology related issues but rather timeline or process related issues blamed on technology. Here we have some good processes, are always working on improvements and our business processes and timelines work well for the most part resulting in a largely positive experience.

I look forward to getting more 2008 implementations out there (using it myself right now for Policy Based Management of other instances and the new SQL 2008 SharePoint cluster will be live soon. Hopefully the RS/AS 2008 for the warehouse reports in production by Q1/Q2). It’s fun watching developers increase their knowledge and watch the improved code over time. Sure there are some long days and weeks. Sure there are some tough weekends but all in all, this is fun. Every day of working with SQL Server as a DBA, “Performance Geek” or self proclaimed Data Architect is a fun time and I still treat the job with excitement most of the time.

Tag – You’re it

Rather than tag anyone specifically as quite a few have been tagged in posts already, what about you? Consider this an open tag (pretend I sneezed in a crowded movie theater and each invisible spore that left my nose is a mini hand reaching out to tag you… Sorry.. “outbreak” was on in the background while writing this post). How do you use SQL? What are some challenges you face? Add a comment, write a post and link back to the original thread Dave started or reference this post so I can see your response.

Welcome to part 3 in this series on a thought process around SQL Server Installation. In Part 1, we started talking about some basic steps and a thought process for a repeatable success story with your SQL Server installations. Part 2 discussed security, playing around before doing a first install and smoke testing afterwards.

Today we’ll close the discussion with some talk about maintenance, defaults and some post installation tips.

“The install is done, here you go”

Wait! You clicked finish, you reviewed the logs and tested connectivity like we talked about in Part 2. You aren’t ready to deliver yet though. Let’s cover a few things first. This, again, is not meant to be exhaustive but to help you think about the full process. Check out the documentation and blogs and explore in a dev environment.

Defaults

If you just did the installation and changed a few things like some of the directories and options, you don’t have all of the defaults but there are things to look at after the installation. There are defaults to change, or at least understand and consider. Let’s hit a few of them here.

Recovery Model

As the model database goes, so goes each new database you create (without manually changing it). The Model database is just that – a model database. Add a table to model and each new database you create will have that table in it. The same goes for recovery model. On all new installations of SQL Server the recovery model for the model database is “FULL” out of the box. This means that every new database you create will start out in FULL recovery model and the log file will continue to grow (after you take your first full backup — until you take a full backup you are not truly in full recovery mode either when first starting out or when switching to full from simple). This is important to consider because if you are only planning on ever doing full backups and your recovery plans only have you recovering to a daily full backup, for example, you will see your log file grow to a point that can get out of control. (Then you have to start playing with -ugh- shrinking)

If you don’t want this then change your recovery model. If you don’t know what it all means, start with books online.

Database Sizes

By default new database files are set to a small size (2MB for data, 1MB for log). Don’t accept the defaults here. How big will your database grow to? What kind of transaction log space do you expect to need? Plan for that growth, add an overage percentage and “right-size” your files at the beginning. This prevents file fragmentation from frequent growths each time the file needs to grow and it helps give you peace of mind in knowing your database is right sized from the beginning.

For the Log File, you may want to check out this post by Kimberly L. Tripp on some tips for right sizing the transaction log.

Database Locations

Hopefully you setup a separate drive each for data files, log files and tempdb. That is generally a best practice though in lighter workloads it may not be absolutely necessary to split out tempdb. I say for log files it is always good from a performance and recovery standpoint to split log files from data files.

Where is your tempdb file? Do you need to move it to the drive you requested and setup for tempdb? (Check out this books online article on Alter Database. There is an example there for moving tempdb, in fact)

Are your default directories for new database log and data files setup right? (Right click on the server in SQL Server Management Studio –> Go to Database Settings –> What’s specified for the default directories?)

Data and Log File Growth

The default growth options for data and log files are likely not what you want to see. While it’s important to “right-size”, I am also of the opinion that you should allow for autogrowth as an insurance policy.  I just don’t like the default growth sizes (1MB for data files and 10% for log files). Instead I like to specify an amount that allows a “healthy” growth for that particular database and workload while looking to minimize file fragmentation from small chunks grown at a time. This varies from database to database. On an environment I just configured for a database that started at 25GB data and 5GB log file I chose 500MB and 250MB respectively.

I like to setup alerts for autogrowth operations with a monitoring tool watching my SQL environments. I like the insurance policy but in my mind using the insurance means there was a problem with the right-sizing.

Backups (or lack thereof)

We just talked above about understanding your recovery model. That is the first step in the game. Step two is setting up a backup strategy that matches your recovery strategy. My philosophy is that people focus on their backups too much.  What I mean by that is – remember why we take backups – we take them to have a way of recovering our databases in a crisis. If you can remember that, your backup plan should come together and you should have backups setup and running in your new instance sooner than most other tasks.

Maintenance

There isn’t any being done yet. You can change the defaults above and deliver, but you’ll be getting to know this newly created instance at some point in production. Could it be a need to recover from failure? Maybe performance was fine and just started getting worse all of the sudden? SQL Server databases, like most other tools and applications, require regular maintenance. Let’s briefly talk about some of the quick hits I throw on most instances as a basic rule.

Backups and history maintenance

Can’t have too many reminders about backups. Make sure you are taking backups and have them running in an automated fashion.

Also make sure you are cleaning up your backup history. There is a great blog post by Jonathan Kehayias here. Rather than regurgitate or try my own attempt, check it out.

Index and Statistics Maintenance

Your databases should have indexes for performance minded querying of data. They also help in the performance of updates (which are essentially making changes to data based on a query of that data) and having a clustered index can sometimes mean an improvement to inserts and deletes as well.

They grow less useful if your indexes are heavily fragmented and more work is required when working with an index than would otherwise be necessary. Look at rebuilding or reorganizing indexes as time allows. A great script by Michelle Ufford for this is here.

Statistics also help your database performance. Without them, the optimizer has a lot less to work with. Statistics help show the optimizer how unique your data is, how many qualifying rows could be found for queries, etc. They can get out of data even with auto update statistics set on (the default behavior). Updating statistics is a good practice to get into with maintenance as well. Paul Randal blogs about the debate on what to do first (statistics update or index rebuild).

Error Log Recycles

Look up sp_cycle_errorlog and sp_cycle_agent_errorlog in books online. They are system stored procedures that do what they sounds like. They cycle the error logs in SQL Server and the SQL Server Agent. If you don’t do this from time to time the error logs can get a little too large to easily scroll through if you don’t restart your instance a lot (the error logs are reset each time your instance is restarted).

I typically recycle them weekly, especially in environments where I don’t have a monitoring tool and/or I do daily log checks on production environments ensuring no issues.

I also increase the number of error logs to a new number. If someone were to compromise a SQL environment they could theoretically run the sp_cycle_errorlog command the right number of times and some of their tracks are gone. I increase this to help alleviate that. It’s not ironclad but it is one more way to help harden SQL Server or at least provide more of a forensics ability.

DBCC CHECKDB

I don’t like database corruption. It doesn’t happen much and I take frequent backups to help alleviate potential data loss. Database corruption is rare nowadays. With each new release of SQL it seems to become rarer and rarer. But… It happens.

I like the comfort of knowing I check my databases for corruption as frequently as I can. I will typically setup a job to perform a “DBCC CHECKDB with no_infomsgs” on all of my databases as frequently as I can. While DBCC CHECKDB can be run concurrently with users in the system, I like to pick either low use or no use times to run it, especially for larger databases. I try to run it at least weekly and the more frequently, the better.

This will help my chances of detecting corruption before a user does.

Wake me up, as you go-go

(Is it wrong to paraphrase a wham song in public? I grew up in part of the 80s, but I digress…)

What kind of monitoring do you use at your company? There are a lot of great tools out there to use. There are even homegrown approaches you can find on SQLServerPedia or in articles at SQL Server Central.

There are pros and cons to many of the tools and some quick web searches will show you a lot of these. The point is – use something!

Don’t rely on the users to tell you when you have a problem or when a job fails. Before I hand an environment over to a project team or users, I like to know that I will find out if a job runs too long, a job finishes too quickly, the CPU is pegged for a substantial amount of time, the SQL Services become unavailable, etc.

It bears restating: Discover your problems before your users report them to you. (Or at least have a chance to do so!)

—–

Those are the basics I like to focus on when installing SQL Server. I am sure there are items that others look at as well. Please feel free to share them in the comments below. Thanks for reading the series and happy installations!

If you have any problems, feel free to leave a comment – I check regularly and have no problem helping you out with an issue during installation with some advice, clarification or a point in the right direction.

Some Related Thoughts

• While Talking about planning, do you ask potential or new vendors any questions about their database needs?
• Do you know about all of the SQL installations in your network? As a DBA, you should.
• Are you a new DBA? Maybe a sysadmin wearing a DBA’s hat? Here are some tips on where to start.
• Doctors, Chefs and Pilots can teach us DBAs a thing or two about Checklists, Recipes and Algorithms. Can be very useful in an installation or setup process.
• I used to hate documentation. I now see it as something to help me get help and have someone else do the next installation. Embrace documentation.
• Part one of this series – preparing for SQL Server installation by planning.
• Part two of this series – securing and testing your SQL Server instance after installation.

Want more content like this? Subscribe to this blog’s feed in your favorite feed reader and stay up to date with tips and tricks. I like to share techniques and free tools I use to help me with my day job.

Welcome to this series on a thought process around SQL Server Installation. In Part 1, we started talking about some basic steps and a thought process for a repeatable success story with your SQL Server installations. Today let’s continue that story and talk some more about installation planning and success. We’ll finish up talking about some post installation options (You aren’t done when you click finish!).

If you have questions or concerns along the way, please shoot me a note in the comments and I’ll answer, get you an answer or update this post if anything isn’t clear.

SQL Server Installation Tips (Cont.)

Again this isn’t a step by step installation guide. This isn’t even a series to read in order as you install SQL Server. In fact, when reading documentation (which I hope you write when required), always read through first before you start doing. I learned that the hard way when making cookies with my daughter once. Just started combing ingredients then got to the step in the recipe that said, “Combine the dry ingredients separately from the wet.” Those cookies were salty, crunchy and, well, pretty bad.

Instead these are some things to read to help inspire questions to ask and think about when planning to roll out a SQL Server Installation.

Security

What kind of industry do you work in? What kind of auditing/compliance regulations and secuirty best practices do you fall under? Regardless, it’s in your best interest as DBA to think of security from the beginning. Some questions to consider ahead of time are:

• What rights will your SQL Server and SQL Server Agent service accounts run under? Certainly doesn’t need Domain Admin, doesn’t even need local admin necessarily. Brian Kelley (Blog|Twitter) is a great resource on security. He blogs about the woes of using Domain Admin here.
• Unless you are installing 2008, the BUILTIN\Administrators group will have Sys Admin level access in SQL. Do you want this? You can change it (but you have to change it to do so)
• Windows Authentication only? I prefer it that way, it relies on the security of your AD and network, less chance of clear text password being stored someplace. Will your apps support it? (Talk to your vendors from time to time.. Ask them questions) If you go this route, make sure you have the right AD groups in the sysadmin role.
• Least Privilege –> A philosophy to think about with all of the above is least privilege. Grant the minimal permissions needed to do the job required.
• Groups instead of Accounts –> I prefer to use AD groups as SQL logins in most cases. This can make administration easier (new member joins a dev team, they get added to the proper group and have developer rights in the dev SQL instance) and if you already do a great job with approvals and audit trails of adding people to groups you just inherited a best practice for “free”. 

Availability/Recovery

What Service Level Agreement (SLA) will this instance fall under? Along with planning for I/O for performance and capacity make sure you consider your recovery solution. Do you have a separate drive for backups? Will you be using a third party program for SQL backups? If so, does it work on your proposed hardware and software setup? As I write this there are some interesting Operating System choices – Windows Server 2003 is still going strong, Windows 2008 has been in the wild for some time and Windows Server 2008 R2 is out and being used. What is the plan for your organization’s future? Do you implement that now? Better make sure the backup tool works and is supported first, kind of an important part of the job, recovery is. 

What about availability/disaster recovery? Considering Mirroring/Clustering? Replication/Log Shipping? Does the hardware support it? Are you installing the components necessary and the editions necessary?

Try It Before You Buy It

Yeah I know… Your timeline is tight, project management is breathing down your management’s neck to get this done. It’s your first time installing this version, this setup or with these options, though. You have a dilemma here – do you bang it out and slug through and have no impact on the timeline for when you can say, “Done! It’s built!”? Or do you spend a little time trying it out and breaking a few things along the way?

I vote for the latter when playing with something new. Even if it means a longer week in the office that week in order to make a date. I choose to pay now instead of later where possible. I am not suggesting you do a trial run for every single installation for the rest of your career. No, at some point you have to take off the training wheels and trust your process, your checklist and your smoke testing abilities. When first trying something major (and installing a production database instance is something major, no?), though, it makes sense.

Read the documentation. Read posts like this series you are reading right now. Look at pre-existing checklists, tailor them to your preferences and standards and try it out. Build up an instance, follow the checklist, take screen shots for your own documentation, tweak your checklist based on input, etc. Try it, test it, experience it.

Ask, “what happens if I press this button?” and then press the button and see. Take note of your findings and research the lessons. It’s called learning and building experiences. Take all of this knowledge and then apply it when building the real deal.

Smoke Test

You went through the process. You checked your checklist. You have an installed instance of SQL Server (congratulations, yes it was almost as easy as next-next-next-finish, but you thought of the big picture and paid attention) now test it out. We’ll go on in Part 3 and talk about some maintenance, settings and defaults post installation.

For now, check everything over. Can you stop and start the instance through SQL Server Configuration Manager? Does the server restart just fine? Can you connect locally and remotely? Is SQL Agent running?

Have you looked over the installation logs? Have you looked at the SQL Server and SQL Server Agent Error Logs? What about the System and Application event logs on the server? Verify the installed files are where you expected them to be?

Verify everything looks good but don’t check the “done” box yet. In Part 3 we’ll take a walk through some final considerations around defaults, maintenance and some other post installation tips. Then I’ll leave you alone.

What about you? What else do you think about pre installation and during SQL Server installation? Have some horror stories about installations gone wrong because they were so simple and quick? We’d love to hear your opinion.

Seriously? A Blog post about SP_CONFIGURE?

I was in a Kalen Delaney’s SQL Internals class (Blog) last week. It was a great class and I learned a lot of great stuff. One thing I learned was very simple yet it was really big to me… A tip about sp_configure that she didn’t even teach as a tip, just used it and thought it was common knowledge (was to a lot of people in the room but not me).

That got me thinking about writing a post about SP_CONFIGURE. What it is, what it does and what that tip is. So… Read on if you ever find yourself wondering, “How do I use sp_configure?”

Like what you are reading? Subscribe to my RSS feed to get updated with content like this in the future.

What is SP_CONFIGURE?

Simply put – it’s a tool to display and change SQL Server settings. It seems to me that a lot of reluctant and newer DBAs are well versed in the GUI based configuration options but not always changing them through a query (or even viewing them). Not all options are changed through a GUI, some are only changeable through sp_configure.

How do I use SP_CONFIGURE?

Well it depends on what you are trying to do….

View Settings

Take a look at your SQL Settings? Open a query window and just type and run sp_configure; you’ll likely get a partial list of settings. To see them all you have to enable an option called ‘Show Advanced Options’

Change Settings

Be careful.. Changing settings affects your instance, a lack of understanding of a result could dramatically affect your instance, performance, availability, etc. Look up a setting in books online and understand it first! This post is not about the settings, it is about the tool used to change the settings. Books Online is a great, free, resource when you have SQL Server installed, you can also get Books Online on the web (2005,2008). No excuses here about making a setting change without understanding it and testing it (Remember, I like to see empirical evidence before trying something)

Alright, now that my conscience is clear. You use sp_configure to change settings as well. You simply type sp_configure ‘setting name’ (*) followed by the value. Execute that and you either have to restart the instance (if the option is not dynamic – able to be changed on the fly while the instance is running) or execute the statement “RECONFIGURE” if the setting is dynamic.

For example – if you wanted to show advanced options you would have to type: sp_configure ‘show advanced options’, 1 GO reconfigure GO

Then when you run sp_configure again, you will see all of the available options.

* The Tip I learned from Kalen

You don’t have to type the entire option text in! At least in SQL Server 2005 and above. I never knew this. It’s right there in books online but I never went there for sp_configure because I’ve been using it all this time. So maybe this isn’t as exciting to you as it is me. I mean you can copy and paste the value. Perhaps you don’t mix up your L’s when typing Parallelism (see…  I had to pause while typing it…) but I do. You just have to type in an unambiguous portion of the text.. Try it.. Don’t make a change but run: sp_configure ‘degree’ and you will see the setting for max degree of parallelism. This is great! (Update: While spell checking my post, I realized that even though I typed parallelism slowly each time I spelled it, I got it wrong still… I’m a fool.)

Output Columns of SP_CONFIGURE

Pretty self explanatory but:

name – The name of the value to be changed, again you can look up the definition for these values in books online.

minimum – The minimum value setting that is allowed

maximum – Yea, the maximum value that is allowed

config_value – What value is currently configured?

run_value – What value is currently running?

Difference Between Config_Value and Run_Value

The difference may already be clear but it’s important to take note. When you first make a change by running exec SP_CONFIGURE (‘parameter’),newvalue the Config_Value has changed only. It is not until you either run reconfigure (if the setting is dynamic – that is no restart of SQL or reboot required) or restart your SQL Server instance (if the setting is not dynamic) that the run_value changes.

SYS.CONFIGURATIONS

The view only twin of sp_configure. You can select from this catalog view to see configuration options. No changing of settings necessary to see all options here since you can’t change them, it is a way to view your options and you can filter with a where clause.

This catalog view has several columns, the ones that are an exact match to a column in sp_configure will be ignored but the rest:

configuration_id – Just an internal ID of the configuration setting. Good for trivia? I don’t use it for anything…

value – same as config_value above

value_in_use – the twin of run_value above.

description – nice. A little less cryptic then the name column here or in sp_configure. I was going to say it might save you a trip to books online but if you didn’t know what it meant before reading a couple more words, you should still visit books online and understand the setting.

is_dynamic - This very helpful tells you if a value is dynamic or not. 1 = Dynamic, just run reconfigure after changing and it changes “on the fly”. 0 = not dynamic – need to stop and start SQL Server service.

is_advanced – Like the above, ever wonder if you have to change the show advanced option to display a value? Well you can find out here. It’s a flag, 1 is yes, 0 is no, like the is_dynamic flag.

Does This Change Require A Restart?

Just running SP_CONFIGURE, you can’t tell, can you? That’s why it’s important to pay attention above to SYS.CONFIGURATIONS (SELECT * FROM sys.Configurations). That is_dynamic value will come in handy. The Next time your manager asks you, “Does changing the max memory in SQL Server require a reboot?” you can look here and see the dynamic flag of 1 meaning, yes it’s dynamic so “no boss, we can change it on the fly.” Or see a value of 0 meaning, “Sorry boss, need to have an outage while we restart SQL Server).

But SP_CONFIGURE flushes the procedure cache!

No, it doesn’t. At least not in SQL 2005 and above. I don’t have access to SQL 2000 to verify that, but I believe it doesn’t there either. Something some people still say that used to be true in 6.5 and below (maybe 7.0 also, and possibly 2000 but I am pretty sure not.. test and see.. test and see..)

There, I gave you a few other basic knowledge items around sp_configure all to justify my shock, awe and desire to tell everyone that you don’t have to type the entire configuration name into sp_configure! Whoever said it’s the simple things in life had me in mind…

Lesson learned: Visit books online on occassion. Even if you think you know it all and it is a simple feature. Always something new to learn.

Also Check Out

I have posted some other tips and tricks of items I wish I knew when starting out or earlier in my career. Some are technical how-to’s, some are DBA career related.

• Advice to beginning DBAs wondering, “Where do I start?!?!”
• Shrinking – several posts on the topic.
• Troubleshooting Methodology Woes (I also wrote an article for SQL Server Central on this topic)
• Empirical Evidence
• Documentation (or how I learned to stop procrastinating and love tolerate a chore necessary task)
• A little Paranoia and Control Freak attitude can help a DBA
• Checklists, Recipes and Algorithms – Learning about these great tools from other professions (Pilots, Chefs and Doctors)
• How do I find all of my SQL Servers? – Maybe after listening to us you’ll want to spend more time with the instances at your network. Check this link out to learn about a tool that I use to find all the SQL Servers in my network.
• Questions to ask a software vendor – Working with a new vendor with their own database? Here are some questions I ask them.
• Benchmarking… Who needs it? – The answer, I hope you will agree, is everyone. Here I talk about how easy it is to do with tools you already have and a tool you can download free from codeplex.