Requisitos do subsistema de E/S do Microsoft SQL Server para o banco de dados tempdb

Este artigo apresenta os requisitos do subsistema de E/S para o banco de dados tempdb no SQL Server.

Versão original do produto: Microsoft SQL Server
Número original do KB: 917047

Resumo

O Microsoft SQL Server requer que o subsistema de E/S usado para armazenar bancos de dados do sistema e do usuário respeite totalmente os requisitos de WAL (Log Write-Ahead) por meio de entidades de E/S específicas. Esses requisitos são necessários para honrar as propriedades ACID das transações: Atômica, Consistente, Isolada e Durável. Os detalhes sobre os requisitos de conformidade do subsistema de E/S são fornecidos nos conceitos básicos de E/S do SQL Server.

A lista a seguir é um resumo rápido dos requisitos:

  • A ordem de gravação deve ser mantida.
  • A consistência de gravação dependente deve ser mantida.
  • As gravações devem sempre ser protegidas em/em mídia estável.
  • A prevenção de E/S interrompida deve ocorrer.

A manutenção de durabilidade permanece crítica para todos os outros bancos de dados, mas pode ser relaxada para o banco de dados tempdb. A tabela a seguir resume vários dos requisitos críticos de E/S para bancos de dados do SQL Server.

Requisito de E/S Breve descrição Sistema ou usuário tempdb (banco de dados temporário)
Escreva ordenação

Consistência de gravação dependente		 A capacidade do subsistema de manter a ordem correta das operações de gravação. Isso pode ser especialmente importante para soluções de espelhamento, requisitos de consistência de grupo e uso do protocolo WAL do SQL Server. Necessário Recomendadas
Ler após a gravação A capacidade do subsistema de atender a solicitações de leitura com a imagem de dados mais recente quando a leitura é emitida após qualquer gravação ser concluída com êxito. Necessário Necessário
Sobrevivência em interrupções A capacidade de os dados permanecerem totalmente intactos (duráveis) durante uma interrupção, como uma reinicialização do sistema. Necessário Não aplicável
Prevenção de E/S rasgada A capacidade do sistema de evitar a divisão de solicitações de E/S individuais. Necessário Recomendadas
Reescrita de setor O setor só pode ser escrito em sua totalidade e não pode ser reescrito devido a uma solicitação de gravação em um setor próximo. * Desencorajado, permitido apenas se transacional * Desencorajado, permitido apenas se transacional
Dados reforçados A expectativa de que, quando uma solicitação de gravação ou uma operação FlushFileBuffers for concluída com êxito, os dados tenham sido salvos em uma mídia estável. Necessário Não aplicável
Alinhamento e tamanho do setor físico O SQL Server interroga os locais de armazenamento de dados e arquivos de log. Todos os dispositivos são necessários para dar suporte a atributos de setor, permitindo que o SQL Server execute gravações em limites alinhados ao setor físico e em múltiplos do tamanho do setor. Necessário Necessário

As regravações de setor transacional envolvem operações totalmente registradas pelo subsistema, permitindo que um setor seja totalmente movido, substituído ou revertido para a imagem original. Essas regravações geralmente são desencorajadas devido à sobrecarga adicional necessária para executar essas ações. Um exemplo disso seria um defragmentation utilitário que está movendo os dados do arquivo. O setor original no arquivo não pode ser substituído pelo novo local do setor até que o novo setor e os novos dados sejam protegidos. O remapeamento do setor deve ocorrer de forma transacional para que qualquer falha, incluindo uma falha de energia, provoque o restabelecimento dos dados originais. Verifique se você tem mecanismos de bloqueio disponíveis durante esse tipo de processo para evitar o acesso a dados inválidos, mantendo assim os outros locatários de E/S do SQL Server.

Sobrevivência em interrupções

O banco de dados tempdb é uma área temporária para o SQL Server e é recriado a cada inicialização do SQL Server. A inicialização substitui qualquer necessidade de dados sobreviverem a uma reinicialização.

Operações de reescrita do setor transacional

Para garantir o sucesso dos processos de recuperação, como reversão e recuperação de falha, os registros de log devem ser armazenados corretamente em mídia estável antes que a página de dados seja armazenada e não podem ser regravados sem respeitar as propriedades transacionais. Isso exige que o subsistema e o SQL Server mantenham atributos específicos, como ordenação de gravação, gravações alinhadas e dimensionadas por setor e outros atributos de segurança de E/S descritos nos documentos mencionados anteriormente. Para o banco de dados tempdb, a recuperação de falha é desnecessária porque o banco de dados é sempre inicializado durante a inicialização do SQL Server. No entanto, o banco de dados tempdb ainda requer recursos de reversão. Portanto, alguns atributos do protocolo WAL podem ser relaxados.

