LowlyDBA - John M's questions

我试图让登录通过内置的 SSISDB 存储过程而不是通过 SQL 代理来启动 SSIS 包。

登录将通过 Ubuntu 机器上的 Airflow DAG 进行连接，因此我们使用 FreeTDS / pyodbc 允许它作为 Windows 登录进行身份验证，这工作正常。

但是，启动包时会发生以下情况：

1. 使用[SSISDB].[catalog].[start_execution] @execution_id. 尝试同步和异步运行。
2. 生成一个执行 ID，以及[SSISDB].[catalog].[executions]一个状态为 5（“待定”）的条目
3. 约 1 分钟后，执行“完成”并且执行 ID 从所有 SSISDB 表中擦除，并且不会显示在任何内置报告中。

即使添加 exec 参数来创建转储文件，在包执行期间也不会创建任何内容。

额外问题：在大约 1 分钟的时间范围内，从 SQL 代理启动的其他通常可以正常工作的包通常会失败并显示以下错误消息：

由于执行超时，操作失败。

笔记：

• SQL Server 安装在 Windows 上，并且是 SQL Server 2016 Ent。
• 从 Windows 框使用我的 Windows 身份验证登录时，此过程可以正常工作。
• DAG 使用的 Windows 帐户是代理服务帐户，因此具有所有必要的权限。
• 挂起执行的两个 SID 字段[SSISDB].[catalog].[executions]与 SQL 代理为同一服务帐户处理的其他工作执行的 SID 匹配。
• 我们正在使用 TDS 版本 7.2 和最新的 FreeTDS 版本。
• 使用自动提交 True/False 时没有区别
• 执行期间没有看到阻塞

我猜登录在用于启动外部 SSIS 进程时会被重新验证，但我希望可能有一些方法可以使这项工作仍然有效。

由于增加了复杂性和安全隐患，通过 CLR 调用是不受欢迎的选择。

我目前也在测试通过 dtexec 通过 xp_cmdshell 启动它们（看起来很有希望），但我不清楚它如何/为什么会起作用，而使用存储过程则不会。

我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的、不必要的文件。对于其中一个收缩，下面的命令会导致错误：

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

数据库 ID x 的文件 ID x 无法收缩，因为它正在被另一个进程收缩或为空

它不是空的，也不是收缩的。它正在一个数据库上运行，目前除了我自己以外没有人在使用它。自动收缩未启用且从未启用。但是，如果这很重要的话，在我接触这个数据库之前，会定期对该数据库进行手动收缩。

在SQLServerCentral上，十年前的一个线程建议向文件添加几 MB，因为这“重置了一个内部计数器或开关，告诉它现在不在收缩中。”

这有效 - 太棒了。但是谁能更详细地解释这在 SQL Server 内部是如何/为什么起作用的？

我有一段 SQL 似乎在环境 A 中运行得非常快，但完全相同的查询在环境 B 中运行得非常慢！

环境应该是相同的，所以我应该怎么做和/或我应该去哪里看看为什么查询不执行相同的？

如果我有一个包含一NVARCHAR(MAX)列的表并且我删除了它，回收它使用的空间的标准方法是：

1. 重建聚簇索引或
2. 跑DBCC CLEANTABLE

如果我不执行其中任何一个，该列仍然保留（通过可见sys.system_internals_partition_columns）在表的物理结构中，并且对数据库进行了完整备份和恢复，恢复的副本是否仍然在其物理结构中删除了列并且占用与删除列之前相同的空间？

对于我自己的用例，我正在查看 SQL Server 2012，但我认为它在所有相对现代的版本中都具有相同的功能。我知道这很容易测试，但我希望有人对此有更多的背景知识，因为我自己找不到太多。

参考：

• 删除具有可变长度列的 SQL Server 表时清理未使用的空间
• 底层的 SQL Server 表列

如果您没有听说，最近发现了一组相关的漏洞，这些漏洞几乎影响了过去十年销售的所有处理器。您可以在 InfoSec.SE 上找到有关崩溃/幽灵漏洞的更多技术细节。

作为 MongoDB DBA，我需要了解什么？

潜在的性能影响是什么？正确的修补指南是什么？云提供商针对此漏洞采取了哪些措施？

相关问题：

• 作为 MS SQL DBA，我需要了解有关崩溃/幽灵漏洞的哪些信息？

在 SQL 2014 版服务器（12.0.2430.0 - 还没有 SP1）中，数据库处于 2012 兼容模式（正在努力将其切换到 2014 ......）我有一些外键对象，它们not trusted在数据库中始终标记为. 我在没有NOCHECK选项的情况下删除并重新创建了它们，但在 5-10 分钟内它们再次变得不受信任，如果我生成一个CREATE脚本，它会显示为：

ALTER TABLE [dbo].[Points]  WITH NOCHECK 
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

正在使用的创建脚本是：

ALTER TABLE [dbo].[Points]
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

ALTER TABLE [dbo].[Points] CHECK CONSTRAINT [FK_BadgeId]
GO

没有复制，没有第三方工具，而且我正在监视数据库上的所有 DDL 语句，因此它不是另一个用户。

我能够很好地检查约束（WITH CHECK CHECK在每个约束上使用），但不久之后它们仍然变得不受信任。只有在早上运行的维护作业是 Ola 的，并且这种情况全天都在发生。

更新：

因此，在进行了几次跟踪以缩小可能性之后，似乎 aBULK INSERT可能导致FK变得不受信任。这个 msdn question指出这是密钥变得不受信任的有效途径，这是我第一次听说它。

所以我现在的问题是，是否有替代策略BULK INSERT可以保持外键is_trusted状态？它是在每小时运行几次的应用程序的上下文中执行的。我可以让开发人员批量处理他们的插入语句，但BULK INSERT如果我不需要，我不希望使用最后通牒。

我们有一个故障转移集群，名为MainSQL由MainSQL01和组成，MailSQL02它们是默认的命名实例，我们可以简单地连接到活动节点MainSQL。

如果我们要将 FC 重命名为MainSQL-NY那么连接将MainSQL-NY\MainSQL据我所知，因为实例无法重命名。如果我们然后将这个集群放入具有另一个集群（假设有它自己的两个节点）的 DR 站点中的可用性组中， 我们是否能够在创建 AG 虚拟网络名称时MainSQL-NJ\MainSQL重新使用该名称，从而允许连接 AG 和MainSQL它的底层活动集群节点仍然可以简单地使用MainSQL，因为它会再次成为MainSQL\MainSQL？

另一种方法是重建集群或强制我们所有的应用程序更新它们的连接字符串，但我很好奇这是否可行。

所以我最近开始在一家新公司工作，并且有很多 ArcGIS 用户似乎非常热衷于使用 PostGIS 实例来为我们的客户提供一些数据。虽然我对此没有意见，但我们是一家 95% 的 SQL Server 和 5% 的 Oracle 商店。我们当前的内部 GIS 在 SQL Server 上运行，我还没有听到任何抱怨。

我知道自 2012 年起 SQL Server 具有许多改进的空间/几何功能，但是 PostGIS 中是否有任何杀手级功能值得进入新平台？我试图研究它，但找不到任何真正深入的东西，或者这不完全是偏见。

我想为他们提供最好的工具来完成他们的工作，但也必须权衡这样一个事实，即我将从一开始就学习 Postgres/GIS，这本身就是一个完整的旅程。