标签: azure-sql-database

例如，如果 SQL 代理不适用于 Azure SQL 数据库，那么是否可以使用 Ola Hallengren 的维护脚本来维护（索引、统计等）数据库？

我编写了代码将记录更新到数据库。数据库是Azure DB，S4层。

更新和插入有时是高度并发的，因为它来自执行太多更新的应用程序。

该代码在大多数情况下都能成功运行，但有时会抛出 2627 异常（在 CATCH 语句内部处理）。到目前为止还无法弄清楚可能是什么问题。

我可以用 MERGE 语句替换它，但是我不太喜欢它，并且还想弄清楚这个 try and catch 发生了什么。

SET nocount ON;
IF NOT EXISTS(SELECT * FROM MyTable WHERE ID = @ID)
BEGIN TRY
INSERT INTO Table(ID, Value, TimeChanged) VALUES (@id, 'xxx', GETDATE())
END TRY
BEGIN CATCH
IF @@Error <> 2627 ----Violation of PRIMARY KEY constraint
THROW;
END CATCH

UPDATE MyTable SET Value = 'xxx' WHERE ID = @ID AND TimeChanged < GETDATE()

我正在寻求有关 SQL Azure 版本和升级的一些说明。在尝试使用某些特定功能时，我注意到数据库的兼容性级别是 100（我需要 130）。进一步查看后，我发现引擎版本被报告为12.0.2000.8（相当于 SQL Server 2014），但我需要最低引擎版本为 13.x才能使用兼容性级别 130。

我需要做什么来升级此 SQL Azure 实例的引擎版本？在 Azure SQL 数据库中热修补 SQL Server 引擎一文具体指出：

Azure SQL 数据库是常青树，这意味着它始终拥有最新版本的 SQL 引擎

此外，像这样的答案意味着引擎将始终是最新版本，但报告的版本将不正确。

这是否意味着我可以忽略报告的引擎版本并继续设置兼容性级别，或者我需要采取其他步骤来升级引擎？

我这里说的是sql server。

我可以连接到天蓝色。我还可以管理权限。

但是在进行一些自动化操作时，我需要知道我是在天蓝色还是普通sql中。我怎样才能做到这一点？

我一直在使用@@版本。不过，据说并不准确。

我有一个宽表，相对较大，有 14,264,775 行，在 Azure SQL 数据库上运行。

以下查询需要一些 TLC。

IF EXISTS (
    SELECT  1/0 
    FROM dbo.table1 src
      INNER JOIN dbo.table1 tgt 
        ON tgt.Col1 = src.Col1
    WHERE tgt.ValidFrom <= src.ValidTo
    AND tgt.ValidTo >= src.ValidFrom
    AND tgt.RecordId <> src.RecordId  
)
 BEGIN
    RAISERROR('Overlap detected in dbo.table1', 11, 1); 
 END ;

我有这个索引。

CREATE NONCLUSTERED INDEX [IX__table1] ON dbo.table1
        ( Col1 ) 
INCLUDE (ValidFrom, ValidTo, RecordId)
GO

这是查询的 io 统计信息。逻辑阅读能力非常出色。

这是计划 XML。我尝试了 PasteThePlan，但它无法解析计划 XML。（也许它不喜欢Axure sql数据库计划xml）。

如您所见，[src] 上有一个索引扫描；读取 14,264,775 行（与表中的所有行数相同）。并在 [tgt] 上进行索引查找；读取 194,405,307 行。

我需要改变什么来提高查询的性能？ …

我正在重构数据库。有一个过程在两个表中的一个中插入一行，并且 id 需要在两个表中是唯一的。

目前，应用层会遍历预定的键数组。

我正在考虑 aSequence生成下一个 id，与 a 相关联SELECT MAX(id) + 1。

使用 Sequence 是否可以实现任何性能提升？

（在 Azure 中运行的 SQL Server 12.0.2000.8）

我的理解是 REORGANIZE 索引不应该干扰其他操作（也就是说，它不应该阻止对正在进行索引重组的表的查询，当然也不应该阻止对其他表的查询）。但是，我有一个夜间索引维护作业，它似乎在运行时阻塞了其他查询。

导致阻塞的查询格式为：

ALTER INDEX [indexName] ON tableName REORGANIZE

它导致其他查询等待，即使是简单的查询，例如：

SELECT * FROM tableName WHERE indexedColumn = @value

我使用该sp_who2过程来查看哪些查询正在等待，以及它们被哪些其他查询阻止。再一次，正在进行索引维护的表和 SELECT 中的表完全不相关（它们甚至在不同的模式中；FWIW 被重组的表在 中dbo）。

被重组的表有近 5 亿行。受影响的索引是外键使用的单个 bigint 列上的非聚集、非唯一索引。表本身由两个 bigint 列、一个 tinyint 和几个小 nvarchars 组成。

看起来没什么特别的，但我不明白为什么它会阻止其他查询。是否有一些我遗漏的隐藏依赖？

确定行或页或列存储压缩（或无）对于用于 OLTP（其中不支持sp_estimate_data_compression_ savings）的 Azure SQL 数据库（标准层或高级层）中的每个索引最有效的最有效方法是什么？

我意识到这样做是否有利于性能取决于每个索引的写入频率和数量。还应考虑哪些其他因素？

（我意识到是否对分区索引使用列存储是一个复杂的问题，我认为这超出了此请求的范围。）

我有一张表存储客户信息（您的沼泽标准 CRM 资料）：

CREATE TABLE dbo.Customers (
    TenantId    int            NOT NULL,
    CustomerId  int            NOT NULL,
    
    FirstName   nvarchar(50)   NOT NULL DEFAULT '',
    LastName    nvarchar(50)   NOT NULL DEFAULT '',
    CompanyName nvarchar(50)   NOT NULL DEFAULT '',

    Notes       nvarchar(4000) NOT NULL DEFAULT ''
)

此表最近已转换为 SQL Server 时态表：

ALTER TABLE dbo.Customers
    ADD COLUMN
        SysStart datetime2(7) GENERATED ALWAYS AS ROW START NOT NULL,
        SysEnd   datetime2(7) GENERATED ALWAYS AS ROW END   NOT NULL;

GO

ALTER TABLE dbo.Customers WITH (
    PERIOD FOR SYSTEM_TIME ( SysStart, SysEnd ), …

我一定是在某个地方遗漏了一些东西..

Azure SQL

DispatchedOn is a DateTime column

ALTER TABLE [table] WITH CHECK ADD CONSTRAINT [CK_ReportDate6MonthRollGreater] CHECK  ((CONVERT([date],[DispatchedOn])>='2022-12-07'))
GO

ALTER TABLE [table] CHECK CONSTRAINT [CK_ReportDate6MonthRollGreater]
GO

我可以插入日期 2022-12-01

不确定这个问题是否在这里被认为是合适的，但看看这个版本历史记录： https: //en.wikipedia.org/wiki/History_of_Microsoft_SQL_Server 似乎 Azure SQL 数据库自 2014 年以来就没有更新过。这种解释正确吗？

我注意到 Azure SQL 数据库的实例不知道RowVersion数据类型，这让我感到惊讶并促使我查看版本历史记录。我知道我可以使用timestamp代替RowVersion，但我想知道是否有过去十年中引入的任何有用功能我必须放弃，因为我使用的是 Azure SQL 数据库而不是 SQL Server。

对于那些投票关闭的人：如果社区决定关闭，我不会冒犯，但出于辩护，如果我的谷歌查询找到了这个问题和相关答案而不是维基页面，我会得到更好的信息。