标签: sql-server-2014

我的机器有当前（2014 年 3 月）版本的 SSDT、Visual Studio 2012 Professional 和 SQL Server 2014 Developer。我有一个MyProject.sqlproj针对 SQL Server 2014的 SQL Server 项目（我们称之为）。我尝试了以下操作：

MsBuild.exe MyProject.sqlproj 
            /t:SqlPublish /p:SqlPublishProfilePath=Somewhere.publish.xml

这失败并出现以下错误：

部署错误 部署 72002：内部错误。
类型为 Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider 的数据库平台服务无效。您必须确保服务已加载，或者您必须提供有效数据库平台服务的完整类型名称。

如果我将此项目切换到目标 2012（并指向 2012 实例），则相同的命令会成功运行。我之前问过一个可能相关的问题，那里的答案解决了我的问题，但这不是这里的问题——如果我SqlPackage.exe直接使用，我可以成功发布这个 2014 DACPAC 。

发生了什么，我该如何解决？

我在 SQL Server 2014 中遇到一个查询问题。第一次运行该查询时，需要很长时间才能生成执行计划。

奇怪的是，它在 SQL Server 的所有早期版本（2012、2008 R2、2008 等）中都运行良好。它似乎与所涉及的表之一上的唯一索引以及主查询中一定数量的子查询有关。

以下是查询中涉及的表。与原始表格相比，我已经简化了表格很多，但问题仍然存在。请注意 table2 上的唯一约束，这似乎是导致问题的原因。无论是Table2上的唯一约束、唯一索引、甚至主键，结果都是一样的。

IF OBJECT_ID('Table2') IS NOT NULL DROP TABLE [Table2]
IF OBJECT_ID('Table1') IS NOT NULL DROP TABLE [Table1]
CREATE TABLE [dbo].[Table1] ( [ReferencedColumn] [int] NOT NULL PRIMARY KEY)
CREATE TABLE [dbo].[Table2] ( [ReferencedColumn] [int] NOT NULL FOREIGN KEY REFERENCES [Table1] ([ReferencedColumn]), [IntColumn] [int] NOT NULL, [AnotherIntColumn] [int] NULL )
CREATE UNIQUE NONCLUSTERED INDEX [IX_Table2] ON [dbo].[Table2] ([ReferencedColumn], [IntColumn])

如果我随后使用 select 语句中的索引从表中执行一些子查询，则第一次需要很长时间才能完成（在我的测试中超过 30 秒）。

SELECT  (SELECT F2.IntColumn FROM Table2 …

我有一个用于查询链接服务器的服务代理队列的激活过程。我已使用此处找到的方法签署了该程序。但是，我不断在 sql server 日志中看到以下消息：

在队列 'DBName.dbo.TestReceiveQueue' 上运行的激活过程 '[dbo].[TestProc]' 输出以下内容： '访问远程服务器被拒绝，因为当前安全上下文不受信任。

奇怪的是我在同一个数据库中有几个不同的激活程序，由同一个证书签名，也做链接服务器查询，并且工作正常。出于某种原因，这个程序拒绝。

这是一些（主要）重现问题的代码。我已经创建了证书和关联的登录名。

CREATE PROCEDURE TestProc
WITH EXECUTE AS OWNER
AS
BEGIN
    SET NOCOUNT ON;

DECLARE @convHandle UNIQUEIDENTIFIER;
DECLARE @msgTypeName SYSNAME;
DECLARE @status TINYINT;
DECLARE @srvName NVARCHAR(512);
DECLARE @srvConName NVARCHAR(256);
DECLARE @msgTypeValidation AS NCHAR(2);
DECLARE @msgBody NVARCHAR(256);
DECLARE @cmd AS NVARCHAR(50);


RECEIVE TOP(1)
        @convHandle = conversation_handle,
        @msgTypeName =  message_type_name,
        @status = status,
        @srvName = service_name,
        @srvConName = service_contract_name,
        @msgTypeValidation = validation,
        @msgBody = CAST(message_body AS NVARCHAR(256))
        FROM TestReceiveQueue;

    --SELECT …

因此，我正在运行本地主机 SQL Server，并尝试编辑表的前 200 行。然后我收到了这个（原件是德文的，我通过网络找到的）：

此后，SSMS 关闭。我研究了一下，发现如果 PATH 变量超过 2K 个符号，这是一个已知问题。我的是1336，所以问题应该出在其他地方。

这是路径变量：

C:\Program Files\Common Files\Microsoft Shared\Windows Live;
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;
C:\ProgramData\Oracle\Java\javapath;
C:\Program Files (x86)\Intel\iCLS Client\;
C:\Program Files\Intel\iCLS Client\;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Intel\WiFi\bin\;
C:\Program Files\Common Files\Intel\WirelessCommon\;
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;%systemroot%\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;
C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;
C:\Program Files\Microsoft SQL …

VS 2013 中构建的 SSIS 包（v 12.0.31101）
DTSExec 在 SQL Server 2014 上运行

描述：从版本 8 到版本 6 的程序包迁移失败，错误为 0xC001700A“程序包中的版本号无效。版本号不能大于当前版本号。”。

当人们使用 SQL 2012 时，我看到很多关于上述内容的 google 结果，但我使用的是 2014 年，找不到任何支持。版本应该匹配（即都是包版本 8）

select @@version

Microsoft SQL Server 2014 (RTM-CU14) (KB3158271) - 12.0.2569.0 (X64) 2016 年 5 月 27 日 15:06:08 版权所有 (c) Windows NT 6.3 上的 Microsoft Corporation Enterprise Edition（64 位）（内部版本 9600：）

附加信息 - 看起来它正在运行较旧的 DTSExec，可能来自现已删除的 sql 2012 实例。我将如何修复/重新指向 2014？

适用于 64 位的Microsoft (R) SQL Server 执行包实用程序版本11.0.2100.60 版权所有 (C) Microsoft Corporation。版权所有。

我正在使用 FluentMigrator 在 SQL Server 2014 数据库上进行数据库迁移。如果我使用重命名构建器来重命名表，如下所示：

Rename.Table("Old Name").To("NewName");

然后我是否需要删除并重新创建引用表旧名称的任何外键，或者 SQL（或 FM）是否知道更新引用？

我使用 SQL Server 2014 并且我已经运行了这个测试 T/SQL。

    BEGIN TRY
        BEGIN TRANSACTION T1

        CREATE TABLE aa9
        (
            A int
        )

        SAVE TRANSACTION S1

        INSERT INTO aa9 (A) VALUES ('aa')

        COMMIT TRANSACTION T1

    END TRY 
    BEGIN CATCH 
        ROLLBACK TRANSACTION S1
        PRINT 'Error ..... '
        ;throw
    END CATCH 

为什么我会收到此错误：

消息 3931，级别 16，状态 1，第 17 行
当前事务无法提交，也无法回滚到保存点。回滚整个事务。

我应该能够将事务回滚到我的 SavePoint 事务吗？

我需要计算正在运行的存储过程之一的平均持续时间。例如SP的持续时间（以秒为单位）为：1,30,2,5,2,15,35,7,3,4,2,1,2,40

我必须消除前 10% 的调用（快速调用）和后 10% 的调用（慢速调用）并计算其余调用的平均值。

由于必须定期在庞大的数据集上完成此操作，是否有更好的方法可以最大限度地减少性能损失？

我知道的方法是：

使用以下查询消除前 10% 的记录，该查询会产生两个值 (1,1)

SELECT TOP 10 PERCENT WITH TIES value FROM #t order by value asc

底部 10% 给出 (35,40)，

SELECT TOP 10 PERCENT WITH TIES value FROM #t order by value desc

消除这些值（1、1、35 和 40）后，平均值将为 7。

微软SQL 2014

如果可能的话，有人可以提供tsql来从服务器属性和数据库属性页面中提取设置吗？

谢谢

我遇到一些查询有时比从服务器返回结果所需的时间长 500 毫秒的情况。准确地说：正常响应时间为 5-6 毫秒，与服务器的 ping 时间相同。SQL 探查器的正常查询持续时间约为 1 毫秒。有时响应时间会上升到500ms左右。从来没有 300 或 400 毫秒，总是非常接近 500 毫秒。SQL Profiler 报告的实际查询持续时间仍然只有 1 毫秒左右。我使用 Wireshark 分析了网络流量，发现当响应时间为 500 毫秒时，我几乎立即收到请求包的 ACK（在 5-6 毫秒 ping 时间内）。这一定意味着服务器快速接收请求并且这不是与网络相关的问题，对吧？

因此，由于某种原因，SQL 服务器收到请求，但在执行查询之前会等待，或者执行 SQL 探查器的“持续时间”中未包含的其他操作。看起来很奇怪，它总是在 500 毫秒左右 - 这会给任何人带来任何关联吗？PS：我也觉得SQL Server这么快发送ACK可能有点奇怪？通常我希望它等待更长的时间，事实上，当响应时间很短时，就不会发送 ACK（只是搭载在响应包上）。

编辑：我正在循环测试这个。大多数响应速度很快，只有一小部分有这种延迟。延误通常是分组的。这是一个生产服务器，我认为它可能与同时发生的其他请求有关，但令我困惑的是为什么它总是有 500 毫秒的延迟，以及为什么它没有包含在分析器的“持续时间”列中。