数据库管理员

问题 我有一对可串行隔离的查询，它们导致RX-X锁定。但是，当我使用扩展事件来观察锁获取时，RX-X锁获取从未出现，它仅被释放。它从何而来？ 再现 这是我的桌子： CREATE TABLE dbo.LockTest ( ID int identity, Junk char(4) ) CREATE CLUSTERED INDEX CX_LockTest --not unique! ON dbo.LockTest(ID) --preload some rows INSERT dbo.LockTest VALUES ('data'),('data'),('data') 这是我的问题批次： SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN INSERT dbo.LockTest VALUES ('bleh') SELECT * FROM dbo.LockTest WHERE ID = SCOPE_IDENTITY() --ROLLBACK …

13 sql-server  locking  sql-server-2017 

我正在执行带有physical_only选项的checkdb，并且失败，并显示以下多个错误： 消息8965，级别16，状态1，第1行 表错误：对象ID 1557580587，索引ID 1，分区ID 72057594088456192，分配单元ID 72057594177454080（类型为行内数据）。页面（1：13282192），插槽3，文本ID 6370769698816的行外数据节点由页面（0：0），插槽0引用，但未在扫描中看到。消息8965，级别16，状态1，第1行 表错误：对象ID 1557580587，索引ID 1，分区ID 72057594088456192，分配单元ID 72057594177454080（类型为行内数据）。页面（1：13282192）插槽5的行外数据节点由页面（0：0）插槽0引用文本ID 6370769764352，但在扫描中未看到。 CHECKDB在表'TableX'（对象ID 1557580587）中发现了0个分配错误和5255个一致性错误。CHECKDB在数据库'DatabaseX'中发现0个分配错误和5255个一致性错误。repair_allow_data_loss是DBCC CHECKDB（DWH_LAND）发现的错误的最低修复级别。 但是完整的checkdb是成功的： CHECKDB在数据库'DatabaseX'中发现0个分配错误和0个一致性错误。DBCC执行完成。如果DBCC打印了错误消息，请与系统管理员联系。 TableX大约有20万行，并在其上具有群集的列存储索引。 我们正在使用以下版本的SQL Server： Microsoft SQL Server 2017（RTM-CU13）（KB4466404）-14.0.3048.4 我应该担心吗？

13 sql-server  sql-server-2017  dbcc-checkdb 

我在4个vCPU VM运行Microsoft SQL Server 2016 SP2-CU6（13.0.5292.0）与max degree of parallelism设置为2和cost threshold for parallelism设置为50。 早晨，当尝试显示SELECT TOP 100查询的估计执行计划时，我遇到了大量的等待，渲染估计计划的操作需要花费几分钟，通常是5到7分钟。同样，这不是查询的实际执行，这只是显示“ 估计的执行计划”的过程。 sp_WhoIsActive将显示PAGEIOLATCH_SH等待或LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待，当我在操作期间运行Paul Randal的WaitingTasks.sql脚本时，它将显示CXPACKET等待，而工作线程显示PAGEIOLATCH_SH等待： *资源描述字段= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen 工作线程看起来是将整个stats表都放入内存中（因为从Paul Randal的查询中显示的那些页号以及后续页号都指向该stats表的集群键）。一旦计划恢复，即使在stats剩余的各种记录（我认为由于类似查询的查找操作而将其拉出）的情况​​下，大部分缓存都从高速缓存中消失之后，一天中的剩余时间基本上都是瞬时的。 如果查询实际上是使用SCAN运算符的计划执行的，我会期望出现这种初始行为，但是为什么在评估执行计划时才这样做（如上面链接的计划所示），以达到SEEK运算符呢？我该怎么办（除了在办公时间之前运行此语句，以便适当地缓存我的数据），以帮助提高此处的性能？我假设一对覆盖索引将是有益的，但是它们真的可以保证行为的任何改变吗？我必须在这里在一些存储和维护窗口限制内工作，并且查询本身是从供应商解决方案生成的，因此，此时欢迎任何其他建议（除了更好的索引编制）。

13 sql-server  performance  sql-server-2016 

磁盘驱动器（松散地说不仅包括旋转介质，还包括非旋转介质[SSD，NVMe等]）正在以其基本格式和硬件不断发展。其中一部分是从512字节物理扇区大小到4k物理扇区大小的“增强”，这改变了磁盘上的布局（512n，512e，4kn）。 下一个发展趋势是使用8k物理扇区大小，一些制造商已开始生产该物理扇区，并在生产中进行设置。下一步，Windows是否支持8k扇区大小的磁盘？SQL Server是否关心扇区大小？

13 sql-server  hardware 

我们正在使用新服务器和Microsoft SQL Server的更新版本升级测试环境，但遇到了问题。 在新服务器上，执行某些存储过程时，我们的旧代码将获得“关闭对象时不允许操作”。该消息从未出现在旧服务器上。当我们对其进行跟踪时，可以通过添加SET NOCOUNT ON;到存储过程中来解决该问题。 我查看了数据库的默认设置，没有发现与默认设置相关的其他设置（SQL Server 2008与SQL Server 2014）。 我应该在什么条件下解决全局问题，而无需增加SET NOCOUNT ON一千个存储过程？

13 sql-server  sql-server-2008  sql-server-2014  sp-configure 

PostgreSQL使用默认值，加上 default_statistics_target=1000 random_page_cost=1.5 版 PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit 我已经吸尘并进行了分析。该查询非常简单： SELECT r.price FROM account_payer ap JOIN account_contract ac ON ap.id = ac.account_payer_id JOIN account_schedule "as" ON ac.id = "as".account_contract_id JOIN schedule s ON "as".id = s.account_schedule_id JOIN rate r ON s.id = r.schedule_id WHERE …

13 postgresql  join  execution-plan  postgresql-10 

在使用页面压缩（ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)）重建其SQL Server索引之后，是否需要重新指定数据压缩？索引是否可以有效地解压缩？

13 sql-server  index  compression  data-pages 

我有一个查询，其中使用select *不仅读取次数少得多，而且比使用占用的CPU时间少得多select c.Foo。 这是查询： select top 1000 c.ID from ATable a join BTable b on b.OrderKey = a.OrderKey and b.ClientId = a.ClientId join CTable c on c.OrderId = b.OrderId and c.ShipKey = a.ShipKey where (a.NextAnalysisDate is null or a.NextAnalysisDate < @dateCutOff) and b.IsVoided = 0 and c.ComplianceStatus in (3, 5) …

13 sql-server  sql-server-2014  query-performance  execution-plan 

我的任务是尝试恢复遭受损坏的数据库（由于I / O故障，此问题已修复）。我不熟悉数据库或其包含的内容。 我得到了旧的（约3周）完整备份和一系列事务日志...但是缺少事务日志，因此我只能恢复到某个日期。大约有2.5周的数据丢失（并且不断有大量数据添加到该数据库中）。 我还收到了损坏的数据库的副本（可以访问，但是有很多页面损坏/丢失）。 我已经尝试了典型的DBCC CHECKDB命令（仍然没有repair_allow_data_loss，如果没有其他方法，那将是我的最后选择）。 在许多数据库进入数据库之后（数据库是一个1.5 TB的小怪物，我所做的一切都很缓慢并且需要一段时间），我尝试从上次已知的损坏页面备份中恢复联机页面。 为此，我已经完成了一个脚本，该脚本RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'从DBCC CHECKDB输出中创建了许多命令（基本上是一个正则表达式和一个单独的命令）...到目前为止，效果很好，可以说达到了1000页的限制每个还原命令每个文件（此db上有8个文件）。 因此，它要求我“完成在线还原”，但是我对如何做到这一点感到茫然。我基本上不知道如何完成还原以继续尝试其余页面。 我尝试了一个，RESTORE DATABASE <foo> WITH RECOVERY但是也没有用，它要求我提供我没有的日志。 有人对我如何从此处恢复任何内容有任何提示吗？还是如何“完成”在线还原，以便我可以继续尝试恢复更多页面？如果我尝试脱机还原（基本上添加WITH NORECOVERY到所有内容，然后尝试将其恢复到最后，是否会遇到相同的问题？） 手工计算数据库基本上是不可能的……有数百个表和数百万行，并且没有明确的含义。数SELECT百万行后，损坏的数据库将对查询失败，但是我不确定我可以算出哪里。我试过重建所有非聚集索引，但是有行数据损坏的页面，所以也行不通。 某些数据丢失是可以接受的，但至少应尝试实现数据库的一致性。 损坏的数据库仍处于联机状态，并且客户正在使用它（因此它将不断获取新数据），因此，我在实验室工作台上执行的任何过程都应可在生产数据库上重现（停机将非常困难）。 这是SQL Server 2014 Enterprise PS：我不是DBA ...我是一名程序员，但是客户端尝试了一些“专家” sql灾难恢复服务，但他们已经放弃了，所以我被要求研究一下，看看是否可以做任何事情。 更新：经过多次测试，逐页还原是不可行的，因此我们放弃了这个想法。我们将进行手动恢复（手动从损坏的表中选择丢失的记录，并将其插入到最后一个已知的良好备份中），为此做一些自动化的工具（同样，有成百上千的表）。

13 sql-server  t-sql  sql-server-2014  restore  recovery 

您如何关闭此烦人的功能？我不希望我的数据库管理员尽可能大声吼叫我。

13 configuration  toad 

我正在努力理解为什么行估计是如此严重的错误，这是我的情况： 简单连接-使用SQL Server 2016 sp2（在sp1上存在相同问题），dbcompatiblity = 130。 select Amount_TransactionCurrency_id, CurrencyShareds.id from CurrencyShareds INNER JOIN annexes ON Amount_TransactionCurrency_id = CurrencyShareds.Id option (QUERYTRACEON 3604, QUERYTRACEON 2363); SQL估计1行，而SQL为107131，并选择做一个嵌套循环（链接到plan）。在CurrencyShareds上更新统计信息之后，估算就可以了，并选择了合并联接（链接到新计划）。一旦仅将一条记录添加到CurrencyShareds，统计信息就会“过时”，并且sql返回错误的估计。 我不太担心这个简单的查询，但这只是一个更大的查询的一部分，而这就是多米诺骨牌的开始... 为什么在100条记录表中添加一行会造成这种损坏？查看基数估计跟踪的输出时，我看到此警告，***WARNING: badly-formed histogram ***但在此主题上找不到更多信息。 这是基数估计的全部输出： Begin selectivity computation Input tree: LogOp_Join CStCollBaseTable(ID=1, CARD=107131 TBL: annexes) CStCollBaseTable(ID=2, CARD=100 TBL: CurrencyShareds) ScaOp_Comp x_cmpEq ScaOp_Identifier QCOL: [test.MasterData].[dbo].[CurrencyShareds].Id …

13 sql-server  query-performance  sql-server-2016  cardinality-estimates 

这是此问题的后续措施。这也与Microsoft的此功能请求有关。 但是，自从报道以来，已经过去了许多年，并且有几个主要版本进入了市场。 问题： SQL Server 2017是否提供任何机制来简化找出此错误的根本原因？还是很难像9年前报告该问题那样进行调查？

13 sql-server  sql-server-2017  string  truncation 

我有以下表格（来自Sakila数据库）： 电影：film_id是pkey 演员：actor_id是pkey film_actor：film_id和actor_id是影片/演员的键 我正在选择一部特定的电影。对于这部电影，我还希望所有演员都参与该电影。我对此有两个查询：一个带有a LEFT JOIN和一个带有a LEFT JOIN LATERAL。 select film.film_id, film.title, a.actors from film left join ( select film_actor.film_id, array_agg(first_name) as actors from actor inner join film_actor using(actor_id) group by film_actor.film_id ) as a on a.film_id = film.film_id where film.title = 'ACADEMY DINOSAUR' order by film.title; select film.film_id, …

13 postgresql  join  execution-plan  postgresql-performance  postgresql-10 

我已经安装了Windows 10 Fall更新（1709），现在我的PostgreSQL 9.5服务器无法启动。它昨天在更新之前有效，并且我没有对配置进行任何更改。 我检查了事件查看器，发现以下错误消息： 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_monetary": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_numeric": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_time": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST FATAL: configuration file "C:/Program Files/PostgreSQL/9.5/data/postgresql.conf" contains errors 似乎Microsoft随着Fall更新更改了语言环境名称，我找不到可用的语言环境名称的任何列表，因此我决定安装Postgres 10，它证实了我的怀疑，Postgres …

13 postgresql  postgresql-9.5  windows-10 

在SQL Server 2017（CU3）上，每当我在一个TDE数据库上启用备份压缩时，备份过程始终会损坏数据库中的特定页面。如果我运行备份时不进行压缩，则不会损坏它。这是我为验证和重现此问题而采取的步骤： 在数据库“ TDE_DB1”上运行DBCC CheckDB；一切都很好，没有错误； 成功备份数据库而无需压缩；RESTORE VERIFYONLY表示一切都很好； 成功将数据库还原为“ TDE_DB2”；一切都很好，DBCC CheckDB没有显示任何错误； 使用压缩成功备份“ TDE_DB1”数据库；RESTORE VERIFYONLY错误，提示“检测到备份集损坏”； 尝试将数据库还原为“ TDE_DB2”；错误，说“ RESTORE在数据库中的页面（1：92454）上检测到错误” 重复步骤1-3；一切都很好; DROP“ TDE_DB1”和“ TDE_DB2”; 从备份中还原“ TDE_DB1”；一切都很好; 重复步骤1-5；得到相同的结果 总结一下：数据库和常规备份看起来不错，在数据库上运行CHECKDB并在备份上运行VERIFYONLY不会报告任何错误。使用压缩备份数据库似乎会导致损坏。 下面是有错误的代码示例。（注意：将压缩与TDE数据库一起使用需要MAXTRANSFERSIZE） -- Good, completes with no corruption; BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE …

13 sql-server  corruption  transparent-data-encryption  sql-server-2017