A Great Idea – #SQLHelp hashtag on Twitter

I was following a conversation today between Brent Ozar, who is @BrentO on twitter and Aaron Nelson, who is @SQLVariant on twitter.

A great idea was discussed: A twitter hashtag that, as Jorge Segarra (or @SQLChicken on twitter) describes it in his blog post, can act like a bat signal.

Brent blogs about using the #sqlhelp hashtag to get help to an immediate concern and lists other options for help that require more than 140 characters.

Check out both blogs. In fact, Brent describes in great detail how to ask for help and I won’t recreate that here. You can tweet me any questions you may have. I’m @Mike_Walsh on twitter.

So that’s reason 1 for writing – To tell you about it.

What’s reason 2?

An add-on idea, or a bad idea?

So there are lots of ways to get help. Serverfault, Stackoverflow, Twitter’s #sqlhelp tag, MSDN Forums, SQL Server Central, Newsgroups (I go there just to watch the Aaron Bertrand/Joe Celko show and answer the occasional question) and even sometime in LinkedIn answers.

Most of these all have something in common: RSS FEEDS.

Why not get them all together and tweet new questions?

So that’s the idea. I am too busy to take it on right now but maybe, if anyone thinks it’s a good idea, someone can take it and run with it. The dream in my head looks something like this:

