Database Sizing

  • Hi All

    Could anybody help regarding define Database sizing before deployment

    Following are the initial figure

    Below are details which you can use for DB sizing:

    1. Call Volume per day ---- Mentioned in table below

    2. Data Purging (No of days data needs to be available into DB) – Chandra would provide this data.

    3. Three entries of each customer record in following databases:

    - CalllistDB

    - Reporting DB

    - IVRDB

    Based on the call projections provided, the AD sizing will be 4139 ports for this process. The BoM will be as follows:

    Description

    Factor

    KK

    Daily Call Volume

    6,556,500

    AD Full Call

    25%

    1,639,125

    AD Short Call

    75%

    4,917,375

    Operating hours of Auto Dialer per day

    8

    204,891

    Operating hours of Auto Dialer per day

    8

    614,672

    AD ports required for full call (AHT 60 Sec)

    60

    3,415

    AD ports required for Short Call (AHT 6 Sec)

    6

    1,024

    Total AD Ports Required

    4,439

    Existing AD ports

    300

    Additional AD ports Required

    4,139

    Additional IPCS Server required

    300

    14

    Total E1 ports required

    148

    Existing E1 ports

    10

    Additional E1 ports

    138

    Additional Gateway required

    9

    Total BW Required

    14.6

    Existing BW

    1.36

    Additional BW Required with (in MB)

    13.25

    Additionl BW with 20% Add-on (in MB)

    15.89

    Thanks

    Ghanshyam

  • Two suggestions:

    1) format the tabular data into a form that we can use

    2) take out any personally identifying information. We're not really in a position to contact Chandra for her data, and I doubt that she wants us to.

    [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]

  • Also, see Estimating the Size of a Database in Books Online 😉

  • This is not a database point really, but the numbers provided imply that the ports used for autodial will all be 100% utilised throughout the 8 hour operational day. Your application will presumably work on a two level queuing system with a single 15-server (using the real servers) queue feeding 15 300-server (server = AD port) queues so getting it to load balance in such a way as to achieve constant 100% utilisation at the bottom end may well entail very large steady state queue lengths (particular if the two call types have variable duration, rather than constant) and it may be better to allow some margin to in the port count instead of planning on 100% utilisation - just as you have allowed a marging in the bandwidth.

    Tom

  • carolwood (6/26/2010)


    Hello Friends.....

    Sizing a database can be one of the most arduous tasks a DBA, analyst or developer must attend to. It’s time consuming and more hours go into analyzing the database than actually sizing it. This article focuses on how to monitor the database’s growth after its deployed and contains some tips on how to size it before deployment. We will also dive a little into how to benchmark your database against a robust data load.

    Thanks

    Ummm.... WHICH article???

    --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)
    Intro to Tally Tables and Functions

  • Jeff Moden (6/26/2010)


    carolwood (6/26/2010)


    Hello Friends.....

    Sizing a database can be one of the most arduous tasks a DBA, analyst or developer must attend to. It’s time consuming and more hours go into analyzing the database than actually sizing it. This article focuses on how to monitor the database’s growth after its deployed and contains some tips on how to size it before deployment. We will also dive a little into how to benchmark your database against a robust data load.

    Thanks

    Ummm.... WHICH article???

    It's a spam post. Content copied from elsewhere, link in sig.

    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
  • GilaMonster (6/27/2010)


    It's a spam post. Content copied from elsewhere, link in sig.

    That's what I was starting to think because of other posts of that user.

    --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)
    Intro to Tally Tables and Functions

  • Dunno if anyone else has done it but.... reported.

    --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)
    Intro to Tally Tables and Functions

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

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