Como usar procedimentos armazenados estendidos

Este artigo descreve a criação adequada e a implementação do SQL Server procedimentos armazenados estendidos. Além disso, este artigo fornece detalhes e referências para executar uma implementação bem-sucedida do SQL Server procedimentos armazenados estendidos.

Procedimentos armazenados estendidos são uma maneira muito eficiente para estender a funcionalidade do SQL Server. É o seguinte trecho do SQL Server Books Online: Você deve tratar o procedimento armazenado estendido DLL como qualquer outro desenvolvimento DLL: é código compartilhado, e vários segmentos podem acessá-lo ao mesmo tempo. Como com qualquer projeto production-worthy, certifique-se usar design completo e concluir o teste.

Para escrever procedimentos armazenados estendidos bem-sucedidos, é necessário um conhecimento funcional de muitos tópicos. Para revisar esses tópicos, consulte os capítulos seguintes no Windows Advanced por Jeffrey Richter:

• O capítulo 3, "Processos"
• O capítulo 4, "Segmentos"
• Capítulo 10, "Segmento sincronização"
• Capítulo 12, "Bibliotecas de vínculo dinâmico"
• Capítulo 13, "Armazenamento local de thread"
• Capítulo 16, "manipulação de exceção estruturada"

Para obter mais informações sobre como escrever código com segurança melhorada quando você estiver usando procedimentos armazenados estendidos, consulte Writing Secure Code de Michael Howard e David LeBlanc. Para obter mais informações sobre este livro, visite o seguinte site:

Registro

A arquitetura do procedimento armazenado estendido não é complicada; ele é um Microsoft Visual C ou C++ DLL compatível está vinculado com o arquivo Opends60.lib que expõe a função exportada corretamente (ou funções). Você usa o procedimento sp_addextendedproc armazenados para registrar a DLL associada e o nome de função exportada. Consulte o xp , xp_dblib e exemplos de xp_odbc que são no Toolkit do programador do SQL Server para obter exemplos. Para acessar o Kit de ferramentas do programador do SQL Server, visite a página SQL Server no site da Microsoft: Procedimentos armazenados estendidos estão registrados no banco de dados mestre e o administrador do sistema (SA) mantém controle sobre seu uso e o registro.

Quando você registra sua DLL, verifique se que ele está no caminho do sistema atual e que ele segue o 8.3 convenção de nomeação de arquivos.

Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

O espaço de endereço

SQL Server usa LoadLibrary, GetModuleHandle e GetProcAddress para obter um ponteiro para a função exportada e, em seguida, passa a função de uma estrutura SRVPROC. Depois que a DLL recebe a estrutura SRVPROC, você pode executar operações padrão Open Data Services para obter parâmetros e retornar resultados para o chamador.

Como uma DLL, ele é carregado no espaço de endereço do processo de chamada. No caso do procedimento armazenado estendido, o processo é SQL Server. Se uma DLL está acessando incorretamente memória ou se ele não é thread-safe, você pode afetar adversamente o processo. Você deve executar testes completa para garantir que a DLL mantém a integridade do processo. Se você estiver preocupado em todos os que um procedimento armazenado estendido pode ser afetando negativamente SQL Server, você deve resolver esse problema imediatamente.

Por exemplo, você pode usar o Microsoft Visual C ou assistentes do Microsoft Visual C++ para criar um Assistente de suplemento DevStudio. Este assistente é um servidor COM em processo ou DLL. Se você não escrever seu assistente corretamente, ele pode afetar adversamente o processo.

Exemplo

Neste exemplo, você está copiando incorretamente dados ultrapassou o fim do buffer strName . A documentação para a rotina strncpy informa que ele copiará a segunda seqüência de caracteres para o parâmetro strName e, em seguida, zero preencher o restante do buffer. Portanto, o exemplo está escrevendo 35 bytes, mesmo quando a segunda seqüência de caracteres é 3 bytes de comprimento. A rotina de funções strncpy provavelmente não irá causar uma violação de acesso porque você ainda no espaço de endereço de processo. No entanto, a operação pode ter facilmente corrompidas uma estrutura de memória interna, o que causaria o comportamento do processo inesperado. No caso de processo do SQL Server, esse tipo de erro pode corromper uma crítica estrutura interna do SQL Server e, como tal, pode mostrar si por meio de conexões ignorados ou outro comportamento inesperado do SQL Server. Além disso, o servidor pode parar de responder.

