通过手臂模板更新弹性池效率

Question

最初，我们通过臂模板将数据库弹性池部署在Azure中。该池在标准版本中，总共有50个EDTU。当通过发行管理部署该应用程序时，正在发生这种情况。

在某个时候，数据库的大小会增长，因此我们必须增加池的EDTU，以获得一些额外的空间。我们直接从门户网站完成了此操作，但我们没有通过手臂模板部署。我们将edtus增加到100。

当我们想通过VST重新部署应用程序并使用ARM模板时，问题现在就会发生。我们在ARM模板中更新值以反映我们在门户(100(中配置的值，但我们会收到以下错误。

弹性池"池 - 名称"的DTU或存储限制不能降低，因为这不会为其数据库提供足够的存储空间。"

我们的池的手臂模板就像以下

{
  "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",
   }
}

该消息是描述性的，但是我们不明白为什么即使我们通过EDTUS值提供了适当的尺寸，它也会尝试减小大小。

Answer 1

我们部分地确定了问题发生的原因。

正如此处提到的，尤其是 Storagemb的文档可选参数最好不要提供此信息，让Azure计算大小。

为弹性池指定兆字节中的存储极限。您无法为高级版本指定此参数的值。

如果未指定此参数，则该cmdlet计算一个取决于DTU参数值的值。我们建议您不指定Storagemb参数。

正如初始帖子中指出的，我们没有在ARM模板中指定Storagemb选项，这是由Azure设置的。没有提及的，尚不清楚这只是第一次发生。

因此，当我们第一次使用50个EDTU部署时，池的大小设置为50 GB。当我们再次部署并将EDTU设置为100时，大小仍保留在50GB上，这令人困惑。因此，解决方案和可能更安全的方法是始终指定Storagemb选项，以使池对正在发生的事情有更好的视野和控制。

Answer 2

我的猜测是，池中数据库的当前大小可能大于标准100 EDTU池随附的随附的数据存储。该尺寸的随附的存储量为100 GB。存储量是可以单独调整的仪表，以便您拥有更少的EDTU但存储量更高的池。标准100 EDTU池上的当前最大存储空间为750 GB。

我想知道是否有人进入门户，还调整了池的最大数据存储大小。如果是这种情况，并且池中的数据库现在超过100 GB标记，那么您看到的此错误是有道理的。由于该模板没有指定较大的数据存储量，因此我的猜测是系统将其默认为100 GB的量并尝试应用它，现在可能太小了。

我建议您检查池中数据库当前正在使用的存储总量的门户。如果超过100 GB，则您需要更新模板，以还包括您使用的最大尺寸的附加设置。

如果现在不超过100 GB的总数，我不确定它在抱怨什么。