O local de armazenamento do banco de dados tempdb deve agir em estrita conformidade com os protocolos de unidade de disco estabelecidos. De todas as maneiras, o dispositivo no qual o banco de dados tempdb está armazenado deve aparecer e atuar como um disco físico que fornece recursos de leitura após gravação. As operações de reescrita do setor de transação podem ser um requisito adicional de implementações específicas. Por exemplo, o SQL Server não oferece suporte a modificações de banco de dados usando a compactação do sistema de arquivos NTFS porque a compactação NTFS pode reescrever setores do log que já foram gravados e considerados protegidos. Uma falha durante esse tipo de reescrita pode fazer com que o banco de dados fique inutilizável, danificando dados que o SQL Server já considerava seguros.

Observação

O SQL Server estendeu o suporte ou a compactação para ler somente bancos de dados e grupos de arquivos. Consulte os Manuais Online do SQL Server para obter detalhes completos.

As operações de reescrita de setor transacional são pertinentes a todos os bancos de dados do SQL Server que incluem o banco de dados tempdb. Uma variedade crescente de tecnologias de armazenamento estendido usa dispositivos e utilitários que podem reescrever dados que o SQL Server considera seguros. Por exemplo, algumas das tecnologias emergentes executam cache na memória ou compactação de dados. Para evitar danos graves ao banco de dados, qualquer regravação de setor deve ter suporte transacional completo de forma que, se ocorrer uma falha, os dados sejam revertidos para as imagens de setor anteriores. Isso garante que o SQL Server nunca seja exposto a uma interrupção inesperada ou a uma condição de dano aos dados.

Você pode colocar o banco de dados tempdb em subsistemas especializados, como discos RAM, estado sólido ou outras implementações de alta velocidade que não podem ser usadas para outros bancos de dados. No entanto, os principais fatores apresentados na seção Mais informações devem ser considerados ao avaliar essas opções.

Observação

Os discos locais em ambientes clusterizados de failover só têm suporte com implementações de estado sólido ou de alta velocidade. Isso ocorre porque o disco RAM só pode ser criado em um destino iSCSI. Além disso, os recursos de destino iSCSI e cluster de failover não podem ser usados no mesmo host.

Mais informações

Vários fatores devem ser cuidadosamente estudados ao avaliar o local de armazenamento do banco de dados tempdb. Por exemplo, o uso do banco de dados tempdb envolve, mas não se limita a, volume de memória, plano de consulta e decisões de E/S. O ajuste e a implementação apropriados do banco de dados tempdb podem melhorar a escalabilidade e a capacidade de resposta de um sistema. Esta seção discute os principais fatores para determinar as necessidades de armazenamento para o banco de dados tempdb.

Subsistemas de alta velocidade

Há várias implementações de subsistema de alta velocidade disponíveis no mercado que fornecem requisitos de protocolo de subsistema de E/S do SQL Server, mas que não fornecem durabilidade da mídia.

Importante

Sempre confirme com o fornecedor do produto para garantir a conformidade total com as necessidades de E/S do SQL Server.

Um disco RAM é um exemplo comum de tal implementação. Os discos RAM instalam os drivers necessários e permitem que parte do disco RAM principal apareça e funcione como qualquer unidade de disco conectada ao sistema. Todos os subsistemas de E/S devem fornecer conformidade total com os requisitos de E/S do SQL Server. No entanto, é óbvio que um disco RAM não é uma mídia durável. Portanto, uma implementação como um disco RAM só pode ser usada como o local do banco de dados tempdb e não pode ser usada para nenhum outro banco de dados.

Chaves a serem consideradas antes da implementação e implantação

Há vários pontos a serem considerados antes da implantação do banco de dados tempdb nesse tipo de subsistema. Esta seção usa um disco RAM como base para discussão, mas resultados semelhantes ocorrem em outras implementações de alta velocidade.

Segurança de E/S

A conformidade de leitura após gravação e gravações do setor transacional é uma obrigação. Nunca implante o SQL Server em qualquer sistema que não ofereça suporte total aos requisitos de E/S do SQL Server, ou você corre o risco de danos e perda de seus dados.

Páginas já armazenadas em cache (cache de RAM dupla)

As tabelas temporárias são como todas as outras tabelas em um banco de dados. Eles são armazenados em cache pelo pool de buffers e tratados por operações de gravação lentas. O armazenamento de páginas de tabela temporárias em um disco RAM causa cache de RAM duplo, um no pool de buffers e outro no disco RAM. Isso tira diretamente o tamanho total possível do pool de buffers e geralmente diminui o desempenho do SQL Server.

Desistindo de RAM