• A Twitter Account “MSSQLHelp” or something
• That twitter account simply tweets out from an aggregated feed comprised of all of the above feeds new question posts (including the #sqlhelp hashtag)
• Want to get notified of question? Follow that twitter account and put it in it’s own list/group and watch the list/group.
• When a question comes in that someone happens to catch on twitter and knows something about – they can click the link and help the person in whichever forum they asked the question.

Short of the idea?

So if that idea is really bad because I missed all of the finer points and details (or it just falls on it’s face) that’s fine. You can at least sign up the RSS feeds of your favorite locations to get and give help and see the questions as they come in. I need to be a little better at this. I am not the highest degree SQL Server guru-belt out there but I do enjoy helping with questions when I can.
That’s it.. Like the idea? Steal it, claim it and do it. Don’t like it, well like Brent and I said in the first part of our video interview on blogging (on Brent’s site), even negative comments can be better than no comments

Adam Machanic, who blogs at SQLBlog.com (lots of great sql bloggers over there) started a neat tradition: T-SQL Tuesday. Read his post here to see the rules and information but it’s basically a weekly (2nd Tuesday of each month) blog topic where we can all have a post about the same topic. I like this because it’s a great way to go in depth on a topic of interest to the community at large. I am not sure if the focus needs to remain on T-SQL or if we can bring up DBA topics, etc but I’ll find out if I get a chance to host the “event”.

I also really Like the numbering convention Adam used (“00n”), it shows he really wants to make this continue for awhile.

Dates and Times 101

This month’s topic is about dates and times. From Adam’s original post: “the topic for this month is Date/Time Tricks. Write a blog post that talks about dates and times–this can be based around T-SQL programming, data modeling, ETL, reporting, or whatever else you’re using dates and times for (and who isn’t?)”

Check back at his initial post to see all of the responses that come in on Tuesday. I will be visiting and expecting to learn a lot. I wanted to keep my response simple here so some of the true T-SQL gurus can have more of your time (and my time) when reading the posts.

So I am going to cover a couple basic points that have been on my mind for some reason or another recently…

We Are The World

Working for a global company with developers on three continents writing procedures and processes for users on at least 5 continents, dates and times can sometimes be confused. A lot of our databases are centrally hosted here in the states and tend to be in the default collation. So we don’t have a lot of language/special character issues but there are times when Dates can be confused.

Today is 8/12/2009. No, Today is 12/8/2009.

Who is right? Well really both answers are right depending on where you are and where you are from. To someone in the United States the second answer seems more right (Unless you are in the military and when using your pen, ball-point, black; you may be used to writing a date on a report as 08December2009). To someone in a lot of Europe the first may seem more right.

Keep this in mind when querying with dates.

The following date format will always be interpreted correctly by SQL Server regardless of your regional settings and collation. It is the ISO format for dates: YYYYMMDD. Today, by that standard, is 20091208.  When looking at the Cast/Convert books online topic and the chart, you’ll see this is format 112.

Format 126 (ISO 8601) is also recognized globally and it includes time. Check out that books online article and get to know and love these date formats, especially if you are working with folks across the globe.

You Don’t Have to Cluster the Primary Key!

This is something that should be common knowledge but through interviewing folks, working with developers and seeing newsgroup/forum questions, it still isn’t. The default behavior in SQL Server is to make all Primary Keys the clustered index. There is some merit there but it isn’t a requirement.

Sometimes a date column, even if the date is not very unique (perhaps not tracking times) or even in some cases where the “date” is really just an integer of YYYYMM. Can be a good clustered index in my experience.

Where? Mostly in data warehousing situations in my experience. Especially if folks are typically querying for a range of time, for transactions on a particular day or wanting to sort results by date. I find that in Fact tables a clustered index on something to do with the date can be helpful.

Why? How often do you query a Fact Table by a surrogate key? Yes some could argue well indexed dimensions and non clustered indexes on all the dimension keys in the fact table (perhaps on some commonly used measures) is enough. I find that the dates help for the reasons describe above on querying the data. It also helps when loading the warehouse if the dates come in in date order. You still have much of the benefit of an ever increasing clustered key reducing insert overhead from page splits,  and having to look all over. Yeah there will likely be some dupes, so there is a 4byte uniqueifier overhead in the clustered index. I would also imagine that when partitioning by date this clustered index strategy would make life a bit easier for you.

Of course, you should test in your environment and use what works for you. Empirical Evidence speaks volumes when trying scenarios out. Experiment with your indexes and see what works best for your work load, your insert behavior, your query behavior, etc.

Off To Read The Other Posts

Ok well I’m not really off to read them at this moment. I am writing this post on 20091204 and will, on 20091208, go and read other posts to learn a lot about dates and times. Check the original post for all the trackbacks of interesting date/time information.

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.

How many times have you heard or uttered those words? You work hard and understand the business requirements, you try and get the logic to work to make the procedure return what was expected or update the data as expected. You do some unit tests in your environment, it may not scream but it comes back in what seams like a reasonable time, the results appear right and you say, “Ship It!” It passes QA (if you are someplace that has a proper QA process) and it gets to production. Then the DBA walks by (or a user calls you) and something is wrong… It isn’t returning, or it is taking far too long or timing out even.

Why? It “Worked fine in development”!!!

If you have experienced that with SQL Server development (and who hasn’t at least once) then I am hopefully writing to you here. I will warn you ahead of time, though: some of the things in this post may seem obvious. I think we need to take a quick back to basics approach here though based on most of the cases I see…

The Basics

• How much data is in dev?-  Seems kind of basic but it is often overlooked. Especially without a production mirroring Test/UAT/Performance environment (Which more environments than you think suffer from). If your development database has a fraction of the data in production you may be in for some surprises.

• Parallelism – Most machines now have more than one (physical or logical) CPU but what if your development environment doesn’t and prod does? (or vice versa which would be kind of odd). What if you don’t mirror your Degree of Parallelism settings? You could go to production and a query that seemed to perform well is now not. One recent example I saw had a query plan that was influenced by parallelism choosing an index scan when it should have been doing a seek. It was reading far too much data but all things were the same between dev and prod except for the number of procs (1 to 8). The fix wasn’t to disable parallelism, the fix was an important missing index. In development the plan was still inefficient but it didn’t “feel” inefficient to the developer.
• You do look at your query plans, right? - As I blogged about here, reading a query plan isn’t rocket science. Once you start looking at them they become clearer over time. The real danger, however, is not looking at them. Even if your query comes back in half a second in dev, look at the plan and make sure you aren’t doing anything silly.

• While you are at it what about IO Statistics or Profiler? – Whenever I am tuning a query, I generally have SET STATISTICS IO ON at the top of that query. I want to see what the reads look like. You will find debates about tuning to reads but from my point of view it is important to keep your reads lower. Not to the point where doing so increases duration because of some crazy logic. Generally it is my finding that the less reads a query does, the less duration it takes. Not always true but look at your reads in dev. If it is high there and in production there are a lot of similar queries and more than the one user in dev you may be asking the production server to flush pages from memory at a faster rate than you would otherwise like. This means more physical I/Os, which are not as happy as logical I/Os. Profiler is a great tool (as Gail blogged about here) to show you the impact of a UDF. Your query plan and I/O Statistics are not going to show you the impact of that UDF you have in your select list because you are a procedural programmer turned SQL Developer. In fact don’t just look at the duration/reads in profiler but look through Gail’s post and look at the statement completed events to see just how many times that UDF code that was so efficient alone is being called.

• You do keep your statistics updated, right? – Sounds like a “No Duh” but it isn’t in a lot of places. How often do you update your statistics in the database? When you refresh dev, do you update statistics? Do you have a job to do so in Prod as well? If your statistics are out of date, your query plans may not make a lot of sense and they could be sub-optimal. The optimizer is a powerful tool but it can only be as good as the information it has when figuring out an approach.

•  How often do you compare schemas? – Your dev environment does look like production, right? What about your indexes? Do you ever run a tool like Visual Studio Team System for Database Professionals or SQL Compare from Redgate (not a paid endorser but this is the tool I personally use for schema comparisons, even with VSTS DB in house which I like for other reasons), etc? You may be surprised but I have seen a lot of cases where a developer has created an index in dev or even in QA/UAT/Performance (Why, oh why, did you give the developers permissions to those environments…) and got quite busy and forgot that they meant to check that the index was scripted and included in a deployment plan.

There are other causes and there are even some strange occurrences that take a bit of time digging into. Generally, though, these are the reasons I tend to uncover in this scenario. Another cause is not meant as a slight against any one role in a project, it is something we all mutually contribute to:

The development is NOT done when the expected results are returned or the expected actions occur!

I have seen overworked developers and DBAs, under funded project managers (resource and time wise), over zealous management (as far as this date will be met, no matter how realistic it is) and a variety of other causes to that rant above. The simple truth is, development is done when it performs the expected action, the unit tests in dev have verified it and the unit tests also looked at performance and the piece of code is performing as best as it possibly can given the circumstances. Low hanging fruit type problems abound in most environments I have encountered. I know the projects never have enough time but sometimes 20 minutes extra on a procedure could have meant that one wouldn’t have showed up on a “worst offenders” list.

I don’t want to put all of the onus on development either. DBAs should setup standards and best practices and have code reviews. They should mentor their teams in performance areas. Senior developers should do the same.

Management needs to put an emphasis on proper testing, including performance testing (either in dedicated environments that mirror production hardware and data as best as possible or in a test environment that is as close as possible). There will always be performance problems that slip past development just like non-performance bugs. Without searching for them before production, it’s your users that will be your bug reporters. That could mean the difference between retaining a client or system adoption.

Disclaimer: I mean what I am going to post. This is not a Microsoft fan boy post. That would include a conversation about my Zune, the Xbox 360 I don’t have or something… I think this is a great resource for a Microsoft shop.

A TAM?

Technical Account Manager. When your company pays for a premier support contract with Microsoft you get assigned a TAM. They help liaison between you and the support arm at Microsoft. When a case is open for too long, an on the ball TAM will call you, call the support group and get things moving. If you want to ask a question without incurring hours, they can sometimes help you out. Most TAMs will come out to your site at least monthly and just check in with all of the folks who have support accounts. They want to make sure you are happy and getting what you need.

How do I get one?

Well you have to have a Premier Support contract. I don’t know the details on pricing or how it works but if you are an enterprise that wants to have that peace of mind that you have the hours available, have the escalation assistance available, etc. It makes sense in my mind.

So what, I don’t need a TAM.

Well right, it’s not all about your TAM. It’s the services offered by Premier Support Services through your TAM and the support umbrella. Some of the benefits from being a PSS customer and having your very own TAM:

• A recent training course on SQL Server 2005 Performance Tuning and Optimization. This was taught by a Premier Field Engineer (They will rapidly respond to a critical situation at your site that can’t be handled over the phone. They work within premier support, not sure how they are dispatched to non-premier customers. Like anything I imagine if you set it all up front, it is more timely and less expensive) named George. Knowledgeable guy, great material. There are countless classes like this for all products. You don’t “pay” for the course but you have proactive support hours deducted from your account. If you do it right and spend more time in proactive mode, your reactive calls are hopefully lower and you end up doling out less hours anyway so it all works out.
• Alerts (Upcoming security patches, serious issues, information of interest to my role – SQL -, upcoming free webinar reminders, upcoming local free or PSS-hour deducting courses) – I probably get at least one e-mail a week from my TAM and that is consistent with other gigs that included premier support.
•  An Extra Set of Hands – Your TAM sees your cases on their web interface, checks in to be sure you are getting proper support and helps escalate as needed.
• Access to web interface/advanced hotfixes – When you have premier you can log calls through a web interface. You can also search this interface for special knowledge base  articles and hotfixes available only to Premier customers which may assist you.
• Someone to vent to – As in most of life, things don’t always happen in an ideal fashion. Without Premier you can still get to the chain of command. With a TAM you have someone readily available to whine to and you get instant help in making it right.
• A monthly visit - It has been my experience at a couple of places that our TAM came up and visited monthly. Asked how things were, chatted about upcoming events, asked how they could better help us, suggest proactive services and even head out to lunch on occasion.

Proactive Services

One of my pet peeves is always being stuck in reactive mode. Sometimes you need to stop and ask yourself where to begin. Sometimes you may need some help. Through Premier Support you can have a SQL Server Health Check or a SQL Risk Assessment Program check (SQLRAP.. Not Michelle Ufford’s kind of SQL Rap – Ward Pond’s kind of SQLRAP)

Through these programs, a Premier Support engineer with expertise in the product being checked will come onsite, work with you and analyze your environment with a goal of increasing your proactive abilities. They don’t come to ding you, audit you or belittle you. They come with great tools, analyze your instances and help document a plan to get where you need to go. They also give you an excuse to be proactive. You have to schedule the days to work with them and you need to sort of just let things pile up and focus on proactive mode. This is an invaluable tool for you to use. In fact I feel the same way about these checks as I feel about finding your instances with the Microsoft Assessment and Planning tool.

You can learn more about Premier Support Services at this link.

This is the final in a series on shrinking and transactions. You can see them all in the Shrinking & Transactions category.

In part 1, we talked about factors that affect transaction log growth. We talked about what a SQL Server transaction is and the various modes SQL interacts with a transaction (Autocommit, Implicit Transactions and Explicit Transactions).

The theme of that post was about managing your transactions so they don’t manage you. In that same theme, let’s continue being in charge of our transactions. Rather than from a physical size perspective, let’s look at it from a performance standpoint.

Database Engine/Administration Factors

When it comes to ensuring that transaction logging and transactions don’t cause performance bottlenecks there are a few things DBAs should remember and look at, I’ll highlight a few of them.

Pay careful attention to the I/O of your transaction log – As I discussed in Part 1, the transaction log record needs to be written first and this is vital to remember. Keep your Transaction log on fast I/O, separate I/O and follow best practices with your log file.

A great blog post by Kimberly Tripp with eight tips here goes through many more details that I have often hinted about in various posts. Some of her tips are best practices for the data file as well.

She mentions things like: Pre-Allocate Your Space!! This is a huge pet peeve of mine. Plan for your capacity and start out with the size you think you will need. This will stop costly autogrowths which can lead to fragmentation and waits (for the growth.)

Or Defragment the physical volume , people spend a lot of time in the database world looking at index fragmentation (at least I hope you do!) What about your physical storage?

When it comes to choosing your RAID, remember the transaction log is going to want fast writes. These writes are sequential. These writes are writes. RAID 5 (Wikipedia article on RAID) may not generally be a horrible solution for your data (.MDF/.NDF) files. For the Log files, it just doesn’t make sense. RAID 5 incurs extra cost for each write (essentially 2 reads and 2 writes for each write because of the maintenance of parity for fault tolerance).

If cost is an issue, look at just mirroring. This will give you some fault tolerance (Remember, the transaction log is key to a happy, consistent database as we talked about in Part 1) and still gives you the same performance as writing to one disk.

If the mirror doesn’t give you great performance for your high end, high throughput applications, consider RAID 10 or RAID 0+1 (both are essentially combining striping and mirroring in various means). These will give you the redundancy with the performance benefit of a stripe.

Don’t get into a shrink/grow. shrink/grow pattern. I have harped on this one. Set it to the size you think you need, manage it’s growth and monitor it. Tibor Karaszi has an excellent post about log shrinking and it’s effect on Virtual Log Files (VLFs).

Pick the right recovery model! As I discussed in Part 1, recovery models are important for log growth. It’s also important to pick the right model for your recovery needs (in fact much more important to pick for recovery needs.. (Remember we do backups for restores in fact it’s the restores that are more important). Let’s presume that you care about point in time recovery and you pick Full Recovery:

That’s great. Now get a strategy to PERFORM LOG BACKUPS. Being in full recovery mode without doing full backups is pointless. This tells me you aren’t performing restore drills (are you?), you are probably truncating and shrinking your log file when you run out of space and you potentially can’t meet SLAs or expectations. This will cause all of the above issues but it will also manifest itself in performance problems. So get with the program and do those log backups on a schedule that meets your required recoverability (one of the “itties” we should all care about) and manages growth/performance best.

These are some of the highlights that quickly come to mind that a DBA can have effect on. There are definitely more, check out Kimberly’s post above and look around her blog, great stuff to keep in mind.

What about:

Things Developers Can Be Mindful Of

KISS – Keep it short stupid – Alright, the stupid part was uncalled for but it worked. The key to remember when developing is if you are holding a transaction open, you are holding locks for the duration of your transaction.

What kind of locks you are holding depends on your operation (Select, DML, DDL, etc) and your transaction isolation level and any lock hints you may be using (Andrew Kelly has a great post about the dangers of NOLOCK or SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED). Remember that when you are in a transaction, whatever lock you had to hold to perform your operation is held until that transaction is committed.

If you perform an update within an explicit transaction (BEGIN TRANSACTION) and you are in the default isolation level of SQL Server (Read Committed) you will be holding some sort of exclusive lock even after your update statement is finished. SQL doesn’t know if you are going to rollback or commit your work so it has to lock either the rows, page or table (depending on the grain of lock chosen) until you tell SQL that you are done. This means that you can block other updates, other reads or other operations until you have committed/rolled back your transaction.

This is excellent behavior out of a DBMS. You want to hold a lock until you are done. Otherwise you might as well just throw data integrity out the window. It’s bad when you hold that poor transaction hostage longer than need be. So, the solution is simple:

• Keep your transactions as short as possible
• Properly handle errors and rollback when necessary
• COMMIT as soon as possible
• Don’t try to solve world peace and hunger within one transaction - I cringe when I see a single “BEGIN TRANSACTION” and then multiple page downs of operations, cursors, select statements, crazy logic, etc before you get to the commit or rollback. This means that all of those locks are held and you are probably causing blocking until you are done. Batch out work.
• Even with implicit transactions, don’t try to do too much work in one operation. If you are updating an entire table, and it is a huge table, try and batch it out, allow the work to commit, allow a checkpoint to fire and keep your log from growing.

You tell those Writers, we just want to read!

Sorry, you hold locks also. When you issue a select you are still holding a potentially blocking lock. This depends on isolation level and lock hints but in the default isolation level you are holding a lock. This is to prevent you from reading data that is about to be rolled back. Readers Can (and often do) block writers. If you are in a busy OLTP system and experience a lot of timeouts on update/insert operations look at your reporting queries, your select queries.

Optimize your code for performance. This holds true for updates/inserts and selects but watch your selects, if it takes you 10 seconds to bring back data to a screen, that is 10 seconds (per select) that you are potentially blocking a writer. Even if it takes 20ms but is executed quite frequently, that is a potentially substantial situation. Look at the performance of every piece of code you release! Query tuning doesn’t have to be difficult. One place to start is this post but a quick search will yield a lot of tips. Check out my blogroll, a lot of excellent advice on those blogs.

Think about performance at the beginning of a project rather than the end and your life will be easier in production. DBAs – make performance be an initiative at the beginning. Yes you are too busy for proactive work right now, make time for it anyway. When you pay later you always pay a lot more.

Again, with Part 1, I am hoping that a lot of this was review and simple. At the same time, if it helped anyone, great. There is plenty of advice out there and some careful thought and consideration to managing your transactions and .LDFs will go a long way.

Related Posts At StraightPath SQL

• Manage Your Transactions (So They Don’t Manage You – Part 1)
• Don’t Touch That Shrink Button!
• Shrinking Is A Popular Topic
  

This is part 3 in a series on shrinking and transaction management. Click here for part 4. You can see them all in the Shrinking & Transactions category.

If you are one of the people who have been reading this blog, you know where I stand on shrinking databases/log files. I don’t like the practice (Post 1, Post 2, SQLServerPedia article.)

That being said, let’s look at a couple of reasons why transaction logs can grow and what you can do about that in a proactive mode. We’ll break this down into a couple posts.

Through answering forum questions and some recent conversation at a Microsoft SQL Tuning class, it strikes me that there are some misconceptions about how transactions work, when one needs to commit/rollback and what the recovery models actually do to your database. Hopefully we can rake through some of that today.

What is a transaction?

This is probably a review, so let’s just hit the quick points:

• An atomic unit of work that either succeeds or fails together as one.
• Classic example is the credit/debit example (Note this doesn’t work with government budgets, think of your checking account)
  • You are online with your bank and initiate a transfer from your checking account to your loan account. This transaction includes a withdrawal and deposit. What happens if there is a failure between operations? Depends on if the work was done in a transaction:
  • In a Transaction – The withdrawal that happened is undone (rollback) and everything is fine.
  • No Transaction – The withdrawal completes (commit) and the deposit never happens. You are out $300 and have it sitting in limbo land someplace.

Implicit/Explicit/Autocommit?

There are three modes that SQL Server can operate in with regards to transactions. Implicit and Explicit transactions or in autocommit mode. Let’s explore those:

• Autocommit Mode – This is default behavior in SQL Server. This is also where a lot of people can get tripped up in their thinking (more on that in a minute…). Basically here, if you were to issue a SQL query that modifies data, once that statement completes (without error) the work you did is automatically committed.
• Explicit Transaction – This is also default behavior in SQL Server. If you want to declare a transaction yourself and specify when to commit or rollback a unit of work you use the BEGIN TRANSACTION, ROLLBACK TRANSACTION or COMMIT TRANSACTION commands. You declare your transaction and then through proper error handling manage when to rollback or  commit based on your business rules. Through this method you can have multiple statements inside the same transaction as opposed to what happens with autocommit.
• Implicit Transaction Mode – This is off by default but you can enable it within a session with this command: SET IMPLICIT_TRANSACTIONS ON. You can read more about it in books online (here). Basically anytime you issue a command that can modify data, SQL Server will implicitly issue a behind the scenes BEGIN TRANSACTION for you. Every statement issued from that same connection is part of that one transaction and you have to manually issue a rollback/commit command to complete that transaction. Forget to do it and now you have one big transaction which has it’s drawbacks (see below).

My Log is still growing! I didn’t do a BEGIN TRAN?!

So you are doing ETL, doing a large delete operation or otherwise modifying a lot of data at once. You are in simple recovery mode (transaction log is overwritten at certain periods, more on recovery models here) because you don’t need to restore to a point in time. Since you haven’t declared a transaction, why on earth is SQL Server’s transaction log growing out of control?

The answer is simple: because it cares. It doesn’t matter which recovery model you have chosen, SQL Server will always write to the transaction log. In order to maintain consistency in the database, before something is considered as having been completed it needs to be in the transaction log. It will eventually write to the physical disk but it has to be in the transaction log before your transaction is complete (see why it’s so important to put your transaction log on a separate drive and great IO??). If something were being written to the physical .mdf file but not complete when someone pulls the power plug from your server, we have a reasonable expectation of SQL to come back up in a consistent state. This is called recovery. Any transactions that are marked as committed in the log file are essentially rolled forward to the data files. Any that were not done but started are rolled back.

The recovery models just tell SQL how some operations get logged and when that log file is marked for reuse. In FULL recovery mode, it is not reusable until you do your log backup. In Simple recovery mode it is reusable once the data is written to the physical disk and no longer needed in the log, essentially.

The consistency and recovery means something to us when combined with the default mode that SQL operates in:

• Every statement is a transaction whether you tell SQL it is or isn’t. This is a great thing for us and our data quality.

So if you think about that statement, it makes sense that one big update or delete statement would cause your log file to grow “out of control” (it’s actually very much in control, just not your expected results ).

Try and think about different methods for handling what you are doing:

• Can you batch your work into smaller units? Issuing several updates,inserts or deletes dealing with a smaller amount of rows each time can help manage log growth. (The log will only be reused only to the point of the longest running transaction, if you have one big query it’s all one transaction).
• When deleting, are you deleting most of the rows? Maybe consider doing a truncate and recreate/repopulate of the table if the rows remaining after the delete will be less than those deleted.
• Consider changing recovery models – Going to Simple or Bulk Logged recovery mode won’t help you if it is all one being done in one operation. It will potentially help the reuse if you batch it out into manageable chunks. If you change your recovery mode, look it up on books online, you will most likely have to perform a full backup to keep your log chain intact and maintain restorability!
• Staying in Full Recovery mode? Perform frequent log backups. Again this won’t help you with the growth of your transaction log during one large operation but it does help with multiple batches.
• Look at using SSIS for ETL work, various options within SSIS can help manage this better and do your loads in a more efficient manner.

While I have your attention –

I mentioned above one good reason to have your transaction log separate. This falls into the “widespread news” category but it’s my experience it isn’t so widely followed. Separate your transaction logs onto a separate drive when you can! Log write performance is incredibly important. If you are going to do RAID at all on it, do RAID 10 or RAID 1 as performance is important (hence no RAID 5) and redundancy is important (hence no RAID 0- striping only).

While we are at it do you put your log backups (are you taking any???) on a separate drive also? If not, what happens if your log file drive crashes and you want to restore a log file backup? Oops.. Separate (Physically, not partitions on the same drive) your usage of drives. Yes budgets come into play but there are some basics you should try and follow where possible…

Find All SQL Server Instances On Your Network!

It’s been awhile since a tool has given me that giddy, starstruck feeling but it’s happened this week… If you ever struggle with instance discovery and management, I hope you get excited and try this tool out as well. Bear with me as I walk through it.

If you are like me, you have racked your brain for ways to find all of your SQL Server instances on the network. Maybe you didn’t get a chance to be involved in the vendor selection process and ask these questions but you are responsible for all instances known and unknown. Maybe you have to do an enterprise license true up? No matter the reason one of the biggest pains to this DBA is trying to find your SQL Server instances. There are ways to do it with SQLCMD or OSQL but they don’t catch nearly half of the instances because of network/UDP/security/etc issues. There are command line scripts you can write that use DMO or SMO to enumerate SQL Instances but they still miss some.

Well this past week I was at the Waltham, MA Microsoft Technology Center and I whined about this to Rob Walters (Co-Author on two great books about SQL Server 2005 and SQL Server 2008) and Rich Crane (Co-Author of this WCF book and general MTC guru). The reply was “MAP, you need to see MAP”. I hadn’t seen MAP yet and when I saw it, it was love at first sight. (Seriously)

MAP?

“Microsoft Assessment and Planning Toolkit” is a tool suite that Microsoft has developed for various purposes. One of those purposes appears to be helping give suggestions on upgrading your environment (it’s a free tool so it has to have some mutual value, right?). You can see all about it at the MAP site here.

I have only played with this tool as it relates to SQL Server and I am sure it offers more value in other ways but let’s just talk about what it does for SQL Server. That’s the part that caught my eye.

Basically this tool can connect to machines either you specify specifically, exist on an IP range you specify or exist within an Active Directory domain you specify and have Admin privileges on. The SQL Server Accelerator will interrogate these machines and through low impact WMI queries ask if SQL (or related SQL components) is installed. It will then report back a lot of great information that can really help you out.

Best of all? It formats this data in an Excel Spreadsheet giving you the following pieces of information:

• Computer Name
• Instance Name
• SQL Product Name
• SQL Version Number
• SQL Service Pack level (from the version number)
• SQL Server Edition (Developer, Standard, Express, etc)
• Clustered yes/no flag
• Physical or Virtual Machine indicator
• What sub-directory that instance is in (MSSQL.1/MSSQL.2/etc)
• SQL Server State (Running/Stopped)
• SQL Server Service start mode
• O/S and Service Pack info
• 64/32 Bit flag
• How many processors/cores/logical processors
• CPU brand/model number/speed/etc
• Memory
• Drive letters with total and current free space
• And other useful information

So you can kick this off to go through your AD, have a Domain Admin login to the utility (it does not remember credentials and it is very light impact, simple WMI queries after simple AD “walking”), let it run (it can take awhile as it has to wait for a WMI/network timeout for each machine) and eventually get a spreadsheet with all of your SQL Server information! You can then import that to a database, write code to interrogate it, plug it into a powershell auditing script to check all servers for policies, etc. etc. This is a HUGE tool in a DBAs toolkit and I am very excited about it.

There is a second tab on the spreadsheet listing similar information about other components found like Analysis, Reporting and Integration services.

Okay, what’s the catch, how tough is it to use?

No catch. One of the deliveries is also a word document that summarizes information about your environment, gives some pretty charts showing what editions and versions you are on. If you are not on SQL 2008 across the board it has a good executive summary telling you why you should upgrade. That isn’t really a catch, it’s half market-ware but half useful. If you want to have some information to give to management about why to upgrade, this document is your friend.

As for the ease of use.. Nothing to it really. Bear with me and my screenshots as we walk through the use of it. You can download the tool at the home site for the toolkit. This installer will install SQL Server 2008 Express Edition (instance gets called MAPS. Rob tells me if you already have an instance called MAPS, it won’t recreate it and will just put the database onto that instance)

Once the install is done you get presented with a simple UI:

From here you create a database to use for the storage of the data. Simply Create a database and give it whatever name makes sense for you. I called mine MAP_Test:

Once the database is created you then go back to that dialog and from the middle pane, select the “Identify SQL Server instances to upgrade to SQL Server 2008″ option. We get a new dialog box confirming the reports/proposals you want the tool to review:

Verify SQL Server assessment is checked and click Next. This next dialog box is where you can choose your connection options. For a quick test, I chose “Manually enter computer names and credentials”. This allowed me to go to a computer I was already local admin on and enumerate all installed SQL Instances. This weekend I will be letting this tool run with a Domain Admin typing their credentials (again it’s not saving them, I verified this when playing in the MTC lab). You can also specify another method that works best for your environment.

Once you click next you will be greeted by a screen that allows you to specify authentication informatio and specific machine information if you selected to look at one server. Your account will need to have admin privs on the machine(s) being checked. I am doing it as a domain admin this weekend to hopefully find all cases of “Rogue” instances that I should be enforcing policy against or at least should know about.

Once you supply your credentials, click finish and the collection begins. The dialog box below describes the status. Beware, this can take a long time depending on how many machines it needs to check. Try it with one machine and get a feel for the report and delays. I noticed no degradation to the machines I was checking as the footprint is low. As always use caution,  understanding and testing when doing anything to your production environment as I post in my empirical evidence post. Test it, get familiar with it and be wooed by the report!

Once this is done the cancel will turn into a close and the status should indicate success/failure counts.

Now Comes the exciting part!

Two things were saved to your Documents\MAP\Map_Test (or whatever you called your database) folder. an Excel Spreadsheet and a Word Document.

The Word document is cool. It shows pretty graphs and tables that upper level management likes to see. It tells you to upgrade to 2008 and why you should. Marketing helped with this document.

The Excel Workbook is where it’s at. The first worksheet is a summary showing you counts of what was found and what couldn’t be found because of WMI issues or insufficient data. The other tabs are the instances found with the list of information from above and the same type of information about non database-engine components found.

Using this Info

As I said above, the possibilities of what to do with this data are limitless. Some things that pop into my head right away:

• Next Enterprise True-Up - When we have to do a true-up, no more getting caught having to compile data from multiple places. Get your latest excel from the MAP tool and you already have all of the information.
• Policy Based Management – I am one of one DBA, there are a lot more instances than me. I am still new here and going through server by server checking things is tedious. Now I can use pre-defined policies and custom policies, table drive or powershell drive the evaluation of policies and have a list of all non-compliant SQL Server 2000, 2005 or 2008 instances in my enterprise. Talk about a force multiplier!
• Service Pack Roll Outs – Do we have any RTM 2005 instances? I don’t know let me query the data that I imported from my MAP spreadsheet.
• Planning Decisions – So you are going to buy your monitoring tool, how many instances do you have anyway? How many are worth monitoring? (trick question, I think even dev/QA should have some level of monitoring.. maybe not your enterprise tool but blocked developers are just as bad as blocked users, if not more expensive)
• Etc – Really anywhere you need a list of your instances that is searchable and importable (Registering servers in management studio?) this tool can greatly help you.

Check it out, it’s free to download and free to use. Maybe I have something wrong with me but this genuinely excited me and makes me a happy camper. It even finds your clustered and named instances with success every time I have tried it!

You Might Also Like

If you enjoyed learning about this free method of identifying your SQL Server Instances, perhaps this content may also be of interest:

• Benchmarking, Who Needs It? We talk about a great free project on codeplex that allows you to get pretty graphs and reports from perfmon. This tool takes the numbers from performance monitor counters, prettifies them and gives a red/green/yellow indicator of status with helpful descriptions for you or your manager.
• Where do I start?! Tips and tricks for the SQL Server DBA just starting out in a new environment.

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.

This is part 2 in a series on Shrinking “Best Practices” and logging. Click here for part 3. You can see them all in the Shrinking & Transactions category.

A while back I posted about not touching the shrink button. I am still finding it fun to see what search queries bring traffic to my blog so I look at the search query log every once in awhile. That shrink post is coming up the most in searches which leads me to believe I should add a few more points.

As I said in that post there are some great comments on shrinking over at Paul Randal’s blog. I suggest you definitely take a visit there, in fact if you had to stop reading and go to his blog, I wouldn’t be offended in the least.

Let’s talk about some of the more common questions that I see or infer from the web searches…

My Transaction Log Has Grown Too Much or My Transaction Log is Out of Space

If you have come here because your transaction log is growing out of control there is a strong chance that you are in Full Recovery mode and are not backing up your log file on a regular basis. Your transaction log continues to grow until you explicitly backup that log (a full backup won’t do). This is the expected behavior since Full Recovery mode means you want the ability to backup to a point in time and as long as your backup is someplace safe minimize your losses to the frequency of your backups.

Solutions:

1.) Setup a log backup schedule that meets your business needs. Search books online and understand recovery models, figure out the SLAs you are supposed to be supporting (do it before it’s too late since you are here reading this and Mr. Murphy likes to attack in these kinds of situations). Once you figure that out get your logs backing up on that schedule. Make sure they are going to a drive other than your mdf/ldf files so they are useful in the event of a failure. Perhaps even to tape directly or after a copy. You should see your log files become more manageable size-wise, hopefully.

2.) Get more space. Maybe you are doing Log backups but you still don’t have enough space. Either your activity is quite high or your allocated space is quite low. If it’s the former maybe a more frequent log backup helps. If it’s the latter or former, more space for your log files may be required.

