Visão geral da integração do CLR
Aplica-se a: 
SQL Server Instância Gerenciada de SQL do Azure
O CLR (Common Language Runtime) é o centro do Microsoft .NET Framework; ele fornece o ambiente de execução para todo o código do .NET Framework. O código executado no CLR é chamado de código gerenciado. O CLR fornece diversas funções e serviços necessários para a execução de programas, incluindo a compilação JIT (Just-In-Time), alocação e gerenciamento de memória, imposição de segurança de tipos, tratamento de exceções, gerenciamento de threads e segurança. Para obter mais informações, consulte Guia de desenvolvimento do .NET Framework.
Observação
Para obter mais informações sobre como usar o novo .NET com Extensões de Linguagem do SQL Server, consulte Como chamar o runtime do .NET em Extensões de Linguagem do SQL Server.
Com o CLR hospedado no SQL Server (chamado de integração CLR), você pode criar procedimentos armazenados, gatilhos, funções definidas pelo usuário, tipos definidos pelo usuário e agregações definidas pelo usuário em código gerenciado. Como o código gerenciado é compilado para código nativo antes da execução, você pode obter aumentos significativos de desempenho em alguns cenários.
Segurança de acesso do código
No SQL Server 2016 (13.x) e versões anteriores, a CAS (Segurança de Acesso ao Código) impedia que assemblies executassem determinadas operações.
O CLR usa o CAS (Segurança de Acesso do Código) no .NET Framework, para o qual não há mais suporte como um limite de segurança. Um assembly CLR criado com o PERMISSION_SET = SAFE pode conseguir acessar recursos externos do sistema, chamar um código não gerenciado e adquirir privilégios sysadmin. No SQL Server 2017 (14.x) e versões posteriores, a opção a opção de sp_configure, clr strict security aprimora a segurança dos assemblies CLR. A clr strict security está habilitada por padrão e trata assemblies SAFE e EXTERNAL_ACCESS como se eles fossem marcados como UNSAFE. A opção clr strict security pode ser desabilitada para compatibilidade com versões anteriores, mas não é recomendado.
Recomendamos que você assine todos os assemblies por um certificado ou uma chave assimétrica com um logon correspondente que tenha recebido a permissão UNSAFE ASSEMBLY no banco de dados master. Os administradores do SQL Server também podem adicionar assemblies a uma lista de assemblies, na qual o Mecanismo de Banco de Dados deve confiar. Para obter mais informações, consulte sys.sp_add_trusted_assembly.
Vantagens da integração CLR
O Transact-SQL foi projetado para acesso direto a dados e manipulação no banco de dados. Embora o Transact-SQL se destaque no acesso e gerenciamento de dados, ele não é uma linguagem de programação completa. Por exemplo, o Transact-SQL não dá suporte a matrizes, coleções, loops for-each, deslocamento de bits ou classes. Embora alguns desses constructos possam ser simulados no Transact-SQL, o código gerenciado tem suporte integrado para esses constructos. Dependendo do cenário, esses recursos podem representar um motivo convincente para implementar determinada funcionalidade de banco de dados no código gerenciado.
O Visual Basic e o C# oferecem recursos orientados a objetos, como encapsulamento, herança e polimorfismo. Agora, o código relacionado pode ser facilmente organizado em classes e namespaces. Quando você está trabalhando com grandes quantidades de código de servidor, esses recursos permitem que você organize e mantenha seu código com mais facilidade.
O código gerenciado é mais adequado do que o Transact-SQL para cálculos e lógica de execução complicada e apresenta amplo suporte para muitas tarefas complexas, incluindo manipulação de cadeia de caracteres e expressões regulares. Com a funcionalidade encontrada na biblioteca do .NET Framework, você tem acesso a milhares de classes e rotinas predefinidas. Essas classes podem ser facilmente acessadas de qualquer procedimento armazenado, gatilho ou função definida pelo usuário. A BCL (biblioteca de classes base) inclui classes que fornecem funcionalidade para manipulação de cadeia de caracteres, operações matemáticas avançadas, acesso a arquivos, criptografia e muito mais.
Observação
Embora muitas dessas classes estejam disponíveis para uso no código CLR no SQL Server, aquelas que não são apropriadas para uso no lado do servidor (por exemplo, classes de janelas) não estão disponíveis. Para obter mais informações, consulte Bibliotecas do .NET Framework com suporte.
Uma das vantagens do código gerenciado é a segurança de tipos ou a garantia de que o código acesse apenas os tipos de modos permitidos e bem definidos. Antes da execução do código gerenciado, o CLR verifica se o código é seguro. Por exemplo, o código é verificado para garantir que nenhuma memória seja lida que não tenha sido gravada anteriormente. O CLR também pode ajudar a garantir que o código não manipule a memória não gerenciada.
A integração CLR oferece a possibilidade de melhorar o desempenho. Para obter informações, consulte Desempenho da arquitetura de integração CLR.
Escolher entre Transact-SQL e código gerenciado
Ao escrever procedimentos armazenados, gatilhos e funções definidas pelo usuário, você deve decidir se deseja usar o Transact-SQL tradicional ou uma linguagem .NET Framework, como Visual Basic ou C#. Use o Transact-SQL quando o código executa principalmente o acesso a dados com pouca ou nenhuma lógica de procedimento. Use o código gerenciado para funções que utilizam intensamente a CPU e procedimentos que apresentam lógica complexa, ou quando desejar usar a BCL do .NET Framework.
Escolha entre a execução no servidor e a execução no cliente
Outro fator em sua decisão sobre usar o Transact-SQL ou o código gerenciado é onde você gostaria que seu código residisse, o computador servidor ou o computador cliente. O Transact-SQL e o código gerenciado podem ser executados no servidor. Assim, o código e os dados ficam próximos, o que possibilita o aproveitamento do poder de processamento do servidor. Por outro lado, talvez você queira evitar colocar tarefas intensivas do processador em seu servidor de banco de dados. A maioria dos computadores clientes hoje é poderosa e você pode querer aproveitar esse poder de processamento colocando o máximo de código possível no cliente. O código gerenciado pode ser executado em um computador cliente, enquanto o Transact-SQL não.
Escolher entre procedimentos armazenados estendidos e código gerenciado
Procedimentos armazenados estendidos podem ser criados para executar funcionalidades que não são possíveis com procedimentos armazenados Transact-SQL. No entanto, os procedimentos armazenados estendidos podem comprometer a integridade do processo do SQL Server, enquanto o código gerenciado verificado como de tipo seguro não pode. Além disso, o gerenciamento de memória, o agendamento de threads e fibras e os serviços de sincronização são mais profundamente integrados entre o código gerenciado do CLR e do SQL Server. Com a integração do CLR, você tem uma maneira mais segura do que os procedimentos armazenados estendidos de escrever os procedimentos armazenados necessários para executar tarefas que não são possíveis no Transact-SQL. Para obter mais informações sobre a integração CLR e procedimentos armazenados estendidos, consulte Desempenho da arquitetura de integração CLR.