These issues are not strictly speaking performance tuning issues, but they do affect performance in real ways by determining what data is available, when it is available, and how it is backed up and restored in case of failure or corruption.
Fragmentation can improve data availability if devices fail. Table fragments on the failed device can be restored quickly, and other fragments are still accessible.
An OLTP application or a query that does not require data in an unavailable fragment can still successfully retrieve data from fragments that are available.
Some DSS applications might be designed in such a way that they can accept the unavailability of data in a fragment and retrieve only the data that is available. For example, some decision-support queries require only a statistical sample of the table data.
Consider how restoring tables and fragments of tables might affect transaction and query processing and whether warm or cold restores would be required to restore backed-up data.
Although you must perform a cold restore if a dbspace that contains critical data fails, you need to perform only a warm restore if a noncritical dbspace fails.
Reduce the impact of cold restores by careful choice of the dbspace where you store critical data, which includes the root dbspace on each coserver and all dbspaces that contain logical or physical logs. If possible, store critical data on separate disks.
For more information about backup and restore, see the IBM Informix: Backup and Restore Guide.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]