SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


shrinking the log file


shrinking the log file

Author
Message
mr.neil.bryan
mr.neil.bryan
Valued Member
Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)Valued Member (51 reputation)

Group: General Forum Members
Points: 51 Visits: 324
Hi,

we have a problem at work and the DBA has just gone on holiday (on an airplan right now!)

We have a number of database, with log files on the G:\ of the db server. Note G:\ is 750Gig

The G:\ is now full and we are struggling to regain space.

Looking at the log files, the on for database ReportServerTempDB is over 400Gig in size.

Would shrinking this database file resolve our issue?

Any help would be greatly appreciated, also please bear in mind, we are not DBA's.

Many thanks,
GilaMonster
GilaMonster
SSC Guru
SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)

Group: General Forum Members
Points: 217551 Visits: 46278
Shrinking the DB is not only not the solution, it'll potentially make things worse

Please read through this - Managing Transaction Logs and this: http://www.sqlservercentral.com/articles/Transaction+Log/72488/

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


heymiky
heymiky
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1425 Visits: 845
depending on what access you have to the SQL instance you may or may not be able to do this

Run SQL Server Management Studio and check to see if the ReportServerTempDB is in Simple recovery mode (right click properties, options), if its not set it to simple recovery. This won't recover the disk space but will clear the transaction which i'm presuming is not getting backed up. To get the space back run this in a new query, replace the 1000 to whatever you want the new size to be in MB.

USE [ReportServerTempDB]
GO
DBCC SHRINKFILE ('ReportServerTempDB_log' , 1000)
GO

you can set the DB to simple recovery using this as well

USE MASTER
GO
ALTER DATABASE [ReportServerTempDB] SET RECOVERY SIMPLE
GO
heymiky
heymiky
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1425 Visits: 845
GilaMonster (8/17/2012)
Shrinking the DB is not only not the solution, it'll potentially make things worse

Please read through this - Managing Transaction Logs and this: http://www.sqlservercentral.com/articles/Transaction+Log/72488/


On this particular database I personally would shrink it because it doesn't appear to be setup corectly, but on the whole your advice is spot on
GilaMonster
GilaMonster
SSC Guru
SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)

Group: General Forum Members
Points: 217551 Visits: 46278
SQLDBA360 (8/17/2012)
On this particular database I personally would shrink it because it doesn't appear to be setup corectly, but on the whole your advice is spot on


You'd shrink without knowing why the log is full, what's preventing it from being reused?

The first thing to do with a full log is figure out why it's not being reused, not knee-jerk shrink. Shrink of the log may be required later, after resolvign whatever's keeping the log from being reused (which may well not be recovery model)

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


GilaMonster
GilaMonster
SSC Guru
SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)SSC Guru (217K reputation)

Group: General Forum Members
Points: 217551 Visits: 46278
Just as a note to a 'not a DBA', switching to simple recovery is not typically something you'd do to an important DB as that breaks the log chain and prevents point-in-time restores after the switch (as covered in the first article I referenced)
ReportServerTempDB should be in simple recovery anyway unless someone switched it into full recovery for some reason

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)SSC Guru (95K reputation)

Group: General Forum Members
Points: 95871 Visits: 33013
Doubly important not to switch to simple recovery because you're already potentially in a position where you may have an issue and might need to recover the database to a point in time.

Frequently, the fast & easy solutions are the most dangerous.

----------------------------------------------------
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore Roosevelt

The Scary DBA
Author of: SQL Server Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
heymiky
heymiky
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1425 Visits: 845
Correct,
but this is the reportservertempdb why would you need to recover it, just re-run your report?
Carlton Leach
Carlton Leach
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1546 Visits: 1304
Another one here for "why's it not being reused?"

Q: Has the drive always been this full?

I'd shy away from changing the recovery model if it is in fact not in simple mode. Could be all manner of reasons for this (good and bad). DBA returns from holiday to find his recovery models have changed...thoughts?

;-)
Louis Li
Louis Li
Old Hand
Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)

Group: General Forum Members
Points: 350 Visits: 258
Agreed with GilaMonster, blindly shrinking a database might not be the best way of reclaiming space.

For this particular issue. If you are in a rush to get the server back, you could detach this ReportServerTempDB, move it to another location, attach it back then do your investigation or wait until your DBA comes back.

Also, the default recovery model of this database is SIMPLE, no need to change it unless it has been changed by your DBA. In this case, you might want to check with him/her.

----------------------------------------------------------------------------------------------
Microsoft Certified Solution Master: Data Platform, Microsoft Certified Trainer
Email: Louis.Li@rrlminc.com | Blog | LinkedIn
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search