TMF Planning and Configuration Guide (H06.05+)

Doing an Initial Configuration
HP NonStop TMF Planning and Configuration Guide—540136-002
2-9
NonStop SQL/MP Considerations When Configuring
TMF
•
Do not audit log files. If a log file is audited, TMF backs out event records after a
failure, thereby eliminating valuable historical information about failure events.
•
A database with audited and nonaudited tables can be left in an inconsistent state
after a failure. After a failure, audited tables are recovered to their original,
consistent state, while updates to nonaudited tables are left in an unknown state. If
you configure audited and nonaudited tables in the same database, you must
develop a strategy for restoring the database to a consistent state after a failure.
Consider configuring TMF to audit all tables to ensure both the integrity of the
database and timely recovery from media failures or failed transactions.
•
In general, TMF should be running whenever users are running NonStop SQL/MP
application programs or using SQLCI, to ensure auditing.
•
Certain SQL Utility and DDL operations might generate significant amounts of audit
information. These operations require a different audit-trail configuration from that
required by normal day-to-day operations. The amount of audit generated by this
request could exceed your current settings, so you might need to increase the size
of your audit trail. For more information about increasing the size of an audit trail,
refer to Changing the Audit-Trail Configuration on page 3-3 and Increasing Audit-
Trail Capacity on page 3-6.
For tables or indexes containing over 400 partitions, HP recommends that you
configure a large audit trail. If you need to configure a large audit trail for these
reasons, it is best to do so immediately after installing NonStop SQL/MP, to ensure
sufficient disk space and maximize TMF’s protection of your database.
•
Other SQL Utility and DDL operations can run for long periods without generating
much audit information. For example, creating an index on a table that contains a
large amount of data could take longer than two hours. Because the index create
operation is run in a single transaction, you need to increase the transaction
timeout limit (which is called the autoabort threshold).
HP recommends increasing the autoabort threshold by one hour for each gigabyte
of data in the table. For example, if your table contains three gigabytes of data, the
autoabort threshold should be three hours. For more information about the
autoabort threshold, refer to Controlling Transaction Duration (Autoabort) on page
4-1.
•
Still other SQL Utility and DDL operations can generate significant amounts of
audit information and run for a long time. One example of such an operation is
moving a partition boundary on a table with a large number of partitions when the
partition being split contains many rows. These types of operations require both
large audit trails and high autoabort thresholds.