SQL/MX Release 2.0 Best Practices

Database Sizing Considerations 18
Database Sizing Considerations
General Rules for Sizing
This section includes some general rules for sizing a database system when very few details are known
about the application.
A processor supports about 30 to 50 gigabytes of data (logical data, based on common customer
implementations); the number varies based on the processors and types of storage chosen. Please
consult your hardware representative for your processor and storage configuration abilities.
The total table space is about 1.5 times that of the base table data. Indexes generally are used only
on the dimension tables.
Specify at least one empty disk volume for sort and workspace.
Specify at least one empty disk volume for OSS for standard I/O.
Purchase the maximum memory that the processors can support.
Plan to mirror all volumes. There is an advantage to parallel reads from a disk that is mirrored.
Sizing Questionnaire
These questions arise from the need to properly size the NonStop system. Much of the information needed
probably already exists from the initial project-planning activities.
Quantifiable Metrics
For each legacy system involved:
How many records will be extracted:
For the initial load?
For cyclical updates?
What are the record sizes?
What is the frequency of extraction?
For the Database System
What is the required transaction each second?
What are the service-level agreements?
How many rows will be loaded initially?
What is the anticipated row size?
What is the frequency of updates:
For the operational data store (ODS)?
For the warehouse?
How many rows will be inserted cyclically? Updated? Deleted?
What are the response-time requirements?
What is the number of concurrent users? (For sizing, concurrent is defined as the number of users
actively running a query and not the number of sessions established.)
What is the total number of users?
What is the total number of sessions?
How long will a history be maintained:
In the ODS?
In the warehouse?