none
SHRINK sem efeito

    Frage

  • Ola senhores estou com um pequeno problema estou com uma base de 74gb apaguei, ou melhor dropei, varias tabelas de log antigas

    e depois disso dei um shrink mais não teve nem um efeito verifiquei se tinha espaço alocado e tinha nada mais nada menos que 64gb de espaço

    alocado alguma dirca?

    database_name     database_size      unallocated space
    ------------------------ ------------------       ------------------
    BASE                        74281.25 MB        64468.60 MB

    reserved           data               index_size         unused
    ------------------ ------------------ ------------------ ------------------
    10047128 KB        8228208 KB         1810368 KB         8552 KB

    • Verschoben Roberto F FonsecaModerator Sonntag, 20. Mai 2012 18:54 Movido para um forum mais adequado (De:SQL Server - Desenvolvimento Geral)
    Sonntag, 20. Mai 2012 10:24

Antworten

  • André,

    Vamos por partes:

    Normalmente o ShrinkFile é a melhor das soluções, tanto para arquivo de Dados como também para arquivo de Log, isso vai de encontro com alguns fatores.

    1 - Configuração da opção FillFactor para suas tabelas e PadIndex para seus dados;

    2 - Definição do modelo de recuperação do banco de dados;

    3 - Taxa de crescimento do seu bancos de dados;

    4 - Taxa de fragmentação de suas páginas de dados e índices;

    5 - Não adiante tentar fazer um ShrinkDatabase se o mesmo não sofreu nenhuma alteração de dados ou se somente ocorreu um reindexação dos índices, neste caso o Shrinfile vai fazer o processo de encolhimento;

    6 - Especificar valores muito pequenos não significa que você vai conseguir realizar o encolhimento;

    7 - Forçar o encolhimento dos dados sem realizar qualquer tipo de desfragmentação ou atualização dos índices, vai representar após o encolhimento um aumento no crescimento do arquivo de dados, quando os novos dados começarem a ser manipulados.

    8 - Se você não quer mais ter o log de transações, simplesmente mude o modelo de recuperação do banco de Simple e faça um DBCC ShrinkFile, sobre o mesmo.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    Montag, 28. Mai 2012 17:42
    Moderator
  • André, boa tarde.

    Entenda como é a arquitetura do arquivo de TLog e de dados para então realizar estes procedimentos. Devolver alguns GB para o sistema operacional geralmente fragmenta os índices e quando você desfragmenta estes índices o arquivo de dados acaba ficando bem maior do que era antes.

    Shrink de arquivos deve ser executado em situações emergenciais, onde há risco e não existe nenhuma possibilidade de aumentar a capacidade dos discos.

    Veja como funciona o TLog:

    http://sqldicas.com.br/dicas/arquitetura-do-transaction-log/

    Veja como o shrink não é só boato, é prejudicial mesmo:

    http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

    Abs!


    Luiz Eduardo MCP Windows Server 2003. MCTS Network Windows Server 2008. MCTS Application Windows Server 2008. MCTS SQL Server 2008. Se a resposta ajudou, colabore com o Fórum e classifique.

    Freitag, 8. Juni 2012 16:35
    Moderator

Alle Antworten

  • Olá André,

    é preciso que você forneça mais informações sobre o problema. Você quer fazer shrink de datafile ou transaction log ? Qual a versão usada do SQL Server ? que comando você utilizou para fazer o shrink ?

    Apenas para constar, se você fizer shrink no database e tiver backup de logs rodando em seu ambiente, você vai ficar impossibilitado de restaurar os backups dos logs, anteriores ao shrink, e dependendo da política de sua empresa, isso pode ser um problema.

    Abs.


    Angelo Máximo
    MCSA Windows 2003|MCTS SQL Server 2008
    angmms@gmail.com
    http://angmaximo.wordpress.com/

    Sonntag, 20. Mai 2012 23:37
  • Fala Máximo

    o mais importante e do datafile pois ele tem mais espaço alocado, estou usando o sql server 2008 r2, os comandos

    utilizados foram:

    USE [Base]
    GO
    DBCC SHRINKFILE (N'Base_Data' , 0, TRUNCATEONLY)
    GO
    USE [Base]
    GO
    DBCC SHRINKFILE (N'Base_TRN' , 0, TRUNCATEONLY)
    GO
    USE [Base]
    GO
    DBCC SHRINKFILE (N'Base_Data' , 0, TRUNCATEONLY)
    GO

    Montag, 21. Mai 2012 11:44
  • André, me parece que vocêorreta está executando o comando de forma incorreta. O parâmetro TRUNCATEONLY afeta apenas arquivos de log. Tente usar o seguinte comando:

    USE [BASE]

    GO

    DBCC SHRINKDATABASE (BASE, TRUNCATEONLY)

    GO

    Esse comando vai reduzir o arquivo de dados.

    Um detalhe que precisa ser verificado, é que o database não vai ser reduzido a um valor abaixo do que o tamanho mínimo do mesmo, definido nas propriedades do database.

    Mais detalhes sobre o comando citado você pode encontrar em http://msdn.microsoft.com/pt-br/library/ms190488(v=sql.105).aspx

    Não esqueça de postar os resultados.

    Abs.


    Angelo Máximo
    MCSA Windows 2003|MCTS SQL Server 2008
    angmms@gmail.com
    http://angmaximo.wordpress.com/

    Montag, 21. Mai 2012 22:32
  • Olá André.

    Esqueça o Data file(MDF) somente faça Shrink nele se antes você fizer um espurgo(apagar) de dados nas tabelas, caso contrario você perderá tempo.

    Quanto ao Transaction Log(arquivo de log) 

    Execute o seguinte comando para ver o tamando dos LOG de todos os DATABASES: DBCC SQLPERF ('logspace') = Log Space Used (%) quer dizer quantidade em % utilizado, verificando o tamanho, execute o seguinte comando para verificar quais são os nomes do arquivos de LOG.

    SP_HELPFILE - copie e cole abaixo

    DBCC SHRINKFILE ('Arquivo de log', 10)  - No lugar do 10 nunca deixe 0, pois ele irá crescer novamente de acorcor com o seu autogrowth, isso é ruim.

    As vezes isso não resolve.

    Neste caso você pode executar um Backup de log apenas para limpar o log:

    BACKUP LOG AquiNomeDataBase TO DISK = 'NUL'

    Depois execute SHRINKFILE  novamente.

    Qualquer dúvida estou a disposição.


    Keny Maciel da Silva
    DBA SQL-Server
    MCTS SQL Server 2008 Implementation and Maintenance
    Email: kenymaciel@gmail.com

    Sonntag, 27. Mai 2012 01:20
  • André,

    Vamos por partes:

    Normalmente o ShrinkFile é a melhor das soluções, tanto para arquivo de Dados como também para arquivo de Log, isso vai de encontro com alguns fatores.

    1 - Configuração da opção FillFactor para suas tabelas e PadIndex para seus dados;

    2 - Definição do modelo de recuperação do banco de dados;

    3 - Taxa de crescimento do seu bancos de dados;

    4 - Taxa de fragmentação de suas páginas de dados e índices;

    5 - Não adiante tentar fazer um ShrinkDatabase se o mesmo não sofreu nenhuma alteração de dados ou se somente ocorreu um reindexação dos índices, neste caso o Shrinfile vai fazer o processo de encolhimento;

    6 - Especificar valores muito pequenos não significa que você vai conseguir realizar o encolhimento;

    7 - Forçar o encolhimento dos dados sem realizar qualquer tipo de desfragmentação ou atualização dos índices, vai representar após o encolhimento um aumento no crescimento do arquivo de dados, quando os novos dados começarem a ser manipulados.

    8 - Se você não quer mais ter o log de transações, simplesmente mude o modelo de recuperação do banco de Simple e faça um DBCC ShrinkFile, sobre o mesmo.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    Montag, 28. Mai 2012 17:42
    Moderator
  • Olá Bom dia,

    Que tipo de shrink você quer fazer em que arquivo do BANCO (.mdf, .log)?

    Verifique o fator de preenchimento de suas páginas antes de executar este comando de shrinkfile e observe como está a taxa de crescimento dos arquivos de log.

    Mittwoch, 30. Mai 2012 14:36
  • André, boa tarde.

    Entenda como é a arquitetura do arquivo de TLog e de dados para então realizar estes procedimentos. Devolver alguns GB para o sistema operacional geralmente fragmenta os índices e quando você desfragmenta estes índices o arquivo de dados acaba ficando bem maior do que era antes.

    Shrink de arquivos deve ser executado em situações emergenciais, onde há risco e não existe nenhuma possibilidade de aumentar a capacidade dos discos.

    Veja como funciona o TLog:

    http://sqldicas.com.br/dicas/arquitetura-do-transaction-log/

    Veja como o shrink não é só boato, é prejudicial mesmo:

    http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

    Abs!


    Luiz Eduardo MCP Windows Server 2003. MCTS Network Windows Server 2008. MCTS Application Windows Server 2008. MCTS SQL Server 2008. Se a resposta ajudou, colabore com o Fórum e classifique.

    Freitag, 8. Juni 2012 16:35
    Moderator