February 9, 2009 at 1:19 am
I cannot manage to shrink my logfile and datafile, the command used before in SQL 2000 doesn't work anymore, Urgent assistance is required please, tried doing it from the Management Studio as well but file does not shrink
executed:
dbcc shrinkfile (ServerAdmin_log, truncateonly)
dbcc shrinkfile (ServerAdmin_log, 1000)
Error:
Cannot shrink log file 2 (ServerAdmin_Log) because of minimum log space required.
The other error i recieved was:Cannot shrink log file 2 (ServerAdmin_Log) because all logical log files are in use
February 9, 2009 at 1:33 am
make sure there are no open transactions before shrinking the log, also insted of using 1000 try ,0 this will take it down to what ever space is free not just to zero bytes.
dbcc opentran (database)
go
and so on.
Terry
February 9, 2009 at 1:50 am
dbcc opentran (ServerAdmin)
go
dbcc shrinkfile (ServerAdmin_log, truncateonly)
dbcc shrinkfile (ServerAdmin_log, 0)
Results:
No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Cannot shrink log file 2 (ServerAdmin_Log) because the logical log file located at the end of the file is in use.
I cannot shrink the logfile and datafile to any amount then what it's currently at. How is this possible
February 9, 2009 at 2:15 am
There are some common reasons why a transaction log might not shrink when you use the DBCC SHRINKFILE or DBCC SHRINKDATABASE command.
Please rerfer to the following link http://support.microsoft.com/kb/q256650/
SET NOCOUNT ON
DECLARE @LogicalFileName SYSNAME,
@MaxMinutes INT,
@NewSize INT,
@Factor FLOAT
USE
--Use sp_helpfile to identify the logical file name that you want to shrink.
SET @LogicalFileName = 'databasename_Log';
--Limit on time allowed to wrap log in minutes
SET @MaxMinutes = 5;
--Ideal size of logfile in MB
SET @NewSize =100;
SET @Factor = 1.0;
DECLARE @OriginalSize INT,
@StringData VARCHAR(500)
SELECT @OriginalSize = size -- in 8K pages
FROM sysfiles
WHERE name = @LogicalFileName;
SELECT @StringData = 'Original Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName;
PRINT @StringData;
PRINT ''
--Drop the temporary table if it already exists
IF ( OBJECT_ID('[dbo].[DummyTrans]') IS NOT NULL )
DROP TABLE [DummyTrans]
CREATE TABLE [DummyTrans]( [DummyColumn] CHAR(8000) NOT NULL );
-- Wrap log and truncate it.
DECLARE @Counter INT,
@MaxCount INT,
@StartTime DATETIME,
@TruncLog VARCHAR(500)
-- Try an initial shrink.
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
SET @TruncLog = 'BACKUP LOG [' + db_name() + '] WITH TRUNCATE_ONLY';
EXEC (@TruncLog)
-- Configure limiter
IF @OriginalSize / @Factor > 50000
SET @MaxCount = 50000
ELSE
SET @MaxCount = @OriginalSize * @Factor
-- Attempt to shrink down the log file
PRINT 'Minimum Quantity : '+CAST( @MaxCount AS VARCHAR(10) )
PRINT 'Maximum Time : '+CAST( @MaxMinutes AS VARCHAR(10) )+' minutes ('+CAST( @MaxMinutes*60 AS VARCHAR(10) )+' seconds)'
PRINT ''
SET @Counter = 0;
SET @StartTime = GETDATE();
--loop the padding code to reduce the log while
-- within time limit and
-- log has not been shrunk enough
WHILE (
(@MaxMinutes*60 > DATEDIFF(ss, @StartTime, GETDATE())) AND
(@OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)) AND
((@OriginalSize * 8 / 1024) > @NewSize)
)
BEGIN --Outer loop.
--pad out the logfile a page at a time while
-- number of pages padded does not exceed our maximum page padding limit
-- within time limit and
-- log has not been shrunk enough
WHILE (
(@Counter < @MaxCount) AND
(@MaxMinutes*60 > DATEDIFF(ss, @StartTime, GETDATE())) AND
(@OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)) AND
((@OriginalSize * 8 / 1024) > @NewSize)
)
BEGIN --Inner loop
INSERT INTO DummyTrans VALUES ('Fill Log') -- Because it is a char field it inserts 8000 bytes.
DELETE FROM DummyTrans
SELECT @Counter = @Counter + 1
--Every 1,000 cycles tell the user what is going on
IF ROUND( @Counter , -3 ) = @Counter
BEGIN
PRINT 'Padded '+LTRIM( CAST( @Counter*8 AS VARCHAR(10) ) )+'K @ '+LTRIM( CAST( DATEDIFF( ss, @StartTime, GETDATE() ) AS VARCHAR(10) ) )+' seconds';
END
END
--See if a trunc of the log shrinks it.
EXEC( @TruncLog )
END
PRINT ''
SELECT @StringData = 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName;
PRINT @StringData
PRINT ''
DROP TABLE DummyTrans;
PRINT '*** Perform a full database backup ***'
SET NOCOUNT OFF
February 9, 2009 at 2:49 am
Result after executing your statemet
Original Size of ServerAdmin LOG is 358648 8K pages or 2801MB
Cannot shrink log file 2 (ServerAdmin_Log) because the logical log file located at the end of the file is in use.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 155, Level 15, State 1, Line 1
'TRUNCATE_ONLY' is not a recognized BACKUP option.Minimum Quantity : 50000
Maximum Time : 5 minutes (300 seconds)
Final Size of ServerAdmin LOG is 330112 8K pages or 2579MB
February 9, 2009 at 2:53 am
try this backup database name with no_log ..then try to shrink the database....
February 9, 2009 at 2:58 am
stop all the activity on the db, if needed kill threads.
change the recovery model to simple and then shrink it.
Worst case even then if it is not resolved, dettacch the db,move the log file to other location and then attach the mdf file in single file mode,
Sriram
February 9, 2009 at 3:29 am
Aha thanx that seems to do the trick, Changed the recovery model to simple then shrunk the logfile using the shrink tool in Server Management Studio. Thanks alot for all the assistance
Grasshopper
Why do you have to change the recovery model in order to shrink the files
February 9, 2009 at 3:50 am
Brother, In Simple recovery model the logs are not saved or in other words truncated when ever there is a commit. It is not desirable to do this until unless it is highly important.
As you said it has worked change it back "FULL"
Sriram
Sriram
February 9, 2009 at 4:17 am
If your database is Production than after changing db back to Full recovery mode do not forget to take full backup.
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
February 9, 2009 at 4:47 am
free_mascot (2/9/2009)
If your database is Production than after changing db back to Full recovery mode do not forget to take full backup.
Please do reply over here..that after changing model to full,were u able to shrink it or problem persists...
February 9, 2009 at 4:53 am
if this is not a production db then maybe your best option will be to kill all the connections backup the db detach the database delete the tranlog manullay and re-attach I really wound not recomend this but it will create you a new tranlog that is empty. Or back up the db in simple and dump the log with no_log then run dbcc shrinkfile.
the dbcc opentran will show you the connections type
kill spid where spid = say 17
terry
February 9, 2009 at 10:50 am
terryj30 (2/9/2009)
I really wound not recomend this but it will create you a new tranlog that is empty.
I would not recommend that under any circumstances. It's the quickest way to get a corrupt and unusable database.
Or back up the db in simple and dump the log with no_log
In simple recvery,no backup log is necessary. A checkpoint truncates the log.
Backup log ... with no_log is no longer available in SQL 2008. It will throw an error saying unrecognised backup option.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 10, 2009 at 3:03 am
Repeated shrinking and growing a database file will harm your performance. You should not shrink a database file unless you know there will be a permanent reduction in the space needed.
There are lots of forum postings on this subject, and the harm that repeated file shrinking does to your performance. It is worth using Google, etc, to find them and take the time to understand what they are saying.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 10, 2009 at 7:52 am
ed is quite right however, I am guessing you are shrinking as you are running out of disk-space as that is the only reason I can think off. 2008 is rather tricky I am wondering if you have also looked into the compression aspect of sql20008
Terry
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply