Alterando parâmetros de startup inseridos incorretamente em um cluster SQL Server 2000 ou 2005.


 Se a edição dos parâmetros de startup impedir uma instância do SQL Server de localizar os arquivos que compõe o master / model / tempdb ela não inicia, seja stand-alone ou em cluster. Em uma instância SQL Server stand-alone não teríamos grandes problemas em acertar os parâmetros, contudo em uma instância cluster o acerto não é muito simples de se fazer devido a um processo do cluster conhecido como registry checkpoint.

 O registry checkpoint serve para garantir que determinadas chaves usadas por um recurso do cluster estejam sempre em sincronia entre todos nós do mesmo.  A indicação das chaves a serem protegidas por este processo parte dos próprios recursos durante o setup.  

 Uma característica do registry checkpoint é que uma nova marca de verificação somente pode ser criada nas chaves protegidas quando o respectivo recurso do cluster está no ar. Se você editar os parâmetros de startup, e esta edição impede a instância de iniciar, qualquer tentativa de editar diretamente as chaves protegidas do registry irá falhar, porque os valores utilizados são obtidos da última marca gerada quando a instância estava online, não importa que estes valores estão incorretos.

Simulando o problema 

 No meu exemplo abaixo, perceba que logo após o caminho que aponta o arquivo “ldf” da base de dados de sistema “master" eu inseri propositalmente um “trace flag” sem utilizar o divisor “;”: 
 Veja o que acontece quando eu tento subir o serviço do SQL Server:
Olhando no ERRORLOG:
 Ah ok! O SQL Server não está conseguindo abrir o arquivo “ldf” da “master” chamado “master.ldf-T1118, realmente o arquivo não tem este nome, vamos tentar corrigir então? Entrando no Configuration manager eu vou inserir o divisor “;” entre o arquivo da “master" o “trace flag”: 
 
 Ok, isto para uma instalação “stand-alone” resolveria, contudo no cluster, abrindo o ERRORLOG veja que interessante, nós mudamos no “Configuration manager” porém ele continua registrando a mesma coisa de antes:
 Vamos voltar ao “Configuration manager”, ao verificar como estão os parâmetros veja que estranho, o que nós havíamos alterado ele desconsiderou e manteve o que estava antes: 
  

Resolvendo o problema 

Bom para resolver este problema, nós temos que desproteger uma chave no “registry” através do comando que estou passando abaixo. Rode o mesmo a partir de um prompt elevado: 

cluster res "SQL Server (Instancename)" /removecheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER"

  Se o procedimento for bem sucedido você verá a seguinte mensagem: 

Repita agora o procedimento de correção dos parâmetros de inicialização no “Configuration Manager” e tente agora subir o serviço do SQL Server...

Pronto! O serviço voltou a funcionar! Agora vamos proteger o registry novamente com o seguinte comando: 

cluster res "SQL Server (Instancename)" /addcheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLSERVER"
 Se o procedimento for bem sucedido você verá a seguinte mensagem:
 Neste post simulei o problema e mostrei os procedimentos de correção para uma instância cluster do SQL Server 2005, consulte o link oficial abaixo sobre o problema para realizar os procedimentos para instâncias default do SQL Server 2005 e para instalações do SQL Server 2000: 


SQL SERVER 2008 e posteriores. 

No SQL Server 2008 e versões posteriores o checkpoint é feito no nível do network name, isto significa que se o problema ocorrer a correção pode ser feita sem desproteger as chaves do registry. O artigo abaixo contém algumas considerações adicionais para o SQL Server 2008 / 2008 R2: 


Para dificultar a introdução de erros nos parâmetros de startup, o SQL Server 2012 trouxe de volta um artifício parecido com o do Enterprise Manager do SQL Server 2000, no SQL Configuration Manager existe uma aba que permite que os parâmetros sejam inseridos um por vez, e não mais editados numa única linha, como era feito desde o SQL Server 2005:
 
Espero que o post tenha sido útil a vocês!
Um abraço!

SQL Server 2005: Falha do serviço do SQL Server Full Text Search em um cluster com Windows Server 2008 R2


