Capacity planning

  • Can someone help me out with the questions that I need to ask the application team in regards to capacity planning? This for a new application.

    The questions that I can think of are listed below:

    (1) The criticality of the data, so I can plan the backup strategy.

    (2) If it's used for both OLTP and OLAP, so that I could setup replication to a reporting server.

    (3) Estimated database size.

    (4) If the database needs to be on a dedicated server.

    (5) Users who need to have read or write or both permissions.

    (6) How many users will be accessing the data.

    (7) Any other datasources that the database need to connect to get the data.

    I'd appreciate if you could add any to the above listed ones.

    My other important question is how much memory and how many CPUs should I allocate as I do not know anything about the application? My worry is that I may either over assign or under assign resources.

  • A lot of what you're asking about isn't necessarily related to capacity planning. Just speaking on capacity planning, focus on size and volume and growth. "How many" and "how much" are going to be the primary questions.

    How large will the initial database be?

    How much anticipated growth per day?

    How big will the database get over the next year, two years, three years, five years?

    How many users will have access to the system?

    How many active connections per minute?

    How many transactions per minute?

    You should have a bunch of questions regarding Point of Recovery and Time of Recovery so that you can set up appropriate backups and log settings, all of which affect capacity planning. And those are questions for the business, not technical questions.

    How large are the transactions?

    Do you have performance or load testing results? If not, can we build some?

    That's what I've got off the top of my head.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • To gauge memory and CPU create a dummy load expected on the application database and stimulate the environment as production. However calculate the expected future growth and keep the buffer.

    HTH

    ---------------------------------------------------
    "Thare are only 10 types of people in the world:
    Those who understand binary, and those who don't."

  • With due respect, this is starting from the wrong end, one should not focus on technical but business quantifiable for overall quantities and sizes, from there its all either division or multiplication.

    😎

  • Part of the answer to this question is how many tables and /or columns to existing tables you think could be added? You multiply the size per one row times the number of rows you anticipate you may have. This will also depend on how well you profile future data and thus apply sharpening. Or are your fields usually a datetime ( as opposed to smalldatetime if warranted ) and varchar(255) which makes it easy to capacity plan but I would not go that route. Better to overestimate a little though.

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

  • If it is a new application then have they got a test version available for you to examine the database and have they done any load trials on that?

    If bought-in what does the supplier recommend and what use will it have within your business?

    If developed in-house, is the database properly designed and optimised? If in-house why haven't you been involved in the design from the start?

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

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