Compartilhar via

Fundamentos de E/S do SQL Server

  • Artigo

Aplica-se a: SQL Server Instância Gerenciada de SQL do Azure SQL Server na VM do Azure

A principal finalidade de um banco de dados do SQL Server é armazenar e recuperar dados, de modo que a intensa E/S de disco é uma característica importante do mecanismo de banco de dados. Como as operações de E/S de disco podem consumir muitos recursos e levar um tempo relativamente longo para terminar, o SQL Server se concentra em tornar a E/S altamente eficiente.

Os subsistemas de armazenamento para SQL Server são fornecidos em vários formatos, incluindo armazenamento em unidades mecânicas e em estado sólido. Este artigo contém detalhes sobre como usar princípios de cache da unidade para melhorar a E/S do mecanismo de banco de dados.

O SQL Server requer que os sistemas ofereçam suporte à entrega garantida para mídia estável, conforme descrito nos Requisitos do Programa de Confiabilidade de E/S do SQL Server. Para obter mais informações sobre os requisitos de entrada e saída para o mecanismo de banco de dados do SQL Server, consulte Requisitos de entrada/saída (E/S) de disco do mecanismo de banco de dados do SQL Server.

E/S de disco

O gerenciador de buffer apenas faz leituras e gravações no banco de dados. Outras operações de arquivo e banco de dados, como abrir, fechar, estender e reduzir são executadas pelos componentes do gerenciador de banco de dados e de arquivos.

As operações de E/S de disco pelo gerenciador de buffer têm as seguintes características:

  • A E/S normalmente é executada de forma assíncrona, o que permite ao thread de chamada continuar o processamento enquanto a operação de E/S acontece em segundo plano. Em algumas circunstâncias (por exemplo, E/S de log desalinhadas), pode haver E/S síncrona.

  • Todas as E/S são emitidas nos threads de chamada, a menos que a opção affinity I/O esteja em uso. A opção affinity I/O mask associa o E/de disco de SQL Server a um subconjunto especificado de CPUs. Em ambientes OLTP (online transactional processing) avançados de SQL Server , esta extensão pode aumentar o desempenho de threads SQL Server que emitem E/S.

  • Várias E/Ss de página são realizadas com E/S de dispersar e reunir, que permite transferir dados para dentro ou para fora de áreas não contíguas de memória. Isso significa que o SQL Server pode preencher ou liberar o cache do buffer rapidamente enquanto evita várias solicitações de E/S físicas.

Solicitações de E/S demoradas

O gerenciador de buffer informa sobre qualquer solicitação de E/S pendente durante pelo menos 15 segundos. Isso ajuda o administrador de sistema a distinguir entre problemas do SQL Server e problemas do subsistema de E/S. A Mensagem de erro MSSQLSERVER_833 é informada e exibida no log de erros do SQL Server da seguinte forma:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Uma E/S demorada pode ser uma leitura ou uma gravação; isso não está indicado atualmente na mensagem. Mensagens de E/S demoradas são avisos, não erros. Elas não indicam problemas com o SQL Server, mas com o sistema de E/S subjacente. As mensagens são informadas para ajudar o administrador de sistema a encontrar mais depressa a causa de tempos de resposta insatisfatórios do SQL Server e distinguir problemas que estão fora do controle do SQL Server. Como tal, eles não exigem nenhuma ação, mas o administrador do sistema deve investigar por que a solicitação de E/S demorou tanto e se o tempo é justificável.

Causas de solicitações de E/S demoradas

Uma mensagem de E/S demorada pode indicar que uma E/S está bloqueada permanentemente e nunca será concluída (conhecida como E/S perdida) ou, então, que apenas não foi concluída ainda. Não é possível distinguir qual é o cenário com base na mensagem, embora uma E/S perdida geralmente conduza a um tempo limite de trava.

E/S demorada geralmente indica uma carga de trabalho do SQL Server muito intensa para o subsistema de disco. Um subsistema de disco inadequado pode ser indicado quando:

  • Várias mensagens de E/S demorada são exibidas no log de erros durante uma carga de trabalho pesada do SQL Server.
  • Contadores de monitor de desempenho mostram latências de disco demoradas, filas de disco demoradas ou nenhum tempo ocioso de disco.

E/Ss demoradas também podem ser causadas por um componente no caminho de E/S (por exemplo, driver, controlador ou firmware) que continuamente adia o atendimento de uma solicitação de E/S antiga em favor do atendimento de solicitações mais recentes. Isso pode ocorrer em ambientes interconectados, como iSCSI e redes de canal de fibra (devido a uma configuração incorreta ou falha no caminho). Isso pode ser difícil de confirmar com a ferramenta Performance Monitor, porque a maior parte da E/S está sendo atendida prontamente. As solicitações de E/S demoradas podem ser agravadas por cargas de trabalho que executam grandes quantidades de E/S sequenciais, como backup e restauração, exames de tabela, classificação, criação de índices, carregamentos em massa e anulação de arquivos de saída.

E/Ss demoradas e isoladas que não aparecem relacionadas a quaisquer condições anteriores podem ser causadas por um problema de hardware ou driver. O log de eventos do sistema pode conter um evento relacionado que ajuda a diagnosticar o problema.

Problemas de desempenho de E/S causados por consultas ou drivers de filtro ineficientes

A E/S demorada pode ser causada por consultas que não são escritas de forma eficiente ou não ajustadas adequadamente a índices e estatísticas. Outro fator comum na latência de E/S é a presença de antivírus ou outros programas de segurança que varrem os arquivos de banco de dados. Esse software de varredura pode se estender para a camada de rede, o que aumenta a latência da rede, por sua vez afetando indiretamente a latência do banco de dados. Embora o cenário descrito sobre E/S de 15 segundos seja mais comum com componentes de hardware, uma latência de E/S menor é observada com mais frequência com consultas não otimizadas ou programas antivírus mal configurados.

Para obter informações detalhadas sobre como tratar desses problemas, consulte Solucionar problemas de desempenho lento do SQL Server causado por problemas de E/S.

Para obter informações sobre como configurar a proteção antivírus no SQL Server, consulte Configurar o software antivírus para funcionar com o SQL Server.

Cache de gravação em controladores de armazenamento

As transferências de E/S que são executadas sem o uso de um cache podem ser significativamente mais demoradas em unidades mecânicas, devido às taxas de rotação do disco rígido, ao tempo mecânico necessário para mover as cabeças da unidade e a outros fatores limitantes. As instalações do SQL Server são destinadas a sistemas que fornecem controladores de cache. Esses controladores desabilitam os caches em disco e fornecem caches de mídia estáveis para atender aos requisitos de E/S do SQL Server. Eles evitam problemas de desempenho relacionados aos tempos de busca e gravação no armazenamento, usando as diversas otimizações do controlador de cache.

Observação

Alguns fornecedores de armazenamento usam memória persistente (PMEM) como armazenamento em vez de um cache, o que pode melhorar o desempenho geral. Para obter mais informações, consulte Configurar memória persistente (PMEM) para SQL Server no Windows e Configurar memória persistente (PMEM) para SQL Server no Linux.

O uso de um controlador de armazenamento com cache de gravação (também chamado de cache com write-back) pode melhorar o desempenho do SQL Server. Os controladores com cache de gravação e os subsistemas de armazenamento são seguros para o SQL Server, se forem projetados para uso em um ambiente de DBMS (sistema de gerenciamento de banco de dados) transacional com dados críticos. Esses recursos de projeto devem preservar os dados armazenados em cache se ocorrer uma falha do sistema. Usar uma fonte de alimentação ininterrupta (UPS) externa para conseguir isso geralmente não é suficiente, porque podem ocorrer modos de falha que não estão relacionados à alimentação.

Os controladores de cache e os subsistemas de armazenamento podem ser seguros para uso pelo SQL Server. A maioria das novas plataformas de servidor que as incorporam, criadas especificamente, são seguras. No entanto, você deve verificar com o fornecedor do hardware se o subsistema de armazenamento foi testado e aprovado para uso em um ambiente de sistema de gerenciamento de banco de dados relacional (RDBMS) transacional de dados críticos.

Registro em logs write-ahead

As instruções de modificação de dados do SQL Server geram gravações de página lógicas. Esse fluxo de gravações pode ser imaginado como indo em dois lugares: o log e o próprio banco de dados. Por questões de desempenho, o SQL Server adia gravações no banco de dados por meio de seu próprio sistema de buffer de cache. As gravações no log são adiadas apenas momentaneamente, até o momento do COMMIT. Elas não são armazenadas em cache da mesma forma que as gravações de dados. Como as gravações de log para uma determinada página sempre precedem as gravações de dados da página, o log às vezes é chamado de log write-ahead (WAL).

Protocolo de log write-ahead (WAL)

O termo protocolo é uma excelente maneira de descrever o WAL. O WAL usado pelo SQL Server é conhecido como ARIES (Algorithm for Recovery and Isolation Exploiting Semantics). Para obter mais informações, confira Gerenciar recuperação acelerada de banco de dados.

É um conjunto específico e definido de etapas de implementação necessárias para garantir que os dados sejam armazenados e trocados corretamente e possam ser recuperados para um estado conhecido em caso de falha. Assim como uma rede contém um protocolo definido para trocar dados de maneira consistente e protegida, o WAL também descreve o protocolo para proteger dados. Todas as versões do SQL Server abrem os arquivos de log e de dados usando a função CreateFile do Win32. O membro dwFlagsAndAttributes inclui a opção FILE_FLAG_WRITE_THROUGH quando aberto pelo SQL Server.

FILE_FLAG_WRITE_THROUGH

O SQL Server cria seus arquivos de banco de dados usando o sinalizador FILE_FLAG_WRITE_THROUGH. Essa opção instrui o sistema a atravessar qualquer cache intermediário e ir diretamente para o armazenamento. O sistema ainda pode armazenar as operações de gravação em cache, mas não pode liberá-las lentamente. Para obter mais informações, confira CreateFileA.

A opção FILE_FLAG_WRITE_THROUGH garante que, quando uma operação de gravação retornar à conclusão bem-sucedida, os dados sejam armazenados corretamente em armazenamento estável. Isso se alinha com a especificação do protocolo Write Ahead Logging (WAL) para garantir os dados. Muitos dispositivos de armazenamento (baseados em NVMe, PCIe, SATA, ATA, SCSI e IDE) contêm caches integrados de 512 KB, 1 MB ou mais. Os caches de armazenamento geralmente contam com uma solução de suporte com capacitor, e não com bateria. Esses mecanismos de cache não podem garantir gravações em um ciclo de energia ou ponto de falha semelhante. Eles apenas garantem a conclusão das operações de escrita do setor. À medida que os dispositivos de armazenamento continuam a aumentar de tamanho, os caches se tornam maiores e podem expor maiores quantidades de dados durante uma falha.

Para saber mais sobre o suporte do FUA pela distribuição do Linux e o impacto dele no SQL Server, confira SQL Server em Linux: Elementos internos do FUA (Acesso forçado à unidade).

Integridade transacional e recuperação do SQL Server

A integridade transacional é um dos conceitos fundamentais de um sistema de banco de dados relacional. As transações são consideradas unidades de trabalho atômicas, que são totalmente aplicadas ou totalmente revertidas. O log write-ahead de transações do SQL Server é um componente vital na implementação da integridade transacional.

Qualquer sistema de banco de dados relacional também deve lidar com um conceito intimamente relacionado à integridade transacional, que é a recuperação de falha não planejada do sistema. No mundo real, vários efeitos não ideais podem causar essa falha. Em muitos sistemas de gerenciamento de banco de dados, a falha do sistema pode resultar em um longo processo de recuperação manual conduzido por humanos.

Por outro lado, o mecanismo de recuperação do SQL Server é automático e opera sem intervenção humana. Por exemplo, o SQL Server pode estar dando suporte a uma aplicação de produção de missão crítica e enfrentar uma falha do sistema devido a uma flutuação momentânea de energia. Após a restauração da energia, o hardware do servidor seria reiniciado, o software de rede seria carregado e inicializado, e o SQL Server seria reiniciado. À medida que o SQL Server é inicializado, ele executa automaticamente seu processo de recuperação com base nos dados no log de transações. Todo esse processo ocorre sem intervenção humana. Sempre que as estações de trabalho cliente eram reiniciadas, os usuários encontravam todos os seus dados presentes, até a última transação inserida.

A integridade transacional e a recuperação automática no SQL Server constituem um poderoso recurso de economia de tempo e trabalho. Se um controlador de cache de gravação não for projetado corretamente para uso em um ambiente DBMS transacional de dados críticos, ele poderá comprometer a capacidade de recuperação do SQL Server, corrompendo assim o banco de dados. Isso pode ocorrer se o controlador interceptar gravações no log de transações do SQL Server e armazená-las em buffer em um cache de hardware na placa controladora, mas não preservar essas páginas gravadas durante uma falha do sistema.

Cache de gravação e controladores do dispositivo de armazenamento

A maioria dos controladores de cache de dispositivo de armazenamento executa cache de gravação. A função do cache de gravação nem sempre pode ser desabilitada.

Mesmo que o servidor use um no-break, isso não garante a segurança das gravações armazenadas em cache. Pode haver muitos tipos de falhas do sistema que um no-break não resolve. Por exemplo, um erro de paridade de memória, uma interceptação (trap) do sistema operacional (SO) ou uma falha de hardware que causa uma reinicialização do sistema podem produzir uma interrupção descontrolada do sistema. Uma falha de memória no cache de gravação de hardware também pode resultar na perda de informações vitais do log.

Outro possível problema relacionado a um controlador de cache de gravação pode ocorrer no desligamento do sistema. Não é incomum trocar o sistema operacional ou reiniciar o sistema durante as alterações de configuração. Mesmo que um operador cuidadoso siga a recomendação do sistema operacional de aguardar até que toda a atividade de armazenamento cesse antes de reiniciar o sistema, ainda pode haver gravações armazenadas em cache no controlador. Quando a combinação de teclas Ctrl+Alt+Del é pressionada ou um botão de reinicialização no hardware é pressionado, as gravações armazenadas em cache podem ser descartadas, potencialmente danificando o banco de dados.

É possível projetar um cache de gravação de hardware, que leva em conta todas as possíveis causas de descarte de dados de cache sujos, sendo assim seguro para uso por um servidor de banco de dados. Alguns desses recursos de projeto incluiriam a interceptação do sinal RST do barramento para evitar a reinicialização descontrolada do controlador de cache, backup de bateria integrado e memória espelhada ou de verificação e correção de erros (ECC). Verifique com o fornecedor do hardware para garantir que o cache de gravação inclua esses e quaisquer outros recursos necessários para evitar a perda de dados.

Usar caches de armazenamento com o SQL Server

Um sistema de banco de dados é, em primeiro lugar, responsável pelo armazenamento e recuperação precisos de dados, mesmo em caso de falhas inesperadas do sistema.

O sistema deve garantir a atomicidade e a durabilidade das transações, ao mesmo tempo em que contabiliza a execução atual, várias transações e vários pontos de falha. Isso é muitas vezes referido como propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade).

Esta seção aborda as implicações dos caches de armazenamento. É recomendável que você leia os seguintes artigos na Base de dados de Conhecimento Microsoft para obter mais esclarecimentos sobre cache e discussões de modo de falha alternativo:

Os seguintes documentos também são recomendados:

Esses dois documentos se aplicam a todas as versões do SQL Server atualmente com suporte.

Soluções de cache com bateria

Os sistemas avançados de controlador de cache desativam o cache em disco e oferecem uma solução funcional de cache com bateria. Esses caches podem manter os dados no cache por vários dias e até mesmo permitir que a placa de cache seja colocada em um segundo computador. Quando a energia é devidamente restaurada, os dados não gravados são completamente liberados antes que qualquer acesso adicional aos dados seja permitido. Muitos deles permitem o estabelecimento de uma porcentagem de cache de leitura versus gravação, para obter desempenho ideal. Alguns contêm grandes áreas de armazenamento em memória. Alguns fornecedores de hardware fornecem sofisticados sistemas de cache de unidade com bateria, com vários gigabytes de cache. Estes podem melhorar significativamente o desempenho do banco de dados. O uso de soluções de cache com bateria oferece a durabilidade e a consistência de dados que o SQL Server espera.

