Temos um servidor SQL Server 2016 (v13 SP3) Enterprise Edition hospedado em um cluster de failover do Windows/grupo de disponibilidade SQL com dois nós (primário e secundário). Os dois nós estão sendo executados em instâncias AWS EC2 executando o Windows Server 2012 R2 de 64 bits (NT 6.3).
No início desta semana, o servidor começou a responder com este erro:
Could not allocate space for object 'dbo.Batches'.'pk_Batches_BatchID' in database 'XXX' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
No início, isso parecia bastante simples: percebemos que tínhamos sido descuidados e permitido que os dados e/ou arquivos de log ficassem muito grandes. Os arquivos estavam definitivamente cheios, sem nenhum espaço não alocado neles. Achamos que só precisávamos aumentar a unidade do Windows (NTFS) (apoiada pelo AWS EBS nos bastidores). O banco de dados 'XXX' possui um arquivo de log e dois arquivos de dados - os arquivos de dados são configurados para crescimento ilimitado (embora apenas 64 MB por vez) e o banco de dados possui apenas o grupo de arquivos 'PRIMARY' padrão, nenhum outro grupo de arquivos envolvido. Os arquivos de dados estão na unidade ‘D:’.
Mas a unidade ‘D:’ tem mais de 400 GB livres, então por que os arquivos de dados não estão crescendo?
Passamos muito tempo analisando o cluster do Windows e os grupos de disponibilidade do SQL, pois também víamos muitos erros sobre o status do AG indo para "Recuperando" e a função de cluster não sendo aplicada/sincronizada corretamente. Algumas alterações permitiram que o nó primário voltasse a funcionar por alguns minutos, mas depois travava novamente. (Por causa disso, nossa capacidade de inspecionar o próprio banco de dados 'XXX' era limitada.) Verificamos se o EBS estava tendo algum tipo de problema ou interrupção, mas não encontramos erros.
Percebemos que os servidores estão antigos e desatualizados. Percebemos que alguns diriam que usar/confiar no crescimento automático é uma má prática. Mas esta questão não é sobre práticas recomendadas - é como colocar esse servidor de produção atualmente inativo de volta em funcionamento?
A solução foi adicionar outro arquivo de dados!
Devido à rápida ascensão e queda do nó, tivemos que ativá-lo novamente ("Iniciar função" no cluster do Windows) e então correr para executar este comando:
ALTER DATABASE [XXX] ADD FILE ( NAME = N'XXX3', FILENAME = N'D:\DATA\XXX3.mdf' , SIZE = 1110884352KB, FILEGROWTH = 65536KB ) TO FILEGROUP [PRIMARY](Fazer isso por meio da IU era muito lento.)
Depois que fizemos isso, o problema desapareceu e o servidor/cluster permaneceu ativo!
(Antecipamos o tamanho da unidade/volume.)
Não consigo explicar adequadamente por que isso funcionou. A pessoa que descobriu isso disse que a Microsoft uma vez lhe disse que isso é causado por um bug no NTFS que não permite que os arquivos cresçam sob certas condições. Não consigo encontrar nada sobre isso em lugar nenhum, então não sei se isso é verdade.
Parece haver um equívoco comum (que eu também tive) aqui. Aparentemente, a ideia de que os arquivos em um grupo de arquivos cresceriam individualmente é falsa. Na verdade, um evento de crescimento automático estenderá todos os arquivos do grupo de arquivos ao mesmo tempo. Isso faz sentido, mas não parece explicar nada aqui: parece que significaria apenas que o Mecanismo de Banco de Dados estava tentando obter 128 MB em vez de 64 MB, para os quais há espaço mais que suficiente.
Agora, os dois arquivos de dados têm tamanhos diferentes: o primeiro arquivo tem 2.161.928 MB (~ 2 TB) e o segundo arquivo tem 1.084.912 MB (~ 1 TB). Informações sobre como funciona o algoritmo de preenchimento proporcional para grupos de arquivos crescentes sugerem que isso pode ter feito com que o mecanismo solicitasse 192 MB ou até 256 MB. Mas, novamente, ambos têm menos de 400 GB.
Há uma relação entre o comportamento de crescimento do grupo de arquivos e os sinalizadores de rastreamento 1117 e 1118 . Para registro, nenhum desses sinalizadores de rastreamento foi habilitado neste servidor. (Para sua informação, você pode verificar isso com
DBCC TRACESTATUS.) Não consegui descobrir se o serviço SQL Server foi iniciado com a-Eopção (extensões aumentadas).De uma forma ou de outra, parece que o mecanismo estava tentando alocar muito, muito, muito mais espaço de arquivo do que sugeriam as configurações de crescimento automático. Somente adicionando outro arquivo de dados e contornando efetivamente o crescimento automático é que conseguimos estender o tamanho do banco de dados e recuperá-lo.
Eu estava amaldiçoando a mensagem de erro 'imprecisa/enganosa' o tempo todo, mas ela dizia bem ali:
Create disk space by ...adding additional files to the filegroupdeveríamos ter feito isso desde o início.