标签: azure-sql-database

我有一张大表的 I/O 问题。

一般统计

该表具有以下主要特征：

• 环境：Azure SQL 数据库（层为 P4 Premium (500 DTU)）
• 行数：2,135,044,521
• 1,275 个已用分区
• 聚集索引和分区索引

模型

这是表的实现：

CREATE TABLE [data].[DemoUnitData](
    [UnitID] [bigint] NOT NULL,
    [Timestamp] [datetime] NOT NULL,
    [Value1] [decimal](18, 2) NULL,
    [Value2] [decimal](18, 2) NULL,
    [Value3] [decimal](18, 2) NULL,
    CONSTRAINT [PK_DemoUnitData] PRIMARY KEY CLUSTERED 
    (
        [UnitID] ASC,
        [Timestamp] ASC
    )
)
GO

ALTER TABLE [data].[DemoUnitData] WITH NOCHECK ADD CONSTRAINT [FK_DemoUnitData_Unit] FOREIGN KEY([UnitID])
REFERENCES [model].[Unit] ([ID])
GO

ALTER TABLE [data].[DemoUnitData] CHECK CONSTRAINT [FK_DemoUnitData_Unit]
GO

分区与此有关：

CREATE PARTITION SCHEME [DailyPartitionSchema] …

我在 S2 版本 (50 DTU) 下运行 Azure SQL 数据库。正常使用服务器通常会挂在10%左右的DTU。但是，此服务器会定期进入一种状态，它将在数小时内将数据库的 DTU 使用率发送到 85-90%。然后突然间它恢复到正常的 10% 使用率。

在这种过载状态下，应用程序对服务器的查询似乎仍在快速运行。

我可以从 S2 => 任何东西（例如 S3） => S2 扩展服务器，它似乎清除了它挂在的任何状态。但是几个小时后它会再次重复相同的过载状态循环。我注意到的另一件奇怪的事情是，如果我在 S3 计划 (100 DTU) 24/7 上运行此服务器，我没有观察到这种行为。只有当我将数据库缩小到 S2 计划 (50 DTU) 时才会出现这种情况。在 S3 计划中，我始终保持 5-10% 的 DTU 使用率。显然没有得到充分利用。

我已经检查了 Azure SQL 查询报告以查找恶意查询，但我并没有真正看到任何异常，它显示我的查询使用资源，正如我所期望的那样。

正如我们在这里看到的，使用量都来自数据 IO。如果我在此处更改性能报告以显示 MAX 的顶级数据 IO 查询，我们会看到：

查看这些长期运行的查询似乎指向统计更新。并不是真正从我的应用程序运行的任何东西。例如，查询 16302 显示：

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS …

早些时候，对我来说，关于是否（总是）使用/避免聚集索引的辩论/讨论没有定论。

好吧，我知道它们有时会在适当的+特定目的和上下文中使用。

SQL Azure 数据库聚集索引要求：

“SQL Azure 不支持没有聚簇索引的表。一个表必须有一个聚簇索引。如果一个表是在没有聚簇约束的情况下创建的，那么在允许对该表进行插入操作之前必须先创建一个聚簇索引”

不符合先前的结论、理由和解释。

我在前面的解释中遗漏了严格要求无任何例外地普遍存在的聚集索引的基本原理是什么？

背景资料：

• 我正在创建一组审计表，以跟踪我的应用程序对一组数据表的更新和删除。
• 审计记录是通过触发器创建的。
• 我的应用程序数据库中的 DML 通常来自服务用于进入数据库的登录名。因此，我认为SYSTEM_USER在触发器中调用时，结果总是相同的。
• 我的应用程序当前不存储用户数据，尽管UserId每次完成 DML 时都会为其提供一个字符串（仅在存储过程中完成）。

我遇到的问题是，当用户删除记录时，我想知道是谁做的。因为它将通过相同的登录完成，我不想看到所有操作都是由服务完成的，我想看看是哪个用户完成的。这不是更新的问题，因为我们有ModifiedBy将通过发送的UserId更新来更新的列。

问题是：有没有办法在SYSTEM_USER运行删除时设置或以其他方式将用户信息放入触发器中？

我现在拥有的“最佳”想法，虽然我不确定这是否是一个好主意，但在服务中，我检查当前UserId是否以用户身份存在于数据库中，如果没有，则创建一个用户为他们反对。然后运行存储过程EXECUTE AS User = @UserId。然后当 DML 在存储过程中完成并且触发器触发时，SYSTEM_USER应该从EXECUTE AS.

我最近在我拥有的工作站上安装了 SQL Server 2014 Express，并正在尝试部署到 SQL Azure。我之前在使用 SQL Server 2012 Express 的以前的工作站上通过执行以下操作完成了此操作：

右键单击数据库 > 任务 > “将数据库部署到 SQL Azure”

在 SQL Server 2014 上，该选项完全丢失，取而代之的是一个新选项：“将数据库部署到 Windows Azure VM”

我不明白为什么缺少部署到 SQL Azure 的选项。现在是否需要为 SQL Server 2014 单独安装一些东西？从我在网上阅读的内容来看，2014 版应该有这两个选项。Microsoft 是否为 SQL Server 2014 Express 删除了此选项？

我们最近观察到在 Standard3 性能层中运行的 SQL Azure 数据库出现严重的性能下降 - CPU 利用率在短短一小时内从 10% 到 50% 上升到接近 100%。因此，我们将性能层更改为 Premium2，CPU 利用率立即下降到 8% 左右。

Standard3 声称提供 100 个 DTU，Premium2 声称提供 250 个 DTU。这意味着 8% 的 P2 只是 20 个 DTU，这与使用 Standard3 中的所有 100 个 DTU 相去甚远。

这些 DTU 是否不同？否则，从 100 DTU 性能层切换到 250 DTU 性能层时，这种利用率突然下降怎么可能？

我有一个支持 .NET Core API 应用程序的 Azure SQL 数据库。浏览 Azure 门户中的性能概览报告表明，我的数据库服务器上的大部分负载（DTU 使用情况）来自 CPU，特别是一个查询：

正如我们所见，查询 3780 负责几乎所有服务器上的 CPU 使用率。

这在某种程度上是有道理的，因为查询 3780（见下文）基本上是整个应用程序的关键，并且经常被用户调用。这也是一个相当复杂的查询，需要许多连接才能获得所需的正确数据集。查询来自一个最终看起来像这样的 sproc：

-- @UserId UNIQUEIDENTIFIER

SELECT
    C.[Id],
    C.[UserId],
    C.[OrganizationId],
    C.[Type],
    C.[Data],
    C.[Attachments],
    C.[CreationDate],
    C.[RevisionDate],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Favorites] IS NULL
            OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL
        THEN 0
        ELSE 1
    END [Favorite],
    CASE
        WHEN
            @UserId IS NULL
            OR C.[Folders] IS NULL
        THEN NULL
        ELSE TRY_CONVERT(UNIQUEIDENTIFIER, JSON_VALUE(C.[Folders], CONCAT('$."', @UserId, '"')))
    END [FolderId],
    CASE 
        WHEN C.[UserId] IS NOT NULL OR …

我们的团队继承了一个应用程序和相关的数据库。以前的开发人员似乎强制执行了一个规则，即每个表上的每个索引都有一个 INCLUDE 子句，以始终添加不属于键的每一列。这些表平均有两到五个索引或唯一约束以及外键。

目的似乎是提高 SELECT 性能，无论向数据库抛出什么查询，因为访问是通过 ORM 进行的，默认情况下（但并非总是）检索所有列。我们预计这样做的副作用是增加了存储需求（可能显着增加）和 INSERT/UPDATE/DELETE 的额外开销时间。

问题是，这是一个明智的策略吗？我们的团队有使用 SQL Server 的历史，但没有成员认为自己是其内部行为的专家（尽管有人提出问题，如果这种策略是最佳的，现在不是默认吗？）。我们应该期待哪些其他副作用（数据库服务器 CPU/内存/TempDB 使用等），或者我们上面的一些假设是不正确的？

此外，该应用程序可以安装到本地 SQL Server（自 2012 年以来的版本）以及 Azure SQL 中——我们是否应该为两者之间的任何差异做好准备，或者因此对 Azure 产生额外的副作用方法？

我有一个包含以下内容的示例数据文件，并使用 UTF8 编码保存。

oab~opqr\n\xc3\xb6ab~\xc3\xb6pqr\n\xc3\xb6ab~\xc3\xb6pqr\n

该文件的格式是固定宽度，第 1 至第 3 列各分配 1 个字符，第 4 列保留 5 个字符。

我创建了一个 XML 格式文件，如下所示

<?xml version = "1.0"?>  \n<BCPFORMAT xmlns="http://schemas.microsoft.com/sqlserver/2004/bulkload/format" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  \n   <RECORD>  \n      <FIELD xsi:type="CharFixed" ID="Col1" LENGTH="1"/>       \n      <FIELD xsi:type="CharFixed" ID="Col2" LENGTH="1"/> \n      <FIELD xsi:type="CharFixed" ID="Col3" LENGTH="1"/> \n      <FIELD xsi:type="CharFixed" ID="Col4" LENGTH="5"/> \n      <FIELD xsi:type="CharTerm" ID="LINE_BREAK" TERMINATOR="\\n"/> \n   </RECORD>  \n   <ROW>  \n      <COLUMN SOURCE="Col1" NAME="Col1" xsi:type="SQLNVARCHAR"/>  \n      <COLUMN SOURCE="Col2" NAME="Col2" xsi:type="SQLNVARCHAR"/> \n      <COLUMN SOURCE="Col3" NAME="Col3" xsi:type="SQLNVARCHAR"/>  \n      <COLUMN SOURCE="Col4" NAME="Col4" xsi:type="SQLNVARCHAR"/> …