Post reply

Performance Issue with when Proc called thru SSIS "SQL Task"

  • July 12, 2008 at 10:34 pm

    #190665

    I have a Proc which runs in 4 hours when executed as a step in SQL Job but takes 10 hours when executed thru SSIS using "Execute SQL" Task. I have testd this multiple times.

    Is there a setting (memory wise) I need to look at for better performance?

    I will appreciate any help.

    I am on SQL 2005 with 8 processors with 64GB of RAM.

    Thanks.

  • July 13, 2008 at 5:32 am

    #842073

    Hi,

    Hope you are enjoying the weekend.

    Take a look at the following Microsoft article. It provides details and generic instruction as to how to performance tune SSIS projects.

    http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx

    John Sansom (@sqlBrit) | www.johnsansom.com

  • July 13, 2008 at 5:38 am

    #842075

    One further point, as far as I understand things, SSIS uses a specific protion of a servers memory, sometimes called the memToLeave portion of the entire SQL Server Memory space.

    So for example, although SQL Server may report that it is making use of a large portion of a servers memory, this may not actually be available to SSIS for use.

    This may provide more insight into SQL Server Memory allocation.

    http://www.sqljunkies.ddj.com/Tutorial/0D4FF40A-695C-4327-A41B-F9F2FE2D58F6.scuk

    John Sansom (@sqlBrit) | www.johnsansom.com

  • July 13, 2008 at 6:46 am

    #842081

    Thanks for your reply. But, stored procedure should run on the Server and not be limited by SSIS memory and should be using SQL server memory, right?

    Thanks.

  • July 13, 2008 at 11:51 am

    #842117

    Just a side bar... if the job is taking 4 hours on anything to run, you might want to look at tuning the code instead of trying to tune SSIS. 😉

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

  • July 13, 2008 at 1:14 pm

    #842128

    Code is processing over 700 million records (also joins 10 different tables with over 100 million records in each table) so I think 4 hours is pretty good.

    Jeff Moden (7/13/2008)

    Just a side bar... if the job is taking 4 hours on anything to run, you might want to look at tuning the code instead of trying to tune SSIS. 😉

  • July 14, 2008 at 12:00 am

    #842196

    Heh... if you're happy with 4 hours, I'm happy. 🙂

    --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 7 posts - 1 through 6 (of 6 total)

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