Questions tagged «sql-server-2016»

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

1
100％CPU的执行计划不正确
由于特定查询使用了错误的执行计划，我遇到了100％CPU峰值的严重问题。我现在花了数周时间自行解决。 我的资料库 我的样本数据库包含3个简化表。 [数据记录仪] CREATE TABLE [model].[DataLogger]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [ProjectID] [bigint] NULL, CONSTRAINT [PK_DataLogger] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] [变频器] CREATE TABLE [model].[Inverter]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [SerialNumber] [nvarchar](50) NOT NULL, CONSTRAINT [PK_Inverter] …
2
SQL Server 2016企业版性能不佳
抱歉，很长，但是我想给您尽可能多的信息，以便对分析有所帮助。 我知道有几个帖子有类似的问题，但是，我已经关注了网上发布的这些帖子和其他信息，但是问题仍然存在。 我在SQL Server中遇到严重的性能问题，这使用户发疯。这个问题持续了好几年，直到2016年底由另一个实体管理，从2017年开始由我管理。 在2017年中，我能够按照Microsoft SQL Server 2012性能仪表板报告中指示的索引提示解决问题。效果是立竿见影的，听起来像魔术。在过去的日子里，几乎总是100％的处理器变得超级宁静，并且用户的反馈声也很高。甚至我们的ERP技术人员也很高兴，因为通常需要20分钟才能获得某些清单，最后他可以在几秒钟内完成。 但是，随着时间的流逝，它开始慢慢恶化。我避免创建更多索引，因为担心过多的索引会降低性能。但是在某些时候，我不得不删除那些没用的东西，并创建Performance Dashboard向我建议的新东西。但没有影响。 在ERP中进行保存和咨询时，感觉到的缓慢本质上。 我有专用于SQL Server 2016 Enterprise（64位）的Windows Server 2012 R2，具有以下配置： 处理器：Intel Xeon CPU E5-2650 v3 @ 2.30GHz 记忆体：84 GB 在存储方面，服务器具有专门用于操作系统的卷，专门用于数据的卷和专门用于日志的卷。 17个数据库 使用者： 在最大的数据库中，大约有113个用户并发连接 另外约有9位使用者 其中两个是3 + 3 其余各只有1个用户 我们有一个网站，它也为较大的数据库编写数据，但是使用情况不那么常规，应该有大约20个用户。 数据库大小： 最大的数据库有290 GB 第二大有100GB 第三大有20 GB 第四个14 GB 其余各只有3 GB以上 这是生产实例，但我们也有一个开发实例，我相信可以为此忽略它，因为在大多数情况下，我是唯一的连接对象，但是即使没有连接，该问题也会不断发生。 处理器几乎总是这样： 我们的例程在夜间运行（没有问题），而某些例程在白天运行。 …
1
SQL Server 2016仍然包含sqlmaint.exe吗？
根据文档（SQL Server 2016中不推荐使用的数据库引擎功能），sqlmaint.exe仍然应该可用（强调我的）： 本主题描述了SQL Server 2016中仍然可用的不推荐使用的SQL Server数据库引擎功能。这些功能计划在 SQL Server 的将来版本中删除。 ... 工具：sqlmaint实用工具... 绝对不会在已停用功能列表中列出该功能。 但是，我sqlmaint.exe在最近安装的SQL Server 2016 Express系统上找不到。在以前的版本中，它与处于同一文件夹中sqlserver.exe。 文档有误吗？还是文件位置移动了？还是在安装过程中错过了什么？ （注意：受重现此问题的评论的鼓舞，我为此创建了一个Microsoft Connect条目，该条目已迁移到UserVoice。）
4
“ AlwaysOn”不总是“ Always On”吗？
我们创建了Windows故障转移群集，然后添加了两个SQL Server实例作为SQL Server故障转移群集的节点。 我们在SQL Configuration Manager中将服务器设置为使用“ AlwaysOn可用性组”。 为了测试故障转移，我加载并运行了一个长查询，然后通过使用故障转移群集管理器停止活动节点上的群集服务来关闭活动节点。 查询在没有连接的情况下中断，服务器在节点耗尽并新节点接管之前的20秒钟内显示为不可用。 我做错了吗？我应该如何配置它，以确保几乎没有连接丢失？ AlwaysOn是否不总是开启？
2
SQL Server 2016 Standard Edition是否支持表分区？
我想将我的SQL Server 2008企业版升级到SQL Server 2016标准版; 但是，一个数据库利用多个文件组上的表分区（用于大型日志表，每天都是一个分区） 我在SQL Server 2016的版本和受支持的功能的“ RDBMS可伸缩性和性能”部分下看到，它说标准版支持表和索引分区，但是不支持分区表并行。 我不确定我是否完全理解这一后果。 在我看来，这到底是什么意思，它将如何影响数据库的性能？
1
AlwaysON从2014年迁移到2016年
我喜欢2014年的20个Listners，大约有500 DBS， 用最少的时间和精力来迁移这些文件的最佳方法是什么 我的想法是：停止访问备份数据库开始还原数据库运行还原时：在2014上删除AOG在2016上创建AOG完成 这似乎很简单，但是使用TB数据将需要一些时间。 已找到此-> 从2014年升级到2016年的AlwaysOn AG的推荐方法， 但是它确实解释了 希望有人能帮忙
3
为什么时态表记录事务的开始时间？
更新临时表中的行时，该行的旧值存储在历史记录表中，事务开始时间为SysEndTime。当前表中的新值将使事务开始时间为SysStartTime。 SysStartTime并SysEndTime在datetime2使用时态表来记录当行是当前版本列。事务开始时间是包含更新的事务开始的时间。 BOL说： 系统datetime2列中记录的时间基于事务本身的开始时间。例如，在单个事务中插入的所有行将在与SYSTEM_TIME周期开始相对应的列中记录相同的UTC时间。 示例：我开始从以下位置更新“订单”表中的所有行，20160707 11:00:00并且该事务需要5分钟才能运行。这将在历史记录表中为每行创建一行，并用SysEndTimeas 20160707 11:00:00。在当前表中的所有行会产生SysStartTime的20160707 11:00:00。 如果有人要20160707 11:01:00在更新运行时执行查询，他们将看到旧值（假设默认读取已提交隔离级别）。 但是，如果有人随后使用AS OF语法查询时态表，那么20160707 11:01:00他们将看到新值，因为它们SysStartTime将是20160707 11:00:00。 对我来说，这意味着它不会显示当时的行。如果它使用事务结束时间，则该问题将不存在。 问题：这是设计使然吗？我想念什么吗？ 我可以认为它正在使用事务开始时间的唯一原因是，它是事务开始时唯一的“已知”时间。它不知道事务在开始时将在何时结束，并且在结束时应用结束时间将花费一些时间，这将使正在应用的结束时间无效。这有意义吗？ 这应该允许您重新创建问题。
4
SQL 2016 SQL Server声明：文件：<pageref.cpp>，行= 951失败声明
我目前正在将数据仓库从SQL 2012升级到SQL2016。新旧DW并行运行。 我的ETL流程（由第三方在SSIS中开发的框架）在2012年成功运行了两年多，但在2016年失败了。到目前为止，数据库和ETL流程是相同的。 这两个服务器都是在VMWare上运行的虚拟机。旧服务器是Win 2008，具有24Gb RAM。SQL 2012标准 最大内存设置为16Gb。新服务器是Win 2012，具有64Gb RAM。SQL 2016开发 最大内存设置为50Gb。新的DW正在运行v13.0.1601.5 RTM Developer Edition（64位）。 在运行我的ETL进程时，将SQL合并到维或事实表中的加载步骤失败，并出现以下错误。 全文： 描述：SQL Server声明：文件：，line = 951失败声明='IS_OFF（BUF_MINLOGGED，m_buf-&gt; bstat）|| pageModifyType！= PageModifyType_Contents || GetPagePtr（）-&gt; IsTextPage（）'。此错误可能与时序有关。如果重新运行该语句后错误仍然存​​在，请使用DBCC CHECKDB检查数据库的结构完整性，或者重新启动服务器以确保内存中的数据结构没有损坏。 按照建议，我已经运行DBCC，没有发现错误。我还重新启动了SQL。然后，我重新启动了ETL流程，并得到了相同的错误。 我对此错误的搜索显示，这是SQL 2008、2012和2014年的已知错误并已在后续的修补程序和累积更新中修复。因此，我很惊讶看到它在2016年重新出现。 我发现的链接说，如果数据库处于“简单”或“大容量日志记录”恢复模型中，则在尝试执行插入操作时会影响SSIS。（我正在以简单恢复模式运行） 建议的解决方法是将Db恢复模型更改为FULL。我已经尝试过了，并且可以正常工作，但这并不是数据仓库的解决方案。 其他人在2016年遇到过这个吗？ 谁能建议替代解决方法？ 更新： 2016年7月26日：我应用了重要更新KB3164398（v13.0.1708.0），问题仍然存在。 2016年7月27日：我已应用累积更新CU1 KB3164674（v13.0.2149.0）。 2016/3/8：在我们最小的立方体上，错误在一夜之间发生。CU1无法解决问题。今天，我报告了MS Connect上的错误，并且还与Microsoft记录了支持电话。 2016年12月8日：MS-Support最初做出了回应，但回应是“我们没有针对此问题的解决方案”。支持人员将与他的同事讨论该问题，并尽快与我联系。8天后，我没有收到他的消息。 尽管我没有“解决方案”，但我们确实找到了适合我们的解决方法。查看我发布的答案。 29/9/2016。我上周应用了CU2。在Thursay上，我们意外地运行了旧版本的合并，但由于相同的错误再次失败。所以.. CU2也没有修复它。 23/1/2017：我应用了2016 SP1 CU1，我相信这已经解决了问题。特别是KB3205964
2
升级到2016年后，SQL Server代理无法连接到实例
在具有SQL Server 2014 Enterprise的群集Windows 2012 R2服务器上。 刚刚将实例从2014 SP1 CU4升级到2016 RTM，现在在尝试启动SQL Server代理时收到此错误。 SQL服务器代理日志 2016-06-06 11:53:58 - ? [100] Microsoft SQLServerAgent version 13.0.1601.5 (X64 unicode retail build) : Process ID 10884 2016-06-06 11:53:58 - ? [495] The SQL Server Agent startup service account is DOMAIN\USERNAME. 2016-06-06 11:54:28 - ! [150] SQL Server …
3
数据仓库服务器。您如何计算RAM / CPU规格？
我正在尝试为我们计划的数据仓库升级编写数据仓库服务器的规范。 在VMWare主机上运行虚拟服务器时，我们可以根据需要添加或删除资源。过去，我们根据需要逐渐增加了RAM和CPU。随着需求的增加，我们游说了更多的资源。（主要是磁盘和RAM）。 我们要求更多。他们给了我们尽可能少的东西。 但是最近，每当我们谈论资源时，我们都因一开始就没有正确配置机器而受到批评，现在我被告知开发主机已被用尽，没有可用的RAM。 我们是一个小型的地方政府组织，拥有约50个DW常规用户。在正常的日常使用中，它运行良好。我们获得了良好的mdx查询性能，并且我们的报告和仪表板速度很快。用户感到高兴。 但是，我们的ETL流程会整夜运行，并且当同时处理数据集市时，我们开始看到内存不足的迹象。昨晚SSIS失败，并发出有关“内存不足错误”的警告。 我们现有的DW服务器是Win 2008 R2，具有4个CPU和16Gb RAM，运行SQL 2012 Std。我将最大服务器内存设置为12GB，为OS和服务等保留了4GB。我们现有的DW有3个数据集市/ OLAP多维数据集，并且我们还在开发2个。 +----------+----------+---------------+-----------+---------------+ | Datamart | Files GB | Fact (Rows) | Fact (Mb) | ETL &amp; Process | | OLAP cube| | | | Time (hours) | +----------+----------+---------------+-----------+---------------+ | PBI | 3 | 190,000 | 180 | 0.2 …
4
VM上的单核SQL Server
最近，我们的学区已将多台服务器从2005版升级到2016年，并且从物理服务器升级到了VM服务器。 我们的基础架构团队为单核提供了用于SQL Server安装的VM服务器。 我试图向该部门负责人解释说，SQL Server“讨厌”在单个内核上，他想看到“证明”。我提供的数据都没有满足他的证明要求，因此他要求提供一些文章，说明为什么VM SQL Server无法在单个内核上有效运行。 您为此使用什么文章？ 任何对我的帮助对我来说都将不胜感激！
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.