Questions tagged «sql-server-2012»

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

1
聚簇索引查找和非聚簇索引查找之间的区别
聚集索引（CI）搜索和非聚集索引（NCI）搜索之间有什么区别？一个人比另一个人表现更好吗？ 我之所以这样问，是因为我有一个具有5000万行和150列的表。它有一列名为ID定义为聚簇索引的列。还有一个具有相同索引键ID和七个include-d列的NCI 。在我看来，NC索引在这里是重复的，可以安全地删除。 因此，我想获得一些专家意见/建议，以确保可以安全地放下它或保持其完好无损？
3
将多个数据库备份到同一时间点
通常，当我们开始备份时，我们不允许提交更改，否则将无法访问数据库。我的意思是数据库将处于单用户模式，但是我想开始备份并释放数据库以供使用。另外，一旦开始备份，我就不想将正在进行的更改写入备份文件。我想知道如何在Microsoft SQL Server 2012中实现此目标。请帮助我。 好吧，让我先解释我的问题。目前，我正在将数据库设置为单用户模式，直到备份完成。我的目的是为了避免备份过程中的数据更改。但是我的应用程序与多个数据库绑定在一起（每个数据库相互链接，并且有var dbs不断按月创建）。因此，备份所有这些数据库已成为一个繁琐的过程，更重要的是，在备份过程中，我必须将用户排除在系统之外。 因此，我正在寻找可以满足以下要求的备份机制。 一次启动所有数据库的备份，然后释放该数据库以供使用。 由于数据库相互链接，因此我希望在备份文件中保持数据一致性。因此，由于这种数据一致性要求，我不想将正在进行的更改提交到备份文件中。 我想要的是-在给定时间备份所有数据库。
2
缓冲池外的SQL Server 2012内存消耗
我有一个SQL Server 2012 SP2 Enterprise Edition实例，比最大内存消耗约20GB的内存。内存限制。该实例限制为65GB，但以下查询显示的正在使用的物理内存为86GB SELECT (physical_memory_in_use_kb/1024)/1024 AS [PhysicalMemInUseGB] FROM sys.dm_os_process_memory; GO 该服务器是物理服务器，具有2个NUMA节点。有没有一种方法可以找出正在消耗缓冲池之外的内存的原因（我假设这是正在发生的事情）？ 这是DBCC MEMORYSTATUS的输出： 这是设置的内存限制： 提前致谢。 更新：-我已经运行了亚伦建议的查询 SELECT TOP (20) * FROM sys.dm_os_memory_clerks ORDER BY pages_kb DESC 这是输出：- pages_kb的总和约为60GB 更新2：-DBCC MEMORYSTATUS的完整输出在这里：-http: //pastebin.com/nGn6kXEc 更新3： - Shanky在这里的Excel文件的脚本输出： - http://jmp.sh/LKRlH4K 更新4：-输出的屏幕截图：- SELECT (physical_memory_in_use_kb/1024)/1024 AS [PhysicalMemInUseGB] FROM sys.dm_os_process_memory; GO 因此，这似乎表明SQL Server使用的内存大于65GB。
1
嵌套在OUTER JOIN内部的INNER JOIN语法与查询结果
TLDR；如果您查看这两个执行计划，有一个简单的答案是哪个更好？我故意没有创建索引，因此更容易看到正在发生的事情。 在我之前的问题（我们发现不同的联接样式（即嵌套与传统）之间的查询性能差异）进行了跟进之后，我意识到嵌套语法也可以修改查询的行为。考虑以下两个查询。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m JOIN dbo.Manufacturers n -- <-- Nested INNER JOIN ON n.ManufacturerID = m.ManufacturerID ON m.ModelID = a.ModelID 这并不一定使制造商加入，以包括与ModelID自动行是不是在型号表。 使用传统语法，我们必须将Manufactures的联接更改为外部联接，就像这样……但这会更改查询计划。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m ON m.ModelID = a.ModelID LEFT JOIN dbo.Manufacturers n …
3
为什么.bak文件大小随着SQL Server上的每个连续备份而增加/增加？
我在SQL Server 2012 Express上运行一个简单的数据库。 就在今天，当我备份数据库时，.bak文件大小增加了一倍，是几分钟前上次备份的大小。今天，我已经进行了几次备份（通过SQL Server Management Studio->备份类型：完整），并且每次备份.bak文件都会加倍。 在SQL Server Mgmt Studio中，当我右键单击数据库->“报告”->“备份和还原事件”->展开“成功备份操作”时： 此处的报告显示，最新备份大小记录为55MB，但是当我转到实际.bak文件时，它为260MB。今天.bak，彼此备份的大小也记录为55MB，而其相应文件的大小则是原来的几倍（并且随着每次备份操作的增加而增加）。 可能出什么问题了？自从发生这种情况以来，我还没有对数据库进行任何更改。
1
检测到SQLHANDLE的可能的无限重新编译
我一直在sql错误日志中发现奇怪的错误消息： Bocss：每小时都会发生同样的僵局–需要调查 此外，按照以下示例，错误日志中还列出了许多其他SPID的重新编译内容： 2015年9月4日14：30：10，spid64，未知，为SQLHANDLE检测到可能的无限重新编译0x0200000059631A288882589E0C54B76404CAE1B97E08D368000000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000600最后一次补偿是10：30/04/04：10：04/04 /结尾，spid150，未知，已检测到SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A000000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000的可能无限重新编译，起始偏移量998Uncompute 09，20 09:09结束，偏移量2020是：0909结束时的偏移量2020：20，09:09结束，偏移量2030：0检测到可能无限的重新编译为SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000起始偏移1064结束偏移2652是2. 2015年9月4日14最后重新编译原因：30：09，spid163，未知，是为SQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle探测到一个可能无限的重新编译0x06000400E7C7BF0EF0EB68A52C00000001000000000000000000000000000000000000000000000000000000000000起始偏移量1028终止偏移量2580.上次重新编译的原因是2。 是什么原因造成的？ 看来我已经没有计划在缓存中了。 按照这篇文章的建议 http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx 然后作为一项安全措施禁用了全文目录，这没有什么区别，因此我完全回滚了更改（删除了新对象等）。这也没有什么不同，最终似乎唯一阻止它的是重启SQL实例，这立即解决了问题。 这样也可以解决我的问题，但是，我仍然首先要找出是什么原因造成了这种混乱？
2
SQL Agent-PowerShell步骤“语法错误”
我在SQL Agent Job步骤中未运行的以下代码设置。收到的消息很简单： 无法开始执行步骤1（原因：第46行：语法错误）。该步骤失败。 工作时间为： 00:00:00 该脚本的第46行是here-string： ,@DriveLetter = '$($c.DriveLetter)' 该脚本可以在SQL Server代理之外完美运行。 ServerNames表： CREATE TABLE ServerTable ( ServerName varchar(50) ) 磁盘空间表将类似于： CREATE TABLE DiskSpace ( ID int IDENTITY(1,1), ServerName varchar(50), DriveLetter varchar(2), DiskSpaceCapacityGB decimal(12,5), DiskSpaceFreeGB decimal(12,5) ) PowerShell脚本： This command is to allow SQL Agent job to show failure in …
1
为什么MS SQL Server SEQUENCEs没有像Oracle这样的ORDER参数？
在T-SQL 的文档中CREATE SEQUENCE，您可以看到该CREATE SEQUENCE命令没有ORDER参数。 为了进行比较，用于CREATE SEQUENCE显示ORDER/ NOORDER选项的Oracle文档： ORDER 指定ORDER以确保按请求顺序生成序列号。如果将序列号用作时间戳，则此子句很有用。对于用于生成主键的序列，保证顺序通常并不重要。 ORDER仅在将Oracle数据库与Real Application Clusters一起使用时才有必要保证有序生成。如果使用独占模式，则序列号始终按顺序生成。 NOORDER 指定NOORDER是否不想保证按请求顺序生成序列号。这是默认值。 Microsoft SQL Server是否为SEQUENCEs 提供强大的排序约束？还是Microsoft总体上认为它不重要？
2
升级到更好的存储后，检查点的等待时间增加
当我们从一个较早的全闪存阵列迁移到一个较新的全闪存阵列（不同但信誉良好的供应商）时，我们开始发现检查点期间SQL Sentry中的等待时间增加了。 版本：SQL Server 2012 Sp4 在我们的旧存储中，检查点期间的等待时间约为2k，“峰值”为2500，而在新存储中，峰值通常为10k，峰值接近50k。哨兵将我们更多地指向PAGEIOLATCH瓦蒂斯。做我们自己的分析，似乎是PAGEIOLATCH and PAGELATCH等待的组合。使用Perfmon，我们通常可以说检查点的页面越多，等待的时间就越多，但是在检查点期间我们只刷新了约125 mb。我们的工作量主要是写操作（主要是插入/更新）。 存储供应商向我们证明，在这些检查点事件期间，光纤通道直接连接的阵列在1毫秒内响应。HBA还确认阵列的编号。我们也不认为这是HBA排队的问题，因为队列深度从未超过8。我们还尝试了更新的HBA，将ZIO，执行限制和队列深度设置更改为无效。我们还将服务器的内存从500 GB增加到1 TB，没有任何变化。在检查点过程中，我们确实看到2-4个核心（共16个）峰值达到100％，但总体CPU约为20％。BIOS也设置为高性能。但是有趣的是，即使禁用了CPU，我们也确实看到它们通常处于C2睡眠状态，因此我们仍在研究为何睡眠状态超过C1。 我们可以看到，几乎所有等待都在数据页面上，偶尔的PFS为DCM页面类型。等待在用户数据库中，而不在tempdb中。我们还看到，等待是在多个数据页面上进行的，其中一些SPID在同一页面上等待。数据库设计确实有几个插入热点，但是旧存储采用了相同的设计。 运行此查询循环100次，我们能够捕获正在磁盘与内存上等待的SPID数量 SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100 “好”的事情是，我们可以在具有相同模型阵列和相似服务器规格的性能环境中轻松重现该问题。对于任何其他地方或如何缩小问题的想法，我将不胜感激。现在，我们的下一个测试包括：带有更新的主板和更多CPU的新服务器；禁用SIOS数据保持器（即使旧存储中已安装该功能）；不同的HBA品牌。 exec sp_Blitz @outputtype = 'markdown' 优先级5：可靠性：-危险的第三方模块-Sophos Limited-Sophos缓冲区溢出保护-SOPHOS〜2.DLL-已安装可疑的危险第三方模块。 优先级200：信息性：-群集节点-这是群集中的节点。-TraceFlag On-跟踪标记1117全局启用。-跟踪标记1118全局启用。-跟踪标记3226全局启用。 优先级200：许可：-正在使用的企业版功能* xxxxx-[xxxxxx]数据库正在使用压缩。如果将此数据库还原到Standard Edition Server上，则还原将在2016 SP1之前的版本上失败。* …
1
sp_cursorprepexec导致5300万次读取？
我们正在使用SQL Server 2012运行Dynamics AX 2012安装。我知道不应再使用游标，但是AX正在使用它，并且我们无法更改此行为，因此必须使用它。 今天，我遇到了一个非常糟糕的查询，读取次数超过5300万，执行时间超过20分钟。 我通过我们的监视工具SentryOne捕获了此查询。 declare @p1 int set @p1=1073773227 declare @p2 int set @p2=180158805 declare @p5 int set @p5=16 declare @p6 int set @p6=1 declare @p7 int set @p7=2 exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 …
2
在过去4小时内重新创建了大多数查询计划
我的SQL Server数据库性能出现问题。我已经找到了此工具sp_BlitzCache。命令执行后，我得到以下语句： 您在过去24小时内创建了92.00％的计划，在过去4小时内创建了92.00％的计划。 在确定问题的同时（使用SQL Server Profiler，我检查了StmtRecompile事件的发生），但我只能找到一些经常被重建的全文本搜索查询。但是，全文搜索查询仅占所有查询的5％。 您有什么建议可能导致其余87％的计划重新生效吗？ 我有SQL Server 2012（版本11.0.6567.0）。 编辑：我添加了我的性能计数器 +---------------------------+--------------------------------+--------------+ | object_name | counter_name | cntr_value | +---------------------------+--------------------------------+--------------+ | SQLServer:Buffer Manager | Background writer pages/sec | 0 | | SQLServer:Buffer Manager | Buffer cache hit ratio | 28436 | | SQLServer:Buffer Manager | Buffer cache hit ratio base …
3
执行计划未使用INDEX，而是使用表扫描
我知道使用索引或表扫描时，SQL Server使用统计信息来查看哪个更好。 我有一个2000万行的表。我在（SnapshotKey，Measure）上有一个索引，并且此查询： select Measure, SnapshotKey, MeasureBand from t1 where Measure = 'FinanceFICOScore' group by Measure, SnapshotKey, MeasureBand 查询返回500k行。因此，查询仅选择表的2.5％的行。 问题是为什么SQL Server不使用我拥有的非聚集索引，而是使用表扫描？ 统计信息已更新。 值得一提的是查询性能还是不错的。 表扫描 强制索引 表/索引结构 CREATE TABLE [t1]( [SnapshotKey] [int] NOT NULL, [SnapshotDt] [date] NOT NULL, [Measure] [nvarchar](30) NOT NULL, [MeasureBand] [nvarchar](30) NOT NULL, -- and many more fields …
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.