通过ARM模板更新弹性池EDTU

Question

Initially we had deployed database elastic pool in Azure though ARM template. The pool is in Standard edition and had 50 EDTUs in total. This is happening when deploying the app from VSTS through release management.

At some point the databases grew in size so we had to increase the EDTUs of the pool to get some additional space. We did this directly from the portal and we didn't deploy through ARM templates. We increase the EDTUs to 100.

The problem happens now when we want to redeploy the app through VSTS and use the ARM template. We update the value in ARM template to reflect the one we configured in the portal (100) but we are getting the following error.

The DTUs or storage limit for the elastic pool 'pool-name' cannot be decreased since that would not provide sufficient storage space for its databases. "

Our ARM template for the pool is like the following

{
  "comments": "The elastic pool that hosts all the databases",
  "apiVersion": "2014-04-01-preview",
  "type": "elasticPools",
  "location": "[resourceGroup().location]",
  "dependsOn": ["[concat('Microsoft.Sql/Servers/', variables('sqlServerName'))]"],
  "name": "[variables('elasticPoolName')]",
  "properties": {
      "edition": "Standard",
      "dtu": "100",
      "databaseDtuMin": "0",
      "databaseDtuMax": "10",
   }
}

The message is descriptive but we don't get why it tries to decrease the size even if we have provided an appropriate size through EDTUs value.

Answer 1

We partially identified why the problem is happening.

As it's mentioned here and especially the documentation of StorageMB optional argument is better not to provide this and let Azure calculate the size.

Specifies the storage limit, in megabytes, for the elastic pool. You cannot specify a value for this parameter for the Premium edition.

If you do not specify this parameter, this cmdlet calculates a value that depends on the value of the Dtu parameter. We recommend that you do not specify the StorageMB parameter.

As noted in the initial post we didn't specify the StorageMB option in the ARM template and this was set by Azure. What is not mentioned and it was not clear is that this happens only the first time.

So when we deployed for first time with 50 EDTUs the size of the pool was set to 50 GB. When we deployed again and set the EDTUs to 100 then the size remains on 50GB which is confusing. So the solution and probably a safer way is to always specify the StorageMB option for the pool to have a better view and control of what is happening.

Answer 2

My guess is that the current size of the databases in the pool may be greater than the included data storage that comes with a Standard 100 eDTU pool. The included storage amount for that size is 100 GB. The amount of storage is a meter that can be adjusted separately so that you have pools with fewer eDTU but higher amounts of storage. The current max of storage on an Standard 100 eDTU pool is 750 GB.

I wonder if someone went into the portal and also adjusted the max data storage size for the pool. If this is the case, and the databases within the pool now exceed the 100 GB mark, then this error you are seeing makes sense. Since the template doesn't specify the larger data storage amount then my guess is the system is defaulting it to the included amount of 100 GB and attempting to apply that, which may be too small now.

I'd suggest checking the portal for the total size of storage currently being used by the databases in the pool. If it exceeds the 100 GB then you'll want to update the template to also include the additional setting for the max size you are using.

If it doesn't exceed the 100 GB total now I'm not sure what it's complaining about.