我有一个 SQL Server 2016 实例，我刚刚注意到某些用户的某些用户登录名未列出。例如，如果我执行此查询：
select count(*) FROM sys.database_principals a where type = 'U'
我收到的计数是1348. 但是如果我执行这个查询：
execute as user = 'some_user';
select count(*) FROM sys.database_principals a where type = 'U';
revert;
我收到的计数为92，这意味着存在1256上述用户看不到的用户。如果我授予用户db_accessadmin数据库角色成员资格，那么他们就可以看到1348从上述查询返回的所有用户。但我不想授予db_accessadmin所有用户，因为这提供的访问权限比我想要授予的要多得多。
我已将显示的 92 个用户之一的属性与未显示的用户的属性进行了比较，但我没有注意到任何看起来允许列出该用户的属性。
我该如何允许所有用户都列在对database_principals 的查询中？
我正在将数据库移动到新服务器。
新服务器运行 SQL Server 2016，当前服务器运行 SQL Server 2008。
我需要在几周内制定备份/后备计划（以防出现问题 - 我可以将我的应用程序切换回 2008 Server 并继续工作）。
我想知道是否可以启用复制（或替代方案？）并使所有事务/合并在 2008 实例上同步，以便两个数据库都是最新的，以防我需要切换到旧数据库？
由于业务需求，我们必须能够回退到 SQL Server 2008。这是没有商量余地的。
我有一个具有复杂逻辑和三个深度级别（嵌套视图）的视图。由于复杂，我无法粘贴执行计划。
由于视图的目的是向数据分析师提供一些业务分析，而他们正在开发报告时，他们会通过执行选择（前 N 个）查询来检查视图样本。
视图中的这个（前 N 个）查询执行得非常糟糕，因为优化器正在为此视图选择不同的执行计划（afaik CQScanTopSortNew）
我尝试对顶部 (N) 用例进行一些优化，例如使用哈希连接，但这会破坏非顶部 (n) 用例。
非顶级 (n) 表现良好。我想知道如何防止优化器在具有 top (n) 子句时选择不同的执行计划，而不会显着改变视图的结构或功能。
例如，如果我在视图中添加一个 select distinct ，优化器总是会选择正确的计划，但视图的功能会发生变化。
sql-server execution-plan sql-server-2016 performance-tuning
我正在将 Ola Hallengren IndexOptimize 脚本用于大小为 7 TB、表超过 300,000 的 SQL 2016 数据库。我每晚只有 6 小时的时间来管理索引。我正在使用 timelimit 参数在 6 小时后停止作业。
问题是，每天晚上索引作业都按字母顺序从索引的开头开始，并且只能通过大约相同的 4,000 个表。
我该怎么做才能让索引作业覆盖数据库中的所有索引？也许通过创建多个作业，一周中的每个晚上做一个索引子集？或者有没有办法让工作在之前停止的第二天重新开始？
所有的表都在同一个数据库模式中。这是供应商提供的数据库，我无法更改数据库架构。
在此先感谢您的任何指导。
我目前的工作步骤如下：
EXECUTE [dbo].[IndexOptimize]
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 10,
@FragmentationLevel2 = 40,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@PartitionLevel = 'N',
@MaxDOP = 0,
@SortInTempdb = 'Y',
@TimeLimit = 21600,
@LogToTable = 'Y'
我正在查看SQL Server 标准版和企业版之间的差异，但无法重现此演示中宣传的差异，以解释这些差异- 我在跨标准版和企业版运行查询时观察到的性能具有可比性，并且查询并行运行执行计划中的分区表。
我已经证实：
set statistics time on似乎在 SQL Server 2016 中，这种差异是不可重现的。此功能是否还有其他影响 - 也许我没有测试正确的东西，但查询与演示中的查询相当。
这是我用来测试的脚本：
-- MAXDOP is 10
-- structure of table
--Column type
--testData.PKcolumn1 bigint
--testData.PKcolumn2 int
--date datetime
--testData.PKcolumn3 bigint
--metric1 float
--metric2 float
--metric3 float
--metric4 float
--index_description index_keys
--clustered, unique, primary key located on ps_testData categoryId, transactionId, date
--pf_testData/ps_testData is a range right datetime partition scheme, fanout 368
GO
-- Actual partition count: …sql-server parallelism partitioning sql-server-2016 enterprise-edition
是否OPTION (RECOMPILE)用于生产？
这个选项似乎受到了很多负面报道。值得吗？
我有一个 DBA，到目前为止，他不喜欢OPTION (RECOMPILE)Report ETL ssis 代理查询的核心思想。这些查询（据我所知）按计划的时间间隔按顺序执行。
回溯历史：
等等，你确定 OPTION (RECOMPILE) 是答案吗？
我所知道的风险：
因此，鉴于上述情况 - 该选项是否在现实世界中实际使用？我推荐（并测试）它作为生产环境的一个选项是否可以接受？
我被要求提供更多细节。我提到我确实有其他与此主题相关的帖子。让我提供更多信息：
serializable在休眠层内；我了解到，这对于大批量生产环境来说并不是最佳选择。让我分享其他问题：
sql-server ssis hibernate sql-server-2016 performance-tuning
我试图了解 SQL Server 2016 SP3 系统上缓存元数据的一些执行计划，但我无法将我所看到的内容与文档相一致。
文档sys.dm_exec_cached_plans说它包含：
SQL Server 缓存每个查询计划的一行，以加快查询执行速度。
在我正在观察的系统上，该视图现在有 41,283 行。其中绝大多数（37,594 行）是cacheobjtype =“Compiled Plan”和objtype =“Adhoc”。
文档sys.dm_exec_query_stats说它包含：
缓存计划中每个查询语句一行，行的生命周期与计划本身相关。当从缓存中删除计划时，相应的行将从该视图中删除。
我预计此视图中至少有 37,594 行（每个缓存计划一个，如果某些缓存计划有多个语句，则可能更多）。但是，该视图总共有 6,867 行。
这种差异是如此之大，以至于我必须假设我误解了这些视图中应该包含的内容。
sys.dm_exec_query_stats有人可以帮助我理解为什么与 相比 的行数如此之少吗sys.dm_exec_cached_plans？
我尝试在 上将表内部连接在一起plan_handle，唯一的匹配是 1:1 - 换句话说，有数以万计的缓存计划，没有“查询统计”行。
我还认为差异可能是由sys.dm_exec_procedure_stats或中的许多行来解释的sys.dm_exec_trigger_stats，但事实并非如此（分别为 93 行和 2 行）。
对于任何对这个问题的“为什么”感到好奇的人，我试图查看缓存中的各种计划有多旧，并且我不确定除了加入和sys.dm_exec_query_stats检查之外还有什么方法可以做到这一点creation_time。
以下是我用来获取上面引用的数字的查询：
-- total cached plans
SELECT COUNT_BIG(*) AS total_cached_plans
FROM sys.dm_exec_cached_plans decp
-- totals by type
SELECT decp.cacheobjtype, decp.objtype, COUNT_BIG(*) AS plan_count
FROM sys.dm_exec_cached_plans …据我了解，当您在表上定义列时，您就定义了其精度。该精度占用 1 个字节并存储在列级别。如果您使用 5 或更高的精度，则 DateTime2 列每行将占用 8 个字节。（精度不存储在行级别。）
但是，当您将相同的 DateTime2 转换为 VarBinary 时，它将占用 9 个字节。这是因为它需要存储在列级别的精度字节。
我很好奇这与 DateTime2 存储在内存中有何关系。假设内存中有 1,000,000 个 DateTime2（每个的精度为 5 或更高）。它会占用 8,000,000 字节内存还是 9,000,000 字节内存？
基本上，我想知道默认精度的 DateTime2 是否会比普通的 DateTime 对页面预期寿命造成更大的压力？
我有一个查询，我在查询存储中强制执行一个计划（该计划是为此查询编译的 SQL Server）如果我在强制执行该计划后立即运行该查询，NO_PLAN尽管数据库没有发生任何更改，但我会得到last_force_failure_reason_desc。我可以成功地对同一查询强制执行不同的计划
这个问题可以用下图来说明：
创建我们的测试数据库
USE [master]
CREATE DATABASE NO_PLAN
ALTER DATABASE [NO_PLAN] SET QUERY_STORE = ON
ALTER DATABASE [NO_PLAN] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, QUERY_CAPTURE_MODE = ALL)
GO
USE NO_PLAN
GO
IF EXISTS (SELECT 1 FROM sys.tables WHERE name = 'MyTableA') DROP TABLE MyTableA
IF EXISTS (SELECT 1 FROM sys.tables WHERE name = 'MyTableB') DROP TABLE MyTableB
/* create our tables */
CREATE TABLE [dbo].[MyTableA](
[Column1] VARCHAR(50) NULL ,
[Column2] VARCHAR(255) NULL ,
[Column3] INT NULL , …我目前正在查询sys.dm_db_log_info()DMV 以从数据库检索 VLF，以确定何时可以收缩、重组和减少 TLOG 文件中的碎片量（10 MB VLF）。
原因是，如果事务位于 TLOG 文件末尾并导致活动 VLF，则无法收缩 TLOG 文件。类似的情况，如果活动事务驻留在 TLOG 文件的中间，那么您就无法缩小到超过该 VLF。
我目前有这个语句来检索MAX(vlf_begin_offset)记录、MIN(vlf_begin_offset)记录和任何具有 active 的记录vlf_active = 1：
SELECT ddli.vlf_begin_offset,
ddli.vlf_sequence_number,
ddli.vlf_active,
ddli.vlf_status,
ddli.vlf_first_lsn
FROM sys.dm_db_log_info(DB_ID()) AS ddli
WHERE ddli.vlf_begin_offset = (
SELECT MIN(ddli2.vlf_begin_offset)
FROM sys.dm_db_log_info(DB_ID()) AS ddli2
)
OR ddli.vlf_active = 1
OR ddli.vlf_begin_offset = (
SELECT MAX(ddli3.vlf_begin_offset)
FROM sys.dm_db_log_info(DB_ID()) AS ddli3
)
ORDER BY
ddli.vlf_begin_offset ASC
当所有记录都返回时，结果集如下所示：
+------------------+---------------------+------------+------------+------------------------+
| vlf_begin_offset | vlf_sequence_number | vlf_active | vlf_status …sql-server ×10
sql-server-2016 ×10
datetime ×1
dmv ×1
hibernate ×1
hints ×1
parallelism ×1
partitioning ×1
permissions ×1
plan-cache ×1
query ×1
query-store ×1
replication ×1
ssis ×1