Implementações de subsistemas de armazenamento

Existem muitos tipos de implementações de subsistemas. RAID (redundant array of independent disks) e SAN (storage area network) são dois exemplos desses tipos de implementações de subsistemas. Esses sistemas são normalmente construídos com unidades SCSI. Há vários motivos para isso. A seção a seguir descreve genericamente considerações para o armazenamento de alto nível.

SCSI, SAS e NVMe

Dispositivos de armazenamento SCSI, SAS e NVMe:

  • São normalmente fabricados para uso pesado.
  • Normalmente são direcionados a implementações multiusuário, baseadas em servidor.
  • Normalmente, têm melhores taxas de tempo médio para falha do que outras implementações.
  • Contêm heurísticas sofisticadas para ajudar a prever falhas iminentes.

Não-SCSI

Outras implementações de unidade, como IDE, ATA e SATA:

  • São normalmente fabricados para uso leve e médio.
  • Normalmente são direcionados a aplicações baseadas em usuário único.

Controladores não-SCSI baseados em desktop exigem mais largura de banda do processador (CPU) principal e costumam ser limitados a um único comando ativo. Por exemplo, quando uma unidade não-SCSI está ajustando um bloco defeituoso, a unidade requer que os comandos do host aguardem. O barramento ATA apresenta outro exemplo: o barramento ATA suporta dois dispositivos, mas apenas um único comando pode estar ativo. Isso deixa uma unidade ociosa enquanto a outra unidade atende ao comando pendente. Os sistemas RAID baseados em tecnologias de desktop podem experimentar esses sintomas e ser muito afetados pelo respondedor mais lento. A menos que esses sistemas usem projetos avançados, seu desempenho não é tão eficiente quanto o desempenho de sistemas baseados em SCSI.

Considerações de armazenamento

Há situações em que uma unidade ou array baseado em desktop é uma solução de baixo custo apropriada. Por exemplo, se você configurar um banco de dados somente leitura para relatórios, não deverá encontrar muitos dos aspectos de desempenho de um banco de dados OLTP quando o uso de cache da unidade estiver desabilitado.

Os tamanhos dos dispositivos de armazenamento continuam a aumentar. Unidades de baixo custo e alta capacidade podem ser atraentes. Porém, ao configurar a unidade para o SQL Server e as necessidades de tempo de resposta dos seus negócios, você deve considerar cuidadosamente os seguintes aspectos:

  • Projeto do caminho de acesso
  • O requisito para desativar o cache em disco

Discos rígidos mecânicos

Unidades mecânicas usam pratos magnéticos giratórios para armazenar dados. Elas estão disponíveis em várias opções de capacidade e fator forma, como IDE, SATA, SCSI e Serial Attached SCSI (SAS). Algumas unidades SATA incluem constructos de previsão de falha. As unidades SCSI são projetadas para ciclos de trabalho mais pesados e menores taxas de falha.

O cache da unidade deve ser desabilitado para usar a unidade com o SQL Server. O cache da unidade está habilitado por padrão. No Windows Server, use a guia Propriedades de disco>Hardware para acessar a guia Propriedades>Política para controlar a configuração de cache da unidade.

Observação

Algumas unidades não respeitam essa configuração. Essas unidades exigem um utilitário específico do fabricante para desabilitar o cache.

Os sistemas baseados em IDE e ATA podem adiar os comandos do host quando executam atividades como ajuste de setor defeituoso. Isso pode ocasionar períodos de atividade de E/S paralisada.

Os benefícios do SAS incluem enfileiramento avançado de até 256 níveis e enfileiramento de início de fila e fora de ordem. O backplane SAS é projetado de uma forma que permite o uso de drives SAS e SATA dentro do mesmo sistema.

A instalação do SQL Server depende da capacidade do controlador de desabilitar o cache em disco e fornecer um cache de E/S estável. Gravar dados fora de ordem em várias unidades não é um obstáculo para o SQL Server, desde que o controlador forneça os recursos corretos de cache de mídia estável. A complexidade do projeto do controlador aumenta com técnicas avançadas de segurança de dados, como espelhamento.

Armazenamento de estado sólido

