Shrinking the transaction log

Question

Post reply

Shrinking the transaction log

VM-723206

SSCrazy

Points: 2964
More actions
December 10, 2009 at 12:09 am

#217559

Comments posted to this topic are about the item Shrinking the transaction log

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

Dude76 Mr or Mrs. 500 Points: 585 More actions · Answer 1

One more time (as usual ? as often ? ) , "all of these apply".

My MCP Transcript (ID : 692471 Access : 109741229)

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 2

I'm confused, what is the question asking? I'd like to answer it today, but with this question it would all be a shot in the dark.

SanjayAttray SSChampion Points: 13157 More actions · Answer 3

Lynn Pettis (12/10/2009)
I'm confused, what is the question asking? I'd like to answer it today, but with this question it would all be a shot in the dark.

( It would all be a shot in the dark ). That's what I did. Checked all and got points. I am not sure about this option. Will have to test it on some server. I thought its same and never observed time in seconds.

-- If a log file has lots of free space, shrinking the transaction log file in SQL Server 2005 is faster than shrinking the transaction log file in SQL Server 2000.

SQL DBA.

Alan Vogan SSCrazy Points: 2513 More actions · Answer 4

Not a very interesting or up-to-date question. I would have expected comparisons between 2005 and 2008.

Bhavesh_Patel SSCrazy Points: 2259 More actions · Answer 5

It was bit confusing.

[font="System"]Bhavesh Patel[/font]

http://bhaveshgpatel.wordpress.com/

BudaCli Hall of Fame Points: 3404 More actions · Answer 6

Another one busted the dust out on me...

What you don't know won't hurt you but what you know will make you plan to know better

wbeaton-664441 SSC Eights! Points: 880 More actions · Answer 7

3 of the 4 options are correct. But, this statment can't be true:

"Reducing the physical size of a log file requires shrinking the file."

You can truncate a transaction log and that will reduce the physical size of the log file, therefore shrinking is not required.

Sorry for the late reply. I'm playing catchup on old questions I skipped over. 😀

Peter Trast SSCarpal Tunnel Points: 4392 More actions · Answer 8

wbeaton-664441 (3/18/2010)
3 of the 4 options are correct. But, this statment can't be true:
"Reducing the physical size of a log file requires shrinking the file."
You can truncate a transaction log and that will reduce the physical size of the log file, therefore shrinking is not required.
Sorry for the late reply. I'm playing catchup on old questions I skipped over. 😀

I am behind on all of them but I am playing catchup anyway 🙂

Peter Trast
Microsoft Certified ...(insert many literal strings here)
Microsoft Design Architect with Alexander Open Systems

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 9

wbeaton-664441 (3/18/2010)
3 of the 4 options are correct. But, this statment can't be true:
"Reducing the physical size of a log file requires shrinking the file."
You can truncate a transaction log and that will reduce the physical size of the log file, therefore shrinking is not required.
Sorry for the late reply. I'm playing catchup on old questions I skipped over. 😀

Hate to be the bearer of bad news, but truncating the transaction log, either by changing the recovery model from FULL or BULK_LOGGED to SIMPLE, or using the depreciated command BACKUP LOG <DBNAME> WITH TRUNCATE_ONLY, simply marks the space used by the committed transactions as reusable. To physically shrink the ldf file, you must use the DBCC SHRINKFILE.

wbeaton-664441 SSC Eights! Points: 880 More actions · Answer 10

I guess I got confused by semantics... my point was that, if you use the depreciated command "BACKUP LOG <DBNAME> WITH TRUNCATE_ONLY", the physical file would literally decrease in size from say 10GB to 10MB... thus "shrinking" the file size. But, I agree that it's not technically accurate.