SHRINK sem efeito

[Andre Nascimento]

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 no mdf de espaço

alocado alguma dica?

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

Estou usando o sql server 2008 r2 os comandos utilisados são 

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_Log' , 0, TRUNCATEONLY)
GO

--

"O pessimista queixa-se do vento, o otimista espera que ele mude e o realista ajusta as velas." - Ward, William G.
Ass.: André
Cel: 8530-1277

[José Rodrigo Silva Oliveira]

Qual é o modelo de recovery?

[Andre Nascimento]

Ai e que ta e full

[José Rodrigo Silva Oliveira]

Da forma que vc fez funciona somente no simple. 

Voce tem que fazer o backup do log primeiro, depois disso execute os comandos novamente.

[Andre Nascimento]

Bom José em parte funcionou o espaço alocado ficou em 44gb poderem ele adicionou um ndf e outro ldf
fiquei sem entender pq nunca tinha visto isso

[Marina Marques]

Eu executo essa sequencia para fazer Shirink no Log das bases

use banco 

go

SELECT * FROM sys.database_files --para pegar o arquivo_log

--------------------------*************

use master

go

DECLARE @cmd   nvarchar(4000)

SELECT @cmd ='ALTER DATABASE ' + 'NomeBase' + ' SET RECOVERY SIMPLE' FROM sys.databases

EXEC sp_executesql @cmd

-----------------***************---

USE NomeBase

GO

DBCC SHRINKFILE(NomeBase_log, 10) 

use master

go

DECLARE @cmd   nvarchar(4000)

SELECT @cmd ='ALTER DATABASE ' + 'NomeBase' + ' SET RECOVERY FULL' FROM sys.databases

EXEC sp_executesql @cmd

--
----------------------------------------------
Att.
Marina Marques Malvino

[Andre Nascimento]

Hum ok Mariana funcionou diminuiu mais 1gb mais ainda tem muito espaço alocado

[Marina Marques]

André... essa base deve estar tendo transação sendo executada no momento, tente matar todas as conexões e execute novamente os scripts. Deve ter alguma pendente que ainda está alocando o espaço no LOG.

[Andre Nascimento]

Ok vou tentar mais tarde

[Jefferson Oliveira]

--desativar todos jobs de backup e esperar terminar se algum estiver faltando

--Backup Full da base
--comando faltou

--backup do log
BACKUP LOG [xxxx]
TO  DISK = N'J:\Backup SQL Server\BackupTransactionLog\BkLogxxxx02122011'
WITH NOFORMAT, INIT,  NAME = N'xxxxx-Transaction Log  Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

--colocar base em modo simples
USE [master]
GO
ALTER DATABASE [xxxx] SET RECOVERY SIMPLE WITH NO_WAIT
GO

--fazer o shrink file no arquivo de log, zerando todo espaço livre
USE [xxxx]
GO
DBCC SHRINKFILE (N'Xxxx' , 0, TRUNCATEONLY)

--alterar modo de recovery para full novamente
USE [master]
GO
ALTER DATABASE [xxxx] SET RECOVERY FULL WITH NO_WAIT
GO

 

--verificar tamanho das bases
sp_helpdb

 

 

 

Em 21 de maio de 2012 10:46, Andre Nascimento <andr...@gmail.com> escreveu:

--
-------------------------------------------------
att,

Jefferson Santos

[Leonardo Pedroso Costa]

André,

se você dropou a tabela por completo, é o lance do recovery model / trasação aberta ainda, mas se você dropou algumas colunas dessa tabela e o campo dessa tabela for de comprivmento variável, aí você tem que rodar o DBCC CLEANTABLE, senão ele não libera espaço de jeito nenhum.

As colunas de tipo variável são:

varchar, nvarchar, varchar(max), nvarchar(max), varbinary, varbinary(max), text, ntext, image, sql_variant e xml. 

[Andre Nascimento]

O que e estranho Leonardo  e que as tabelas não são de tamanho variado.mais vou testar

[Andre Nascimento]

E pelo que eu li esse comando libera espaço para colunas retiradas tipo eu dropei totalmente as tabelas. Eu ate tentei executar o comando mais não deu certo.

[Leonardo Pedroso Costa]

Então, por isso que comentei que se você tivesse dropado a tabela toda, seria recovery model / transações abertas que impactaria (use o dbcc opentran) pra ver se tem alguma coisa, ou detalhe que pode estar fazendo a diferença é se o banco que você está executando o shirink é publisher de alguma replicação. Já tive que parar replicação pra poder liberar espaço.

Se tivesse dropado apenas colunas, o cleantable resolveria.

[Andre Nascimento]

Humm entendi

[Lucas Benevides]

tenta executar também um CHECKPOINT, pois pode estar alguma transação travando o banco.

 

Abraço,

Lucas