createRpsDatabaseMultithreaded
createRpsDatabaseMultithreaded(backupDir: String;
schema: Schema;
rpsMapping: RelationalView;
rpsStorageMode: Integer;
verifyFiles: Boolean;
overwriteFiles: Boolean;
quiesce: Boolean;
workers: Integer) updating;
The createRpsDatabaseMultithreaded method of the JadeDatabaseAdmin class creates a multithreaded RPS database for a specified schema and RPS mapping in the directory specified in the backupDir parameter. The backup directory must be a writable valid directory that is relative to the server.
This method can be executed on the primary system only.
This method can be called only if the method is not currently in a shared transient transaction. An error will be displayed if another user in a shared transient transaction tries to call it.
The database and partition files are processed according to size, with the largest files being processed first.
Specify the schema and RPS mapping (that is, the RPS name) for which the multithreaded RPS database is to be created in the schema and rpsMapping parameters, respectively.
Specify the storage mode of the created RPS database in the rpsStorageMode parameter, using one of the JadeDatabaseAdmin class constants listed in the following table.
| Class Constant | Integer Value | Description |
|---|---|---|
| RpsStorageMode_Full | 0 | Full database replica RPS data store mode |
| RpsStorageMode_MappedExtent | 1 | Mapped extent RPS data store mode |
For details about the RPS database storage modes, in "RPS Data Store", see Chapter 2, "
Set the verifyFiles parameter to true if you want the RPS mapping entities checked, or verified. In a checked RPS database creation, entities are read using the database access routines and object caching mechanisms, and at the same time, a verification of the data and indexes is performed. The verification performs various consistency checks similar to a database certify, to ensure the integrity of the RPS database creation. Furthermore, additional checksum information is added to the RPS database creation, to allow restore operations to verify the integrity of the RPS system.
Set the overwriteFiles parameter to true if you want to allow RPS database entities to overwrite existing entities in the destination RPS database. When this parameter is false, an exception is raised if an existing entity is detected.
Use the quiesce parameter to allow a quiesced read-only database transaction to be specified. When you set this parameter to true, the database is placed in a quiescent state by first allowing current active transactions to be completed and flushing modified buffers for cache to the stable database. In this mode, physical database files contain all committed updates to the database, and the files are opened in read-only mode with shared read access allowing the RPS create process to safely copy database files. In the quiescent mode, updating transactions are not permitted and attempts to execute database transactions raise a database exception. When an RPS database creation is performed in the quiescent mode, the physical database files are guaranteed to contain all database updates and a quiesced RPS database does not require backup recovery.
Set the quiesce parameter to false to allow updates during the RPS database creation process. When restoring an RPS database created with this option (that is, false), the restoration process requires the recovery of database transaction journals, which will be automatically transferred from the primary and the transactions applied.
Although this method runs a multithreaded backup, the current executing thread of this method still waits for the entire backup to be finished before it executes any following method.
For the workers parameter:
-
If the number of workers is less than 1 (in the range zero (0) through any negative Integer value that is overridden to zero), this method performs a backup in the current thread, in the same manner as the createRpsDatabase method.
-
If the number of workers is 1 or greater, the createRpsDatabaseMultithreaded method implements the creation of a multithreaded RPS database with the specified number of worker applications.
-
The maximum number of workers is capped at the total number of database files and partitions required to be backed up; that is, if you specify a large number of workers, it will be adjusted to the total number of database files and partitions required to be backed up.
2025.0.01 and higher
