Ramblings of Greg Low (SQL Server MVP, MCM and Microsoft RD) - SQL Down Under
AzureCon is the main #Azure related conference each year, and of course, it’s an online conference.
It’s coming up at the end of this month (September).
It’s time to register to see what ScottGu and the people from the Azure team have to tell us.
We recently started working with the new Personal Data Management Gateway for Power BI. Overall, we really like it but the error messages in most of Power BI have left much to be desired.
One error that we were encountering made us feel like the service was flaky as it seemed to happen randomly. When we tried to refresh a dataset, we got this error:
The Power BI team came to the rescue and worked out what was happening. Turns out that you cannot currently refresh more than once every 5 minutes. That also includes within 5 minutes of your initial upload. Unfortunately, this is the error returned when you attempt it.
Apparently this 5 minute limit is going to be removed soon and hopefully that will be one less error we might see.
One of my biggest goals for this year was to try to pass the HSK 3 exam. I wanted to do it as a validation of my efforts to learn Chinese.
HSK (Hanyu Shui Ping Kaoshi - 汉语水平考试) is the exam given to foreigners to assess their level of Chinese. (Hanyu is the Chinese language, Shuiping basically means a level of achievement, and Kaoshi is an exam). The organisation that runs it is called Hanban.
There are six levels of exam.
- Level 1 is “Designed for learners who can understand and use some simple Chinese characters and sentences to communicate, and prepares them for continuing their Chinese studies. In HSK 1 all characters are provided along with Pinyin.”
- Level 2 is “Designed for learners who can use Chinese in a simple and direct manner, applying it in a basic fashion to their daily lives. In HSK 2 all characters are provided along with Pinyin as well.”
- Level 3 is “Designed for learners who can use Chinese to serve the demands of their personal lives, studies and work, and are capable of completing most of the communicative tasks they experience during their Chinese tour.”
- Level 4 is “Designed for learners who can discuss a relatively wide range of topics in Chinese and are capable of communicating with Chinese speakers at a high standard.”
- Level 5 is “Designed for learners who can read Chinese newspapers and magazines, watch Chinese films and are capable of writing and delivering a lengthy speech in Chinese.”
- Level 6 is “Designed for learners who can easily understand any information communicated in Chinese and are capable of smoothly expressing themselves in written or oral form.”
While I’d love to achieve Level 6 one day, my medium term goal is Level 5. That’s the level required for students entering Chinese universities. But my goal for this year was Level 3. It included 100 points for listening, 100 points for reading, and 100 points for writing. I managed 275 all up, which I am super happy about.
I need to thank all my Chinese buddies on Facebook who endlessly answer my mundane questions about Mandarin.
But my biggest thanks needs to go to all at eChineseLearning.com. Spending an hour one-on-one with a teacher three times each week has made an enormous difference. For most of this period, Amy was my teacher. Amy (and most of the teachers including my current teacher Bella) is based in Wuhan, China. If you have any interest in getting serious about Mandarin Chinese, I strongly suggest talking to them. If you mention me, we both get some free time but that’s not my main concern. I’d just love to see more people learning Mandarin. It’s going to be (and already is) a very important language in the future. Estimates are that 1 in 4 children born today will be native Mandarin speakers. (And for interest, 1 in 5 will be native Spanish).
I’ve found that learning Mandarin has already opened up another whole world to me.
Onwards to Level 4 ! 加油！
One of the most anticipated new features in SQL Server 2012 was the introduction of sequences. Prior to SQL Server 2012, developers had a choice of IDENTITY columns or a roll-your-own table mechanism.
Sequences allow us to create a schema-bound object that is not associated with any particular table. For example, if I have a Sales.HotelBookings table, a Sales.FlightBookings table, and a Sales.VehicleBookings table, I might want to have a common BookingID used as the key for each table. If more than the BookingID was involved, you could argue that there is a normalization problem with the tables but we'll leave that discussion for another day.
Recently when working with sequences however, I found a problem with their implementation. It works as described but is not useful.
So let's start by creating the schema and the sequence:
We could then use this schema as the default value for each of the three tables:
All this is as expected. One question that often arises though, is "how do I know the last value for a given sequence". The answer provided is to query the sys.sequences view. We can do this as follows:
The current_value colum in sys.sequences is defined as follows:
Datatype: sql_variant NOT NULL
The use of sql_variant here makes sense as the view needs to be able to provide the current value for all sequences, regardless of data type. Sequences can be created with any built-in integer type. According to BOL, the possible values are:
- tinyint - Range 0 to 255
- smallint - Range -32,768 to 32,767
- int - Range -2,147,483,648 to 2,147,483,647
- bigint - Range -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
- decimal and numeric with a scale of 0.
- Any user-defined data type (alias type) that is based on one of the allowed types.
The output of that column is described as:
The last value obligated. That is, the value returned from the most recent execution of the NEXT VALUE FOR function or the last value from executing the sp_sequence_get_range procedure. Returns the START WITH value if the sequence has never been used.
And this is where I have a problem with how it's defined. When you have never retrieved a value from the sequence, there is no last value obligated. What it does return is the first value that will be generated, but has not yet been generated:
The documentation is correct but the behaviour is bizarre. I believe that this column should return NULL. Otherwise, there is no way to tell that this value has not yet been generated.
If I generate a new value and then query it again ie:
Note that the same value is returned:
It's only when I request it another time, that I see the expected value:
So the problem is that when you read the current value from the sys.sequences view, there's no way to know if this is the last value obligated or the next one that will be obligated.
I'd really like to see this behaviour changed. Given that the SQL Server team rates backwards compatibility highly, an alternative would be to add a new column to sys.sequences that indicates that the sequence has never been used. There is a column is_exhausted. At a pinch, that could be set for new sequences.
If you agree, you can vote here: https://connect.microsoft.com/SQLServer/feedback/details/1461552
While SQL Server’s plan cache generally is self-maintaining, poor application coding practices can cause the plan cache to become full of query plans that have only ever been used a single time and that are unlikely to ever be reused. We call this “plan cache pollution”.
The most common cause of these issues are programming libraries that send multiple variations of a single query. For example, imagine I have a query like:
SELECT c.CustomerID, c.TradingName, c.ContactName, c.PhoneNumber FROM dbo.Customers AS c WHERE c.CustomerID = @CustomerID AND c.BusinessCategory = @BusinessCategory AND c.ContactName LIKE @ContactNameSearch ORDER BY c.CustomerID;
The query has three parameters: @CustomerID, @BusinessCategory, and @ContactNameSearch. If the parameters are always defined with the same data types ie: @BusinessCategory is always nvarchar(35) and so on, then we will normally end up with a single query plan. However, if on one execution the parameter is defined as nvarchar(35), and on the next execution it is defined as nvarchar(20), and on yet another execution it is defined as nvarchar(15), each of these queries will end up with different query plans. A similar problem would also occur if any of the plan-affecting SET options are different on each execution ie: if DATEFORMAT was dmy for one execution, and mdy for the next, you’ll also end up with a different plan.
For more details on the internal causes of this or for a list of plan-affecting SET options, you might want to read the whitepaper that I prepared for the MSDN site. The latest version was for SQL Server 2012 and can be found here: https://msdn.microsoft.com/en-us/library/dn148262.aspx (Plan Caching and Recompilation in SQL Server 2012).
So what on earth would cause someone to send parameters defined differently each time? The worst offenders are not queries that are written intentionally, they are queries written by frameworks.
As an example, while using the SqlCommand object in ADO.NET, it is convenient to use the AddWithValue(parametername, parametervalue) method of the Parameters collection. But notice that when you do this, you do not specify the data type of the parameter. ADO.NET has to derive an appropriate data type based on the data that you have provided. For string parameters, this can be particularly troubling. If the parameter value is initially “hello”, a query plan with an nvarchar parameter length of 5 will be cached after the command is executed. When the query is re-executed with a parameter value of “trouble”, the command will appear to be different as it has an nvarchar parameter with a length of 7.
The more the command is executed, the more the plan cache will become full of plans for different length string parameters. This is particularly troubling for commands with multiple string parameters as plans will end up being stored for all combinations of all lengths of all the parameters. Some later variants of these libraries are improved by always deriving strings as nvarchar(4000). That’s not ideal but it’s much better than the previous mechanism.
While someone coding with ADO.NET can use another method to add a parameter ie: one that allows specifying the data type as well, developers using higher level libraries do not have that option. For example, Lync to SQL uses AddWithValue() within the framework. The user has no control over that. Ad-hoc queries generated by end-user query tools can also cause a similar problem where many combinations of similar queries can end up becoming cached.
As mentioned, to work around such a problem, the application should use a method to add the parameter that allows specifying the data type precisely.
As an example, nvarchar(100) might be used as the data type for each execution in the above example, if we know that all possible parameter lengths are less than 100.
Treating Plan Cache Pollution
There are several additional options that can help in dealing with plan cache pollution issues:
FORCED PARAMETERIZATION can be set at the database level. SQL Server will often auto-parameterize queries by determining that a value looks like a parameter, even though you didn’t specify it as a parameter. Using the FORCED PARAMETERIZATION setting makes SQL Server become much more aggressive in deciding which queries to auto-parameterize. The down-side of this option is that it could potentially introduce parameter-sensitivity problems. (This option was added in SQL Server 2005).
OPTIMIZE FOR ADHOC WORKLOADS is an sp_configure server level option. When set, SQL Server only caches a plan stub on the first execution of an ad-hoc query. The next time the same query is executed, the full plan is stored. Plan stubs are much smaller than query plans and this option ensures that the plan cache is not filled by query plans that have never been reused. (This option was added in SQL Server 2008). We tend to enable this option on most servers.
Sometimes you can get into a situation where you simply cannot avoid the queries from creating this situation and you need to deal with it. DBCC FREESYSTEMCACHE can be used to clear the query cache. One little understood option on it however, is that you can then specify a particular Resource Governor resource pool. It then only clears the plans associated with that resource pool. (This command was first available in SQL Server 2005 but the option to clear a specific resource pool was added in SQL Server 2008).
We often use this method to work around plan cache pollution issues. We try to isolate the badly-behaved applications or ad-hoc queries into one or more separate resource pools using Resource Governor. Then periodically, (perhaps every 5 or 10 minutes), we clear the plan cache for members of this “tough luck” pool.
Best advice is to try to avoid the situation in the first place by appropriate coding techniques but that option isn’t available to everyone.
I always say that one of the things that I love about consulting or mentoring work is that I see things (mostly code) that I would have never have thought of, both good and bad. You could spend all day dreaming up bizarre ideas and never come close to the ones that I just happen to come across.
A good example of this was a site I was at a while back where every table had a GUID name. Yes, I'm talking about tables named dbo.[3B38AB7E-FB80-4E56-9E5A-6ECED7A8FA17] and so on. They had tens of thousands of tables named this way. Query plans were close to unreadable.
Another was a site where the databases were named by their location on the disk. Yes, they had a database named X:\Database Files\Data Files\CoreDB.mdf. And yes that does mean that you end up using it like:
Not all odd things that I see are so blatant though. Today I saw a more subtle coding issue. With SQL Server the UNION operation combines to rowsets into a single rowset. If UNION ALL is used then all rows are returned. With just UNION without the ALL, only distinct rows are returned. All good so far.
But until today, I'd never stopped to think about what happens when you mix the two operations. For example, without running the code (or reading further ahead yet), what would you expect the output of the following command to be? (The real code read from a table but I've mocked it up with a VALUES clause to make it easier to see the outcome).
I was left wondering if there was some type of operation precedence between UNION and UNION ALL. The output rows are:
It isn't a case of precedence. The operations are just being applied in order. You can see this as follows:
Executing the first part:
returns the following with no surprises:
Executing the first two parts:
returns all rows from both queries:
Executing the first three parts:
returns the following rows. This is formed by taking the previous result, executing the third query then performing a distinct operation on the whole combined rowset.
Executing the entire query then takes this previous result set and appends (based on the UNION ALL), the results from the fourth part of the query.
Regardless of how it actually works, I think it's important to avoid writing code where the outcome is less than obvious. In this case, it was just a bug but if the code as written was the intended code, adding some parentheses to this query might have made the intent clearer.
And of course in this case, a sprinkle of extra DISTINCT and GROUP BY operations made it a thing of beauty:
which actually returned:
So what they really should have written in the first place was:
Hi Folks, on the 5th June (yes that’s Friday next week), I’m running a Data Camp day for the local Microsoft team. It’s being held at Cliftons in the city.
We’ve got four topics for the day:
- Azure SQL DB
- Azure DocumentDB
- Azure Machine Learning
- Azure Stream Analytics
If you want to get your head around any/all of these, we’d love to see you there. Places are limited but you must register and can do so here: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032627085&Culture=en-AU&community=0
The team at Microsoft Virtual Academy (MVA) have pushed out some new content that’s relevant to database people.
First, if you’re wondering about using Azure for SQL Server, the Jumpstart for SQL Server in Azure VMs is worth a look. Longer term, I suspect we’ll mostly end up using SQL Server as a platform service (Azure SQL DB) but in the short-term, implementing it in a VM will be more common as it’s probably both easier when migrating existing applications and a little more familiar to most.
Next, if you have to deal with other databases (shock horror, yes there are others including open source ones), there is a course on Open Source Databases on Azure.
Finally, you would have to have been living under a rock not to notice that Windows 10 is coming. But now, it’s time to start to get your head around what’s different. There’s a course that covers off the Fundamentals of the Technical Preview of Windows 10.
Hi Folks, we’ve been working hard on a new Azure Machine Learning course.
Come and spend a solid day finding out why Azure Machine Learning should be part of your arsenal.
Our first Melbourne offering of Azure Machine Learning Core Skills is 31st July. I’d love to see you there:
Have you looked into Azure Machine Learning as yet?
If not, this might help. It’s a free eBook on getting started with it. Click the book to follow the link:
Was speaking with a customer today about an issue where they were receiving “Out of Memory” exceptions when trying to load a 32 bit PostgreSQL ODBC driver from within an SSIS package.
When the package was run from the command line using Dtexec, all was fine. When the package was run from within the SSIS Catalog, the same package refused to run. They had presumed it was some issue to do with 32 bit vs 64 bit drivers. The customer resolved it by installing the latest 64 bit PostgreSQL ODBC drivers.
However, it’s important to know that when you see an “Out of Memory” error on attempting to load a 32 bit DLL, it usually doesn’t mean anything about memory at all.
Under the covers, in 32 bit Windows, loading an accessing a function in a DLL was performed by:
1. Making an API call to LoadLibrary() – this brought the DLL into memory if it wasn’t already present
2. Making an API call to GetProcAddress() – because the DLL could be located anywhere in memory, there was a need to locate the actual memory address of the procedure in the DLL in its loaded location
3. Making a call to the address returned by the GetProcAddress() call.
With my previous developer hat on, there are several places where I’ve seen this go wrong.
One is that people don’t check the return address from GetProcAddress(). It can return null if the procedure isn’t found. So someone who writes code that just immediately calls the address returned without checking if it is null, would end up generating the previous infamous “this program has performed an illegal operation and will be shut down” message that we used to see.
The less common problem was that LoadLibrary() had its own qwerks. The worst was that if it could not locate the DLL, the error returned was “Out of Memory”. I always thought that was one of the silliest error messages to ever come out of Windows, but it’s entirely relevant here.
When you see an “Out of Memory” error when attempting to load a 32 bit DLL, it’s time to check whether the DLL can be located by the process. The easiest (although not the cleanest) would be to make sure the DLL is in the GAC (global assembly cache).