Post reply

Some good tips on projecting database growth?

  • December 4, 2009 at 7:18 am

    #213161

    Hi folks, I was wondering if there were some good tips/guidelines out there on how to project sizing in the future for various database systems we have. We are planning a move to a new data center and in anticipation of that, they have asked the DBA's what we think we need.

    We have sufficient data for at least a year back to establish daily/weekly/montly values (we'll probably go weekly) and the math is pretty straightforward. I guess I'm looking for the softer, "intangible" ways to give ourselves a good margin of safety.

    Thanks.

    Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein

  • December 5, 2009 at 4:51 pm

    #1088201

    I just love questions that include the answer.

    As stated uou already have the volume metrics, trust the data 😉

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.

  • December 5, 2009 at 6:18 pm

    #1088209

    Yep... I agree with Pablo... you already have the metrics... make a spreadsheet and a graph from that and extend the line. 🙂

    --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 5, 2009 at 6:58 pm

    #1088216

    If you have the data, that's the way I'd go.

    I was going to suggest using backup sizes, which is how I've tracked database growth over time. I have autogrow set for emergencies, and I monitor the free space, but watching the trend of backup sizes allows me to just see a rough aggregate of data changes. It also allows me to catch strange events like secret loads of data when I see a backup size change unexpectedly.

  • December 7, 2009 at 9:29 am

    #1088665

    Thanks folks, will trust the data then. Regarding backup sizes, I'll have to modify that as some of our backups are compressed, but otherwise, it looks like I have all I need.

    Cheers. 🙂

    Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein

  • January 4, 2010 at 3:03 pm

    #1098658

    If you retain backup history, that shows the data size before compression. Keep in mind that backups don't show free space, so you need to account for that as part of disk space used.

Viewing 6 posts - 1 through 5 (of 5 total)

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