SQL Profiler trace testing

  • Application running slowly.

    I ran the profiler and got the exact sql statement, extracted it and first it built a table and used this in the next sql statement.

    So i ran the same statements in query analzyer and the query itself in SQL Analyzer took 8 seconds to complete. Now inside of the application the statement is taking 6 minutes.

    Anything else i can investigate why in app it is taking so much longer.

    Indexes are fine because it wouldn't have responsed so quickly in analyzer.

    Cheers

  • If the same queries being excuted quickly are on the same production server then likely the issue is with the application versus the database. I would look at the connection from the application. What is the driver and how is the connection established. You may have a performance issue there. I would also look at the application code. If you are getting results back and populating business objects (etc) then you may be seeing overhead from that processing.

    That being said, you may also find that the queries called from the app will have different execution plans if you are using different drivers for the connection. If this is the case you may want to clear the procedure cache and update stats to have the queries re-evaluate their execution plans.

  • You also need to look at the lock events, CacheHits, and Recompiles in Profiler. It may be taking time because of these reasons as well.

    What is the application using to connect to the database?

  • Thanks i take a look at the other events too..but from APP i can't do too much as it is the vendor software so i need to pass to them also..just wanted to make sure i cross all my 'T''s

  • Capture all the cursor events too.

    If you see many sp_cursorfetch w,x,y,z in the trace, and z is 1, then that's a clear indication the application is asking for the data one row at a time.

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

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