While using Start-CopyAzureStorageBlob today I got this rather cryptic error message:

Start-CopyAzureStorageBlob : The remote server returned an error: (412) The condition specified using HTTP conditional header(s) is not met.. HTTP Status Code: 412 - HTTP Error Message: The condition specified using HTTP conditional header(s) is not met.

Quite perplexing as of course all the HTTP conditional headers are a layer of abstraction down from the PowerShell cmdlet.  Hey, don't look at me, I wasn't the one who created the HTTP headers!   :)

It turned out I was specifying the -force keyword, a holdover from an abandoned copy I had restarted.  After removing the -force keyword to the cmdlet invocation, I got a clearer error message:

Start-CopyAzureStorageBlob : The remote server returned an error: (409) Conflict. HTTP Status Code: 409 - HTTP Error Message: There is currently a pending copy operation.

I got this error because I already have a copy underway to copy the same blob to a different storage account.  Apparently you have to wait for the current copy of a blob to finish before you use it as a source for another copy operation.  Who knew? I guess I do now!   :)

Just another puzzling way blobs are different than files in a file system.

select t.[name], ps.*  from sys.dm_db_index_physical_stats(DB_ID(), 0, -1, 0, null) as ps

left outer join sys.tables as t on ps.object_id = t.object_id

 For more information about sys.dm_db_index_physical_stats including the performance impact of using it check out an excellent article by Paul Randal at https://www.sqlskills.com/blogs/paul/inside-sys-dm_db_index_physical_stats/.

Imagine you are building a client application which uses WCF, and you'd like to add some headers before you invoke the web method on a proxy.  The code might look something like:

OperationContextScope scope = new OperationContextScope(myProxy.InnerChannel);

MessageHeader<string> myHeader = newMessageHeader<string>("My header value);

MessageHeader headerWrapper = myHeader.GetUntypedHeader("MyHeaderName", "");

OperationContext.Current.OutgoingMessageHeaders.Add(headerWrapper);

myProxy.MyWebMethod()

Of course you'd want to package this up in some way so that this particular code can be reused for all your web method calls, but that is a different blog post.  Anyway, if you write your code this way, you might be surprised to learn that you are leaking OperationContextScope objects.  You can tell this is happening because looking in Task Manager you can see the memory consumption of your application grow, and grow as more web method calls are executed.  You can find out what is leaking by using this excellent tool called CLRProfiler (https://www.microsoft.com/en-us/download/details.aspx?id=16273).  Run your application for long enough, and if the application repeatedly calls web methods to get data to refresh its data model over time you'll see when you dump the heap using CLRProfiler that although the variable scope in the above example goes out of scope, it's storage is never reclaimed by the GC as you might expect it would.  As it turns out, WCF maintains a stack of OperationContextScope instances.  Making a new OperationContextScope instance pushes onto that stack, and disposing of the topmost OperationContextScope instance pops the stack.  If you never dispose of the OperationContextScope instance, the stack just keeps growing.  Because the stack is accessible, the GC isn't allowed to collect anything on the stack.  Thus the leak.  To fix the above code is super simple once you've figured out the problem:

using (OperationContextScope scope = new OperationContextScope(myProxy.InnerChannel))

{

MessageHeader<string> myHeader = newMessageHeader<string>("My header value);

MessageHeader headerWrapper = myHeader.GetUntypedHeader("MyHeaderName", "");

OperationContext.Current.OutgoingMessageHeaders.Add(headerWrapper);

myProxy.MyWebMethod()

}

There are a lot of other things you need to be careful about, like carefully closing the proxy, but that is also for another blog post.  Meantime, happy coding!

If you haven't heard of SQL Azure definitely go to https://www.windowsazure.com/en-us/home/tour/sql-azure/ and check it out.  SQL Azure is Microsoft's cloud based database offering.  It allows you to deploy database applications to the cloud so that you only pay for the database infrastructure you need when you need it.  A lot of hassles of building highly reliable SQL Server instances are taken care of for you (buying and setting up hardware, configuring replication, for example).  You get to focus on developing and deploying your application, and focus less on the hardware and low level software infrastructure.

However, it is still up to you to monitor your database applications in the cloud, and that is what the SQL Azure management pack can help you do.  The management pack plugs into Microsoft's premier monitoring product, System Center Operations Manager 2007 R2.

This management pack has a great set of features which include:

• Monitoring disk space usage compared to your current quota.  Now you can avoid running out space and crashing your database app.
• Monitoring network utilization so that your billing isn't a huge surprise when you start using more network bandwidth in your app.
• Monitoring how many sessions (how many user connections) are occurring.
• Monitoring CPU, memory, and IO usage.
• Monitoring how many locks are being acquired during the operation of your database application.
• Monitoring how much log space is being used.
• Monitoring how long your transactions execute.
• Monitoring how many databases are associated with each SQL Azure server.
• Monitoring the availability of your SQL Azure server and the databases hosted on the server.  Don't wait to find out from your customers!

You can view graphs showing you the trends of the above numerical data over time.  You can also create overrides which enable System Center Operations Manager to raise alerts when the numbers exceed certain thresholds for those numbers.  You get a great UI showing you the health of the servers you are monitoring and the databases you are monitoring.

Even cooler, with a "single pane of glass" you can monitor both cloud based SQL Server assets using this management pack, and with the regular SQL Server management pack you can monitor your on-premise database server assets.  The vision of hybrid cloud/on-premesis monitoring is here today!

Make sure you read through the deployment guide that comes with the management pack.  It has important information about how to successfully install and use the software.  The SQL Azure management pack is quite unique, so don't assume it will install the same way as other management packs you are used to, even other SQL Server management packs.

I'd love to get your feedback on this CTP and I hope it helps you keep better tabs on all of your SQL Azure assets!

Sample code changes include new Reporting Services samples targeted specifically at SQL Server 2008R2.

Sample database changes include the following:

·         All dates have been incremented by 4 years.  This is a customer requested change and helps keep the data looking relevant.

·         Product descriptions in the data warehouse have been localized into 73 new languages.  A new table has been added to store this new localized content.

·         Scripts have been updated to use new names for the databases (AdventureWorks2008R2, AdventureWorksDW2008R2, AdventureWorksLT2008R2) so that the updated databases can live side by side with the SQL Server 2008 sample databases.

·         A new approach to installing the databases has been implemented.  This approach provides more targeted feedback when issues (such as an incorrectly configured server) arise and provides links to detailed help.  It addresses some issues customers have had with previous installers.

On a personal note, it has been a privilege working on community samples for SQL Server but I am moving on from that role.  Many thanks to all the contributors who continue to make the SQL Server community great!

The scripts and data files in the zip file can be used to create the data warehouse (DW) and light (LT) sample databases in a SQL Azure server without SQL Server or Visual Studio being installed on the machine performing the installation. Currently the AdventureWorks OLTP database is not supported for SQL Azure and is not included in the zip file.