1. The organizers might know my name or may know of my books or the fact that I’m working for a vendor that sponsors their event
2. I’ve submitted sessions that seem to be of interest to the people who might be attending the event being organized
3. I’ve got a track record of delivering decent, if not world-altering, presentations that people find useful.

Let’s say you’re organizing a SQL Saturday event. And, let’s say that you want to get as many attendees as you possibly can. Is your best bet to find a bunch of people with MVP or MCM after their name? Or, should you focus on getting an interesting set of content from speakers that you know can deliver?

From what I’ve seen, it’s that second option that is your best bet. I’ve stood in front of people and started talking about a topic that I have a written a book about only to find that the entire room was not aware that I had written that book. They weren’t there for me. They were there for knowledge that I might be able to communicate to them. They were there for the topic, not the speaker. I’ve seen local speakers give presentations that were simply amazing, despite the fact that they didn’t have a book or weren’t blogging constantly. It’s the content and delivery, not the person delivering it. You’re going to know your local speakers as well as, or better than, any of the MVPs. Rely on your knowledge of these people and the fact that you’ve seen them present before.

This is something that I think way too many people overlook. Especially when you’re managing a SQL Saturday event, you need to build an interesting set of topics, not lure a bunch of MVPs to your event. Guaranteed, you’ll get an MVP or three. Don’t focus on that or worry about it. Instead, focus on your agenda. Build a good set of presentations, the kind that are going to be the most useful to your audience.

Don’t believe me? Check out these links to the front page of the PASS Summit 2011, 2010, 2009. Note a couple of things. First, no headliners at all. No speakers are called out in any way except the people delivering the key notes. Second, there are Flickr & Twitter streams in which anyone can be one the front page for a time. In short, the focus is on content and attendees.

Remember this when you’re setting up your event.

Oh, and don’t bother linking to this post. Everyone has my permission to copy and paste this and claim it as their own. You just have to include this disclaimer for everyone else to copy and paste this post as well.

I was asked, what happens when you run ‘SELECT *’ against a clustered index, a non-clustered index, and a columnstore index. The answer is somewhat dependent on whether or not you have a WHERE clause and whether or not the indexes are selective (well, the clustered & non-clustered indexes, columnstore is a little different).

Let’s start with the simplest:

SELECT    *
  FROM    Production.ProductListPriceHistory AS plph;

This query results in a clustered index scan and 5 logical reads. To do the same thing with a non-clustered index… well, we’ll have to cheat and it’ll look silly, but let’s be fair. Here’s my new index:

CREATE NONCLUSTERED INDEX TestIndex
  ON Production.ProductListPriceHistory
(ProductID,StartDate,EndDate,ListPrice,ModifiedDate);

When I rerun the query it results in an index scan, non-clustered, with 5 logical reads. Granted, this is stupid. Instead, let’s do this. We’ll create a meaningful non-clustered index and then force it’s use:

CREATE NONCLUSTERED INDEX TestIndex
  ON Production.ProductListPriceHistory
(ListPrice);

Then run this:

SELECT    *
  FROM    Production.ProductListPriceHistory AS plph
WITH (INDEX(TestIndex));

Now that’s using a non-clustered index in a ‘SELECT *’ situation. It results in 794 logical reads and this execution plan:

Clearly, this is not an improvement. Finally, let’s get rid of the non-clustered index and put this columnstore index in place:

CREATE NONCLUSTERED columnstore INDEX xtest
  ON production.ProductListPriceHistory
(productid,startdate,enddate,listprice,modifieddate);
GO

Now when I run the ‘SELECT *’ query I have 37 reads and this execution plan:

This means the columnstore index is being used, but, if you look at the properties, you’ll see that the execution mode on this one is Rows, which is not the preferred use you’ll want out of a columnstore index. You want to see the execution mode be Batch.

If we stopped here, the answer is simple, a clustered index scan is better. But what if we add filtering? Let’s modify the query to look like this:

SELECT    *
  FROM    Production.ProductListPriceHistory AS plph
WHERE    plph.ListPrice = 23.5481;

Now, I’ll go back and set up the table so that it has just the clustered index, a non-clustered index, or the columnstore index. The results for the clustered index are identical. Since the column, ListPrice, is not part of the clustered key, a scan is necessary and the results are 5 reads and an execution time of about 1ms (the data is cached). The non-clustered index resulted in the same execution plan as before, but only 8 reads. But, the execution time was 42ms, so the added processing of getting the data put together from the key lookup was a little costly. Finally, the columnstore index results in 42 reads and an execution time of 4ms. The execution mode of the columnstore index was still Row.

What’s all this mean? Not much since you shouldn’t be using ‘SELECT *’ anyway, but the main takeaway I’d suggest is that columnstore indexes are not magic. They don’t replace traditional indexing. Further, if you’re going to use them, be sure that you’re really using them correctly. Just because you see the columnstore operator in the execution plan doesn’t mean you’re taking advantage of all the fantastic benefits they offer. Dive down into the properties and check the execution mode to ensure you’re getting a Batch execution. Then you’ll know that you’re benefiting from the columnstore index.

ALTER DATABASE Testing SET DB_CHAINING OFF;
GO

CREATE PROCEDURE x
AS
    SELECT    *
    FROM    test.dbo.A AS a2;
GO

CREATE PROCEDURE y
AS
    SELECT    *
    FROM    dbo.Table_1 AS t;
GO

EXEC dbo.x;

EXEC dbo.y;

SELECT    deqs.creation_time
FROM    sys.dm_exec_query_stats AS deqs
        CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE    dest.text LIKE 'CREATE PROCEDURE x%'
        OR dest.text LIKE 'CREATE PROCEDURE y%';

ALTER DATABASE Testing SET DB_CHAINING ON;

SELECT    deqs.creation_time
FROM    sys.dm_exec_query_stats AS deqs
        CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE    dest.text LIKE 'CREATE PROCEDURE x%'
        OR dest.text LIKE 'CREATE PROCEDURE y%';

ALTER DATABASE Testing SET DB_CHAINING OFF;

The script is almost self-explanatory. I want to point out that I put in one cross-database query to imply the possibility of cross-database ownership or access, but also to show that regardless of what’s referenced, all queries from this database are flushed from cache.

The first of the simple DMO queries returns two rows, the second returns no rows because everything is out of the cache because of the change to the database. It’s a little thing, but since it wasn’t explicitly stated in the Microsoft documentation, I thought I’d toss this out there.

This blog post has been percolating in my mind for quite some time, but a few new stories have brought it to the fore. The most recent was when I heard that, in front of multiple other male MVPs, a female peer was propositioned using language that I wouldn’t condone when speaking to an animal, let alone a peer. And that’s the point, these women are peers. Yes, they happen to be female, but more importantly, they’re our peers.

And you know who I’m most upset with? No, not the individual who acted like a jerk. There’s always a few of those around. No, I’m upset with the MVPs who were present when it occurred and did nothing. Said nothing. Did nothing! Simple question for you lot. Are you men, or are you boys? If you’re men, you don’t let other men talk to your peers that way. Ever. It’s not acceptable. It’s not polite. Most importantly, it’s not professional. If you’re boys, please go home until you’ve decided to grow up.

I get it. We’re all consenting adults (except the boys, who have left) and we all have different levels of tolerance for different types of behavior. I know I’ve personally crossed lines that upset others and I’ve been called out on it (by men, and professionals, acting as such). Sooner or later everyone is going to cross a line somewhere. It happens. What I would expect is that we will stand up, like men, like professionals, and hold that person accountable for their actions. Then that person can adjust their behavior appropriately, issuing apologies as needed. And women aren’t gentle flowers that need protecting. Far from it. However, they are peers. They are our equals (probably, based on behaviors noted, superior to some of you). They should absolutely be treated like it.

I also understand that we’re going to be in places where alcohol may be consumed, and to excess (guilty again). This lowers inhibitions and changes behaviors. Once more, we’re all adults and if you don’t want to be around this behavior, don’t go. But once more, it’s entirely possible to go through your alcohol consumption without turning into a raging jerk. And, if someone turns into a raging jerk, the rest of us have to be ready to intervene when it’s clear it’s necessary. In the case I mention, and in others I’ve heard about, it was necessary.

And yeah, we may go to places intentionally to let our hair down in less than appropriate ways (once more, guilty). Usually these are very clearly marked and announced so you can’t go into them expecting a church social. It won’t be. But, you also can’t go into them acting like a raging jerk.

I was discussing this with others, because of other similar stories that came up, and we decided that the simplest way to explain this is using the Wheaton Law (possibly NSFW), which I had to look up. It’s very similar to the Golden Rule (and yeah, that’s Wikipedia, cope), which I already knew. But I’ve supplied links to both so you can figure it out in case either of these is new to you. I mean come on guys, just because you’re away from your wives and you’re around fun, intelligent, beautiful women (of which we have more than our share in the SQL Server Community) doesn’t mean you start propositioning anything that moves. And if you really must do this, do it with some class and understand that when the lady says no, it ends that line of pursuit.

And don’t think this has gone unnoticed. I’m using the one general scenario because it was pointed out to me that MVPs are evidently not capable of policing themselves. If we don’t do it, it will be done for us and not in ways that any of us are going to appreciate.

I realize this is likely to be an unpopular post. I really don’t care. I’m more than a little ashamed to be associated with people who act that way towards women. Sorry. Don’t like it. Can’t abide it. Something must be said before things have to be done. I actually can’t believe I’ve had to write this down, but I’ve heard too many of these stories to stand quietly by any longer.

Let me reiterate. I’m not saying this because I think women are wilting flowers that need protection. Far from it. I know a few of the ladies from the SQL Family that will remove your family jewels and show you the side of them that you’ve never seen before. It’s not that I think they need protection, no. It’s that I think they shouldn’t have to put up with the jerky behavior. It’s that simple.

Jerks, you’re on notice. There are men, professional men, out there and they’re going to call you out on your behavior. Clean it up now. Guys, don’t let these jerks define us, ever.

To boil the questions down to as simple a single statement as possible:

Should your database be in FULL recovery mode at all times which requires you to run log backups on a regular schedule?

The same question came up while Brad McGehee(blog|twitter) was presenting a session on using the settings on your SQL Server instance and your database to ensure you got proper performance. We both answered the question the same way, but our emphasis was slightly different.

Brad’s answer was that, yes, you should, by default, set your databases to FULL recovery in order to plan for the possibility of a point in time recovery. I agree with him.

But, my answer was different. What I said was, you need make a choice here. Yes, you should have your production databases in FULL recovery in order to arrive at the best possible recovery process. However, that means you’re dedicating yourself to maintaining log backups. If, for whatever reason, you can’t maintain log backups, then you should set your recovery to SIMPLE.

My point was not to disagree with Brad, or, more accurately, I don’t think he disagreed with me (since he went on 2nd). Rather, I’m trying to tell you that you must make that choice. You need to either commit to the process of setting up an appropriate recovery process for your production systems, which, in the majority of circumstances should include log backups, or, you need to admit that you can only recover your databases to the last FULL or DIFFERENTIAL backup and make that part of your documented plan, setting your databases to SIMPLE. What you can’t do, at least not any more since SQL Server 2008 was released, is rely on BACKUP LOG WITH NO_LOG or WITH TRUNCATE_ONLY as a means for leaving your database in FULL recovery, but also throwing away the log data (and I’ve never understood why people do that except through ignorance of how Log backups & recovery works).

Now, you have to commit. I believe you should set up the Log backups, but if you don’t, fine, turn off FULL recovery. Just do so with the complete knowledge of what that means.

It appears as if the cost of the UDF is free. This is especially true if you use the UDF in a query with other objects, such as joining it to actual tables. Since the optimizer always assumes a multi-statement UDF has a single row for statistics estimates, it’ frequently displays a low cost.

But you know that there’s more going on there, right? It’s a multi-statement UDF because it’s doing a lot of work, but that is not reflected in the execution plan.. or is it?

What if we went after the cache? Let’s run this little query:

SELECT  deqp.query_plan,
dest.text,
SUBSTRING(dest.text, (deqs.statement_start_offset / 2) + 1,
(deqs.statement_end_offset – deqs.statement_start_offset)
/ 2 + 1) AS actualstatement
FROM    sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE   deqp.objectid = OBJECT_ID(‘dbo.ufnGetContactInformation’);

This query doesn’t do anything really fancy. I’m using the sys.dm_exec_query_stats which holds aggregated performance metrics for any query currently in cache because it has the plan_handle that lets me look up execution plans in sys.dm_exec_query_plan. It just so happens that you also get the objectid there in the plan so we can look for the specific plan that corresponds to our UDF (I’m using an example from AdventureWorks2008R2). The results from the query look like this:

