SDS and Recovery Considerations when Using Partitioned Database Files

Partitioned file structures and most meta data are replicated on SDS secondary databases. For details about database file partitioning, see Chapter 20, "Partitioning Database Files", in the JADE Developer’s Reference.

You can change certain partition attributes such as location on the secondary in order to support a different storage strategy; for example, a tiered strategy on the primary and all partitions on the same default volume on the secondary.

Database tracking logic supports the replay of partitioned file operations, including file-level reorganization and compaction. Certain database file and file partition operations are replayed on SDS secondary databases but some are not. The operations that are replayed in SDS are also reapplied by roll-forward recovery.

The following tables list database file and file partition operations that modify state. The second column indicates whether the operation is replayable; that is, the operation will be audited and reapplied by roll-forward recovery and SDS secondary replay. The third column indicates whether the operation can be executed on an SDS secondary database. In general, if the operation is replayable, it is not valid to execute the operation directly to an SDS secondary. Conversely, if an operation is not replayable, the operation can be executed on a secondary database, allowing the affected state to differ from the primary database.

The following table lists database file operations.

Operation	Replayable	Valid on SDS Secondary?
Set Partitioned	Yes	No
Create Partition	Yes	No
Set Partition Modulus	Yes	No
Freeze	No	Yes
Thaw	No	Yes
Mark Offline	No	Yes
Mark Online	No	Yes

The following table lists file partition operations.

Operation	Replayable	Valid on SDS Secondary?
Freeze	No	Yes
Thaw	No	Yes
MarkOffline	No	Yes
MarkOnline	No	Yes
Move	No	Yes
SetLabel	Yes	No
SetLocation	No	Yes

When considering use of partitioned database files in a Synchronized Database Environment (SDE):

• A file or partition that is not frozen on a primary can be frozen on a secondary. If a file or partition is frozen on the secondary and updated on the primary, the file or partition must be located on writeable media to allow the database tracker to replay updates made to the primary version.

• It is possible and valid to have partitions:

  • Online on a secondary database that are offline on the primary. This could be useful if secondary query applications need access to historical archived data that was taken offline on the production primary.

  • Offline on a secondary database that are online on the primary, provided that the offline partitions are not updated on the primary database. Ideally, the partitions should be frozen on the primary to protect against accidental updates. If the SDS tracker encounters updates that must be applied to an offline file or partition, tracking will halt. User intervention will be required to bring the required file or partition online before resuming tracking.

• When SDS is being used to implement a disaster recovery strategy, you should ensure that backup copies of partitions that are taken offline at the primary or secondary sites can be restored at either site in the event of a disaster.