P+R SQL Problemas de soma de verificação, escolher o modelo de recuperação correto e mais
Paul S. Randal
QEu sou um administrador do SharePoint e você recentemente, descobri que um dos meus bancos de dados conteúdos ficou corrompido quando meu consistência mensal verifica erros encontrados. Nós rastreado ele volta para um controlador RAID defeituoso e, depois de fazer algumas pesquisas, estão ativados somas de verificação nas páginas do banco de dados. Minha pergunta é: como saber quando há um problema de soma de verificação sem esperar até o plano de manutenção mensais?
AExistem algumas coisas que você pode fazer. Primeiro, você pode adicionar a opção WITH CHECKSUM para seus backups. Para backups normal e diferenciais, essa opção fará com que a operação de backup testar as somas de verificação ele vê e falhar com um erro se ele encontrar uma corrupção. (Abordei isso em mais detalhes no artigo do mês passado, "Noções básicas sobre backups do Server SQL".)
Em segundo lugar, considere executar as verificações de consistência com mais freqüência do que mensal. É recomendável executando alguma forma de verificação de consistência pelo menos semanalmente, se é um DBCC CHECKDB no banco de dados ou talvez em uma cópia do banco de dados restaurada. Que, claro, será depende de seu nível de conforto com seu subsistema de E/s.
Em terceiro lugar, adicione alguns alertas do SQL Agent. É possível definir um alerta seja disparado em uma variedade de fatores, tais como um número de erro específica que está sendo gerado pelo SQL Server, um erro com uma gravidade específica que está sendo gerado ou um contador de desempenho cruzando um limite. Esse recurso fornece um mecanismo realmente poderoso para monitorar problemas no servidor.
Quando um alerta é acionado, uma mensagem é enviada para um "operador" predefinido usando uma ou todas essas opções: uma mensagem de pager, email ou NET SEND. Você pode usar o procedimento armazenado sp_add_notification para definir um operador.
Como diz respeito problemas de subsistema de E/s, os erros que você estiver interessado em são 825, 823 e 824. As duas primeiras são disparadas quando ocorre um problema de E/s (especificamente, 824 é quando uma soma de verificação página encontra-se para ser interrompida e 825 ao SQL Server tem que tentar uma operação de leitura várias vezes antes que ela conclua). Esses são todos os problemas que você deseja saber sobre assim que possível para limitar ainda mais danos para o banco de dados (e possivelmente a quantidade de tempo de inatividade para recuperar).
823 e 824 são ambos os erros de 24 de nível de gravidade mas 825 é apenas um nível de gravidade 10 "" mensagem informativa (para obter mais informações, consulte meu blog lançar " Um sinal de pouco conhecido de doom iminente: erro 825.") Para alertar para esses erros, você deve definir um alerta para todos os erros de 24 de nível de gravidade e especificamente para erro 825 (na verdade, ele é uma prática recomendada ter um alerta para cada-nível de gravidade de 19 a 25).
Para definir os alertas reais, você pode usar T-SQL ou Management Studio. Abaixo é um exemplo de código T-SQL para adicionar um alerta para o erro 825.
USE msdb;
GO
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required',
@message_id = 825,
@severity = 0,
@enabled = 1,
@delay_between_responses = 0,
@include_event_description_in = 1,
@category_name = N'IO Subsystem Error';
GO
Você pode encontrar mais informações sobre definir e adicionar alertas, incluindo um treinamento passo a passo sobre como adicionar alertas usando o Management Studio, no meu blog SQL Agent categoria "( Bug de plano de manutenção SQL 2005 SP2 mascaramento corrupção)."
QEu sou um desenvolvedor-DBA quem é responsável por algum código e o banco de dados que é executado. Eu tiver sido argumentando com alguns outros desenvolvedores de banco de dados sobre como obter um valor exclusivo para identificar linhas da tabela. Gostaria de usar um GUID como a chave de índice de cluster, mas as outras são argumentando que ele pode levar a problemas de desempenho com índices. É essa true e, em caso afirmativo, você pode explicar por quê?
UM Sim, é verdade — GUIDs são uma das causas à esquerda de fragmentação de índice nos bancos de dados SQL Server.
Um GUID é um identificador global exclusivo. No SQL Server, esse é um valor 16 bytes que é gerado no SQL Server ou em algum outro lugar (como por meio do .NET no cliente- ou mid-tier). GUIDs geralmente tem um valor aleatório, a menos que gerado com a função NEWSEQUENTIALID introduzida no SQL Server 2005.
Esta função produz intervalos de GUIDs, que podem ajudar a aliviar alguns dos problemas que descreverei aqui. Mas isso exige gerar um GUID no lado do servidor, que não funciona em vários ambientes de aplicativos porque o identificador exclusivo deve ser gerado antes dos dados são enviados para baixo para a camada de dados.
Não importa onde o GUID não seqüencial é gerado, fazendo com que como a chave à esquerda em um índice significa que, porque a chave é essencialmente aleatória, o ponto de inserção de um novo registro no índice também é aleatório — o valor de chave de um registro determina o posicionamento no índice. Isso também significa que o GUID de 16 bits estarão presente em cada linha de cada índice não agrupado como parte do link que permite que o mecanismo de armazenamento navegar de registros de índice não agrupado para registros de índice de cluster para obter valores de coluna para a lista de consulta seleção que não estão no índice não agrupado que foi usado (também normalmente conhecido como uma pesquisa de indicador).
Como mais registros são inseridos no índice, as páginas de armazenar os registros preencher. Se um registro está sendo inserido em uma página que já está completa (Lembre-se de que o valor da chave determina onde vai o novo registro), em seguida, a página deve dividir, com alguns registros mover para uma página recém-alocada. Uma divisão da página é uma operação cara para executar (uma nova página é alocada e vinculada ao índice e registros são movidos para a nova página), e faz com que a fragmentação.
Divisões de página causar fragmentação lógica no índice (que afeta o desempenho de verificação de intervalo) fazendo com que a ordem física e lógica de páginas no índice seja diferente. Ela também faz com que página baixa densidade (onde não há espaço não utilizado em páginas), que leva para o espaço desperdiçado em páginas e utilização de disco, E/s e memória baixa.
Para obter mais informações sobre como detectar e removê-lo e fragmentação do índice, consulte meu artigo de agosto de 2008 " Principais dicas para uma manutenção de banco de dados eficiente." Uma chave de índice de cluster boa de separação é além do escopo deste artigo; deixarei para minha esposa, Kimberly l. Tripp, para explicar. Consulte seu excelente postagem no blog o tópico, que também entra em mais detalhes sobre GUIDs e estruturas de índice de cluster "(sobre GUIDs como chaves PRIMÁRIAS e/ou a chave de cluster.")
QNossa estratégia de alta disponibilidade é usar o envio de log para alguns servidores secundários. Nossa equipe de gerenciamento é pressuring me para fazer algumas uso dos servidores redundantes para salvar em maiúscula gastos. Minha idéia é usar os servidores secundários para permitir o relatório de consultas a serem executadas, que também teria o benefício de descarregamento a carga de trabalho relatório do servidor primário. Que problemas pode executar para fazer isso?
UM Esse tipo de cenário está se tornando muito mais comum na clima econômica atual, onde as empresas não deseja ter servidores sentado ao redor que parecem estar ocioso (mesmo que eles está fornecendo uma cópia redundante dos banco de dados).
Como provavelmente já sabe, quando você configurar o envio de log, você pode definir como os backups de log de transação são restaurados em um servidor secundário — o WITH NORECOVERY ou WITH STANDBY. O primeiro não permite qualquer acesso o banco de dados, ao passo que o último permite acesso somente leitura para o banco de dados. Ele utiliza um modo especial onde execuções de recuperação e o banco de dados é transacionalmente consistente, mas as operações executadas são armazenadas em um arquivo separado de desfazer para que mais backups do log de transações podem ser restaurados (abordarei isso mais detalhadamente próximo mês em um artigo sobre como usar RESTORE).
Para permitir que o relatório sobre o servidor secundário, você vai usar WITH STANDBY para que as consultas de relatórios podem se conectar ao banco de dados. Uma vez você permite conexões de usuário, você imediatamente executar backup alguns problemas.
Primeiro, usando a opção WITH STANDBY pode levar a backups de log de transações seeming levar um tempo longo para restaurar em um servidor secundário, como o conteúdo do arquivo desfazer deve ser repetido antes do próximo backup de log de transação pode ser restaurado. Isso pode ser um problema se o arquivo de desfazer contiver um grande número de operações.
Em segundo lugar, a restauração de um backup do log de transações não é uma operação online. Ninguém pode ser conectada ao banco de dados para a duração da restauração. Isso significa que todas as conexões ao servidor secundário relatório devem ser descartadas, reconectadas após a restauração. Aqui você tem um dilema: quando é hora de restaurar o próximo backup de log de transação, você encerrar conexões de usuário ou permitir que eles concluir suas consultas? Isso é completamente até você.
Uma pergunta para ter em mente se você não decidir encerrar conexões: como tempo você permitir as consultas continuar antes de você forçosamente encerrar? Quanto mais tempo você esperar, mais ela está desde o último backup de log foi restaurado e behind ainda mais o banco de dados que secundário primário obtém. Isso pode ser um problema se você, em seguida, tem failover para o secundário, porque pode haver uma fila de backups de log aguardando para ser restaurado para colocar o banco de dados como muito atualizado quanto possível, minimizando a perda de dados.
Você pode encontrar mais informações sobre essas opções, bem como sobre o monitoramento problemas como o período de tempo desde a última restauração de backup log no servidor secundário, manuais online do tópico " Usando servidores secundários para processamento de consulta."
QComo posso escolher o modelo de recuperação correto? De que li, parece deve ser usando registradas em massa para reduzir o tamanho do log meu transação, mas parece que o tamanho do meu log mantém crescendo. É possível usar um modo que não usar o log de transações e evitar completamente o problema todo?
UM m das solicitações que já ouvi falar várias vezes é para um banco de dados não-conectado, quando nenhum registro de log de transação é gerado em todos os — especialmente para tempdb, que pessoas modo de exibição como um banco de dados transitório porque ele é recriado na inicialização do servidor.
Quanto eu sei, isso nunca acontecerá para o SQL Server. O melhor que você obterá é o modo BULK_LOGGED, que drasticamente cortes para baixo a quantidade de log de transações gerados para determinadas operações (como indexar recria e em massa carrega). Todos os bancos de dados, até mesmo tempdb, devem ter algum nível de log para permitir transações reverter (ou seja, para desfazer todas as operações que fazem parte da transação) no caso de um usuário cancelar a operação ou algum erro fazendo com que a operação falha.
O que é mais importante para bancos de dados além de tempdb, é que se ocorrer uma falha do sistema, o banco de dados deve ser capaz de recuperar sem deixar dados inconsistentes transacional ou uma estruturalmente inconsistente (isto é, danificar) banco de dados. Imagine se não havia nenhum registro de que tinha sido alteração no banco de dados antes da falha — como o SQL Server deve executar recuperação? Você pode ler mais sobre como recuperação de log e funcionam no meu artigo de fevereiro de 2009 " Noções básicas sobre log e recuperação no SQL Server."
Para escolher um modelo de recuperação, uma pergunta substituição irá determinar sua escolha: você deseja ser capaz de fazer o "ponto-in-time" ou "atualizadas" recuperação em caso de desastre? Em caso afirmativo, você vai usar o modelo de recuperação FULL (e possivelmente o modelo _LOGGED BULK) ocasionalmente. Se você não estiver interessado em fazer isso, use o modelo de recuperação simples.
O motivo para usar SIMPLE em vez de FULL se você quiser ser capaz de recuperar o banco de dados (sem perda de trabalho desde o último banco de dados ou backup diferencial) é que com o modelo de recuperação simples, você não precisa fazer backups de log para gerenciar o tamanho do log de transação de transação.
Agora, pode haver outros motivos por que você precise usar o modelo de recuperação total — por exemplo, se você desejar usar espelhamento (DBM somente suporta o modelo de recuperação FULL) do banco de dados ou envio (log remessa suporta tanto os FULL e BULK_LOGGED modelos de recuperação) de log. Em ambos os casos, você vai ter para garantir que você estiver levando transação backups de log para que o log não crescer muito grande (mesmo se você apenas descartando-los).
Eu mencionei que você pode ocasionalmente deseja usar o modelo de recuperação BULK_LOGGED, em vez de constantemente executar nesse modo. Isso ocorre porque existem algumas limitações em torno fazer e restauração de backups log quando foi uma operação registrado minimamente no modelo de recuperação BULK_LOGGED desde o último backup de log de transação. Os detalhes são muito complexas para explicar nesta coluna, mas você pode descobrir mais sobre isso e sobre como escolher um modelo de recuperação em geral, no tópico Books Online " Visão geral do modelo de recuperação."
Paul S. Randal é diretor da SQLskills.com, diretor regional da Microsoft e um MVP do SQL Server. 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. Paul é 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. Blogs de he no SQLskills.com/blogs/paul, e ele pode ser encontrado em Twitter no Twitter.com/PaulRandal.