Configuration and Tuning

V10 and V11 Configuration Recommendations

FairCom DB V10 introduced numerous performance gains and tightened security measures. To take a advantage of the power-packed release, you will need to be sure your system is configured correctly. Other options have either been deprecated or changed in behavior.

Customers moving from prior releases should consider the following options and changes in configuring their servers.

Performance

Shared Memory on Unix Systems

V10 and later releases now support shared memory for localhost application connections. Enabling this should give a major performance boost for those applications. The following keyword enables this feature:

COMM_PROTOCOL FSHAREMM

Memory Suballocation Subsystem

There is a configuration for our memory suballocator lists. We strongly recommend testing with this option for performance comparison. Set this value to the number of CPUs available to the FairCom DB process for optimal advantage.

MEMORY_HASH <N>

• Memory Suballocator Configuration

Data Integrity

Enhanced Automatic Recovery

The RECOVER_DETAILS setting is now default. This option can be removed from previous configuration files.

• RECOVER_DETAILS Default

LOGIDX Improves Recovery

In V10, a mode called LOGIDX is now enabled by default. This potentially adds slightly more overhead than you had in prior versions. However, the payoff is great during recovery. We recommend leaving this default in place.

• LOGIDX Default

RECOVER_MEMLOG Speeds Recovery Times

We also recommend adding the RECOVER_MEMLOG option to your configuration. It can greatly speed recovery times and has no effect during normal operation.

Access Security

Encrypted User/Group Information

ADMIN_ENCRYPT YES is the default in V10 and later. AES encryption is available if ADVANCED_ENCRYPTION YES is specified in ctsrvr.cfg.

• Encrypted User/Group Information

To disable this encryption level, add ADMIN_ENCRYPT NO to your configuration file.

Guest Logons Denied

Guest logons (logons without any provided user name) are now denied by default. To enable applications that don't use FairCom DB user authentication you now need to explicitly allow those connections.

GUEST_LOGON YES

Guest Logons Denied

Compatibility

Transaction Log Writing

The COMPATIBILITY SYNC_LOG setting is now deprecated. Use COMPATIBILITY LOG_WRITETHRU (which has exactly the same behavior).

Commit Read Locks

Commit read locks prevent dirty record reads during the commit phase of a transaction.

COMPATIBILITY COMMIT_READ_LOCK is now default. You can remove this option from previous configuration files if used (introduced in V9).

Caching: TDATA_WRITETHRU vs. UNBUFFERED_IO

TDATA_WRITETHRU uses the file system cache. The file is placed into a mode that causes the write to go to file system cache and then to disk before returning; the data still resides in file system cache.

UNBUFFERED_IO completely bypasses the file system cache.

FairCom DB Server Configuration Recommendations

The following options can be defined in the FairCom DB Server configuration file ctsrvr.cfg and should be taken into consideration for all new and existing FairCom DB customers:

SKIP_MISSING_FILES

Do not operate with SKIP_MISSING_FILES enabled in the ctsrvr.cfg configuration file by default. This configuration may cause files to be inadvertently skipped during recovery, making it difficult to restore the database back to a consistent state. This keyword should only be utilized when confirmed necessary (by reviewing specific error messages in the CTSTATUS.FCS status log file), and then promptly removing it. (Commenting the keyword in the configuration file is suggested, as it is then readily available if absolutely needed.)

KEEP_LOGS

To take fullest advantage of FairCom DB’s recovery options, it is advisable to keep as many transaction logs as practical — up through the last two backups, if possible. The FairCom DB restore process can start with an existing backup and roll forward through remaining logs if available, restoring data to the latest possible time point.

FORCE_LOGIDX

FairCom has a feature that reduces the amount of time it takes for automatic recovery to complete, especially in systems with high transaction rates. By adding the keyword FORCE_LOGIDX ON to your ctsrvr.cfg file, FairCom DB will store a few additional bytes of information per index node within the FairCom DB transaction logs, which will greatly reduce the amount of time automatic recovery will take. There is no performance loss with the production system for enabling this feature and you do not need to rebuild indexes to enable this feature.

FORCE_LOGIDX supports these settings:

• ON forces all indexes to use LOGIDX entries.
• OFF forces all indexes not to use LOGIDX entries.
• NO uses existing file modes to control LOGIDX entries.

Large Page Support to Improve Large Cache Performance

Symptom

Pages being stolen by another process or the file system cache.

Diagnose

Monitor the RSS memory of the FairCom DB process (ps v PID) to see if it drops at the times of poor performance.

Solution

Set the FairCom DB SQL executable and/or the system for large page support.

64-bit Windows Filesystem Behavior

On 64-bit Windows systems, by default, the Windows file system cache can grow without limit, causing Windows to "steal" memory pages from user processes such as FairCom DB. The reported symptom is that FairCom DB sometimes becomes unexpectedly slow, in particular for accessing memory files and cached data.

Microsoft provides a utility that limits the file system cache size. The link below can be used to download this utility:

Dynamic Cache Service

Configuring 32-bit ODBC Drivers on 64-bit Windows Versions

With 64-bit versions of Windows, the previous 32-bit ODBC Driver Manager is now located in a different location, and is not used by default. To configure a 32-bit driver on these systems, use the following steps:

• Execute: %WINDIR%\syswow64\odbcad32.exe
• Create a DSN using the 32-bit version of the Administrator

See Also

• DSN-less ODBC Connections.

