标签: sql-server-2014

我有以下MERGE针对数据库发出的语句：

MERGE "MySchema"."Point" AS t
USING (
       SELECT "ObjectId", "PointName", z."Id" AS "LocationId", i."Id" AS "Region"
         FROM @p1 AS d
         JOIN "MySchema"."Region" AS i ON i."Name" = d."Region"
    LEFT JOIN "MySchema"."Location" AS z ON z."Name" = d."Location" AND z."Region" = i."Id"
       ) AS s
   ON s."ObjectId" = t."ObjectId"
 WHEN NOT MATCHED BY TARGET 
    THEN INSERT ("ObjectId", "Name", "LocationId", "Region") VALUES (s."ObjectId", s."PointName", s."LocationId", s."Region")
 WHEN MATCHED 
    THEN UPDATE 
     SET "Name" = s."PointName"
       , "LocationId" = s."LocationId"
       , "Region" …

使用“SQLCMD.EXE”来备份我的 SQL Server Express 数据库多年，我才发现在安装2014 版本后，我再也找不到 SQLCMD.EXE。

在以前的版本中，它位于

C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE

但是在我 2014 年的安装中，没有 SQLCMD.EXE 存在于

C:\Program Files\Microsoft SQL Server\120\Tools\Binn

我的问题：

有机会将 SQLCMD.EXE 导入 SQL Server Express 2014 吗？

在查询中使用列存储索引时，SQL Server 能够使用批处理模式。关于什么可以在批处理模式下运行，什么不能运行的文档很少。请查看以下（激励性）查询计划，其中以批处理模式（绿色）执行的事情数量惊人：

_{（这是一个估计的计划，我用实际计划来验证实际执行方式确实是批处理。）}

请注意，只有 T1 的构建端使用列存储索引。所有探测输入（T2 和 T3）都是行存储。他们的数据似乎过渡到批处理模式。我一直认为批处理模式仅用于通过探针端运行的数据流。

即使数据不是来自列存储索引，数据似乎也可以转换为批处理模式。这就提出了一个问题：为什么 SQL Server 不对仅行存储的查询使用批处理模式？可能对他们中的一些人有益。使用列存储索引是否是使 SQL Server 考虑批处理模式所必需的正式要求？我们可以添加一个带有列存储索引的零行虚拟表来引入批处理模式并实现性能提升吗？

从 SQL Server 2014 开始，究竟可以在批处理模式下运行什么？

我有一个空间索引用于该DBCC CHECKDB报告损坏：

DBCC CHECKDB(MyDB) 
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

空间索引、XML 索引或索引视图“sys.extended_index_xxx_384000”（对象 ID xxx）不包含视图定义生成的所有行。这不一定表示此数据库中的数据存在完整性问题。

空间索引、XML 索引或索引视图“sys.extended_index_xxx_384000”（对象 ID xxx）包含不是由视图定义生成的行。这不一定表示此数据库中的数据存在完整性问题。

CHECKDB 在表“sys.extended_index_xxx_384000”（对象 ID xxx）中发现 0 个分配错误和 2 个一致性错误。

维修级别为repair_rebuild.

删除并重新创建索引不会删除这些损坏报告。没有EXTENDED_LOGICAL_CHECKS但有DATA_PURITY错误是不报告的。

此外，CHECKTABLE尽管它的 CI 大小为 30 MB 并且有大约 30k 行，但该表需要 45 分钟。该表中的所有数据都是点geography数据。

在任何情况下都会出现这种行为吗？它说“这不一定代表完整性问题”。我应该做些什么？CHECKDB正在失败这是一个问题。

此脚本重现了该问题：

