A execução de um objeto COM baseados em DLL fora do processo do SQL Server

Microsoft SQL Server 6.5 ou posterior fornece a capacidade de carregar e executar objetos COM (Component Object Model) personalizados por meio de um conjunto de automação OLE procedimentos armazenados ou por meio de procedimentos armazenados estendidos. Por padrão, objetos COM base em DLL são carregados como em processo de servidor, que significa que os objetos COM não são carregados somente no espaço de endereço de memória processo SQL Server, mas eles também têm acesso completo a esse espaço de endereço de memória. Portanto, um objeto COM carregados no espaço de processo do SQL Server deve aderir às mesmas regras como qualquer arquivo DLL. Há uma possibilidade de que um objeto COM pode substituir a memória no SQL Server processo ou vazamento de recursos, causando instabilidade.

Se houver suspeita que um objeto COM pode estar afetando a robustez do processo do SQL Server, talvez queira usar as etapas neste artigo para instanciar o objeto COM fora do espaço de processo do SQL Server. Implementação do Distributed Component objeto modelo (DCOM) especificação de "Local transparência" no sistema operacional tenha fornecido a capacidade de executar um objeto COM baseados em DLL fora o espaço de processo do SQL Server.

O processo da execução de um objeto COM baseados em DLL fora do espaço de endereço do aplicativo principal é chamado de sistema de interação remota. Sistema de interação remota requer que outro executável seja um processo substituto no lugar do executável do SQL Server. O padrão executável usado pelo DCOM Gerenciador de controle de serviços (RPCSS.exe) é denominado Dllhost.exe. A estrutura de suporte ao DCOM usa o arquivo Dllhost.exe para carregar a DLL em seu espaço de processo e usa pares de proxy/stub para empacotar a interface solicitada transparente para o cliente, que nesse caso é o SQL Server. Este executável pode aceitar várias solicitações/método de interface simultaneamente. Depois que o uso de interface for concluído, o Gerenciador de controle de serviço (SCM) do DCOM gerencia limpa backup e descarregamento do arquivo Dllhost.exe. Objetos COM não devem ser esperados para manter informações de estado entre instanciações.

Em ordem para este artigo funcionar corretamente, o sistema deve estar executando um sistema de operacional DCOM habilitado. Isso seria o Microsoft Windows NT 4.0 Service Pack 2 ou posterior, Microsoft Windows 98 ou Microsoft Windows 95 com o suplemento DCOM instalado. As etapas a seguir podem aplicar a qualquer objeto baseado em DLL COM que está sendo criado no espaço de processo do SQL Server, se é seja instanciado por meio de sp_OACreate ou um procedimento armazenado estendido.

Informações sobre os dois métodos básicos que você pode usar para instanciar o objeto COM fora do processo segue.

COM remoting de solicitações de cliente do objeto

Alterando a maneira que você chamar o objeto COM, você pode solicitar que o objeto ser criado fora do espaço de endereço do SQL Server.

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

     DECLARE @object int
     DECLARE @hr int
     EXEC @hr = sp_OACreate 'SQLOLE.SQLServer', @object OUT, 4
  						

• Se o objeto COM é criado dentro de um longo procedimento armazenado o terceiro parâmetro de CoCreateInstance ou CoCreateInstanceEx pode ser alterado para CLSCTX_LOCAL_SERVER. Isso é mostrado na seguinte exemplo de código usando CoCreateInstance :

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

Modificar registro para forçar a comunicação remota do objeto

Se você não pode modificar o cliente COM para solicitar que o objeto ser criado fora do processo, dois métodos diferentes existem para forçar o objeto a ser criado fora do processo.

