小编Mar*_*man的帖子

我执行了以下操作：

USE [MyDatabase];
GO
CREATE LOGIN [MyDomain\MyAccount] FROM WINDOWS WITH DEFAULT_DATABASE=[MyDatabase];
CREATE USER [MyDomain\MyAccount] FOR LOGIN [MyDomain\MyAccount];
GRANT EXECUTE   ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT SELECT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT INSERT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];

（我没有授予任何角色，因为我不希望此登录名能够访问此数据库中的任何其他架构。）

我以 MyDomain\MyAccount 的身份运行 SSMS（以不同的用户身份运行）。然后我尝试连接到这个实例。但是，我得到：

无法打开用户默认数据库。登录失败。用户
“MyDomain\MyAccount”登录失败。（Microsoft SQL Server，错误：4064）

如果我在连接属性中将默认数据库设置为 MyDatabase，我会得到相同的结果。

我运行了 Profiler 跟踪并看到错误 18456 状态 38：

用户“MyDomain\MyAccount”登录失败。原因：无法打开明确指定的数据库“MyDatabase”。[客户：MyIpAddress]

接下来是错误 18456 状态 40：

用户“MyDomain\MyAccount”登录失败。原因：无法打开登录属性中指定的数据库“MyDatabase”。[客户：MyIpAddress]

MyDatabase 在线，我可以使用其他登录名轻松连接到它。我需要向 MyDomain\MyAccount 授予哪些额外权限？还有什么我想念的吗？

我需要一个计算列来解决隐式转换问题。我有一个声明为 VARCHAR 的列，它应该只存储整数，但偶尔会被带有字符串的第三方应用程序错误填充，因此该列需要保持原样。

该表通常连接到一个将该值存储为 INT 的表。我定义了一个 PERSISTED 计算列，用于将该 VARCHAR 转换为 INT：

[iOrderNumber] AS (CONVERT([int],
case
   when [ordernumber] like '#%' then (-99) when isnumeric([ordernumber])=(0) then (-99) 
   when CONVERT([bigint],[ordernumber],(0))>(2147483647) then (-99)
   else [ordernumber]
end,(0))) PERSISTED NOT NULL

使用计算列上的适当索引，现在可以连接到 INT 列的查询的性能显着提高。但是，即使在更新表而不是读取表时发生转换，执行计划仍会显示隐式转换警告。

我尝试在计算列定义中使用 UDF 来消除警告（我找到了一篇建议这样做的博客文章），但随后我的查询的执行时间更长，并且使用了更多的 CPU，尽管逻辑读取保持不变。但是 UDF 确实消除了警告。

除了错误之外，还有其他理由考虑警告吗？是否有理由将优化器对使用 UDF 定义的持久计算列的处理视为错误？

更重要的是，有没有办法摆脱警告，而不会招致 UDF 解决方案的性能损失？

我考虑使用触发器和包含数据的 VARCHAR 和 INT 版本的转换表，而不是使用计算列，但这似乎是很多不必要的开销。

我有一个 8 核（576 个最大工作线程）的 SQL Server 2008 R2 SP3 标准版 64 位实例，32 GB RAM（MaxMem = 28000）。它是 SharePoint 安装的数据存储，具有 218 个数据库。

它收到了数十条“SQL Server 失败，错误代码为 0xc0000000，无法生成线程来处理新的登录或连接。” 每天错误，但没有其他错误。我发现 MAXDOP = 0，这对 SharePoint 不利。我逐渐（数周后）将 MAXDOP 降低到 1。当我这样做时，这些错误的频率在大多数日子里都降到了零。但我还是会偶尔看到他们。

sys.dm_os_wait_stats 关于 THREADPOOL 等待是这样说的：

waiting_tasks_count wait_time_ms    max_wait_time_ms    signal_wait_time_ms
26149               474516          4428                9

服务器上次重启时间为 2018 年 3 月 25 日下午 5:55，当前服务器时间为 2018 年 4 月 20 日晚上 10:07。除了在保存 tempdb 文件的驱动器上使用连接和顺序提示以及慢速存储写入之外，sp_Blitz 没有发现任何有趣的东西。

