To use the inner replica facility, you need the HiRDB Staticizer Option. For details about the inner replica facility, see the manual HiRDB Version 9 Staticizer Option Description and User's Guide.
- 176) pd_inner_replica_control = inner-replica-maximum-group-count
- ~<unsigned integer>((1-4194296))<<0>>
- Specifies the maximum number of inner replica groups to be used. For this operand, specify a value that is greater than the number of inner replica groups used during normal startup of HiRDB.
- For a HiRDB parallel server configuration, specify the largest inner replica group count among those managed by back-end servers. For example, specify at least 31 for this operand for the following back-end server configuration:
- Back-end server 1 has 10 inner replica groups.
- Back-end server 2 has 20 inner replica groups.
- Back-end server 3 has 30 inner replica groups.
- Notes
- If the actual number of inner replica groups is greater than the value specified for this operand, HiRDB cannot be started.
- The number of inner replica groups to be defined cannot exceed the value specified for this operand.
- Increasing the specification value of this operand increases the shared memory used by a single server or back-end server. Therefore, do not specify an unnecessarily large value. If a shortage occurs in the shared memory, HiRDB might not be able to start. For details about the shared memory used by a single server and back-end servers, see the HiRDB Version 9 Installation and Design Guide.
- Real Time SAN Replication based on the log-only synchronous method cannot be used together with the inner replica facility. If an attempt is made to use them together, HiRDB cannot be started.
- Relationship to other operands
- When this operand is specified, NONE is assumed in the pd_indexlock_mode operand.
- Effects on individual estimation formulas
- If the value of the pd_inner_replica_control operand is changed, the following estimation formulas are affected:
- HiRDB Version 9 Installation and Design Guide:
- Calculation of required memory under Estimating the memory size required for a HiRDB single server configuration
- Calculation of required memory under Estimating the memory size required for a HiRDB parallel server configuration
- Formula 5 under Formulas for shared memory used by a single server
- Formula 5 under Formulas for the size of the shared memory used by a back-end server
- 177) pd_inner_replica_lock_shift = Y | N
- Specifies whether a UAP and commands can be executed concurrently when the inner replica facility is being used. The following commands can be executed concurrently with a UAP:
- pddbchg
- pdorbegin
- pdorchg
- pdorend
- Y:
- Permits concurrent execution of a UAP and commands while the UAP is executing within a server, provided that the original RDAREA of the RDAREA that the UAP is processing is different from the original RDAREA of the RDAREA that the command is processing. Concurrent execution is not allowed if the original RDAREAs are the same.
- N:
- Does not permit concurrent execution of a UAP and commands while the UAP is being executed within a server. When you specify N, fewer resources are locked during UAP execution compared to when Y is specified.
- The table below shows whether concurrent command and UAP execution is permitted, depending on the specification:
Execution sequence | pd_inner_replica_lock_shift operand specification | Original RDAREA of the processing target RDAREA |
---|
Different | Same |
---|
Command starts while UAP is executing | N | No | No |
Y | Yes | No |
UAP starts while command is executing | -- | Yes | No |
- Legend:
- Yes: Command and UAP can execute concurrently.
- No: Command and UAP cannot execute concurrently.
- --: Not applicable
- Differences in locked resources depending on the specification of this operand are shown below:
Execution sequence | pd_inner_replica_lock_shift operand specification | Lock |
---|
Locked resource | Range of lock | Locked resource count compared to use of inner replica |
---|
Command starts while UAP is executing | N | Inner replica configuration management | Single server or back-end server | Increases by one |
Y | Replica loop configuration management | Inner replica loop | Increases by number of target RDAREAs of processing |
UAP starts while command is executing | -- | Replica loop configuration management | Inner replica loop | Increases by number of target RDAREAs of processing |
- Legend:
- --: Not applicable
- 178) pd_lv_mirror_use = Y | N
- Specifies whether to set the open attribute of the replica RDAREA to SCHEDULE.
- Y:
- Sets the open attribute of the replica RDAREA to SCHEDULE.
- N:
- Sets the open attribute of the replica RDAREA to that of the original RDAREA. The open attribute of the original RDAREA is specified by the following operands:
- pd_rdarea_open_attribute_use
- pd_rdarea_open_attribute
- Specification guidelines
- If you use the inner replica facility under Logical Volume Manager (LVM), the open attribute of the replica RDAREA must be set to SCHEDULE. Therefore, specify Y for this operand. For details, see Notes on Operation in Logical Volume Management in the manual HiRDB Version 9 Staticizer Option Description and User's Guide.
- If you do not use LVM, specify N for this operand.
- Note
- Note that specifying Y for this operand increases the shared memory used by a single server or back-end server. If a shortage occurs in the shared memory, HiRDB might not be able to start. For details about the shared memory used by a single server and back-end servers, see the HiRDB Version 9 Installation and Design Guide.
- 179) pd_inner_replica_hold_status = NORMAL | HOLD
- Specifies whether replica RDAREAs with the DEFER or SCHEDULE attribute are to be placed on command hold when HiRDB starts normally. The status of any RDAREAs in error shutdown status remains unchanged.
- NORMAL: Do not place HiRDB in command hold status.
- HOLD: Place HiRDB in command hold status.
Table 2-5 Statuses of replica RDAREAs and the pd_inner_replica_hold_status operand value
No. | Status of replica RDAREA | pd_inner_replica_hold_status operand value |
---|
Open attribute of RDAREA | Status of RDAREA during normal termination of HiRDB | NORMAL | HOLD |
---|
1 | DEFER | Error shutdown | Error shutdown and closed | Error shutdown and closed |
2 | Other than error shutdown | Closed | Command hold and closed |
3 | SCHEDULE | Error shutdown | Error shutdown and closed | Error shutdown and closed |
4 | Other than error shutdown | Closed | Command hold and closed |
- Condition
- This operand takes effect if the following conditions are satisfied:
- HiRDB Staticizer Option is installed and the inner replica facility is used.
- The open attribute of replica RDAREAs is DEFER or SCHEDULE.
- Advantages
- When HiRDB starts normally, replica RDAREAs with the DEFER or SCHEDULE attribute are normally closed, but the disk can be updated (because the disk is automatically placed in open status when it is accessed). If, while the pair volumes of original and replica RDAREAs are paired, an attempt is made to update a replica RDAREA using an SQL statement such as a definition SQL statement an input/output, an error occurs and the replica RDAREA is placed in error shutdown status.
- If this operand value is HOLD, replica RDAREAs cannot be accessed unless the user explicitly releases the RDAREAs from shutdown status. This protects RDAREAs from being placed in error shutdown status by erroneous operations.
- Specification guidelines
- If you run an operation that pairs the pair volumes of original and replica RDAREAs when HiRDB starts normally, we recommend that you specify HOLD in this operand.
- Notes
- If HOLD is specified in this operand, replica RDAREAs are placed in command hold and closed status immediately after HiRDB has started normally. When you are ready to access the replica RDAREAs, use the pdrels command to release the RDAREAs from shutdown status.
- If you specify HOLD in this operand and execute a definition SQL statement while the target replica RDAREA is in command hold and closed status, the KFPH22032-W message is issued. If this happens, take the appropriate action by referencing Output and handling of the KFPH22032-W message in the HiRDB Version 9 Staticizer Option Description and User's Guide.
- Relationship to other operands
- This operand is related to the following operands:
- pd_rdarea_open_attribute_use
- pd_rdarea_open_attribute
- pd_lv_mirror_use
- 180) pd_max_reflect_process_count = number-of-processes-to-be-allocated-for-reflection-processing
- ~<unsigned integer>((1-256))
- Specify this operand if you plan to perform updatable online reorganization. If you omit this operand, you cannot perform updatable online reorganization.
- For this operand, specify the number of processes to be used for reflection processing. HiRDB allocates the number of processes specified by this operand. For a HiRDB parallel server configuration, the value specified for this operand indicates the number of processes per front-end server.
- Specification guidelines
- The value of this operand must satisfy the following condition. Otherwise, HiRDB cannot be started.
For a HiRDB single server configuration, value of pd_max_reflect_process_count + value of pd_max_users
3,000 (maximum value of pd_max_users)
For a HiRDB parallel server configuration, value of pd_max_reflect_process_count + value of pd_max_users
2,000 (maximum value of pd_max_users)
- For the number of processes to be allocated for reflection processing (formula for estimating the value for the pd_max_reflect_process_count operand), see the manual HiRDB Version 9 Staticizer Option Description and User's Guide.
- Effects on individual estimation formulas
- If the value of the pd_max_reflect_process_count operand is changed, the following estimation formulas are affected:
- HiRDB Version 9 Installation and Design Guide:
- Considerations when migrating to 64-bit mode
- Calculation of required memory under Estimating the memory size required for a HiRDB single server configuration
- Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB single server configuration
- Calculation of required memory under Estimating the memory size required for a HiRDB parallel server configuration
- Formulas for shared memory used by a unit controller under Estimating the memory size required for a HiRDB parallel server configuration
- Processes Started by HiRDB
- Estimating HP-UX OS parameter values
- Estimating Linux kernel parameter values
- Estimating Solaris OS parameter values
- Size of a work table file used by an SQL statement
- Determining the value of S under Determining the size of status files
- Determining the maximum number of files (pdfmkfs -l command)
- Determining the number of records in a synchronization point dump file
- Formula 2 under Formulas for shared memory used by a single server
- Formula 2 under Formulas for the size of the shared memory used by a back-end server
- Estimating the sizes of message queues and semaphores
- 181) pd_log_org_reflected_logpoint = keep | release
- Specify this operand if you plan to perform updatable online reorganization.
- This operand specifies whether to change the status of the system log file for which reflection processing has been completed.
- keep:
- Does not change the status of the system log file for which reflection processing has been completed. Even when reflection processing has been completed for all update logs inside the file, the system log file is kept in the overwriting-denied status for online reorganization.
- release:
- Changes the status of the system log file for which reflection processing has been completed. When reflection processing has been completed for all update logs inside the file, the system log file status is changed from the overwriting-denied status for online reorganization to the overwriting-permitted status for online reorganization.
- Note that in the following cases, the system log file status is changed from the overwriting-denied status for online reorganization to the overwriting-permitted status for online reorganization regardless of the value specified for this operand.
- All reflection processes have been terminated.
- The pdorbegin -u command is executed.
- The pdorend -u command is executed.
- Specification guidelines
- The values specified for this operand and the pd_log_org_no_standby_file_opr operand determine how the overwriting-denied status for online reorganization of the system log file changes and how updatable online reorganization is performed. For the specification guidelines for this operand, the manual HiRDB Version 9 Staticizer Option Description and User's Guide.
- Note
- Following forcible termination, abnormal termination, or planned termination, you can change the specification value of this operand from keep (default value) to release only.
- 182) pd_log_org_no_standby_file_opr = stop | continue
- Specify this operand if you plan to perform updatable online reorganization.
- This operand specifies the processing for HiRDB when system log file swapping occurs while all system log files are in the overwriting-denied status for online reorganization.
- stop:
- Forcibly terminates HiRDB. For a HiRDB parallel server configuration, the applicable unit is forcibly terminated.
- continue:
- The overwriting-denied status for online reorganization is changed to the overwriting-permitted status for online reorganization, and processing continues. For a HiRDB parallel server configuration, this option applies to the system log files inside the server.
- Specification guidelines
- The values specified for this operand and the pd_log_org_reflected_logpoint operand determine how the overwriting-denied status for online reorganization of the system log file changes and how updatable online reorganization is performed. For the specification guidelines for this operand, see the manual HiRDB Version 9 Staticizer Option Description and User's Guide.
- Note
- If you forcibly release the overwriting-denied status for online reorganization by specifying continue for this operand, system log files used after that time are not placed in the overwriting-denied status for online reorganization. Consequently, if a system log file that has an update log that has not been reflected to the main-system RDAREA is overwritten, reflection processing might not be executed. In this case, HiRDB continues executing jobs using only the current sub-system RDAREAs. To return the main-system RDAREA to the current status or to re-execute updatable online reorganization, you need to restore the main-system RDAREA from the sub-system RDAREA in advance. For the procedure for restoring the main-system RDAREA, see the manual HiRDB Version 9 Staticizer Option Description and User's Guide.