Я рассматриваю возможность доступа к некоторому коду CLR из UDF в Sql Server 2005.
Я слышал истории о том, что необработанные исключения, созданные в коде CLR, могут вывести из строя сервер.
Очевидно, моя функция будет содержать блок try-catch. Однако некоторые исключения (stackoverflow) могут пропустить уловку.
Есть ли у кого-нибудь набор руководящих принципов, которые могут полностью исключить (или минимизировать) риск того, что мой код CLR выйдет из строя сервер.
Необработанные исключения оказывают неблагоприятное влияние на SQL Server, но насколько они неблагоприятны, зависит от серьезности создаваемого исключения.
Вообще говоря, вы используете ограниченные области выполнения, чтобы указать область действия (процесс, домен приложения, поток и т. Д.), На которую часть вашего кода может повлиять в случае сбоя. SQL Server использует это, чтобы определить, следует ли просто прервать текущий запрос / запрос или пойти дальше в случае более серьезной ошибки.
В журнале MSDN есть хорошая статья, в которой рассказывается о CER, а также о том, как SQL Server их использует:
http://msdn.microsoft.com/en-us/magazine/cc163716.aspx#
Кроме того, вот список передовых методов, специально предназначенных для разработки кода CLR для SQL Server:
http://msdn.microsoft.com/en-us/library/ms228970.aspx#
Что делает код?
Я предлагаю вам полностью избежать риска, достигнув своей цели без использования CLR в первую очередь, вместо того, чтобы использовать технологию, которая, как вы знаете, вполне вероятно добавит взаимосвязи и сложности и будет полностью непереносимой. Но я не могу ничего порекомендовать, если не знаю, в чем проблема или действительно ли вам нужна среда CLR.
Неперехваченные исключения в коде CLR не приведут к остановке сервера. Код CLR выполняется в отдельном домене приложения и изолирован. Максимум, что может произойти (а это маловероятно), - это то, что исключение приведет к отключению домена приложения и выгрузке домена приложения. Это приведет к а) перезагрузке при следующем запросе или б) отключению до устранения проблемы или развертывания новой версии сборки.
Таким образом, самое большее, что эта сборка CLR будет отключена, и вызывающие сеансы будут получать сообщения об ошибках. Крайне маловероятно, что неправильный код CLR приведет к остановке всего экземпляра сервера sql; если это так, я бы сказал, что это ошибка Microsoft, а не ошибка функции CLR или сохраненной процедуры.
Весьма вероятно, что неперехваченное исключение .net будет преобразовано в сообщение об ошибке tsql. В лучшем случае соединение tsql будет прервано; скорее всего, это приведет к сообщению об ошибке.
Я настоятельно рекомендую ограничить возможность параллельного выполнения запросов, использующих функции CLR. Ваш опыт может отличаться, но я обнаружил, что это избавляет от некоторых ошибок моего механизма SQL.
http://msdn.microsoft.com/en-us/library/ms181714.aspx
WITH( MAXDOP 1)
