Compartilhar via

Visão geral da integração do CLR

  • Artigo

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 PERMISSION_SET = SAFE pode ser capaz de acessar recursos externos do sistema, chamar código não gerenciado e adquirir privilégios de administrador de sistema. No SQL Server 2017 (14.x) e versões posteriores, a sp_configure opção 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 clr strict security opção pode ser desabilitada para compatibilidade com versões anteriores, mas não é recomendada.

Recomendamos que você assine todos os assemblies por um certificado ou chave assimétrica, com um logon correspondente que tenha recebido UNSAFE ASSEMBLY permissão no master banco de dados. 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.

Conteúdo relacionado