05Apr 2010 by Grant Fritchey 25 Comments

nHibernate, First Look at TSQL

nHibernate
I've blogged in the past about the nHibernate project that has been going on at my company for the last eighteen months. Prior to today, I have only seen the database generated by nHibernate. But today I finally started seeing some TSQL code. My first impressions... oy! There are two levels of concern coming out of the gate. First, it appears that some of the programming decisions, completely independent of nHibernate, are going to cause problems. Second, it appears we're going to be hitting issues with nHibernate. First, the programming decision. I've been using Confio to monitor this server for a few days now (look for upcoming posts on my eval of Confio). Only one day has captured any real activity from the nHibernate team (and yes, I'm basically spying on…
Read More
15Sep 2009 by Grant Fritchey 2 Comments

More Free Training

SQL Server, T-SQL
Quest Connect 2009, taking place in October 21 for 24 hours, looks like it's going to have 64 different sessions, live and recorded, by a variety of the names in the industry. It's another chance to dig in and learn the details on a variety of topics from some of the top names in the business. Can you say Tom LaRock? How about Tim Ford? I know you want to hear from Brent Ozar. Those are just some of the featured speakers. There are a whole slew of others, it's worth pursuing, and did I mention, the price is right. I recorded a session for them last night. It's on the basics of understanding execution plans.
Read More
15Sep 2009 by Grant Fritchey 30 Comments

No Join Predicate

SQL Server, T-SQL
You could be looking at an execution plan on a query and see this message: Warning, No Join Predicate. With a very few exceptions (very few), that's not a warning, like "Mind the gap" or "Your Mileage May Vary" or "Never fight a land war in Asia." No. It's a screaming shout saying "BY ALL THE GODS IN VALHALA, YOU DON'T HAVE ANY JOIN PREDICATES IN THIS QUERY!" Seriously, that's exactly what it says. But, you might be asking yourself, that's what it says, but what does it mean? Please allow me to explain. The tables in your system, whether it's a classic BI star schema, or a highly normalized OLTP system, or even (shudder) ORM objects, are related to one another. Usually they're related through the use of primary…
Read More
31Jul 2009 by Grant Fritchey 13 Comments

No really. When did this statement start?

SQL Server
I thought I had an interesting answer to the question. Unfortunately Adam Machanic, who has been working in this specific area quite a bit longer than I have, and, let's face it, is a bit smarter, pointed out (in the comments) the possibility that I didn't have this quite right. I ran all his tests and sure enough, it wasn't working the same way that I saw it work. First, I tried modifying his query so that it ran the SELECT statements from the DMV's between the operations, but this didn't change the results, start_time and last_request_start_time were the same. From a scientific stand-point, if no one can replicate your results, the experiment failed. So I went back and tried again. To be sure I got things right and wasn't, somehow,…
Read More
28Jul 2009 by Grant Fritchey 7 Comments

When did this statement start?

SQL Server, T-SQL
UPDATE: This post is incorrect. Adam nailed it in the comments. I explain my mistake here. A question came up over at SQL Server Central where someone was wondering if it was possible to know when a given statement within a batch started. Immediately I thought, oh yeah, that's easy, use the sys.dm_exec_requests dynamic management view (DMV). Done. Wrong. The original poster pointed out that I had assumed that the values present in the DMV represented statement level values, but they show the batch. While the DMV shows a start_time, that time is the start of the current batch, not the statement within the batch. Now the question was, where else might I get this data? I next tried sys.dm_exec_sessions because it has the last_request_start_time value. Sure enough this worked. Don't…
Read More
17Jul 2009 by Grant Fritchey 15 Comments

Execution Plan Compile Termination

SQL Server, T-SQL
Recently I've been seeing a lot of people with bad execution plans, desperately trying to tune them, but they were unable to explain why they had such bad plans. More often than no these were larger queries, with a number of derived tables, CTE's, CROSS APPLY, etc. In most cases the statistics appeared to be fine (this is usually checked by comparing estimated & actual rows within the operations in the execution plan) and the plans themselves didn't look crazy, but the execution plans were flat out, not good. If you're looking at a plan and it doesn't make much sense, one option that most people don't check... SQL Server didn't have enough time to complete optimization. The optimizer is a pretty amazing bit of code. The scary volume of…
Read More
26Jun 2009 by Grant Fritchey No Comments

Re-evaluating Execution Plans (again)

SQL Server, T-SQL
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…
Read More
11Jun 2009 by Grant Fritchey 2 Comments

More Spatial Headaches

Spatial Data, T-SQL
I keep thinking I've got a handle on spatial data and I keep finding out I'm wrong. I rewrote the cursor that my co-worker used into a query that joined the list of test criteria onto our list of locations. I used an OUTER APPLY to more or less run a check for each of the test criteria since, except for the proximity to the locations, there's no actual relationship between the test criteria and the location data for me to join on. The query looked something like this: SELECT a .CriteriaDesc ,a.CriteriaLoc ,l.[Location].Lat AS LocationLatitude ,l.[Location].Long AS LocationLongitude ,l.LocationDesc FROM dbo.Alert AS a OUTER APPLY (SELECT x.[Location] FROM dbo.MyLocs x WHERE x.OrgID = 42 AND x.[Location].STDistance(a.AlertLocation) < 50000) AS l The cursor was taking almost a full minute to…
Read More
09Jun 2009 by Grant Fritchey 3 Comments

Spatial Indexes and a Lack of Data

Spatial Data, T-SQL
I was feeling quite confident about my new-found abilities with spatial indexes so I did a presentation for my team, to share what I had learned. I had also been sharing with one co-worker as I developed the knowledge of spatial indexes. While I was preparing my presentation, he was preparing his. I had focused on finding a set of data that showed it's proximity to a test location and then showing how retrieving that set of data was faster because of the spatial index. He took a different approach. He took the idea of saying, here's a list of different test locations, let's see which one of our internal locations meet the proximity test. At the same time, he tried three different spatial indexes, one with high granularity, one with medium and a final…
Read More
03Jun 2009 by Grant Fritchey 2 Comments

ORDER BY Speed

T-SQL
I answered a question on SSC with the comment that while an INT would perform better than a DATETIME in an ORDER BY query, assuming each has a viable index, that the difference wouldn't be all that terribly substantial. Then I realized, maybe that's not true. So I ran up a quick test, just to see. First I created a little test table with the right indexes and loaded it with data: CREATE TABLE dbo.IntDate (IntCol INT NOT NULL, DateCol DATETIME NOT NULL); CREATE INDEX ixInt ON dbo.IntDate(IntCol); CREATE INDEX ixDate ON dbo.IntDate(DateCol); SELECT TOP 10000 IDENTITY( INT,1,1 ) AS n INTO #Tally FROM Master.dbo.SysColumns sc1, Master.dbo.SysColumns sc2; INSERT INTO dbo.IntDate ( IntCol ,DateCol) SELECT t.n, DATEADD(dd,- t.n,GETDATE() ) FROM #Tally AS t; DROP TABLE #Tally; Then I ran these…
Read More