Steps to consider at time of testers working on database

  • Hello,

    Can someone provide me set of instructions to consider at the time when testers works on database. What I know is to monitor the space and locks. Apart from this as DBA do we need to do monitor any other thing on the database/server level.

  • Why would you need to specifically monitor anything that yuo don't normally monitor when testers are working on a testing server?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • To just make sure of log space is not running.out of space...and database is functioning as is....

  • what kind of testing ?

    performance testing (soak, stress, load tests)?

    functional testing / Unit testing?

    environment/patch deployment testing ?

    MVDBA

  • performance testing(load)

  • in that case (depending on how dilligent your test analyst is and what methods/tools they are using for the test) then i would just leave it alone - any changes to monitoring may skew their results.

    the whole point of these tests is to push the server as far as possible and see if it breaks. If you test analyst is a good one then he will be grabbing performance data as the test is run that will support his findings (test evidence) - if he's not collecting test evidence then point him at the ISEB/ISTQB foundation level certification for test professionals.

    i would imagine that the tester will be running perfmon for the duration of the test and collecting the following data

    Page life expectancy

    locks per second

    Various Memory statistics

    compiles/recompiles per second

    cache hits/misses

    disk i/o statistics

    disk queue length

    cpu statistics

    he will most likely not care about t-log usage or data file expands/shrinks or tempdb usage , which are the things the DBA should be monitoring anyway

    MVDBA

  • in that case (depending on how dilligent your test analyst is and what methods/tools they are using for the test) then i would just leave it alone - any changes to monitoring may skew their results.

    the whole point of these tests is to push the server as far as possible and see if it breaks. If you test analyst is a good one then he will be grabbing performance data as the test is run that will support his findings (test evidence) - if he's not collecting test evidence then point him at the ISEB/ISTQB foundation level certification for test professionals.

    i would imagine that the tester will be running perfmon for the duration of the test and collecting the following data

    Page life expectancy

    locks per second

    Various Memory statistics

    compiles/recompiles per second

    cache hits/misses

    disk i/o statistics

    disk queue length

    cpu statistics

    he will most likely not care about t-log usage or data file expands/shrinks or tempdb usage , which are the things the DBA should be monitoring anyway

    MVDBA

  • Thanks mike..

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

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