Выполнение пользовательского кода в net framework отключено включить параметр конфигурации clr включен

Обновлено: 02.07.2024

Получите полный доступ к Programming SQL Server 2005 и более чем 60 000 другим играм с бесплатной 10-дневной пробной версией O'Reilly.

Есть также прямые онлайн-мероприятия, интерактивный контент, материалы для подготовки к сертификации и многое другое.

Глава 4. Введение в интеграцию Common Language Runtime (CLR)

Среда CLR предоставляет такие службы, как автоматическая сборка мусора, поддержка безопасности и проверка типов во время выполнения. Поскольку скомпилированный код выполняется средой CLR, а не непосредственно операционной системой, приложения с управляемым кодом не зависят от платформы и языка.

SQL Server 2005 размещает среду CLR в компоненте Database Engine. Это называется интеграция CLR. Интеграция со средой CLR позволяет создавать объекты базы данных, такие как функции, хранимые процедуры, триггеры, определяемые пользователем типы (UDT) и определяемые пользователем агрегатные функции (UDA) на языках программирования, поддерживаемых средой CLR. Управляемый код, работающий в среде CLR, размещенной на SQL Server, называется подпрограммой CLR.

До SQL Server 2005 основным способом расширения SQL Server было использование расширенных хранимых процедур, которые позволяли создавать внешние подпрограммы с использованием таких языков программирования, как C. Расширенные хранимые процедуры используются так же, как и обычные хранимые процедуры, однако могут иметь проблемы с производительностью. таких как утечка памяти, и может привести к тому, что сервер станет ненадежным. Интеграция со средой CLR позволяет расширить SQL Server за счет безопасности и надежности T-SQL и гибкости расширенных хранимых процедур.

Управляемый код использует безопасность доступа для кода (CAS) для управления операциями, которые могут выполнять сборки. CAS защищает код, работающий в SQL Server, и предотвращает неблагоприятное воздействие кода на операционную систему или сервер базы данных.

Как правило, T-SQL следует использовать, когда код подпрограмм в основном выполняет доступ к данным. Подпрограммы CLR лучше всего подходят для расчетов, интенсивно использующих ЦП, и для поддержки сложной логики, которую в противном случае было бы трудно реализовать с помощью T-SQL.

Цели проектирования интеграции с CLR

Microsoft определяет цели интеграции SQL Server 2005 CLR следующим образом:

Подпрограммы CLR не могут выполнять операции, нарушающие целостность процесса компонента Database Engine, а также не могут перезаписывать буферы памяти компонента Database Engine и внутренние структуры данных.

SQL Server и CLR имеют разные модели потоковой передачи, планирования и управления памятью. Цель разработки — обеспечить масштабируемость, когда пользовательский код вызывает API для потоковой передачи, примитивов синхронизации и памяти.

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

Код пользователя, работающий в базе данных, должен работать как минимум так же хорошо, как эквивалентные реализации с помощью собственных функций ядра СУБД или T-SQL.

Среда CLR предоставляет следующие услуги для достижения этих целей проектирования:

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

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

Безопасность доступа для кода

CAS применяет разрешения к коду для управления операциями, которые код может выполнять, и системными ресурсами, к которым он может получить доступ, на основе идентификатора кода.

Атрибуты защиты хоста (HPA)

SQL Server 2005 размещает среду CLR в компоненте Database Engine, фактически выступая в качестве операционной системы для среды CLR. Цели разработки интеграции SQL Server 2005 CLR для обеспечения надежности, масштабируемости и безопасности достигаются следующим образом:

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

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

При создании или изменении зарегистрированной сборки SQL Server можно указать один из трех наборов разрешений для сборки: SAFE , EXTERNAL-ACCESS или UNSAFE . SQL Server использует наборы разрешений для установки разрешений CAS при выполнении сборки.Три набора разрешений описаны в таблице 4-1.

Сборки SAFE могут получать доступ к данным из локальных баз данных SQL Server и могут выполнять вычисления и бизнес-логику, не задействуя ресурсы за пределами локальных баз данных.

Сборки SAFE не могут получить доступ к внешним системным ресурсам, таким как файлы, сети, переменные среды или реестр.

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

EXTERNAL-ACCESS позволяет сборкам получать доступ к определенным внешним системным ресурсам, таким как файлы, сети, переменные среды и реестр, в дополнение к доступу, предоставляемому набором разрешений SAFE.

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

Небезопасные сборки имеют неограниченный доступ к ресурсам как внутри, так и вне SQL Server. НЕБЕЗОПАСНАЯ сборка может вызывать неуправляемый код.

Только администратор базы данных может зарегистрировать НЕБЕЗОПАСНУЮ сборку.

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

Код с пометкой SAFE или EXTERNAL-ACCESS не может использовать статические элементы данных и переменные.

Включение интеграции с CLR

Чтобы включить интеграцию CLR, необходимы разрешения ALTER SETTINGS на уровне сервера.

Классы, поддерживающие специфичные для SQL Server 2005 функции

Классы, поддерживающие собственные типы данных SQL Server

Типы подпрограмм CLR

Открытый статический метод

Пользовательская функция, которая возвращает одно значение.

Открытый статический метод

Пользовательская функция, которая возвращает таблицу в качестве результирующего набора.

Открытый статический метод

Процедура, которая возвращает наборы результатов и сообщения в виде таблиц клиенту, вызывает операторы DDL и DML и возвращает выходные параметры.

Пользовательская агрегатная функция

Класс или структура

Функция UDA, которая работает со значениями в наборе строк и возвращает скаляр.

Класс или структура

Сложные типы данных дополнены методами, расширяющими систему скалярных типов в SQL Server.

Триггер (DML и DDL)

Открытый статический метод

Тип хранимой процедуры, которая автоматически запускается при возникновении события DML или DDL.

Пример приветствия, мир

Выберите «Файл» → «Создать» → «Проект».

Выберите проект SQL Server в диалоговом окне «Новый проект», показанном на рис. 4-1, назовите его HelloWorld, укажите местоположение и нажмите «ОК».

Поскольку хранимая процедура не будет обращаться к каким-либо данным, нажмите кнопку "Отмена" в диалоговом окне "Добавить ссылку на базу данных", показанном на рис. 4-2.

В обозревателе решений щелкните правой кнопкой мыши проект HelloWorld и выберите в контекстном меню пункт Добавить → Хранимая процедура, как показано на рис. 4-3.

В диалоговом окне "Добавить новый элемент", показанном на рис. 4-4, выберите шаблон хранимой процедуры. Введите имя HelloWorldStoredProcedure.cs и нажмите «Добавить».

Добавьте следующую строку кода в метод HelloWorldStoredProcedure() в файле HelloWorldStoredProcedure.cs:

Полный код теперь должен выглядеть следующим образом:

Создайте решение, выбрав Build → Build Solution в главном меню Visual Studio 2005, нажав кнопку Build Solution на панели инструментов Build или щелкнув правой кнопкой мыши проект HelloWorld в обозревателе решений и выбрав Build из контекстного меню. Хранимая процедура компилируется в сборку с именем HelloWorld.dll в подкаталоге bin\Debug.

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

Щелкните правой кнопкой мыши базу данных ProgrammingSqlServer2005 в обозревателе объектов и выберите «Новый запрос» в контекстном меню, как показано на рис. 4-5.

Зарегистрируйте сборку HelloWorld.dll с именем сборки SQL Server HelloWorld, выполнив следующую инструкцию T-SQL:

Вы можете подтвердить, что сборка зарегистрирована, развернув узел Базы данных → ProgrammingSqlServer2005 → Программируемость → Сборки в древовидном представлении обозревателя объектов, как показано на рис. 4-6.

Создайте хранимую процедуру CLR с именем HelloWorldSP на основе статического метода HelloWorld StoredProcedure() в сборке HelloWorld.dll, зарегистрированной на шаге 2. Выполните следующий запрос:

Предложение EXTERNAL NAME состоит из трех частей, разделенных точками:

Имя зарегистрированной сборки SQL Server (из шага 2) — HelloWorld

Имя общедоступного статического метода, реализующего хранимую процедуру — HelloWorldStoredProcedure()

Вы можете подтвердить, что хранимая процедура была создана, развернув узел Базы данных → ProgrammingSqlServer2005 → Хранимая процедура в древовидном представлении обозревателя объектов, как показано на рис. 4-7.

Теперь вы можете использовать хранимую процедуру так же, как и любую другую хранимую процедуру.

Выполните хранимую процедуру HelloWorldSP со следующим оператором T-SQL:

Результаты следующие:

Компилятор командной строки

Каталог, в котором установлена ваша версия Windows — часто WINDOWS или WINNT

Чтобы использовать компилятор, добавьте каталог, содержащий компилятор, в системную переменную среды Path, определенную в списке Системные переменные, доступном через Панель управления → Система → Дополнительно → Переменные среды.

Поддержка DDL для интеграции CLR

Администратор (администратор CertPoint)
24.10.2021
Еще один взгляд на это сообщение. Интересно, что еще мы.

< td>Сб< /tr>< td style="text-align: center">14

Эта работа находится под лицензией Creative Commons Attribution-NonCommercial-NoDerivs 3.0.

Программирование — это управление поведением компьютера. Я считаю, что лучше всего изучать новые технологии, изучая, что они могут делать и как они это делают, прежде чем приступать к реализации проекта. Предоставление контекста для информации, которую нужно хорошо изучить, поможет вам принять более правильное решение относительно того, когда вам следует использовать эту функцию; знание того, как создать функцию для вычисления квадратного корня, не поможет вам, если вы не знаете, что гораздо эффективнее делать это в T-SQL.

Что такое SQLCLR
В этой первой части я попытаюсь развеять некоторые заблуждения, чтобы было легче сосредоточиться на том, что такое SQLCLR на самом деле.

Как ни странно, Microsoft официально не использует термин «SQLCLR» (официальное значение в документации по продукту SQL Server/MSDN, хотя вы найдете его в статьях TechNet и в нескольких местах в Visual Studio как «SQLCLR» и "SQL CLR").Однако, как и слово «производительный», оно используется настолько часто, что технический аспект, скорее всего, не имеет значения. Кроме того, это совершенно громоздкое слово ;-). Предпочтительной терминологией является «интеграция со средой CLR», когда она используется в общем смысле, и просто «CLR», когда речь идет о коде, объектах и т. д. Для наших целей я буду использовать либо «SQLCLR», либо «на основе CLR».

Расширение возможностей запросов за пределы встроенных функций T-SQL
Выполнение определенных операций быстрее, чем это можно сделать в T-SQL
Лучшее взаимодействие с внешними ресурсами, чем это можно сделать с помощью xp_cmdshell
SQLCLR позволяет создавать хранимые процедуры, функции, агрегаты, типы и триггеры для выполнения действий, которые либо невозможно, либо невозможно выполнить столь же эффективно в T-SQL. Примерами вещей, которые нельзя сделать в T-SQL, являются доступ к внешним ресурсам, многопоточность и олицетворение текущего пользователя при доступе к внешним ресурсам. Да, в T-SQL можно использовать хранимые процедуры автоматизации OLE (например, SP_OA*) для доступа к внешним ресурсам, но они не столь гибки и могут иметь другие проблемы с памятью и/или безопасностью. Связанные серверы могут олицетворять себя при подключении к другим экземплярам, но они не поддерживают общую функциональность сети и файловой системы. Примерами вещей, которые не могут быть выполнены столь же эффективно, являются вычисления и манипулирование текстом/строкой. При правильном использовании SQLCLR может оказать большую помощь в решении некоторых других непреодолимых проблем.

Так же, как xp_cmdshell и некоторые другие функции, функция "Интеграция с CLR", позволяющая запускать пользовательский код SQLCLR, по умолчанию отключена. Когда эта функция отключена, вы можете создавать сборки и объекты-оболочки T-SQL, которые ссылаются на методы внутри сборок, но эти объекты-оболочки T-SQL нельзя будет использовать. Чтобы включить "интеграцию с CLR", выполните следующие два оператора:

EXEC sp_configure 'CLR Enabled', 1;
RECONFIGURE;
Что может сделать SQLCLR
Чтобы лучше передать полезность SQLCLR, возможности можно разделить на три категории. Первая категория — это функции, которые просто невозможно реализовать ни в пользовательских функциях T-SQL, ни в хранимых процедурах T-SQL. Вторая категория — это функции, которые, по крайней мере, в некоторой степени могут быть реализованы в UDF T-SQL, но только через OPENQUERY/OPENROWSET или, в двух случаях, также через представление. Третья категория — производительность.

Выполняется только в SQLCLR

Следующие элементы можно обрабатывать только с помощью SQLCLR.

Доступ к внешним ресурсам/замена xp_cmdshell: вот лишь несколько аспектов того, почему SQLCLR почти всегда является лучшим выбором для большинства задач, для которых вы бы использовали xp_cmdshell:

Передача данных упрощается: в зависимости от того, какие параметры нужно отправить внешней команде, использование xp_cmdshell может быть довольно громоздким. xp_cmdshell принимает единственный параметр, который представляет собой команду, которую вы хотите запустить, плюс все ее параметры. Следовательно, вам нужно отформатировать одну строку командной строки, и вы столкнетесь с той же проблемой, что и при создании динамического SQL, такими проблемами, как экранирование встроенных кавычек и преобразование нестроковых переменных. В документации по xp_cmdshell указано:
command_string — это varchar(8000) или nvarchar(4000) без значений по умолчанию. command_string не может содержать более одного набора двойных кавычек. Одна пара кавычек обязательна, если в путях к файлам или именах программ, указанных в command_string, присутствуют пробелы. Если у вас возникли проблемы со встроенными пробелами, рассмотрите возможность использования имен файлов FAT 8.3 в качестве обходного пути.
С помощью SQLCLR вы вызываете либо хранимую процедуру, либо определяемую пользователем функцию, обе из которых имеют отдельные параметры, которые могут относиться к любому типу данных.
Возврат нескольких столбцов результирующего набора проще: результаты xp_cmdshell представляют собой один столбец и должны быть проанализированы / разделены, если содержат несколько столбцов данных, что является дополнительным уровнем сложности и подвержено ошибкам. Другим вариантом является сохранение результатов внешнего процесса в файл с разделителями, который можно импортировать с помощью BULK INSERT или OPENROWSET(BULK.), что менее подвержено ошибкам, чем разбиение строки, но также может быть сложным в дополнение к возможной необходимости дополнительных действий. предоставленные разрешения (например, OPENROWSET(BULK. ) требует разрешения «АДМИНИСТРИРОВАНИЕ МАССОВЫХ ОПЕРАЦИЙ»).
Никаких внешних зависимостей: нет гарантии, что любая программа или сценарий, который вы запускаете через xp_cmdshell, существует, поскольку SQL Server ничего не знает об этом. Это означает, что вы можете установить ProrgamA.exe на одном сервере, и он отлично работает через xp_cmdshell, но затем вы запускаете ту же командную строку на другом сервере, и по какой-то причине ProgramA.exe там нет. Внешние программы и сценарии не резервируются, по крайней мере, как часть резервной копии SQL, поэтому их может не быть при восстановлении сбойного сервера на новую машину. С другой стороны, сборки являются частью резервной копии БД, как и объекты-оболочки.
Олицетворение: xp_cmdshell запускается в контексте безопасности либо учетной записи входа в систему службы/процесса SQL Server для любого пользователя с ролью сервера sysadmin, либо учетной записи-посредника xp_cmdshell для всех остальных (если она настроена). По умолчанию код SQLCLR выполняется в контексте безопасности учетной записи входа в систему службы/процесса SQL Server для всех. Однако вы можете закодировать свой объект SQLCLR для доступа к этим внешним ресурсам (т. е. к ОС, файловой системе и сети) с учетными данными безопасности входа, выполняющего объект SQLCLR (для входа в Windows, а не входа в SQL Server). Существуют ограничения на то, когда это можно сделать и что именно можно сделать с олицетворенными учетными данными, но это очень хороший вариант, тем более что он не ограничен одним контекстом безопасности, таким как прокси-аккаунт xp_cmdshell.
Многопоточность: код SQLCLR может использовать многопоточность для запуска нескольких процессов одновременно. Эта возможность доступна только в том случае, если для параметра Сборка установлено значение НЕБЕЗОПАСНО, что обычно не одобряется, но иногда действительно приятно иметь эту опцию. Если эта способность используется, это следует делать с большой осторожностью и проверкой.

