标签: azure-sql-database

我有一个表，该表当前在一列中有重复的值。

我无法删除这些错误的重复项，但我想防止添加其他非唯一值。

我可以创建一个UNIQUE不检查现有合规性的吗？

我曾尝试使用NOCHECK但未成功。

在这种情况下，我有一个表格将许可信息与“公司名称”联系起来

编辑：具有相同“公司名称”的多行是错误数据，但我们目前无法删除或更新这些重复项。一种方法是让INSERTs 使用一个存储过程，该过程将因重复而失败......如果可以让 SQL 自行检查唯一性，那将是可取的。

此数据按公司名称查询。对于少数现有的重复项，这意味着返回并显示多行...虽然这是错误的，但在我们的用例中是可以接受的。目的是防止将来发生。从评论看来，我必须在存储过程中执行此逻辑。

我有一些使用 Entity Framework Code First 创建的数据库；应用程序正在运行，总的来说，我对 Code First 让我做的事情感到非常满意。我首先是一名程序员，其次是 DBA，这是必要的。我正在阅读 DataAttributes 以在 C# 中进一步描述我希望数据库执行的操作；我的问题是：将这些nvarchar(max)字符串放在我的桌子上会吃什么惩罚（见下面的例子）？

在这个特定的表中有几列；在 C# 中，它们是这样定义的：

    [Key]
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Message { get; set; }
    public string Source { get; set; }
    public DateTime Generated { get; set; }
    public DateTime Written { get; set; }

我希望根据名称、来源、生成和书面内容进行查询和/或排序。我希望 Name 和 Source 的长度为 0-50 个字符，有时可达 150 个。我希望这个表开始时很小（<100k 行），但随着时间的推移显着增长（>1m 行）。显然消息可以是小或大的，并且可能不会被查询。

我想知道的是，我的 Name 和 Source …

我需要将本地 SQL Server 2017 数据库迁移到 Azure SQL 数据库，但我面临着一些挑战，因为要克服很多限制。

特别是，由于 Azure SQL 数据库仅在 UTC 时间（无时区）下工作，而我们需要本地时间，因此我们必须更改数据库中GETDATE() 各处的使用，事实证明，这比我预期的要多。

我创建了一个用户定义的函数来获取适合我的时区的本地时间：

CREATE FUNCTION [dbo].[getlocaldate]()
RETURNS datetime
AS
BEGIN
    DECLARE @D datetimeoffset;
    SET @D = CONVERT(datetimeoffset, SYSDATETIMEOFFSET()) AT TIME ZONE 'Pacific SA Standard Time';
    RETURN(CONVERT(datetime,@D));
END

我遇到的问题是GETDATE()在每个视图、存储过程、计算列、默认值、其他约束等中实际更改此函数。

实施此更改的最佳方法是什么？

我们正处于托管实例的公共预览版中。它仍然有同样的问题GETDATE()，所以它对这个问题没有帮助。迁移到 Azure 是一项要求。这个数据库总是在这个时区使用（并将被使用）。

我再次发现 SQL Server 和 MERGE 语句存在问题，需要进行一些确认。

我可以在 Azure 数据库上不断重现我的问题（但不能在本地 SQL Server 2017/2019 上重现）。

请执行以下步骤（一步一步，而不是一次命令执行）！

1）架构脚本：

    CREATE TABLE [dbo].[ImpactValueHistory]
    (
        [Rn] BIGINT NOT NULL,

        [ImpactId] UNIQUEIDENTIFIER NOT NULL,
        [ImpactValueTypeId] INT NOT NULL,

        [Date] DATE NOT NULL,
        [Value] DECIMAL(38, 10) NOT NULL,

        [ValidFrom] DATETIME2 NOT NULL CONSTRAINT [DF_ImpactValueHistory_ValidFrom] DEFAULT CONVERT(DATETIME2, '0001-01-01'),
        [ValidTo] DATETIME2 NOT NULL CONSTRAINT [DF_ImpactValueHistory_ValidTo] DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),

        [ImpactPeriodId] INT NOT NULL,

        [NormalizedValue] DECIMAL(38, 10) NOT NULL,
    )
    GO

    CREATE CLUSTERED COLUMNSTORE INDEX [COLIX_ImpactValueHistory]
        ON [dbo].[ImpactValueHistory];
    GO

    CREATE NONCLUSTERED …

我想修改 SQL Azure 表上的现有主键。
它目前只有一列，我想添加另一列。

现在，在 SQL Server 2008 上这是小菜一碟，只是在 SSMS 中做到了，噗。完毕。如果我从 SQL Server 编写 PK，这就是 PK 的样子：

ALTER TABLE [dbo].[Friend] ADD  CONSTRAINT [PK_Friend] PRIMARY KEY CLUSTERED 
(
  [UserId] ASC,
  [Id] ASC
)

但是，在 SQL Azure 上，当我尝试执行上述操作时，它当然会失败：

Table 'Friend' already has a primary key defined on it.

很好，所以我试着放下钥匙：

Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again.

好的，所以我尝试创建一个临时聚集索引以删除 PK：

CREATE CLUSTERED INDEX IX_Test ON [Friend] ([UserId],[Id])

结果是： …

我有这张桌子：

CREATE TABLE [dbo].[Accounts] (
    [AccountId] UNIQUEIDENTIFIER UNIQUE NOT NULL DEFAULT NEWID(),
    -- WHATEVER other columns
);
GO
CREATE UNIQUE CLUSTERED INDEX [AccountsIndex]
    ON [dbo].[Accounts]([AccountId] ASC);
GO

这个查询：

DECLARE @result UNIQUEIDENTIFIER
SELECT @result = AccountId FROM Accounts WHERE AccountId='guid-here'

使用由单个索引查找组成的查询计划执行 - 正如预期的那样：

SELECT <---- Clustered Index Seek

此查询执行相同的操作：

DECLARE @result UNIQUEIDENTIFIER
SET @result = (SELECT AccountId FROM Accounts WHERE AccountId='guid-here')

但它是按照一个计划执行的，其中索引查找的结果与一些常量扫描的结果左外连接，然后输入计算标量：

SELECT <--- Compute Scalar <--- Left Outer Join <--- Constant Scan
                                      ^
                                      |------Clustered Index Seek

什么是额外的魔法？常量扫描后跟左外连接有什么作用？

我想在 Azure SQL 数据库 V12 上试用包含的数据库用户功能，但是我遇到了一个对我来说似乎很奇怪的身份验证问题。

我创建了一个名为Classifier. 我将我的 IP 添加到防火墙规则中，以便我可以从工作站上的 SSMS 连接到 Azure db 服务器。一旦我能够通过 SSMS 连接以进行管理，我尝试向数据库添加一个带有密码的用户，如下所示：

CREATE USER classifier WITH PASSWORD='thepassword'

我还将此用户添加到数据写入者和读取者角色中：

exec sp_addrolemember 'db_datawriter', 'classifier'
exec sp_addrolemember 'db_datareader', 'classifier'

在此之后，我可以使用来自 SSMS 的这些凭据连接到数据库：

但这就是事情出错的地方：我尝试了几种不同的连接字符串咒语，但似乎无法在我正在开发的网络应用程序中建立连接。它在 Azure 环境中不起作用，所以我在 localhost 上运行，并带有到 Azure 数据库的连接字符串，但它无法连接。这是我目前使用的连接字符串：

<add name="Classifier" connectionString="Data Source=xxxxxxx.database.secure.windows.net;Initial Catalog=Classifier;User ID=classifier;Password=xxxxxxxxxxxxx;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" providerName="System.Data.SqlClient"/>