Relocating Transaction Logs

Transaction logs can be relocated to a different physical drive so they reside in a different directory than the data. Relocating to a different physical drive can improve performance by giving you two channels to write the data. Use these configuration keywords to relocate transaction logs:

• LOG_EVEN
• LOG_ODD
• START_EVEN
• START_ODD

In V10.3 and later, these configuration options can include an environment variable name that will be substituted with its value when the configuration file is read.

See the FairCom Server Administrator's Guide for information about these keywords.

Transaction Log Reset Procedure

There are a number of reasons to reset the transaction logs: Impending transaction limits, Database upgrades, and more.

Once you can safely shut down the system, be sure to shut it down cleanly. Follow these steps to reset the transaction logs for a FairCom server.

1. Cleanly shut down the FairCom server using one of the following methods:
   • Use ctadmn or ctstop
      
   • On Windows use the Control menu->shutdown.
   • Do NOT use force quit, Task Manager End Task, kill, and so forth.
2. Restart the FairCom server and prevent any users from connecting.
   This can be done using any of the following methods:
   • Change the port
   • Add "CONNECTIONS 0" to ctsrvr.cfg
   • Disrupt the network
   • Disable application usage
   • Disable PLUGINs in ctsrvr.cfg
3. Cleanly shut down the FairCom server a second time. This second shutdown ensures that any pending transactions in the current logs are processed
   This can be done by disabling any PLUGIN in ctsrvr.cfg and changing the port (add "CONNECTIONS 0" to ctsrvr.cfg), disrupting the network, or at the application level. This can be verified by checking that the CTSTATUS.FCS file does not contain any comments like "auto recover" or "server was not shutdown properly" since the previous startup
   You may now safely move the existing transaction logs to a backup location.
4. Move the following files if they exist, from the tranlogs folder to a backup location:

L*.FCS
S*.FCS
L*.FCT
L*.FCA
L*.FCQ

5. Move the following deferred indexing files from the data folder to a backup location.

DFRKSTATEDT.FCS
DFRKSTATEIX.FCS

1. Restart the FairCom server and it will create new transaction logs and deferred indexing files from scratch. To confirm this, look at the file names of the transaction logs (on Unix/Linux: ls L*.FCS) and you should see that the first L*.FCS file has been reset to L*00001.FCS
2. The Old logs saved in steps 4 and 5 may be discarded.

Dynamic Dump Backups

If your dynamic dump backup restore procedure uses Forward Roll (ctfdmp utility), backups taken before the transaction log reset cannot apply database changes after the log reset. New backups should be created immediately after the log reset to be usable with the new transaction logs.

Replication

Replication uses a transaction log reader to apply database changes to another database server. Typically, the log reset procedure needs to be completed on each server involved in replication. The following instructions are appropriate for simple replication configurations but may need to be modified for complex scenarios. Contact FairCom if you have any questions.

Asynchronous Replication

1. Perform the log reset procedure on the replication target server. The source server may remain active.
2. Restart the replication agent for the target server.
3. Repeat steps 1-2 for each additional replication target server.
4. Before stopping the source server, stop all application activity on the source and allow enough time for the target replica(s) to catch up. Run ./repadm -c getoldestuncommitedtran for each replication agent, it should report the "uncommitted tran count" as zero when caught up.
5. Perform the log reset procedure on the replication source server.
6. The replication agents will be unable to replicate from the source, as their stored log positions are now incorrect. To reset these positions for each replication agent, create a file named "ctreplagent.ini" in the target server working directory with the following 2 lines:

1 0
1 0

Then restart the agent, which should delete the ctreplagent.ini and reset its log read position. (Legacy ctreplagent users should instead place the ctreplagent.ini in that process's working directory).

Synchronous Replication

This assumes an initial configuration with server (A) acting in Primary role and server (B) acting as Secondary.

1. Perform the log reset procedure on the Secondary server (B).
2. After restarting (B) , wait until the Secondary server (B) has resynced with the Primary (A). This can be identified when the command "repadm -c getsyncmode" returns "y" rather than "n".
3. Failover. (B) becomes the Primary server.
4. Perform the log reset procedure on server (A) (now in Secondary role)

Deferred indexing, Fulltext indexing, and Record update callbacks

These features might use the transaction logs and DFRKSTATE*.FCS to take asynchronous actions. If this processing is lagging behind when the logs are reset, these actions will not occur for the unprocessed log interval. Before executing the log reset procedure, stop all external server activity and allow for the deferred indexing to reach the current log position. Use the following commands to check this.

Get current server log# and position:
ctstat -var -h 1 -u ADMIN -p ADMIN -s FAIRCOMS
Get current agent log# and position:
dfkctl -getstate -u ADMIN -p ADMIN -s FAIRCOMS -h 1

When the returned log numbers and positions are equal the deferred indexer should be caught up.

Maximum Number of Indexes Per Data File

Occasionally data files require a large number of indexes. Commencing with FairCom DB V10.3, the number of indexes default limit was increased from 32 to 64. Customers using the FairCom Server can use the MAX_DAT_KEY keyword to change the limit on the number of indexes per data file.

If this limit is too low, the typical error code that would be seen is error 107, IDRK_ERR "too many keys for ISAM data file."

This value affects the amount of memory that is allocated to store ISAM index state information. It can be increased without a major impact on performance unless FairCom Server is being run in an environment with very little memory (e.g., certain embedded applications).