Will shrinking the DB improve time taken by index rebuild process ?

  • Experts,

    Will shrinking the DB improve time taken by index rebuild process ?

    If yes, why ?

    Thanks,

    Smith.

  • No. After shrink index rebuild process can take more time if there will be not enough free space in the DB file to rebuild index.

  • No. Increase it if anything as the data file will have to regrow.

    Regular shrinks of the database file should not be done.

    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
  • plus the shrink will cause heavy fragmentation so there will be more for the rebuild\reorg to do.

    ---------------------------------------------------------------------

  • Thank you all.

    Just one more query..

    What are thr things that we need to do to speed up the index rebuild process ?..... in brief...

    Thanks again.

  • Joy Smith San (6/17/2013)


    What are thr things that we need to do to speed up the index rebuild process ?..... in brief...

    Better IO subsystem.

    More memory (maybe)

    Reduce the need to rebuild indexes.

    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 (6/17/2013)


    Joy Smith San (6/17/2013)


    What are thr things that we need to do to speed up the index rebuild process ?..... in brief...

    Better IO subsystem.

    More memory (maybe)

    Reduce the need to rebuild indexes.

    To add to Gail's suggestions...

    Partitioning of certain tables, such as audit tables (or other tables that don't usually suffer updates, just inserts), can help a lot if partitioned by row creation date. For example, I have an audit table at work that I'm setting up to partition by creation date. It has almost 3 years of data in it and the table has about 25GB of data in it. Even though the clustered index is in good shape (based on the IDENTITY column) and never needs reindexing (follows Gail's suggestion of "Reduce the need to rebuild indexes"), the other indexes take quite some time. When I'm done partitioning it, I'll only need to reindex the "current month" partition.

    I'm also moving all but the last 3 months of audit partitions to another database (using partitioned views so I can put them in a different DB) so that my backup and restore times will be reduced by quite a bit. During a restore for DR, it's much more important to get the database back up and running than it is to restore 3 years of audit data which can be done almost leisurely after the main database is up.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • The main way to speed up index rebuilds is don't do them if they are not needed. Ola Hallengren http://ola.hallengren.com/ publishes an index rebuild routine used around the world that processes only those indexes that need work on them.

    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

Viewing 8 posts - 1 through 7 (of 7 total)

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