我尝试为用户重置密码（通过 SSMS），然后更新连接字符串；我还通过将密码从该连接字符串中复制到 SSMS 中的连接对话框中来仔细检查密码，以确保那里没有某种类型的拼写错误。

我在 Azure db 服务器中启用了审计，希望得到一些关于它失败原因的详细信息，但我得到的只是：

这就是我被困的地方。我通过文档或博客找到的大部分内容表明要做的是查看 SQL Server 日志以查看真正的错误状态是什么，这将更狭隘地表明失败的性质，但是由于我正在处理 Azure 没有办法做到这一点（据我所知）。

什么会导致应用程序在 SSMS（以及 LinqPad 和 Visual Studio Server Explorer，顺便说一句）成功的情况下失败？

这是破败：我在做一个选择查询。WHEREandORDER BY子句中的每一列都在一个非聚集索引中IX_MachineryId_DateRecorded，或者作为键的一部分，或者作为INCLUDE列。我正在选择所有列，因此将导致书签查找，但我只使用TOP (1)，因此服务器肯定会告诉查找只需要在最后完成一次。

最重要的是，当我强制查询使用 index 时IX_MachineryId_DateRecorded，它会在不到一秒的时间内运行。如果我让服务器决定使用哪个索引，它会选择IX_MachineryId，并且最多需要一分钟。这真的向我表明我已经正确地建立了索引，而服务器只是做出了一个错误的决定。为什么？

CREATE TABLE [dbo].[MachineryReading] (
    [Id]                 INT              IDENTITY (1, 1) NOT NULL,
    [Location]           [sys].[geometry] NULL,
    [Latitude]           FLOAT (53)       NOT NULL,
    [Longitude]          FLOAT (53)       NOT NULL,
    [Altitude]           FLOAT (53)       NULL,
    [Odometer]           INT              NULL,
    [Speed]              FLOAT (53)       NULL,
    [BatteryLevel]       INT              NULL,
    [PinFlags]           BIGINT           NOT NULL,
    [DateRecorded]       DATETIME         NOT NULL,
    [DateReceived]       DATETIME         NOT NULL,
    [Satellites]         INT              NOT NULL,
    [HDOP]               FLOAT …

我有一个托管在 Azure 上的 SQL 数据库。问题是大小越来越失控，我可以在主键聚集索引中看到高达 99% 的碎片。

我可以使用online=on选项重建所有其他索引，并且不会影响性能。PK Clustered 索引之一的大小大于 200GB，因此 aREBUILD...WITH (ONLINE=ON)会导致锁定。

我们确实有来自所有时区的用户访问该站点，所以真的，我无法找到可以离线重建索引的时间。

在站点不停机的情况下重建大型索引的最佳策略是什么？

我相信重组无济于事，因为碎片化是 99%。问题是即使在线，表也会被锁定。主要问题是索引大于200GB。主键是一个整数。

当使用子查询查找具有匹配字段的所有先前记录的总数时，在只有 50k 条记录的表上性能很差。如果没有子查询，查询会在几毫秒内执行。对于子查询，执行时间超过一分钟。

对于此查询，结果必须：

• 仅包括给定日期范围内的那些记录。
• 包括所有先前记录的计数，不包括当前记录，无论日期范围如何。

基本表模式

Activity
======================
Id int Identifier
Address varchar(25)
ActionDate datetime2
Process varchar(50)
-- 7 other columns

示例数据

Id  Address     ActionDate (Time part excluded for simplicity)
===========================
99  000         2017-05-30
98  111         2017-05-30
97  000         2017-05-29
96  000         2017-05-28
95  111         2017-05-19
94  222         2017-05-30

预期成绩

对于日期范围2017-05-29，以2017-05-30

Id  Address     ActionDate    PriorCount
=========================================
99  000         2017-05-30    2  (3 total, 2 prior to ActionDate)
98  111         2017-05-30    1  (2 total, 1 prior to ActionDate) …