P+R SQL: Backup e configuração
O SQL Server é uma plataforma robusta, mas requer astúcia ao se considerar as configurações do log de transações e outras questões de configuração.
Paul s. Randal
Logs de transações XXXL
P: Nosso produto usa o SQL Server para armazenar dados. Vez com freqüência, podemos lançar uma nova versão do nosso produto inclui um script de atualização para ser executado no banco de dados. Como os nós foram testes nosso script de atualização mais recente em um banco de dados de teste de amostra, o arquivo de log de transações cresceu para mais de 40 GB. Gostaríamos de impedir que o arquivo de log fique tão grande. Quais são as nossas opções? Temos que fique com o modelo de recuperação total para fins de recuperação de desastres.
R: Para começar com, é ótimo que você está testando contra dados representativos do cliente. Muitas vezes, vejo fornecedores de aplicativos em camadas, esses tipos de scripts em pequenos conjuntos de dados de teste e, em seguida, liberando-os a seus clientes, que executam o em todos os tipos de problemas de produção. Como se você for o usuário, irá responder sua pergunta. Em seguida, você pode traduzir no contexto de seus clientes.
Você diz que você precisa manter-se com o modelo de recuperação total. Isso implica estiver levando transação já backups de log e você não tiver problemas gerais com o log de transações em expansão do controle. Isso é bom, tirar backups do log de transação é a única operação que permite que o log de transações limpar assim que se comprometeram a transações. (Para informações detalhadas sobre esse assunto, consulte technet.microsoft.com/magazine/2009.02.logging , que explica como funciona o log de transações e como os diferentes modelos de recuperação de afetam seu comportamento.)
Dito que, a freqüência com que você executar backups de log de transações é uma coisa que determinarão como rapidamente o log de transações pode limpar e não crescer. Por exemplo, se o seu trabalho de backup regular executa um backup do log de transação a cada 30 minutos, o arquivo de log de transações deve ser suficiente para manter a maior quantidade de dados de log de transações que podem ser geradas durante um período de 30 minutos. Caso contrário, ele irá crescer.
Se o script de atualização é executado em 60 minutos, que pode funcionar 20 GB de log de transações gerado a cada 30 minutos, portanto, o arquivo de log de transações terão de ser 20 GB. Que provavelmente ainda é muito grande, portanto, você terá que executar backups de log de transações mais freqüentemente durante a execução do script de atualização. Isso permitirá que o log de transações limpar com mais freqüência e impedir que ele fique tão grande. Nós tinha uma situação semelhante em um local de cliente e acabamos de executando um backup do log de transações uma vez por minuto por várias horas, enquanto um script semelhante foi executado em um banco de dados grande.
Uma coisa em mente é que essas transações “ extra ” efetuar backups fazem parte da cadeia de backup de log e são necessários para recuperação de desastres. Certifique-se de que todos têm nomes significativos e não são excluídos.
Não há outro fator a ser considerado: O que é a única maior de transação ocorre como parte do processo de atualização que você tenha projetado? O log de transações pode desmarcar somente se os registros de log de transações confirmadas (que pode ser um pouco oversimplifying — consulte o artigo supramencionado , para obter mais detalhes). Isso significa que uma transação de execução demorada não permitirá que o log de limpar, mesmo que a transação de efetuar backup faz backup do log de transações gerados.
Se o script de atualização contém uma necessidade de 15 GB de espaço de log de transação, o arquivo de log de transações terão de ser pelo menos 15 GB para manter a transação inteira até que ele confirma. Se for esse o caso, não importando a freqüência de realizar um backup de log de transações não limpe o log de transações. Os únicos recursos nesse caso é dividir a transação de grande em menores, se possível.
Tenha isso em mente: o tamanho do log de transações necessário para executar o script de atualização será determinado, a freqüência dos backups de log de transação e o tamanho da transação de maior único que você criar.
Configuração Conundrum
P: Nós estiver provisionamento algum novo armazenamento com conexão direta para um dos nossos servidores de banco de dados e queremos tornar-se de que compreendemos a todas as nossas opções e obter a configuração correta. Você pode explicar os diversos parâmetros de configuração que deve estar ciente de que diz respeito ao SQL Server?
R: Há inúmeras configurações e opções de configuração ao provisionamento de armazenamento, portanto, eu prefiro envolver um administrador de armazenamento dedicada. Existem, definitivamente, algumas opções com o qual um administrador do SQL Server deve se preocupar e certifique-se de defini-la adequadamente.
A primeira delas é o nível RAID subjacente. Os vários níveis RAID têm diferentes trade-offs que diz respeito desempenho e redundância são. Por exemplo, a configuração de RAID mais barato que ainda oferece algumas redundância é RAID-5, mas essa configuração só pode lidar com uma única unidade de falha (a menos que o uso do RAID-6, ou configurado discos sobressalentes) e algumas vezes podem prejudicar o desempenho para cargas de trabalho pesado de gravação, dependendo de quantas unidades são na matriz.
RAID-10 fornece a melhor redundância, mas é mais cara. A capacidade total da matriz é, no máximo, meia capacidade total das unidades constituintes. Uma boa discussão dos diversos níveis de RAID é apresentada no Apêndice A do TechNet white paper “ do projeto de banco de dados de armazenamento físico. ”
Outros fatores principais a serem considerados são o tamanho de distribuição RAID, o tamanho da unidade de alocação de NTFS (o tamanho de cluster) e o alinhamento da partição de disco. Todos esses fatores podem reduzir drasticamente desempenho se definidos incorretamente. O mais importante é o alinhamento da partição de disco para volumes de discos criados usando o Windows Server 2003. Usa um alinhamento 31,5 KB por padrão, o que não corresponde aos tamanhos de faixas de disco RAID comuns de 64 KB (ou múltiplo dele). Portanto, cada e/S tem, essencialmente ler ou gravar duas faixas RAID para satisfazer a e/S. Obviamente, isso faz enorme degradação no desempenho.
Por padrão, o Windows Server 2008 usa um alinhamento de 1 MB. Todos os volumes criados no Windows Server 2003 e atualizado para hospedar pelo Windows Server 2008 não tem o seu alinhamento alterado, para que eles ainda podem ser afetados. Corrigir o problema significa que os volumes de reformatação, mas os ganhos de desempenho freqüentemente tornam uma etapa valha a pena.
Uma discussão detalhada desses realmente está além do escopo desta coluna, mas há mais detalhes (e links para leituras) na minha postagem de blog, “ tamanhos de distribuição são deslocamentos de sua partição de disco, RAID e unidades de alocação de NTFS definidas corretamente? ”
Qualquer novo armazenamento de provisionamento, é uma boa idéia para teste de carga e teste de desempenho antes de iniciar uma carga de trabalho de produção. Testes de estresse permite afastar os problemas de configuração que poderiam levar a tempo de inatividade ou perda de dados. Requer o ajuda a verificar que o novo armazenamento fornece a capacidade de e/S sua carga de trabalho de teste de desempenho. A Microsoft possui ferramentas gratuitas para ajudá-lo com isso, você poderá aprender mais sobre o white paper “ de de práticas recomendadas de e/S do Pre-Deployment. ”
Espelho, espelho
P: Tenho um pouco sobre a natureza do servidor-testemunha durante a configuração de espelhamento de banco de dados. Poderosas como o servidor-testemunha precisa ser? Ele depende do número de bancos de dados para o qual ele faz o failover? No Centro de dados que você colocar o servidor-testemunha faz diferença? Quero me certificar-se de obter a mais alta disponibilidade para os bancos de dados espelhados.
R: A função de servidor-testemunha é um dos aspectos mais mal compreendidos de qualquer sistema de espelhamento de banco de dados. O servidor-testemunha em uma configuração de espelhamento de banco de dados síncrona existe somente para ajudar a facilitar um failover automático que o servidor principal fica indisponível.
O servidor principal envia continuamente o registros de log de transações para o servidor de espelhamento, nunca o servidor-testemunha. Os servidores principal e espelho de testemunha ping uns aos outros por segundo como parte do mecanismo de detecção automática de falha. Se o servidor de espelhamento determina que ele não pode se comunicar com o servidor principal por qualquer motivo, ele não pode iniciar um failover automático, a menos que o servidor-testemunha concorda que ele também não pode se comunicar com o servidor principal. Se concordar com os dois servidores, o que constitui um quorum e o servidor de espelhamento inicia um failover automático. Se um servidor-testemunha não estiver presente, não pode ser que haja um quorum e um failover automático não é possível.
Dessa forma, o servidor-testemunha existe somente para ajudar a formar um quorum. Ele não iniciar o failover ou reproduzir qualquer parte em que hospeda o banco de dados espelhado. Geralmente o quorum existe entre os servidores principal e espelho.
Assim como o servidor-testemunha não processar como tal, ele não precisa ser um poderoso servidor. Ele pode hospedar qualquer edição do SQL Server, incluindo o SQL Server Express Edition gratuita. Também é sem limite no número de sessões para o qual uma determinada instância do SQL Server pode agir como testemunha o espelhamento de banco de dados.
O servidor-testemunha melhor é colocado em um data center separado dos servidores principal ou espelhamento. No entanto, a maioria das empresas não tem três centros de dados, portanto, a questão é se o servidor-testemunha deve ser colocado com o servidor de espelhamento ou com o servidor principal.
Quando houver apenas dois centros de dados disponíveis, o servidor-testemunha sempre deve ser colocado com o servidor principal. O motivo pelo qual tem a ver com formando um quorum. Se os servidores de testemunha e de espelhamento serão co-localizados e o link de rede cai para o servidor principal, um quorum formarão entre a testemunha e de espelhamento e o servidor de espelhamento iniciará um failover.
O servidor principal, que pode não ter nenhum problema em todas as, terão o banco de dados principal off-line quando ela perde o quorum. Ele supõe que o espelhamento executará failover nesse caso. Para evitar isso, posicionando os servidores principal e de testemunha permite o princípio manter o quorum com a testemunha no caso de uma falha de rede. O banco de dados principal permanece disponível.
O servidor-testemunha é totalmente opcional, porém, não há nenhuma possibilidade de um failover automático — e, portanto, a maior disponibilidade do banco de dados que está sendo espelhado — sem uma. O espelhamento de banco de dados funciona iguais em todas as outras formas. Se um servidor-testemunha é configurado, mas fica indisponível por algum motivo, não há sem perda de funcionalidade, exceto a capacidade de executar um failover automático de espelhamento.
Você também pode ter duas testemunhas para uma sessão de espelhamento de banco de dados. A única maneira de adicionar ainda mais redundância para a função de servidor de testemunha é que a instância do SQL Server de testemunha hospedada em um cluster de failover. Você pode obter mais informações sobre as configurações no TechNet white paper “ espelhamento de banco de dados no SQL Server 2005 . ” o espelhamento de banco de dados
.jpg)
Paul s. Randal é o diretor administrativo da SQLskills.com e MVP do SQL Server de um diretor regional da Microsoft. Ele trabalhou na equipe do mecanismo de armazenamento do SQL Server da Microsoft de 1999 para 2007. Ele 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 é especialista em recuperação de desastre, alta disponibilidade e manutenção de bancos de dados, e participa regularmente de conferências em todo o mundo. Ele bloga em SQLskills.com/blogs/paul e você pode encontrar no Twitter no Twitter.com/PaulRandal.