• Use o objeto OLE/COM visualizador (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 sinalizadores . Veja que CLSCTX_LOCAL_SERVER somente está marcada. Em seguida, na implementação e Servidor InProc guias Selecione um Processo substituto de usar e deixar o "caminho para personalizar substitutos" em branco, que permite que o arquivo Dllhost.exe a ser carregado e a DLL de COM colocado do espaço de processo.
  
  Se você não tiver o Microsoft Visual C++, o utilitário de Visualizador de objeto OLE/COM também está disponível para download no seguinte site da Microsoft:
  http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en (http://www.microsoft.com/downloads/details.aspx?familyid=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en)
• Use as seguintes etapas para atualizar manualmente o registro.
  
  Aviso Podem ocorrer sérios problemas se você modificar o registro incorretamente usando o Editor do registro ou usando outro método. Esses problemas podem exigir que você reinstale seu sistema operacional. A Microsoft não garante que esses problemas possam ser solucionados. Modificar o registro por sua própria conta e risco.
  1. Obter o identificador de classe (CLSID) do objeto COM. O CLSID é um número de 128 bits e considerado um identificador global exclusivo (GUID) que é usado para identificar exclusivamente o componente, módulo ou arquivo que contém esse objeto COM. Quando criarem objetos COM usando a automação OLE, procedimentos armazenados, o primeiro parâmetro para o procedimento armazenado é um identificador programático ou o ProgID do objeto OLE é usado para derivar o CLSID. Essa seqüência de caracteres descreve a classe do objeto OLE e tem o seguinte formulário:

           OLEComponent.Object
     								

     você pode usar o identificador programático para localizar o identificador de classe para um objeto COM.
     
     Abra o Editor do Registro (Regedit.exe) e sob a chave HKEY_CLASSES_ROOT use o método Find para localizar uma chave com o nome do seu <OLEComponent.Object>. Você o encontrará em outros níveis, mas ele deve estar localizado no nível diretamente abaixo de HKEY_CLASSES_ROOT. Após localizar a chave, expanda a pasta para o nome da chave e você verá uma subchave denominada CLSID. Clique nessa pasta para ver os valores dentro dessa chave. No lado direito da tela é um título chamado "(default)". Os dados para essa chave devem estar no seguinte formato:

           {59F929A0-74D8-11D2-8CBC-08005A390B09}
     								

     Anote esse valor ou copiá-lo para bloco de notas. Inclua os colchetes.
  2. Navegue sob a chave HKEY_CLASSES_ROOT\CLSID e localize a subchave com esse número GUID. Depois que você realce a chave HKEY_CLASSES_ROOT\CLSID você pode usar a função Localizar no Editor do Registro (no menu Editar ) e cole o GUID na caixa de diálogo Localizar . Certifique-se que você descobriu a interface apropriada inspecionando a subchave InprocServer32 abaixo essa chave, que aponta para o local do arquivo COM DLL. Se houver uma chave TypeLib, verifique este valor de GUID. Isso deve ser diferente do que você anotou na etapa 1. Caso contrário, você terá o GUID TypeLib e não o GUID para o objeto COM. A subchave ProgID terá um valor de 'OLEComponent.Object.1'. Ao final é para esse exemplo apenas e é usado para informações de versão.
  3. Enquanto subchave do GUID InprocServer32, certifique-se que um valor de ThreadingModel existe e que é definida como qualquer ambos ou livre para certificar-se o empacotamento entende o modelo de threading do objeto COM para habilitar a execução do COM espaço de processo do SQL Server. Se não houver um valor de ThreadingModel ou ele é definido como Apartment, instanciação de objetos COM pode não ser consistente.
     
     Observação Se você adicionar ThreadingModel valor Certifique-se de que você testar seu objeto COM antes de implementar.
  4. Realce o número/subchave GUID sob a chave HKEY_CLASSES_ROOT\CLSID. No menu Editar , clique em novo e, em seguida, selecione o Valor da seqüência . Na coluna Name , digite o seguinte:
     AppID
  5. Pressione ENTER e, em seguida, insira o identificador de classe ou número GUID que você anotou na etapa 1 como o valor. O GUID deve estar dentro de chaves como no exemplo a seguir:

      
           {59F929A0-74D8-11D2-8CBC-08005A390B09} 
     
     								

     o identificador de aplicativo AppID é usado pelo DCOM para associar a DLL com um arquivo executável.
  6. Adicione uma nova subchave sob a HKEY_CLASSES_ROOT\AppID e defina seu nome para o mesmo identificador de classe ou o número GUID com os colchetes conforme inserido na etapa anterior.
  7. Realce o nome GUID. No menu Editar , clique em novo e, em seguida, selecione o Valor da seqüência . Na coluna Name , digite o seguinte:
     DllSurrogate
     Deixe a coluna de dados em branco para esse valor. Como a coluna de dados estiver em branco, isso informa ao DCOM executar o arquivo executável padrão, o Dllhost.exe e carregar o objeto COM dentro dele processo espaço.
  8. Feche o Editor do Registro. Clique em Iniciar e, em seguida, clique 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 distribuída do DCOM . Clique na guia Propriedades padrão e certifique-se de que Ativar DCOM neste computador está selecionada. Se não estiver, selecioná-lo e, em seguida, clique em Aplicar .
  9. Verifique se a conta de usuário do Microsoft Windows NT SQL Server está sendo executado em tem permissão "Full Control" nas chaves do Registro para este objeto. Se as permissões não forem suficientes ou as chaves do Registro são inseridas incorretamente os seguintes erros podem ocorrer quando você está criando o objeto COM:
     Informações de erro de automação de OLE
     HRESULT: 0 X 80040154
     Fonte: ODSOLE procedimento estendido
     Descrição: Classe não registrada
     
     Informações de erro de automação de OLE
     HRESULT: 0 X 80070005
     Fonte: ODSOLE procedimento estendido
     Descrição: Acesso negado.
     
     Informações de erro de automação de OLE
     HRESULT: 0X80080005
     Fonte: ODSOLE procedimento estendido
     Descrição: Falha na execução do servidor
     
  10. Teste e veja se isso estiver executando o arquivo Dllhost.exe e carregando o objeto COM no seu espaço de processo. Isso requer que o Microsoft Windows NT Resource Kit está no computador Windows NT em que o SQL Server está em execução. Abra um prompt de comando e a partir do prompt de comando execute o arquivo tlist.exe, que mostra todos os processos e seus identificadores de processo associado ou identificadores de processo (PIDs). No script Transact-SQL onde sp_OACreate é executado e depois que a chamada for executada, mas antes do término de script, use o seguinte para atrasar a conclusão do script para um adicionais 20 segundos:

      WAITFOR DELAY '000:00:20'
      								

      executar o script e imediatamente navegue até o prompt de comando e execute o arquivo tlist.exe. Observe o Dllhost.exe PID. Execute novamente tlist.exe e passar a identificação como um parâmetro. Isso mostra as DLLs que são carregadas no espaço de processo Dllhost.exe. O objeto COM baseados em DLL deve ser listado como execução no processo. Depois que o script retorna, executando novamente o tlist.exe revela que o processo Dllhost.exe não está sendo executado.
      
      Na saída de exemplo a seguir o objeto ADODB.Connection é 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 SQL Server versão 7.0 Desktop Edition em execução em estações de trabalho do Microsoft Windows 95 ou Microsoft Windows 98, "32-bit módulos carregado" dentro da ferramenta de aplicativo informações do sistema Microsoft pode ser usado durante a execução de consulte loading\unloading do arquivo Dllhost.exe e o objeto COM DLL durante esse teste. Para acessar a ferramenta, clique em Iniciar , aponte para programas , aponte para Acessórios e, em seguida, clique em Ferramentas do sistema .

Observação Devido às limitações de segurança, Windows 95 ou Windows 98 não oferece suporte iniciar um processo DLLSurrogate e carregar uma DLL COM por um cliente remoto. Portanto, o objeto COM deve existir em ROT (executar objeto tabela) e ser executado/carregados se ele deverá estar disponível para uso por um computador cliente remoto. Você pode usar as etapas neste artigo para ajudar a isolar objetos COM quando eles são suspeita de ser a causa da instabilidade no SQL Server. Certifique-se de que cada componente seja testado exaustivamente executando fora do processo para garantir um comportamento consistente. Diferença de desempenho no instanciar um objeto COM no processo do SQL Server e fora do espaço de processo varia. Além disso, alguns objetos COM não foram criados para ser remoto e podem vazar recursos. Teste completamente antes de implementar as etapas neste artigo para algo diferente de uma etapa de solução de problemas. O seguinte artigo tem um exemplo de como um objeto COM do remoting pode causar um vazamento de recursos: Observação Microsoft SQL Server 6.5, por padrão, funciona com o modelo de STA (single Thread Apartment) e trata a inicialização de objetos COM em um segmento separado interno. Nesse modelo, um thread está selecionado para controlar a criação de todos os objetos OLE dentro do processo do SQL Server e ao proxy de volta para todas as conexões de cliente que precisam de acesso a este objeto COM. Porque isso é tratado internamente pelo SQL Server, persistência do objeto não pode ser garantida entre instanciações do objeto COM.

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: Para obter mais informações sobre a maneira que o Sp_OA procedimento armazenado é implementado, clique no seguinte número de artigo para ler o artigo na Base de dados de Conhecimento da Microsoft: Para obter mais informações sobre objetos baseados em DLL COM dentro de substitutos de DLL; consulte o seguinte:

Eddon, equipe; Eddon Henrique, Inside Distributed Com (Mps). Microsoft Press, 1998 (ISBN 1-57231-849-X), capítulo oito: ' DLL substitutos e executável componentes

Caixa, Don, COM essenciais . Addison-Wesley Pub. Co., (ISBN 0-201-63446-5) capítulo seis: 'Applications' Grimes, Richard, programação do Professional DCOM . Capítulo 4, Wrox Press Inc. (ISBN 1-861000-60-X): 'Distributed Component Object Model' O Add-in DCOM para Windows 95 é fornecido com a mídia do SQL Server 7.0 e o arquivo é chamado DCOM95.exe. Você pode baixar DCOM95.exe o seguinte site: