Post reply

query is taking long time to run

  • August 21, 2013 at 8:59 am

    #277182

    Hi all

    here i am executing the query "select * from tmp_Brad_Product_Configuration_12months"

    while executing this it is taking 25 mins above and it is still executing.

    what may be the reason. can anyone please advise me on this.

  • August 21, 2013 at 9:16 am

    #1643506

    If it's a simple "SELECT * FROM Table", I would look for blocking issues.

    It's hard to give a correct advise with so little information. What's the size of the table? How many users use the database? Do you have something else in your query?

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2

  • August 21, 2013 at 9:20 am

    #1643508

    Post the definition of the object tmp_Brad_Product_Configuration_12months. Without knowing what it is, it's difficult to answer your question with any degree of confidence.

    “Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • August 21, 2013 at 10:34 am

    #1643535

    here in this table 9112177 records are there 6.3gb data is available.

  • August 21, 2013 at 10:52 am

    #1643537

    how can i find the fragmentation on this single query

  • August 21, 2013 at 11:10 am

    #1643544

    How many columns are in this "large" table?

    SELECT * (2 or 3 columns) FROM TABLE will run quite well most of the time, whereas if you have dozens of columns in that table, it will take quite some time to pull in the information as you'll be scanning the clustered index (assuming the table has one)

    Without seeing the DDL or an execution plan, it's difficult to tell where your issue is...could be a matter or just tweaking a few included columns in an existing non-clustered index (assuming these exist as well)

    Do you really need all columns to be returned?

    ______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

  • August 21, 2013 at 11:19 am

    #1643547

    we have 26 columns in that. the execution plan is showing as table scan

  • August 21, 2013 at 11:32 am

    #1643552

    here we found that memory usage is showing as 99%

  • August 21, 2013 at 11:37 am

    #1643554

    You are pulling back 6GB of data. If you're doing this in a client, you might have rendering issues, as well as IO/memory issues on the server. 6GB of data will slide through the buffer cache and clear out things.

    If any other user is querying the table, they might be blocking. Check sp_who2 for blocking connections. Don't do a "select *" unless you really need all that data.

  • August 21, 2013 at 11:52 am

    #1643559

    no we are not executing anything still physical memory usage is showing as 95.45gb.

    i have checked for blockages there is no blockages.

    how can i solve this memory issue.

  • August 21, 2013 at 12:21 pm

    #1643575

    It's not necessarily memory, and physical memory doesn't matter all the time. SQL Server has its own memory management and limits.

    Perhaps you could start from the beginning and explain how you are querying the data, what client,and what is happening that you notice. Is your query showing as executing if you check SQL Server?

  • August 21, 2013 at 4:02 pm

    #1643695

    New persopn (2013-08-21)

    here in this table 9112177 records are there 6.3gb data is available.

    And from where are you running that query? Not SQL Server Management Studio I hope!

    The problem is not with SQL Server, but with the client program. How is it written? Where are you putting all this data?

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • August 21, 2013 at 4:10 pm

    #1643697

    New persopn (8/21/2013)

    Hi all

    here i am executing the query "select * from tmp_Brad_Product_Configuration_12months"

    while executing this it is taking 25 mins above and it is still executing.

    what may be the reason. can anyone please advise me on this.

    Even if the code returned the result set in 25 milliseconds, my question would be, why do you want to return all rows of a table with more than 9 million rows in it to begin with?

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

  • August 22, 2013 at 3:05 am

    #1643800

    Thank you all temporarily the issue solved. we have created the cluster index on table then it is solved.

Viewing 14 posts - 1 through 13 (of 13 total)

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