Partilhar via

Fundamentos de E/S do SQL Server

Aplica-se a:SQL ServerInstância Gerida do Azure SQLSQL Server na VM do Azure

O objetivo principal de um banco de dados do SQL Server é armazenar e recuperar dados, portanto, a entrada/saída de disco (E/S) intensiva é uma característica central 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 serem concluídas, o SQL Server se concentra em tornar a E/S altamente eficiente.

Os subsistemas de armazenamento para o SQL Server são fornecidos em múltiplos formatos, incluindo discos mecânicos e armazenamento em estado sólido. Este artigo fornece detalhes sobre como utilizar os princípios de caching de unidade de disco para melhorar a E/S do Mecanismo de Base de Dados.

O SQL Server requer que os sistemas ofereçam suporte garantido à 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 de disco (E/S) do Mecanismo de Banco de Dados do SQL Server.

E/S de disco

O gerenciador de buffer só executa 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 do gerenciador 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 que o thread de chamada continue o processamento enquanto a operação de E/S ocorre em segundo plano. Em certas circunstâncias (por exemplo, I/O de log desalinhado), podem ocorrer E/S síncronas.

  • Todas as E/S são emitidas nos threads de chamada, a menos que a opção de E/S de afinidade esteja em uso. A opção de máscara de E/S de afinidade vincula a E/S de disco do SQL Server a um subconjunto especificado de CPUs. Em ambientes OLTP (processamento transacional online) de alto padrão do SQL Server, esta extensão pode melhorar o desempenho dos processos do SQL Server emitindo E/S.

  • As operações de E/S de várias páginas são realizadas com E/S scatter-gather, o que permite que os dados sejam transferidos para dentro ou para fora de áreas não contíguas da memória. Isso significa que o SQL Server pode preencher ou liberar rapidamente o cache do buffer, evitando várias solicitações de E/S físicas.

Solicitações de E/S longas

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

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 operação de E/S longa pode ser uma leitura ou uma escrita; atualmente, não é indicado na mensagem. As mensagens de E/S longas são avisos, não erros. Eles não indicam problemas com o SQL Server, mas com o sistema de E/S subjacente. As mensagens são relatadas para ajudar o administrador do sistema a encontrar a causa dos tempos de resposta insatisfatórios do SQL Server mais rapidamente e para 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 tempo e se o tempo é justificável.

Causas de solicitações de E/S longas

Uma mensagem de E/S longa pode indicar que uma E/S está permanentemente bloqueada e nunca será concluída (conhecida como E/S perdida), ou simplesmente que ainda não foi concluída. Não é possível dizer pela mensagem qual é o cenário, apesar de uma perda de entrada/saída geralmente resultar em um tempo limite de travamento.

Operações de E/S longas geralmente indicam uma carga de trabalho do SQL Server demasiado intensa para o subsistema de disco. Um subsistema de disco inadequado pode ser indicado quando:

  • Várias mensagens de E/S longas aparecem no log de erros durante uma carga de trabalho pesada do SQL Server.
  • Os contadores do Monitor de Desempenho mostram latências de disco longas, longas filas de disco ou nenhum tempo ocioso de disco.

E/S longas também podem ser causadas por um componente no caminho de E/S (por exemplo, um driver, controlador ou firmware) adiando continuamente 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 de caminho). Isso pode ser difícil de corroborar com a ferramenta Monitor de Desempenho porque a maioria das E/S está sendo atendida prontamente. As solicitações de E/S longas podem ser agravadas por cargas de trabalho que executam grandes quantidades de E/S sequenciais, como backup e restauração, varreduras de tabelas, classificação, criação de índices, carregamentos em massa e zeragem de arquivos.

I/Os longas isoladas que não parecem relacionadas com nenhuma das 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 ineficientes ou controladores de filtro

A E/S lenta pode ser causada por consultas que não são escritas de forma eficiente ou não estão ajustadas corretamente com í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 verificam arquivos de banco de dados. Esse software de varredura pode se estender para a camada de rede, que adiciona latência de rede, afetando indiretamente a latência do banco de dados. Embora o cenário descrito sobre a E/S de 15 segundos seja mais comum em componentes de hardware, uma latência de E/S menor é observada com mais frequência em consultas não otimizadas ou em programas antivírus mal configurados.

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

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

Cache de escrita em controladores de armazenamento

As transferências de E/S realizadas sem o uso de um cache podem ser significativamente mais longas 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 destinam-se 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 à busca de armazenamento e tempos de gravação usando as várias otimizações do controlador de cache.

