Os erros do sistema operacional 665 e 1450 são relatados para arquivos SQL Server

  • Artigo

Este artigo ajuda você a resolve o problema em que os erros do sistema operacional 1450 e 665 são relatados para arquivos de banco de dados durante a execução DBCC CHECKDB, criando um Instantâneo de Banco de Dados ou crescimento de arquivo.

Versão original do produto: SQL Server
Número de KB original: 2002606

Sintomas

Suponha que você execute uma das seguintes ações em um computador que está executando SQL Server:

  • Você cria um banco de dados instantâneo em um banco de dados grande. Em seguida, você executa várias operações de modificação ou manutenção de dados no banco de dados de origem.
  • Você cria um banco de dados instantâneo em um banco de dados espelho.
  • Você executa a DBCC CHECKDB família de comandos para marcar a consistência de um banco de dados grande e também executa um grande número de alterações de dados nesse banco de dados.

Observação

SQL Server usa arquivos esparsos para essas operações: instantâneo de banco de dados e DBCC CHECKDB.

  • Backup ou restauração de bancos de dados.
  • Você executa cópia em massa por meio de BCP para vários arquivos usando execuções de BCP paralelas e gravando no mesmo volume.

Como resultado dessas operações, você pode notar um ou mais desses erros relatados no log de erros do SQL Server, dependendo do ambiente em que SQL Server está em execução.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

Além desses erros, você também pode notar os seguintes erros de tempo limite de trava:

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

Além disso, você também pode notar o bloqueio ao exibir várias exibições de gerenciamento dinâmico (DMV), como sys.dm_exec_requests e sys.dm_os_waiting_tasks.

Em casos raros, você pode observar um problema de agendador não produtivo relatado no log de erros SQL Server e que SQL Server gera um despejo de memória.

Motivo

Esse problema ocorrerá se um grande número de ATTRIBUTE_LIST_ENTRY instâncias for necessária para manter um arquivo fortemente fragmentado no NTFS. Se o espaço estiver ao lado de um cluster que já é rastreado pelo sistema de arquivos, os atributos serão compactados em uma única entrada. No entanto, se o espaço estiver fragmentado, ele deverá ser rastreado com vários atributos. Assim, a fragmentação de arquivo pesada pode levar ao esgotamento de atributos e ao erro resultante de 665. Esse comportamento é explicado no seguinte artigo do KB: um arquivo fortemente fragmentado em um volume NTFS pode não crescer além de um determinado tamanho.

Arquivos regulares e esparsos criados por SQL Server ou outros aplicativos podem ser fragmentados para esses níveis quando grandes quantidades de modificações de dados acontecem durante a vida desses arquivos instantâneo.

Se você executar backups de banco de dados em um conjunto de arquivos localizados no mesmo volume ou se você estiver copiando em massa dados (BCP-ing) para vários arquivos no mesmo volume, as gravações poderão acabar em locais adjacentes, mas pertencentes a arquivos diferentes. Por exemplo, uma gravação de fluxo para deslocamento entre 201 e 400, as outras gravações de fluxo de 401 a 600, o terceiro fluxo pode gravar de 601 a 800. Esse processo continua para outros fluxos também. Isso levará à fragmentação de arquivos na mesma mídia física. Cada um dos arquivos de backup ou fluxos de saída BCP pode esgotar o armazenamento de atributos, pois nenhum deles obtém armazenamento adjacente.

Para obter um plano de fundo completo de como SQL Server Engine usa arquivos esparsos do NTFS e fluxos de dados alternativos, confira Mais informações.

Resolução

