Share via

  • Artigo

Perguntas e respostas sobre SQL Verificações de consistência inesperadas, solução de problemas de memória e muito mais

Paul S. Randal

Pobservei algo incomum acontecendo desde que tenha se movido alguns dos nossos bancos de dados para SQL Server 2005. Sempre que o servidor é iniciado, vejo mensagens no log de erro indicando que o SQL Server está executando verificações de consistência no banco de dados como parte do processo de inicialização. Ele faz isso para alguns bancos de dados, mas não para os bancos de dados do sistema. As verificações parecem executar rapidamente não importa quão grande o banco de dados é e ocorrer sempre que o SQL Server é iniciado. Você pode explicar o que está acontecendo?

R muito poucas pessoas tem sido perguntando sobre isso em diversos fóruns on-line. Eis um exemplo de uma das mensagens de log de erro em questão:

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

Ela certamente parecer DBCC CHECKDB (que executa verificações de consistência de todo o banco de dados) foi executada no "mestre"banco de dados, mas, na verdade não era. Esta mensagem está relatando simplesmente uma estatística sobre o banco de dados chamado de "últimos válidas"tempo.

Do SQL Server 2005 em diante, sempre que DBCC CHECKDB terminar verificação de consistência um banco de dados sem encontrar erros de consistência (ou seja, o banco de dados é livre de corrupção), o tempo que DBCC CHECKDB concluída é observado na página de inicialização do banco de dados (uma única página no banco de dados que armazena metadados críticos sobre ele).

Toda vez que um banco de dados for iniciado (no banco de dados ou inicialização de instância anexar), a página de inicialização é verificada para ver se há uma armazenados "última válidas"tempo, e se assim, ele é relatado no log de erros. Infelizmente, não é possível documentada para consultar esse valor, mas você pode usar um número de comandos não documentados para localizá-lo. Sankar Reddy, um MVP, fellow blogged recentemente um script irá relatá-lo para você.

A lógica por trás de armazenar as "últimos válidas"tempo é que pode ser muito úteis em uma situação de recuperação de desastres para saber quanto tempo (potencialmente) um banco de dados pode ter sido corrompido.

Pgostaria de conseguir determinar a quantidade de memóia do SQL Server está sendo usado por cada banco de dados. Percebi que uma instância do SQL Server 2005, de repente, usando praticamente toda a memória disponível no servidor e estou preocupado que há um problema em algum lugar. É possível descobrir onde essa memória está sendo usada de dentro do SQL Server?

RA boa notícia é que isso não é provável que haja um problema. SQL Server 2005 usará o máximo de memória como é possível quando necessário, mas responderá às solicitações de pressão memória do sistema operacional para liberar mais memória. O uso de memória repentino que você está vendo provavelmente é o pool de buffer expandindo para permitir que mais o banco de dados para ser mantidos na memória.

O pool de buffer (às vezes chamado de cache de buffer) é parte da camada de mecanismo de armazenamento no SQL Server e é responsável por gerenciar cópias de memória de partes de arquivos de dados em vários bancos de dados a instância do SQL Server. Se iniciar uma consulta que requer muita de páginas do banco de dados de leitura na memória (por exemplo para uma tabela grande verificação ou uma associação), o pool de buffer pode capturar mais memória do servidor do sistema operacional para que ela pode expanda. Isso permite que ele acomodar as imagens de página extra na memória sem ter necessariamente descartar cópias em memória de outras páginas do banco de dados que estão sendo usadas para outras consultas.

Como um aparte, um dos benefícios da adição de mais memória para o SQL Server usar é que o pool de buffer pode ser maior. Isso significa que mais dados podem ser na memória em um determinado momento, possivelmente levando a E/s reduzida e melhor produtividade de carga de trabalho.

Há outras possíveis causas do SQL Server usando muita memória, para a instância se um grande número de planos de consulta diferentes está sendo armazenados em cache em outra área da memória chamada o cache do plano, mas minha estimativa é que é provavelmente a ser o pool de buffer, conforme descrito anteriormente.

No SQL Server 2005, você pode determinar que proporção de pool de buffer está sendo usada para cada banco de dados usando a exibição de gerenciamento dinâmico sys.dm_os_buffer_descriptors. Essa consulta simples dirá a você quantas páginas de 8 KB são no pool de buffer para cada banco de dados:

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

