Como utilizar procedimentos armazenados estendidos

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

Procedimentos armazenados estendidos são uma forma muito eficaz para expandir a funcionalidade do SQL Server. É o seguinte excerto de SQL Server Books Online: Tem de tratar o procedimento armazenado expandido DLL como qualquer outro desenvolvimento DLL: é código partilhado e vários threads podem aceder ao mesmo tempo. Se tal como com qualquer projecto production-worthy esqueça utilizar estrutura completa e concluir o teste.

Para escrever procedimentos armazenados estendidos com êxito, terá conhecimento prático de muitos tópicos. Para rever estes tópicos, consulte os capítulos seguintes no Windows Advanced por Jeffrey Richter:

• Capítulo 3, "Processos"
• Capítulo 4, "Threads"
• Capítulo 10, "Thread sincronização"
• Capítulo 12, "Dynamic-Link Libraries"
• Capítulo 13, "Thread memória local"
• Capítulo 16, "Estruturado o processamento de excepções"

Para mais informações sobre como escrever código com segurança melhorada quando estiver a utilizar procedimentos armazenados estendidos, consulte Anotações Secure código Michael Howard e David LeBlanc. Para obter mais informações sobre este livro, visite o seguinte Web site da Microsoft:

Registo

A arquitectura do procedimento armazenado expandido não é complicada; é um Microsoft Visual C ou C++ DLL compatível que está associado o ficheiro Opends60.lib que expõe função exportados correctamente (ou funções). Utilizar o procedimento armazenado sp_addextendedproc para registar o nome de função exportada e a DLL associada. Consulte o xp , xp_dblib e exemplos de xp_odbc incluídos na Toolkit para programadores de SQL Server para obter exemplos. Para aceder Toolkit para programadores de SQL Server, visite a página do SQL Server no seguinte Web site da Microsoft: Procedimentos armazenados estendidos são registados na base de dados principal e o administrador do sistema (SA, Security ASSOCIATION) mantém controlar a respectiva utilização e o registo.

Quando registar a DLL, certifique-se se está no caminho do sistema actual e que segue a 8.3 convenção de nomenclatura de ficheiro.

Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

O espaço de endereços

SQL Server utiliza LoadLibrary GetModuleHandle e GetProcAddress para obter um apontador para função exportada e, em seguida, passar a função de uma estrutura SRVPROC. Depois da DLL recebe a estrutura SRVPROC, pode efectuar operações de abrir Serviços de dados padrão para obter parâmetros de e para devolver resultados para o autor da chamada.

Como uma DLL, é carregado no espaço de endereço do processo de chamada. No caso do procedimento armazenado expandido, o processo é do SQL Server. Se uma DLL incorrecta aceder a memória ou se não se trata de thread de segurança, pode afectar negativamente o processo. Tem de executar teste exaustivo para garantir que a DLL mantém a integridade do processo. Se estiver preocupado em todos os de que um procedimento armazenado expandido pode ser afectar negativamente do SQL Server, terá de resolver este problema imediatamente.

Por exemplo, pode utilizar o Microsoft Visual C ou assistentes do Microsoft Visual C++ para criar um assistente DevStudio Add-in. Este assistente é um servidor COM em processo ou DLL. Se não gravar correctamente o assistente, pode afectar negativamente o processo.

Exemplo

Neste exemplo, está a copiar dados depois do fim da memória intermédia cadNome incorrectamente. A documentação para a rotina strncpy indica que copiará a segunda cadeia para o parâmetro cadNome e, em seguida, zero preencha o resto da memória intermédia. Por conseguinte, o exemplo que está a escrever bytes 35, mesmo quando a segunda cadeia é 3 bytes de comprimento. A rotina strncpy provavelmente não causará um erro de violação de acesso porque está ainda no espaço de endereço de processo. No entanto, poderá ter danificado facilmente a operação de uma estrutura de memória interna, que deverá ter causado o comportamento inesperado do processo. No caso de processo do SQL Server, este tipo de erro pode corromper a uma estrutura de SQL Server interna crítica e, como tal, pode mostrar próprio através de ligações interrompidas ou outro comportamento inesperado do SQL Server. Além disso, o servidor poderá deixar de responder.