Пользовательские типы. Вы можете создать свой собственный определяемый пользователем тип (UDT) для обработки сложных данных и включения методов и свойств, использующих сохраненные в них данные. Доступ к свойствам и методам UDT осуществляется так же, как к «.value()» и другим функциям для полей и переменных XML (например, @XMLvar.value() ). Например, вы можете создать тип адреса, который позволяет вводить улицу, город, штат/регион, почтовый индекс и страну. Затем у вас может быть метод проверки, который проверяет формат PostalCode для указанной страны и возвращает BIT, а также свойство, которое возвращает полное имя страны (при условии, что вы сохраняете только двухсимвольный код ISO). Наконец, UDT SQLCLR можно отправлять в качестве параметров в хранимые процедуры и функции SQLCLR.

Захват сообщений. Иногда сообщения отправляются с помощью команды PRINT или RAISERROR (с уровнем серьезности от 0 до 10), которые вы можете захотеть захватить. Если вы используете SSMS, эти сообщения отображаются на вкладке «Сообщения», но хранимая процедура T-SQL не может захватить сообщения, отправленные любой хранимой процедурой, которую она, в свою очередь, вызывает. С другой стороны, функции SQLCLR и хранимые процедуры могут перехватывать эти сообщения.

Участвовать в параллельных планах: пользовательские функции T-SQL нельзя использовать в параллельных планах, поэтому будет принудительно выбирать непараллельные планы. Но определяемые пользователем функции SQLCLR (если они не осуществляют никакого доступа к данным и имеют пометку IsDeterministic = true, а также могут потребоваться в сборке с пометкой SAFE) могут участвовать в параллельных планах, что может помочь повысить производительность.

Перехват наборов результатов: у вас есть не только доступ к метаданным набора результатов (что-то, что вы можете сделать в T-SQL, начиная с SQL Server 2012, через sys.dm_exec_describe_first_result_set, тогда как это можно сделать в SQLCLR, начиная с SQL Server 2005). , но вы также можете получить доступ к отдельным наборам результатов. Это означает, что если у вас есть хранимая процедура, которая возвращает несколько наборов результатов, и вам нужен только один из них, вы можете легко сделать это в SQLCLR. На самом деле, вы даже можете манипулировать результирующим набором, если хотите. Вы можете добавлять или удалять поля, переименовывать поля или даже объединять 2 или более наборов результатов в один набор результатов.

