Questions tagged «sql-server-2016»

SQL Server 2016(主要版本13.00.xxxx)。还请标记sql-server。

1
SQL Server 2016中的表命名约定和策略管理问题
在SQL Server 2012中,我有一个策略设置为不允许表名中包含空格。但是,当我在SQL Server 2016中使用相同的策略时,出现错误。 这是条件的代码: DECLARE @condition_id INT EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'No Spaces', @description=N'No spaces in table names.', @facet=N'IMultipartNameFacet', @expression=N'<Operator> <TypeClass>Bool</TypeClass> <OpType>NOT_LIKE</OpType> <Count>2</Count> <Attribute> <TypeClass>String</TypeClass> <Name>Name</Name> </Attribute> <Constant> <TypeClass>String</TypeClass> <ObjType>System.String</ObjType> <Value>% %</Value> </Constant> </Operator>', @is_name_condition=4, @obj_name=N'% %', @condition_id=@condition_id OUTPUT SELECT @condition_id 这是该策略的代码: DECLARE @object_set_id INT EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Table Names_ObjectSet', @facet=N'IMultipartNameFacet', …

3
使用MAXTRANSFERSIZE和CHECKSUM时,无法还原启用TDE的数据库
更新:@AmitBanerjee -Microsoft SQL Server产品组的高级程序经理,确认MS将调查此问题,因为它是缺陷。 有没有人遇到在启用TDE并使用MAXTRANSFERSIZE> 65536的情况下还原在SQL Server 2016上进行的备份的问题(对于我而言,我选择了65537,以便可以压缩TDE数据库)和CHECKSUM? 下面是一个副本: --- create database create database test_restore go -- create table create table test_kin (fname char(10)) go -- Enable TDE use master GO CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert' GO SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore' GO …

1
升级后,SQL Server AlwaysOn数据库卡在“不同步” /“恢复”模式下。错误:无法打开数据库“…”版本782
测试从SQL Server 2014 SP1(12.0.4422.0)到SQL Server 2016 CTP 3.2(13.0.900.73)的升级时,我遵循建议的更新过程,并遇到了故障转移后数据库无法在旧主数据库上启动的问题到更新的中学。我们的设置是一个主副本和一个辅助副本,我完成的步骤是: 在同步提交的辅助副本上删除自动故障转移 将辅助服务器实例升级到新版本 手动故障转移到辅助副本 验证数据库在新的主副本上是否在线 将以前的主副本升级到新版本 辅助服务器的升级和故障转移以使其成为主要服务器,完全可以按预期进行。但是,在升级了先前的主副本之后,我注意到其上的数据库在SSMS中被列为“ 未同步/正在恢复”。同样尝试访问它们也会生成错误消息: 数据库...不可访问。(对象浏览器) 通过我看到的SQL Server日志进行检查 无法打开数据库“ ...”版本782。将数据库升级到最新版本。 查询master..sysdatabases表表明它确实是一个较旧的版本,并且在升级过程中未进行更新: 不幸的是,日志没有指出为什么不对其进行更新,并且可用性组仪表板仅给出一般性警告,指示某些可用性数据库的数据同步状态不正常,没有任何原因。 我尝试使用TSQL分离数据库或将其设置为脱机以“踢”数据库以进行更新,但是由于它们是SQL AG的一部分,因此这些命令不起作用。 如果数据库是SQL AG的一部分,如何将其升级到最新版本?

2
如何防止SELECT上的分区列存储死锁
我在SQL Server 2016中拥有三个群集列存储索引(CCI)表。所有这些CCI都基于租户ID处于同一分区方案中。最近,而且前后矛盾,我在从联接到这些表的简单选择语句中陷入僵局。死锁的示例查询: SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 错误信息: 事务(进程ID 56)与另一个进程在通用的可等待对象资源上处于死锁状态,并且被选择为死锁牺牲品。重新运行事务。 线索: 如果查询使用CCI以外的其他索引,则不会死锁。 如果删除三个tenantid过滤器中的两个,则不会死锁。 如果我选择前32位或更低,则不会死锁。 如果添加OPTION(MAXDOP 1),则不会死锁。 我可以在混乱的PROD副本,PROD只读次要副本和PROD本身中对此进行复制。 我无法在DEV或INT中复制此行为。 如果我将WITH(NOLOCK)添加到所有3个表联接中,它仍然会死锁 查询自身会死锁。当没有其他活动进程时,它将死锁。 没有并行性的查询计划不会死锁 死锁XML在这里 我们的PROD版本: …

1
使用页面压缩时的行开销是多少?
我创建了一个包含650 Numeric(19,4)列的表。当我打开页面压缩时,通过运行 ALTER TABLE fct.MyTable REBUILD WITH (DATA_COMPRESSION = PAGE); 我懂了 消息1975,级别16,状态1 索引“ PK_Mytable”的行长度超过了“ 8060”字节的最大允许长度。 但是650乘以9字节仅是5850字节,与规定的8060字节的限制相去甚远。 服务器正在运行Windows 2012 r2和SQL Server 2016 SP1 CU2 使用页面压缩时的行开销是多少? 这是一些代码来显示我的意思: /* test script to demo MSG 1975 */ DECLARE @sql NVARCHAR(max)='', @i INT =0 drop table if exists dbo.mytable; SET @sql = 'Create table dbo.Mytable …

1
缺少的非聚集索引已成为聚集索引的一部分
我正在调试运行缓慢的查询,在执行计划中建议使用51.6648 Impact的非聚集索引。但是,非聚集索引仅包括主键(PK)复合聚集索引中已经存在的列。 难道是因为索引中列的顺序?即,如果聚集索引中的列从最有选择性到最少的顺序不顺序,那么非聚集索引是否有可能提高性能? 此外,非聚集索引仅包含三个PK列中的两个,而第三个添加为包含列。include使用非聚集索引可能会更优化的另一个原因吗? 以下是我正在使用的表结构的示例: 桌子- Retailers ( RetailerID int PK, name ...) Retailer_Relation_Types ( RelationType smallint PK, Description nvarchar(50) ...) Retailer_Relations ( RetailerID int PK FK, RelatedRetailerID int PK FK, RelationType smallint PK FK, CreatedOn datetime ...) 该表Retailer_Relations具有以下综合PK指数和建议指数- CONSTRAINT PK_Retailer_Relations PRIMARY KEY CLUSTERED ( RetailerID ASC, RelatedRetailerID ASC, RelationType …

1
测量计划驱逐
我们有一个SQL Server 2016 SP1,最大内存设置为24GB。 该服务器具有大量编译,其中只有10%的编译来自临时查询。因此,新编译的计划应存储在计划缓存中,但计划缓存的大小不会增加(约3.72GB)。 我怀疑本地内存压力会导致从缓存中删除计划。计划缓存压力限制为5GB。(0-4GB的可见目标内存的75%+ 4GB-64GB的可见目标内存的10%+> 64GB的可见目标内存的5%)。当缓存存储达到压力限制的75%时,应从缓存中删除计划。就我而言,5 GB的75%为3.75 GB。因此,这可能是高编译率的原因。 有没有一种方法可以测量(性能,扩展事件等)从缓存中删除计划?这样我就可以确定本地内存压力确实是高编译的原因吗?

1
如果系统健康中有“ sql_exit_invoked”,这意味着什么?
我的一台SQL Server 2016 Standard服务器遇到问题。我有8个生产服务器,这是唯一一台随机崩溃而日志中没有任何痕迹的服务器。 我已启用system_health。我注意到我在系统健康状况中有一行是“ sql_exit_invoked”。 我正在尝试在该行上找到更多信息。这是什么意思?我在互联网上发现的唯一信息是,它在调用SQLExit()时发生,并且仅在SQL 2012以后才记录。(msdn网站上的链接) 所以我的问题是:我应该担心在日志中看到这个吗?我只能在有问题的服务器上找到它,而在其他7个服务器上都找不到。(所有都是SQL Server 2016 Standard版) 有人可以给我更多信息吗?

3
为协作距离有限的行分配唯一值的解决方案
我有一个可以使用以下代码创建和填充的表: CREATE TABLE dbo.Example(GroupKey int NOT NULL, RecordKey varchar(12) NOT NULL); ALTER TABLE dbo.Example ADD CONSTRAINT iExample PRIMARY KEY CLUSTERED(GroupKey ASC, RecordKey ASC); INSERT INTO dbo.Example(GroupKey, RecordKey) VALUES (1, 'Archimedes'), (1, 'Newton'), (1, 'Euler'), (2, 'Euler'), (2, 'Gauss'), (3, 'Gauss'), (3, 'Poincaré'), (4, 'Ramanujan'), (5, 'Neumann'), (5, 'Grothendieck'), (6, 'Grothendieck'), …

2
在msdb上启用查询存储有什么好处?
在SQL系统数据库(主数据库,模型数据库,msdb数据库,tempdb数据库)中,查询存储只能在msdb上使用。我查看了,没有找到有关msdb上查询存储的任何文档。 虽然您无法在GUI中看到它,但可以在您的SQL 2016实例上对其进行验证 验证查询存储已关闭 USE msdb SELECT * FROM sys.database_query_store_options; 开启查询存储 USE [master] GO ALTER DATABASE msdb SET QUERY_STORE = ON GO ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE , INTERVAL_LENGTH_MINUTES = 30 , MAX_STORAGE_SIZE_MB = 1000 , QUERY_CAPTURE_MODE = AUTO) GO 验证查询存储已打开 USE msdb SELECT * FROM sys.database_query_store_options; …

3
如何提示SQL Server中的多对多联接?
我有3个“大”表,它们连接在一对列(均为int)上。 Table1拥有约2亿行 Table2拥有约150万行 Table3拥有约600万行 每个表都有一个聚集索引Key1,Key2以及再得一列。Key1具有低基数并且非常偏斜。WHERE子句中始终引用它。条款中Key2从未提及WHERE。每个联接都是多对多的。 问题在于基数估计。每个连接的输出估计值变小而不是变大。当实际结果达到数百万时,最终得出的结果估计只有几百个。 我有什么办法让行政长官提示做出更好的估计? SELECT 1 FROM Table1 t1 JOIN Table2 t2 ON t1.Key1 = t2.Key1 AND t1.Key2 = t2.Key2 JOIN Table3 t3 ON t1.Key1 = t3.Key1 AND t1.Key2 = t3.Key2 WHERE t1.Key1 = 1; 我尝试过的解决方案: 在创建多列统计Key1,Key2 创建大量已过滤的统计信息Key1(这很有帮助,但是我最终在数据库中获得了数千个用户创建的统计信息。) 掩盖的执行计划(抱歉掩盖不好) 就我而言,结果有900万行。新的CE估计有180行;旧版CE估计有6100行。 这是一个可重现的示例: DROP TABLE IF EXISTS #Table1, #Table2, …

1
服务经纪人-对话寿命?
我们正在努力使Service Broker在我们的环境中工作,以解决业务案例。我不知道消息标题是否是一个好标题,但是我的问题在下面。但这可能不是一个好问题,所以在那之后我们要做的就是为什么我认为这是正确的问题。 在结束对话之前,应在对话中发送多少条消息? 我们要使用Service Broker来异步更新结果表。结果表平坦且快速。我们在基表上具有触发器,该触发器发送带有其表和主键的消息。我们有三个队列: 低延迟-目标是处理15秒。它处理与特定项目有关的更改项目。 批量队列-目标是5分钟的处理时间。它处理何时会影响数百(或数千)个项目的更改。它列出了受影响的项目列表,并将其馈入“延迟的低延迟队列” 延迟的低延迟-目标是30分钟才能处理。这仅处理批量队列中的项目。 基本上,如果客户的信息更新;这会影响许多产品,因此将其发送到批量队列以减慢处理速度。但是,如果产品得到更新,则将其发送到低延迟队列。 我们重用类似于Remus Rusanu的博客http://rusanu.com/2007/04/25/reusing-conversations/的对话,不同之处在于我们是基于主键的模数来进行对话的。这具有辅助主键重复数据删除的附带好处。 因此,我们正在重新使用对话并且在我们的准则之内。通过两个线程,我能够每秒刻录125条消息(人为丢弃几千条消息),这远远超过了保持生产的速度(每秒15条消息)。 但是,我们遇到的问题是,经过一段时间,大约4个小时或120K消息,我们开始在sysdesend和队列表上看到块和高争用。锁是LCK_M_U,是KEY锁。有时,宏块解析为sysdesend,有时解析为特定的队列表(queue_)。 我们已经制定了一个流程,该流程将在闲置24小时或30分钟后结束对话,因此我们可以增加循环讨论之前的时间。 我们正在使用SQL 2016 Enterprise(13.0.4001.0) 触发触发(发送低延迟或批量发送) 查找或创建对话句柄。 发信息 队列激活过程 更新结果表 清理过程每10分钟运行一次,以查看是否有空闲的对话。如果连续超过三遍发现它们,则将其标记为无效并结束对话。 请让我知道是否还有其他可能有益的细节。我在Service Broker方面没有太多经验,所以我不知道我们的消息/秒是低,高还是无动于衷。 更新 因此,我们今天再次尝试,并遇到了相同的问题。我们将对话寿命更改为2小时,但没有任何效果。因此,我们实施了150招;有同样的问题。 大量等待SEND CONVERSATION,等待sysdesend。有人还有其他想法吗? 更新2 今天我们进行了更长的测试,并且在17分钟的采样期间之一中,我们在4个会话句柄上处理了41K条消息。当sysdesend上的锁和队列表变得过多,并且在停止它之前我们开始向后漂移时,我们能够保持到最后。我们似乎在处理消息方面没有问题,没有任何东西进入队列,我们​​可以将其拉出并以至少5倍的速度处理它们。基于添加消息,我们的速度似乎受到限制。 在以后的测试中,我们删除了占消息总数80%的触发器之一。即使负载大大减少,我们也开始看到相同的等待。 更新3 谢谢Remus的建议(也感谢您发布有关该主题的出色博客文章,它们对于达到这一点很有帮助)。 我们今天再次运行它,并且表现更好(因为在等待之前,我们走了更长的时间,甚至在我们瘫痪之前走了更长的时间)。所以,细节。 我们更改了:*将每个线程的可维护会话数从1:1增加到2:1。基本上,我们有4个线程的8个会话句柄。 合并大容量队列(因为一条传入消息可能意味着数百条传出消息),从而合并为更少,更大的消息。 关于此尝试的注意事项: 禁用目标队列激活过程。阻塞没有变化(我们等待了5分钟),消息确实发送到了sys.transmission_queues。 监视sys.conversation_endpoints。这个数字从0很快就达到了13K,然后全天缓慢上升,直到大约5小时后才达到25K。直到达到16K +/-才开始阻塞 我进入DAC并为队列运行DBREINDEX命令,尽管通过查询,幻象记录在进行清理并将计数降至0之前从未超过200左右。 当我结束测试时,sysdesend和sysdercv的计数相同,为24,932。 我们在5个小时内处理了约310K条消息。 我们走了很长时间,事情才崩溃了,我真的以为这次可以做到。明天我们将尝试强制消息通过网络。



1
我应该对链接SQL Server有什么大的限制?
我们的产品基于Microsoft SQL Server。当前,我们正在使用三个数据库,并且始终将它们部署在一个SQL Server实例上。 这三个数据库是OLTP,OLAP和审计。OLAP数据库使用跨数据库查询,具有来自OLTP和审计的有关EOD的大量入站数据。 问题 如果我们要将这三个数据库部署到单个物理服务器内的三个单独的Standard Edition 实例上,并使用SQL Server的链接服务器功能将它们绑定在一起: 对应用程序代码的透明度如何?我应该期待多少变化? 到OLAP的入站数据总计为5万至10万行,每个EOD负载为200-500MB。我应该期望多少性能下降? 我还应该期待其他哪些重大限制? 背景 目前,我们正在为潜在的第一个客户提供500多个并发用户。 我们正在起草服务器规范,其中包括64个内核和256GB RAM。为了使SQL Server能够利用所有这些丰富的资源,客户端必须购买Enterprise Edition,而对于SQL Server 2016,Enterprise Edition仅在基于每核的许可中可用。 我们担心光是许可成本(64 x 7400美元)就会使他们失望。因此,我正在考虑将数据库分为Standard Edition的三个实例,并将它们链接在一起,希望链接功能对应用程序代码是透明的。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.