15.6 Shared RDAREAs (HiRDB/Parallel Server only)
Normally, a back-end server can access only those RDAREAs that are located under that back-end server. By partitioning a table, parallel processing can be applied to table search or update operations, thereby improving the processing efficiency. In the case of a table that is heavily accessed by multiple transactions and that is difficult to partition, you can improve the efficiency of parallel processing by storing the table in a shared RDAREA. A shared RDAREA is a user RDAREA that can be accessed by all back-end servers. A table stored in a shared RDAREA is called a shared table and its index is called a shared index. Shared tables and indexes can be referenced by all back-end servers. Only shared tables and indexes can be stored in a shared RDAREA. Figure 15-5 provides an overview of a shared RDAREA.
Only a HiRDB/Parallel Server can define shared RDAREAs.
Figure 15-5 Overview of a shared RDAREA
![[Figure]](figure/zu140050.gif)
- Explanation:
- The shared RDAREA RDSHR01 can be referenced by all back-end servers, BES1 to BES3. Note that only the updatable back-end server (BES3) can update the shared table; BES1 and BES2 are reference-only back-end servers.
- Organization of this section
- (1) Effects
- (2) Criteria
- (3) Definition method
- (4) Updating a shared RDAREA
- (5) Managing the shutdown status of a shared RDAREA
- (6) Setting system switchover
- (7) Executing utilities and operation commands on a shared RDAREA
- (8) Notes about using shared RDAREAs
(1) Effects
The efficiency of parallel processing improves because all back-end servers can access the shared RDAREA.
(2) Criteria
We recommend that you use shared RDAREAs in the following cases:
- A table is heavily accessed by multiple transactions, but it is difficult to partition the table.
- Complex search processing, such as join processing, is executed.
(3) Definition method
Specify a shared RDAREA as follows:
- Specify Y in the pd_shared_rdarea_use operand.
- Specify SDB in the -k option (purpose) of the pdfmkfs command and specify the name of a character special file. Also set the access path so that all back-end servers will use the same path name to access the shared RDAREA.
- Specify shared in the create rdarea statement of the database initialization utility (pdinit) or database structure modification utility (pdmod) to define a user RDAREA. Also specify an updatable back-end server in the server name operand. Any back-end server that is not specified in the server name operand becomes a reference-only back-end server.
- Notes about definition
- You can define as many shared RDAREAs as the value specified in the pd_max_rdarea_no operand, which is the maximum number of RDAREAs. Note that the number of shared RDAREAs is added to the number of RDAREAs for each back-end server.
- A shared RDAREA cannot be defined in the HiRDB file system area for a back-end server that is not an updatable back-end server for the shared RDAREA.
- A shared RDAREA is defined in the HiRDB file system area for shared RDAREAs. To define a shared RDAREA, specify SDB in the pdfmkfs -k command. Only shared RDAREAs can be defined in a HiRDB file system area for shared RDAREAs.
The following shows an example of a control statement of the database structure modification utility (pdmod) for the shared RDAREA shown in Figure 15-5:
create shared rdarea RDSHR01 globalbuffer buf01 for user used by PUBLIC
server name BES3 ...Specification of updatable back-end server
open attribute INITIAL
page 4096 characters
storage control segment 20 pages
file name "/HiRDB/DATABASE/SHR1/rdshr01_f01" ...file name
initial HiRDB 10000 segments; |
(4) Updating a shared RDAREA
To update a shared RDAREA, you must specify IN EXCLUSIVE MODE in the LOCK statement to lock the shared RDAREA for all back-end servers. In the case of an UPDATE statement that does not change index key values, there is no need to issue the LOCK statement. For details about updating shared tables, see 13.17.3 Manipulating shared tables. Updates to a shared table or shared index are written to the disk when the COMMIT statement is issued.
(5) Managing the shutdown status of a shared RDAREA
Accesses to a shared RDAREA are managed independently by each back-end server. Therefore, in the event of an error, the shutdown status may vary from one back-end server to another. When you execute the database structure modification utility (pdmod) or database recovery utility (pdrstr), you must use the pdhold command to match the shutdown status of the shared RDAREA among all back-end servers. You can use the pddbls -m command to display the status of the shared RDAREA for all the back-end servers.
(6) Setting system switchover
To use a shared RDAREA, you must activate the shared disks that store the shared RDAREAs for all units in which a back-end server is installed. Therefore, in cases in which both an updatable back-end server and reference-only back-end server are installed on the same host, if the updatable back-end server performs system switchover to switch the shared disks, the reference-only back-end server is no longer able to reference the shared RDAREAs. For that reason, to perform system switchover for units on which a back-end server is installed, the method used to set system switchover differs depending on the system switchover system configuration. For details about how to set up system switchover, see the manual HiRDB Version 8 System Operation Guide.
(a) When the standby system switchover configuration is used
- For a 1-to-1 system switchover configuration:
Since the updatable back-end server and reference-only back-end server do not exist on the same host, no special settings are required for a 1-to-1 system switchover configuration. For details about how to set up system switchover, see Shared disk access control by the cluster software in the manual HiRDB Version 8 System Operation Guide.
- For a mutual system switchover or 2-to-1 system switchover configuration:
For a mutual system switchover configuration, no special settings are required unless system switchover is performed for systems other than the updatable back-end server and reference-only back-end server (for example, the system manager, front-end server, or dictionary server). For details about how to set up system switchover, see Shared disk access control by the cluster software in the manual HiRDB Version 8 System Operation Guide.
For mutual system switchover between an updatable back-end server and reference-only back-end server, switching of shared disks cannot be performed. For details about how to set up system switchover, see Shared disk access control by HiRDB in the manual HiRDB Version 8 System Operation Guide.
(b) When a 1-to-1 standby-less system switchover configuration is used
When a 1-to-1 standby-less system switchover configuration is used with an updatable back-end server, the system is switched to the reference-only back-end server, but the shared disks cannot be switched. For details about how to set the system switchover, see Shared disk access control by HiRDB in the manual HiRDB Version 8 System Operation Guide.
(c) When the standby-less system switchover configuration (effects distributed) is used
When a 1-to-1 standby-less system switchover configuration is used with an updatable back-end server, the system is switched to the reference-only back-end server, but the shared disks cannot be switched. For details about how to set system switchover, see Shared disk access control by HiRDB in the manual HiRDB Version 8 System Operation Guide.
- Note:
- Make sure that, for the shared RDAREAs, no reference-only back-end server uses shared disks as a cluster software management resource.
(7) Executing utilities and operation commands on a shared RDAREA
When a utility or operation command is used to process a shared RDAREA, shared table, or shared index, HiRDB may internally issue LOCK TABLE to lock the shared RDAREA for all the back-end servers. If an application is accessing a table or index in the shared RDAREA, deadlock or server-to-server global deadlock may occur. When you execute a utility or operation command, make sure that you place the target shared RDAREA in command shutdown status.
(8) Notes about using shared RDAREAs
- To back up a shared RDAREA, you must use the reference/update-impossible mode or reference-possible mode. The following specifications are not permitted:
- pdcopy -M s (updatable mode)
- pdhold -bu (updatable backup-hold)
- pdhold -buw (updatable backup-hold (WAIT mode))
- If you use the system switchover facility, place the unit containing the updatable back-end server as follows:
- Place it on a separate host from a reference-only back-end server.
- Place the target system in such a manner that the updatable back-end server does not coexist with a reference-only back-end server on the same host when system switchover occurs.
Make sure that no reference-only back-end server uses the disk volume for the shared RDAREA as the cluster software's management resources.
- No floating servers can be installed because a shared RDAREA is placed in all back-end servers.
- A shared table cannot be the replication target.
- Updatable online reorganization of shared RDAREAs cannot be executed for each server (-s option). However, if some of the back-end servers are inactive and cannot be started immediately, the following actions can be taken for each server:
- Forcibly cancel online reorganization hold (committing the database for online reorganization) only by the active back-end servers (pdorbegin -u).
- Forcibly cancel reflection processing for updatable online reorganization only by the active back-end servers (pdorend -u).
After the inactive back-end servers have started, place them in the same status as the other back-end servers.
- When you use local buffers to update a table and index in a shared RDAREA, first issue the LOCK TABLE statement. If a shared table or index is updated without issuing the LOCK TABLE statement, and the server process terminates abnormally, it may not be possible to restore the updated pages from the global buffer when rollback processing executes restore processing. If the updated pages cannot be retained, they cannot be restored; therefore, the unit terminates abnormally with abort code Phb3008. If this happens, restart HiRDB.