Проблемы и решения при использовании хранимых процедур CLR? - PullRequest
4 голосов
/ 29 марта 2012

Мы внедряем новое масштабируемое и ориентированное на производительность приложение ASP.Net в нашей организации, которое в настоящее время находится на этапе разработки.

Менеджеры решили использовать гибридный подход.Они решили широко использовать хранимые процедуры CLR, а T-SQL - только для простых манипуляций с данными.

Мне бы хотелось узнать от сообщества следующее:

  1. Может ли быть производительностьпроблемы на более позднем этапе с таким большим количеством хранимых процедур CLR?
  2. Если у вас возникли проблемы с производительностью, было ли исправление доступно от команды MS?

Примечание: я сделал Googleи обнаружил следующие наиболее вероятные проблемы, но не нашел решения для первых двух.

  1. Когда SQL Server загружает сборки, они кэшируются в памяти.Когда O / S сигнализирует о нехватке памяти для SQL Server, может быть запущен явный сборщик мусора, и сборки могут быть выгружены.Это может вызвать проблемы с производительностью, если это происходит часто.

  2. Код SQL CLR не может быть точно рассчитан оптимизатором запросов, поскольку он не смотрит на то, что код делает на самом деле - это может повлиять на выполнениеПланы.

  3. Код SQL CLR иногда может предотвратить параллелизм, поскольку они обычно являются однопоточными.Иногда это может повредить производительности.<< Хотя я нашел решение этой проблемы здесь <a href="/1048597/mnogopotochnyi-kod-v-hranimyh-protsessah-clr"> Многопоточный код в хранимых процессах CLR? >>

Сообщите мне о проблемах и исправлениях с помощью хранимых процедур CLR.

1 Ответ

2 голосов
/ 30 марта 2012

Я сделал сборки CLR для сервера SQL.Это был болезненный опыт.Есть много ограничений, которые вы можете использовать в подобных проектах CLR.Например, было бы невозможно использовать сторонние библиотеки и библиотеки с открытым исходным кодом.Некоторые библиотеки не могут быть просто развернуты на сервере SQL.У вас есть только ограниченные библиотеки, которые вы можете использовать.

Вторая проблема - это параметры развертывания и разрешений.Если у вас есть очень ограниченная политика DBA для базы данных, вы просто не сможете развернуть сборки CLR в базе данных.

Мой совет - записывать компоненты базы данных в виде библиотек для ASP.Net.Это очень просто и без ограничений, как сборка CLR для SQL-сервера.

В 2008 году я написал сериальные блоги на эту тему: Проекты SQL Server (1-4) .Вы можете использовать их для справки.

...