I know this has been covered before (perhaps ad nauseum), but it never hurts to get ask.
I am in the process of preparing for a upgrade for a 400+GB db from 10.2B08 to 11.7.1 (or .2 or whatever is available when the upgrade happens by year end).
Many moons ago we set them up with type II storage areas, where tables with lots of record adds going into their own data and index areas, and pretty much the rest went into a single areas for data and indexes.
I am planning on doing a dump/load for the upgrade, and would like some thoughts on recommendations for the table areas layout.
I have analyzed the existing mean record sizes to come up with RPB's as well as utilizing record counts + utilization (yes I know all of our code usage for the tables) to come up with tentative cluster sizes.
The large tables that have lots of reads/updates/additions (sales, etc) will have their own data/index areas as I currently have them laid out.
What I am wondering for the relatively static tables:
- Should relatively static but lots of reads/updates tables be segregated into their own areas or does it matter?
- Should like sized RPB's be in their own data areas? Or does it really matter if I make them into all say 128 RPB areas vs a 64 and 128 (or even 256)?
- Does it make sense to have the index areas match the data areas, or should indexes be put together in one index area?
I am also going to utilize B2 (finally). We have a number of smallish but highly read tables that I am planning on moving into B2 (which I should have already done, but ... ).
- Is there a practical limit as to efficiency when allocating B2 when taking memory from -B ?
- If a smallish table gets updated frequently is it still a good candidate for B2?
Any and all comments, suggestions, criticisms welcome!
I am in the process of preparing for a upgrade for a 400+GB db from 10.2B08 to 11.7.1 (or .2 or whatever is available when the upgrade happens by year end).
Many moons ago we set them up with type II storage areas, where tables with lots of record adds going into their own data and index areas, and pretty much the rest went into a single areas for data and indexes.
I am planning on doing a dump/load for the upgrade, and would like some thoughts on recommendations for the table areas layout.
I have analyzed the existing mean record sizes to come up with RPB's as well as utilizing record counts + utilization (yes I know all of our code usage for the tables) to come up with tentative cluster sizes.
The large tables that have lots of reads/updates/additions (sales, etc) will have their own data/index areas as I currently have them laid out.
What I am wondering for the relatively static tables:
- Should relatively static but lots of reads/updates tables be segregated into their own areas or does it matter?
- Should like sized RPB's be in their own data areas? Or does it really matter if I make them into all say 128 RPB areas vs a 64 and 128 (or even 256)?
- Does it make sense to have the index areas match the data areas, or should indexes be put together in one index area?
I am also going to utilize B2 (finally). We have a number of smallish but highly read tables that I am planning on moving into B2 (which I should have already done, but ... ).
- Is there a practical limit as to efficiency when allocating B2 when taking memory from -B ?
- If a smallish table gets updated frequently is it still a good candidate for B2?
Any and all comments, suggestions, criticisms welcome!