小编Mag*_*ier的帖子

我已经使用过几次部署后脚本，并且总是直观地使用构建操作“PostDeploy”，因为它就是这样。现在我第一次尝试按照脚本模板中的内置指令使用":r somescript.sql"语法。

此行立即被标记为错误：

“':' 旁边的 SQL80001 语法错误”

我找到了将 PDS 设置为“无”的建议。这没有帮助，错误仍然存​​在。我在这里缺少什么？

我遇到了开发人员代码，其中 SqlCommand.Prepare() （参见 MSDN）方法在执行 SQL 查询之前被广泛使用。我想知道这样做有什么好处？

样本：

command.Prepare();
command.ExecuteNonQuery();
//...
command.Parameters[0].Value = 20;
command.ExecuteNonQuery();

我玩了一点并进行了追踪。调用Prepare()方法后执行Command，使Sql Server执行如下语句：

declare @p1 int
set @p1=1
exec sp_prepexec @p1 output,N'@id int,@desc text',N'INSERT INTO dbo.testtable (id) VALUES (@id)',@id=20'
select @p1

之后，当 Parameter 获取它的值并被SqlCommand.ExecuteNonQuery()调用时，将在 Sql-Server 上执行以下操作：

exec sp_execute 1,@id=20

对我来说，这看起来就像语句在Prepare()执行时被编译。我想知道这样做有什么好处？这是否意味着它被放入计划缓存中，并且可以在使用所需参数值执行最终查询后立即重新使用？

我发现（并在另一个问题中记录了它）使用 SqlParameters 执行的 SqlCommands 总是包含在sp_executesql过程调用中。这使得 Sql Server 能够独立于参数值存储和重用计划。

关于这一点，我想知道该prepare()方法是无用的还是过时的，或者我在这里遗漏了什么？

我正在查看一个对 SQL Server 使用高度动态 sql 查询的应用程序。查看以非常奇怪和复杂的方式构建的查询，但这是一个不同的故事，我告诉它是为了给我无法（太愚蠢）自己找出问题的充分理由......我看不到查询用sp_executesql.

但是当我跟踪时，我可以看到很多查询都包含在sp_executesql. 整个应用程序解决方案甚至根本不包含该命令sp_executesql。

所以我想知道是否有一种我还不知道的配置强制软件默认使用 sp_executesql 包装查询？

什么可能导致这种行为？

我正面临着一些重复发生的死锁，其中一个是 Keylock 并且包含一个带有 XLOCK 提示的 SELECT 查询，该查询成为死锁的受害者。另一个语句是对作为第一个查询视图的一部分的一个表的 INSERT。

看法：

create view dbo.viewE
 as
    select * from dbo.E  
    where myValue > 13000 

选择查询：

select * from dbo.viewE with (XLOCK) where A > GETUTCDATE() 

插入语句：

INSERT INTO [dbo].[E] (myValue,A) VALUES (10,GetDate())

基础表 dbo.E 在大约 20 列中包含大约 300 万行，其中一些是 ntext。

取出查询并使用两个事务手动模拟它，该行为是可重现的。如果从选择中删除 XLOCK，则行为会发生变化。

死锁图：

<deadlock-list>
 <deadlock victim="process222222221">
  <process-list>
   <process id="process222222221" taskpriority="0" logused="0" waitresource="KEY: 5:72057604035644444 (ccdf51accc0c)" waittime="2522" ownerId="27202256401" transactionname="SELECT" lasttranstarted="2015-09-14T16:32:36.160" XDES="0x2f1ec5ca0" lockMode="RangeX-X" schedulerid="15" kpid="12936" status="suspended" spid="359" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2015-09-14T16:32:36.160" lastbatchcompleted="2015-09-14T16:32:36.160" clientapp="x" hostname="x" hostpid="14536" …

有没有办法可以确定计划是为特定查询生成的，还是在计划缓存中找到的？

我正在尝试改进这个（子）查询作为更大查询的一部分：

select SUM(isnull(IP.Q, 0)) as Q, 
        IP.OPID 
    from IP
        inner join I
        on I.ID = IP.IID
    where 
        IP.Deleted=0 and
        (I.Status > 0 AND I.Status <= 19) 
    group by IP.OPID

Sentry Plan Explorer 指出了由上述查询执行的表 dbo.[I] 的一些相对昂贵的 Key Lookups。

表 dbo.I

    CREATE TABLE [dbo].[I] (
  [ID]  UNIQUEIDENTIFIER NOT NULL,
  [OID]  UNIQUEIDENTIFIER NOT NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  [] UNIQUEIDENTIFIER NULL,
  []  UNIQUEIDENTIFIER NOT NULL,
  []  CHAR (3) NOT NULL,
  []  CHAR (3)  DEFAULT ('EUR') NOT NULL,
  []  DECIMAL …

我想创建一个发布配置文件，它可以进行完整的架构比较和发布，但不会删除在新旧版本之间删除的任何表或任何列。

我知道设置中的阻止可能的数据丢失选项。AFAIK 这会停止发布过程，以防数据丢失。所以问题是，模式升级过程会被中断（在不知何故？）还是会完成但受影响的表将被排除在外？

如果表已添加和删除列，新列是否会添加到架构中，尽管由于潜在的数据丢失而阻止数据丢失选项会停止架构更新？

编辑 09.08.2016：

我想添加这些链接以补充有关背景的其他信息的问题：

• MS Connect 进入这个BUG
• MS 关于此 BUG 的社交讨论

为了获得概览和可比较的数据，我当前的任务是创建一个性能基线，以获取有关不同生产 SQL Server 实例的一些数据。

我的想法是：

• 我想使用几个 DMV
• 我想包括一个探查器跟踪（包括执行计划）
• 我想包括性能数据

所以我试图实现的是一个通用的性能监控可启动和可停止（也可调度）返回：

1. 确定正在进行的性能优化任务是否成功所需的所有信息

2. 几个汇总的简单数字有助于形象化长期进展……尤其是。用于管理;-)

