Integração CLR – Visão geral

Aplica-se a: Instância Gerenciada de SQL do Azure do SQL Server

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. Consulte o SDK do .NET Framework para obter mais informações.

Com o CLR hospedado no Microsoft SQL Server (a chamada 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 no código gerenciado. Como o código gerenciado é compilado em código nativo antes da execução, você pode obter aumentos significativos de desempenho em alguns cenários.

O código gerenciado usa a CAS (segurança de acesso do código) para impedir que os assemblies executem determinadas operações. O SQL Server usa CAS para ajudar a proteger o código gerenciado e evitar o comprometimento do sistema operacional ou servidor de banco de dados.

Vantagens da integração CLR

O Transact-SQL foi projetado especificamente 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 Microsoft Visual Basic .NET e o Microsoft Visual C# oferecem recursos orientados a objeto, como encapsulamento, herança e polimorfismo. Agora, o código relacionado pode ser facilmente organizado em classes e namespaces. Ao trabalhar com grandes quantidades de código de servidor, isso permite organizar e manter seu código de forma mais fácil.

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 que se encontra na Biblioteca do .NET Framework, você tem acesso a milhares de classes e rotinas pré-criadas. Elas podem ser acessadas facilmente de qualquer procedimento armazenado, gatilho ou função definida pelo usuário. A BCL (Base Class Library) inclui classes que fornecem funcionalidade para manipulação de cadeias de caracteres, operações matemáticas avançadas, acesso a arquivos, criptografia e outros.

Observação

Várias dessas classes estão disponíveis para uso a partir do código CLR no SQL Server, mas aquelas que não são apropriadas para uso 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 assegurar que nenhuma memória que não tenha sido gravada anteriormente seja lida. O CLR também pode ajudar 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 integração CLR.

Aviso

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. A partir do SQL Server 2017 (14.x), uma opção sp_configure chamada clr strict security é introduzida, a fim de aumentar a segurança de 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 isso não é recomendado. A Microsoft recomenda que todos os assemblies sejam assinados por um certificado ou uma chave assimétrica com um logon correspondente que recebeu a permissão UNSAFE ASSEMBLY no banco de dados mestre. Para obter mais informações, consulte Segurança estrita do CLR.

Escolhendo entre o Transact-SQL e o código gerenciado

Ao escrever procedimentos armazenados, gatilhos e funções definidas pelo usuário, uma decisão que você deve tomar é usar o Transact-SQL tradicional ou uma linguagem .NET Framework, como Visual Basic .NET ou Visual C#. Use o Transact-SQL quando o código executará 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.

Escolhendo 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 que utilizam intensamente o processador no servidor de banco de dados. Atualmente, a maioria dos computadores cliente tem uma capacidade grande, e talvez você queira aproveitar esse poder de processamento colocando a maior quantidade de código possível no cliente. O código gerenciado pode ser executado em um computador cliente, enquanto o Transact-SQL não.

Escolhendo entre procedimentos armazenados estendidos e o 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 integração CLR.

Confira também

Instalando o .NET Framework
Arquitetura da integração CLR
Acesso aos dados dos objetos de banco de dados CLR
Introdução à integração CLR