Post reply

SQL Query Performance: CXPACKET

  • April 30, 2014 at 12:30 am

    #290769

    Hello,

    I am running a query for which Waittype is CXPACKET, query does join two tables and insert the data into another table. I ensured to have the good space in TempDB physical drive however as the query progress, it goes in KBs and finally query fails with Transaction log full.

    Server has 32 Cores with 64 Logical processors and has 768 Gig RAM. "Cost Threshold for Parallelism" set to 50 and MAXDOP set to 48. I read through about "Cost Threshold for Parallelism" but quite confused about MAXDOP.

    Could you please help me set up the MAXDOP please

    Thanks!

  • April 30, 2014 at 12:43 am

    #1709701

    Ignore the CX packet and tune the query. Look for waits that the query incurs other than CX packet.

    If you want specific help, please post the query, table and index definitions and the execution plan.

    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

  • April 30, 2014 at 12:54 am

    #1709704

    Attached is the execution plan and I am trying to see in which way creating indexes might help.

  • April 30, 2014 at 1:13 am

    #1709712

    Table definitions, index definitions, the query itself and the actual execution plan (not estimated)

    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

  • April 30, 2014 at 2:30 am

    #1709730

    According to the statistics you're moving 197 million rows with no where clause. Don't bother with an index. It won't do any good. As currently built out, there's almost nothing you can do here to improve performance except buy bigger and better hardware. I would suggest considering some type of filtering. You can't even apply an index to the grouping because it's across 15 or so columns from two tables.

    "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

Viewing 5 posts - 1 through 4 (of 4 total)

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