O armazenamento de estado sólido tem vantagens sobre os discos rígidos mecânicos (giratórios), mas é suscetível a muitos dos mesmos padrões de falha dos dispositivos giratórios. O armazenamento de estado sólido é conectado ao servidor usando diversas interfaces, incluindo NVM Express (NVMe), PCI Express (PCIe) e SATA. Trate a mídia de estado sólido como faria com a mídia giratória e certifique-se de que as proteções apropriadas estejam em vigor para falta de energia, como um controlador de cache com bateria.

Problemas comuns causados por uma falta de energia incluem:

  • Bits corrompidos: os registros exibem erros de bits aleatórios.
  • Gravações fora do lugar: registros bem formados acabam no lugar errado.
  • Gravações cortadas: as operações são parcialmente feitas em um nível abaixo do tamanho esperado do setor.
  • Metadados corrompidos: os metadados na FTL estão corrompidos.
  • Dispositivo sem resposta: o dispositivo não funciona de jeito nenhum ou, na maioria das vezes, não funciona.
  • Desserialização: o estado final do armazenamento não reflete uma ordem de operação serializável.

512e

A maioria do armazenamento de estado sólido relata tamanhos de setor de 512 bytes, mas usa páginas de 4 KB dentro dos blocos de apagamento de 1 MB. O uso de setores alinhados em 512 bytes para o dispositivo de log do SQL Server pode gerar mais atividades de leitura/modificação/gravação (RMW), o que pode contribuir para um desempenho mais lento e desgaste da unidade.

Recomendação: verifique se o controlador de cache está ciente do tamanho correto da página do dispositivo de armazenamento e pode alinhar corretamente as gravações físicas com a infraestrutura de armazenamento de estado sólido.

0xFFFFFFFF

Uma unidade recém-formatada geralmente contém somente zeros. Um bloco apagado de um dispositivo de estado sólido contém somente 1s, fazendo com que uma leitura bruta de um bloco apagado contenha somente 0xFFs. No entanto, é incomum que um usuário leia um bloco apagado durante operações normais de E/S.

Estampagem de padrões

Uma técnica que usamos no passado é gravar um padrão conhecido para toda a unidade. Então, à medida que executamos a atividade do banco de dados nessa mesma unidade, podemos detectar o comportamento incorreto (leitura obsoleta / gravação perdida / leitura deum deslocamento incorreto / etc.) quando o padrão aparece inesperadamente.

Essa técnica não funciona bem no armazenamento de estado sólido. As atividades de apagamento e RMW para gravações destroem o padrão. A atividade de coleta de lixo (GC) do armazenamento de estado sólido, o nivelamento de desgaste, os blocos de lista proporcional/reserva e outras otimizações tendem a fazer com que as gravações adquiram locais físicos diferentes, ao contrário da reutilização de setor da mídia giratória.

Firmware

O firmware usado no armazenamento de estado sólido tende a ser complexo quando comparado com as contrapartes de mídia giratória. Muitas unidades usam vários núcleos de processamento para lidar com solicitações de entrada e atividades de coleta de lixo. Certifique-se de manter o firmware do dispositivo de estado sólido atualizado para evitar problemas conhecidos.

Danos pela leitura de dados e nivelamento do desgaste

Uma abordagem comum de coleta de lixo (GC) para armazenamento de estado sólido ajuda a evitar danos pela leitura repetida dos dados. Ao ler a mesma célula repetidamente, é possível que a atividade dos elétrons possa vazar e causar danos às células vizinhas. O armazenamento de estado sólido protege os dados com vários níveis de código de correção de erros (ECC) e outros mecanismos.

Um desses mecanismos diz respeito ao nivelamento do desgaste. O armazenamento de estado sólido controla a atividade de leitura e gravação no dispositivo de armazenamento. A coleta de lixo pode determinar pontos de acesso frequente ou locais de desgaste mais rápido do que outros locais. Por exemplo, a GC determina que um bloco esteve em um estado somente leitura por um período de tempo e precisa ser movido. Este movimento é geralmente para um bloco com mais desgaste, de modo que o bloco original possa ser usado para gravações. Isso ajuda a equilibrar o desgaste da unidade, mas move os dados somente leitura para um local com mais desgaste e, matematicamente, aumenta as chances de falha, mesmo que ligeiramente.