O disco RAM designa uma parte da RAM principal como o nome indica. Existem várias implementações de discos RAM e caches de arquivos baseados em RAM disponíveis. Alguns também permitem operações físicas de suporte de E/S. O elemento-chave do cache de arquivos baseado em RAM é que ele tira diretamente da memória física que pode ser usada pelo SQL Server. Sempre tenha fortes evidências de que adicionar um cache de arquivos baseado em RAM melhora o desempenho do aplicativo e não diminui o desempenho de outras consultas ou aplicativos.

Sintonize primeiro

Um aplicativo deve ser ajustado para remover classificações e hashes desnecessários e indesejados que podem causar o uso do banco de dados tempdb. Muitas vezes, a adição de um índice pode eliminar completamente a necessidade de classificação ou hash no plano, levando a um desempenho ideal sem exigir o uso do banco de dados tempdb.

Possíveis pontos de benefícios

Os benefícios de colocar o banco de dados tempdb em um sistema de alta velocidade só podem ser determinados por meio de testes e medições rigorosos das cargas de trabalho do aplicativo. A carga de trabalho deve ser estudada cuidadosamente para as características das quais o banco de dados tempdb pode se beneficiar, e a segurança de E/S deve ser confirmada antes da implantação.

As operações de classificação e hash funcionam em conjunto com os gerenciadores de memória do SQL Server para determinar o tamanho da área temporária na memória para cada operação de classificação ou hash. Assim que os dados de classificação ou hash excederem a área de rascunho alocada na memória, os dados poderão ser gravados no banco de dados tempdb. Esse algoritmo foi expandido no SQL Server, reduzindo os requisitos de uso do banco de dados tempdb em relação às versões anteriores do SQL Server.

Cuidado

O SQL Server foi projetado para levar em conta os níveis de memória e as atividades de consulta atuais ao tomar decisões de plano de consulta que envolvem o uso de operações de banco de dados tempdb. Portanto, os ganhos de desempenho variam significativamente com base nas cargas de trabalho e no design do aplicativo. É altamente recomendável que você conclua o teste com a solução preferida para determinar possíveis ganhos e avaliar os requisitos de segurança de E/S antes de tal implantação.

O SQL Server usa o banco de dados tempdb para lidar com várias atividades que envolvem classificações, hashes, o repositório de versão de linha e tabelas temporárias:

  • As tabelas temporárias são mantidas pelas rotinas comuns do buffer pool para páginas de dados e geralmente não exibem benefícios de desempenho de implementações de subsistemas especiais.
  • O banco de dados tempdb é usado como uma área temporária para hashes e classificações. Reduzir a latência de E/S para essas operações pode ser benéfico. No entanto, saiba que adicionar um índice para evitar um hash ou uma classificação pode fornecer um benefício semelhante.

Execute linhas de base com e sem o banco de dados tempdb armazenado no subsistema de alta velocidade para comparar os benefícios. Parte do teste deve incluir consultas no banco de dados do usuário que não envolvam classificações, hashes ou tabelas temporárias e, em seguida, confirmar se essas consultas não são afetadas negativamente. Ao avaliar o sistema, os indicadores de desempenho a seguir podem ser úteis.

Indicador Descrição/uso
A página lê e escreve Melhorar o desempenho das E/Ss do banco de dados tempdb pode alterar a taxa de leituras e gravações de página para os bancos de dados do usuário devido à latência reduzida associada à E/S do banco de dados tempdb. Para páginas de banco de dados de usuário, o número geral não deve variar na mesma carga de trabalho.
Bytes físicos de leitura e gravação no banco de dados tempdb Se mover o banco de dados tempdb para um dispositivo, como um disco RAM, aumentar a E/S real para o banco de dados tempdb, isso indicará que a memória retirada do pool de buffers está causando o aumento da atividade do banco de dados tempdb. Esse padrão é um indicador de que a expectativa de vida das páginas do banco de dados também pode ser afetada de maneira negativa.
duração prevista da página Um declínio na expectativa de vida da página pode indicar um aumento nos requisitos de E/S física para um banco de dados de usuário. A diminuição da taxa provavelmente pode indicar que a memória retirada do pool de buffers está forçando as páginas do banco de dados a sair do pool de buffers prematuramente. Combine com os outros indicadores e teste para entender completamente os limites dos parâmetros.
Taxa de transferência geral
Uso da CPU
Escalabilidade
Tempo de resposta		 O objetivo principal de uma alteração de configuração de banco de dados tempdb é aumentar a taxa de transferência geral. Seus testes devem incluir uma combinação de cargas de trabalho repetíveis que podem ser dimensionadas para determinar como a taxa de transferência é afetada.

Algo como uma implementação de disco RAM baseada em compactação pode funcionar bem com 10 usuários. No entanto, com o aumento da carga de trabalho, isso pode empurrar os níveis de CPU além dos níveis desejados e ter efeitos negativos no tempo de resposta quando as cargas de trabalho são altas. Testes de estresse verdadeiros e testes de previsão de carga futuros são incentivados.
Arquivos de trabalho e ações de criação de tabela de trabalho Se mover o banco de dados tempdb para um dispositivo, como um disco RAM, alterar o plano de consulta aumentando o número ou o tamanho dos arquivos de trabalho ou tabelas de trabalho, isso indicará que a memória retirada do pool de buffers está causando o aumento da atividade do banco de dados tempdb. Esse padrão é uma indicação de que a expectativa de vida das páginas do banco de dados também pode ser afetada de forma negativa.

Exemplo de reescrita do setor transacional

O exemplo a seguir elabora a segurança de dados exigida pelos bancos de dados do SQL Server.

Suponha que um fornecedor de disco RAM use uma implementação de compactação na memória. A implementação deve ser encapsulada corretamente, fornecendo a aparência física do fluxo de arquivos como se o setor estivesse alinhado e dimensionado para que o SQL Server não tenha conhecimento e seja protegido corretamente da implementação subjacente. Veja o exemplo de compactação mais de perto.

  • O setor 1 é gravado no dispositivo e compactado para economizar espaço.
  • O setor 2 é gravado no dispositivo e compactado com o setor 1 para economizar espaço.

O dispositivo pode executar as seguintes ações para ajudar a proteger os dados do setor 1 quando combinados com os dados do setor 2.

  • Bloqueie todas as gravações nos setores 1 e 2.
  • Descompacte o setor 1 em uma área de rascunho, deixando o armazenamento atual do setor 1 como os dados ativos a serem recuperados.
  • Comprima os setores 1 e 2 em um novo formato de armazenamento.
  • Bloqueie todas as leituras e gravações dos setores 1 e 2.
  • Troque o armazenamento antigo pelos setores 1 e 2 pelo novo. Se a tentativa de troca falhar (rollback):
    • Restaure o armazenamento original para os setores 1 e 2.
    • Remova os dados combinados dos setores 1 e 2 da área de rascunho.
    • Falha na operação de gravação do setor 2.
  • Desbloqueie leituras e gravações para os setores 1 e 2.

A capacidade de fornecer mecanismos de bloqueio em torno das modificações do setor e reverter as alterações quando a tentativa de troca do setor falhar é considerada compatível com a transição. Para implementações que usam armazenamento físico para suporte estendido, ele incluiria os aspectos de log de transações apropriados para ajudar a proteger e reverter as alterações que foram aplicadas às estruturas em disco para manter a integridade dos arquivos de banco de dados do SQL Server.

Qualquer dispositivo que permita a reescrita de setores deve dar suporte às regravações de maneira transacional para que o SQL Server não seja exposto à perda de dados.

Observação

A instância do SQL Server é reiniciada quando ocorrem falhas de E/S e reversão online no banco de dados tempdb.

Tenha cuidado ao mover o banco de dados tempdb

Tenha cuidado ao mover o banco de dados tempdb porque, se o banco de dados tempdb não puder ser criado, o SQL Server não será iniciado. Se o banco de dados tempdb não puder ser criado, inicie o SQL Server usando o parâmetro de inicialização (-f) e mova o banco de dados tempdb para um local válido.

Para alterar o local físico do banco de dados tempdb, siga estas etapas:

  1. Use a ALTER DATABASE instrução e a MODIFY FILE cláusula para alterar os nomes de arquivo físico de cada arquivo no banco de dados tempdb para se referir ao novo local físico, como o novo disco.

    ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

  2. Pare e reinicie o SQL Server.

As certificações de produtos de parceiros não são uma garantia de compatibilidade ou segurança

Um produto de terceiros ou um fornecedor específico pode receber uma certificação de logotipo da Microsoft. No entanto, a certificação de parceiro ou um logotipo específico da Microsoft não certifica a compatibilidade ou a adequação a uma finalidade específica no SQL Server.

Suporte

Se você usar um subsistema com SQL Server que dê suporte às garantias de E/S para uso de banco de dados transacional, conforme descrito neste artigo, a Microsoft fornecerá suporte para SQL Server e aplicativos baseados em SQL Server. No entanto, os problemas com o subsistema ou causados pelo mesmo serão encaminhados ao fabricante.

Para problemas relacionados ao banco de dados tempdb, os Serviços de Suporte da Microsoft solicitarão que você realoce o banco de dados tempdb. Entre em contato com o fornecedor do dispositivo para verificar se você implantou e configurou corretamente o dispositivo para uso do banco de dados transacional.

A Microsoft não certifica nem valida que os produtos de terceiros funcionam corretamente com o SQL Server. Além disso, a Microsoft não fornece nenhuma garantia ou declaração de adequação de qualquer produto de terceiros para uso com o SQL Server.

Referências

Para obter mais informações, consulte:

  • Last updated on