Troubleshooting Kerberos Configuration

Galera, venho compartilhar com vocês uma ferramenta que eu descobri esse semana… “Microsoft Kerberos Configuration Manager for SQL Server” . Eu não sei vocês, mas eu não sabia de sua existência. Fiquei feliz demais por descobrir isso, pois fazer troubleshooting de falha de autenticação Kerberos é horrível!!!! Já sofri muito com isso, já perdi muito tempo com isso até identificar onde está o erro e esta ferramenta é MARAVILHOSA!!! Super intuitiva, caso seja algum SPN que não está cadastrado, ela gera o script para você cadastrar.

Enfim, meu objetivo aqui não é explicar como que a ferramenta trabalha, mas divulgar (para quem ainda não sabia) a sua existência. Fiquei feliz demais ao descobri-la.

Estou meio que me sentindo o Rubinho Barrichello, pois vi que essa ferramenta foi lançada em 2013, mas antes tarde do que nunca rsrsrs.

 

Alguém aqui sabia de sua existência?

 

Para mais detalhes do funcionamento dessa ferramenta, é só acessar o seguinte link.

 

Para fazer download da ferramenta é só clicar no link.

 

Mulheres na TI: quantas você conhece?

WebCast

Estou aqui, às 23:30 de um domingo para lembrar que o nosso WebCast está chegando!!!

EU(Nane Flores – DBA), juntamente com Sulamita Dantas(DBA), Dani Marinho(Desenvolvedora) e Suh Moraes(DBA) resolvemos nos juntar para realizar um bate-papo que  irá ocorrer no dia 06/06/2017 (Terça-Feira) sobre as mulheres no mercado de trabalho de TI. Falar sobre os nossos desafios, dia a dia, contar como que chegamos onde estamos e desenvolver uma conversa descontraída de forma a encorajar cada vez mais as mulheres virem para esta área. É mostrar que temos um belo espaço nesta área linda!

Segue um pouco da descrição do nosso WebCast:

“Este WebCast tem o objetivo de mostrar para as mulheres, que esta área não é um bicho de sete cabeças, fazendo da TI uma opção a mais na escolha de sua profissão. Vamos mostrar como começou nossas carreiras, o nosso dia-a-dia no trabalho, de forma a incentivar/inspirar outras mulheres. Mostrar que, cada um tem um espacinho nessa área, que cresce cada vez mais, mas que a participação feminina ainda é muito pequena. Lembrando sempre, que todas (e todos, é claro) são muito bem vindos! Vai perder?

Link do evento aqui .

Esperamos todos vocês para este bate-papo, com o objetivo de enriquecê-lo cada vez mais.

NoLock – Remote table-valued function calls

Olá pessoas. Estou participando de uma migração e achei interessante compartilhar um caso com vocês.

O Post é bem pequenino somente a título de curiosidade mesmo.

Nessa migração estamos retirando as bases de dados do ambiente de produção SQL Server 2008 R2 com modo de compatibilidade 80 para SQL Server 2014 com modo de compatibilidade 120.

A maior dificuldade dessa migração é sair do modo de compatibilidade 80, pois a partir dele muita sintaxe deixou de funcionar como o * = / = * substituído pelo Left join / Right Join e a sintaxe do Raiserror sendo exigido colocar os parâmetros entre parênteses, porém uma coisa que deixou a equipe mais “encucada”  foi o NoLock .

Sabemos que os desenvolvedores quase nunca usam o NoLock, né? (sarcasmo). Então tivemos uma amostra legal do erro.

Na documentação do SQL Server 2016 está dizendo que em versões futuras não será mais permitido a utilização de Hints sem a clausula “With”, porém EM VERSÕES FUTURAS, ou seja, ainda conseguimos usar o NoLock sem o With.

hintssqlserver

Porém quando executamos uma consulta via linked server sem a clausula with, é retornado o seguinte erro:

SELECT *
FROM [sqlh110].master.sys.databases (NOLOCK)

Msg 4122, Level 16, State 1, Line 2
Remote table-valued function calls are not allowed.

Obs.: A consulta foi realizada em um SQL Server 2014 (SP2).

Agora vocês pensam: “O quê é que tem a ver erro de Remote table-value function com o NoLock? “.

Tudo indica que o parse do SQL Server entende aqui que ao colocar o NoLock entre parênteses (NOLOCK) na verdade está chamando uma função remotamente e que não é uma Hint. Vi essa explicação no seguinte link:

(http://stackoverflow.com/questions/17242733/why-is-with-required-when-using-nolock-on-a-remote-table-call)

Podemos provar isso com a seguinte consulta:

SELECT *
FROM [sqlh110].master.sys.databases NOLOCK

resultadoselectnolock

Ao retirar o parênteses a consulta retorna o resultado normalmente, mesmo sem a clausula “With”.

Identificamos que para o código voltar a funcionar basta retirar os parênteses, porém já que o mesmo será editado para corrigir o erro recomendo que editem da forma “completa”, pois, como olhamos na documentação, isso será descontinuado, então não custa nada sempre que forem utilizar a Hint “NoLock”, que a mesma seja precedida pela clausula “With”, evitando assim, erros em versões futuras.

Editado em 28/12/2016

Conforme observado pelo Reginaldo Silva o nolock sem os parênteses funciona, pois na verdade o SQL Server entende que a palavra “NoLock” é um alias e não uma Hint para realizar a leitura suja, ou seja, para consertar de fato o erro citado no post é colocando o with antes do (nolock).

Minha primeira palestra

08f4ad19-7b49-4b0c-b4de-14722d6337d3

No dia 26/11/2016 aconteceu o SQL Saturday 573 aqui em Brasília conforme já havia falado no post de divulgação do evento , mas o quê eu não tinha falado é que eu ia palestrar. De fato, até a data que lancei o post, eu não havia decidido bem se ia palestrar ou não, mas com muito incentivo dos meus colegas/amigos de trabalho e SQL decidi palestrar juntamente com o Gustavo (também colaborador do blog) .

Então aproveitando a oportunidade que me foi concedida de palestrar no Sat de Brasília (que já me sentiria a vontade por ser a minha cidade), juntando em ter meu parceiro de algum tempo de SQL Server (Gustavo) palestrando do meu lado e um tema que gosto muito (índices) tive a coragem e encaminhei minha palestra.

A palestra foi voltada para os alunos da faculdade e para todos os DBA’s iniciantes que querem entender melhor para que serve um índice. Como o próprio tema deixa bem claro, “Indexação para iniciantes” foi bem básica mesmo, expliquei para que servia um índice, suas vantagens, melhores práticas e desvantagens seguidos de exemplos. Apesar da palestra ser bem básica, tive a presença de colegas DBA’s, que já entendem bastante do assunto, assistindo a nossa palestra. Todo esse apoio me deixou mais segura e confiante para passar um pouco do meu conhecimento.

Sou muito grata por ter essa oportunidade de poder contribuir um pouco com a comunidade. Essa gratidão é grande, pois a comunidade SQL Server é muito forte, cada um apoia o outro, passam o conhecimento sem nenhum interesse e sem nenhuma cobrança e posso dizer que minha carreira de DBA teve muita ajuda dela, então poder devolver um pouco do conhecimento adquirido é uma felicidade enorme. Agradecimento mais que especial para o Gustavo parceiro do blog e por ter palestrado comigo , Edvaldo pelo evento incrível e pela oportunidade de palestrar nele e Renato por ter assistido minha palestra e pelo feedback.

Espero que essa seja a primeira palestra de muitas que estão por vir (realmente espero não parar por aqui), aperfeiçoando cada vez mais a forma de passar o conhecimento.

Enfim, o material estará disponível no site do sql sat em alguns dias.

Seguem algumas fotos do evento para que quem não foi, não perder o próximo!

 

SQL Saturday #573 Brasília!!!!!

sat2

Dia 26 de Novembro de 2016 acontecerá a edição de número 573 do Sat e a terceira que acontece em Brasília. Será um sábado inteiro de palestras e networking, onde você aprenderá muita coisa e vai sair com aquele pensamento e vontade de “tenho que estudar muito, pois não sei de NADA”, mesmo você se achando que é um DBA cabuloso!  E o melhor de tudo que o evento é GRATUITO, 0800, FREE!

O evento será na faculdade Projeção em Taguatinga Norte.

Para mais informações do local, palestras e inscrição acessar o site do evento: http://www.sqlsaturday.com/573/eventhome.aspx ;

Aqui deixo algumas fotos das duas edições anteriores do Sat de Brasília ( #253 e #469) já para ir entrando no ritmo.

fb_img_1475238931463

Sat 253 Brasília – Setembro 2013

fb_img_1475238943359

Sat 253 Brasília – Setembro 2013

 

fb_img_1475239035590

Sat 469 Brasília – Novembro 2015

fb_img_1475239040856

Sat 469 Brasília – Novembro 2015

Segue o link do Post do Gustavo (Autor do Blog Também) falando sua impressão ao ministrar sua primeira palestra em um SAT (tem mais fotos aqui também)! https://comunidadesqlserver.wordpress.com/2015/11/24/sql-family-e-minha-primeira-palestra/

Então não percam tempo, aproveitem esse oportunidade maravilhosa e VAMOS APRENDER!!!!

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/

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