Huge news: Azure expanding to Australia!!!

I was so glad to hear today that Azure is expanding to Australia. This helps with two remaining areas of concern that I've heard from a variety of customers:

  • Compliance and data sovereignty (not wanting to store data outside Australia)
  • Latency (previously high latency even to our nearest external data centres)

With both these concerns now disappearing, it's time for more Australian customers to get involved with Azure if they've been resisting so far. 

Two Azure sub-regions are to be added. One for New South Wales and another for Victoria. In addition, data geo-replication between the sub-regions will also be available.


Another large set of Azure enhancements: including some for SQL folk

I'm really impressed by the rate that the Azure team is making and releasing enhancements. Scott Guthrie posted about these again recently.

The following items in the announcement were ones that I think can be useful to those with an interest in SQL Server:

* General availability of Azure VMs. While we've had SQL Database and SQL Reporting available as services in Azure, we don't have the other parts of the database platform. With Azure VMs, you can spin up a VM to run SQL Server.

* SQL Server templates. You don't need to install SQL Server when creating a VM. There are templates that have this already installed. You can also save your own templates. They've also provided BizTalk and SharePoint templates.

* Hourly billing for the templates above. This means that if you just need a SQL Server system for a few hours, you can easily do that.

* Virtual Networks. You can create a virtual network, including the ability to stretch that out to your on-premises systems.

* Larger memory VMs. If you really want to try out tabular analytic models, etc. you can now get up to 8 cores and 56GB of memory in a VM.

* Durable data disks from storage can now be up to 1TB in size each.

* Significant reduction in the price of the VMs.

You'll find Scott's announcement here:

Warning: Lost my stored Azure credential details in SSMS after applying CU3 + Hotfix

I posted the other day about a hotfix that's needed after you apply SQL Server 2012 SP1 CU3, to still be able to open or edit SSIS projects or database maintenance plans in SSDT.

However, I found that after I applied CU3 and the hotfix, that all my stored credential details for SQL Servers was gone. That was particularly nasty for all my Azure-related logons. I had to set them up again.

No idea why that happened but figured I should give you all a heads-up about it!

New Features added to Azure today – AD, Backup & Website Monitoring

It's great to see the constant roll-out of capabilities across the Azure platform.

One in particular that many have been waiting for is Active Directory. Scott Guthrie posted today that it's now available for production use. This is particularly significant and also enables options for on-premises directory sync and federation. If you have been using Office365, you have already been using Azure AD.

Scott also mentioned that they are about to open a preview of a link from OAuth 2 (or OpenID) to Azure AD. That will enable you to use alternate credentials (such as Twitter credentials) to authenticate against Azure AD.

They have also added an Azure Backup option and added a variety of monitoring options for Azure Websites, including the ability to retrieve website logs via FTP.

Scott's post about this is here:

Another government certifying Azure: UK

One of the common objections that comes up when talking to people about storing their data in Azure, is that "we are not allowed to do it". In so many cases, that simply isn't true, or it's true for a small part of the overall data. In other cases, it's a case of no-one wanting to be seen to be the first in their industry to do so, for some perceived liability reasons. Again, most of these are unfounded.

The thing that can change these opinions though is certification by governments. Some have already done so and it's great to see the announcement that Windows Azure received G-Cloud Impact Level 2 Accreditation from Cabinet Office for use across the UK Public Sector. You can read more about it here:

Using Existing Windows Azure SQL Databases with Azure Mobile Services

I was one of the speakers today at the 6 Weeks of Azure bootcamp event in Sydney today. During the day, as well as speaking, we have an "unconference". There's a lot of discussion on whatever the attendees want to discuss.

One of the offline questions I got today though was about how to hook up Azure Mobile Services to an existing Windows Azure SQL Database rather than using the one that Mobile Services can auto-create. While getting that to work, we learned a few things:

  • Tables need to be created in a schema that has the same name as the Mobile Service. (ie: if I want a table called CurrentTasks, and my service is called TaskManager, I need to have my table called TaskManager.CurrentTasks.
  • Tables need to have a clustered primary key that is an integer and is called "id" (it appears case-sensitive in the app for some reason)
  • After you modify the mobile service to point to your database (or after you create a mobile service referencing the existing database), you need to add each table to the service by using the mobile services portal. (If you reference a table that doesn't exist, that's when it would also create the table)

The attendee had already created his tables in the dbo schema. We moved his tables by using:

ALTER SCHEMA servicename TRANSFER dbo.OldTableName;

It's also worth noting that Mobile Services isn't yet available in all datacenters. The attendee's database was in a different datacenter and it's important to try to avoid that, or the latency can be a big issue. He and another attendee were asking about the best ways to move the database to another datacentre. One option for this is to export a BACPAC of the database to Azure Storage, and to then import the database to the alternate server.

Unfortunately, even though CREATE DATABASE AS COPY OF works across servers within the same datacenter, it doesn't work for servers in different datacenters.


Windows Azure SQL Reporting – now configurable in the new portal

Scott Guthrie blogged yesterday about a raft of new changes to the Azure platform.

Of interest to SQL folk are really three main changes:

* SQL Reporting has made its way into the new portal (ie: you no longer have to flip back to the old portal to work with it. Hopefully Data Sync will do the same soon).

* Better options now exist for downloading blobs from Azure Storage. (This could include, for example, SQL Server backups made using BACKUP TO URL).

* New tools for monitoring the usage and availability of VMs.

For others, it's good to see that you can now upload .cer certificate files, not just .pfx certificate files when working with cloud services, and also interesting to see Android support added to mobile services.

You'll find Scott's post here:

SQL Down Under Show 56 – Thomas LaRock – DBAs moving to architect, constant learning, Azure, big data

I recorded another podcast today with Thomas LaRock, aka SQL Rock Star.

In this show, Tom and I discussed the migration of many DBAs into architect roles, the challenges in constant learning (and useful resources for doing so), the hype around big data, the role of Windows Azure in our future, and upcoming PASS events.

It's online now:


Sysprep improvements in SQL Server 2012 SP1 CU2

Sysprep has been a useful tool to allow the preconfiguration of SQL Server environments, along with the rest of the operating system. This can be very useful for templated Azure VMs as well as for on-premises systems and private clouds.

One of the limitations has been that not all SQL Server components were "sysprep-able".

Another important change in CU2 for SQL Server 2012 SP1 is that more SQL Server components are now able to be "sysprepped". In particular, SQL Server Analysis Services (SSAS) and SQL Server Integration Services (SSIS) can now be part of this.

This is good news and you'll find more info in the VM Engineering team's blog post by Robert Hutchison here:

Backup TO DISK, TAPE and now URL – Backup On-Premises SQL Server Databases to Azure Storage

There has been a lot of discussion over the years about whether or not it's a good idea to introduce new functionality in service packs (for SQL Server, the OS, and others). The concern is that it can invalidate testing, invalidate documentation, books, courseware, etc. However, it can also introduce much-needed features without having to wait for another version of the product. It's been even-less likely that new functionality would be introduced in a cumulative update (or CU), which are basically a set of rolled-up hotfixes.

However, interesting new functionality has appeared in CU2 for SQL Server 2012 SP1.

The BACKUP command now supports TO URL when specifying a backup device. That allows you to specify the location of an Azure storage account as the backup destination. This avoids the need to create a backup locally, and to then have a process to copy it to Azure storage. Similarly, RESTORE now also supports a FROM URL option.

This is very interesting news for a number of reasons.

For customers using SQL Server within Azure Virtual Machines (VMs), it provides a way to specify the use of a storage account as the backup destination. While you could do that before by mapping a drive letter to a storage account (and that's what you do when setting up a VM in the first place), the number of drive letters available is limited and this avoids using them up.

For customers using SQL Server on-premises, this provides a direct cloud-based backup option with low-cost, large storage available. The biggest limitation for these customers will no doubt be network bandwidth but for some customers, that isn't an issue. It's also an interesting new DR option for customers that have relatively smaller databases that don't take too long to send over the network but which are none-the-less critical to the organisations.

Another group of customers that would benefit from this would be any customer that needs to distribute a single copy of a database to multiple locations. A backup can be done once, and each secondary location can restore directly from the cloud. I can imagine this being an interesting way to push out new versions of reference data, etc.

A notable group of customers that would benefit from this would be those using Windows Azure SQL Databases. However, the syntax is not yet supported in WASD. I have no advanced knowledge on this but I'm guessing that adding this looks pretty likely, as it would be so beneficial.

When you connect to a storage account, you need to provide both the URL and a storage key. There are two types of keys. One type of key allows for unlimited access. The other type of key can be time-bombed, handed out for short-term purposes and can easily be revoked. Both these types of keys should work with this new option. The BACKUP and RESTORE commands both support a WITH CREDENTIAL option for providing the link to this key.

Credentials were introduced in SQL Server 2005. They are basically a way of giving a name to a set of authentication details (name and secret/password). Previously we have used them with SQL Server Agent Proxy accounts, to allow us to fine tune the permissions that are granted to steps in SQL Server Agent jobs. Now they have an interesting new use.

You'll find details of the changes, with samples of the syntax in this article: