Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; GeSHi has a deprecated constructor in /home5/midnigk3/public_html/DBARant/wp-content/plugins/wp-codebox/geshi/geshi.php on line 255

Warning: Cannot modify header information - headers already sent by (output started at /home5/midnigk3/public_html/DBARant/wp-content/plugins/wp-codebox/geshi/geshi.php:255) in /home5/midnigk3/public_html/DBARant/wp-content/plugins/wp-codebox/wp-codebox.php on line 34

Warning: Cannot modify header information - headers already sent by (output started at /home5/midnigk3/public_html/DBARant/wp-content/plugins/wp-codebox/geshi/geshi.php:255) in /home5/midnigk3/public_html/DBARant/wp-content/plugins/wp-codebox/wp-codebox.php on line 35
----------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- ---------------------Truncate and shrink all Log Files----------------------------------------- ----------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- /* The biggest question I get with this is why you would want to shrink all log files. There's a question of VLFs and log growths, etc. Well, a simple use case for this is when you need to move a bunch of log files to a new drive and you don't want to be up all night. Shrink them down and transfer just a few gigs instead of a few dozen or even into the hundreds of gigs. Another reason is to restore a DB to a dev box or something. If the drive isn't as big as it is on your main box then you'll need to shrink the log so you can actually restore. Then take the backup. So the fact that it may be good to leave your logs alone for the most part, there are times when it's best to trim them. Of course, the obvious other reason is space. If you've got a lot of log files on a single drive then you need the space to be managed a little tighter and if you've got one that got blown out really big for some reason then there's no reason the others have to suffer because you refuse to shrink it. */ DECLARE @curDBName sysname, @curFileName VARCHAR(2000), @SQL varchar(4000), @FileSize VARCHAR(10); SET @FileSize = '1024'; -- The size you want the files to be shrunk to. Declare DBName Cursor For SELECT DB_NAME(database_id) AS DBName, name AS FileName FROM sys.master_files WHERE type_desc = 'LOG' AND database_id > 4 ORDER BY DB_NAME(database_id) ASC Open DBName Fetch Next From DBName INTO @curDBName, @curFileName while @@Fetch_Status = 0 Begin SET @SQL = 'USE [' + @curDBName + ']; ' SET @SQL = @SQL + 'DBCC SHRINKFILE ([' + @curFileName + '], ' + @FileSize + ')' PRINT @SQL; --EXEC (@SQL); Fetch Next From DBName INTO @curDBName, @curFileName END Close DBName DeAllocate DBName GO