14.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. The following figure provides an overview of a shared RDAREA.
Only a HiRDB/Parallel Server can define shared RDAREAs.
Figure 14-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) Executing utilities and operation commands on a shared RDAREA
- (7) 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. 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 14-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 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 12.18.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) 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.
(7) Notes about using shared RDAREAs
- 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.
- When you use local buffers to update a table and index in a shared RDAREA, first issue the LOCK TABLE statement. If you update without issuing a LOCK TABLE statement, updated pages that are recovered using the global buffer might not always be retained when the server process terminates abnormally and the transaction recovery process runs. 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.