3. 探查器跟踪中的可重新执行执行计划，以通过索引优化任务比较各个队列的更改和改进

我发现了一些描述性能基线创建的信息。它们中的大多数要么非常复杂，要么只关注所需的性能指标之一（主要是性能数据）。

最匹配的示例/描述如下：为 SQL Server 创建性能基准

问题是：

有没有人有以快速可行的方式创建这种性能监视器的经验？

索引重建所需的时间是否取决于碎片级别？

如果重建一个 40% 碎片的索引需要 1 分钟，那么重建一个 80% 碎片的索引大约需要 2 分钟吗？

我要求执行所需操作可能需要的 RUNTIME（例如以秒为单位），而不是在什么特定情况下需要哪个操作。我知道应该完成索引重组或重建/统计更新时的基本最佳实践。

这个问题不询问 REORG 以及 REORG 和 REBUILD 之间的区别。

背景：由于设置了不同的索引维护工作（每天晚上，周末的工作更重......）我想知道是否应该在中低碎片索引上更好地执行每日“轻强度”离线索引维护工作以保持关闭时间很小 - 或者甚至无关紧要，并且在 80% 碎片化索引上的重建可能与对同一索引 40% 碎片上的相同操作花费相同的关闭时间。

我遵循了这些建议，并试图找出自己发生了什么。我的实验设置：在测试服务器上不做任何其他事情并且没有被任何人或其他任何人使用，我在唯一标识符主键列上创建了一个带有聚集索引的表，其中包含一些附加列和不同的数据类型 [2 个数字、9 个日期时间和2 varchar(1000)] 并简单地添加行。对于呈现的测试，我添加了大约 305,000 行。

然后我使用了一个更新命令并随机更新了一系列过滤整数值的行，并使用不断变化的字符串值更改了其中一个 VarChar 列以创建碎片。在此之后我检查当前avg_fragmentation_in_percent的水平sys.dm_db_index_physical_stats。每当我为基准创建“新”碎片时，我都会将此值添加physical_page_count到我的记录中，如下图所示。

然后我跑了：Alter index ... Rebuild with (online=on); 并CPU time通过使用STATISTICS TIME ON到我的录音中。

我的期望：我期望至少看到一种线性曲线的指示，显示碎片级别和 CPU 时间之间的依赖性。

不是这种情况。我不确定这个程序是否真的适合一个好的结果。也许行数/页数太少？

然而，结果表明我原来的问题的答案肯定是NO。看起来 SQL Server 重建索引所需的 CPU 时间既不取决于碎片级别，也不取决于基础索引的页数。

第一个图表显示了与之前的碎片级别相比，重建索引所需的 CPU 时间。正如您所看到的，平均线是相对恒定的，碎片化与可观察到的所需 CPU 时间之间根本没有关系。

为了考虑更新后索引中页数变化可能需要或多或少的重建时间的可能影响，我计算了 FRAGMENTATION LEVEL * PAGES …

我正在尝试使用 sqlpackage.exe 实用程序部署 ssdt 项目。我收到以下错误（德语）：

Fehler bei der Erstellung des Bereitstellungsplans。Die Bereitstellung kann nicht fortgesetzt werden。元素属性-类别长度在元素-oder Annotation-Klasse PersistedResolvableAnnotation中尚无定论。

这意味着…… 喜欢：

创建部署计划时出错。部署无法继续。属性类 Length 不包含在元素或注释类 PersistedResolvableAnnotation 中。

我找不到关于“PersistedResolvableAnnotation”的很多信息。但我意识到它包含在 dacpac 的 model.xml 中。

它包含一些与此类似的 SqlLogins 定义：

<Element Type="SqlUser" Name="[Angela]">
            <Property Name="IsWithoutLogin" Value="True" />
            <Relationship Name="DefaultSchema">
                <Entry>
                    <References Name="[Angela]" Disambiguator="8" />
                    <Annotation Type="**PersistedResolvableAnnotation**" Name="[Angela]">
                        <Property Name="TargetTypeStorage" Value="SqlSchema" />
                        <Property Name="Length" Value="8" />
                        <Property Name="Offset" Value="62" />
                    </Annotation>
                </Entry>
            </Relationship>
        </Element>

Angela（和其他候选人）不作为 Login 存在于目标服务器上，尽管他们是目标数据库中的注册数据库用户。我期待另一个错误——如果有的话——而不是这个无用的错误。

该项目的数据库基于一个非常古老的 SQL Server 版本。是否有可能这是来自 Sql Server 版本的一些已弃用的功能/语法或属性，并且根本不受支持？有谁知道更多详情？