Knowledgebase

Transaction Log Reset Procedure

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

NOTE: Resetting the transaction logs may impact several subsystems that require transaction log continuity. Special consideration is needed if you use dynamic dump backups, replication, deferred Indexing, full-text indexing, or record update callbacks. Review those sections for additional information before executing the log reset procedure.

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

   NOTE: Check the "LOG_EVEN" and "LOG_ODD" lines in ctsrvr.cfg to verify the server transaction log folder location..

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

   DFRKSTATEDT.FCS

   DFRKSTATEIX.FCS

   NOTE: Check the "LOCAL_DIRECTORY" line in ctsrvr.cfg to verify the server working directory location .

6. 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
7. 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.