Início / dba / Perguntas / 53003
Accepted
Peter
Asked: 2013-11-09 01:18:44 +0800 CST

DBCC SHRINKDATABASE TRUNCATEONLY - 2008R2 vs 2012

  • 772

Estou um pouco confuso. O TRUNCATEONLYparâmetro foi alterado no SQL 2012 ou a documentação está errada no SQL 2008 R2?

2008 R2

Libera todo o espaço livre no final do arquivo para o sistema operacional, mas não executa nenhuma movimentação de página dentro do arquivo. O arquivo de dados é reduzido apenas até a última extensão alocada. target_percent será ignorado se especificado com TRUNCATEONLY.

TRUNCATEONLY é aplicável apenas a arquivos de dados. Os arquivos de log não são afetados.

A última declaração me faz pensar que isso não tem nenhum efeito nos arquivos de log?

2012

Libera todo o espaço livre no final do arquivo para o sistema operacional, mas não executa nenhuma movimentação de página dentro do arquivo. O arquivo de dados é reduzido apenas até a última extensão alocada. target_percent será ignorado se especificado com TRUNCATEONLY.

TRUNCATEONLY afeta o arquivo de log. Para truncar apenas o arquivo de dados, use DBCC SHRINKFILE.

A última declaração agora me diz que afeta apenas o arquivo de log?

Então, a funcionalidade foi alterada ou há um erro na documentação ou minha interpretação está errada?

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    TRUNCATEONLY afeta os arquivos LOG e DATA em 2008. No BOL para SQL Server 2012, a mensagem simplesmente indica que, se você deseja apenas REDUZIR o arquivo de banco de dados, deve usar DBCC SHRINKFILE, que permitirá reduzir os dados ou o log arquivos.

    Para 2008, está claramente indicado que TRUNCATEONLY afeta apenas os arquivos DATA.

    Vamos testar. Para visualizar o que acontece TRUNCATEONLYcom o SHRINKDATABASE, aqui está um resumo do que aconteceu com um banco de dados chamado performanceque instalei localmente.

    SELECT @@VERSION;
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)
   Jun 28 2012 08:36:30
   Copyright (c) Microsoft Corporation
   Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) 

USE performance;

    Corri DBCC LOGINFOapenas para dar uma olhada no log de transações e descobri que todos os arquivos de log virtual após cerca de 200 estavam inativos, status = 0. Em meu banco de dados de desempenho, todos os VLFs inativos podem ser truncados e o espaço pode ser devolvido para o sistema operacional.

    Aqui está um exemplo de saída de LOGINFO.

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
------ -------- ----------- ------ ------ ------ -----------------
2      253952   8192        23     2      64     0
2      253952   262144      24     2      64     0
2      270336   516096      25     2      64     24000000013400005

    Eu então corri DBCC SQLPERF(LOGSPACE)e obtive a seguinte saída

    DBCC SQLPERF(LOGSPACE)
/*
Database Name   Log Size (MB)   Log Space Used (%)  Status
Performance          9870,867             3,395626  0
*/

    eu então corri

    DBCC SHRINKDATABASE(PERFORMANCE, truncateonly)

    e obtive o seguinte resultado

    /*
DbId    FileId  CurrentSize MinimumSize UsedPages   EstimatedPages
8       1       66464       288         44944       44944
8       2       116584      72          116584      72
*/

    Em seguida, eu recorri

    DBCC SQLPERF(LOGSPACE)

    e pegou

    /*
Database Name   Log Size (MB)   Log Space Used (%)  Status
Performance     910,8047        37,08699            0
*/

    SHRINKDATABASEcom TRUNCATEONLYdevolveu mais de 9 GB de espaço disponível do arquivo de log de transações de volta ao sistema operacional.

    Eu tentei o mesmo experimento com outro banco de dados chamadoperformance2

    sp_spaceused

/*
Performance2 52.19 MB   22.81 MB
*/

DBCC SHRINKDATABASE(Performance2, truncateonly)

sp_spaceused

/*
database_name   database_size   unallocated space
Performance2 31.13 MB   21.13 MB
*/

    O que devolveu 20 MB ao sistema operacional. Usando o SQL Server 2008, SHRINKDATABASE TRUNCATEONLYreduz os arquivos de log de dados e transações.

    • 5

  2. Acabei de testar com um banco de dados temporário e usar a opção TRUNCATEONLY fez com que o arquivo de dados e o arquivo de log fossem reduzidos.

    Acredito que o que eles estão tentando esclarecer é que a opção TRUNCATEONLY altera o comportamento ao reduzir o arquivo de dados (ou seja, não reorganize nenhuma página de dados, apenas corte o espaço não utilizado no final), mas o arquivo de log ainda será encolheu normalmente.

    Se meu entendimento da opção estiver correto, provavelmente esta é uma maneira melhor de descrevê-la:

    O arquivo de log ainda será reduzido normalmente ao usar a opção TRUNCATEONLY. Esta opção afeta apenas o comportamento ao reduzir os arquivos de dados. Para truncar apenas o arquivo de dados, use DBCC SHRINKFILE.

    • 2

relate perguntas