Compartilhar via

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

  • Artigo

Este artigo ajuda a resolver o problema em que os erros 1450 e 665 do sistema operacional são relatados para arquivos de banco de dados durante a execução DBCC CHECKDBdo , a criação de um instantâneo do banco de dados ou o crescimento do arquivo.

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

Sintomas

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

  • Você cria um instantâneo de banco de dados 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 instantâneo de banco de dados em um banco de dados espelho.
  • Você executa a DBCC CHECKDB família de comandos para verificar 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

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

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

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

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 observar 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 de não rendimento relatado no log de erros do SQL Server e que o SQL Server gera um despejo de memória.

Causa

Esse problema ocorre se um grande número de ATTRIBUTE_LIST_ENTRY instâncias for necessário para manter um arquivo altamente fragmentado no NTFS. Se o espaço estiver próximo a 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 pesada de arquivos pode levar ao esgotamento de atributos e ao erro 665 resultante. Esse comportamento é explicado no seguinte artigo da base de conhecimento: Um arquivo muito fragmentado em um volume NTFS pode não crescer além de um determinado tamanho.

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

Se você executar backups de banco de dados em um conjunto de arquivos localizados no mesmo volume, ou se estiver copiando dados em massa (BCP) para vários arquivos no mesmo volume, as gravações podem acabar em locais adjacentes, mas pertencentes a arquivos diferentes. Por exemplo, um fluxo grava para deslocamento entre 201 e 400, o outro fluxo grava 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 do arquivo 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 histórico completo de como o Mecanismo do SQL Server usa arquivos esparsos NTFS e fluxos de dados alternativos, consulte Mais informações.

Solução

Considere usar uma ou mais das seguintes opções para resolver 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 NTFS atual, deverá reformatar 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

    O SQL Server 2012 e versões anteriores usavam fluxos de arquivos nomeados em vez de arquivos esparsos para criar CHECKDB instantâneos. O ReFS não dá suporte a fluxos de arquivos. A execução DBCC CHECKDB em arquivos do SQL Server 2012 no ReFS pode resultar em erros. Para obter mais informações, consulte a observação em Como DBCC CHECKDB cria um banco de dados de instantâneo interno a partir do SQL Server 2014.

  2. Desfragmente o volume em que residem os arquivos de banco de dados. Certifique-se de que seu utilitário de desfragmentação seja transacional. Para obter mais informações sobre como desfragmentar unidades em que os arquivos do SQL Server residem, consulte Precauções ao desfragmentar unidades de banco de dados do SQL Server e Recomendações. Você deve desligar o 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 maneira diferente em mídias SSD (unidades de estado sólido) e normalmente não resolve o problema. Copiar o(s) arquivo(s) e permitir que o firmware do 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 o DBCC.

  3. Cópia de arquivo - executar uma cópia do arquivo pode permitir uma melhor aquisição de espaço porque os bytes podem ser compactados no processo. Copiar o arquivo (ou movê-lo para um volume diferente) pode reduzir o uso de atributos e evitar o erro 665 do sistema operacional. 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 aliviar esse problema porque torna o ATTRIBUTE_LIST_ENTRY maior. Essa opção pode não ser útil ao usar DBCC CHECKDB porque a última cria um arquivo esparso para o instantâneo do banco de dados.

    Observação

    Para sistemas que executam o Windows Server 2008 R2 e o Vista, primeiro você precisa aplicar o hotfix do artigo da base de dados de conhecimento 967351 antes de usar a /L opção 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 probabilidade de introduzir o esgotamento de atributos. Além disso, no processo de movimentação de dados, os arquivos serão organizados de forma compacta 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. Reconstrua os índices clusterizados das tabelas existentes, o que espalhará automaticamente os dados de cada tabela entre os oito arquivos. Se uma tabela não tiver um índice clusterizado, crie um e descarte-o para fazer 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 do 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 forem as ocorrências de crescimento automático e quanto maior o tamanho do incremento de crescimento, menor será a probabilidade de fragmentação do arquivo.

  7. Reduza o tempo de vida dos comandos usando os aprimoramentos de DBCC CHECK desempenho e, assim, evite os erros 665: Melhorias para o comando DBCC CHECKDB podem resultar em desempenho mais rápido quando você usa a opção PHYSICAL_ONLY. Lembre-se de que a execução DBCC CHECKDB com PHYSICAL_ONLY switch não garante 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 faixas), planeje cuidadosamente o número de arquivos MAXTRANSFERSIZE e BLOCKSIZE (consulte BACKUP). O objetivo é reduzir os fragmentos no sistema de arquivos, o que geralmente é feito gravando os pedaços de bytes maiores juntos em um arquivo. Você pode considerar a distribuição dos arquivos em vários volumes para obter um desempenho mais rápido e reduzir a fragmentação.

  9. Se você estiver usando o 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 gravar vários fluxos em volumes diferentes para evitar a fragmentação ou reduzir o número de gravações paralelas.

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

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

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

Mais informações