SQL Server tentará proteger o espaço de endereços. Invocação de um procedimento armazenado expandido é moldada numa tentativa / excepto bloco e muitos pontos no código efectuam verificação de correcção runtime mínimo. É importante lembrar que a protecção é fornecida por um tente / excepto bloco e não por um bloco try/catch. Por conseguinte, o código não efectuará pilha unwinding para objectos.

Fugas de memória

Qualquer projecto pode ter um problema onde memória atribuída, uma alça ou um recurso semelhante não é a ser libertado correctamente. É extrema para qualquer conjunto de teste DLL que o conjunto torna-se de que a DLL está a libertar todos os recursos correctamente. Estes tipos de problemas é provável que Mostrar próprios como utilização de ficheiro de página maiores, desempenho alterado ou de paginação maior.

Segurança de threads

As aplicações como o Microsoft Internet Information Server (IIS) e Microsoft SQL Server são thread de agrupamento de aplicações multithread. Isto significa que pode iniciar a DLL de várias ligações ao mesmo tempo, especialmente num computador com múltiplos processadores. Isto também significa que uma única ligação pode chamar pontos de entrada diferente da DLL (XPROC, ISAPI) a partir de um thread de trabalho diferente. Agrupamento de threads pode limitar a utilidade das variáveis de thread local armazenamento (TLS).

Certifique-se que todos os caminhos de código estão thread de segurança e re-entrant por ligação com bibliotecas de tempo de execução multithread e certifique-se que todos os fornecedores dll que está a utilizar são segurança do thread.

Para obter mais informações sobre o armazenamento local do thread e uma conta detalhada dos problemas de segurança do thread, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Estrutura de processamento de excepções

Tem de compreender também claramente tratamento de erros excepção estruturado. Cada ponto de entrada de uma DLL correctamente deve ter erros de excepção. SQL Server tenta detectar erros de excepção mas tem de qualquer DLL para capturar e processar erros de excepção correctamente. Especificamente, os threads que são iniciados de uma DLL tem de instalar processadores de erro de excepção estruturado.

Cada thread num processo tem uma pilha de excepção. No entanto, se a DLL for iniciado um novo thread, começa a excepção naked. Se o thread não instalar um tente ou excepto ou um bloco try/catch imediatamente, o thread está apenas protegido pelo sistema operativo. Qualquer erro de excepção que o thread encontra é considerado unhanded e fatal todo o processo. Lembre-se a DLL está no espaço de processo do autor da chamada e este tipo de problema fará com que uma excepção fatal ao processo.

SQL Server e componentes associados do SQL Server estão ligados com as versões da DLL de tempo de execução. Qualquer procedimento armazenado expandido que tenha desenvolvido também tem de estar ligado com as versões da DLL de tempo de execução.

Ligações de loopback

Uma ligação de loopback é efectuada quando o procedimento armazenado expandido estabelece uma ligação para o mesmo computador que esteja a executar o SQL Server. Estas são descritas as amostras xp_dblib e xp_odbc , estão incluídas o SQL Server Programmer Toolkit.

Só é possível efectuar ligações de loopback em sessões dependentes. Um problema com uma ligação de loopback é que este é uma nova ligação, num espaço de transacção separado. Por exemplo, suponha que o procedimento armazenado expandido efectua um cálculo matemático complexo a tabela vendas. A ligação de loopback tenta concluir uma instrução SELECT da tabela ' Vendas '. No entanto, a ligação original tinha efectuado uma instrução UPDATE para a tabela de vendas . A menos que tenha obtido diligente cuidado para implementar um tempo limite de consulta, para executar consulta assíncrona processamento e verificar SRV_GOTATTENTION, esta ligação pode bloquear automaticamente.

SQL Server 6.5 e versões posteriores do SQL Server suportam ligações dependentes. Consulte srv_getbindtoken e sp_bindsession para detalhes de implementação. Enlace da ligação loopback da ligação original coloca ambas as ligações no mesmo espaço de transacção. Isto significa que o bloco originalmente ocorreu na tabela vendas podem ser evitados.

Nota SQL Server suporta apenas ligações de loopback em sessões dependentes.

Para obter mais informações sobre problemas de bloqueio, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft:

Erros e mensagens

Outro aspecto de uma ligação de loopback ou um procedimento armazenado expandido que estabelece uma ligação a outro computador que esteja a executar o SQL Server ou para um gateway de abrir Serviços de dados é o processamento de erros e mensagens.

Se estiver a utilizar biblioteca de base de dados, tem de utilizar por processo mensagem de erro e processadores. SQL Server controla os processadores de mensagem global e um procedimento armazenado expandido não tem substituí-los. Processadores de mensagens de erro e por processo são também garantidamente segurança do thread. Consulte dbprocmsghandle e dbprocerrhandle para detalhes completos.

sugestão Instalá-las no LOGINREC antes de chamar dbopen .

Para obter mais informações sobre as limitações da utilização de biblioteca de base de dados num ambiente expandida, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Com a API de serviços de dados abrir chamar srv_message_handler , pode colocar o texto no registo de erros do SQL Server. Para obter mais informações, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Uma nota final sobre o processador de erro de biblioteca de base de dados: É possível devolver o valor INT_EXIT da função de chamada de retorno instalado. No entanto, como documentado, provoca a aplicação EXIT. Isto significa que são instruir o processo EXIT. Por este motivo, esta tem não ser chamada a partir de uma DLL devido os efeitos para aplicações tais como o IIS ou SQL Server.

O Transact-SQL KILL

Outro aspecto da ligação de loopback de execução do procedimento armazenado expandido geralmente é a utilização da instrução Transact-SQL KILL. Uma vez que a instrução de KILL é Transact-SQL com base, o conjunto de API de serviços de dados abrir actual não tem conhecimento do estado KILL Transact-SQL. Um procedimento armazenado expandido tem de procurar SRV_GOTATTENTION modo pode processar pedidos do cliente para cancelar a operação. No entanto, a SA actualmente não é possível emitir uma instrução Transact-SQL KILL para interromper a execução de um procedimento armazenado expandido. Isto torna mais importante que utilize correctamente ligações dependentes e boas práticas de codificação correctas. Uma estrutura alterar pedido (DCR) foi arquivado com o desenvolvimento do SQL Server para expandir a funcionalidade da instrução Transact-SQL KILL para procedimentos armazenados estendidos.

Definições globais

Nunca afecta o estado global de um processo de uma DLL. Por exemplo, SQL Server chama especificamente a chamada de API do Win32 SetErrorMode para definir o comportamento pretendido. Um procedimento armazenado expandido nunca deve chamar SetErrorMode ou outras chamadas global do processo porque se trata de global para o espaço de processo. Existem várias outras chamadas que afectam um processo global; Certifique-se de que a DLL não utiliza estas chamadas.

Além disso, determinadas abrir dados dos serviços (ODS) chamadas concebidas unicamente para utilizar numa aplicação baseada no ODS e não deve ser utilizado um procedimento armazenado expandido. Estas incluem as chamadas tais como srv_init srv_config , srv_handle e srv_errhandle . Chamar estas funções substitui os valores que instala o SQL Server e pode provocar a falha imprevisíveis condições.

Srv_Senddone

Por predefinição, o SQL Server chama automaticamente srv_senddone expandido o procedimento armazenado com o sinalizador SRV_DONE_FINAL na devolução de invocação de um procedimento armazenado expandido. O procedimento armazenado expandido tem não chamada srv_senddone com o sinalizador SRV_DONE_FINAL; em vez disso, este tem de utilizar o sinalizador SRV_DONE_MORE.

Fim de cadeia

Quando está a lidar com cadeias que são devolvidas abrir API de serviços de dados, tem de sempre certificar-se que a terminação ocorre. Uma cadeia que é devolvida de srv_paramdata expandido procedimento armazenado não é garantido que ser NULL terminou. Tem de utilizar srv_paramlen expandido o procedimento armazenado para manipular correctamente as cadeias. Outras funções de abrir Serviços de dados podem ser semelhantes; testá-las cuidadosamente.

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

Howard e David LeBlanc e Michael. Programar códigos seguros, Segunda Edição . Redmond, WA: Microsoft Press, 2002.