Resumo

O Microsoft SQL Server 6,5 ou posterior fornece a funcionalidade para carregar e executar objetos COM (Component Object Model) personalizados por meio de um conjunto de procedimentos armazenados de automação OLE ou por meio de procedimentos armazenados estendidos. Por padrão, os objetos COM baseados em DLL são carregados como no servidor de processo, o que significa que os objetos COM não só são carregados dentro do espaço de endereço de memória do processo do SQL Server, mas também têm acesso completo a esse espaço de endereço de memória. Portanto, um objeto COM carregado no espaço de processo do SQL Server deve aderir às mesmas regras que qualquer arquivo DLL. Há um potencial que um objeto COM pode substituir a memória dentro do processo do SQL Server ou os recursos de perda, causando instabilidade. Se houver suspeita de que um objeto COM pode estar afetando a robustez do processo do SQL Server, talvez você queira usar as etapas neste artigo para instanciar o objeto COM fora do espaço de processo do SQL Server. A implementação da especificação DCOM (Distributed Component Object Model) de "transparência de localização" no sistema operacional fornece a capacidade de executar um objeto COM baseado em DLL fora do espaço de processo do SQL Server. O processo de execução de um objeto COM baseado em DLL fora do espaço de endereço do aplicativo principal é chamado de comunicação remota. O Remoting requer que outro executável seja um processo substituto no lugar do executável do SQL Server. O executável padrão usado pelo Gerenciador de controle de serviço DCOM (RPCSS. exe) chama-se Dllhost. exe. A estrutura de suporte DCOM usa o arquivo Dllhost. exe para carregar a DLL em seu espaço de processo e, em seguida, usa pares proxy/stub para empacotar a interface solicitada de forma transparente para o cliente, que, nesse caso, é o SQL Server. Esse executável pode aceitar várias solicitações de interface/método simultaneamente. Depois que o uso da interface estiver concluído, o Gerenciador de controle de serviço (SCM) DCOM gerencia a limpeza e o descarregamento do arquivo Dllhost. exe. Objetos COM não devem ser esperados para reter informações de estado entre as instanciações. Para que este artigo funcione corretamente, o sistema deve estar executando um sistema operacional habilitado para DCOM. Isso seria o Microsoft Windows NT 4,0 Service Pack 2 ou posterior, o Microsoft Windows 98 ou o Microsoft Windows 95 com o suplemento DCOM instalado. As etapas a seguir podem ser aplicadas a qualquer objeto COM baseado em DLL que está sendo criado no espaço de processo do SQL Server, seja instanciado por meio de sp_OACreate ou de um procedimento armazenado estendido.

Informações adicionais

As informações sobre os dois métodos básicos que você pode usar para instanciar o objeto COM para fora do processo são as seguintes.

O cliente COM solicita comunicação remota do objeto

Ao alterar a forma como você invoca o objeto COM, você pode solicitar que o objeto seja criado fora do espaço de endereço do SQL Server.

  • Se o objeto COM for carregado usando o procedimento sp_OACreate , por padrão ele será carregado em processo. No entanto, há um terceiro parâmetro opcional para esse procedimento que pode ser usado para indicar o contexto de onde criar o objeto. Se esse parâmetro não for especificado, a configuração padrão de cinco (5) será usada, o que significa executar o objeto dentro ou fora do processo. Você precisa alterar o parâmetro para quatro (4), que indica ao DCOM que esse componente deve ser executado como um executável local. Use a sintaxe semelhante ao exemplo a seguir para informar explicitamente ao DCOM para executar o objeto COM "out of Process" usando o procedimento armazenado sp_OACreate :

       DECLARE @object int
       DECLARE @hr int
       EXEC @hr = sp_OACreate 'SQLOLE.SQLServer', @object OUT, 4
    
  • Se o objeto COM for criado dentro de um procedimento armazenado estendido, o terceiro parâmetro de CoCreateInstance ou CoCreateInstanceEx poderá ser alterado para CLSCTX_LOCAL_SERVER. Isso é mostrado no exemplo de código a seguir usando CoCreateInstance:

       HRESULT hr = CoCreateInstance(CLSID_Test, NULL, CLSCTX_LOCAL_SERVER,
         IID_IUnknown, (void**)&piunknown);
    

Modificar o registro para forçar o Remoting do objeto