Совместное использование/кеширование памяти между сеансами: в T-SQL вы можете использовать CONTEXT_INFO (или SESSION_CONTEXT, начиная с SQL Server 2016), чтобы сохранить значение в памяти, доступное для всего, что выполняется в этом сеансе, и на которое не влияют операторы GO. или транзакции и т. д. Но значение ограничено как по размеру (это VARBINARY (128), хотя SESSION_CONTEXT не так ограничен), так и по области действия (доступно только для текущего сеанса). Существует не так много сценариев, в которых хотелось бы обмениваться данными между сеансами (обычно для кэширования данных между соединениями), но если это необходимо, единственный способ сделать это в T-SQL — через глобальную временную таблицу или реальную таблицу. . Но с SQLCLR вы можете сделать это в памяти, используя статическую переменную класса. Если это обновляемая переменная, сборка должна быть помечена как НЕБЕЗОПАСНАЯ. Или, если переменная представляет собой коллекцию, вы можете сделать ее «только для чтения», сохраняя при этом возможность добавлять и удалять элементы из нее, и в этом случае сборку можно пометить как БЕЗОПАСНУЮ (при условии, что никакие другие функции не требуют EXTERNAL_ACCESS или UNSAFE). Как и в случае с многопоточностью, это следует делать с большой осторожностью и тестировать, поскольку вся память, используемая для кэширования, отнимается от обработки запросов.

Установка постоянных переменных среды: если вы устанавливаете переменную среды с помощью xp_cmdshell через «SET VariableName=Value», то эта переменная доступна только для этого конкретного вызова xp_cmdshell и исчезнет после завершения этой функции. Но в SQLCLR вы можете вызвать Environment.SetEnvironmentVariable, и эта переменная станет частью процесса службы SQL Server.Это означает, что доступ к значению можно получить в T-SQL (используя либо xp_cmdshell 'echo %variable_name%' ИЛИ SQLCLR с Environment.GetEnvironmentVariable), любой сценарий, вызываемый из xp_cmdshell, шаги задания CmdExec заданий агента SQL (по крайней мере, иногда) и т. д. .

Ссылка на псевдотаблицы INSERTED и DELETED в динамическом SQL: в триггерах T-SQL доступ к таблицам INSERTED и DELETED возможен только в самом верхнем/нединамическом контексте. Однако в триггерах SQLCLR весь T-SQL является динамическим, и вы, безусловно, имеете доступ к таблицам INSERTED и DELETED.

Используйте WAITFOR DELAY в функции: хотя вы, конечно, не стали бы делать это в рабочей среде, для тестирования и исследований иногда может быть очень удобно держать открытой транзакцию с одним оператором или даже наблюдать за тем, что происходит, когда каждая строка обрабатывается добавление скалярной функции SQLCLR, которая вызывает Thread.Sleep(), в список SELECT.

Проще в SQLCLR

SQLCLR позволяет выполнять следующие действия при использовании обычного/внешнего подключения к БД (т. е. не текущего сеанса), но для этого требуется предоставить сборке как минимум разрешения EXTERNAL_ACCESS. С другой стороны, некоторые из следующих элементов могут быть выполнены, хотя и в ограниченной степени, через контекстное соединение (текущий сеанс/в процессе), которое работает, даже если для разрешений сборки установлено значение SAFE. Обратите внимание, что первые два пункта — использование NEWID и RAND — можно выполнить в T-SQL, создав представление для простого SELECT функции, а затем SELECT из представления в T-SQL UDF. Следовательно, если вам нужно сгенерировать эти типы значений, но не нужны какие-либо другие функции, специфичные для среды CLR, придерживайтесь обходного пути представления.

Сравнение производительности объектов T-SQL и SQLCLR — более сложная тема. Начнем с того, что вы действительно можете сравнивать только те функции, которые одинаковы между ними. Затем вы должны рассмотреть тип выполняемой логики, эффективно ли выполняется логика в обоих типах кода, если сравнивать функции, выполняется ли она с помощью инструкции SET или многострочного запроса и т. д.

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