Observação

Alguns fornecedores de armazenamento usam memória persistente (PMEM) como armazenamento em vez de 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 de cache de gravação (também chamado de cache write-back) pode melhorar o desempenho do SQL Server. Os controladores de 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 sistema de gerenciamento de banco de dados transacional (DBMS) crítico de dados. Esses recursos de design devem preservar os dados armazenados em cache se ocorrer uma falha do sistema. Usar uma fonte de alimentação ininterrupta externa (UPS) para conseguir isso geralmente não é suficiente, porque podem ocorrer modos de falha que não estão relacionados à alimentação.

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

Registo de escrita antecipada

As instruções de modificação de dados do SQL Server geram gravações lógicas de página. Esse fluxo de gravações pode ser retratado como indo para dois lugares: o log e o próprio banco de dados. Por motivos 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 apenas momentaneamente adiadas até o momento COMMIT. Eles não são armazenados 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 de gravação antecipada (WAL).

Protocolo WAL (write-ahead logging)

O termo protocolo é uma excelente maneira de descrever a WAL. A WAL utilizada pelo SQL Server é conhecida como ARIES (Algorithm for Recovery and Isolation Exploiting Semantics). Para obter mais informações, consulte 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 forma consistente e protegida, a WAL também descreve o protocolo para proteger dados. Todas as versões do SQL Server abrem os arquivos de log e dados usando a função Win32 CreateFile . O dwFlagsAndAttributes membro 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 FILE_FLAG_WRITE_THROUGH sinalizador. Esta opção instrui o sistema a escrever através de qualquer cache intermediário e ir diretamente para o armazenamento. O sistema ainda pode armazenar em cache operações de gravação, mas não pode liberá-las preguiçosamente. Para obter mais informações, consulte CreateFileA.

A FILE_FLAG_WRITE_THROUGH opção garante que, quando uma operação de gravação retorna a conclusão bem-sucedida, os dados são armazenados corretamente no 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 dependem de um capacitor e não de uma solução alimentada por 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 crescer em tamanho, os caches tornam-se maiores e podem expor maiores quantidades de dados durante uma falha.

Para obter mais informações sobre o suporte de FUA pela distribuição Linux e o seu efeito no SQL Server, consulte SQL Server On Linux: Forced Unit Access (FUA) Internals.

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 atômicas de trabalho que são totalmente aplicadas ou totalmente revertidas. O log de transações write-ahead 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. Vários efeitos não ideais, no mundo real, 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 dirigido 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 um aplicativo 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 este processo ocorre sem intervenção humana. Sempre que as estações de trabalho cliente reiniciavam, os usuários encontravam todos os seus dados presentes, até a última transação que inseriam.

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ítico, ele poderá comprometer a capacidade de recuperação do SQL Server, corrompendo o banco de dados. Isso pode ocorrer se o controlador intercetar gravações de log de transações do SQL Server e armazená-las em buffer numa cache de hardware na placa controladora, mas não preservar essas páginas já escritas durante uma falha do sistema.

Controladores de cache de gravação e de dispositivos de armazenamento

A maioria dos controladores de cache para dispositivos de armazenamento realizam cache de escrita. A função de cache de gravação nem sempre pode ser desativada.

Mesmo que o servidor use um no-break, tal não garante a segurança das gravações em cache. Podem ocorrer muitos tipos de falhas do sistema que uma UPS não resolve. Por exemplo, um erro de paridade de memória, um 'trap' do sistema operativo (SO) ou uma falha de hardware que leva a uma reinicialização do sistema podem causar uma interrupção incontrolada do sistema. Uma falha de memória no cache de escrita do hardware também pode resultar na perda de informações vitais do log.

Outro problema potencial relacionado com um controlador de cache de escrita pode surgir durante o encerramento do sistema. Não é incomum alternar 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 esperar até que toda a atividade de armazenamento cesse antes de reiniciar o sistema, as gravações em cache ainda podem estar presentes no controlador. Quando a combinação de Ctrl+Alt+Del teclas é pressionada ou um botão de redefinição de hardware é pressionado, as gravações 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 causas possíveis de descartar dados de cache sujos, o que seria seguro para uso por um servidor de banco de dados. Alguns desses recursos de design incluiriam intercetar o sinal do barramento RST para evitar a reinicialização descontrolada do controlador de cache, backup de bateria integrada e memória espelhada ou de verificação e correção de erros (ECC). Verifique com seu fornecedor de 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 e acima de tudo, responsável pelo armazenamento e recuperação precisos de dados, mesmo no caso de falhas inesperadas do sistema.