Se não for possível modificar o cliente COM para solicitar que o objeto seja criado fora do processo, há dois métodos diferentes para forçar o objeto a ser criado fora do processo.

  • Use o Visualizador de objetos OLE/COM (Oleview. exe) fornecido com o Microsoft Visual C++ e localize o ProgID na forma de OLEComponent. Object em todos os objetos. Selecione o objeto COM e, em seguida, no menu objeto , selecione CoCreateInstance flags. Certifique-se de que somente CLSCTX_LOCAL_SERVER esteja selecionado. Em seguida, nas guias servidor de implementação e InProc, selecione usar processo substituto e deixe o "caminho para substituto personalizado" em branco, o que permite que o arquivo Dllhost. exe seja carregado e a dll com colocada dentro do espaço de processo.

  • Use as etapas a seguir para atualizar manualmente o registro. Aviso: podem ocorrer problemas sérios se você modificar incorretamente o Registro usando o Editor do Registro ou qualquer outro método. Esses problemas podem exigir a reinstalação do sistema operacional. A Microsoft não pode garantir que esses problemas poderão ser solucionados. A modificação do Registro é de sua total responsabilidade.

    1. Obter o identificador de classe (CLSID) do objeto COM. O CLSID é um número de 128 bits e é considerado um identificador globalmente exclusivo (GUID) que é usado para identificar exclusivamente o componente, o módulo ou arquivo que contém esse objeto COM. Ao criar objetos COM usando os procedimentos armazenados de automação OLE, o primeiro parâmetro para o procedimento armazenado é um identificador programático ou o ProgID do objeto OLE usado para derivar o CLSID. Esta cadeia de caracteres descreve a classe do objeto OLE e tem o seguinte formato: OLEComponent.Object Você pode usar o identificador programático para localizar o identificador de classe de um objeto COM. Abra o editor do registro (regedit. exe) e, na tecla HKEY_CLASSES_ROOT use o método Find para localizar uma chave com o nome do seu <OLEComponent. Object>. Você vai encontrá-lo em outros níveis, mas ele deve estar localizado no nível diretamente abaixo do HKEY_CLASSES_ROOT. Depois de localizar a chave, expanda a pasta para o nome da chave e você deverá ver uma subchave chamada CLSID. Clique nessa pasta para ver os valores dentro dessa chave. No lado direito da tela está um título chamado "(padrão)". Os dados para essa chave devem estar no seguinte formato:   {59F929A0-74D8-11D2-8CBC-08005A390B09} Anote esse valor ou copie-o para o bloco de notas. Inclua os colchetes.

    2. Navegue na chave \CLSID do HKEY_CLASSES_ROOT e localize a subchave com esse número de GUID. Depois de realçar o HKEY_CLASSES_ROOT chave \CLSID, você pode usar a função Localizar no editor do registro (no menu Editar ) e colar o GUID na caixa de diálogo Localizar . Certifique-se de que você encontrou a interface adequada inspecionando a subchave InprocServer32 abaixo dessa chave, que aponta para o local do seu arquivo de DLL COM. Se houver uma chave TypeLib, marque esse valor de GUID. Isso deve ser diferente do que você anotou na etapa 1. Caso contrário, você tem o GUID TypeLib e não o GUID do objeto COM. A subchave ProgID terá um valor de ' OLEComponent. Object. 1 '. O que está no fim é para este exemplo apenas e é usado para informações de controle de versão.

    3. Enquanto estiver sob a subchave InprocServer32 do GUID, verifique se há um valor de ThreadingModel e se ele está definido como both ou Free para garantir que o empacotamento compreenda o modelo de Threading do objeto COM para habilitar a execução do espaço de processo sem do SQL Server. Se não houver um valor de ThreadingModel ou se for definido como Apartment, a instanciação do objeto COM pode não ser consistente. Observação Se você adicionar o valor ThreadingModel, certifique-se de testar o objeto COM antes de implementá-lo.

    4. Realce o número/subchave GUID na chave HKEY_CLASSES_ROOT \CLSID No menu Editar , clique em novoe selecione valor da cadeia de caracteres. Na coluna nome , digite o seguinte:

      AppID

    5. Pressione Enter e, em seguida, insira o identificador de classe ou o número GUID que você anotou na etapa 1 como o valor. O GUID deve estar dentro dos colchetes como no exemplo a seguir:   {59F929A0-74D8-11D2-8CBC-08005A390B09} O identificador do aplicativo AppID é usado pelo DCOM para associar a DLL a um arquivo executável.

    6. Adicione uma nova subchave sob o HKEY_CLASSES_ROOT \AppID e defina-a como o mesmo identificador de classe ou número de GUID com os colchetes inseridos na etapa anterior.

    7. Realce o nome do GUID. No menu Editar , clique em novoe selecione valor da cadeia de caracteres. Na coluna nome , digite o seguinte:

      DllSurrogate Deixe a coluna de dados em branco para esse valor. Como a coluna de dados está em branco, ela informa DCOM para executar o arquivo executável padrão, Dllhost. exe e carregar o objeto COM dentro do espaço de processo.

    8. Feche o editor do registro. Clique em Iniciar e em Executar. Na caixa de diálogo executar , digite o seguinte:

      DCOMCNFG Pressione a tecla Enter para abrir a caixa de diálogo Propriedades de configuração de DCOM. Clique na guia propriedades padrão e verifique se a opção habilitar distribuído com neste computador está selecionada. Se não estiver, selecione-o e clique em aplicar.

    9. Verifique se a conta de usuário do Microsoft Windows NT em que o SQL Server está sendo executado tem permissão "controle total" nas chaves do registro desse objeto. Se as permissões não forem suficientes ou se as chaves do registro forem inseridas incorretamente, podem ocorrer os seguintes erros ao criar o objeto COM:

      Informações de erro de automação OLE HRESULT: 0x80040154 Fonte: procedimento estendido ODSOLE Descrição: classe não registrada Informações de erro de automação OLE HRESULT: 0x80070005 Fonte: procedimento estendido ODSOLE Descrição: acesso negado. Informações de erro de automação OLE HRESULT: 0x80080005 Fonte: procedimento estendido ODSOLE Descrição: falha na execução do servidor

    10. Teste e veja se isso está executando o arquivo Dllhost. exe e carregando o objeto COM em seu espaço de processo. Isso requer que o Microsoft Windows NT Resource Kit esteja no computador com Windows NT em que o SQL Server está em execução. Abra um prompt de comando e no prompt de comando, execute o arquivo tlist. exe, que mostra todos os processos e seus identificadores de processo associados ou os identificadores de processo (PIDs). No script Transact-SQL em que sp_OACreate é executado e após a execução da chamada, mas antes de o script terminar, use o seguinte para atrasar a conclusão do script por mais 20 segundos:

      WAITFOR DELAY '000:00:20'
      

      Execute o script e navegue imediatamente até o prompt de comando e execute o arquivo tlist. exe. Observe o PID Dllhost. exe. Reexecute tlist. exe e passe o PID como parâmetro. Isso mostra as DLLs que são carregadas dentro do espaço de processo Dllhost. exe. O objeto COM baseado em DLL deve estar listado como sendo executado dentro desse processo. Depois que o script retorna, executar tlist. exe novamente revela que o processo Dllhost. exe não está mais em execução. No exemplo a seguir, a saída do objeto ADODB. O objeto de conexão é criado fora do espaço de processo do SQL Server. Esse instantâneo usando tlist. exe foi executado enquanto o objeto COM existia no espaço de processo Dllhost. exe. Observe que o módulo MsADO15. dll, que é o módulo que contém o objeto COM, é carregado.

      C:\>tlist dllhost
       275 dllhost.exe
         CWD:     C:\NT40\system32\ 
         CmdLine: C:\NT40\System32\dllhost.exe {00000514-0000-0010-8000-00AA006D2EA4}
      -Embedding
         VirtualSize:    19180 KB   PeakVirtualSize:    19180 KB
         WorkingSetSize:  1780 KB   PeakWorkingSetSize:  1780 KB
         NumberOfThreads: 3
          278 Win32StartAddr:0x01001920 LastErr:0x00000000 State:Waiting
          215 Win32StartAddr:0x00001b5e LastErr:0x00000000 State:Waiting
          253 Win32StartAddr:0x00001b60 LastErr:0x000000cb State:Waiting
         4.0.1381.105 shp  0x01000000  dllhost.exe
         4.0.1381.130 shp  0x77f60000  ntdll.dll
         4.0.1381.121 shp  0x77dc0000  ADVAPI32.dll
         4.0.1381.133 shp  0x77f00000  KERNEL32.dll
         4.0.1381.133 shp  0x77e70000  USER32.dll
         4.0.1381.115 shp  0x77ed0000  GDI32.dll
         4.0.1381.131 shp  0x77e10000  RPCRT4.dll
         4.0.1381.117 shp  0x77b20000  ole32.dll
           6.0.8267.0 shp  0x78000000  MSVCRT.dll
                           0x1f310000  msado15.dll
          2.30.4265.1 shp  0x766f0000  OLEAUT32.dll
          4.0.1381.72 shp  0x77bf0000  rpcltc1.dll
      

      Com a versão 7,0 do SQL Server em execução em estações de trabalho do Microsoft Windows 95 ou Microsoft Windows 98, os 32 "módulos de 32 bits carregados" dentro da ferramenta do aplicativo informações do sistema Microsoft podem ser usados durante a execução para ver o loading\unloading do arquivo Dllhost. exe e a DLL do objeto COM durante esse teste. Para acessar a ferramenta, clique em Iniciar, aponte para programas, aponte para acessóriose clique em Ferramentas do sistema.