Объекты SQLCLR (хранимые процедуры, определяемые пользователем функции и т. д.) управляются теми же разрешениями, что и обычные объекты. Вам нужно ПРЕДОСТАВЛЯТЬ разрешения, и вы также можете ОТВЕРГАТЬ разрешения. Если вы не хотите, чтобы кто-то запускал определенную хранимую процедуру, не предоставляйте ему доступ к ней. Тот факт, что это SQLCLR, значения не имеет.

Код SQLCLR, даже если он написан для доступа к файловой системе, сети или выполнения чего-то вроде многопоточности, не может выполнять ни одну из этих задач без предварительного предоставления сборке соответствующего разрешения. По умолчанию сборки создаются с разрешением SAFE. Если вы хотите, чтобы код имел доступ к файловой системе и/или сети, но не порождал другие процессы или потоки, то для сборки можно установить значение EXTERNAL_ACCESS. Если требуется, чтобы сборка могла делать все, что захочет, включая совместное использование памяти через SPID или многопоточность, то ей необходимо предоставить набор разрешений UNSAFE.

Полезно знать
Функция «Интеграция с CLR» — не единственное использование .NET / CLR в SQL Server. Это просто относится к возможности добавления пользовательского кода SQLCLR. Таким образом, даже если для параметра конфигурации «CLR Enabled» установлено значение 0 (т. е. выключено/отключено), CLR, скорее всего, все еще используется другими функциями SQL Server. В следующем списке перечислены как минимум некоторые, но, возможно, не все функции, которые используют CLR в SQL Server и на которые не влияет включение или отключение функции «Интеграция со средой CLR»:

Типы данных:
География
Геометрия
Идентификатор иерархии
Функции:
В ЧАСОВОМ ПОЯСЕ (начиная с SQL Server 2016)
СЖАТИЕ (начиная с SQL Server 2016)
DECOMPRESS (начиная с SQL Server 2016)
FORMAT (начиная с SQL Server 2012)
PARSE (начиная с SQL Server 2012)
TRY_PARSE (начиная с SQL Server 2012)
DMV и DMF:
sys.time_zone_info (начиная с SQL Server 2016)
Возможности:
Change Data Capture (CDC)
Dynamic Management Framework
Master Службы данных (MDS)
Репликация
Управление на основе политик
Каталог служб SSIS (т. е. SSISDB)
Обратите внимание на это, согласно странице MSDN для параметра конфигурации сервера «clr enable» :
Выполнение общеязыковой среды выполнения (CLR) не поддерживается в упрощенном пуле. Отключите один из двух вариантов: «CLR включен» или «облегченный пул». Функции, которые зависят от CLR и которые не работают должным образом в режиме волокна, включают тип данных иерархии, функцию FORMAT, репликацию и управление на основе политик.
Поддержка платформы
SQL Server в Windows: полная поддержка SQLCLR, начиная с SQL Server 2005.Сюда входит SQL Server, работающий на виртуальной машине Azure или AWS.

SQL Server в Linux: SAFE-сборки, загружаемые из двоичного литерала/шестнадцатеричной строки байтов (например, 0x4D9A. ), поддерживаются, начиная с SQL Server 2017 (это первая версия, доступная на этой платформе).

База данных Azure SQL: SAFE-сборки, загруженные из двоичной литеральной/шестнадцатеричной байтовой строки (например, 0x4D9A. ), поддерживались, начиная с выпуска версии 12 в конце 2014 года. Однако, к сожалению, вся поддержка SQLCLR была удалена, а не внезапно 15 апреля 2016 г. (клиенты получили уведомление всего за 7 дней до удаления этой функции).

Управляемые экземпляры базы данных SQL Azure: поддерживаются в основном (?), но не могут загружать сборки из файлов DLL, должны загружаться из строки двоичных литералов/шестнадцатеричных байтов (например, 0x4D9A. ).

