Como fazer com que o status de execução dos jobs do SQL Server Agent apareça também nos logs do Windows!

Olá pessoal!

 Hoje vou passar uma dica bem simples, vocês sabiam que é possível fazer com que o status da execução de determinado job do SQL Server Agent apareça nos logs do Windows? 

Como?

1. Primeiro criem um JOB qualquer:

2. Criem um STEP para este job com um comando T-SQL qualquer, no meu caso estou usando:

SELECT * FROM SYS.DM_EXEC_REQUESTS


3. Agora cliquem na página Notifications, e ativem a opção Write to the Windows Application Log event log, deixando selecionado When the job succeeds. Cliquem em Ok: 


5. Executem o job:


6. Agora, abram o Event Viewer do Windows, selecionem o Application Log e notem o evento de código 208:


7. O status da execução do job foi registrado no log do Windows! Configuramos para registrar sucesso. Se quiséssemos registrar as falhas, escolheríamos a opção When the job fails, conforme imagem abaixo:


8. Coloquem um “x” no final da query em T-SQL apenas para forçar uma falha no job, executem e agora vejam o que aparece no log do Windows:


9. Para registrarmos ambos, falha ou sucesso, bastaria selecionarmos a opção When the job completes, conforme imagem abaixo:


É isso pessoal! Espero que tenha sido útil. Abraço!

Como instalar o SQL Server 2012/2014 com as últimas atualizações através do Product Updates!


Fala galera tudo certo?

 Bom, já faz um tempo, mas um amigo me questionou se tinha como instalar o SQL Server e já “embutir” na instalação alguma atualização do produto como por exemplo Service Packs, Cumulative Updates, no intuito de ganhar tempo. A resposta para esta pergunta é SIM!

 No SQL Server 2012 foi implementado o Product Updates, ele pode ser considerado uma extensão do slipstreaming, introduzido com o SQL Server 2008 / 2008 R2. Em linhas gerais, o modo avançado do slipstreaming usava um procedimento relativamente complexo para montar uma mídia de instalação com os updates necessários (service pack, updates cumulativos). A mídia gerada com este procedimento precisava ser bastante testada para evitar surpresas indesejadas.

 Com o Product Updates, você inicia o setup do SQL Server via prompt de comando, e com apenas alguns parâmetros faz referência a um diretório ou share com as atualizações necessárias que serão instaladas com a instância. Também é possível usar servidores WSUS ou o Windows Update como fonte para as atualizações. 

 Vou demonstrar o procedimento com uma mídia de instalação do SQL Server 2012.

1. Criei na unidade C: uma pasta chamada sql12updates e dentro dela coloquei o instalador do SP1 e o Cumulative Update 8 pós SP1 do SQL Server 2012:


2. Depois, inseri a mídia de instalação do SQL Server 2012 e abri um prompt de comando rodando como administrador:


3. Com o prompt aberto, naveguei até o drive onde estava a mídia do SQL Server, no meu caso, D:, e digitei os comandos abaixo:

SETUP /ACTION=INSTALL /UPDATESOURCE=C:\SQL12UPDATES


Notem, estou passando um parâmetro chamado UPDATESOURCE, ele é responsável por fazer o setup do SQL Server associar atualizações do produto no processo.

4. No prompt é exibida à confirmação de que os parâmetros foram aceitos, notem na figura a palavra Success:


5. Depois a instalação seguiu normalmente, na tela de Setup Support Rules cliquei em OK:


6.  Escolhi o tipo de licença na etapa Product Key e cliquei em Next:


7. Aceitei os termos na etapa License Terms e cliquei em Next:


8. E na etapa Product Updates, notem que interessante, o SQL listou as atualizações que deixei no diretório referenciado via prompt de comando no passo 3:


 É isso pessoal! Espero que o post tenha sido útil a vocês! Um abraço!

Bibliografia:

Overview of SQL Server Servicing Installation


Product Updates in SQL Server 2012 Installation

Investigando uma queda do contador Page Life Expectancy.


Olá pessoal, tudo certo? Espero que sim!

 Já faz um tempo que montei um rápido post explicando o contador Page Life Expectancy (http://sqlmagu.blogspot.com.br/2013/04/v-behaviorurldefaultvmlo_30.html), bom, apenas para relembrarmos, este contador marca em segundos quanto tempo uma página permaneceu na memória (Buffer Pool) do SQL Server.

 Recentemente, analisando uma coleta do Performance Monitor feita através do SQLdiag das 06h00 às 18h00 de um servidor, me deparei com o seguinte gráfico para este contador:


 Notem a queda aproximadamente às 08 horas, chama bastante atenção não? Mas tem algo nesta imagem que chama mais atenção ainda...descobriram? Vejam que o PLE caiu e não conseguiu mais se reestabelecer. Além disso, várias outras quedas menores foram registradas, precisamos descobrir o que está fazendo estas páginas na memória “girarem” tão rápido que acabaram impedindo o contador de voltar ao seu valor normal. 

 Ao olhar os dados do PerfStats Script no momento da queda (~08h00) não encontrei nada estranho. Porém, olhando 7 minutos à frente, localizei uma procedure que do ínicio até o final de sua execução fez 35.598,398 leituras lógicas, este valor é extremamente alto para uma única request:
 


 Sabendo que uma página que uma request toca é uma leitura lógica, e que uma página no SQL Server possui 8kb, temos que este valor em MBytes corresponde à ~278,112 MBytes, ou ~271 GB.

 O Max Server Memory da instância do SQL Server estava configurado em 6GB conforme abaixo:


 Olhando as próximas quedas do PLE, novamente peguei a mesma procedure rodando e fazendo sempre uma quantidade alta de leituras lógicas. Esta ai nosso problema, com um Buffer Pool limitado em 6 GB e com apenas uma procedure que sozinha manipula uma quantidade de dados ~45x maior que isso é impossível que a expectativa de vida das páginas volte a subir e permaneça em um valor considerado normal para o ambiente.

 É isso pessoal, neste cenário o mais importante não foi olhar a queda e sim o que veio depois dela, daí pra frente partiríamos pra uma análise lógica da procedure etc. Espero que o post tenha sido útil, um abraço pessoal!