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 server process that will execute the transaction that issues the reference request does not handle writing of the update buffer contents into the database. (The handling is skipped.) | The server process that will execute the transaction that issues the reference request handles writing of the update buffer contents into the database. (The handling is not skipped.) |
Advantage | Because the server process that will execute the transaction 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 might be adverse effects on the referencing transaction during synchronization point acquisition processing. |
pd_thdlock_sleep_func operand value | pd_thdlock_retry_time operand value | |
---|---|---|
1 to 10000 | 10001 to 1000000 | |
0 | The processes go on standby for only the amount of sleep time set for the inter-thread lock specified with select() or Sleep(). | |
1 | The OS determines process allocation using sched_yield() or SwitchToThread() (the pd_thdlock_retry_time operand value is ignored)# | The processes go on standby for only the amount of sleep time set for the thread lock specified with select() or Sleep(). |
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 status of all RDAREAs that might be accessed before locking the RDAREAs. For example, when accessing a table that is row-partitioned into RDAREAs 1 through 4, HiRDB checks the hold status of all four RDAREAs. However, when conditions are specified by key range partitioning or FIX hash partitioning, and the RDAREAs that might be accessed by the UAP are narrowed, no error results even when RDAREAs that cannot be accessed are on hold. | During UAP or command# execution, HiRDB first locks RDAREAs and then checks the hold status of all RDAREAs that might be accessed. For example, assume 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 earlier. |
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 might 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 might 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 |
Value of pd_rpc_bind_loopback_address operand | Port numbers and programs that will be used by HiRDB and need to be added to the Windows Firewall exception list |
---|---|
Y | None |
N | All port numbers and programs that will be used by HiRDB |
S |
|
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 |