SQL Server tenta proteger o espaço de endereço. Invocação de um procedimento armazenado estendido é encapsulada em um try / exceto bloco, e vários pontos no código executam verificação de correção de tempo de execução mínimo. É importante lembrar-se de que a proteção é fornecida por um try / exceto bloco e não por um bloco try/catch. Portanto, o código não executará pilha desenrolar para objetos.

Vazamentos de memória

Qualquer projeto pode ter um problema onde memória alocada, um identificador ou um recurso semelhante não está sendo lançado corretamente. É fundamental para qualquer conjunto de teste DLL que o conjunto torna-se de que a DLL está lançando corretamente todos os recursos. Esses tipos de problemas são provavelmente Mostrar próprios como página maior uso do arquivo, desempenho alterado ou paginação maior.

Segurança do thread

Aplicativos como o Microsoft Internet Information Server (IIS) e Microsoft SQL Server são segmento de pool, de aplicativos multithread. Isso significa que você pode iniciar sua DLL de várias conexões ao mesmo tempo, especialmente em um computador que possui vários processadores. Isso também significa que uma única conexão pode chamar pontos de entrada diferente da DLL (XPROC, ISAPI) de um segmento de trabalho diferentes. Pool de segmentos pode limitar a utilidade das variáveis de armazenamento local de segmento (TLS).

Verifique se todos os caminhos de código são thread-safe e reentrante por vinculação com bibliotecas de tempo de execução de vários segmentos e por certificando-se que o fornecedor de todas as DLLs que você está usando são thread-safe.

Para obter mais informações sobre armazenamento local de thread e uma conta detalhada dos problemas de segurança do thread, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

Manipulação de exceção de estrutura

Você deve compreender também claramente o tratamento de erro de exceção estruturada. Cada ponto de entrada em uma DLL deve conta corretamente para erros de exceção. SQL Server tenta detectar erros de exceção, mas qualquer DLL precisa capturar e manipular erros de exceção corretamente. Especificamente, os threads que são iniciados em uma DLL devem instalar manipuladores de erro de exceção estruturada.

Cada thread em um processo tem uma pilha de exceção. No entanto, se a DLL iniciar um novo thread, ele começa sua exceção descoberta. Se o thread não uma tentativa de instalar / exceto ou um bloco try/catch imediatamente, o thread está apenas protegido pelo sistema operacional. Qualquer erro de exceção que encontra o thread é considerado unhanded e fatal para todo o processo. Lembre-se, a DLL está no espaço de processo do chamador e esse tipo de problema causará uma exceção fatal ao processo.

SQL Server e componentes associados do SQL Server são vinculados com as versões DLL de tempo de execução. Qualquer procedimento armazenado estendido que você desenvolva também deve ser vinculado com as versões DLL de tempo de execução.

Conexões de auto-retorno

Uma conexão de auto-retorno é feita quando o procedimento armazenado estendido faz uma conexão volta para o mesmo computador que está executando o SQL Server. Eles são descritos nos exemplos xp_dblib e xp_odbc , que estão incluídos no Toolkit do programador do SQL Server.

Você pode executar apenas conexões de auto-retorno em sessões acopladas. Um problema com uma conexão de auto-retorno é que ele é uma nova conexão e, portanto, está em um espaço de transação separado. Por exemplo, suponha que o procedimento armazenado estendido executa um cálculo matemático complexo na tabela de venda. A conexão de auto-retorno tentar concluir uma instrução SELECT na tabela de venda. No entanto, a conexão original executou uma instrução UPDATE para a tabela de vendas . A menos que você ter deixado o cuidado persistente para implementar um tempo limite da consulta, para executar processamento assíncrona de consulta e para verificar SRV_GOTATTENTION, esta conexão pode bloquear propriamente dito.

SQL Server 6.5 e versões posteriores do SQL Server oferece suporte a limite conexões. Consulte srv_getbindtoken e sp_bindsession para detalhes de implementação. Vinculando a conexão de auto-retorno a conexão original coloca as duas conexões no mesmo espaço de transação. Isso significa que o bloco originalmente ocorreu na tabela de vendas pode ser evitado.

