Post reply

Test Environment

  • September 18, 2008 at 12:33 pm

    #72880

    I need to create a test environment at my work place. I donno why they never had one. But we need to create a test environment for one of the mission critical db of the size 250 GB. We want to be sure of what the results going to be on production. To what extent the hardware or software should resemble the ones from production.

    Thanks in Advance

    The_SQL_DBA
    MCTS

    "Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."

  • September 18, 2008 at 1:58 pm

    #873909

    Best you can, though most people have smaller environments and have to make guesses on performance. I would think the data size is the most important, get all data, then perhaps memory, and lastly CPU.

  • September 18, 2008 at 2:15 pm

    #873916

    If the data is on a SAN, the SAN comes with software to make it easy to do this. Once it's setup (read the documentation that came with the SAN), it'll creat a copy on becon-call in about 10 minutes.

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

  • September 18, 2008 at 2:34 pm

    #873924

    Steve Jones - Editor (9/18/2008)

    Best you can, though most people have smaller environments and have to make guesses on performance. I would think the data size is the most important, get all data, then perhaps memory, and lastly CPU.

    Generally, you cannot predict the performance accurately anyway (unless you have a way to simulate the user/application load and know how to performance model the differences away) so I wouldn't worry about hardware equality for development and (functional) test environments. I usually make the performance tests a separate stage using duplicate HW only at that point.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.     [/font]    [font="Verdana"] "Performance is our middle name."[/font]

  • September 18, 2008 at 9:10 pm

    #873998

    In that vein, I normally make the test boxes less robust than the production server. If it's fast on the test box, imagine what it will do on the server. I do agree about the connections.

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

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