Questions tagged «sql-server-2012»

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

3
我可以创建用户定义的表类型并在同一事务中使用它吗？
当我执行以下命令时（在Management Studio中，GO会将命令分成批处理） use tempdb begin tran go CREATE TYPE dbo.IntIntSet AS TABLE( Value0 Int NOT NULL, Value1 Int NOT NULL ) go declare @myPK dbo.IntIntSet; go rollback 我收到死锁错误消息。我的过程已经陷入僵局。我已经在2008、2008R2和2012中看到了这种行为。 有没有办法在创建的同一笔交易中使用我新创建的类型？
2
将ExecutionInstanceGUID与SSISDB相关
SQL Server Integration Services的2012年发行版SSIS提供了一个SSISDB目录，该目录可跟踪程序包的操作（以及其他操作）。使用项目部署模型的解决方案的默认程序包执行将打开到SSISDB的日志记录。 程序包执行时，将System::ExecutionInstanceGUID使用一个值填充，如果使用显式日志记录（到sys.sysdtslog90/ sys.sysssislog）将记录特定程序包执行的所有事件。 我想知道的是如何将ExecutionInstanceGUID绑定到SSISDB目录中的任何内容。或者，是否以SSISDB的值执行SSIS包中的SSIS包catalog.executions.execution_id 最终，我尝试使用现有的自定义审核表，并将其链接回SSISDB目录中的详细历史记录，但似乎找不到链接。
1
在SQL Server Profiler中进行跟踪时，是否可以在过程调用中记录传入的参数值？
我正在尝试使用SQL Server Profiler（我正在使用SQL Server 2012）来生成有用的跟踪，以显示参数值，而不仅仅是显示带有变量名的SQL。该存储过程将遍历大量库存数据，以产生一些非常有价值的结果，而我正尝试记录现有行为，因此我可以对其进行单元测试，准确定义，然后将其重构为合理的形式。 我有一个执行54参数子过程的存储过程，该过程在一个循环内，在该循环中该存储过程创建一个游标，然后执行while循环。这是一个简化的视图： CREATE PROCEDURE [dbo].[OuterProcedure] ( @ProductCode varchar(8), -- 41 more parameters omitted ) AS SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SET NOCOUNT ON DECLARE @AboutFourHundredLocalvariables -- omit about 400 local variable declarations. -- OMIT ABOUT 10 temporary table declarations. DECLARE aCursor CURSOR FAST_FORWARD FOR SELECT …
1
工作区内存内部
根据克里斯蒂安·博尔顿，布伦特·奥扎尔等人撰写的有关SQL Server 2008内部和故障排除（从伊利诺伊州本地图书馆借来的）的阅读书。可以确认或纠正我的理解。 每个需要查询内存授予的查询或操作都将需要工作空间内存。在使用排序，哈希匹配联接，并行性（不确定），批量插入（不确定），索引重建等的一般查询中，将需要查询工作区内存。 工作区内存是SQL Server缓冲池的一部分（分配为缓冲池的一部分），最大工作区内存为分配给缓冲池的内存的75％。默认情况下，单个查询不能获得超过25％的工作空间内存（在SQL 2008 / SQL 2012中-由资源调控器默认工作负载组开箱即用）。 寻求我的理解的确认 1）考虑具有48 GB RAM和最大服务器内存配置为40 GB的系统，这是否意味着最大工作空间内存限制为30 GB，并且单​​个查询不能获取超过10 GB的工作空间内存（查询内存）。因此，如果您有一个错误的查询要处理大量的哈希联接的十亿行，并且需要超过10 GB的内存（工作空间内存），那么是否还要遍历此内存授予队列或立即溢出到磁盘？ 2）如果为执行大规模排序操作的查询分配了5 MB的工作空间内存，并且在查询执行期间查询优化器意识到由于统计错误或缺少索引，此查询实际上将需要30 MB的工作空间内存将立即溢出到tempdb。即使系统在执行期间有足够的工作区内存，一旦查询在执行期间超出了授予的工作区内存，它也必须溢出到磁盘上。我的理解正确吗？
4
查询以选择联接上的最大值
我有一个用户表： |Username|UserType|Points| |John |A |250 | |Mary |A |150 | |Anna |B |600 | 和级别 |UserType|MinPoints|Level | |A |100 |Bronze | |A |200 |Silver | |A |300 |Gold | |B |500 |Bronze | 我正在寻找一个查询来获取每个用户的级别。类似于以下内容： SELECT * FROM Users U INNER JOIN ( SELECT TOP 1 Level, U.UserName FROM Levels L …
1
当where子句对`value（）`进行过滤时，为什么不使用二级选择索引？
设定： create table dbo.T ( ID int identity primary key, XMLDoc xml not null ); insert into dbo.T(XMLDoc) select ( select N.Number for xml path(''), type ) from ( select top(10000) row_number() over(order by (select null)) as Number from sys.columns as c1, sys.columns as c2 ) as N; 每行的样本XML： <Number>314</Number> …
1
SQL Server的优化器如何估计联接表中的行数？
我在AdventureWorks2012数据库中运行此查询： SELECT s.SalesOrderID, d.CarrierTrackingNumber, d.ProductID, d.OrderQty FROM Sales.SalesOrderHeader s JOIN Sales.SalesOrderDetail d ON s.SalesOrderID = d.SalesOrderID WHERE s.CustomerID = 11077 如果查看估算的执行计划，则会看到以下内容： 初始索引查找（右上）使用IX_SalesOrderHeader_CustomerID索引并在文字11077上进行搜索。其估计值为2.6192行。 如果使用DBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAM，则表明值11077在两个采样键11019和11091之间。 11019和11091之间的不同行的平均数为2.619718，或舍入为2.61972，这是为索引搜索显示的估计行的值。 我不了解的部分是针对SalesOrderDetail表的聚集索引查找的估计行数。 如果我运行DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID')： 因此，SalesOrderID（我要加入）的密度为3.178134E-05。这意味着1 / 3.178134E-05（31465）等于SalesOrderDetail表中唯一SalesOrderID值的数量。 如果在SalesOrderDetail中有31465个唯一的SalesOrderID，则分布均匀，每个SalesOrderID的平均行数为121317（总行数）除以31465。平均值为3.85561 因此，如果要循环遍历的估计行数是2.61972，并且要返回的平均值是3.85561，则我认为估计行数将是2.61972 * 3.85561 = 10.10062。 但是估计的行数是11.4867。 我认为我对第二个估算值的理解是不正确的，不同的数字似乎表明了这一点。我想念什么？
2
重置SQL Server 2012序列
我正在测试和填充利用该SEQUENCE对象的特定表。在这个过程中，我正在测试用成千上万的插入行填充表（因为我不熟悉如何编程）。我在此特定表上看到的问题是，当我开始另一个人口测试时，SEQUENCE它不会重置回我想要的第一个数字（即1）。 当我希望重新运行新测试时，请删除有问题的表，然后运行以下命令： DROP SEQUENCE foo.fee; GO DROP SCHEMA foo; GO 当我想重新运行测试时，我运行以下SCHEMA＆SEQUENCE命令，它们按以下顺序触发： CREATE SCHEMA foo; GO CREATE SEQUENCE foo.fee START WITH 1 INCREMENT BY 1 NO CYCLE NO CACHE; GO 然后创建表： CREATE TABLE foo.sample_table_with_data (order_number bigint PRIMARY KEY NOT NULL, sample_column_one nvarchar(max) NULL, sample_column_two nvarchar(max) NULL, sample_column_three nvarchar(max) NULL) GO 一旦完成，我将运行以下插入命令50,000次： …
4
登录不会在可用性组之间同步
AlwaysOn组中有2台服务器。 每个同步数据库中的用户帐户都位于两台服务器上，而数据库实例级别的登录仅存在于其中一台服务器上。即一台服务器上缺少DBINSTANCE-> Security-> Logins。 因此，当发生故障转移时，我在第二台服务器上遇到登录失败（该服务器没有相应的实例级别登录名）。 我该如何克服这个问题？我是否应该以特殊方式设置用户帐户？
4
CREATE FILE遇到操作系统错误5（访问被拒绝。）
我正在尝试在SQL Server Management Studio中执行以下脚本： USE [master] GO CREATE DATABASE [test1] ON PRIMARY ( NAME = N'test1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\test1.mdf', SIZE = 70656KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB) LOG ON ( NAME = N'test1_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\test1_log.ldf', SIZE = 164672KB , MAXSIZE = …
1
这是服务器过载的症状吗？
我一直在尝试诊断应用程序中的运行缓慢。为此，我记录了SQL Server 扩展事件。 对于这个问题，我正在研究一个特定的存储过程。 但是有一组核心的存储过程，这些存储过程同样可以用作“一对一调查” 而且每当我手动运行其中一个存储过程时，它总是运行很快 如果用户再次尝试：它将运行很快。 存储过程的执行时间千差万别。此存储过程的许多执行都在<1s内返回： 而对于“快速”存储桶，它远小于1s。实际上大约是90毫秒： 但是有很多用户需要等待2s，3s，4s秒。有些必须等待12s，13s，14s。然后就是真正的可怜人，他们必须等待22、23、24秒。 30秒后，客户端应用程序放弃，中止查询，用户不得不等待30秒。 相关查找因果关系 所以我尝试关联： 持续时间与逻辑读取 持续时间与物理读取 持续时间与CPU时间 而且似乎没有任何关联。似乎没有原因 持续时间与逻辑读取：不管是逻辑读取还是多次读取，持续时间仍在剧烈波动： 持续时间与物理读取：即使查询不是从缓存中进行的，并且需要大量物理读取，它也不会影响持续时间： duration vs cpu time：查询所用的CPU时间为0s，还是CPU的完整时间为2.5s，则持续时间具有相同的可变性： 奖励：我注意到持续时间v物理读取和持续时间v CPU时间看起来非常相似。如果我尝试将CPU时间与“物理读取”相关联，就证明了这一点： 原来很多I / O占用了CPU。谁知道！ 因此，如果执行查询的行为没有什么可以解释执行时间的差异，这是否暗示它与CPU或硬盘驱动器无关？ 如果CPU或硬盘驱动器是瓶颈；难道不是瓶颈吗？ 如果我们假设是CPU是瓶颈，那么，该服务器的CPU电源不足： 那么执行使用更多CPU时间的时间不会更长吗？ 因为他们必须使用过载的CPU与他人一起完成？ 对于硬盘驱动器类似。如果我们假设硬盘驱动器是瓶颈；硬盘驱动器对此服务器没有足够的随机吞吐量： 那么执行更多物理读取操作不会花费更长的时间吗？ 因为他们必须使用过载的硬盘I / O与其他人一起完成？ 存储过程本身既不执行也不要求任何写操作。 通常它返回0行（90％）。 有时它将返回1行（7％）。 很少会返回2行（1.4％）。 在最坏的情况下，它已返回2行以上（一次返回12行） 因此，这并不像在返回疯狂的数据量。 服务器CPU使用率 服务器的处理器使用率平均约为1.8％，偶尔会激增至18％-因此看来CPU负载似乎不是问题： 因此，服务器CPU似乎没有过载。 但是服务器是虚拟的... 宇宙之外的东西？ 我能想象的唯一剩下的就是服务器领域之外的东西。 …
3
为什么并行（分区流）运算符会将行估计值减少到1？
我正在使用SQL Server 2012 Enterprise。我遇到了一个SQL计划，该计划表现出一些我不完全直观的行为。在执行大量并行索引扫描操作之后，发生了并行（分区流）操作，但是该操作杀死了索引扫描（Object10.Index2）返回的行估计，从而将估计值减小为1。我已经做了一些搜索，但是还没有遇到任何可以解释这种现象的信息。查询非常简单，尽管每个表都包含数百万的记录。这是DWH加载过程的一部分，整个中间数据集都被触及过几次，但是我遇到的问题尤其与行估计有关。有人可以解释为什么并行（Repartition Strems）运算符中的精确行估计为1吗？也， 我已经发布了完整的计划以粘贴计划。 这是有问题的操作： 在添加更多上下文的情况下包括计划树： 我能否碰到Paul White提交的Connect项目的一些变体（在此处，他的博客有进一步的深入探讨）？至少这是我发现的唯一一件事，即使没有TOP运算符，它似乎也几乎接近我所遇到的问题。
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.