Olá pessoal tranquilo?

 Hoje irei comentar sobre um erro no serviço do “SQL Server Full Text Search” do SQL Server 2005 em um ambiente cluster com Windows Server 2008 R2.

 Durante a instalação de um cluster SQL Server 2005 em um Windows Server 2008 R2 você pode ter problemas para iniciar o serviço do “SQL Server Full Text Search”, no Event Viewer você irá ver a seguinte mensagem ao tentar subir o serviço:

 The SQL Server FullText Search (MSSQLSERVER) service depends the following service: NTLMSSP. This service might not be installed.



 Bom, existem duas formas de se corrigir este problema, recomendo a primeira delas que é a aplicação do Service Pack 2 e posteriores do SQL Server 2005. A segunda forma é um procedimento no registry, você deve fazê-lo por sua conta e risco, segue abaixo as etapas:

1. Iniciar.

2. Executar.

3. Regedit.

4. Navegue até a chave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msftesql$???
Obs: A parte em amarelo será o nome da sua instância.

5. Clique duas vezes na chave “DependOnService”, você irá ver dois valores, RPCSS e NTLMSSP, remova o valor “NTLMSSP”, faça o procedimento em todos nós do cluster. Recomendo que você reinicie o servidor após editar o registry.

6. Após isto você deverá ser capaz de iniciar o serviço.

 Valeu pessoal espero que tenha sido útil! Peço desculpas por estar meio ausente pois estou trabalhando em alguns projetos do SQL Server 2014! Logo irei postar novidades sobre o mesmo!

 Um abraço!

Books Online - SQL Server 2014!

Boa noite pessoal tudo certo?

Estou preparando um post sobre o SQL Server 2014 por isso não tenho atualizado o meu blog na frequência usual, contudo, acredito ser interessante divulgar com vocês o link para acesso do Books Online desta nova versão do produto! Segue abaixo:

http://msdn.microsoft.com/en-us/library/ms130214%28v=sql.120%29.aspx

Um abraço!

Muitos VLF’s podem degradar a performance da sua instância do SQL Server!


Olá pessoal tudo certo? Espero que sim!

Hoje irei falar sobre um assunto já bastante discutido entre a comunidade relacionado a perda de performance no ambiente devido a uma grande quantidade de VLF’s (Virtual Log Files) no log de transações das bases de dados.

O Engine do SQL Server divide cada arquivo físico de log internamente em um determinado número de VLF’s. Estes não possuem um tamanho fixo nem uma quantidade padrão para cada arquivo físico de log. O engine escolhe dinamicamente o tamanho dos VLF’s quando o arquivo de log é criado ou passa por uma expansão.

Se as configurações de auto-growth dos arquivos de log não estiverem bem definidas, você irá ter o log de transações com uma quantidade muito grande de VLFs e que irá ficar fragmentado com uma frequência maior, o que pode ser extremamente prejudicial à performance do processo de recovery e atividades relacionadas à replicação.

Primeiramente, vamos entender como são adicionados os VLF’s que passam por uma expansão, usando como referência o post da Kimberly Tripp (SQL Skills):

Expansões menores que 64MB e até 64MB = 4 VLFs serão adicionados.
Expansões maiores que 64MB e até 1GB = 8 VLFs serão adicionados.
Expansões maiores que 1GB = 16 VLFs serão adicionados.

Agora, vamos listar o que muitos VLF’s em um arquivo de log podem vir a causar:

1 – Lentidão no backup do transaction log: No processo de backup todos VLF’s presentes no log serão lidos antes da operação iniciar.

2  - Lentidão no processo de recovery da base de dados: Na primeira fase do processo de recovery das bases de dados chamada de Discovery, todos os VLF’s nas logs serão lidos e uma lista deles será montada para que a operação se inicie, muitos VLF’s podem vir a prejudicar a performance desta operação. Veja mais informações sobre nos links abaixo:



3 – Lentidão em uma replicação transacional: O log reader realiza a leitura dos arquivos de log varrendo os VLF’s, logo muitos VLF’s podem onerar o processo e prejudicar a replicação dos dados como um todo.

4 – Lentidão nas operações de insert/update/delete: Recomendo a vocês a realizar o teste proposto pelo Linchi no site abaixo para evidenciarem o problema neste caso:
  

Portanto, a recomendação é que você mantenha os seus logs sempre com uma quantidade de VLF’s razoável. Você pode verificar a quantidade de VLF’s de um banco de dados através do comando DBCC LOGINFO. Se você já possui o log de transações com muitos VLF’s e deseja reduzir a quantidade dos mesmos, você deve fazer o shrink do arquivo com o log de transações, e expandi-lo numa única operação para o tamanho desejado / necessário para suportar a carga de trabalho.
 
Outros links utilizados de referência para escrita deste post: