Capacity Plan Revision
Hi There,
How can i do Capacity Plan Revision for a database
Please provide me step by step information
Thanks
How can i do Capacity Plan Revision for a database
Please provide me step by step information
Thanks
momi_sabag
which platform do you use?
Hi Nav29,
That's really a lot bigger question than you realize. Kind of like hiring an engineer fresh out of college and telling him to "build me a car". You'll get 4 wheels, a motor, and brakes, but beyond that it's a function of the mind of someone that has no idea what you really want.
What you've asked for is similar. There are a lot of variables involved that only the DBA really knows. Without a good understanding of these variables, a decent estimate is impossible. (Then again, maybe you just want to know some of the variables?)
The first question is what kind of database is it? An OLTP typically grows with every transaction as they are recorded in the history file. An OLTP with 1,000 updates/day won't grow very quickly. An OLTP with 1,000 updates/second has an incredible need to be properly designed and runs the risk of quickly exceeding the system's mass storage capacity. At some point, no amount of disk will help as the database will exceed the server's ability to process the transactions quickly enough.
On the other hand, an OLAP is typically a very stable database. It is a summary of an OLAP the is designed to meet the needs for quick reporting. A data warehouse is a special kind of OLAP. Even though they will grow, it is generally at a rate much, much slower than an OLTP. The challenge here is that an OLAP will often exceed the server's ability to build and/or update the OLAP much more quickly than it will fill the available disk space.
Only after that database type (usage) is known can the next step be taken in Capacity Planning. And the next step is to understand how the database changes on a daily bases to know what resources are most in demand.
Kent
That's really a lot bigger question than you realize. Kind of like hiring an engineer fresh out of college and telling him to "build me a car". You'll get 4 wheels, a motor, and brakes, but beyond that it's a function of the mind of someone that has no idea what you really want.
What you've asked for is similar. There are a lot of variables involved that only the DBA really knows. Without a good understanding of these variables, a decent estimate is impossible. (Then again, maybe you just want to know some of the variables?)
The first question is what kind of database is it? An OLTP typically grows with every transaction as they are recorded in the history file. An OLTP with 1,000 updates/day won't grow very quickly. An OLTP with 1,000 updates/second has an incredible need to be properly designed and runs the risk of quickly exceeding the system's mass storage capacity. At some point, no amount of disk will help as the database will exceed the server's ability to process the transactions quickly enough.
On the other hand, an OLAP is typically a very stable database. It is a summary of an OLAP the is designed to meet the needs for quick reporting. A data warehouse is a special kind of OLAP. Even though they will grow, it is generally at a rate much, much slower than an OLTP. The challenge here is that an OLAP will often exceed the server's ability to build and/or update the OLAP much more quickly than it will fill the available disk space.
Only after that database type (usage) is known can the next step be taken in Capacity Planning. And the next step is to understand how the database changes on a daily bases to know what resources are most in demand.
Kent
ASKER
its Database server = DB2/6000 8.2.9
whats this means
1) in order to get the size of a table, you need to do
(a) runstats on the table
(b) query NPAGES in syscat.tables for the table, the returned number is the number of pages, you need to times 32 KB to get it in Bytes.
whats this means
1) in order to get the size of a table, you need to do
(a) runstats on the table
(b) query NPAGES in syscat.tables for the table, the returned number is the number of pages, you need to times 32 KB to get it in Bytes.
Hi nav29,
There is a DB2 utility called 'RUNSTATS' that will collect statistics about a table. You'll need to run it, typically from the DB2 command line.
The RUNSTATS process will update the statistics, including the number of pages in the table. You suggest that the table is using 32K pages, so if you'll multiply the number of pages by 32K, you'll get the size of the table in bytes.
Kent
There is a DB2 utility called 'RUNSTATS' that will collect statistics about a table. You'll need to run it, typically from the DB2 command line.
The RUNSTATS process will update the statistics, including the number of pages in the table. You suggest that the table is using 32K pages, so if you'll multiply the number of pages by 32K, you'll get the size of the table in bytes.
Kent
ASKER
Hi Kent,
1) I Know about rustats any easy way i can do runstats for all the tables in one shot ,
as i know how to do for each table from control centre
2) how to query NPAGES in syscat.tables ?
1) I Know about rustats any easy way i can do runstats for all the tables in one shot ,
as i know how to do for each table from control centre
2) how to query NPAGES in syscat.tables ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.