如何设置 Azure SQL 自动重建索引？
How to set Azure SQL to rebuild indexes automatically?
在本地 SQL 数据库中，有一个维护计划来重建索引是正常的，当它不被经常使用时。
如何在 Azure SQL 数据库中进行设置？
P.S：我之前尝试过，但由于我找不到任何选项，我想也许他们会自动执行，直到我阅读 this post 并尝试过：
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
并发现我有需要维护的索引
您可以使用 Azure 自动化来安排索引维护任务，如下所述：Rebuilding SQL Database indexes using Azure Automation
步骤如下：
1) 如果您没有自动化帐户，请转到 https://portal.azure.com 和 select 新建 > 管理 > 自动化帐户
2) 创建自动化帐户后，打开详细信息，然后单击 Runbooks > Browse Gallery
在搜索框中键入“索引”一词，运行书籍“Azure 数据库中的索引 tables 如果它们具有高碎片”出现：
4) 请注意，运行这本书的作者是 Microsoft 的 SC 自动化产品团队。点击导入：
5) 导入 运行 书籍后，现在让我们将数据库凭据添加到资产中。单击资产 > 凭据，然后单击“添加凭据...”按钮。
6) 设置一个Credential name（后面运行本书会用到），数据库用户名和密码：
7) 现在再次单击 Runbooks，然后从列表中 select“Update-SQLIndexRunbook”，然后单击“Edit…”按钮。您将能够看到将要执行的 PowerShell 脚本：
8) 如果要测试脚本，只需单击“测试窗格”按钮，测试window 就会打开。输入需要的参数，点击开始执行索引重建。如果发生任何错误，错误将记录在结果 window 中。请注意，根据数据库和其他参数，这可能需要很长时间才能完成：
9) 现在回到编辑器，点击“发布”按钮启用运行这本书。如果我们点击“开始”，会出现一个 window 询问参数。但是因为我们想要安排这个任务，我们将点击“安排”按钮：
10) 单击日程 link 为 运行 图书创建新日程。我已指定每周一次，但这将取决于您的工作量以及您的索引如何随着时间的推移增加它们的碎片。您将需要根据您的需要并通过在执行之间执行初始查询来调整计划：
11）现在介绍参数和运行设置：
注意：您可以使用不同设置的不同时间表，即针对特定 table.
设置特定时间表
至此，您就完成了。请记住根据需要更改日志记录设置：
Azure 自动化很好，价格也可以忽略不计..
您还有其他一些选择
1.Create 执行 sql 任务并通过 sql 代理安排它。执行 sql 任务应包含索引重建代码以及统计数据重建
2.You 也可以创建一个 linked 服务器到 SQLAZURE 并创建一个 sql 代理 job.To 创建一个 linked 服务器到 azure，你可以看到这个 SO link:I need to add a linked server to a MS Azure SQL Server
更新：请注意，工程团队已发布更新指南，以更好地在 Microsoft 更“官方”的地方编纂此答案中的一些建议，因为一些客户要求这样做。 SQL Server/DB Index Guidance。谢谢，康纳
原答案：
我要指出，大多数人根本不需要考虑在 SQL Azure 中重建索引。是的，B+ 树索引可能会变得碎片化，是的，与完美调整的索引相比，这可能会导致一些 space 开销和一些 CPU 开销。因此，在某些情况下，我们确实会与客户合作重建索引。 （主要情况是客户可能 space 中的 运行，目前，由于当前架构，磁盘 space 在 SQL Azure 中有些受限）。因此，我鼓励您退后一步，考虑使用 SQL 服务器模型来管理数据库并没有“错误”，但它可能值得也可能不值得您付出努力。
（如果您最终确实需要重建索引，欢迎您使用其他 post 人员在此处编写的模型 post - 它们通常是编写任务脚本的好模型。请注意，SQL Azure 托管实例还支持 SQL 代理，您也可以使用它来创建作业来编写维护操作脚本）。
以下一些详细信息可以帮助您决定您是否适合索引重建：
- 您引用的 link 来自 2013 年的 post。 SQL Azure 的架构在 post 之后完全重做。具体来说，硬件架构从基于本地旋转磁盘的模型转变为基于本地 SSD 的模型（在大多数情况下）。所以，原来的指南 post 已经过时了。
- 在当前体系结构中，您可能会遇到 space 中 运行 具有碎片索引的情况。您可以选择重建索引或移动到更大的保留大小一段时间（这将花费更多的钱）以支持更大的磁盘 space 分配。 [由于机器上的本地 SSD space 有限，预留大小大致 link 与机器的比例相符。随着我们使用 larger/more 个驱动器获得更新的硬件，您将有更多的纵向扩展选项。
- 与旋转磁盘相比，SSD 碎片影响相对较低，因为随机 IO 的成本实际上并不比顺序 IO 高多少。 CPU 多走几个 B+ 树中间页的开销是适度的。在一般情况下，我通常会看到最多 5-20% 的开销（这可能会或可能不会证明定期重建是合理的，因为在重建时会产生更大的工作负载影响）
- 如果您正在使用查询存储（在 SQL Azure 中默认启用），您可以评估特定索引重建是否对性能有明显帮助。在花时间自己构建和管理索引重建操作之前，您可以将此作为测试来查看您的工作量是否有所改善。
- 请注意，目前在 SQL Azure 中没有针对用户工作负载的数据库内资源治理。因此，如果您开始重建索引，最终可能会消耗大量资源并影响您的主要工作负载。当然，您可以尝试安排在下班时间完成的事情，但对于全球拥有大量客户的应用程序，这可能是不可能的。
- 此外，我会注意到许多客户都有索引重建作业，“因为他们希望更新统计数据”。没有必要仅仅为了重建统计信息而重建索引。在最近的 SQL 服务器和 SQL Azure 中，统计更新算法在更大的表上变得更加积极，并且在客户查询最近插入的数据的情况下我们如何估计基数的模型（自上次统计以来更新）在以后的兼容性级别中已更改。因此，通常情况下，客户甚至根本不需要进行任何手动统计更新。
- 最后，我要指出的是，从历史上看，统计数据过时的影响是您会得到计划选择回归。对于重复查询，通过在查询存储上引入自动调整功能可以减轻很多影响（如果发现与先前计划相比查询性能大幅下降，则会强制执行先前计划）。
我给客户的官方建议是不要为索引重建而烦恼，除非他们有一个 tier-1 应用程序，他们已经证明了真正的需要（收益大于成本）或者他们是 SaaS ISV 他们在哪里尝试在弹性池或多租户数据库设计中调整许多 databases/customers 的工作负载，以便他们可以减少 COGS 或避免 运行 耗尽磁盘 space（如前所述）在一个非常大的数据库上。在我们平台上最大的客户中，我们 有时 看到与客户手动进行索引操作的价值，但我们通常不需要定期进行此类操作操作“以防万一”。 SQL 团队的意图是您根本不需要为此烦恼，您可以只专注于您的应用程序。当然，我们总是可以在我们的自动机制中添加或改进一些东西，所以我完全考虑到个别客户数据库可能需要此类操作的可能性。除了我提到的案例之外，我自己没有见过任何案例，即使是那些案例也很少成为问题。
我希望这能为您提供一些背景信息，让您了解为什么平台中尚未完成此操作 - 与其他服务相比，我们今天在服务中拥有的绝大多数客户数据库都不是问题紧迫的需求。当然，我们会重新审视构建每个计划周期所需的事项清单，并且我们确实会定期寻找这样的机会。
祝你好运 - 无论你在这里的结果如何，我希望这能帮助你做出正确的选择。
真诚的，
康纳坎宁安
建筑师，SQL
作为@TheGamiswar suggested, add a linked server，然后像这样创建一个存储过程：
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [LinkedServerName].[RemoteDB].[dbo].[sp_RebuildReorganizIndexes]
AS
BEGIN
ALTER INDEX PK_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON);
ALTER INDEX IX_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON); --Nonclustered index
ALTER INDEX PK_MyTable ON MyTable REORGANIZE;
ALTER INDEX IX_MyTable ON MyTable REORGANIZE;
END
然后在您的链接服务器上使用 "SQL Server Agent" 创建一个新作业和一个时间表：
详情请看https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-2017
您可以考虑使用 Azure 弹性作业代理在一个作业中自动执行多个数据库上的 Azure SQL 数据库维护。
在 https://azureops.org/articles/automating-azure-sql-database-maintenance-tasks/
阅读更多相关信息
在本地 SQL 数据库中，有一个维护计划来重建索引是正常的，当它不被经常使用时。
如何在 Azure SQL 数据库中进行设置？
P.S：我之前尝试过，但由于我找不到任何选项，我想也许他们会自动执行，直到我阅读 this post 并尝试过：
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
并发现我有需要维护的索引
您可以使用 Azure 自动化来安排索引维护任务，如下所述：Rebuilding SQL Database indexes using Azure Automation
步骤如下：
1) 如果您没有自动化帐户，请转到 https://portal.azure.com 和 select 新建 > 管理 > 自动化帐户
2) 创建自动化帐户后，打开详细信息，然后单击 Runbooks > Browse Gallery
在搜索框中键入“索引”一词，运行书籍“Azure 数据库中的索引 tables 如果它们具有高碎片”出现：
4) 请注意，运行这本书的作者是 Microsoft 的 SC 自动化产品团队。点击导入：
5) 导入 运行 书籍后，现在让我们将数据库凭据添加到资产中。单击资产 > 凭据，然后单击“添加凭据...”按钮。
6) 设置一个Credential name（后面运行本书会用到），数据库用户名和密码：
7) 现在再次单击 Runbooks，然后从列表中 select“Update-SQLIndexRunbook”，然后单击“Edit…”按钮。您将能够看到将要执行的 PowerShell 脚本：
8) 如果要测试脚本，只需单击“测试窗格”按钮，测试window 就会打开。输入需要的参数，点击开始执行索引重建。如果发生任何错误，错误将记录在结果 window 中。请注意，根据数据库和其他参数，这可能需要很长时间才能完成：
9) 现在回到编辑器，点击“发布”按钮启用运行这本书。如果我们点击“开始”，会出现一个 window 询问参数。但是因为我们想要安排这个任务，我们将点击“安排”按钮：
10) 单击日程 link 为 运行 图书创建新日程。我已指定每周一次，但这将取决于您的工作量以及您的索引如何随着时间的推移增加它们的碎片。您将需要根据您的需要并通过在执行之间执行初始查询来调整计划：
11）现在介绍参数和运行设置：
注意：您可以使用不同设置的不同时间表，即针对特定 table.
设置特定时间表至此，您就完成了。请记住根据需要更改日志记录设置：
Azure 自动化很好，价格也可以忽略不计..
您还有其他一些选择
1.Create 执行 sql 任务并通过 sql 代理安排它。执行 sql 任务应包含索引重建代码以及统计数据重建
2.You 也可以创建一个 linked 服务器到 SQLAZURE 并创建一个 sql 代理 job.To 创建一个 linked 服务器到 azure，你可以看到这个 SO link:I need to add a linked server to a MS Azure SQL Server
更新：请注意，工程团队已发布更新指南，以更好地在 Microsoft 更“官方”的地方编纂此答案中的一些建议，因为一些客户要求这样做。 SQL Server/DB Index Guidance。谢谢，康纳
原答案：
我要指出，大多数人根本不需要考虑在 SQL Azure 中重建索引。是的，B+ 树索引可能会变得碎片化，是的，与完美调整的索引相比，这可能会导致一些 space 开销和一些 CPU 开销。因此，在某些情况下，我们确实会与客户合作重建索引。 （主要情况是客户可能 space 中的 运行，目前，由于当前架构，磁盘 space 在 SQL Azure 中有些受限）。因此，我鼓励您退后一步，考虑使用 SQL 服务器模型来管理数据库并没有“错误”，但它可能值得也可能不值得您付出努力。
（如果您最终确实需要重建索引，欢迎您使用其他 post 人员在此处编写的模型 post - 它们通常是编写任务脚本的好模型。请注意，SQL Azure 托管实例还支持 SQL 代理，您也可以使用它来创建作业来编写维护操作脚本）。
以下一些详细信息可以帮助您决定您是否适合索引重建：
- 您引用的 link 来自 2013 年的 post。 SQL Azure 的架构在 post 之后完全重做。具体来说，硬件架构从基于本地旋转磁盘的模型转变为基于本地 SSD 的模型（在大多数情况下）。所以，原来的指南 post 已经过时了。
- 在当前体系结构中，您可能会遇到 space 中 运行 具有碎片索引的情况。您可以选择重建索引或移动到更大的保留大小一段时间（这将花费更多的钱）以支持更大的磁盘 space 分配。 [由于机器上的本地 SSD space 有限，预留大小大致 link 与机器的比例相符。随着我们使用 larger/more 个驱动器获得更新的硬件，您将有更多的纵向扩展选项。
- 与旋转磁盘相比，SSD 碎片影响相对较低，因为随机 IO 的成本实际上并不比顺序 IO 高多少。 CPU 多走几个 B+ 树中间页的开销是适度的。在一般情况下，我通常会看到最多 5-20% 的开销（这可能会或可能不会证明定期重建是合理的，因为在重建时会产生更大的工作负载影响）
- 如果您正在使用查询存储（在 SQL Azure 中默认启用），您可以评估特定索引重建是否对性能有明显帮助。在花时间自己构建和管理索引重建操作之前，您可以将此作为测试来查看您的工作量是否有所改善。
- 请注意，目前在 SQL Azure 中没有针对用户工作负载的数据库内资源治理。因此，如果您开始重建索引，最终可能会消耗大量资源并影响您的主要工作负载。当然，您可以尝试安排在下班时间完成的事情，但对于全球拥有大量客户的应用程序，这可能是不可能的。
- 此外，我会注意到许多客户都有索引重建作业，“因为他们希望更新统计数据”。没有必要仅仅为了重建统计信息而重建索引。在最近的 SQL 服务器和 SQL Azure 中，统计更新算法在更大的表上变得更加积极，并且在客户查询最近插入的数据的情况下我们如何估计基数的模型（自上次统计以来更新）在以后的兼容性级别中已更改。因此，通常情况下，客户甚至根本不需要进行任何手动统计更新。
- 最后，我要指出的是，从历史上看，统计数据过时的影响是您会得到计划选择回归。对于重复查询，通过在查询存储上引入自动调整功能可以减轻很多影响（如果发现与先前计划相比查询性能大幅下降，则会强制执行先前计划）。
我给客户的官方建议是不要为索引重建而烦恼，除非他们有一个 tier-1 应用程序，他们已经证明了真正的需要（收益大于成本）或者他们是 SaaS ISV 他们在哪里尝试在弹性池或多租户数据库设计中调整许多 databases/customers 的工作负载，以便他们可以减少 COGS 或避免 运行 耗尽磁盘 space（如前所述）在一个非常大的数据库上。在我们平台上最大的客户中，我们 有时 看到与客户手动进行索引操作的价值，但我们通常不需要定期进行此类操作操作“以防万一”。 SQL 团队的意图是您根本不需要为此烦恼，您可以只专注于您的应用程序。当然，我们总是可以在我们的自动机制中添加或改进一些东西，所以我完全考虑到个别客户数据库可能需要此类操作的可能性。除了我提到的案例之外，我自己没有见过任何案例，即使是那些案例也很少成为问题。
我希望这能为您提供一些背景信息，让您了解为什么平台中尚未完成此操作 - 与其他服务相比，我们今天在服务中拥有的绝大多数客户数据库都不是问题紧迫的需求。当然，我们会重新审视构建每个计划周期所需的事项清单，并且我们确实会定期寻找这样的机会。
祝你好运 - 无论你在这里的结果如何，我希望这能帮助你做出正确的选择。
真诚的， 康纳坎宁安 建筑师，SQL
作为@TheGamiswar suggested, add a linked server，然后像这样创建一个存储过程：
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [LinkedServerName].[RemoteDB].[dbo].[sp_RebuildReorganizIndexes]
AS
BEGIN
ALTER INDEX PK_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON);
ALTER INDEX IX_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON); --Nonclustered index
ALTER INDEX PK_MyTable ON MyTable REORGANIZE;
ALTER INDEX IX_MyTable ON MyTable REORGANIZE;
END
然后在您的链接服务器上使用 "SQL Server Agent" 创建一个新作业和一个时间表：
详情请看https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-2017
您可以考虑使用 Azure 弹性作业代理在一个作业中自动执行多个数据库上的 Azure SQL 数据库维护。
在 https://azureops.org/articles/automating-azure-sql-database-maintenance-tasks/
阅读更多相关信息