Considerations for developing applications with Log Reader supported table types

Transient and temporary tables are not logged and thus data in them is not returned through the Log Reader.

All events for one transaction are returned at once. Each transaction is returned in full at the time of commit. Log Reader returns full committed transactions in the order they are committed to the log. Overlapping transactions are returned transaction by transaction.

Operations in the trigger action part are logged as normal user operations. Write operations in triggers are logged when they are executed: before-triggers are logged before user data operation, and after-triggers are logged after user data operation.

Operations resulted from cascading referential actions are logged as normal user operations. Cascading operations are logged after the actual user data operation.

For DDL operations, the Log Reader will return a special DBE_LOGREADER_LOG_REC_DDL record that contains the original SQL statement.

When a log read is started from SYS_LOG, the read goes first into catchup mode. The catchup mode means that the log read start position is searched from the log and the read is then started from that position. When log read reaches the end of the current log, it starts to read live data. In live mode transactions are returned as they are executed.

When several Log Readers are used, each Log Reader has its own data mode.

In live data mode the cursor returns every second even if there is no data available. In that case, the FLAGS field in the SYS_LOG table is zero.

Primary key is not mandatory for the tables. System generated internal and hidden primary key value is not returned through the Log Reader.

When designing your database, you must decide how rows are identified if primary key is not defined.

High Availability (HotStandby) is supported so that the log file contents and log address are compatible between Primary and Secondary servers. If the log is read from Primary server and there is a failover, a new read from SYS_LOG can be started using the last LOGADDR received from the old Primary server.

The log can be read also from the Secondary server. This can useful, for example, for load balancing reasons.

If the server can generate log records faster than the client can read, throttling can occur. This means that user transactions writing to the server are slowed down to make sure the Log Readers are not too much behind the live data. The LogReader.MaxSpace parameter can be used to control the buffering after which throttling can occur.

Applications that start a read but then stop reading can also cause the server to stop.

If the application using the Log Reader is stopped or terminated for longer time, a the log maximum size may be reached. In such a case, no error message is produced. Also, the position stored by the application for catchup is not available any more and the effort to catchup fails.

Administrator rights are needed to access the SYS_LOG table, to add tables to a partition or to remove tables from a partition.

The log reading can be stopped at any time. No data is lost even of some undelivered data are left in the log.

The log reading may be resumed without any loss of information if the last read position is known. By using the current log position, the application will be able to continue reading the log, without any loss of data, upon the next SYS_LOG query. If the SYS_LOG table is accessed without specifying the log position, the reading starts from the live data.

The Log Reader can be stopped in the solidDB^® server with the ADMIN COMMAND 'LOGREADER STOP’ command.