Question

与我们的Web应用程序的不同环境（例如生产，登台）相对应的数据库位于同一Azure SQL数据库服务器上。当我到处阅读that an Azure SQL server is just a logical container（并且其中的DB可能甚至不在同一台物理计算机上）时，我们看到DB表现为嘈杂的邻居，即对其中一个进行的操作会影响其他DB的性能。

我们已经看到以下操作和指标在数据库之间发生关联。我们将一个数据库称为“ prod”，将另一个称为“ stage”；在所有情况下，都是通过使用Start-AzureWebAppSqlDatabaseCopy PowerShell命令集复制prod来创建阶段的。

扩展阶段与产品上的数据IO峰值相关。
阶段性运行性能繁重的操作（删除数千个表，更新约10,000行）与SQL连接超时（“在操作完成之前超时时间或服务器没有响应。”）和数据相关产品上的IO激增。

在两个数据库中，我们使用单独的数据库级用户帐户（有关原因，请参见this SO post），但是prod和stage用户帐户都在两个DB下都存在（即，我们使用阶段用户连接到阶段） DB，但阶段用户也存在于prod DB下，并且prod用户也存在于stage DB下）。我们从商品数据库中删除了阶段用户，以查看是否有区别，但这没有影响。

可能值得注意的是，当逐步淘汰Web / Business Azure SQL层时，这些数据库已从Web迁移到其当前的S1层。我们也看到另一台服务器上的数据库存在相同的问题。数据库不是弹性池的一部分。

我们的发现尚无定论，并且这些事件也不与100％的时间相关。我们不确定要调查什么，因为我们确定舞台应用程序未连接到产品数据库。我们试图找到证明舞台应用程序以某种方式影响产品数据库的证据，但我们没有。任何输入将不胜感激。

更新1

使用Grant的sys.dm_os_wait_stats技巧和sys.dm_os_performance_counters，很明显，是的，如果您在同一逻辑服务器上复制数据库，则它也将在同一物理SQL Server上创建。。 object_name中的服务器名称相同，等待值完全相同。

但是，这并不能解释为什么副本上的操作会影响原始数据库。由于似乎并不是一直都在发生嘈杂的邻居效应（向上扩展在大多数情况下确实会影响原始数据库，因此对性能要求较高的操作的影响较小，但相关性仍然很明显），它可能是某种随机的Azure问题。

我们将查看是否使用其他逻辑服务器可以解决此问题。可以确定的是，在这种情况下，物理服务器也会有所不同。

更新2

我们正在监视局势，但是这是否确实能够解决问题，只有在几个月后才能显现出来。目前，我们已将所有数据库放在单独的服务器上。

我们确实注意到，在阶段DB上的所有操作完成之后，产品DB总是在相同的时间间隔中超时。但是，这些超时似乎仅在表创建时发生。就像将prod DB复制到Stage DB之后，prod DB在一段时间（大约45-60分钟）内被“锁定”，并且您不能创建表（但是可以删除它们，这些工作）。有趣的是，今天没有发生这种情况，所以也许它已经解决了……

Answer 1

从您提供的信息中，我怀疑问题是数据库的工作负载有时会占用大量I / O，达到了层限制，并且Azure SQL开始受到限制。这种节流可能是在这些超时之后。

请使用以下查询监控资源消耗：

SELECT 
    (COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent'
    ,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent'
    ,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats

99.9％的服务水平目标（SLO）<=进入下一层。

测量一段时间内的DTU消耗。以下查询显示DTU使用率很高时，您是否超时？

SELECT start_time, end_time,   
  (SELECT Max(v)    FROM (VALUES (avg_cpu_percent), (avg_data_io_percent),
   (avg_log_write_percent)) AS value(v)) as [avg_DTU_percent] 
FROM sys.resource_stats where database_name = 'AdventureWorksLT'  order by end_time desc

比较DTU使用率与DTU限制。

SELECT 
 end_time AS [EndTime]
  , (SELECT Max(v) FROM (VALUES (avg_cpu_percent), (avg_data_io_percent), (avg_log_write_percent)) AS value(v)) AS [AvgDTU_Percent]  
  , ((dtu_limit)*((SELECT Max(v) FROM (VALUES (avg_cpu_percent), (avg_data_io_percent), (avg_log_write_percent)) AS value(v))/100.00)) AS [AvgDTUsUsed]
  , dtu_limit AS [DTULimit]
FROM sys.dm_db_resource_stats

Answer 2

确定这种情况的方法是将sys.dm_os_wait_stats与sys.dm_db_wait_stats一起使用。操作系统等待统计信息用于数据库正在运行的“服务器”，而数据库等待统计信息用于数据库。收集db等待有问题的两个数据库，而os等待两个数据库。首先，直接比较os等待。如果它们是相同的（有一点余地，我不希望它们完全相同，尽管如果有的话，这是您的答案），您可能会在同一台服务器上看到所有内容。如果它们不是真的相同，但是有点相似，则将每个数据库的db等待状态与OS等待状态进行比较，看看是否可以看到直接相关。

仅出于管理目的，即使通常这不是问题，我仍可能会将它们分别放在不同的服务器上。但是，如果可以找到相关性，那么最好的选择就是将服务器分开。它不会花费您任何费用。您需要为数据库而不是服务器付费。

同一台服务器上的Azure SQL数据库会彼此影响性能

2 个答案: