Examples: Restoring Sql Files - HP BACKCOPY Reference Manual

◦
Constraints are mismatched with the underlying table.
◦
Physical attributes of partitions are mismatched.
The state of restored SQL files depends on the particular RESTORE options that were used
during the BACKUP and RESTORE processes. The default options of BACKUP and RESTORE
are:
PARTONLY OFF, INDEXES IMPLICIT
If only the default options are used, these statements are true:
◦
Sets of logically related objects such as partitions and indexes are backed up and restored
together.
◦
The default RESTORE process purges any existing objects with identical names.
◦
At the completion of the RESTORE process, the restored objects are in a valid state. That
is, the objects are now accessible for normal use such as running SQL queries, and so
on.
When you use the PARTONLY option with SQL files:
◦
If the existing disk file is an SQL table partition and the PARTONLY option is ON, only
the partition is purged. The other partitions and the indexes on the table are preserved.
If the PARTONLY option is OFF, an SQL DROP TABLE command is applied to the table,
which causes the entire partitioned table and all indexes defined on the table to be
dropped. Any SQL program that depends on the table is marked invalid.
◦
If the existing disk file is an SQL index partition and the PARTONLY option is ON, only
that partition of the index is purged. If the PARTONLY option is OFF, an SQL DROP INDEX
command is applied to the index, which causes all partitions of the index to be dropped.
Any SQL program that depends on the index is marked invalid.
◦
If the existing disk file is an SQL view definition, an SQL DROP VIEW command is applied
to the view whether the PARTONLY option is ON or OFF. For more information about
the effects of the SQL DROP TABLE, DROP INDEX, and DROP VIEW commands, see the
SQL/MP Reference Manual.
◦
RESTORE PARTONLY ON operations on SQL objects involve timestamp updates and
partition array synchronization to partitions not included in the restore-files
parameter. All logically related table and index partitions, views, collations, and SQL
programs are affected. Error messages appear when required elements are not yet present
or are unavailable for update. Temporary, corrupt file labels might be created for missing
table and index partitions. Some severe situations, such as missing nodes, can result in
partitions being left offline.
◦
The final RESTORE PARTONLY ON session performs steps that cannot complete successfully
until all index and table partitions are recovered. These include placing partitions online,
linking indexes to the table partitions, and verification. Ideally, the primary partition of
the base table should be the last piece recovered to disk though, through special handling,
RESTORE can handle most situations where this is not the case.

Examples: Restoring SQL Files

The first four examples correspond to the Example (page 80):
RESTORE Guidelines and Examples 169