Início / dba / Perguntas / 21895
Accepted
royv
Asked: 2012-08-03 08:14:35 +0800 CST

O disco do sistema fica sem espaço ao executar consultas SQL pesadas no SQL Server 2012

  • 772

Sou bastante novo no SQL Server 2012, ficaria grato se alguém pudesse ajudar. Eu restaurei uma cópia de um banco de dados enorme para o SQL Server 2012 e tentei executar algumas consultas simples nele.

Estou tentando executar uma consulta SELECT em uma tabela de 136898115linhas de banco de dados. Esta SELECTconsulta tem apenas uma WHEREcláusula simples. Toda vez que executo essa consulta, ela falha porque o disco do sistema (a partição em que o Windows está instalado - C:\) fica sem espaço (essa partição tem apenas 6 GB de espaço livre) e não entendo o porquê. Defini meu tempdb para estar em uma unidade diferente, que possui mais de 14 terabytes de espaço livre. Claro que meu banco de dados está localizado em uma unidade diferente também.

O que faz minha partição do sistema ficar sem espaço? É o arquivo de página?

sql-server tempdb

4 respostas

  1. Best Answer

    Os resultados da consulta do SSMS são armazenados em cache na unidade C: por padrão. Vá para Ferramenta \ Opções. Ver anexo. Altere isso para outro volume com mais armazenamento e você deve ficar bem.

    insira a descrição da imagem aqui

    • 12

  2. Ok, eu descobri: Eric e eu estávamos certos!

    • O caminho na caixa de diálogo é como eu disse, apenas um caminho padrão para salvar os resultados da consulta.
    • Os resultados da consulta são armazenados em cache no disco (eu estava errado), mas na pasta temporária do perfil local ( C:\Users\<UserName>\AppData\Local\Tempno meu caso aqui). Verifiquei e não parece haver uma maneira óbvia de desativar esse cache.

    Então as dicas são:

    • Evite executar o SSMS diretamente na caixa SQL
    • Não SELECT *de uma tabela enorme no SSMS, a menos que o conjunto de resultados possa caber na pasta do perfil
    • Certifique-se de que a configuração de memória máxima do SQL Server esteja configurada corretamente (pode ou não ter contribuído para esse problema em relação ao crescimento do arquivo de página)
    • 11

  3. Acabei de sofrer o mesmo problema. Depois de ler as respostas acima, encontrei o seguinte.

    Ferramentas | Opções não é a resposta. O meu estava definido como Y: drive, mas observei enquanto minha consulta era executada e o espaço na unidade C: mergulhava de 2,9 GB para 5,04 MB (antes de matar a consulta).

    Então eu pensei que provavelmente está armazenando resultados em cache (como eles são muito grandes com cada linha retornada contendo um grande pedaço de XML) para o diretório Temp, que é o que Jon disse, mas ele não tinha certeza de como você mudaria isso.

    O que eu fiz para mudar onde os arquivos temporários são gravados foi abrir minhas variáveis ​​​​de ambiente e editar as variáveis ​​​​do usuário TEMP e TMP (que foram definidas como C:\Temp) para gravar em Z:\Temp.

    Posso confirmar que, após essa alteração, observei a consulta criar um arquivo muito grande no meu diretório Z:\Temp.

    • 8

  4. Pergunta realmente antiga, mas eu estava tendo o mesmo problema ou semelhante. A execução de um determinado procedimento armazenado veria GBs consumidos na minha unidade C: até que ela fosse completamente preenchida.

    No meu caso, os arquivos em crescimento eram os que começavam tempdblocalizados por padrão em:

    C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA

    Você pode verificar isso para seu próprio ambiente executando:

    Use master
GO

SELECT 
name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

    Você pode então realocá-lo para uma unidade/pasta diferente:

    USE master;
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = tempdev, FILENAME = 'E:\tempdb.mdf');
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = templog, FILENAME = 'E:\templog.ldf');
GO

    A explicação completa está aqui https://www.mytechmantra.com/learnsqlserver/how-to-move-tempdb-to-new-drive-in-sql-server/

    • 0

relate perguntas