5.2.18 Operands related to server status files
- 60) pd_sts_file_name_1 = "logical-file-name", "file-a-status-file-name", "file-b-status-file-name"
- :
- pd_sts_file_name_7 = "logical-file-name", "file-a-status-file-name", "file-b-status-file-name"
- Define server status files. Although the pd_sts_file_name_2 to 7 operands can be omitted, the pd_sts_file_name_1 operand cannot be omitted.
- "logical-file-name" ~<identifier>((1-8 characters))
- Specifies the logical file name of a status file for the single server.
- When a command that manipulates the status file is to be executed, the logical file name defined here must be specified.
- "file-a-status-file-name" ~<path name>((up to 167 characters))
- Specifies the name of the File A status file as an absolute path name.
- "file-b-status-file-name" ~<path name>((up to 167 characters))
- Specifies the name of the File B status file as an absolute path name.
- Specification guidelines
- The files specified as File A and File B must be status files created with the pdstsinit command. If a file that has not been created with the pdstsinit command is specified, a virtual status file is created.
- If an error occurs in a status file, HiRDB swaps the status files. If no spare file is available for swapping, the unit terminates abnormally. For this reason, defining a large number of system files improves system reliability, but at the expense of increasing the amount of disk space that is required.
- The status files specified for File A and File B must have the same record length and capacity.
- Operand rules
- Up to seven instances of this operand can be specified.
- A status file has a dual structure consisting of File A and File B; both must be specified.
- Environment variables cannot be used for the absolute path names of the File A and File B file names.
- The same names cannot be specified for the logical file name, the File A file name, and the File B file name.
- Notes
- When HiRDB is started normally, the primary file (the file that was the primary file when HiRDB was terminated) is inherited. However, if there is no current file that can be inherited, for example because all status files have been initialized, the first status file that was specified among those specified by the pd_sts_file_name_1 to 7 operands becomes the current file, and the remaining files become spare files if they can be opened. Any files that cannot be opened become reserved files.
- When HiRDB is restarted, the primary file (the file that was the primary file when HiRDB was terminated) is inherited.
- Using a virtual status file
- Specifying a virtual status file makes it possible to add a new status file while HiRDB is running.
- For example, if the number of spare files is reduced because of errors in status files, virtual status files can be converted into spare files. The procedure for converting virtual status files into spare files follows.
- Procedure
- Use the pdstsinit command to create a status file in a HiRDB file system area for system files.
- Use the pdstsopen command to open the status file.
- These operations can be performed while HiRDB is running; there is no need to stop HiRDB.
- Advantages and disadvantages
Defining a virtual status file reduces the amount of space required in the HiRDB file system area. However, a virtual status file cannot be added as a spare file if the HiRDB file system area for system files does not have sufficient space (sufficient space for adding the file), thus reducing system reliability.
When virtual status files are not defined, the amount of space required in the HiRDB file system area is increased. However, because a swap destination is guaranteed when a file error occurs, system reliability is increased.
- Notes
When virtual status files are defined, HiRDB determines that a status file error has occurred when the unit is started. For this reason, HiRDB cannot start if stop (default value) is specified for the pd_sts_initial_error operand. When virtual status files are defined, specify continue or excontinue for the pd_sts_initial_error operand. It is also necessary before starting HiRDB to specify the current file in the pd_sts_last_active_file operand.
- Relationship to other operands
- This operand is related to the pd_sts_subfile_name_1 to 7 operands.
- 61) pd_sts_subfile_name_1 = "logical-file-name","primary-status-file-name-for-log-application-processing","secondary-status-file-name-for-log-application-processing"
:
- pd_sts_subfile_name_7 = "logical-file-name","primary-status-file-name-for-log-application-processing","secondary-status-file-name-for-log-application-processing"
- Defines the server status files for log application processing, which are used at the log application site when Real Time SAN Replication based on the log-only synchronous method is used.
- "logical-file-name": ~<identifier> ((1-8 characters)
- Specifies the logical file name of a server status file for log application processing. This must be a logical file name specified in pd_sts_file_name_1 through pd_sts_file_name_7. A logical file name defined here is used for executing commands that manipulate the status files for log application processing.
- "primary-status-file-name-for-log-application-processing": ~<path name> ((up to 167 characters)
- Specifies the absolute path name of a primary status file for log application processing.
- "secondary-status-file-name-for-log-application-processing": ~<path name> ((up to 167 characters)
- Specifies the absolute path name of a secondary status file for log application processing.
- Conditions
- For details about the supported platforms, see the HiRDB Version 9 Disaster Recovery System Configuration and Operation Guide.
- Y must be specified in the pd_rise_use operand, and also syssync must be specified in the pd_rise_pairvolume_combination operand.
- Specification guidelines
- For the primary and secondary status file names for log application processing, specify the names of status files for log application processing that were created in the preparations for log application. If any other status file for log application processing is specified, the specified file becomes a virtual status file for log application processing.
- If an error occurs in a status file for log application processing, HiRDB swaps status files for log application processing. If no spare file is available for swapping, HiRDB (or the unit in the case of a HiRDB parallel server configuration) terminates abnormally. For this reason, defining a large number of status files improves system reliability, but at the expense of increasing the amount of disk space that is required.
- The specified primary and secondary status files for log application processing must have the same record length and capacity.
- Operand rules
- You can specify a maximum of 7 instances of this operand.
- This operand is ignored at the transaction execution site.
- If you performed the preparations for log application during HiRDB startup, create status files for log application processing that correspond to all status files for transaction processing that can be opened and that were specified in pd_sts_file_name_1 through pd_sts_file_name_7.
- The system uses dual status files for log application processing. Make sure that you specify both files.
- Environment variables cannot be used for the absolute path names of the primary and secondary status files for log application processing.
- Each logical file name, primary status file name for log application processing, and secondary status file name for log application processing must be unique.
- The names of the primary and secondary status files for log application processing must be different from the primary and secondary status file names specified in the pd_sts_file_name_1 through pd_sts_file_name_7 operands.
- Notes
- When HiRDB is started normally or is restarted, the current file (the file that was the current file when HiRDB last terminated) is inherited. However, if there is no current file that can be inherited, such as when all status files for log application processing have been initialized, the log application site can no longer be started. If this occurs, perform the preparations for log application.
- How to use a virtual status file for log application processing
- See the description of the pd_sts_file_name_1 through pd_sts_file_name_7 operands.
- Relationship to other operands
- This operand is related to the pd_sts_file_name_1 through pd_sts_file_name_7 operands.