3.) Switch to Simple Recovery Mode. This is not to be done lightly. You are no longer able to restore to a point in time but can only restore to the last full backup. Maybe that is fine by your SLA. If it is and you have no desire to restore to a point in time, switch to simple. Your log file will now truncate (see below) on certain intervals.

4.) While you are adding that space or setting up your backup look at your growth ratio? Is it the default 10% for a transaction log? How large is your log file? Is 10% really the right amount you want to see it growing by? On that same note has your log file grown a lot larger than it need be because of poor management? Perhaps once you do your first T-Log backup, you should look at setting a reasonable size knowing that it will be truncated on a regular basis. If that is considerably smaller than where you are, maybe one last shrink of the log file is warranted. (Don’t shrink the database! Just the file. Here sis a good reference on DBCC SHRINKFILE so you can see how to just shrink that one file).

What is the Difference Between Truncate and Shrink?

A lot of people get confused. They have truncated their log file yet they still have no free space and the file hasn’t reduced it’s footprint at all. This is because a truncation does nothing to the physical size of the allocated file on the OS. A shrink operation shrinks space from a file and a truncate essentially frees up the used space within that file.

This is why a shrink on a log file that is using all of the space won’t budge the size and why a truncate of a log file won’t budge the size. A truncate would have to happen first to make room available for the shrink to work. I do NOT suggest this, however. Another great post about why not to srink your log file is done by Tibor Karaszi here.

