sql-server - SQL Server 2008 : How crash-safe is a CLR Stored Procedure that loads unmanaged libraries

Question

我们在 SQL Server 2000 中有一个调用外部 exe 的常规(即未扩展)存储过程。该 exe 依次加载来自 SDK 的 .dll 并从中调用一些过程(即 Init、DoStuff、Shutdown)。

我们拥有这个外部 exe 的唯一原因是因为我们不想创建一个调用 .dll 的扩展存储过程。我们相信，如果 dll 崩溃(虽然不太可能发生，但仍然如此)，那么 SQL Server 进程也会崩溃，这不是我们想要的。对于外部 exe，只有该 exe 会崩溃。

现在，我们正在升级到 SQL Server 2008，并考虑创建一个调用该事物的 CLR 存储过程，从而摆脱该 exe。当然，这个 SP 会被标记为 UNSAFE。因此，问题是，与扩展 SP 方法相比，这样做是否安全(更安全、足够安全等)？

我在 BOL 上找到的唯一相关内容是:

Specifying UNSAFE allows the code in the assembly to perform illegal operations against the SQL Server process space, and hence can potentially compromise the robustness and scalability of SQL Server

，但我不确定它是否回答了我的问题，因为我不是追求“稳健性和可扩展性”，而是追求稳定性并保持事物的正常运行。

PS:我们希望摆脱这个 exe，因为它会在管理 SP 权限时带来不便(你知道，如果你调用包含 xp_cmdshell 的 SP，这些东西就会突然适用于你)。

Answer 1

由于此代码最初与扩展存储过程一起使用，因此听起来像是非托管代码。非托管代码中的错误很容易使您的进程崩溃。

CLR 集成比扩展存储过程更加健壮，但代码仍然在进程内运行，因此错误可能会导致 SQL Server 崩溃或损坏。 (作为比较，理论上，SAFE CLR 例程不会损坏 SQL Server，尽管它可能会导致降低服务器可用性的问题，而无需完全关闭 SQL Server。)

基本上，在这种情况下不使 SQL Server 崩溃的唯一方法是:

1. 避免使用会崩溃的功能。
2. 修复有问题的代码。
3. 在单独的进程中运行代码(启动可执行文件、调用 Windows 服务、调用 Web 服务等)。您可以编写托管 .NET DLL 来执行此交互。最有可能的是，您仍然需要以不安全的方式加载它，但是，如果编写正确，实际上它可能非常安全。