SQL Server RDS на AWS: сборки SAFE, загруженные из двоичной литеральной/шестнадцатеричной байтовой строки (например, 0x4D9A. ), поддерживаются вплоть до SQL Server 2016 включительно. Начиная с SQL Server 2017, SQLCLR больше не поддерживается из-за глупость «строгой безопасности CLR» (разрешения системного администратора, не разрешенные в RDS, теперь требуются для загрузки любой сборки).

Эта фиксация не принадлежит ни к одной из веток в этом репозитории и может принадлежать ответвлению за пределами репозитория.

Открыть с рабочего стола
Просмотреть в необработанном виде
Копировать исходное содержимое Копировать необработанное содержимое

Копировать необработанное содержимое

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

параметр конфигурации сервера с поддержкой clr

Используйте параметр с поддержкой clr, чтобы указать, могут ли пользовательские сборки запускаться с помощью [!INCLUDEssNoVersion]. Параметр с включенным clr предоставляет следующие значения:

< /tbody>

Значение	Описание
0	Выполнение сборки запрещено для [!INCLUDEssNoVersion].
1	Выполнение сборки разрешено для [!INCLUDEssNoVersion].

Только для WOW64: перезапустите серверы WOW64, чтобы применить эти изменения. Для других типов серверов перезагрузка не требуется.

Когда вы запускаете команду RECONFIGURE и значение параметра запуска включенной clr изменяется с 1 на 0, все домены приложений, содержащие пользовательские сборки, немедленно выгружаются.

[!IMPORTANT] Выполнение общеязыковой среды выполнения (CLR) не поддерживается в облегченном пуле. Отключите один из двух параметров: «clr включен» или «облегченный пул». Функции, которые полагаются на CLR и которые не работают должным образом в режиме волокна, включают тип данных иерархии, функцию FORMAT, репликацию и управление на основе политик. Дополнительные сведения см. в разделе Вариант конфигурации облегченного сервера пула

[!NOTE] Хотя параметр конфигурации с поддержкой clr включен в [!INCLUDEssSDSfull], разработка пользовательских функций CLR не поддерживается в [!INCLUDEssSDSfull].

В следующем примере сначала отображается текущая настройка параметра включенной clr, а затем включается параметр, задав для параметра значение 1. Чтобы отключить параметр, установите значение 0.

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

Важно

Для IIS: после изменения файла newrelic.config или app.config выполните IISRESET из административной командной строки. Корректировки уровня журнала не требуют сброса.

Методы настройки и уровни приоритета

Подробнее о методах настройки, показанных на диаграмме, и их уровнях приоритета:

Подробности и приоритет

web.config или app.config или appsettings.json

Параметры конфигурации, установленные в этих файлах, имеют наивысший приоритет.

Однако, если агент отключен в локальном или глобальном файле newrelic.config , настройки NewRelic.AgentEnabled в этих файлах будут игнорироваться.

Третий по приоритету. Доступно ограниченное количество параметров конфигурации на стороне сервера; остальные настройки будут получены из других источников конфигурации.

Четвертый по старшинству. Вы можете создать локальные файлы newrelic.config для приложения, чтобы настроить отдельные приложения в системе с несколькими приложениями. Эти локальные файлы конфигурации имеют приоритет над настройками в глобальном файле newrelic.config.

Агент ищет локальные файлы конфигурации приложения в следующих каталогах в следующем порядке:

Каталог, указанный в вашем файле web.config или app.config со свойством NewRelic.ConfigFile

Корневой каталог веб-приложения (с app.config или web.config )

Каталог, содержащий исполняемый файл вашего приложения

По умолчанию (глобальный) newrelic.config

Обязательные переменные среды

Внимание

Рекомендация по безопасности. Следует учитывать, какие пользователи могут устанавливать системные переменные среды. Вы также должны защитить учетные записи, под которыми выполняются ваши приложения, чтобы переменные среды пользователя не переопределяли системные переменные среды

Читайте также:

«	март 2022 г.
Вс	Пн	Вт	Ср	Чт	Пт
1	2	3	4	5
6	7	8	9	10	11	12
13	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31
28/03/2022