Início / dba / Perguntas / 77872
Accepted
SQL Hammer
Asked: 2014-09-28 18:17:17 +0800 CST

Como o provedor PowerShell SQLPS SQLSERVER detecta servidores de gerenciamento central em SQLRegistration\Central Management Server Group

  • 772

Estou tendo um comportamento estranho com o provedor PowerShell SQLSERVER e o diretório SQLRegistration\Central Management Server Group. Abaixo estão os comportamentos. Gostaria de saber como o provedor SQLSERVER sabe quais CMS's estão registrados para que eu possa entender por que parece não perceber o registro quando feito no SSMS 2014 (veja abaixo o comportamento detalhado). Além disso, por que minha conexão falha quando sei que a instância está online.

Máquina de configuração

  • host local

Instâncias

  • localhost\SQL2012
  • localhost\SQL2014
  • localhost\SQL2014_1

Comportamento 1
Usando o SSMS 2014, registrei localhost\SQL2012 como um CMS. A execução desse código não retorna nenhum item. 

PS SQLSERVER:\SQLRegistration\Central Management Server Group> dir

Abrir e fechar o console do PowerShell e o SSMS não altera os resultados. Se eu abrir o SSMS 2012 e registrar localhost\SQL2012 como um CMS e executar novamente o comando acima, vejo localhost\SQL2012 registrado como esperado.

Comportamento 2
Depois de fazer o servidor listar com sucesso...

Diretório: Microsoft.SqlServer.Management.PSProvider\SqlServer::SQLSERVER:\SQLRegistration\Central Management Server Group

Nome do Modo

  • localhost\SQL2012

E a execução do comando abaixo para tentar navegar para meus grupos de servidores registrados falha com o erro abaixo, mesmo que a instância esteja online e disponível. 

PS SQLSERVER:\SQLRegistration\Central Management Server Group> Set-Location "localhost\SQL2012\"

Set-Location: Não é possível localizar o caminho 'SQLSERVER:\SQLRegistration\Central Management Server Group\localhost\SQL2012\' porque ele não existe. Na linha:1 char:1 + Set-Location "localhost\SQL2012\" + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ + CategoryInfo : ObjectNotFound: (SQLSERVER:\SQLR...alhost\SQL2012:String) [Set-Location], ItemNotFoundE xception + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

A atualização 1
SMO parece funcionar bem. O código abaixo retorna com sucesso meus grupos de servidores. 

#Load SMO assemblies
$CentralManagementServer = "localhost\sql2012"
$MS='Microsoft.SQLServer'
@('.SMO', '.Management.RegisteredServers', '.ConnectionInfo') |
     foreach-object {if ([System.Reflection.Assembly]::LoadWithPartialName("$MS$_") -eq $null) {"missing SMO component $MS$_"}}

$connectionString = "Data Source=$CentralManagementServer;Initial Catalog=master;Integrated Security=SSPI;"
$sqlConnection = new-object System.Data.SqlClient.SqlConnection($connectionString)
$conn = new-object Microsoft.SqlServer.Management.Common.ServerConnection($sqlConnection)
$CentralManagementServerStore = new-object Microsoft.SqlServer.Management.RegisteredServers.RegisteredServersStore($conn)

$CentralManagementServerStore.ServerGroups[ "DatabaseEngineServerGroup" ].ServerGroups
sql-server powershell

2 respostas

  1. A explicação de Shawn sobre discrepâncias entre a versão do SQL Server parece correta. Por esse motivo, acredito que o SMO seja um método mais estável. Eu estou indo para a frente usando o código abaixo.

    Import-Module SQLPS -DisableNameChecking

Function Parse-ServerGroup($serverGroup)
{
    $results = $serverGroup.RegisteredServers;
    foreach($group in $serverGroup.ServerGroups)
    {
        $results += Parse-ServerGroup -serverGroup $group;
    }
    return $results;
}

Function Get-ServerList ([string]$cmsName, [string]$serverGroup, [switch]$recurse)
{

    $connectionString = "data source=$cmsName;initial catalog=master;integrated security=sspi;"
$sqlConnection = New-Object ("System.Data.SqlClient.SqlConnection") $connectionstring
    $conn = New-Object ("Microsoft.SQLServer.Management.common.serverconnection") $sqlconnection
    $cmsStore = New-Object Microsoft.SqlServer.Management.RegisteredServers.RegisteredServersStore($conn)
    $cmsRootGroup = $cmsStore.ServerGroups["DatabaseEngineServerGroup"].ServerGroups[$serverGroup]

    if($recurse)
    {
        return Parse-ServerGroup -serverGroup $cmsRootGroup | select ServerName
    }
    else
    {
        return $cmsRootGroup.RegisteredServers | select ServerName
    }
}

Get-ServerList -cmsName "localhost\SQL2012" -serverGroup "Production" -recurse | Format-Table
    • 2
  2. Best Answer

    Comportamento 1 que posso esperar porque há alguns recursos que podem ou não funcionar conforme o esperado ao usar uma versão superior do SSMS na versão inferior da instância. Pode haver coisas em segundo plano que mudaram ligeiramente de 2014 para 2012 sobre as quais você provavelmente nunca encontrará nenhuma documentação. Na verdade, eu criaria um item de conexão nisso se você pudesse recriar esse cenário em outra máquina todas as vezes.

    Agora, o Comportamento 2 falhou na primeira vez que tentei, mas foi bem-sucedido todas as vezes depois disso, mesmo depois de abrir/fechar janelas. No entanto, se você está tentando isso usando apenas PowerShell.exe, é de se esperar que algumas coisas não funcionem exatamente da mesma maneira quando você está lidando com o SQLPSprovedor. Se você tentou fazer o mesmo comando, SQLPS.exeeu esperaria que funcionasse todas as vezes, pelo menos para mim. Agora não estou usando o SQL Server 2014, apenas o 2012 está carregado na minha máquina agora.

    Você pode ver o quão diferentes PowerShell.exee SQLPS.exesão comparando os assemblies carregados em cada um:

    insira a descrição da imagem aqui

    • 1

relate perguntas