标签: azure-sql-database

我有一个我删除的数据库，它曾经有一个“管理”选项，可以打开在线 sql 管理门户。

我创建了一个新数据库，现在我没有“管理”选项了。

当我尝试使用我的新服务器名称访问相同的 URL 时，我无法连接。

我在使用实体框架连接到这个新数据库时也遇到了问题。错误信息：

与 SQL Server 建立连接时发生与网络相关或特定于实例的错误。服务器未找到或无法访问。验证实例名称是否正确以及 SQL Server 是否配置为允许远程连接。（提供者：SQL 网络接口，错误：26 - 错误定位服务器/指定的实例）

我们在 SQL Azure v12 标准/S2 服务层上，对性能不满意，所以我试图衡量瓶颈在哪里。我意识到我们可能会达到 S2 服务层的限制。S2 有 50 个 DTU 和每分钟 2,570 个事务的限制。

内存压力： 我查看了sys.dm_exec_query_memory_grants并且没有未决的内存授予，并且正在授予请求的内存。页面预期寿命约为 600。

DTU 平均 DTU 似乎没有超过 50% 的单元化。avg_cpu_percent 和 avg_data_io_percent 很少超过 50%。avg_memory_usage_percent 保持在 99%。我从sys.dm_db_resource_stats

每秒事务数 如何衡量 SQL Azure 中的事务/秒？sys.dm_os_performance_counters事务/秒的 DMV没有用户数据库的任何值。它具有系统数据库的值。

我们的 SQL Azure 数据库包含一个SELECT每天运行一次的大量语句。沉重的SELECT语句不包含锁定提示。最近我们观察到生产中的一些停顿，这sys.dm_exec_requests是那段时间显示的内容......运行时间最长的查询是SELECT具有PAGEIOLATCH_SH等待类型的繁重查询。接下来是其他查询——最常见的INSERT是具有PAGEIOLATCH_EX等待类型的语句，所有语句都运行了几十秒而不是立即完成。所以基本上，SELECT只有重才会干扰其他查询。

我该如何解决？我可以接受SELECT缓慢运行的繁重工作，但不应中断其他查询。

很像swasheck 的一个相关问题，我有一个历史上曾遭受性能问题的查询。我正在查看 SSMS 上的查询计划并注意到Nested Loops (Inner Join)警告：

无连接谓词

根据一些仓促的研究（鼓舞人心的DBA和Brent Ozar 的信心），看起来这个警告告诉我我的查询中有一个隐藏的笛卡尔积。我已经检查了几次我的查询，但没有看到交叉连接。这是查询：