Observação Devido a limitações de segurança, o Windows 95 ou o Windows 98 não permite iniciar um processo DLLSurrogate e carregar uma DLL COM por um cliente remoto. Portanto, o objeto COM deve existir na tabela de objetos em execução (ROT) e estar em execução/carregado se estiver disponível para ser usado por um computador cliente remoto. Você pode usar as etapas neste artigo para ajudar a isolar objetos COM quando eles forem suspeitos a causa da instabilidade no SQL Server. Certifique-se de que cada componente seja testado com a execução completa do processo para garantir um comportamento consistente. Diferença de desempenho ao instanciar um objeto COM no processo do SQL Server e fora do espaço de processo varia de acordo COM o espaço do processo. Além disso, alguns objetos COM não foram criados para serem remotos e podem vazar recursos. Teste exaustivamente antes de implementar as etapas neste artigo para algo diferente de uma etapa de solução de problemas. O seguinte artigo da base de dados de conhecimento Microsoft tem um exemplo de como um objeto COM Remoting pode causar um vazamento de recurso:

197426 CORRECção: tratamento de vazamento ao passar objetos ADO entre processos   Observação O Microsoft SQL Server 6,5, por padrão, opera com o modelo single thread apartment (STA) e manipula a inicialização de objetos COM em um thread interno separado. Nesse modelo, um thread é selecionado para controlar a criação de todos os objetos OLE dentro do processo do SQL Server e para proxy de volta para todas as conexões de cliente que precisam de acesso a esse objeto COM. Como isso é manipulado internamente pelo SQL Server, a persistência do objeto não pode ser garantida entre as instanciações do objeto COM.  