Explicarei isso um pouco mais na postagem do blog "interna o mecanismo de armazenamento: Novidades no pool do buffer?. "

Para outras seções de memória pelo SQL Server, você pode usar o comando DBCC MEMORYSTATUS para monitorar a quantidade de memória a instância do SQL Server como um todo está usando, mas não permite o uso de memória a ser dividido por banco de dados. Dar uma olhada no artigo do Knowledge Base 907877, que descreve "como usar o comando DBCC MEMORYSTATUS para monitorar o uso de memória no SQL Server 2005."

Pvez com freqüência, um dos bancos de dados em nossa instância do SQL Server 2005 tornará "suspeito". Nós não pode acessar o banco de dados, e seu status é SUSPECT. Ocasionalmente, o status mostra RECOVERY_PENDING. Sei que isso é causado por corrupção de algum tipo, mas você pode explicar o que realmente significa e como recuperar? Nós geralmente acaba tendo que restaurar de backups antigos e perda de dados, que não não ideais.

Rhá muita confusão sobre banco de que esses dois dados estados média, mas você corrigir que eles estão causados por algum tipo de dano. Ambos indicam que algo deu errado com recuperação de falha.

Se um banco de dados não seja corretamente desligado (em outras palavras, se houver transações não confirmadas quando o banco de dados é desligado) e, quando o banco de dados for iniciado novamente, ele deve passar por recuperação de falha. Recuperação de falha é o processo de garantir que todas as transações foram confirmadas no momento do banco de dados desligadom corretamente são refletidas no banco de dados e todas as transações que foram não confirmadas no momento do desligamento não serão refletidas no alguma forma no banco de dados.

Para uma muito mais profunda explicação de como funciona a recuperação, consulte meu artigo sobre "Noções básicas sobre log e recuperação no SQL Server"da edição de fevereiro de 2009.

Um banco de dados sabe se ele foi desligamento correta para baixo ou não — essas informações são armazenadas na página de inicialização de banco de dados, que descrevi na resposta da primeira pergunta. Se a recuperação de falhas for necessária, em seguida, o log de transações deve ser acessível, como ele armazena todos os detalhes dos quais transações (confirmadas) precisará ser repetidos e quais transações (não confirmadas) devem ser revertidas. Se o log de transações não estiver disponível (porque ele foi excluído, por exemplo), recuperação de falha não pode iniciar e o estado do banco de dados torna-se RECOVERY_PENDING. O status RECOVERY_PENDING significa recuperação não pôde ser iniciado.

Se o log de transação estiver disponível, a recuperação de falha começa em execução. Se ele não pode concluir por qualquer motivo, o banco de dados é transacional inconsistente e o status será SUSPECT. O status suspeito significa recuperação iniciado, mas não pôde ser concluída.

Há duas razões não é possível concluir a recuperação. A primeira é a corrupção no log de transações, resultando em um registro de log de transação não pode ser processado pelo SQL Server. O segundo é a corrupção nos arquivos de dados, encontrada enquanto o sistema de recuperação está tentando para aplicar um registro de log de transação para uma página de banco de dados ou para reverter os efeitos de um registro de log de transação em uma página de banco de dados.

Um outro problema pode empurrar um banco de dados em estado suspeito. Se uma transação será cancelada por um usuário ou aplicativo e o banco de dados encontra corrupção ao reverter os efeitos da transação, a reversão não pode concluir e o banco de dados é transacional inconsistente. Nesse caso, o banco de dados é automaticamente colocado offline e o estado definido como SUSPECT.

Há duas maneiras de recuperar nessa situação. A primeira é restaurar a partir de backups atualizados. Se os backups antigos, você provavelmente perder trabalho e dados e deve reavaliar sua estratégia de backup com o objetivo do backup mais freqüentemente para permitir recuperação sem perder uma grande quantidade de dados. Consulte meu artigo "Noções básicas sobre SQL Server Backups"na edição de julho de 2009 da TechNet Magazine para obter algumas dicas sobre como planejar uma estratégia de backup. Se você pretender levar a rota de restauração, você deve tentar sempre um backup de cauda de log, como explicado no artigo, como isso será permitem a você recuperar direita até o ponto do problema que fez o banco de dados SUSPECT.

