Can an Index improve tempdb high usage ?

  • Hi All,

    Imagine a scenario where a datawarehouse database is working and, at the same time, limited disk space in our tempdb system database.

    When any process runs that loads data into memory, the tempdb alert reaches the maximum size.

    Is it worthiness to add an index to reduce tempdb usage ?. But, of course, this is only a first step, as query optimization should be the primary target, but not possible for now.

    All the tables look like they may receive the benefits of having indexes because none of them have one.

    Thanks for your ideas

    Regards,

     

  • This was removed by the editor as SPAM

  • If none of your tables have indexes, you should start there, and fast!

    First, review the missing index stats to see which column(s) should be used in the clustered index.  That is by far the single most important index on any table for getting best overall performance.

    As part of that, for larger tables, you need to see whether page compression is worthwhile.  You can use proc sys.sp_estimate_data_compression_settings to do that.  Normally it is worthwhile for nearly all large tables.

    After deciding the clus index for each table, you can analyze if any nonclus index(es) is(are) needed, and create those.

    SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.

  • Lou wrote:

    Hi All,

    Imagine a scenario where a datawarehouse database is working and, at the same time, limited disk space in our tempdb system database.

    When any process runs that loads data into memory, the tempdb alert reaches the maximum size.

    Is it worthiness to add an index to reduce tempdb usage ?. But, of course, this is only a first step, as query optimization should be the primary target, but not possible for now.

    All the tables look like they may receive the benefits of having indexes because none of them have one.

    Thanks for your ideas

    Regards,

    Scott is absolutely correct.  Also, how many GB in the largest table in your DW, how many files do you have in TempDB, and what are their sizes?

    --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)

  • Does the DW process create temporary tables or is the tempdb usage just from sorts and joins?

  • Thanks for your responses,

    We have more sorts and joins.

    Thank you

  • Lou wrote:

    Thanks for your responses,

    We have more sorts and joins.

    Thank you

    A lot of that can be resolved by indexes in most cases.  In some cases, the indexes won't actually be used and in other indexes just makes your accidental cross joins consume TempDB faster. 😀

    Like I asked, how big is your largest table in GB and how big is your TempDB  in GB?

    --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)

  • Jeff,

    My largest table has 20 million records and uses around 20 gigs but my tempdb maximum size is 192 gigs.

    Regards,

     

     

  • The right indexes will help in some cases. But honestly, you'll have to evaluate each. It's going to be the same as dealing with the query tuning. It's all of a package really.

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

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • It depends.

    If your query does a full scan of those tables because it needs all data from those tables then index are useless.

    If the optimizer determines that full table scan is the most efficient way because your query requires most of data of those tables then again index are useless.

    It's all depends on your query.

    • This reply was modified 1 year, 11 months ago by  jonau1.
    • This reply was modified 1 year, 11 months ago by  jonau1.
  • Lou wrote:

    Jeff,

    My largest table has 20 million records and uses around 20 gigs but my tempdb maximum size is 192 gigs.

    Regards,

    That's a rather huge TempDB considering the relatively small size of your largest table.  Indexes can certainly help full heap scans but then you're also going to have to look at both the performance and the IO to further figure things out.  I strongly suspect that you may have some accidental many-to-many joins that folks use DISTINCT or GROUP BY to overcome duplicate rows problems.

    --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)

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

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