MichaelD's questions

我们在一些 select 语句中使用 updlock 来确保只有一个连接可以读取数据。如果 SQL Server 可以从索引中获取所有数据，而另一个发出 updlock 的查询可以用另一个（非）聚集索引来满足，那么这似乎不起作用。

即使其他查询可以通过索引中的数据来满足，推荐的锁方法是什么？

例如，conn2 应该被阻塞直到 conn1 提交/回滚：

create database TestDB
go
use TestDB
go

create table LockTest(
    LockTestID int not null identity(1,1) primary key,
    Number int
)

create index IX_LockTest on LockTest(Number)

insert into LockTest(Number) values(1)


--Conn1
begin tran
select LockTestID from LockTest with(updlock) where LockTestID=1


--Conn2 -- The expectation here is, that this query waits untill Conn1 has committed
begin tran
select LockTestID from LockTest with(updlock) where Number=1

使用 holdlock 或 lock 可获得相同结果

我们有一张 CustomerNote 表，其中包含 4 列 ID、CustomerID、Note、Date

CustomerID asc 上有一个索引，Date desc

当执行以下查询时

select top 30 
    Date 
from CustomerNote
where CustomerID in (1,5)
order by Date desc

使用了索引，但它仍在为 customerID 的 1 和 5 获取所有 CustomerNotes，然后进行排序/置顶，导致大量 CPU 使用率。

这是由于“in”子句中的多个值。我知道“in”子句的值永远不会超过 10，因此如果 sql server 迭代 10，每个 customerID 至少获取 30 个，然后进行合并、排序和排序，这将是一个更好的方法。是否有查询提示或选项来实现此目的？

我们有 2 个完全相同的数据库环境。第二个环境包含生产数据库的副本，并在 Invoice 表中托管大约 11M 条记录。此环境的目标用于查看特定升级查询需要多长时间才能知道是否会有任何停机时间（因为表在架构更改期间被锁定）

在第二个环境中执行 add 语句时

alter table Invoice add IsVerified bit not null default(0)

查询立即退出，这很奇怪，因为其中有 11M 条记录。我预计至少会有一点延迟。即使是选择计数（*）也需要更长的时间。然而，在主生产数据库上，它需要更长的时间，超过 30 秒，因此我们必须将此查询计划到一个特殊的维护窗口中。在执行查询时，没有任何东西阻塞 SPID（使用 sp_who2 检查）

可能是什么原因，数据库的第二个副本似乎根本没有努力在 11M 记录数据库中添加一列，而另一个 maindb 无法及时完成（<30 秒）。也许一些特殊设置允许您添加一个默认值列而不需要写入所有记录？难道是因为我们的测试环境是开发版，而生产环境是标准版？也许开发版中的某些特殊功能在 SQLStandard 中不可用？

select count(*) from Invoice //result: 11701200
SQL Server Execution Times:
   CPU time = 2375 ms,  elapsed time = 608 ms.

要添加的脚本：

alter table Invoice add IsVerified bit not null default(0)
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 12 ms.

设置：

• 基本高可用性

• 2 个副本（1 个主副本，1 个辅助副本）。

  DB01 => 初始初级。

  DB02 => 初始二级

• 两者同步提交

• 两者都处于同步状态

• 没有配置监听器

• 集群类型 无

当我们使用 services.msc（模拟友好的服务器崩溃）停止 DB01（初始和当前主）SQL 服务，然后使用以下命令在 DB02（初始和当前辅助）上启动强制故障转移时：

ALTER AVAILABILITY GROUP [TestHA] FORCE_FAILOVER_ALLOW_DATA_LOSS;

辅助数据库上线，这是我们想要的。

但是，当使用 services.msc 再次启动 DB01 SQL Server 服务时，DB01 db 再次承担主要角色。

所以目前有 2 个实例可读/可写且不同步。我们期望初始主节点会检测到辅助节点已担任主要角色并承担次要角色，或者至少无法访问，因此应用程序无法处理旧数据。

相同的过程，但使用已弃用的镜像设置，确实会以这种方式运行。

我们的其中一个自定义日志表大小为 3TB。我们需要创建一个新索引。磁盘本身的读取速度为 10mbyte/sec。

这是否意味着索引创建过程将是 3.000.000/10 = 86 小时？索引被写入快速磁盘上的另一个文件组，因此写入时间不是一个因素。

使用 sql profiler，我们跟踪所有慢查询（过滤持续时间/读取）以查看我们可以优化的地方。使用的事件：

• RPC：已完成
• SQL：批处理完成

按持续时间过滤。

如果我添加事件 ShowPlan XML，那么我将无法过滤基础查询的持续时间，从而在每秒有成百上千的查询到达时产生巨大的负载

如何仅捕获与过滤器持续时间/从其他事件中捕获的查询的读取匹配的条目的执行计划？

我们有一个包含 190M 记录的表。在一个相当独特的列上有一个索引，但是，如果我在选择前 10 名的表上运行查询，其中只有 where 和 select 子句中的索引列，它仍然需要很长时间才能完成。

如果我打开实时查询计划 sql server 会显示“等待查询计划”等待微调器。如果查询最终完成，如果我再次运行它，它会立即完成。即使我之前运行 DBCC FREEPROCCACHE 所以感觉就像创建查询计划一直在占用，但是我无法通过在查询之前运行 DBCC FREEPROCCACHE 来重现。一段时间后，同样的问题将再次发生。

注意：数据库有 2 个文件组。索引和系统数据库存储在 SSD 磁盘上，而普通表数据存储在非 SSD 磁盘上。

我有一个带geometry列的表。对于一条记录，只Point存储一条。已创建空间索引，但搜索最近位置的查询不使用此索引，导致性能不佳。

示例脚本：

--Create the table
create table Location(
    LocationID int not null identity(1,1) primary key,
    LocationPoint geometry
)


--add records
declare @counter int =0
WHILE @counter<150000
BEGIN
    set nocount on
    --select 
    set @counter =@counter +1
    declare @RandomLocation geometry=geometry::Point(RAND() *1000, RAND() *1000, 0)     
    insert into Location(LocationPoint) values  (@RandomLocation)   
END

--create index
CREATE SPATIAL INDEX SPATIAL_StructureBE ON dbo.Location(LocationPoint)
USING GEOMETRY_GRID WITH ( 
    BOUNDING_BOX  = (xmin  = 0.0, ymin  = 0.0, xmax  = 1000, ymax  = 1000), 
    GRIDS = ( LEVEL_1  = MEDIUM, LEVEL_2  = MEDIUM, LEVEL_3  = MEDIUM, LEVEL_4  = MEDIUM),
    CELLS_PER_OBJECT  = 16, 
    STATISTICS_NORECOMPUTE = OFF, 
    ALLOW_ROW_LOCKS = ON, 
    ALLOW_PAGE_LOCKS = ON)

--Search, this query should use the index but it doesn't
declare @CurrentLocation geometry=geometry::Point(24,50, 0)
select top 1 *
from Location 
order by LocationPoint.STDistance(@CurrentLocation) asc

发送值的时间怎么可能大于镜像提交开销？镜像在完全安全的情况下运行，因此这意味着只有在提交成功@mirror 时才完成@principal 的提交。当发送时间为 2 秒时，这应该意味着开销至少为 2 秒。或者我错过了什么？

我成功地在两台服务器之间创建了一个带有证书的镜像。其中一台服务器是域控制器。删除域后，镜像被中断。经过数小时的搜索，我重新安装了 SQL Server，希望所有可能的域删除问题都会消失，但镜像仍然无法工作。我不断收到模糊的错误：

Msg 1418, Level 16, State 1, Line 1 服务器网络地址“TCP://...”无法访问或不存在。检查网络地址名称以及本地和远程端点的端口是否可操作。

如果我检查镜像服务器的事件日志，我会看到 2 个错误：

1. 加密操作失败。此错误表明 SQL Server 存在严重问题。检查 SQL Server 错误日志和 Windows 事件日志以获取更多信息。
2. Service Broker 或数据库镜像操作期间系统加密调用失败：系统错误“5（无法检索此错误的文本。原因：15105）”。

有什么想法/建议吗？