O sistema deve garantir a atomicidade e durabilidade das transações, ao mesmo tempo em que contabiliza a execução atual, múltiplas transações e vários pontos de falha. Isto é muitas vezes referido como as 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 da Microsoft para obter mais esclarecimentos sobre cache e discussões de modo de falha alternativo:

Recomendam-se também os seguintes documentos:

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

Soluções de cache alimentadas por bateria

Os sistemas de controladores de cache aprimorados desabilitam o cache em disco e fornecem uma solução funcional de cache com bateria reserva. Esses caches podem manter os dados no cache por vários dias e até mesmo permitir que o cartão de cache seja colocado em um segundo computador. Quando a alimentação é restaurada corretamente, os dados não gravados são completamente descartados antes que qualquer acesso adicional aos dados seja permitido. Muitos deles permitem que a porcentagem de cache de leitura versus gravação seja estabelecida para um desempenho ideal. Alguns contêm grandes áreas de armazenamento de memória. Alguns fornecedores de hardware fornecem sistemas de cache com suporte de bateria de alto desempenho e vários gigabytes de cache. Eles podem melhorar significativamente o desempenho do banco de dados. O uso de soluções de cache com bateria fornece durabilidade e consistência dos dados esperados pelo SQL Server.

Implementações do subsistema 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 drives baseados em SCSI. Há várias razões para isso. A seção a seguir descreve genericamente as considerações de 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 tempos médios entre falhas do que outras implementações.
  • Contenha heurísticas sofisticadas para ajudar a prever falhas iminentes.

Observação

O SQL Server é suportado em componentes da tecnologia Internet Small Computer System Interface (iSCSI) que atendem aos requisitos do Programa de Compatibilidade de Hardware do Windows. Embora o SQL Server não interaja diretamente com o iSCSI, ele opera perfeitamente porque o Windows apresenta o armazenamento iSCSI como unidades padrão. Isso permite que o SQL Server leia e grave no armazenamento remoto em nível de bloco em redes IP. Como o iSCSI depende de redes, você pode enfrentar atrasos ou gargalos, portanto, deve otimizar o desempenho de cache do servidor e minimizar a latência. Para obter mais informações, consulte Limites de escalabilidade do servidor de destino iSCSI.

Não SCSI

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

  • São normalmente fabricados para uso leve e médio.
  • Normalmente são direcionados a aplicativos baseados em um único usuário.

Os controladores não SCSI baseados em desktop exigem mais largura de banda do processador principal (CPU) e são frequentemente limitados por 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 um disco ocioso enquanto o outro disco processa o comando pendente. Os sistemas RAID baseados em tecnologias de desktop podem experimentar esses sintomas e ser muito afetados pela resposta mais lenta. 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 sobre armazenamento

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

Os tamanhos dos dispositivos de armazenamento continuam a aumentar. Unidades de armazenamento de baixo custo e grande capacidade podem ser apelativas. Mas ao configurar a unidade para o SQL Server e suas necessidades de tempo de resposta comercial, você deve considerar cuidadosamente os seguintes problemas:

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

Discos rígidos mecânicos

As unidades mecânicas utilizam discos magnéticos rotativos para armazenar dados. Eles estão disponíveis em várias capacidades e fatores de forma, como IDE, SATA, SCSI e SAS (Serial Attached SCSI). Algumas unidades SATA incluem construções de previsão de falhas. As unidades SCSI são projetadas para ciclos de trabalho mais pesados e taxas de falha reduzidas.

O cache de unidade deve ser desabilitado para usar a unidade com o SQL Server. Por padrão, o cache da unidade está habilitado. No Windows Server, utilize a guia Propriedades de Disco> guia Hardware para aceder à Propriedades>Política para controlar as definições de cache da unidade.

Observação

Algumas unidades não respeitam esta configuração. Essas unidades exigem um utilitário de fabricante específico para desativar o cache.

Os sistemas baseados em IDE e ATA podem adiar comandos do anfitrião quando executam atividades como ajuste de blocos defeituosos. Isso pode levar a períodos de atividade de E/S paralisada.

Os benefícios do SAS incluem filas avançadas de até 256 níveis, bem como a organização de filas como "cabeça da fila" e o processamento fora de ordem. O backplane SAS é projetado de forma a permitir 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 de cache de mídia estáveis corretos. A complexidade do projeto do controlador aumenta com técnicas avançadas de segurança de dados, como espelhamento.

Armazenamento em estado sólido

O armazenamento em estado sólido tem vantagens em relação aos discos rígidos mecânicos (giratórios), mas é suscetível a muitos dos mesmos padrões de falha que os meios giratórios. O armazenamento de estado sólido é conectado ao seu servidor usando várias 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 falhas de energia, como um controlador de cache alimentado por bateria.

Problemas comuns causados por uma falha de energia incluem:

  • Corrupção de bits: Os registros exibem erros de bits aleatórios.
  • Flying escreve: Discos bem formados acabam no lugar errado.
  • Shorn escreve: As operações são parcialmente feitas em um nível abaixo do tamanho esperado do setor.
  • Corrupção de metadados: Os metadados no FTL estão corrompidos.
  • Dispositivo sem resposta: o dispositivo não funciona ou, na maioria das vezes, não funciona.
  • Unserializability: O estado final de armazenamento não resulta de uma ordem de operação serializável.

Artigo 512.º

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 eliminação de 1 MB. O uso de setores alinhados de 512 bytes para o dispositivo de log do SQL Server pode provocar mais atividades de leitura/modificação/gravação (RMW), o que pode contribuir para um desempenho mais lento e o desgaste do disco.

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

0xFFFFFFFF

Uma unidade recém-formatada geralmente contém todos os zeros. Um bloco apagado de um dispositivo de estado sólido consiste completamente em 1, resultando em todos os caracteres 0xFF numa leitura bruta de um bloco apagado. No entanto, é incomum para um usuário ler um bloco apagado durante operações normais de E/S.

Estampagem de padrões

Uma técnica que usamos no passado é escrever um padrão conhecido para toda a unidade. Enquanto executamos atividades no banco de dados contra essa mesma unidade, podemos detectar comportamento incorreto (leitura obsoleta / gravação perdida / leitura de deslocamento incorreto / etc.) quando o padrão aparece inesperadamente.

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

firmware

O firmware usado no armazenamento de estado sólido tende a ser complexo quando comparado com os equivalentes de mídia giratória. Muitas unidades de disco 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.

Leia os dados sobre danos e nivelamento de desgaste

Uma abordagem comum de coleta de lixo (GC) para armazenamento em estado sólido ajuda a evitar danos repetidos em dados de leitura. Ao ler a mesma célula repetidamente, é possível que a atividade eletrônica 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 recolha de lixo pode determinar zonas críticas ou locais que se desgastam mais rapidamente do que outros locais. Por exemplo, o GC determina que um bloco esteve em estado de somente leitura por algum tempo e precisa ser transferido. Este movimento é geralmente para um bloco que já está mais degradado, de modo que o bloco original pode ser usado para registos. Isso ajuda a equilibrar o desgaste da unidade, mas move dados somente leitura para um local que tem mais desgaste e aumenta matematicamente as chances de falha, mesmo que ligeiramente.

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

Erro 665 do SO 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 a 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. Isto significa que a desfragmentação dos meios de comunicação de estado sólido é desnecessária. As atividades seriais são os melhores padrões de E/S para maximizar a taxa de transferência 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 são considerados não mais em uso. No Windows, utilize a ferramenta Otimizar unidades para definir uma programação semanal de otimização das unidades.

Recomendações:

  • Use um controlador apropriado e alimentado por bateria projetado para otimizar as atividades de gravação. Isto pode melhorar o desempenho, reduzir o desgaste do disco e os níveis de fragmentação física.

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

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

Para mais informações sobre a resolução do erro 665 do sistema operacional relacionado à fragmentação, consulte Os erros 665 e 1450 do sistema operacional são relatados para arquivos do SQL Server.

Compressão

Desde que a unidade continue a ter como objetivo manter meios estáveis, a compressão pode prolongar a vida útil da unidade e pode ter um efeito positivo no desempenho. No entanto, alguns firmware podem já comprimir dados de forma invisível. 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 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 cache de dados seja tratado corretamente. Em muitas situações, deve-se desativar a memória cache de escrita da unidade.

Observação

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

A Microsoft realizou testes em várias unidades SCSI e IDE usando o utilitário SQLIOSim . Este utilitário simula atividade de leitura/gravação assíncrona pesada para um dispositivo de dados simulado e 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 PC encomendam as unidades com o cache de gravação desativado. No entanto, os testes mostram que nem sempre é esse o caso, por isso 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 o utilitário apropriado ou as configurações de jumper para desativar 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 de disco (E/S) do Mecanismo de Banco de Dados do SQL Server.

Conteúdo relacionado

  • Last updated on