如何设置Azure SQL以自动重建索引？

Question

在内部部署SQL数据库中,有一个维护计划可以偶尔重建索引,而不是那么多.

如何在Azure SQL DB中进行设置？

PS:我之前尝试过,但由于我找不到任何选项,我想也许他们自动这样做,直到我读完这篇文章并试过:

SELECT
 DB_NAME() AS DBName
 ,OBJECT_NAME(ps.object_id) AS TableName
 ,i.name AS IndexName
 ,ips.index_type_desc
 ,ips.avg_fragmentation_in_percent
 FROM sys.dm_db_partition_stats ps
 INNER JOIN sys.indexes i
 ON ps.object_id = i.object_id
 AND ps.index_id = i.index_id
 CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
 ORDER BY ps.object_id, ps.index_id

并发现我有需要维护的索引

Answer 1

我要指出的是,大多数人根本不需要考虑在SQL Azure中重建索引.是的,B +树索引可能会碎片化,是的,与完美调整的索引相比,这会导致一些空间开销和一些CPU开销.因此,在某些情况下,我们会与客户合作重建索引.(主要方案是当客户可能用完空间时,目前,由于当前架构,SQL Azure中的磁盘空间有限).因此,我将鼓励您退一步考虑使用SQL Server模型来管理数据库不是"错误的",但它可能或可能不值得您的努力.

(如果最终需要重建索引,欢迎使用其他海报发布的模型 - 它们通常是编写脚本任务的好模型.请注意,SQL Azure托管实例也支持SQL Agent,您也可以使用它如果您愿意,可以创建作业来编写脚本维护操作).

以下是一些可以帮助您确定是否可能成为索引重建候选者的详细信息:

• 您引用的链接来自2013年的帖子.在该帖子之后,SQL Azure的体系结构完全重做.具体而言,硬件架构从基于本地旋转磁盘的模型转移到基于本地SSD的模型(在大多数情况下).因此,原帖中的指导已过时.
• 您可以在当前体系结构中使用碎片索引耗尽空间.您可以选择重建索引或移动到更大的预留大小一段时间(这将花费更多的钱),支持更大的磁盘空间分配.[由于机器上的本地SSD空间有限,预订大小大致与机器的比例相关联.随着我们获得具有更大/更多驱动器的更新硬件,您可以获得更多扩展选项].
• 与旋转磁盘相比,SSD碎片影响相对较低,因为随机IO的成本实际上并不高于顺序IO.走几个B + Tree中间页面的CPU开销是适度的.我通常看到平均情况下最多可能增加5-20%的开销(这可能会或可能不会证明在重建时会产生更大的工作负载影响的常规重建)
• 如果您使用的是查询存储(默认情况下在SQL Azure中启用),则可以评估特定索引重建是否有助于您的性能可见.您可以执行此操作作为测试,以查看您的工作负载是否有所改善,然后自己花费时间来构建和管理索引重建操作.
• 请注意,SQL Azure中目前没有用于用户工作负载的数据库内资源治理.因此,如果启动索引重建,最终可能会消耗大量资源并影响主要工作负载.当然,你可以尝试在非工作时间完成工作,但对于世界各地许多客户的应用,这可能是不可能的.
• 此外,我会注意到许多客户都有索引重建作业"因为他们希望更新统计信息".没有必要重建索引只是为了重建统计数据.在最近的SQL Server和SQL Azure中,统计信息更新的算法在较大的表上更具侵略性,并且在客户查询最近插入的数据(自上次统计信息更新)的情况下我们如何估计基数的模型在以后的兼容性中已更改水平.因此,通常情况是客户甚至根本不需要进行任何手动统计更新.
• 最后,我会注意到统计数据过时的影响在历史上是你会得到计划选择回归.对于重复查询,通过在查询存储上引入自动调整功能(如果它注意到查询性能与先前计划相比大幅回归,则会强制执行先前计划)可以减轻此问题的影响.

我给客户的官方建议是不打扰索引重建,除非他们有一级应用程序,他们已经证明了真正的需求(收益大于成本)或者他们是SaaS ISV他们试图调整工作量的地方在弹性池或多租户数据库设计中的许多数据库/客户,因此他们可以减少他们的COGS或避免在一个非常大的数据库上耗尽磁盘空间(如前所述).在我们在平台上拥有的最大客户中,我们有时会看到与客户手动进行索引操作的价值,但我们通常不需要在我们进行"以防万一"这种操作的情况下定期工作.SQL团队的目的是让您根本无需担心这一点,您可以专注于您的应用程序.当然,我们总能在我们的自动机制中添加或改进这些内容,因此我完全允许单个客户数据库可能需要此类操作.除了我提到的案例之外,我没有见过任何自己,甚至那些也很少成为问题.

我希望这可以为您提供一些背景信息,以了解为什么还没有在平台上完成 - 对于我们今天服务的绝大多数客户数据库而言,与其他迫切需求相比,这只是一个问题.当然,我们会重新审视构建每个计划周期所需的事项列表,并且我们会定期查看此类机会.

祝你好运 - 无论你的结果如何,我希望这能帮助你做出正确的选择.

此致,Conor Cunningham Architect,SQL

Answer 2

您可以使用Azure自动化来安排索引维护任务,如下所述:使用Azure自动化重建SQL数据库索引

以下是步骤:

1)如果您没有,请提供自动化帐户,访问https://portal.azure.com并选择新建>管理>自动化帐户

2)创建自动化帐户后,打开详细信息,然后单击Runbook>浏览库

在搜索框中键入单词"indexes"和Runbook"Azure数据库中的索引表,如果它们具有高碎片",则会出现:

4)请注意,Runbook的作者是Microsoft的SC自动化产品团队.点击导入:

5)导入Runbook后,现在让我们将数据库凭据添加到资产中.单击Assets> Credentials,然后单击"Add a credential ..."按钮.

6)设置凭据名称(稍后将在Runbook上使用),数据库用户名和密码:

7)现在再次单击Runbooks,然后从列表中选择"Update-SQLIndexRunbook",并单击"编辑..."按钮.您将能够看到将要执行的PowerShell脚本:

8)如果要测试脚本,只需单击"测试窗格"按钮,即可打开测试窗口.引入所需的参数,然后单击Start以执行索引重建.如果发生任何错误,则会在结果窗口中记录错误.请注意,根据数据库和其他参数,这可能需要很长时间才能完成:

9)现在返回编辑器,然后单击"发布"按钮启用Runbook.如果我们点击"开始",会出现一个询问参数的窗口.但是,由于我们要安排此任务,我们将点击"计划"按钮:

10)单击Schedule链接为Runbook创建新的Schedule.我每周指定一次,但这取决于您的工作量以及索引如何随着时间的推移而增加碎片.您需要根据需要调整计划,并在执行之间执行初始查询:

11)现在介绍参数和运行设置:

注意:您可以使用具有不同设置的不同计划,即具有特定表的特定计划.

有了这个,你已经完成了.请记住根据需要更改"记录"设置: