Falha ao reciclar o ERRORLOG!


Fala pessoal tranquilo? Espero que sim!

Hoje vou falar sobre um problema que enfrentei recentemente ao fazer a reciclagem do ERRORLOG, bom, acredito que a maioria conhece o comando abaixo:

SP_CYCLE_ERRORLOG

Este comando fecha o arquivo de log atual do SQL Server e inicia um novo, é o mesmo que acontece quando o serviço do SQL Server é iniciado.


Existe um outro comando não documentado que tem o mesmo objetivo:

DBCC ERRORLOG

Agora vamos ao problema. Certo dia acessei um servidor e o log do SQL Server estava demasiadamente grande, resolvi então reciclar o mesmo. Porém quando pedi para ler a log atual veja que interessante, encontrei datas e horários misturados, basicamente datas recentes no início e antigas do meio pra frente:

2014-02-04 11:11:24.28 Backup
2014-02-04 11:11:25.53 Backup
2014-02-04 11:11:26.08 Backup
2014-02-04 11:11:27.08 Backup
2014-02-04 11:11:31.53 Backup
2014-02-04 11:30:09.87 spid77
2013-07-03 06:07:57.78 spid74
2013-07-03 06:18:20.60 spid74
2013-07-03 06:23:11.86 spid74
2013-07-03 06:41:46.56 spid73
2013-07-03 06:41:46.58 Backup

Estranho, não? Alguma coisa deu errado no processo de limpeza da log e inicialização de um novo, resolvi então olhar o EVENT VIEWER na parte de Application e notem o erro que encontrei:

 
O erro já nos remete à conclusão de que algo está impedindo o SQL Server de manipular o arquivo. Resolvi repetir o procedimento porém desta vez deixei a ferramenta da Sysinternals chamada Process Monitor ativa, filtrando o Process Name em cima do binário do SQL Server chamado sqlservr.exe. Rodei o comando e veja só o que foi registrado:

 
Obs.: Apaguei o começo do diretório por questões de segurança.

Na coluna Result aparece SHARING VIOLATION, basicamente, isto indica que à operação desejada não pode ser feita no arquivo pois o mesmo estava sendo utilizado por alguma outra coisa no Windows, interessante. Com esta informação, usei outra ferramenta da Sysinternals, o Process Explorer, fui até a aba Find, depois Find Handle or DLL substring e digitei errorlog, vejam os resultados:


Obs.: Apaguei o começo dos diretórios e uma das linhas por questões de segurança.

Notem o binário koqerr.exe, com uma rápida pesquisa notei que ele corresponde à ferramenta de monitoração da IBM chamada IBM Tivoli Monitoring. Agora o próximo passo para resolver o problema já estava mais claro, parei os serviços do agente de monitoração, garanti que seus binários não estavam mais executando e tentei novamente limpar a log, vejam agora o diretório do ERRORLOG:


Sucesso! Um novo arquivo de log foi criado!

Link para download das ferramentas que foram utilizadas neste post:

PROCESS MONITOR 3.1

PROCESS EXPLORER 16.02

Por hoje é só pessoal, espero que o post tenha sido útil a vocês! Um abraço!

SQL Server 2012 SP2 e SQL Server 2014 Cumulative Update 1!

Olá pessoal, tudo certo? Espero que sim!

 A Microsoft liberou no dia 10/06 o Service Pack 2 para o SQL Server 2012, link oficial para download:

http://www.microsoft.com/en-us/download/details.aspx?id=43340

 Também foi liberado recentemente, em 21/04, o Cumulative Update 1 para o SQL Server 2014 RTM, link oficial para download:

http://support.microsoft.com/kb/2931693

 Espero que tenha sido útil!

Um abraço e até a próxima!

Granulando o acesso ao SQL Server Agent!


Olá pessoal! Tudo certo? Espero que sim!

Hoje vou falar de algo que surgiu no SQL Server 2005, as regras de controle de acesso ao SQL Server Agent implementadas na base de dados MSDB, estas permitiram aos administradores um controle maior sobre quem pode visualizar os jobs, seus logs, executá-los etc.

Na prática...

1. Com um usuário sysadmin, criem um novo login chamado loginteste e não deem nenhuma permissão para ele, criem também um job qualquer com uma step que contenha alguma comando simples em T-SQL, chamem este job de TESTE_JOB. Acessem o SQL Server com este novo login e notem que o SQL Server Agent no Management Studio nem aparece:

2. Novamente com um usuário sysadmin entrem nas propriedades do login que criamos e agora, em User Mapping, selecionem a base de dados MSDB e na lista das roles da base, selecionem uma chamada SQLAgentReaderRole:

3. Agora, voltem a se logar na instância com o login loginteste, notem que agora o SQL Server Agent já aparece:

4. Se tentarem ver o histórico do job também será possível:

5. Agora, se vocês entrarem dentro do job e tentarem editar as steps existentes, notem que os botões para isso vão estar desativados com exceção do de visualização:

6. Se vocês tentarem executar o job, também não será possível:

7. Clicando na mensagem de erro em azul temos o seguinte:

8. Antes de falarmos em como fazer para que nosso usuário além de visualizar informações de determinado job consiga também executá-lo, voltem ao mapeamento de permissões dele e notem que a permissão SQLAgentUserRole foi marcada automaticamente:  

Mas por qual razão? Bom, a SQLAgentUserRole é a permissão mais fraca dentre as três existentes, desta forma, membros das outras permissões são automaticamente membros dela.

9. Finalmente vamos fazer com que nosso usuário consiga também executar os jobs. Entrem novamente com um usuário que seja sysadmin na instância, depois, nas propriedades do nosso login de teste, em User Mapping, selecionem a role SQLAgentOperatorRole

10. Agora, novamente com o login de teste que criamos executem o job e vejam que desta vez será possível:

11. É isso pessoal, isto pode ser muito útil quando vocês quiserem granular o acesso de alguém ao SQL Server Agent!  Espero ter ajudado de alguma forma! Um abraço!

Links de referência: