Microsoft has been pretty clear about their commitment to the entire Azure infrastructure. The updates to Azure come out on a massively accelerated schedule. Because of this, they're doing lots of code on lots of things that may, one day, end up in your full blown SQL Server instance, but are currently only available in Windows Azure SQL Database. This is because of that accelerated schedule. It frees Microsoft developers up to experiment a little. I saw some evidence of it the other day. I had been working on a series of queries for the pre-conference seminar that I helped put on at TechEd (and one that I'm doing for the PASS Summit). When I write queries, I use SQL Prompt. Sorry to be plugging Red Gate products on the…
The very concept of the Windows Azure SQL Database (WASD) is predicated on the up-time created by having three active copies of your database. Should there be a hardware or software failure that would cause the primary replica to go down, your database gets moved to one of the secondary replicas which has been maintaining a copy of the data from the primary replica. In theory, the worst thing that happens is that you have to retry a query. In fact, building that sort of resilience into your code is a pretty fundamental aspect of working with WASD. I was asked the question, how do you tell if your database has been moved between replicas. I didn't have a complete answer, so I set out to find one. The first, more obvious…
I have lists. Lots of lists. I even have them in different locations sometimes. Some of them are carefully written down in my notebook, others are typed into OneNote and I've been experimenting with Remember the Milk and Trello (Trello is winning). These lists include ideas for presentations, blogs, articles. Notes from sessions I've attended or meetings. Lots and lots of plans and ideas and all that sort of stuff. I try to keep it organized, but sometimes it runs away from me. However, I find writing things down helps me to keep things organized. Between very carefully scheduling out my calendar and all these notes, I only occasionally completely drop the ball. One ball I dropped was coming up with some goals, some plans, for 2012. I just plowed…
Two quick points, I'm putting this blog together using the Surface.. ooh... and this isn't a keynote, but a spotlight session at the Summit. Still, I thought I would live blog my thoughts because I've done it for every time Dr. Dewitt has spoken at the Summit. Right off, he has a slide with a little brain character representing himself. But, we're talking PolyBase, and futures. This is basically a way to combine hadoop unstructured nosql data with structured storage within SQL Server. Mostly this is within the new Parallel Datawarehouse. But it's coming to all of SQL Server, so we need to learn this. The information ties directly back to what was presented at yesterday's keynote. HDFS is the file system. On top of that a framework for executing…
We're off and running here at the PASS Summit. New this year is live streaming all day. Bill Graziano is introducing the Summit. More importantly, he's introducing PASS. Further, he's introducing speakers to everyone. He doesn't mean just speakers at the summit, but anyone who has spoken at a SQL Saturday or a user group, and it was a scary large group of people. PASS has created a new web site to make it easier to find local Chapters. Track one down. On the one hand, it's weird that we're sitting at the PASS Summit and introducing the PASS organization, but I think they're right to do it. It's a great organization and I'm always surprised at how many people don't know about it. Bill's big announcement is the all…
This conference is new to me. In case it's new to you, I thought I'd take a moment to point it out. Mostly because I'll be presenting there and I love talking to anyone who has actually read any of the blather I post on my blog. If you want to get together in the land of sunshine in December (don't tell Mrs. Scary but I'm looking forward to this one, winter in New England is awful), then click here to register. If you do it now you save $500, so it's a good time to take care of it. I'll be presenting two different sessions. One is on backups and restores for the accidental DBA. I'll go over the important stuff to get you started protecting your company's data…
I presented a session at the SQL Saturday event in Oklahoma City last weekend. The event itself was pretty good. The organizers put everything together pretty well and the venue was quite nice. Plus, since I grew up in Oklahoma (Tulsa), it was a chance to go home. The event was good, but my presentation went a little downhill. The name of the session is "Top Tips for Better Stored Procedure Performance." I should rename it to just say "T-SQL Query Performance" because it's not focused on stored procedures, but on queries. The presentation is 1/3 talking about how you write your queries, naming syntax, formatting, etc. The second 2/3 is all about common mistakes made in writing T-SQL such as using NO_LOCK everywhere, nesting views, joining and nesting multi-statement…
Good question. I don’t have a clue. So let’s set up a test. I’ll create this stored procedure: CREATE PROCEDURE DL2e WITH ENCRYPTION AS BEGIN TRANSACTION UPDATE Purchasing.PurchaseOrderDetail SET OrderQty = 2 WHERE ProductID = 448 AND PurchaseOrderID = 1255; Then I’ll execute things in the following order. From one connection this query: UPDATE Purchasing.PurchaseOrderHeader SET Freight = Freight * 0.9 --9% discount on shipping WHERE PurchaseOrderID = 1255; From a second connection, my stored procedure: EXEC dbo.dl2e; Then, back on the first connection, this query: UPDATE Purchasing.PurchaseOrderDetail SET OrderQty = 4 WHERE ProductID = 448 AND PurchaseOrderID = 1255; That will generate a deadlock. It’s a straight-forward classic deadlock. I’m using extended events to capture the deadlock graph and the output looks like this: <deadlock> <victim-list> <victimProcess id="process472310928" />…
In a recent discussion it was suggested to me that not only is dynamic T-SQL useful for things like catch-all queries or some really hard to solve problems involving variable table lists, but is, in fact, a perfectly acceptable design pattern for all queries against a database. Note, in this case, we’re not talking about an ORM tool which takes control of the system through parameterized queries, but rather an intentional choice to build nothing but dynamic T-SQL directly on the system. To me, this was immediately problematic. I absolutely agree, you’re going to have dynamic T-SQL for some of those odd-ball catch-all search queries. But to simply expand that out to include all your queries is nuts. There really is a reason that stored procedures exist, and it’s not…
The short answer is, of course, none of them, but testing is the only way to be sure. 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…