Someone on the newsgroups told me to…

A large portion of the folks responding to questions in the newsgroups and forums are giving great advice. They are taking their own time to help guide you down the right path. That being said, there are at times pieces of bad advice that hopefully aren’t followed in production. I talked about this practice of doing before trying in an earlier post. Gail Shaw also recently posted about this same topic on her blog.

Judging by some of the searches I have seen, it looks like people are getting some bad advice but at least trying to verify it through google (I would hope the next step is understanding the pieces involved and a test in dev/test/sandbox). A couple examples of that advice and my responses:

Stop SQL, or deatch the DB and delete the log file – No. This will most assuredly remove any transactions in your log, can leave your DB in a transactionally inconsistent state meaning a potential for loss of data or worse. If you are stuck without space for further growths, try the log backup, if you must do one last truncate and shrink after making a full backup and heeding the warning to get a real recovery strategy in place.

Setup a nightly job to issue BACKUP LOG WITH TRUNCATE_ONLY – I hopefully don’t need to say much more about this one that I didn’t say here or in my previous shrink post.

If any of this isn’t clear or you are stuck with an uncomfortable situation, send me an e-mail or leave a comment, recovery is important and I hate to see people messing this up because of bad advice or misunderstanding. I won’t charge you for any time for quick help with something like this.

