SQL Server 2008: насколько безопасна хранимая процедура CLR, загружающая неуправляемые библиотеки

Поскольку этот код изначально использовался с расширенными хранимыми процедурами, похоже, что это неуправляемый код. Ошибки в неуправляемом коде могут легко привести к сбою вашего процесса.

Интеграция со средой CLR намного более надежна, чем расширенные хранимые процедуры, но код по-прежнему выполняется внутри процесса, поэтому ошибки могут вывести из строя или повредить SQL Server. (Для сравнения: теоретически процедура SAFE CLR не сможет повредить SQL Server, хотя даже она может вызвать проблемы, снижающие доступность вашего сервера без полного отключения SQL Server.)

По сути, единственные способы избежать сбоя SQL Server в этом сценарии:

1. Избегайте использования функциональности, которая дает сбой.
2. Исправьте ошибочный код.
3. Запустите код в отдельном процессе (запустите исполняемый файл, вызовите службу Windows, вызовите веб-службу и т. Д.). Вы можете написать управляемую .NET DLL для выполнения этого взаимодействия. Скорее всего, вам все равно нужно будет загрузить его НЕ БЕЗОПАСНО, но - если он написан правильно - на самом деле это может быть довольно безопасно.

В связи с этим возникает вопрос, безопасно ли (безопаснее, достаточно безопасно и т. Д.) Делать это таким образом по сравнению с подходом расширенного SP?

В общем да. Я имею в виду, что если вы выполняете оболочку для процесса ОС, то вы выполняете оболочку для процесса ОС. Я не понимаю, как использование API расширенных хранимых процедур для этого обязательно будет безопаснее, чем API SQLCLR, особенно когда сбой может произойти из-за процесса ОС, находящегося вне базы данных.

Конечно, я не уверен в XP API, поскольку не использовал его, но я знаю следующее:

• XP API устарел, и рекомендуется, чтобы все новые проекты, которые можно было реализовать с помощью любой из этих технологий, выполнялись в SQLCLR.
• SQLCLR допускает более детальные разрешения, чем два других, включая возможность олицетворения (если вход в систему, выполняющий объекты SQLCLR, является входом в Windows).
• SQLCLR API разделяется с точки зрения процесса и памяти как владельцем базы данных, так и владельцем сборки (т. Е. Пользователем, указанным в предложении AUTHORIZATION). Следовательно, у вас может возникнуть проблема со сборкой в ​​одной БД, не затрагивая объекты SQLCLR в других БД (или даже в той же БД, если есть сборки, принадлежащие другому пользователю, хотя на практике это, вероятно, редко когда-либо случается, поскольку большинство людей просто используйте значение по умолчанию dbo).

Я не уверен, отвечает ли он на мой вопрос, поскольку я не за «надежностью и масштабируемостью», а за стабильностью и поддержанием работоспособности.

Что ж, безусловно, есть вещи, которые вы можете делать в SQLCLR, когда для Assembly установлено значение UNSAFE:

• потенциально запись в реестр (в зависимости от доступа, предоставленного учетной записи входа в систему, выполняющей процесс SQL Server, или входа в систему, выполняющего функцию SQLCLR, если олицетворение включено, и это вход в систему Windows).
• потенциально писать в файловую систему
• потенциально взаимодействовать с процессами, запущенными в системе
• совместно использовать память с другими SPID SQL Server (то есть сеансами), выполняющими функции из той же сборки (что означает, что конкретная сборка в этой БД принадлежит этому пользователю). Это, вероятно, ускользает от людей больше всего, поскольку это неожиданно, когда вы привыкли к консольным приложениям и приложениям Windows, имеющим свои собственные индивидуальные пространства памяти, но здесь, поскольку это один домен приложений для каждой сборки на каждую БД на каждого владельца, все сеансы, выполняющие этот код, имеют общий доступ все static переменные. Большая часть кода написана с предположением, что AppDomain является частным, и поэтому хранение значений в статических переменных эффективно, поскольку оно кэширует значение, но в SQLCLR вы можете получить неожиданное поведение, если два процесса перезаписывают значения друг друга и читают другие. значение сеанса.
• потенциальные утечки памяти. Атрибуты защиты хоста пытаются помешать вам использовать встроенные функции .NET, которые могли бы это сделать, например, использование TimeZoneInfo для преобразования времени между идентификаторами TimeZoneID, но атрибуты защиты хоста не применяются к UNSAFE сборкам.
• Возможно, что поток, выполняющий метод SQLCLR, обрабатывается по-другому при выполнении кода UNSAFE / FullTrust (совместная многозадачность против вытесняющего). Я думал, что читал, что потоки UNSAFE управляются по-другому, но я не уверен, где это читал, и ищу источник.

Но все вышесказанное, если вы вызываете внешний EXE, у него есть собственный домен приложения.

Итак, что вы можете сделать, это либо:

1. продолжайте вызывать EXE с помощью оболочки SQLCLR для Process.Start(). Это дает вам как разделение процесса / памяти , так и возможность более легко управлять разрешениями для одной хранимой процедуры, которая будет вызывать только этот EXE-файл, и никто не может его изменить (по крайней мере, без изменения этого кода SQLCLR. и переустановка сборки).

2. установите экземпляр SQL Server Express на тот же компьютер, загрузите туда объекты SQLCLR и создайте связанные серверы в обоих направлениях (от текущего экземпляра SQL Server к новому экземпляру SQL Server Express и обратно), чтобы вы могли легко обмениваться данными между ними. Это позволит вам поместить выполнение SQLCLR в карантин и уберечь его от основного процесса SQL Server.

Конечно, все все сказано, насколько это действительно беспокоит? Это означает, насколько вероятно, что процесс полностью выйдет из строя и уничтожит все вместе с ним? Конечно, это не невозможно, но обычно сбой приводит к отключению только AppDomain, а не самого хоста CLR. Я думаю, что гораздо более вероятно, что код, который не дает сбоев, но написан плохо и потребляет слишком много памяти и / или процессора, будет проблемой, с которой люди столкнутся.