Post reply

True Lab Environemnt

  • December 11, 2008 at 10:32 am

    #125751

    i was thinking about this topic yesterday and I had some questions. I start with my current environment. Currently we copy a backup of our Production database to the Lab environemt and restore it. QA testers run some test or we also trouble shoot some issues using this environment. My concern is we are not truely testing the best way. I guess my concerns revolve around query planning. When we copy the DB down from prod, is the query plan coming along or is a plan recreated in the new environment? In other words is this info stored in the DB or the Engine? What abotu other performance concerns? Servers are identical - size, memory, processes, etc...Still we get different results from each, not always, bbut soemtimes.

  • December 13, 2008 at 5:24 pm

    #912124

    Is the sql server memory and processor configuration same on both?

    MJ

  • December 13, 2008 at 7:45 pm

    #912153

    Do you mean the number of rows or their content is different? Or, do you just mean the query plan or performance is different?

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

  • December 14, 2008 at 5:06 am

    #912180

    query plans are held in cache memory, are the machines the same spec or different (cpu and memory)

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • December 14, 2008 at 5:39 am

    #912185

    The servers are identical.

  • December 14, 2008 at 6:16 am

    #912188

    refer to the following URLs on using query plans.

    http://msdn.microsoft.com/en-us/library/ms179880(SQL.90).aspx

    http://msdn.microsoft.com/en-us/library/ms187032(SQL.90).aspx

    download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/Forcing_Query_Plans.doc


    Pradeep Singh

  • December 14, 2008 at 9:06 am

    #912206

    christian.benvenuto (12/14/2008)

    Still we get different results from each, not always, bbut soemtimes.

    The servers are identical.

    I'm still trying to figure out what you mean by "different results". Do you mean just query plans or do you mean the rowcounts or results for queries are different?

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

  • December 14, 2008 at 11:59 am

    #912244

    If the machines are the same regarding cpu/memory, all settings at server and database are identical, and the databases are the same then you should get the same results in most cases. Potential differences that spring to mind are :

    * plan differences due to recompilation (because you restored the database in QA and started with an empty cache) or due to parameter sniffing (because the statements are not run in exactly the same order and in QA do not extend back past the restore point).

    * differences in behaviour due to query hints / isolation levels / coding methods which make query results differ based on concurrent usage (eg using nolock in a query where one of the tables is being updated by another process)

    You probably should determine exactly what it is you want to test - your method will work for most scenarios. If you are looking at specific performance differences then you might also need to take disk and network setup and usage into account.

  • December 14, 2008 at 12:22 pm

    #912247

    matt stockham (12/14/2008)

    because you restored the database in QA and started with an empty cache

    exactly my thoughts

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 9 posts - 1 through 8 (of 8 total)

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