CREATE TABLE dbo.Cities(
    ID int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = …

我有一个包含 75 亿行和 5 个索引的大表。当我删除大约 1000 万行时，我注意到非聚集索引似乎增加了它们存储的页数。

我写了一个查询dm_db_partition_stats来报告页面中的差异（之后 - 之前）：

索引1是聚集索引，索引2是主键。其他的都是非聚集的和非唯一的。

为什么那些非聚集索引上的页面会增加？
我预计这些数字在最坏的情况下会保持不变。
我确实看到性能计数器报告删除过程中页面拆分的增加。

删除时，ghost 记录是否必须移动到另一页？这与“唯一标识符”有关吗？

我们正在推出 RCSI，但现在，RCSI 已关闭。

它是可用性组中的主节点。我知道快照以某种方式在辅助节点上使用。如果这是相关的，我会感到惊讶。我打算深入研究这个（查看 dbcc 页面输出）以了解更多信息。希望有人看到过类似的东西。

我正在为大表测试不同的体系结构，我看到的一个建议是使用分区视图，将大表分解为一系列较小的“分区”表。

1 , 2 , 3 , 4

在测试这种方法时，我发现了一些对我来说没有多大意义的东西。当我过滤事实视图上的“分区列”时，优化器只查找相关表。此外，如果我过滤维度表上的那一列，优化器会消除不必要的表。

但是，如果我过滤维度的其他方面，优化器会在每个基表的 PK/CI 上寻找。

以下是相关查询：

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where o.ObservationDateKey >= 20000101
    and o.ObservationDateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where od.DateKey >= 20000101
    and od.DateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey …

所以这是我的场景：

我正在为我的一个项目进行本地化，通常我会在 C# 代码中执行此操作，但是我想在 SQL 中执行更多此操作，因为我试图稍微增强我的 SQL。

环境：SQL Server 2014 Standard，C# (.NET 4.5.1)

注意：编程语言本身应该是无关紧要的，我只是为了完整性而包括它。

所以我在某种程度上完成了我想要的，但没有达到我想要的程度。JOIN除了基本的SQL之外，我已经有一段时间（至少一年）完成了任何 SQL ，这是一个相当复杂的JOIN.

这是数据库相关表的图表。（还有很多，但这部分不是必需的。）

图像中描述的所有关系在数据库中都是完整的 -PK和FK约束都是设置和操作的。所描述的列都null不能。所有的表都有架构dbo。

现在，我有一个查询几乎可以满足我的要求：也就是说，给定ANY Id ofSupportCategories和ANY Id of Languages，它将返回：

如果有合适的，正确的翻译是语言该字符串（即StringKeyId- >StringKeys.Id存在，并在LanguageStringTranslations StringKeyId，LanguageId以及StringTranslationId是否同时存在，那么它的负载StringTranslations.Text为StringTranslationId。

如果LanguageStringTranslations StringKeyId，LanguageId和StringTranslationId组合没有不存在，那么它加载的StringKeys.Name值。该Languages.Id是给定的integer。

我的查询，是否一团糟，如下：

SELECT …

我们有一个使用增量统计的大型分区 SQL Server 数据库。所有索引都是分区对齐的。当我们尝试逐个分区联机重建一个分区时，所有统计信息在重建索引后都会消失。

下面是使用 AdventureWorks2014 数据库在 SQL Server 2014 中复制问题的脚本。

--Example against AdventureWorks2014 Database

CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME)
AS RANGE RIGHT FOR VALUES 
(
   '20130501', '20130601', '20130701', '20130801', 
   '20130901', '20131001', '20131101', '20131201', 
   '20140101', '20140201', '20140301'
);
GO

CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO 
(
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY]
);
GO

CREATE TABLE dbo.TransactionHistory 
(
  TransactionID        INT      NOT NULL, -- not bothering with IDENTITY here
  ProductID            INT      NOT …

我正在使用索引对数据仓库进行性能调整。我对 SQL Server 2014 还是很陌生。Microsoft 描述了以下内容：

“我们将聚集列存储索引视为存储大型数据仓库事实表的标准，并预计它将用于大多数数据仓库场景。由于聚集列存储索引是可更新的，您的工作负载可以执行大量的插入、更新、和删除操作。” http://msdn.microsoft.com/en-us/library/gg492088.aspx

但是，如果您进一步阅读文档，您会发现限制和限制：

“不能有唯一约束、主键约束或外键约束。”

这让我很困惑！出于各种原因（数据完整性、语义层可见的关系......）

所以微软提倡数据仓库场景使用聚集列存储索引；但是，它不能处理外键关系？！

我在这方面正确吗？您会建议哪些其他方法？过去，我在数据仓库场景中使用了非聚集列存储索引，对数据加载进行删除和重建。然而，SQL Server 2014 并没有为数据仓库增加真正的新价值？？

这是我的 C# homeworld 中的一种微不足道的任务，但我还没有在 SQL 中实现它，并且更愿意基于集合（没有游标）解决它。结果集应该来自这样的查询。

SELECT SomeId, MyDate, 
    dbo.udfLastHitRecursive(param1, param2, MyDate) as 'Qualifying'
FROM T

它应该如何工作

我将这三个参数发送到 UDF 中。
UDF 在内部使用参数从视图中获取相关 <= 90 天之前的行。
UDF 遍历“MyDate”并返回 1（如果它应该包含在总计算中）。
如果不应该，则返回 0。此处称为“合格”。

udf 会做什么

按日期顺序列出行。计算行之间的天数。结果集中的第一行默认为 Hit = 1。如果差异达到 90，则传递到下一行，直到差距总和为 90 天（必须通过第 90 天）到达时，将 Hit 设置为 1 并将差距重置为 0 . 它也可以代替结果中的行。

                                          |(column by udf, which not work yet)
Date              Calc_date     MaxDiff   | Qualifying
2014-01-01 11:00  2014-01-01    0         | 1
2014-01-03 10:00  2014-01-01    2         | 0
2014-01-04 09:30  2014-01-03    1         | 0
2014-04-01 10:00 …