SQL Q & a: Em busca de desempenho

  • Artigo

Reduzindo a carga de trabalho e funções de espelhamento de suavização são sempre uma boa idéia — mas encolher os bancos de dados não é.

Paul S. Randal

Solução alternativa de carga de trabalho

**P.**Estou trabalhando com uma equipe de desenvolvedores que estão mudando de um aplicativo para usar o SQL Server para armazenamento de dados. Anteriormente, os dados foram armazenados localmente nas máquinas clientes. Você pode me dar uma lista de considerações para os desenvolvedores para que podem conduzir a menos possível quantidade de carga de trabalho para o SQL Server?

**.**Por se esforçando para fazer com que o aplicativo chamar para baixo para a camada de dados tanto quanto possível, você está tendo uma excelente abordagem. Incidindo sobre o aplicativo é infelizmente atípica. A principal coisa a ter em mente é que o aplicativo recuperar dados do SQL Server tanto quanto possível. Quando ele recupera dados, tê-lo a recuperar apenas os dados que ele precisa tão eficientemente quanto possível.

Aqui estão algumas coisas para os desenvolvedores a considerar sobre a maneira em que o aplicativo consulta de dados do SQL Server. Prestando atenção a estes vai evitar a carga de trabalho desnecessária e impacto negativo sobre a CPU, memória e i/o:

  • **Processamento:**Para os dados que está sendo puxados do SQL Server, o aplicativo deve evitar processando os dados de uma linha por vez. Isso é comumente chamado RBAR, ou linha por agonizante-linha de transformação. Qualquer tempo que do SQL Server envia dados para o aplicativo, ele tem um thread Aguardando o aplicativo de reconhecer os dados enviados através de. Processamento de RBAR pode levar a ASYNC_NETWORK_IO esperas no SQL Server. O aplicativo deve entrada dados localmente em cache e rapidamente a resposta para o SQL Server que tem os dados.
  • **Filtragem:**O aplicativo deve evitar a filtragem de dados localmente antes de usar ou exibir esses dados. É muito mais eficiente para empurrar o predicado de filtro para baixo para o SQL Server e se a quantidade mínima de dados retornados para o aplicativo. SQL Server é muito bom em filtragem de dados, tendo em conta os índices não clusterizados certas para apoiar os predicados de filtro.
  • **One Size Fits All (OSFA):**Minimize a quantidade de colunas de tabela que está sendo retornado apenas àqueles necessários. Os desenvolvedores também devem evitar tentando construir uma caixa de diálogo de "tamanho único". Usando uma lista de seleção de destino em vez de SELECT * irá reduzir a quantidade de dados a ser processado e retornado. Com menos colunas solicitadas, o SQL Server também pode ter mais formas ideais de chegar a esses dados, o que poderia melhorar a performance.
  • **Ordenação:**Se os dados estão sendo devolvidos não precisam ser classificado com um ORDER BY, então evite especificando ORDER BY, como isso pode cortar uma operação de classificação. Operações de classificação podem ser caras porque eles acabam exigindo um derramamento de classificação caro para tempdb.
  • **Apenas no caso:**Adie operações SELECT até que eles são realmente necessários. Se um aplicativo está emitindo um SELECT apenas no caso, o usuário clica em um botão de aplicativo. Então pode ser desperdiçado de processamento. É melhor esperar até que o botão é pressionado na verdade antes de emitir o SELECT, removendo todos os processamento quando não premir o botão.
  • **Considere o cache:**Se você está consultando uma e outra vez os mesmos dados, cache localmente e somente emitir uma nova seleção, quando os dados forem alterados. Isto é ideal quando dados não mudam com freqüência, ou se você não precisar de dados atualizados.

Considerando estes fatores pode ter um efeito profundo sobre a quantidade de trabalho que do SQL Server tem que fazer, especialmente se uma única mudança na lógica de consulta de aplicativo é multiplicada por centenas ou milhares de instâncias do aplicativo executando simultaneamente.

