pd_dbsync_point specification | pd_system_dbsync_point specification | |
---|---|---|
sync | commit (default) | |
sync (default) | Commits updates to all RDAREAs at a synchronization point. | Commits updates to the indicated types of RDAREAs when a COMMIT statement is issued. Commits updates to other types of RDAREAs at a synchronization point. |
commit | Commits updates to all RDAREAs when a COMMIT statement is issued. |
Comparison item | pd_dbsync_altwrite_skip operand value | |
---|---|---|
Y | N (default value) | |
Database writing method when an update buffer reference request is issued during synchronization point acquisition processing | The transaction process that issued the reference request does not handle the writing of the update buffer contents into the database (the handling is skipped). | The transaction process that issued the reference request handles the writing of the update buffer contents into the database (the handling is not skipped). |
Advantage | Because the transaction process does not handle the write processing, the performance of the referencing transaction is stable during synchronization point acquisition processing. | The amount of time required for synchronization point acquisition processing is reduced because some of the workload is distributed to the referencing transaction. |
Disadvantage | The amount of time required for synchronization point acquisition processing increases because none of the workload is distributed to the referencing transaction. | There may be adverse effects on the referencing transaction during synchronization point acquisition processing. |
Level | Explanation |
---|---|
Level 0 | No space conversion. |
Level 1 | Converts spaces in literals, embedded variables, and ? parameter data in a data manipulation SQL as follows:
|
Level 3 | The following processing is performed, in addition to the processing in Level 1:
|
pd_thdlock_sleep_func operand value | Characteristics of the function issued by HiRDB | |
---|---|---|
Process switchover rate | CPU usage | |
0 | Low | Low |
1 | High | High |
Comparison item | pd_thdlock_wakeup_lock operand value | |
---|---|---|
Y | N | |
Difference in transaction execution time | Reduces the difference. | Increases the difference. |
Time required for the completion of all transactions | Lengthens | Shortens |
Condition | Recommended value | |
---|---|---|
When a new HiRDB is used | Y | |
When HiRDB is already being used | When the execution times of all transactions must be the same during multiplexed transaction execution | Y |
When some differences in the execution times of all transactions are allowed during multiplexed transaction execution | N |
pd_thdlock_sleep_func operand value | pd_thdlock_retry_time operand value | |
---|---|---|
1 to 10000 | 10001 to 1000000 | |
0 | Each process stands by for the thread lock sleep time specified by select() or Sleep(). | |
1 | The OS determines process allocation using sched_yield() or SwitchToThread() (the pd_thdlock_retry_time operand value is ignored). | Each process stands by for the thread lock sleep time specified by select() or Sleep(). |
Item | Y specified | N specified |
---|---|---|
Processing by HiRDB | During UAP or command* execution, HiRDB checks the hold statuses of all RDAREAs that store the access target tables before locking the RDAREAs. For example, when accessing a table that is row-partitioned into RDAREAs 1 through 4, HiRDB checks the hold statuses of all these RDAREAs. | During UAP or command* execution, HiRDB first locks RDAREAs and then checks the hold statuses of the access target RDAREA. For example, suppose that a table that is row-partitioned into RDAREAs 1 through 4 is to be accessed. If the target RDAREAs are narrowed using an index and if RDAREA 1 is to be accessed, HiRDB checks the hold status of RDAREA 1 only. This mode is used in HiRDB Version 5.0 and older versions. |
When a UAP accesses an RDAREA that is on hold | Because a hold check is performed before locking the RDAREA, the fact that the RDAREA is on hold can be detected more quickly than when N is specified. | Because a hold check is performed after locking the RDAREA, the locked RDAREA may cause a timeout error (KFPA11770-E) if a UAP accesses the RDAREA that is on hold. Additionally, if the access target RDAREA is on hold because data is being loaded or because it is being reorganized, the UAP may cause a hold error (KFPA11920-E). |
When using a non-row partitioning index to narrow the access target RDAREAs | You must be careful when a table is row-partitioned but the index is not. When using a non-row partitioning index to narrow the access target RDAREAs. a hold error (KFPA11920-E) occurs, even when a non-access target RDAREA is on hold. In the example given for processing by HiRDB, the UAP causes a hold error (KFPA11920-E) if any of RDAREAs 1 through 4 is on hold. | When using a non-row partitioning index to narrow the access target RDAREAs, the UAP or command can be executed even if a non-access target RDAREA is on hold. In the example given for processing by HiRDB, the UAP can be executed even if RDAREAs 2 through 4 are on hold. |
Error cause | Output message | |
---|---|---|
pd_connect_errmsg _hide = Y | pd_connect_errmsg _hide = N (default value) | |
Invalid authorization identifier (the specified user does not exist) | KFPA19632-E | KFPA11561-E |
Invalid password (the specified password is invalid) | KFPA19632-E | KFPA11560-E |
Condition | Messages that are output | |
---|---|---|
When Y (default value) is specified | When N is specified | |
Server process is terminated forcibly for one of the following reasons:#
|
|
|
Server process is terminated forcibly for some other reason |
| |
HiRDB cannot identify the cause of the forced termination of the server process |