SQL Q & A: Mantenha seus dados gerenciáveis

  • Artigo

Neste mês, nosso colunista do SQL Server ajuda os leitores a analisar dados discrepantes, desenvolver estratégias e gerenciar dados com grupos de arquivos.

Paul S. Randal

Números não mentem

**P.**Estou tentando medir a latência de I/O de alguns dos nossos bancos de dados e estou recebendo resultados diferentes de exibições de gerenciamento dinâmico (DMVs) e os contadores do Monitor de desempenho. Você pode explicar por que esses números não são o mesmo?

. Esses dois métodos usam o DM io_virtual_file_stats DMV (ver meu blog post para obter mais informações sobre como usar o que) e o AVG. Disk sec/Read e AVG. Contadores de disco s/gravação no objeto de disco físico no Monitor de desempenho. É perfeitamente possível que você poderá ver resultados diferentes entre os dois mecanismos.

O DMV mede a leitura cumulativa e gravação tenda tempo ou latência. Ele faz isso para cada arquivo em cada banco de dados, uma vez que o banco de dados foi colocado on-line (geralmente desde a última reinicialização da instância do SQL Server ). Dividir esses totais pelo número de leituras e gravações para obter a média de leitura e gravação de I/O tempos de latência. Estas médias são durante todo o período de tempo de quando você primeiro consultado o Detran para quando esse banco de dados em questão foi colocado on-line.

Os contadores do Monitor de desempenho são uma média ao longo de um período menor de tempo. Esses dois posts do blog grande, "Windows Performance Monitor explicou contadores de disco," e "latência de medição de disco com o Windows Performance Monitor (Perfmon)," pelo Windows Server Core team explicar mais detalhadamente. Você começa o que equivale a uma visão instantânea do disco ler e escreve as latências. Como você pode ver, esses dois métodos de medição de latência são bem diferentes, o que pode levar a resultados diferentes.

O Detran só mede a latência de arquivos de banco de dados do SQL Server . O Monitor de desempenho é medir todas as e/SS nesse volume. Em um ambiente de armazenamento compartilhado, isso poderia significar muitas outras não - contribuindo para i / o de arquivos doSQL Server carregar no volume. Isso poderia fazer a média baixa quanto à Performance Monitor é medindo-se lotes de e/s através de lotes de arquivos. A média de DMV poderia ser maior, porque ele está medindo menos e/s em arquivos menos.

Pelas mesmas razões, poderia haver mau desempenho há algum tempo no volume, mas nenhum SQL Server e/SS no processo. Os contadores do Monitor de desempenho que refletem o desempenho. Como o DMV é apenas medindo SQL Server e/SS, os resultados DMV não são afetados por esse período de fraco desempenho.

Lembre-se também que o Detran recolhe dados agregados. Se houver um período de pobre desempenho com apenas SQL Server saídas que ocorrem, os resultados DMV serão afetados pelo desempenho insatisfatório e/SS, mesmo depois que o desempenho melhora novamente. Os contadores do Monitor de desempenho refletirá as latências altas durante o período de mau desempenho e, em seguida, baixas latências quando melhora o desempenho.

Como você pode ver, para dar sentido as valores diferentes, você precisa considerar o que eles realmente estão medindo. Infelizmente, não há nenhuma maneira de repor os contadores DMV sem momentaneamente colocar o banco de dados desejado off-line.

HA e todos

**P.**Fui convidada para trabalhar em uma nova estratégia de alta disponibilidade (HA) para nossos servidores SQL. Estou procurando alguma orientação do que considerar e onde começar. Você pode oferecer algum Conselho?

**.**Um problema é descobrir qual HA tecnologia para usar quando estiver criando sua estratégia. Muitas vezes, uma empresa vai com a tecnologia compete apenas porque ele já está em vigor. Pior, a empresa pode fazer uma escolha arbitrária de tecnologia na ausência de exigências claras.

Para projetar a estratégia correta de HA, você deve recolher e analisar suas necessidades. Sem este passo crítico, você não tem nenhuma esperança de satisfazer os requisitos de negócio com sua estratégia. Para cada porção de dados à qual se aplicará a estratégia HA, você precisa de respostas às seguintes perguntas:

  1. Quão importante são este dados em relação a tudo o resto? Afirmar que tudo é prioridade e deve ser protegido igualmente trabalha com uma pequena quantidade de dados, mas torna-se cada vez mais impraticável com vários terabytes, espalhadas em várias instâncias do SQL Server .
  2. A quantidade de dados a empresa pode perder? Empresários compreensivelmente gostaria de ver a perda de dados.
  3. Quanto tempo podem ficar indisponíveis dados? Empresários também gostam de ver zero downtime. Embora você pode chegar perto, infelizmente não é possível na realidade.
  4. Fazer itens no. 1 ou não. 2 alterar em vários momentos do dia ou durante o fim de semana? Isso pode ter um profundo efeito sobre sua capacidade de atender requisitos. Zero tempo de inatividade e perda de dados são muito mais viável por um período limitado — digamos, 09 para 17 durante a semana — em comparação com 24 x 365.
  5. É aceitável a comprometer o desempenho da carga de trabalho para preservar a durabilidade e disponibilidade de dados? As tecnologias únicas que podem proporcionar a perda de dados requerem espelhamento síncrono de registros de log de transação (espelhamento de banco de dados ou grupos de disponibilidade do SQL Server 2012) ou gravações de subsistema de I/O (replicação de SAN). Esses dois podem levar a um atraso de processamento, mas é um trade-off.
  6. A cópia secundária dos dados tem que ser legível ou gravável?

Uma vez que você se depara com esses requisitos, você pode trabalhar através das limitações impostas pelo negócio e, em seguida, comprometer. É importante perceber as limitações que você está trabalhando dentro podem significar que você não pode atender todos os requisitos. Nesse caso, você e os gerentes de negócios terá que aceitar um compromisso. Caso contrário qualquer estratégia HA que você design não vai atender às expectativas. É mais provável que sua solução vai ser composta de várias tecnologias, sabendo assim as limitações de cada um, bem como a forma como eles trabalham juntos, será fundamentais para seu sucesso.

Você pode enfrentar qualquer um das seguintes limitações:

  • Orçamento
  • Energia elétrica disponível
  • Espaço físico para novos servidores, racks e equipamentos de ar condicionado
  • Pessoal — há ninguém disponível para gerenciar os sistemas de novos, ou ninguém atualmente tem as habilidades para implementar e gerenciar as novas tecnologias necessárias

Há descrições detalhadas das tecnologias e exemplos estratégicos nestes dois white papers:

Embora esses informes foram escritos para SQL Server 2008/2008 R2, tudo neles ainda se aplica. Confira também o white paper, "Guia de arquitetura de AlwaysOn: Construção de uma alta disponibilidade e solução de recuperação de desastres por grupos de disponibilidade de AlwaysOn utilizando, "para as mais recentes tecnologias de SQL Server 2012.

Grupo acima

**P.**Eu tenho dito por alguns dos meus colegas que eu deve utilizar grupos de arquivos para novos bancos de dados em vez de um arquivo de dados único. Você pode explicar algumas das vantagens e desvantagens de fazê-lo?

**.**Eu não posso pensar de qualquer desvantagens do uso de grupos de arquivos, exceto talvez indo longe demais e usando centenas deles. Tanto quanto os benefícios vão, vários grupos de arquivos começam a se tornar necessário, como os bancos de dados que se tornam maiores (mais de 50GB - 100GB). Ainda assim, existem três razões principais para tê-los.

Grupos de arquivos permitem restaurações rápidas, alvo durante um desastre. Imagine que você tem um banco de dados de 1TB, com a maioria do espaço com uma tabela de vendas que contém dados de 2009 até hoje. Se o banco de dados é destruído em uma catástrofe, o que é a menor quantidade que você pode restaurar? Se está tudo em um grupo de arquivos não há todas as opções, você deve restaurar o 1TB inteira, incluindo todos os dados antigos.

Uma abordagem melhor para recuperação de desastres é se você tiver grupos de arquivos separados: primário, 2009, 2010, 2011, 2012 e 2013. Em caso de desastre, você deseja que os dados de 2013 estar on-line mais rápido possível. Isso é o que suporta o seu sistema de vendas de processamento de transações Online (OLTP). Enquanto você tem SQL Server Enterprise edition, você pode aproveitar a disponibilidade parcial do banco de dados e iniciar este processo restaurando o grupo de arquivos primário usando a sintaxe com parcial. Então você pode restaurar os outros grupos de arquivos que você quer on-line imediatamente. Em seguida, você pode finalizar a seqüência de restauração.

Você pode restaurar os outros grupos de arquivos on-line e em seu lazer. Agora você está utilizando outro recurso de edição Enterprise, chamado "on-line restauração." Esta é uma combinação de recursos para grandes bancos de dados (VLDBs). Esses recursos reduzem o tempo de inatividade e dar-lhe uma grande flexibilidade quando se trata de priorizar sua seqüência de restauração durante um desastre. Isso também significa que você pode executar uma restauração, se apenas uma parte do banco de dados estiver danificada por algum motivo. Isso limita ainda mais requisitos de tempo de inatividade em caso de desastre.

A segunda razão para usar os grupos de arquivos é apoiar o particionamento e melhor capacidade de gerenciamento. Particionamento permite facilmente carregar e excluir dados de uma tabela grande muito rapidamente, sem gerar um monte de log de transações. Totalmente explicar os benefícios do particionamento está além do escopo desta coluna, mas os seguintes white papers fazem um grande trabalho, utilizando diferentes exemplos de situações:

Uma outra característica de gerenciabilidade lida com fragmentação. Usando o mesmo exemplo de tabela de vendas como antes, se você tem índices sobre a tabela de vendas que se tornam fragmentados e a tabela e os índices não são particionados, então o ALTER INDEX... RECRIAR ou reorganizar comandos terão de operar sobre o índice inteiro sendo desfragmentado. Isso é verdadeiro mesmo que os dados mais antigos não sejam fragmentados. Se eu dividir a tabela em várias partições, cada um em um grupo de arquivos separado, você pode desfragmentar apenas as partições dos índices que são fragmentados. Isso poupa muito tempo e recursos.

Por último, grupos de arquivos que você isolar diferentes cargas de trabalho do banco de dados em diferentes partes do subsistema I/O. Por exemplo, imagine que você tem algumas tabelas levemente usadas e alguns que são fortemente usados e atualizados. Se tudo está em um grupo de arquivos, você pode encontrar que o desempenho operacional nas tabelas levemente usados é comprometido por causa de operações nas tabelas intensamente atualizadas.

Nesse caso, você poderia separar as tabelas levemente usadas em um grupo de arquivos em seu próprio parte do subsistema I/O. Em seguida, armazene cada uma das tabelas fortemente utilizadas e atualizadas em grupos de arquivos separados. Tem cada um em seu próprio parte do subsistema I/O. Isso segrega a carga de I/O para que as cargas de trabalho não interfiram uns com os outros.

Você também pode ter de fazer isso dentro de uma única tabela, se houver uma carga de trabalho OLTP sobre os dados mais recentes (por exemplo, em uma tabela de vendas, como discutido anteriormente) e uma carga de trabalho do armazém de dados sobre os dados mais antigos. Este é um caso onde o particionamento será necessário e cargas de trabalho diferentes vão ser confinadas para separar partições da tabela em grupos de arquivos separados — separar novamente as cargas de trabalho uns dos outros.

Paul S. Randal

Paul S. Randal é diretor-gerente da SQLskills.com, diretor regional da Microsoft e um SQL Server MVP. Ele trabalhou no SQL Server Storage Engine equipe da Microsoft de 1999 a 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 é 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. Blogs de He em SQLskills.com/blogs/paul, e você pode encontrá-lo no Twitter em Twitter.com /PaulRandal..

Conteúdo relacionado