DECLARE @UserId INT; -- Stored procedure input
DECLARE @Now DATETIME2(7) = SYSUTCDATETIME();
;WITH AggregateStepData_CTE AS -- Considering converting this CTE into an indexed view
(
    SELECT 
        [UA].[UserId] -- FK to the UserId
        , [UA].[DeviceId] -- FK to the push device's DeviceId (int)
        , SUM(ISNULL([UA].[LatestSteps], 0)) AS [Steps]
    FROM [User].[UserStatus] [UA]
        INNER JOIN [User].[CurrentConnections] [M] ON 
           [M].[Monitored] = [UA].[UserId] AND …

我们正在将数据库从 Rackspace 迁移到 Azure。我们的数据库部署在机架空间中的虚拟机上。在我们的查询中，我们使用链接服务器到其他数据库。基本上是跨数据库查询。问题是，迁移数据库后，我们无法使用链接服务器查询，因为 Sql Azure db 不支持链接服务器。

请帮忙。

更新：

• 并非所有数据库都位于 Azure 中。有些数据库的所有者位于远程位置。我们需要查询在 Azure 外部运行的数据库。

• Azure 中没有适用于 Sql Server 的 VM。我们在 Azure 中使用数据库即服务。

请参阅下图了解更多详情

我们突然开始看到这个错误，而且在调用我们的弹性池中的数据库或任何其他数据库时，它似乎经常发生。DTU 没有被最大化，资源 dmvs 看起来也不错。

无法使用 HRESULT 0x80131022 进入公共语言运行时 (CLR)。这可能是由于低资源条件。（D b）

这是我从系统资源调控器池中得到的

Resource Pool Name           cache_memory (MB)   used_memory (MB)
internal                     104.773437          1577.125000
default                      37.609375           38.796875
SloSecSharedPool             2.914062            8.156250
InMemBackupRestorePool       26.210937           101.437500
InMemDmvCollectorPool        186.195312          203.406250
InMemMetricsDownloaderPool   2.234375            2.250000
InMemDTAPool                 0.000000            0.000000
SloHkPool                    0.000000            0.031250
InMemQueryStorePool          22.453125           35.304687
InMemWIAutoTuningPool        3.312500            4.062500
InMemXdbLoginPool            3.976562            6.250000
PVSCleanerPool               0.000000            0.000000
InMemTdeScanPool             0.000000            0.000000
SloSharedPool1               1108.890625         1234.312500

从 sys.dm_os_performance_counters 这是过去 3 小时的样子。

cpu%    data_io%   log_write%   memory_usage%   max_worker%   sessions%
22.37   73.51      16.54        41.56           5.50          0.43

这似乎不是 SQL Azure …

我试图找出上周遇到的一种情况，为了临时修复事件期间的计划回归，我使用查询存储强制执行计划，但发现它没有按预期工作。我已经阅读了安德鲁凯利关于如何被迫并不总是意味着被迫的文章，并认为这可能是我所看到的，但我希望对它有更深入的了解，因为在我的情况下，计划与我不同” d 期待。我还查看了有关计划强制的查询存储文档的计划强制限制部分，但我认为此处不适用任何限制。

查询存储中的视图如下所示 - 大约 8:30 出现了一个成本更高的新计划（2.14178 vs 0.894238），我强制执行了之前使用的计划。从图中可以看出，尽管我强制执行了旧计划，但从此时起，新计划将针对查询的指标显示：

查看 sys.query_store_plan，我可以看到旧计划显示为强制的并且没有任何反对意见，表明强制执行失败：

奇怪的是，当我后来查看计划缓存时，这些计划都没有使用，尽管使用中的计划确实具有与上面显示的计划 13449 相同的查询计划哈希值，尽管它们完全不同。实际使用的计划的估计成本要高得多，为 72.6743。

我从这些计划中的每一个中获取了编译值，并运行了对其中三个计划的查询，以了解计划的实际指标是什么样的，并且这些值与估计值大不相同。值得注意的是，我从缓存中获取的计划产生了大约 400 MB 的内存授予，因为它使用不同的索引并且必须对数据进行排序，而其他 2 个计划中的 8 MB 内存授予没有排序。三个计划的估计成本更接近一些，但查询存储中的 2 个计划的估计成本比查询存储中显示的计划高得多。

这是发生的查询：

(
    @id_group int,
    @create_date datetime,
    @rows_per_page int,
    @page_number int
)
SELECT *
FROM ts_customer
WHERE 
    id_group = @id_group 
    AND enabled = 'Y'
    AND (create_date >= @create_date)
ORDER BY 
    full_name, 
    id_customer desc
offset 
    ((@page_number - 1) * @rows_per_page) rows
    fetch next @rows_per_page rows only

谁能帮助我理解为什么不强制执行该计划，以及为什么正在使用的计划要贵得多？

我知道这select *会导致大内存授予，因为它是一个宽表，但我主要是想了解这里看到的查询存储行为，以及在较小程度上，为什么在使用而不是强制的计划中计划它使用不同的索引并且必须进行排序。 …

我正在设计一个包含很多行的表。所以需要注意不要存储太多信息。其中一列是 NVARCHAR(MAX) 列，它包含我们客户的地址。由于地址不经常更改，此列将包含许多重复值，因此包含相当多的冗余。

所以我想知道我是否需要通过维护某种查找表来解决字符串来规范化（请注意，如果地址发生变化，我需要维护历史记录 - 所以这不是通常的规范化问题），或者如果 SQL Server指向幕后字符串的相同引用。或者它可能提供了一个列选项来这样做。我想到的另一种方法是使用 COMPRESS，但我想这没有意义，因为数据本身（即地址）不长。

读/写性能不是那么重要，因为数据会随着时间的推移而累积。

我在使用 Azure SQL Server PAAS 的实时环境中遇到了很多我不理解的页面拆分。正在发生的更新不应增加行的大小，因此永远不会导致页面拆分。此外，该行为仅发生在 Azure 中，不会发生在本地 SQL 实例上。

我使用的是使用 eDTU 定价和标准层 (200 eDTU) 的 Azure 弹性池。

我创建了以下示例来演示：

create table dbo.TestSplit
(
    TestSplitId int not null identity,
    MyInt int not null,
    
    constraint PK_C_dbo_TestSplit_TestSplitId primary key clustered (TestSplitId)
);

插入 100,000 行且 MyInt = 5：

insert into dbo.TestSplit
(MyInt)
select top(100000) 5
from sys.columns AS a 
cross join sys.columns AS b 
cross join sys.columns AS c

运行以下 SQL 显示已创建 384 个页面，并且有 2 个碎片。

select
    ix.name as index_name,
    st.index_type_desc,
    st.fragment_count,
    st.page_count …

我发现本地计算机上的查询计划和 Azure SQL 上的查询计划之间存在奇怪的差异。我正在尝试实现行级安全性，其中我从 SESSION_CONTEXT 读取用户标识符，然后在 TVF 中检查用户是否具有访问权限。

在我的本地计算机上 - SQL Server 2019 Developer Edition，兼容级别 150 的数据库，查询计划符合预期。但是当我在兼容级别为 150 的 Azure DB 上运行它时，我只能获得带有NonParallelPlanReason="NonParallelizableIntrinsicFunction". 我尝试了超大规模数据库以及弹性池中的数据库，两个数据库的结果相同。

您可以使用以下代码重现该内容：

CREATE TABLE Users (
    UserIdentifier nvarchar(100) PRIMARY KEY CLUSTERED
)

INSERT INTO Users (UserIdentifier) VALUES ('MyUserIdentifier')

CREATE TABLE TableWithRLS (
    Id int NOT NULL IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    DataColumn nvarchar(100) NULL
)

INSERT INTO TableWithRLS (DataColumn) 
SELECT TOP 10000000 A.[name] FROM sys.all_columns  AS A
CROSS JOIN sys.all_columns  AS B
CROSS JOIN sys.all_columns  AS C …