This should be my last post on shrinking

A while back a conversation on Jonathan Kehayias’ former blog (he has moved) gave me an idea for this post.

Once you have been a DBA for any length of time, you will encounter the situation of a new vendor coming in with software that has a database back end. Wherever I am working or helping, I like to interject the idea of “DBA Input” as early into the process as possible and I go through a discussion with them.

The Interview

I think of this as a job interview. You want an ideal candidate and you want the candidate to know about your expectations.

These are the questions I ask in initial conference calls or meetings with technical pre-sales or installation staff. They guide other conversations and help me better support the internal customer requesting this application.

1. Which version(s) of SQL Server do you support?
   1. How do you test service packs/CUs?
   2. How many customers do you have on the setup we are planning to go with?
   3. How quickly do you normally certify for a newer version or service pack?
2. Based on what you know about our expected usage can you tell me:
   1. What should I expect to see for performance characteristics? (I/O, Mem, CPU utilization)
   2. Will your app live in a shared instance that looks like x
   3. What sort of performance issues have your support folks commonly dealt with in similar environments?
3. Does your application support a named instance? (sounds stupid but it isn’t.. ask any question)
4. Does your application support and is it certified to communicate with a SQL Cluster? (again may sound stupid when you think about clustering and SQL with an instance only active on one node anyway)
5. Can you explain your architecture? Looking for discussion about:
   1. Data Access methods – are they developing with performance in mind, are they using modern technology… Will you get hammered with a bunch of sp_cursorfetch statements?
   2. You may be “just” the DBA but we all know the DB gets blamed first Understand how they connect, if you are making the back end Highly Available, how is everything above the DB going to be HA?
