Mark Sowul's questions

假设您已经为本地 Windows 组创建了一个登录名，例如machine_name\group_name

您使用相同的计算机名称 ( ) 重建服务器（新物理机）machine_name，并将旧驱动器（包括 SQL 服务器）连接到该服务器。该组也已重新创建。

但这是新安装的操作系统。因此，新安装的操作系统machine_name\group_name将具有新的 SID，并且实际上无法运行。

我们如何检测登录的 SID 不再有效，以便我们知道需要重新创建登录？

SELECT SUSER_SID(machine_name\group_name)仍返回旧 SID（存储在 中sys.server_principals）。 [sys].[sp_validatelogins]也没有报告任何内容。

SUSER_SID乍一看似乎如此sys.server_principals，所以我们不知道如何检测这一点。

我正在考虑在我工作的系统中应用延迟持久性，并希望确保我有正确的心理模型以避免数据丢失。我的理解是它基本上意味着在andCOMMIT之间变成一种“薛定谔的猫” ，对吧？换句话说，某些已提交的事务实际上可能最终会回滚（“提交是谎言”）。COMMITROLLBACK

因此，我们实际上不应该期望在以下情况下看到任何数据丢失：

1. 一个服务代理激活过程，它RECEIVE发送消息，在事务中处理它们，并且COMMITs。如果“提交是谎言”并且事务实际上没有提交，那么它将是一个回滚，并且服务代理将自动重新运行它。
2. 将文件批量导入临时表的定期 ETL 类型作业（这部分将完全持久）。之后，在事务中，它处理暂存数据并将暂存数据标记为已处理。如果“提交是谎言”并且事务实际上并没有提交，那么它将是一个回滚，并且暂存的数据不会被标记为已处理，所以我们下次再做一次。

在这些情况下，我们不会期望实际的数据丢失，因为事务会自动重新运行。在这种情况下，它不会比任何其他可能中断事务的风险更大（例如，死锁或中断进程的计划外关闭）。

相比之下，类似以下的场景不适合延迟持久性，并且可能会丢失数据：

1. 对于目录中的每个文件，外部进程（例如 SSIS）开始一个事务，从文件中批量导入数据，并提交事务。提交事务后，它会删除文件。现在，如果“提交是谎言”并且事务实际上没有提交，我们将永远丢失文件数据，因为我们删除了文件但导入被回滚。

因此，总而言之，延迟持久性只有在某些外部方依赖COMMIT. 例如，在线结账进入销售，并合理地假设数据已经提交，销售完成等，并通知用户。但是，如果某些处理已经可以自动容忍并从中断/回滚中恢复，则应该不会增加风险。

听起来对吗？