Referências

Para obter mais informações sobre o modelo de objeto COM do SQL Server 6,5, clique no número abaixo para ler o artigo na base de dados de conhecimento da Microsoft:

194661 Modelo de persistência de objeto COM do SQL ServerPara obter mais informações sobre a maneira como o Sp_OA procedimento armazenado é implementado, clique no número abaixo para ler o artigo na base de dados de conhecimento da Microsoft:

180780 Como Sp_OA extensão de procedimentos para o SQL Server é implementadaPara obter mais informações sobre como executar objetos COM baseados em DLL em substitutos de DLL; Confira o seguinte: Eddon, Guy; Eddon Henry, dentro de portais distribuídas (MPS). Microsoft Press, 1998, (ISBN 1-57231-849-X), capítulo oito: ' DLL substitutos e executáveis Components'Box, Don, Essential com. Addison-Wesley pub. Co., (ISBN 0-201-63446-5) capítulo seis: ' aplicativos ' Grimes, Richard, programação do DCOM profissional. Wrox Press Inc. (ISBN 1-861000-60-X), capítulo 4: ' modelo de objeto componente distribuído ' o suplemento DCOM para Windows 95 é fornecido com a mídia do SQL Server 7,0 e o arquivo é denominado DCOM95. exe. Você pode baixar o DCOM95. exe do seguinte site da Web:

http://www.microsoft.com/com

Precisa de mais ajuda?

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Microsoft Insider

Essas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade do idioma?
O que afetou sua experiência?

Obrigado pelos seus comentários!

×