I try to watch the search phrases that point people to the blog because sometimes, you get a sense of what problems people are running into. The latest question or phrase I've seen a lot lately is along the lines of "how do you know if an execution plan is being reused." Since compiling an execution plan can be an extremely expensive operation, it's worth your time to understand how well a given plan is getting reused. If you've seen me present, I'll frequently talk about the application that had a query with an 86 table join. Recompiles on that thing were frequent and extremely costly. The only good news was, they were recompiles. If we weren't getting plan reuse it would have been an even worse system than it was. There are…
Not everyone has the opportunity to call Microsoft Premier Support. For those who have not yet had this experience, I'll document my most recent, non-critical, call. Critical calls are a different critter entirely. We were experiencing a very odd error on one server in our system. When a particular procedure was run with a particularly large set of data, it would produce an error, but only when called from the application. The exact same error with exactly the same data called from SSMS did not produce an error. We went through a very extensive set of tests and were unable to fix the problem on the server. After moving the production system that was experiencing the issue to a different server, we decided to contact PSS. 8:48 Am, Tuesday: I made the…
I keep seeing these concepts that have long been disproven, posted again and again on newsgroups as if they were valid information. The latest? Table variables are better because they're only in memory where as temporary tables write to the disk through tempdb. This one is abjectly wrong. I'm not even going to hedge with "it depends." From a macro point of view, there are only a few differences between temporary tables and table variables, statistics being the biggest. Temporary tables have 'em and table variables don't. Other than that, both will reside completely in memory or will swap out to the disk through tempdb, depending on their size. Some of the minor differences, and why you might want to use table variables over temporary tables, table variables won't cause a statement recompile while temporary tables will, table…
There's a very common belief among DBA's: Stored procedures are pre-compiled. I had someone tell me all about it just last week. There are lots of sources that say what I'm getting ready to say, so this really shouldn't come as news to anyone,but it will. No, they're not. Stored procedures are not pre-compiled. When you create or update a stored procedure on the server, it gets a syntax check. But there is no compile process, let alone a pre-compile process. That stored procedure exists exactly as it is named, a procedure that is stored on the server. It's just a collection of TSQL code, possibly with some parameters, waiting to be called. Until it's called, it is not ready to be executed. Don't believe me? I'm not a huge…
I keep thinking I've got a handle on the way execution plans are dealt with in SQL Server. I had a pretty simplistic view of things, there's the estimated plan which comes out of the optimizer and there's the actual plan which comes out of the data engine. The one shows the best guess for what will happen based on the query and the underlying statistics. The other shows what actually happened based on the query and the real data, load on the server, available memory, you get the idea. This model is easy to explain and understand. Too bad it's not quite the way things work. If you query the dynamic management function sys.dm_exec_query_plan, you can see a query plan. Once you drill down on the XML, or browse…
With all the cool kids posting about beginners and interview questions, I thought I'd toss my favorites out there, from the brief-case gang point of view. These are the technical phone-screening questions I use after I look at a resume. There are only 10. They're simple. Stupid simple. Silly even. Yet, I can count on eliminating 4 out 5 people who have a resume that looks like a qualified DBA. I've seen people with 10 years experience fail on these questions. I'm only going to provide the questions. If you can't find the answers on your own, you're already disqualified: What is the difference between a clustered and non-clustered index? No, don't tell me that one is clustered and the other is not. I don't need specific low-level information on this, just…
I had previously outlined a problem with nHibernate code that, in my opinion, was going to cause a lot of problems on production systems especially with memory and the procedure cache. However, it does appear that there is a possible solution. That doesn't eliminate my concerns over nHibernate, but it sure does help.
One of our development teams created a set of queries that are receiving some rather large XML parameters for processing. Unfortunately, the developers didn't think things through entirely. They passed the same, large, XML string in to the server five times in a row. Needless to say, the performance was substandard since the XML parser had to be instantiated five times. My initial suggestion was to use a wrapper procedure to perform a single load of the XML data and then call the other 5 procedures. I further suggested to load the XML into a temporary table and use that within the other procs. Unfortunately this is all taking place within SQL Server 2000. When my initial set of recommendations was done, we had solved one problem and introduced another. We were getting serious recompiles. If…
SQL Server 2008 has been released, but the full capabilities of the product are still be discovered. This isn't a case of discovery so much as Microsoft, in the person of Bart Duncan, has shown us something new. Read the article. This is one of the most exciting things I've seen in a long time. It's especially exciting as we see databases becoming less and less manageable through the implementation of tools like nHibernate. As I noted in a previous post, nHibernate will create a lot of execution plans. With the capabilities here, we'll be able to easily and quickly aggregate some of those plans to identify the costly queries coming out of nHibernate without having to resort to 24 hour Profiler monitoring. Great stuff.
This code is not in the same order as the book. A number of edits were done to the document after it was produced. USE [AdventureWorks]; GO --Listing 1 --Select --highlight this and click "Display Estimated Plan" on tool bar, right click & select from menu, --select from the Query menu above, or type CTL-L. SELECT * FROM [dbo].[DatabaseLog]; GO --Listing 2 --SelectJoin -- click "Include Actual Excecution Plan" on tool bar, highlight and execute SELECT e.[Title] ,a.[City] ,c.[LastName] + ',' + c.[FirstName] AS EmployeeName FROM [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeAddress] ed ON e.[EmployeeID] = ed.[EmployeeID] JOIN [Person].[Address] a ON [ed].[AddressID] = [a].[AddressID] JOIN [Person].[Contact] c ON e.[ContactID] = c.[ContactID] ; --Listing 3 --SelectJoin2 SELECT e.[Title] ,a.[City] ,c.[LastName] + ',' + c.[FirstName] AS EmployeeName FROM [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeAddress] ed ON…