Migração do MSX SQL Server 2005 para SQL Server 2014

Após escrever o Post anterior, a equipe de DBA’s no qual faço parte, decidiu migrar o servidor do MSX para uma instância que temos com o SQLServer 2014. Escrevo aqui os detalhes dessa migração.

Ao migrar de servidor, os jobs já existentes devem ser criados no novo servidor master.

Para migrar os jobs é bem simples, basta realizar os seguintes passos no servidor SQL Server 2005:

Abrir o Object Explorer Details (F7) -> SQL Server Agent (MSX) -> Jobs -> Multi-Server Jobs. Selecionar todos os Jobs que deseja migrar, clica com o botão direito e escolher a opção Script Job as -> Create To e gerar o script da melhor forma que achar para manipulá-lo ou executá-lo.

Foto1MigracaoMSX

Lembrando que esse script é alterado facilmente, trazendo maior flexibilidade. No meu caso, eu retirei a parte que associa o Job ao servidor target para realizar esse vínculo mais tarde.

Simples de realizar a migração dos Jobs não? Exatamente, realmente é bem simples, mas às vezes pode ocorrer o seguinte erro:

ErroMigracaoMSX

“Unable to cast object of type ‘System.DBNull’ to type ‘System.String’.”

Esse erro pode atrapalhar ou atrasar um pouquinho na migração. No post anterior foi relatado que frequentemente o servidor master, perdia a conexão com o servidor target e que a solução era excluir o servidor target e recriá-lo, com isso, o Server_id na sysjobservers muda, ocasionando esse erro na hora de migrar, já que no histórico de execuções, teremos o nome do Job como NULL, sendo que esse servidor não existe mais.

Executemos o seguinte comando para verificar :

 USE MSDB

SELECT j.Name,

js.server_id,

ts.Server_id

FROM dbo.sysjobservers js

INNER JOIN msdb.dbo.sysjobs j ON j.job_id = js.job_id

LEFT JOIN msdb.dbo.systargetservers ts ON ts.server_id = js.server_id

WHERE j.name IS NULL

 

Ao encontrar registros no SELECT anterior, executar o seguinte script para eliminar esses registros:



USE MSDB

DELETE FROM js

FROM dbo.sysjobservers js

INNER JOIN dbo.sysjobs j ON j.job_id = js.job_id

LEFT JOIN dbo.systargetservers ts ON ts.server_id = js.server_id

WHERE ts.server_id IS NULL

Como aqui estamos excluindo os registros de associação de determinado job  com um target server que não existe mais, não há problemas de executar esse script. Lembrando que é sempre bom realizar a verificação antes (SELECT).

Resolvendo esse problema, é só executar o passo de gerar o script para migração novamente.

Como os scripts que geram os jobs estão salvos, iremos desassociar todos os servidores target do servidor master que está na versão SQL Server 2005 (SQLServer2005) com o seguinte script:

Conectar no servidor SQLServer2005:


USE msdb

DELETE FROM dbo.systargetservers

WHERE server_name in ('','','','','','') --Colocar aqui a lista dos servidores <em>target</em>

Às vezes, por motivo de falha de atualização e na comunicação entre os servidores, essa dissociação não é realizada tão facilmente, fazendo com que seja necessário realizar manualmente com os seguintes passos:

Conectar no Servidor Target:

No Microsoft SQL Server Management Studio, clicar com o botão direito no SQL Server Agent -> Multi Server Administration -> Defect

Obs.: é importante que essa dissociação seja realizada, pois só é possível ter um servidor master para cada servidor target.

Após realizar a dissociação, iremos configurar o novo servidor como Master seguindo os seguintes passos:

No Microsoft SQL Server Management Studio, clicar com o botão direito no SQL Server Agent -> Multi Server Administration -> Make This a Master …

É só realizar a configuração solicitada. É bem simples e intuitivo.

E prontinho! É só gerar os scripts de criação dos jobs e testar a conexão. Após essa migração, que tem 15 dias, os problemas que ocorreriam com frequência e que foram relatados no Post Anterior não aconteceram.

Obs.: É importante lembrar que se você tiver alertas configurados e que nesses alertas é disparado um Job  a associação Alert + Job deverá ser refeita, pois ao alterar um job essa referência é perdida.


USE MSDB

EXEC msdb.dbo.sp_update_alert @name=N'NomeAlert',

@job_name=N'NomeJob'

Podemos perceber que a migração é bem simples de ser realizada necessitando apenas tomar alguns cuidados.

Referências:

https://sqlsanctum.wordpress.com/2015/02/12/multi-server-job-scripting-failure/

Anúncios

Problemas no Master Server Job’s

Venho aqui falar sobre alguns erros que com “frequência” acontecem no Master Server Jobs (MSX).

Mas antes de já partir para os problemas, simplifico aqui o que seria o MSX:

Todo DBA utiliza algum tipo de “agendador” para criar as suas rotinas de manutenção do ambiente, seja rotina de desfragmentar os índices, atualizar as estatísticas, coletar algum tipo de informação para estudos… e no SQL Server utilizamos SQL Server Agent para criar e executar os Jobs que nos atendem para esses tipos de atividades. ¹

Acontece que temos este serviço para cada instância do SQL Server, ou seja, se temos somente uma instância, teremos um Agent, se temos 10 instâncias, teremos 10 Agents um para cada instância. Em um caso que temos mais de uma instância, a manutenção desses job’s fica um pouco complicada, pois se queremos que um Job que verifica as transações abertas há muito tempo seja executado em todos os servidores, teremos que criá-lo mais de uma vez. Então a manutenção fica mais complicada, podendo ocorrer diferenças entre versões nos servidores. O Master Server Jobs veio para facilitar essa manutenção dos Jobs criando um servidor Master para que os jobs sejam centralizados nele e que possam ser “replicados” para os outros servidores desejados, sendo que qualquer tipo de manutenção ou criação fica restrito a este servidor Master.

Acontece que nem tudo é tão simples.  Às vezes ocorrem bloqueios ao atualizar algum job ou até mesmo a conexão fica em Suspected impossibilitando que o mesmo seja executado conforme agendado.

Aqui neste passo a passo iremos verificar como ajustar o problema de Suspected e Blocked no Master Server Jobs.

Para administrar o nosso MSX sigamos os seguintes passos:

Passos Para Administrar o MSX 1

Passos Para Administrar o MSX 1

Nos servidores que estão com o Status  de “Normal | Suspected”, provavelmente os jobs dos servidores Target não estão sendo executados, além disso ao atualizar ou criar algum job, os mesmos não serão atualizados/criados nesses servidores, pois estamos com uma falha na comunicação. Para resolver esse problema, recriaremos o Target Server que está com problemas:

Primeiramente, antes de realizar a exclusão do Target Server, salvaremos um script para executar após a normalização da comunicação:

--Executar no Servidor <em>Target</em></code>

USE MSDB

GO

--Selecionar todos os Jobs que são do Master Server Jobs

SELECT 'EXEC msdb.dbo.sp_add_jobserver @job_name=N"' + name +'", @server_name = N"ServerName"'

FROM dbo.sysjobs

WHERE originating_server_id = 1

ORDER BY name

Obs.: Após executar esse script, salvar o resultado, pois será utilizado posteriormente.

--Excluir o TARGET SERVER do MSX</code>

USE MSDB

BEGIN TRAN

DELETE FROM dbo.systargetservers

WHERE server_name = 'ServerName'

--COMMIT

Após excluir o Target Server, iremos adicioná-lo novamente:

No servidor que será o Target Server, realizar os seguintes passos:

Criando Target Server 1

Job4

Job5

Conectar ao servidor Master:

Job6

Job7

Aqui neste caso não tenho a necessidade de criar um novo login para comunicação, porém se for o seu caso, marcar esta opção.

Job8

Job9

Job10

Obs.: Caso ocorra o seguinte erro: “The enlist operation Filed (reason: SQLServerAgent Error: The target server cannot establish an encrypted connection to the master server ‘Server Name’. Make sure that the MsxEncryptChannelOptions registry subkey is set correctly on the target server.) (Microsoft SQL Server. Error: 22026)” Modificar o registro MsxEncryptChannelOptions para 0. Para mais detalhes acessar o link: https://msdn.microsoft.com/en-us/ms365379.aspx.

Após modificar o registro para 0, executar novamente o passo de incluir um novo servidor Target. 

Job11

Com o Target server incluso novamente, executar o script salvo no início deste passo a passo.

Provavelmente, após adicionar todos os Job’s no Target Server, algum erro de “Blocked” pode ocorrer, neste caso, é só verificar os Jobs que ainda não foram transferidos pelo Target, excluir o próximo a ser baixado e atualizar a tela de administração para verificar se o Status de “Blocked” saiu.

Blocked1

Blocked2

Blocked3

Lembrando que por enquanto o meu servidor Master está na versão SQL Server 2005. Muito provavelmente esses erros não ocorram com tanta frequência nas versões mais atuais, porém, caso ocorram, aí está o passo a passo que talvez possa ajudá-los.

1) Para mais informações sobre o SQL Server Agent: https://msdn.microsoft.com/pt-br/library/ms189237(v=sql.105).aspx