Se não há backups disponíveis, você pode usar um mecanismo chamado reparo de EMERGÊNCIA modo. Dê uma olhadaminha postagem de blog abrangente que descreve este recurso, explica o uso e mostra alguns exemplos.

Ptemos instalado com o SQL Server 2005 o espelhamento de banco de dados síncrono e nós já ter notado que às vezes, pode levar muito poucos segundos para o banco de dados espelho failover quando algo dá errado com o servidor principal.. Pensei que a espelhamento de banco de dados síncrono usando uma testemunha deveria para fornecer a detecção de falhas instantânea. O que está havendo?

RO uso de um servidor-testemunha com espelhamento de banco de dados simplesmente permite que o servidor de espelho iniciar automaticamente o failover. A testemunha concorda (ou não) com o espelho como se ele pode "ver"o servidor principal. Se a testemunha e o espelho não podem ver a entidade de segurança, o espelho inicia o failover e se torna o novo objeto. A presença de um servidor de testemunha em um banco de dados espelhamento configuração tem não relação com em rápida como uma falha é detectado ou rapidez um failover ocorre.

Detecção de falhas instantâneas é um conceito errado — como rapidamente uma falha for detectada depende do tipo de falha. Estes são alguns exemplos:

  1. Falha da instância do SQL Server (que hospeda o banco de dados principal). Desde que ainda está executando o Windows e apto a responder, a falha deverá ser detectada no máximo um segundo. Cada um segundo, a testemunha e espelho efetuar ping a entidade. Se a instância do SQL Server não estiver escutando a porta TCP que foi configurada, o Windows sabe isso e pode responder imediatamente que SQL Server não está lá.
  2. O servidor principal toda falha. Nesse caso, Windows não é existe dizer que SQL Server não está escutando a porta TCP definida — para nada dizer existe há nada existe. Nesse caso, a falha não será detectada até que o tempo limite de parceiro de espelhamento decorrido. Este é o número de pings de uma vez por segundo que deve não ser respondeu a até que o espelho declara uma falha na parte do principal. Por padrão, esse número é definido para 10 pings (e assim por 10 segundos), mas se ele foi aumentado por qualquer motivo, a detecção de falha levará mais tempo.
  3. Falha de uma unidade de log de transação no principal. Inicialmente, nada acontecerá, exceto que E/s começará a fila para a unidade de log. Após 20 segundos, o SQL Server será impresso um aviso no log de erros. É não até 40 segundos transcorridos que o SQL Server irá declarar a unidade de log off-line ­ e colocar o banco de dados off-line além disso, acionar uma falha de espelhamento.
  4. Uma página de banco de dados torna-se corrompido. Nesse caso, se uma consulta regular atinge a corrupção, nada acontecerá em todos os espelhamento. No entanto, se uma transação está revertendo e encontra a corrupção de página, o banco de dados tornará SUSPECT, como descrito na resposta anterior, e que irá disparar uma falha de espelhamento imediatamente.
  5. Se um arquivo ou grupo de arquivos fica off-line no banco de dados principal e o grupo de arquivos primário não é afetado, em seguida, na Enterprise Edition, disponibilidade parcial do banco de dados irá iniciar e não ocorrerá uma falha. No Standard Edition, no entanto, uma falha será acionada.

Como você pode ver, a velocidade com que uma falha de espelhamento é detectada realmente depende o tipo de falha ocorre e se o tempo limite de parceiro de espelhamento ocorreu.

Muitos graças ao Kimberly l. Tripp de SQLskills.com para tecnicamente revisão deste mês é coluna.

Paul S.Randal é o diretor de gerenciamento de SQLskills.com e MVP do SQL Server e um diretor regional da Microsoft. Ele trabalhou na equipe o mecanismo de armazenamento do SQL Server da Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Randal é um especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e é apresentador regular em conferências em todo o mundo. Ele bloga em do SQLskills.com/blogs/paul e você pode encontrá-lo em Twitter em do Twitter.com/PaulRandal.