这是在私有云中的虚拟机上。增加 CPU 的数量会非常昂贵，虽然它被大量使用，但 CPU 使用率似乎不是问题。在这种情况下，增加最大工作线程数是否是一个合理的尝试，我应该不理会它并忍受偶尔的 17189 错误，还是有其他选择？

我将 Visual Studio 2012 Professional 与 SQL Server Data Tools 与 SQL Server 2012 标准版数据库实例一起使用。
我无法在我的开发机器或托管 SQL Server 实例的服务器上找到 master.dacpac 文件。

我怎样才能获得这个文件，这样我就可以摆脱如下警告：

SQL71502: Procedure: <ProcedureName> has an unresolved reference to object [sys].[objects]  

在 SQL Server 2012 SP1 实例中，我在表的 PK 列上有一个筛选索引，如下所示：

CREATE INDEX [RF_IXF_Orders_OrderNumber] ON [dbo].[Orders]
(
    [OrderNumber] ASC
)
WHERE [OrderSource]='MO'
AND [Cancelled]=(0)
AND [NumItems]>(0)
AND [OrderDate]>'2014-05-15';

索引的 Row Count (dm_db_partition_stats.row_count) 为 8416，Rows Changed (sysindexes.rowmodctr) 为 16803 (193.6%)，Auto Update Statistics 为 True。有 8400 个 user_scans 和 50,088 个 user_updates。上次 user_scan 是今天，但统计数据已经大约一周没有更新了。

为什么统计数据不会自动更新？

我使用 SQL Server 2008R2 标准版实例（最近迁移到 Azure VM）的数百个数据库的 SharePoint 数据存储定期遇到 THREADPOOL 等待问题。它一次在许多（可能是所有）这些数据库中运行一个名为 proc_DefragmentIndices 的存储过程。

存储过程无条件地重建数据库中的每个索引。当然，它们是头部阻塞器（因为它是标准版，每个 ALTER INDEX 命令都以 ONLINE=OFF 运行）。因为一次运行的程序太多（每个都在不同的数据库中），并且它们并行运行（这会占用更多的工作人员），所以一切都堆积如山。只是为了增加噪音，Azure Backup 正在备份许多数据库，而这一切都在进行，消耗了更多的工作人员。活动监视器显示 106 个等待任务，以及许多 ALTER INDEX 命令的同一会话 ID 的多个实例（这就是我说它们并行的原因）。

我觉得令人困惑的是，即使实例中的 MAXDOP 设置为 1，这些 ALTER INDEX 语句也会并行运行，这是对 SharePoint 数据库的建议，并且由存储过程执行的 ALTER INDEX 语句没有使用 MAXDOP 选项来覆盖它.

Q1：当 MAXDOP 设置为 1 时，INDEX 重建如何并行？

Q2：活动监视器显示 ALTER INDEX 命令，但 sp_WhoIsActive 没有。有谁知道为什么？

我继承了一个带有 80 GB 日志的 10 GB 数据库 [根据 DBCC SQLPERF(logspace)，仅使用了 3%]。假设日志的极端增长是由于我被聘用之前很久的问题似乎是安全的。

主节点有一个日志传送备份作业，每 15 分钟运行一次。主节点具有每 15 分钟运行一次的复制和还原作业。

当我尝试缩小日志时，我收到“无法缩小日志文件 2 (DatabaseName_log)，因为位于文件末尾的逻辑日志文件正在使用中”。我已经间隔 15 分钟甚至几天重试了几次，但总是得到相同的结果。

DBCC LOGINFO 显示 784 个 VLF，只有前 245 个和最后一个 on，状态为 2。 p_WhoIsActive 显示最长的打开事务已运行不到 2 小时（由于第三方 Microsoft访问具有 ODBC 驱动程序问题的应用程序）。

如何成功缩小此日志（而不为用户造成中断）？

谢谢，马克

确定行或页或列存储压缩（或无）对于用于 OLTP（其中不支持sp_estimate_data_compression_ savings）的 Azure SQL 数据库（标准层或高级层）中的每个索引最有效的最有效方法是什么？

我意识到这样做是否有利于性能取决于每个索引的写入频率和数量。还应考虑哪些其他因素？

（我意识到是否对分区索引使用列存储是一个复杂的问题，我认为这超出了此请求的范围。）