#6 Database Partitioning and SDS/RPS
Posted: Tue Sep 07, 2010 1:41 pm
This Jade Source bulletin applies to any developer using partitioned files in a Synchronized Database Service (SDS) environment. While not in the current documentation, it will be included in the JADE 6.3.06 Release Information and the 7.0 JADE Synchronized Database Service (SDS) Administration Guide.
Description:
Partitioned file structures and most meta data are replicated on SDS secondary databases. 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 has been extended to support 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 on 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.
The following table lists file partition operations.
When considering use of partitioned database files in a Synchronized Database Environment (SDE):
Partitioned file structures and meta data are replicated on full replica and mapped extent RPS databases.
File partitioning is not applicable on a working set RPS database.
Description:
Partitioned file structures and most meta data are replicated on SDS secondary databases. 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 has been extended to support 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 on 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.
Code: Select all
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 YesCode: Select all
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- 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 site can be restored at either site in the event of a disaster.
Partitioned file structures and meta data are replicated on full replica and mapped extent RPS databases.
File partitioning is not applicable on a working set RPS database.