Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

shrinking Expand / Collapse
Author
Message
Posted Wednesday, May 21, 2008 11:19 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, February 18, 2013 9:50 PM
Points: 119, Visits: 650

Could any one tell me the diff between shrinking and truncating .
defrag and shrinking.
I read bol , but iam not able to understand what exactly happens inside.
Post #504705
Posted Wednesday, May 21, 2008 12:23 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, November 17, 2014 3:55 PM
Points: 320, Visits: 362
Well, if I'm clear on what you're asking, it's about log files, right?

Well, truncating would be removing all inactive portions of the log. So your log is full with stuff it doesn't need anymore, and you get rid of it. But your physical log file that sits out on the drive is still the same size, it's just empty now. So you shrink it to fit the current size of the data. Get it?

As for defragging, that just reorgs the pages to put them back in order so they can be read easily.


Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground -- http://www.infoworld.com/blogs/sean-mccown
DBA Rant – http://dbarant.blogspot.com
Post #504742
Posted Thursday, May 22, 2008 1:26 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 4, 2009 7:34 AM
Points: 129, Visits: 130
As I understand, you were talking about the SQL Logs.

Truncate is not a logged operation and it will remove uncommited transaction from the Log.

Shrinking is nothing but Comprissing. If have any idea about blocks and sectors in Os drives. It will remove unnecessary space from the file and keep one after other.

You can Shrink data file and log file as well.

Defrag means rearranging the pages, so it can easy to read those.


Manoj

MCP, MCTS (GDBA/EDA)
Post #505444
Posted Thursday, May 22, 2008 2:14 PM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Sunday, January 29, 2012 1:45 AM
Points: 710, Visits: 1,284
any way when truncating the log file the operation want be logged cos u cant log the operations on the log file!!
and u cant drop the log file or delete some recoreds from.
its not like when truncate a table.


..>>..

MobashA
Post #505475
Posted Friday, May 23, 2008 7:06 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, April 19, 2011 7:31 AM
Points: 2,666, Visits: 5,316
I won't define the topics as that has already been taken care of but I will add my 2 cents, for what it's worth.

1) Truncate - if you truncate the log, do a full database backup immediately afterwards as you've broken your backup chain.
2) Shrinking - unless you had a rare event which caused your log file to grow substantially, don't do it. If the log grew due to normal daily processing, it will likely grow again after the shrink, resulting in a performance hit and potential physical fragmentation.
3) Defrag is fine but you should possibly look for a maintenance window to reindex. I do mine weekly. If you can only do it monthly, maybe defrag at other times to keep things running as smooth as possible.


-- You can't be late until you show up.
Post #505809
Posted Friday, May 23, 2008 8:30 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 4, 2009 7:34 AM
Points: 129, Visits: 130
Good tosscrosby,

Appreciate for explanation, I forgot to add those point in my previous reply.

Tip of the Day...

"Pages will not migrate between files during an index reorganization".


Manoj

MCP, MCTS (GDBA/EDA)
Post #505899
Posted Friday, May 23, 2008 9:22 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, February 18, 2013 9:50 PM
Points: 119, Visits: 650
Thanks for all of you for your good answers.
Now iam able to uinderstand what happens exactly.

But i have a small doubt.

Index rebuild means it will drops the existing one and creates new one.
In this situation what happens exactly (abt memory and pages wise and the actual process)
Post #505956
Posted Friday, May 23, 2008 9:29 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, April 19, 2011 7:31 AM
Points: 2,666, Visits: 5,316
Typically, rebuilds should be run when you can have exlcusive use of the database. It will impact the server performance, it will log to the transaction log, use tempdb and, I think, you should have like 50% of the amount your database size free with respect to disk space for that database (I may be wrong about this number, it may be more!). Defrag can be run with users in the system but again, there will be a performance hit. For index rebuilds, there a plenty of scripts on this site that will allow you to do a selective rebuild, i.e. if the index is x% fragmented, rebuild it, look around if this fits your needs. This would allow for a quicker, possibly smaller, rebuild process.

-- You can't be late until you show up.
Post #505965
Posted Friday, May 23, 2008 9:38 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 4, 2009 7:34 AM
Points: 129, Visits: 130
Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does not match the physical ordering inside the data file. All leaf pages of an index contain pointers to the next and the previous pages in the index. This forms a doubly linked list of all index/data pages. Ideally, the physical order of the pages in the data file should match the logical ordering. Overall disk throughput is increased significantly when the physical ordering matches the logical ordering of the data. This leads to much better performance for certain types of queries. When the physical ordering does not match the logical ordering, disk throughput can become less efficient, because the disk head must move back and forth to gather the index pages instead of scanning forward in one direction. Fragmentation affects I/O performance, but has no effect on performance of queries whose data pages reside in the SQL Server data cache.



Manoj

MCP, MCTS (GDBA/EDA)
Post #505974
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse