One of the first things that must be determined when planning new database is how much disk space will be required to support the database. The idea is to both ensure that there is sufficient disk space available for data expansion and to reduce the amount of data and log file growths that are performed to accommodate the data expansion to improve database efficiency.
If the database is being built to support an application purchased from a vendor, the capacity planning for the database should be very easy. However, the simplicity depends on the software vendor providing detailed documentation. The documentation must describe the average size of the database after periodic intervals where a defined number of users and transactions were supported. If the documentation is provided, you will have a good idea of what to expect from the database and can configure it accordingly. If the vendor did not provide the information, your job as a database administrator becomes a bit more complicated, and you may just have to guess. However, it must be an educated guess using as much
information as you are able to collect. The difficulty is often in the fact that you may not know how the vendor is storing and retrieving data, so the database must be monitored for growth trends to adequately predict the amount of storage space.If the database is being designed and built internally, there are established techniques for determining how big the data files will need to be. These techniques work because you know how much data is added for every transaction, whereas in a vendor-provided database, that information may not be available.One such technique that I am sure you will encounter is calculating a database size requirement by calculating table sizes.
It looks like this:
1)Add up the total number of bytes used by the fixed-length columns in the table.
2)Average the total number of bytes used by the variable-length columns in the table.
3)Add the number from Step 1 to the number calculated in Step 2.
4) Divide 8,060 (the maximum amount of data bytes in a page) by the number calculated in Step 3, and round down to the nearest whole number. This is the number of rows that will fit on a single page. Remember that rows cannot span pages, which is why you round down.
5. Divide the total number of expected rows by the number of rows per page calculated in Step 4. This is the total number of data pages expected to support the table.
6. Multiply the number calculated in Step 5 by 8,192 (the size of the data page). This is the total number of bytes required for the table.
7. Repeat the process for every table in the database.