Each row represents a statement that has been executed from the UDF. There’s just a single plan for the UDF, and it looks like this:

Without even drilling down to all the details of what’s going on in the plan, I think we can agree, that this UDF is not zero cost, but may in fact be extremely expensive depending on what’s going on inside that execution plan.

Why is this useful? Because it lets you look behind that simplistic… lie, that is shown as a plan for the execution of a UDF to see what the UDF is actually doing. This may make it possible to improve the performance of the UDF since you’ll be able to identify missing indexes and other information thanks to your direct access to what’s going on inside the UDF.

I had demoed this during my 24 Hours of PASS presentation and was asked to put the code up on my blog, so here you go. I hope it’ proves helpful.

Encrypted data compresses significantly less than equivalent unencrypted data. If TDE is used to encrypt a database, backup compression will not be able to significantly compress the backup storage. Therefore, using TDE and backup compression together is not recommended.

I took that completely at face value and always figured it meant I would only get 5-10% compression or something instead of the higher rates available through backup compression (or the much, much higher rates available through 3rd party compression). Imagine my surprise when I tested this on a 20gb database. Not only did I get no compression, as in zero, but the size of the backup went up slightly.

So, when you go to enable TDE, think about what this means for your backup storage. If you’re counting on compression, you might be in trouble.

I hit a situation where it didn’t work correctly, so I thought I’d share it in case others ran into it.

The setup is straight forward. I have network, contoso (yes, I’m using Microsoft training & documentation, it’s a beta, but you should see it available soon), with a domain controller and five servers all in a failover cluster. They passed the cluster test, so all five are hooked in. I went to use the Availability Group Wizard to set things up. I chose a database with a  full backup in Full Recovery mode. I added a second server to act as the secondary in the Failover Group. I chose a share where the backup was kept and was accessible to the other server (I even checked this). Then I ran the validations:

Which came back all green except for the warning about the listener configuration (which, you don’t need to set up an Availability Group, just to access one from an app, seemlessly).

I checked the summary and then built my group, which took WAY too long, and was presented with this:

What the heck? So I took a look at the error:

Connection not active? Yes it sure is. I went round and round through this. Seriously. First, I found out I had a database in 2008R2 compatibility mode (and how funny is that to be saying at last). Fixed it. No joy. Took a new backup (dummy). No joy. Revalidated every possible check from this server. Nothing.

In desperation I went to another server and tried setting up AlwaysOn between it and a neighbor. It worked… What. The. ****?

Then, I went back and reread the error message (always a good thing). “The CONNNECTION to the primary replica is not active” Well, that’s how I read it the second time. So I tried connecting to the primary from the secondary, just through SSMS. No connection. I went back to the primary & double-checked, yes, it could connect to all four of it’s brother & sister servers. Checked each of them for connectivity back… nothing. I had a network problem that I didn’t realize was there.

So, moral of the story, just because you’ve run the tests that MS provides for AlwaysOn doesn’t mean you won’t run into an issue.

Southern New England SQL Server Users Group, East Greenwich,RI – 3/14/2012:
TSQL Deployment and Continuous Integration Best Practices

SQL Saturday 120, Orange County – 3/24/2012:
I’m presenting two times here. They’re both presentations that I’m working up for Connections.
Common Backup Problems and How To Deal With Them
TSQL Deployment and Continuous Integration Best Practices

SQL Connections:Las Vegas 3/26 – 3/29/2012:
I get it. You don’t go to Vegas to network. That doesn’t mean you can’t still do that too. I’m presenting three sessions.
Top Tips for Writing Better TSQL
Common Backup Problems and How To Deal With Them
TSQL Deployment and Continuous Integration Best Practices

New England SQL Server Users Group – 4/12/2012:
Common Backup Problems and How To Deal With Them

SQL Saturday 111, Atlanta – 4/14/2012:
Execution Plans, a Deep Dive
Common Backup Problems and How to Deal With Them

In addition to these networking opportunities, I’m also speaking online at:

SQL Lunch UK – 3/13/2012:
Deadlocks, How to Identify Them and What to Do About Them

24 Hours Of PASS – 3/24/2012:
What to Look For in SQL Server 2012 Execution Plans

I’ve got more stuff coming in May, June and July (including SQL in the City) and I’ll post that as we get closer.

Seriously, please, let’s talk.