Observação SQL Server só oferece suporte a conexões de auto-retorno em sessões acopladas.

Para obter mais informações sobre problemas de bloqueio, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:

Erros e mensagens

Outro aspecto de uma conexão de auto-retorno ou um procedimento armazenado estendido que faz uma conexão para outro computador que está executando o SQL Server ou para um gateway Open Data Services é o tratamento de erros e mensagens.

Se você estiver usando a biblioteca do banco de dados, você deve usar manipuladores de erro e a mensagem por processo. SQL Server controla os manipuladores de mensagem global e um procedimento armazenado estendido não deve substituí-los. Manipuladores de erro e a mensagem por processo também são garantidos como thread-safe. Consulte dbprocmsghandle e dbprocerrhandle para detalhes completos.

Dica Instalá-las no LOGINREC antes de chamar dbopen .

Para obter mais informações sobre a limitação do uso de biblioteca de banco de dados em um ambiente estendido, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:

Com o API Open Data Services chamar srv_message_handler , você pode colocar texto no log de erro do SQL Server. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: Uma observação final sobre o manipulador de erro de biblioteca de banco de dados: você pode retornar o valor INT_EXIT da função de retorno de chamada instalado. No entanto, conforme documentado, ele faz com que o aplicativo EXIT. Isso significa que são instruindo o processo para EXIT. Portanto, ele não deve ser chamado de uma DLL por causa dos efeitos para aplicativos como IIS ou SQL Server.

Transact-SQL KILL

Outro aspecto da conexão de auto-retorno ou execução do procedimento armazenado estendido em geral é o uso da instrução Transact-SQL KILL. Como a instrução KILL é Transact-SQL com base, o conjunto de API Open Data Services atual não tem conhecimento do status Transact-SQL KILL. Um procedimento armazenado estendido deve procurar SRV_GOTATTENTION para que ele pode manipular as solicitações do cliente para cancelar a operação. No entanto, a SA no momento não é possível emitir uma instrução Transact-SQL KILL para interromper a execução de um procedimento armazenado estendido. Isso torna mais importante que você use corretamente conexões acoplados e boas práticas de codificação. Um design alterar solicitação (DCR) tem sido arquivadas com desenvolvimento do SQL Server para estender a funcionalidade da instrução Transact-SQL KILL para procedimentos armazenados estendidos.

Configurações globais

Nunca afeta o estado global de um processo de uma DLL. Por exemplo, o SQL Server especificamente chama chamada Win32 API SetErrorMode para definir o comportamento desejado. Um procedimento armazenado estendido nunca deve chamar SetErrorMode ou outras chamadas de processo global porque isso é global para o espaço de processo. Há várias outras chamadas que afetam um processo; Verifique se que a DLL não usa essas chamadas globalmente.

Além disso, determinados serviços de dados abrir (ODS) chamadas projetadas exclusivamente para usar em um aplicativo com base em ODS e não deve ser usado em um procedimento armazenado estendido. Incluem chamadas como srv_init , srv_config , srv_handle e srv_errhandle . Essas funções de chamada substitui os valores que instala o SQL Server e pode levar a condições de falha imprevisíveis.

Srv_Senddone

Por padrão, o SQL Server chama automaticamente srv_senddone procedimento armazenado com o sinalizador SRV_DONE_FINAL no retorno da invocação de um procedimento armazenado estendido estendido. O procedimento armazenado estendido deve não chamada srv_senddone com o sinalizador SRV_DONE_FINAL; em vez disso, ele deve usar o sinalizador SRV_DONE_MORE.

Término de seqüência de caracteres

Quando você está lidando com seqüências de caracteres que são retornadas da API Open Data Services, você deve sempre certificar que o encerramento ocorre. Uma seqüência que é retornada de srv_paramdata estendido procedimento armazenado não é garantido para ser NULL finalizado. Você deve usar srv_paramlen procedimento armazenado estendido para manipular as cadeias de caracteres corretamente. Outras funções de Open Data Services podem ser similares; testá-los completamente.

Richter, Jeffrey. avançadas do Windows . Redmond, WA: Microsoft Press, 1997

Howard, Michael e David LeBlanc. Escrevendo código seguro, Second Edition . Redmond, WA: Microsoft Press, 2002.