标签: azure-sql-database

我们有许多表（约 1M 条记录），其中有一列定义为：[GlobalID] [uniqueidentifier] NOT NULL自动填充newid(). 我们使用此 ID 跨多个系统、数据库、文件导入/导出等同步数据。

对于此列，我们创建了以下索引：

CREATE UNIQUE NONCLUSTERED INDEX [IxUx_XXXXXX_GlobalID] ON [dbo].[XXXXXX] 
(
    [GlobalID] ASC
)

正如预期的那样，这个索引很快就会变得碎片化，所以我们必须保持重建。然而，这正是我们遇到问题的地方。我的维护脚本通过并重建超过 x% 碎片的所有索引ONLINE=ON总是永远挂在这些索引上。当数据库几乎完全空闲时，我试图让一个运行超过 3 个小时而没有成功。只是为了踢球，我什至将数据库置于单用户模式，没有任何改变。我也试过ONLINE=OFF, 再次没有改变。不过，我是能够简单地丢弃/创建索引，并将其〜15秒内完成！

为了确保我的维护脚本没有什么可笑的，我手动尝试重建这些索引但没有成功。我使用的脚本是：ALTER INDEX IxUx_XXXXXX_GlobalID ON [dbo].[XXXXXX] REBUILD WITH (ONLINE=ON)它似乎永远不会成功。考虑到我可以在 15 秒内删除并重新创建它，3 小时对于在空闲数据库上看到成功来说已经绰绰有余了。

现在，我已经更改了我的维护脚本以过滤掉名称中带有“GlobalID”的索引，然后有一个删除/创建这些索引的后续脚本。直到我们开始对这些类型的列进行命名变体（即，我们需要一个 uniqueidentifier 用于其他目的）之前，我们一直在这样做。

知道为什么重建这些索引永远不会在合理的时间内完成吗？我看到这种情况发生在大约 12 个表中，所有表都具有基本相同的列/索引。

将生成多少日志索引重建。我记得读取重建索引应该生成与表大小相同数量的日志文件。但我的测试显示并非如此。我们需要这个估计，因为我们正在尝试构建 azure 数据库索引，它有一个限制最大 2 GB。

我的数据库处于完全恢复模式。

桌子尺寸：

日志大小：

从图片中您可以看到在线索引重建操作的日志生成量非常少。如果我遗漏了什么，有人可以纠正我吗

我可以在 SQL Server 2012/2014 上获得的最大密码大小是多少？我无法在网上找到这些信息。

我的意思是 SQL Server 凭据本身，而不是表中的密码。

非常感谢

我正在学习如何管理 MS Sql server 2012，遇到一个问题及其建议的解决方案，用于复制不同名称的现有数据库。

管理一个名为Orders的windows azure sql数据库，需要创建该表的副本并重命名为Order_Reporting

CREATE DATABASE Order_Reporting COPY OF Orders 

我想知道这样有用的查询是否也可以在标准 ms sql server 中使用？

这是此处表定义的一部分：

CREATE TABLE [dbo].[JobItems] (
[ItemId]            UNIQUEIDENTIFIER NOT NULL,
-- lots of other columns
CONSTRAINT [PrimaryKey_GUID_HERE] PRIMARY KEY NONCLUSTERED ([ItemId] ASC)
);

CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
ON [dbo].[JobItems]([ItemId] ASC);

这是一些遗留设计，所以请不要问“为什么”。无论如何，当我查找索引列表时，我看到有两个索引 - 其中一个是JobItemsIndex，另一个是PK-GUID-HERE，它们都用于JobItems表。

我的问题是...

为什么需要一个单独的索引来维护 PK，当我已经拥有JobItemsIndex它是唯一的并且包含非常相同的列并且适合维护 PK 约束时？

我一直在努力理解如何处理在这种情况下经常出现的特定类型的性能问题：当您想在查询中应用多个过滤器，但您知道第一个过滤器将返回一个非常小的数字时来自一个非常大的表的行。