Considere usar uma ou mais das seguintes opções para resolve esse problema:

  1. Coloque os arquivos de banco de dados em um volume ReFS (Sistema de Arquivos Resiliente), que não tem os mesmos ATTRIBUTE_LIST_ENTRY limites que o NTFS apresenta. Se você quiser usar o volume atual do NTFS, deverá fazer a reformat usando o ReFS depois de mover seus arquivos de banco de dados para outro lugar temporariamente. Usar o ReFS é a melhor solução de longo prazo para lidar com esse problema.

    Observação

    SQL Server versões anteriores e 2012 usaram fluxos de arquivos nomeados em vez de arquivos esparsos para criar CHECKDB instantâneos. O ReFS não dá suporte a fluxos de arquivos. Executar DBCC CHECKDB em SQL Server arquivos de 2012 no ReFS pode resultar em erros. Para obter mais informações, confira a nota em Como o DBCC CHECKDB cria um banco de dados instantâneo interno começando com SQL Server 2014.

  2. Desfragmentr o volume em que os arquivos de banco de dados residem. Verifique se o utilitário de desfragmentação é transacional. Para obter mais informações sobre como desfragmentar unidades em que SQL Server arquivos residem, consulte Precauções ao desfragmentar SQL Server unidades de banco de dados e recomendações. Você deve desligar SQL Server para executar essa operação nos arquivos. Recomendamos que você crie backups completos do banco de dados antes de desfragmentar os arquivos como medida de segurança. A desfragmentação funciona de forma diferente na mídia SSD (unidades de estado sólido) e normalmente não resolve o problema. Copiar os arquivos e permitir que o firmware SSD reempacote o armazenamento físico geralmente é uma solução melhor. Para obter mais informações, consulte Erro do Sistema Operacional (665 – Limitação do sistema de arquivos) Não apenas para DBCC.

  3. Cópia do arquivo – a execução de uma cópia do arquivo pode permitir uma melhor aquisição de espaço porque os bytes podem estar bem empacotados no processo. Copiar o arquivo (ou movê-lo para um volume diferente) pode reduzir o uso do atributo e pode impedir o erro do sistema operacional 665. Copie um ou mais arquivos de banco de dados para outra unidade. Em seguida, você pode deixar o arquivo no novo volume ou copiá-lo de volta para o volume original.

  4. Formate o volume NTFS usando a opção /L para obter um FRS grande. Essa escolha pode proporcionar alívio a esse problema porque torna o ATTRIBUTE_LIST_ENTRY maior. Essa escolha pode não ser útil ao usar DBCC CHECKDB porque esta última cria um arquivo esparso para o banco de dados instantâneo.

    Observação

    Para sistemas que executam o Windows Server 2008 R2 e o Vista, primeiro você precisa aplicar o hotfix do artigo KB 967351 antes de usar a opção /L com o format comando.

  5. Divida um banco de dados grande em arquivos menores. Por exemplo, se você tiver um arquivo de dados de 8 TB, poderá dividi-lo em oito arquivos de dados de 1 TB. Essa opção pode ajudar porque menos modificações aconteceriam em arquivos menores, portanto, menos propensos a introduzir o esgotamento de atributo. Além disso, no processo de movimentação de dados, os arquivos serão organizados compactamente e a fragmentação será reduzida. A seguir estão as etapas de alto nível, que descrevem o processo:

    1. Adicione os sete novos arquivos de 1 TB ao mesmo grupo de arquivos.
    2. Recompile os índices clusterizados das tabelas existentes, que espalharão automaticamente os dados de cada tabela entre os oito arquivos. Se uma tabela não tiver um índice clusterizado, crie um e solte-o para realizar o mesmo.
    3. Reduza o arquivo original de 8 TB, que agora está cerca de 12% cheio.

  6. Configuração de crescimento automático do banco de dados: ajuste a configuração de banco de dados de incremento de crescimento automático para adquirir tamanhos propícios ao desempenho de produção e empacotamento de atributos NTFS. Quanto menos frequentes as ocorrências de crescimento automático e maior o tamanho do incremento de crescimento, menor a possibilidade de fragmentação de arquivo.

  7. Reduza o tempo de vida dos DBCC CHECK comandos usando os aprimoramentos de desempenho e evite os 665 erros: melhorias no comando DBCC CHECKDB podem resultar em um desempenho mais rápido quando você usa a opção PHYSICAL_ONLY. Tenha em mente que executar DBCC CHECKDB com PHYSICAL_ONLY o switch não fornece uma garantia de que você evitará esse erro, mas reduzirá a probabilidade em muitos casos.

  8. Se você estiver executando backups de banco de dados em muitos arquivos (conjunto de listras), planeje cuidadosamente o número de arquivos MAXTRANSFERSIZE e BLOCKSIZE (consulte BACKUP). O objetivo é reduzir os fragmentos no sistema de arquivos que geralmente são realizados escrevendo os pedaços de bytes maiores juntos em um arquivo. Você pode considerar remover os arquivos em vários volumes para obter um desempenho mais rápido e redução da fragmentação.

  9. Se você estiver usando BCP para gravar vários arquivos simultaneamente, ajuste os tamanhos de gravação do utilitário, por exemplo, aumente o tamanho do lote BCP. Além disso, considere escrever vários fluxos em volumes diferentes para evitar a fragmentação ou reduzir o número de gravações paralelas.

  10. Para executar DBCC CHECKDB, você pode considerar a configuração de um grupo de disponibilidade ou um servidor de envio/espera de log. Ou use um segundo servidor em que você pode executar os DBCC CHECKDB comandos para descarregar o trabalho e evitar executar os problemas causados pela fragmentação pesada de arquivos esparsos.

  11. Quando você executar DBCC CHECKDB, se você executar o comando em um momento em que há pouca atividade no servidor de banco de dados, os arquivos esparsos serão pouco preenchidos. Quanto menos gravações nos arquivos reduzir a probabilidade de esgotamento de atributos no NTFS. Menos atividade é outro motivo para ser executado DBCC CHECKDB em um segundo servidor somente leitura, quando possível.

  12. Se você estiver executando SQL Server 2014, atualize para o Service Pack mais recente. Para obter mais informações, confira CORREção: erro do sistema operacional 665 ao executar o comando DBCC CHECKDB para o banco de dados que contém o índice columnstore no SQL Server 2014.

Mais informações