Pergunte a sua equipe de desenvolvimento de aplicativo para analisar como a aplicação está usando SQL Server. Isso pode beneficiar muito sua carga de trabalho existente. A causa raiz de problemas de desempenho é muitas vezes considerada SQL Server, em vez da maneira que o aplicativo está usando o SQL Server.

Espelho, espelho

**P.**Estamos usando espelhamento de banco de dados para vários anos. Só recentemente tivemos qualquer problema. Realizamos um failover e o banco de dados espelho levou várias horas para on-line, que foi bastante inesperado. Há qualquer contadores de desempenho que podemos monitorar para dizer se isso irá ocorrer novamente?

**.**Espelhamento de banco de dados se tornou extremamente popular desde que foi introduzido corretamente no SQL Server 2005 SP1. No entanto, há um problema generalizado nos sistemas do cliente. Parece haver um pressuposto que assim que você implementar o espelhamento de banco de dados, pode com segurança esquecê-lo e confiar para funcionar perfeitamente quando ocorre uma falha — sempre vai trazer o banco de dados protegido online no servidor espelho sem perda de dados e tempo de inatividade mínimo.

Embora isto possa ser verdade em alguns casos, é uma pressuposição perigosa. Para reduzir o potencial de desastre, é absolutamente essencial para monitorar o tamanho da fila o SEND e o refazer de uma sessão de espelhamento:

  • O tamanho da fila de envio mostra quanto log de transações foi gerado no servidor principal, mas ainda não foi enviada para o servidor espelho. Se não for zero, isso significa que o estado de espelhamento não é sincronizado e não pode haver um failover automático. Além disso, o tamanho da fila de envio indica a quantidade de perda de dados que irá ocorrer se o banco de dados principal sofre um desastre. Você precisa monitorar isso para garantir o tamanho da fila de envio não excede sua perda de dados máximo permitido Service Level Agreement (SLA) — ou objetivo de ponto de recuperação (RPO) — para o banco de dados espelhado.
  • O tamanho da fila de refazer mostra quanto log de transação existe no banco de dados espelho que ainda não tenha sido repetido no banco de dados espelho. Lembre-se, os registros de log só tem que ser temperado — não repetidos — na unidade de log o espelho do banco de dados. Isso é feito como um processo contínuo no servidor espelho. Se ocorrer um failover de espelhamento, você não pode acessar o banco de dados espelho, até que todos os registros de log de transação na fila de restauração tem sido repetidos no banco de dados espelho. Isto significa, essencialmente, que uma recuperação de falhas tem que ocorrer. Quanto maior a fila de refazer, a longo um failover terá. Lembre-se que na edição Enterprise, recuperação rápida entra em jogo e o banco de dados fica disponível após a refazer a fase de recuperação foi concluída, mas antes o desfazer fase começa. Você precisa monitorar isso para garantir o tamanho da fila de restauração não excede o tempo máximo de inatividade permitida SLA — ou objetivo de tempo de recuperação (RTO) — para o banco de dados espelhado.

A transação não enviada mais antiga é uma outra maneira de monitorar a quantidade instantânea de perda de dados, que você sofreria em caso de desastre de banco de dados principal. Ele se aplica em todos os modos de espelhamento de banco de dados, porque mesmo se você estiver usando espelhamento síncrono, o principal e o espelho podem tornar-se desconectado ou você pode pausar o espelhamento.

Você pode monitorar as filas de envio e refazer usando o Monitor de espelhamento de banco de dados no SQL Server Management Studio para configurar alertas. Você também pode monitorá-los diretamente usando os espelhamento de banco de dados objeto contadores perfmon Log enviar Queue KB e Redo Queue KB.

Se você encontrar o tamanho da fila de refazer a crescer, isso implica que o servidor espelho não consegue acompanhar a quantidade de logs a serem enviados do servidor principal. Poderia ser há uma carga de trabalho adicional no servidor espelho que está impedindo que o log de banco de dados espelho repetindo o mais rápido possível. Também pode ser que o hardware físico no servidor espelho não é tão capaz que no servidor principal.

Reduzi-lo até

**P.**Um dos nossos fornecedores de aplicativos é a imposição de que executar operações SHRINKDATABASE (DBCC) contra o tempdb e bancos de dados do aplicativo de verificação de consistência de banco de dados normal. O vendedor insiste que isso é necessário para manter o desempenho adequado. Você pode me dar alguns conselhos?

**.**Esta pergunta vem à tona muito regularmente. Um fornecedor da aplicação pode recusar-se a deixá-lo remover operações de redução regular porque eles são considerados "necessários para o desempenho." Encolhendo as bases de dados faz com que a fragmentação do índice, consome muitos recursos de CPU e i/o. Ele também gera um monte de log de transações. Isso pode causar problemas para o banco de dados de espelhamento, AlwaysOn grupos de disponibilidade, replicação e qualquer outra coisa que tem de enviar registros de log ao redor. Há algumas circunstâncias, no entanto, onde operações de redução pontual são necessárias.

Bancos de dados nunca devem ser regularmente encolhidos. Encolher regularmente os bancos de dados é uma coisa ruim de fazer, porque se o banco de dados repetidamente cresce após ser encolhido, tudo o que o trabalho do psiquiatra é esforço completamente desperdiçado. É semelhante a ter redução automática habilitada para o banco de dados.

Muitas equipes de aplicação do fornecedor não sei que essas coisas sobre encolhem. Isso é muitas vezes porque tenho portado a aplicação de outro sistema de banco de dados e são relutantes em escutar alguém tentando educá-los sobre como funciona o SQL Server.

Eu vou ocasionalmente envolver com um cliente e a equipe de fornecedor do aplicativo. As justificações da equipe do fornecedor do aplicativo são geralmente ao longo das linhas dos seguintes (parafraseando):

  • Os índices no banco de dados já são fragmentados, assim diminuindo não torná-lo pior.
  • Ninguém nunca reclamou de desempenho antes, então porque você está?
  • Temos que ter um psiquiatra regular, porque as operações fazem com que o banco de dados, expandir-se muito e os clientes querem o seu espaço de disco para trás.
  • Temos que diminuir tempdb, porque as operações nós fazem com que ele cresça continuamente.

Nenhum destes são razões válidas para diminuir regularmente os bancos de dados. Na verdade, ele está documentado em KB artigo 307487 que diminuir tempdb quando há atividade de usuário pode levar à corrupção de tempdb. Além disso, o "trabalhando com Tempdb no SQL Server 2005" livro branco (aplicável a todas as versões) afirma que: "Reduzir arquivos não é uma prática recomendada".

Qualquer hora que um vendedor afirma encolhendo é necessário, ele demonstra que qualquer um mal-entendido fundamental de como você deve gerenciar o SQL Server ou uma deficiência no comportamento do aplicativo encobertas através de regular encolhendo. A melhor maneira de se envolver com fornecedores que mandato regular encolhendo é apontá-las para o artigo do KB da Microsoft ou papel branco. Então eles não podem argumentar que eles estão aderindo às práticas recomendadas da Microsoft.

Infelizmente, não há nenhuma maneira de impedir que operações de redução se eles estão obrigatória de fornecedor. Removendo a operação de redução seria anular um contrato de suporte. A melhor coisa que você poderia fazer é ter um trabalho do SQL Server Agent que executa a cada 15 segundos à procura de conexões que estão encolhendo os bancos de dados e, em seguida, matando-os. Matar uma operação de redução não vai causar a corrupção ou outros problemas. Esta abordagem pode ajudá-lo a permanecer no âmbito do acordo de apoio, evitando também problemas de desempenho no servidor de produção.

Paul S. Randal

Paul S. Randal é o diretor administrativo da SQLskills.com, diretor regional da Microsoft e MVP do SQL Server. Ele trabalhou na equipe do mecanismo de armazenamento do SQL Server na 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