Потоки в CLR в SQL Server 2008

Question

У меня есть CLR процесс, который выполняется под SQL Server2008.Он создает кеш из нескольких таблиц данных для хранения в статическом классе для последующего использования другими вызовами.

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

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

Любые идеи очень полезны для подсказок.

Answer 1

Вы можете использовать потоки, но они должны вести себя. В противном случае вы потеряете преимущества их использования.

С Среда хоста CLR

Как SQL Server и CLR работают вместе

В этом разделе обсуждается, как SQL Server интегрирует потоки, модели планирования, синхронизации и управления памятью в SQL Сервер и CLR. В частности, в этом разделе рассматриваются интеграция в свете масштабируемости, надежности и целей безопасности. SQL Server по существу выступает в качестве операционной системы для CLR, когда он размещен внутри SQL Server. CLR вызывает низкоуровневые процедуры реализованный SQL Server для потоков, планирования, синхронизации, и управление памятью. Это те же самые примитивы, что и остальные движок SQL Server использует. Этот подход обеспечивает несколько преимущества масштабируемости, надежности и безопасности.

Масштабируемость: общие потоки, планирование и синхронизация

CLR вызывает API-интерфейсы SQL Server для создания потоков, как для работающего пользователя код и для собственного внутреннего использования. Для синхронизации между несколько потоков, CLR вызывает объекты синхронизации SQL Server. Это позволяет планировщику SQL Server планировать другие задачи, когда поток ожидает объекта синхронизации. Например, когда CLR инициирует сборку мусора, все его потоки ждут мусора Коллекция до конца. Потому что потоки CLR и синхронизация объекты, которые они ждут, известны планировщику SQL Server, SQL Сервер может планировать потоки, которые выполняют другие задачи базы данных, не с участием ЦПР. Это также позволяет SQL Server обнаруживать взаимные блокировки которые включают блокировки, взятые объектами синхронизации CLR, и используют традиционные методы устранения тупиков.

Управляемый код преимущественно выполняется в SQL Server. Планировщик SQL Server имеет возможность обнаруживать и останавливать потоки, которые не уступили значительное количество времени. Возможность подключать потоки CLR к SQL Серверные потоки подразумевают, что планировщик SQL Server может идентифицировать «убегают» потоки в CLR и управляют их приоритетом. Такой сбежавший потоки приостанавливаются и возвращаются в очередь. Темы, которые неоднократно идентифицированные как бегущие потоки не могут работать для заданный промежуток времени, чтобы другие работники могли работать.

Answer 2

Статические данные, передаваемые между вызовами - не очень хороший план для вызовов CLR: Документация по SQL Server

Ограничения модели программирования

Модель программирования для управляемого кода в SQL Server включает в себя написание функций, процедур и типов, которые как правило, не требуют использования состояния, хранящегося в нескольких вызовы или разделение состояния между несколькими сеансами пользователя. Далее, как описано ранее, наличие общего состояния может вызвать критические исключения, которые влияют на масштабируемость и надежность заявление .

Учитывая эти соображения, мы не рекомендуем использовать статические переменные и статические данные членов классов, используемых в SQL Server. Для БЕЗОПАСНЫХ и В сборках EXTERNAL_ACCESS SQL Server проверяет метаданные сборка на время СОЗДАТЬ АССАМБЛЕЮ и не удается создать такой сборки, если он находит использование статических членов данных и переменных.