Outro efeito colateral do nivelamento do desgaste pode ocorrer com o SQL Server. Suponha que você execute DBCC CHECKDB e ele relate um erro. Se você executá-lo uma segunda vez, há uma pequena chance de que DBCC CHECKDB informe erros adicionais ou um padrão diferente de erros, porque a atividade de GC do armazenamento de estado sólido pode fazer alterações entre as execuções de DBCC CHECKDB.

Erro 665 do sistema operacional e desfragmentação

A mídia giratória precisa manter os blocos próximos uns dos outros para reduzir o movimento da cabeça da unidade e aumentar o desempenho. O armazenamento em estado sólido não tem uma cabeça física, o que elimina o tempo de busca. Muitos dispositivos de estado sólido são projetados para permitir operações paralelas em diferentes blocos em paralelo. Isso significa que a desfragmentação da mídia de estado sólido é desnecessária. As atividades seriais são os melhores padrões de E/S para maximizar a produtividade de E/S em dispositivos de armazenamento de estado sólido.

Observação

O armazenamento de estado sólido se beneficia do recurso trim, um comando no nível do sistema operacional (SO) que apaga blocos que não são mais considerados em uso. No Windows, use a ferramenta Otimizar Unidades para definir um agendamento semanal para otimizar as unidades.

Recomendações:

  • Use um controlador com bateria apropriado, projetado para otimizar as atividades de gravação. Isso pode melhorar o desempenho, reduzir o desgaste da unidade e os níveis de fragmentação física.

  • Considere usar o sistema de arquivos ReFS para evitar as limitações de atributo do NTFS.

  • Verifique se os tamanhos de crescimento do arquivo estão dimensionados adequadamente.

Para obter mais informações sobre como solucionar o erro 665 do sistema operacional relacionado à fragmentação, consulte Erros 665 e 1450 do sistema operacional são relatados para arquivos do SQL Server.

Compactação

Contanto que a unidade mantenha a intenção de mídia estável, a compactação pode prolongar a vida útil da unidade e pode afetar positivamente o desempenho. No entanto, alguns firmwares já podem compactar dados invisivelmente. Lembre-se de testar novos cenários de armazenamento antes de implantá-lo em seu ambiente de produção.

Resumo

  • Mantenha procedimentos e processos adequados de backup e recuperação de desastres.
  • Mantenha o firmware do dispositivo atualizado.
  • Ouça atentamente as orientações dos fabricantes de hardware.

Considerações sobre cache e SQLIOSim

Para proteger totalmente seus dados, você deve garantir que todo o caching de dados seja tratado corretamente. Em muitas situações, isso significa que você deve desabilitar o cache de gravação da unidade.

Observação

Certifique-se de que qualquer mecanismo de cache alternativo possa lidar adequadamente com vários tipos de falha.

A Microsoft executou testes em várias unidades SCSI e IDE usando o utilitário SQLIOSim. Esse utilitário simula atividade de leitura/gravação assíncrona pesada para um dispositivo de dados simulado e um dispositivo de log. Para obter mais informações e detalhes sobre SQLIOSim, consulte Usar o utilitário SQLIOSim para simular a atividade do SQL Server em um subsistema de disco.

Muitos fabricantes de PCs encomendam as unidades com o cache de gravação desativado. No entanto, os testes mostram que esse pode nem sempre ser o caso, então você deve sempre testá-lo completamente. Se você tiver alguma dúvida sobre o status de cache do seu dispositivo de armazenamento, entre em contato com o fabricante e obtenha as configurações apropriadas de utilitário ou jumper para desabilitar as operações de cache de gravação.

O SQL Server requer que os sistemas ofereçam suporte à entrega garantida para mídia estável, conforme descrito nos Requisitos do Programa de Confiabilidade de E/S do SQL Server. Para obter mais informações sobre os requisitos de entrada e saída para o mecanismo de banco de dados do SQL Server, consulte Requisitos de entrada/saída (E/S) de disco do mecanismo de banco de dados do SQL Server.

Conteúdo relacionado