例如，我们有一个包含 10M+ 行的 3rd-party 异构表，其中的列根据TYPEID. 这是一个示例查询：

SELECT ID, NAME, INT109 FROM DATA WHERE TYPEID = 8301514 AND INT109 = 1

在此查询中，两个过滤器没有覆盖索引，但在 'TYPEID' 列上有一个索引。令人困惑的是，即使表中的 10M 中只有大约 500 行TYPEID = 8301514，但此查询有时需要很多秒才能运行。

如果我只是INT109 = 1在最后删除过滤器，查询几乎立即运行：

SELECT ID, NAME, INT109 FROM DATA WHERE TYPEID = 8301514

对我来说，使用较少的过滤器会使查询运行得更快是没有意义的。此外，行为似乎不一致 - 如果第一个查询已经运行多次，它也可以运行得非常快，就像正在缓存某些东西一样。很难做可靠的实验（这是在 SQL Azure 中）。这是正常行为吗？这是否是由错误的执行计划（即使我没有使用参数）或过时的统计数据引起的？

我正在尝试在本地 SQL Server 和 Azure SQL 数据库之间设置事务复制。不幸的是，Azure SQL 似乎不支持 SQL Server 复制，而 Azure 数据同步似乎已被放弃（即使不支持，它也会在具有 200 多个表的数据库上窒息）。

在本地 SQL Server 和 Azure SQL 数据库之间设置连续事务复制有哪些替代方法？我的目标是只复制少数几个表，我希望它近乎实时地发生（而不是按计划进行）。

我只是观察到发布与模式比较的结果存在差异。我对 Visual Studio 数据库项目进行了更改 - 其中一些涉及删除表。

1. 将更改推送到 VSTS，构建成功，成功发布到 Azure DB
2. 检查说Azure DB。未删除在项目中删除的表。仔细检查发布脚本 - 这不包括任何掉落。
3. Ran SchemaCompare - 这暴露了所有丢失的删除，并且在执行时给了我预期的结果（适用的表被删除）。

手动发布与模式比较时，在本地数据库上观察到相同的结果。我做错了什么？我认为发布会删除表格。

我面前有一个有趣的问题。有一个数据库有大约 100 万个用户帐户，预计每年增长 1-200 万个。该数据库是强 TPT，但此特定查询和所涉及的表不涉及任何 TPT 内容。

当指定第二个数据点（即电子邮件地址和姓氏、公司等）时，sproc 和视图的当前设计需要大约 15 秒来执行 (x2)。该数据库是 SQL Azure P11，但它不是 DTU 绑定查询，升级到最高可用产品 (P15) 对结果没有影响。

下面是 sproc、视图和执行计划。在过去 24 小时内重建或重组了所有索引，并更新了所有统计信息。例如，在查看数据时，历史电子邮件地址 (1..N) 的概念目前正在使用 aCROSS APPLY来获取最新的，这可以防止索引视图，可以通过简单地连接历史电子邮件地址和持久化来解决它们在一个列中。

许多数据库在 nvarchar(4000-max) 列中使用 JSON，所有这些列都有一个公开值并启用索引的计算列。范式必须支持分页，我正在寻找有关如何优化它的反馈/建议。

在这一点上，更改表结构不是一个可行的选择，尽管我可以通过一点点操作看到前进的道路。有没有人对我应该首先看哪里有任何想法？我已经对未知的重新编译和优化进行了测试，以查看是否有任何影响，如果有，则可以忽略不计。

注意：一些业务逻辑（专有列名被删除或修改，sproc和view不能按原样执行，但在功能上与源相同。

执行计划和视图

程序

CREATE PROCEDURE [dbo].[spGetUserDetailsDynamic] @JsonFilter NVARCHAR(MAX)
AS /* Page number*/
DECLARE @Page AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.page');
/* Number of records on the page*/
DECLARE @Size AS INT = JSON_VALUE(@JsonFilter, '$.requestPaging.size');

IF (@Page = -1)
    SET @Page = 1;

IF (@Size …