6. Can you share with me all of the recommended best practices your installation and support folks suggest for database maintenance?
7. For an application of this category and usage, here is our general backup/recovery strategy. Do you have any issues with that? (Are there distributed transactions that need to have coordinated backup? Do they have issues with backup methods you use? Does the DB backup need to coincide with some XML file someplace?)
8. Does your support have any processes that involve recycling the SQL instance? If so, is this mandatory? Why?
9. Do you have any reference sites we can talk to? If the app is large enough, try and get a customer of similar scenario. Talk to their IT staff, talk to a DBA there. Maybe overboard but can be helpful if conditions warrant.
10. Security!!! I saved my favorite for last.
    1. Windows authentication or SQL Authentication?
    2. What, if any, fixed server roles do you require?
       1. Is that just for the duration of the installation or the life of the app?
       2. Why so elevated? What happens if we trim that down? (Presuming they answer with SA or something )
    3. How do your users authenticate? (Does each user need a SQL login, do they need to belong to an AD group which has SQL login rights? or is it an app pool with the app handling security with tables in the database?)
    4. What type of access does your support team need? (important if a shared instance or you are a paranoid careful DBA)
    5. Out of curiosity, what database rights do your database user accounts have? (I hate hearing DBO, presuming I haven’t heard SA… I LOVE hearing they create a role with the minimum necessary permissions… Not the end of the world if DBO, only hurts their database but still…)

The list is not always covered verbatim but I bring it with me to help drive a conversation flow and get to the important items that I want to know about. I’ve been burned by not asking and not getting myself involved. If you pick up nothing else from this post: get involved as early as possible.

You’ll be surprised what you learn. I was working with a building security system once. Got to security and the answer was basically that they normally like to be on their own database server, and they generally use SA with a blank password. I was floored… I said to the install team from the vendor, “you guys are in security?!?” We went with them but I worked with them to find out what permissions they truly needed, gave them those, backed them down even further after DB was created and they live happily to this day as far as I know.

What do you ask? How have you been burned by not asking? What’s your funniest/saddest experience with vendor software?

Reading a blog this week, I learned quite a few new tips and tricks about SQL Server Management Studio. Incremental Serach (No annoying search window pop-up and searches as you type), replace within files from SSMS!!, Block Selects and Moves for the T-SQL Code formatting OCDers (like me). Check it out and add Aaron to your blog list. Excellent material. http://thehobt.blogspot.com/2009/01/lesser-known-features-of-sql-server_08.html