Executando o Oracle SQLPlus em uma instrução Powershell Invoke-Command em uma máquina remota

2

Temos um script básico de powershell que tenta executar o SQLPlus.exe em uma máquina remota. O controle remoto não possui o cliente Oracle Instant instalado, mas reunimos todas as DLLs necessárias em uma pasta remota. Por exemplo, temos sqlplus.exe e dependências no diretório C: \ temp \ oracle.

Se eu navegar para esse caminho no servidor remoto e executar o sqlplus.exe, ele funcionará bem. Eu recebo a solicitação do nome de usuário.

Se eu for:

Invoke-Command -comp remote.machine.host -ScriptBlock { C:\temp\oracle\sqplus.exe }

Eu recebo o seguinte:

Error 57 initializing SQL*Plus
    + CategoryInfo          : NotSpecified: (Error 57 initializing SQL*Plus:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Error loading message shared library

Pensando que é potencialmente um problema PATH, tentei o seguinte:

Invoke-Command -comp remote.machine.host -ScriptBlock { $env:ORACLE_HOME= "C:\temp\oracle"; $env:PATH = "$env:ORACLE_HOME; C:\temp\oracle\sqlplus.exe }

Isso teve o mesmo resultado.

O código de erro não é muito útil e é extremamente frustrante, pois funciona quando eu faço logon na máquina. O que é o remoting powershell fazendo isso não funcionar?

    
por Scott Muc 13.09.2010 / 18:12

2 respostas

1

Isso cheira a mim como um problema ambiental. Por que você não pode instalar o cliente corretamente no sistema remoto?

Existe alguma maneira de você despejar seu ambiente do script powershell antes de invocar o SQL * Plus? Se sim, compare isso com o seu ambiente quando você estiver logado e ele funcionar. Talvez algo assim:

Invoke-Command -comp remote.machine.host -ScriptBlock { $env:ORACLE_HOME= "C:\temp\oracle"; $env:PATH = "$env:ORACLE_HOME"; set > c:\temp\oracle\set.txt  }

Observação: parece que há uma aspa dupla faltando na sua declaração PATH adicionada. Suponho que seja um erro de transcrição.

    
por 16.09.2010 / 19:10
1

O erro 57 está frequentemente relacionado a problemas de memória. Embora a saída não seja muito útil e o uso de remotas complique o problema, pode ser devido à memória disponível para o shell remoto, especificamente, o valor MaxMemoryPerShellMB na máquina remota.

Isso pode ser verificado com

winrm get winrm/config

e o resultado está próximo do fim. No nosso caso, isso foi definido como 150, enquanto 512 foi o suficiente nos alvos que não falharam. O valor pode ser definido com

winrm set winrm/config @{MaxMemoryPerShellMB="512"}

ou definindo uma Política de Grupo na máquina.

    
por 05.09.2012 / 16:52