Microsoft keeps sneaking little things under the door for Windows Azure SQL Database. This time it's a couple of new views, a system view and a Dynamic Management View (DMV); sys.resource_stats and sys.dm_operation_stats. But, I also learned another fun fact, not all this stuff rolls out at the same speed. For example, if I run sys.resource_stats on a database on a server located in the North Central US data center, the output looks like this: But, if I run the same query against the same view with a database in a data center in East Asia (I experiment with where I put things), it looks like this (click on it to expand it, probably want to do that into a second tab or window so you can refer to it…
I just did a series of Boogle searches and when that didn't find anything I tried Ging. Neither listed sys.dm_db_wait_stats. Nothing in a search directly against MSDN either. So, let me introduce you to a new DMO, sys.dm_db_wait_stats. It's a dynamic management view since it doesn't require any input. The output is about what you would expect if you thought about it for a second: In short, what we have is the sys.dm_os_wait_stats moved internally into your SQL Database so, even though you cannot get at any of the OS counters from with an a SQL Database normally. In short, thanks Microsoft. Now we can see the wait statistics on our Azure SQL Database in order to better understand where things are problematic. Without documentation I don't know for…
Greetings. Welcome once more to the Miskatonic University branch of SQL University. Does anyone know where to buy some camping equipment, cheap? I’ve been tagged to go an expedition to Antarctica and I need some cold weather gear a bit more substantial than my LL Bean boots. Evidently the last expedition found some caves in some mountains down there. Sounds like the perfect place to get away from all the crazy stuff that goes on here at Miskatonic. I mean, what could happen? Anyway, our last several talks have all been about indexes and indexing. One of the things that we haven’t talked about is how to tell if, how or when your indexes are being used. Starting with SQL Server 2005, and continuing to 2008 and R2, there has…
Nice to see most of you have managed to fight your way through the shoggoths outside to attend another lecture at the Miskatonic branch of SQL University. This will be the third and final part of the introduction to indexes lecture. Please, if you're going mad, step out into the hall. Our previous two lectures introduced the concept of indexes and then talked about two types of indexes, clustered and nonclustered. This lecture will cover the concept of statistics as they relate to indexes. If you followed the previous lecture then you know that indexes are stored in a Balanced Tree or B-Tree structure. You know that this storage mechanism is intended to provide fast retrieval of data. But, how can the query engine inside SQL Server know which index…
Since all the cool kids seem to be posting the sessions that they submitted to the PASS Summit, nerd that I am, I'll follow along and do the same. I submitted four sessions, two by invitation for a Spotlight session and two for regular sessions. I tried to branch out a bit from where I've been in the past to see if I can start talking about different topics. With that in mind, the first session was: Spatial Data: The Business Case We've all seen the cool presentations showing all the pizza joints near the conference center or all the bicycle shops on a biking route, but what's the case for spatial data and business? This session sets out to show how spatial data can be of interest to almost…
No, I'm not talking about a Dickens novel. I'm talking about the number of characters in a string. I had a painful time recently because of the word "characters."Â If you take a look at the dynamic management view sys.dm_exec_sql_text you can get the queries that have been run on your system that are still in the cache. It's a great utility. Better still, you can get specific statements from the code that are actively running through sys.dm_exec_requests or ones that have run through sys.dm_exec_query_stats. To do this is very simple. Each of these DMV's has a pair of columns, statement_start_offset and statement_end_offset. These columns, and I'm quoting directly from books online measure the "number of character" offset from the beginning of the SQL string and from the end of…
It's not enough to look at the longest running query. What if you have two queries, one runs for 5 minutes and the other runs for 5 seconds. Which do you tune? The first one, of course. But, let's add a little information to our thought experiment. The one that runs for 5 minutes is called 2AM, your local time, when there are almost no users on the system and the one that runs for 5 seconds is called 40 times a minute all day long. Now, which one do you tune? That's right, suddenly that 5 second query takes on a HUGE significance based on how often it's called. But how do you know how often a query is called? The easiest way to gather that information is not…
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…
I'm still barely scratching the surface working with spatial data in SQL Server 2008. We've ported some of the data into a table where we built a geography spatial data column and we're begginning to work with point data. The requirements from the developers are, so far, very simple. They'll feed me a point and I find all the locations "close" to it. We had to go round & round on what defines "close" but finally settled on, I think, 15km. The query to answer a question like this is ridiculously simple (a few object names have been changed): SELECT ebe.[Location].STDistance(@Location) AS Distance, ebe.[InterestId], ebe.[Location].Lat AS Latitude, ebe.[Location].Long AS Longitude, ebe.[OrgId] FROM dbo.[ebe] AS ebe WHERE ebe[OrgId] = @OrgId AND ebe.[Location].STDistance(@Location) < @CloseDistance I'm not even hard-coding the "close" value…
SQL Server 2008 introduced TDE (either Total Database Encryption or Transparent Database Encryption, I've seen both) which is a way to get a passive encryption in place on the database to prevent people from stealing backups or detaching files & stealing them. It works with a Certificate in the server, and there are mechanisms around password protection of the Certificates, management etc. Setting it up & turning it on are very easy. This example is from a chapter on a book I'm working on: USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Chapter8Backup'; GO CREATE CERTIFICATE Chapter8Certificate WITH SUBJECT = 'Chapter 8 Certificate' GO USE AdventureWorksLT GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE Chapter8Certificate GO ALTER DATABASE AdventureWorksLT SET ENCRYPTION ON GO…