User Guide > Push-Based Incremental Caching > Push-Based Incremental Caching Configuration Parameters
 
Push-Based Incremental Caching Configuration Parameters
The following is an alphabetical list and description of the TDV Change Management Service configuration parameters on the Central Event Server. These parameters are visible with an active CSCMS license after CMS has been installed. All of them appear in the Configuration window (select Administration > Configuration from the Studio menu bar) under Change Management Service. In two cases, Logging Options and Tibco, parameters are described in groups.
Parameter/Group
Description
Administration
For a description, see under parameter group Logging Options.
Attempt Count
Under Central Function > Fault Tolerance. The number of times CMS attempts connection recovery after a failure. With the default setting of “0” CMS attempts connection recovery with data sources, EMS, and other active cluster members until all connections are restored.
Attempt Delay
Under Central Function > Fault Tolerance. This value denotes the delay, in milliseconds, between attempts to recover from a connection failure. The default value is 1000.
Caching
For a description, see under parameter group Logging Options.
Change Inference
Change Inference Messages
TDV-Managed Destinations
Under Central Function > Messaging. Typically, TDV is set to manage output messaging queue and topic destinations. TDV creates queues and topics according to the needs of the client subscriptions, in transit events, and transient cache buffers. If TDV-Managed Destinations is set to false, all of the Messaging > Internal EMS properties must be set.
Connection Attempt Count
For a description, see under parameter group Tibco.
Connection Attempt Delay
Connection Attempt Timeout
Data Sources
For a description, see under parameter group Logging Options.
Default Connector
Under Central Function > Messaging > Input EMS. The name of the EMS topic connection factory for receiving change notification messages from Oracle GoldenGate through TIBCO EMS. Data source specific connectors and topics can be defined to override the default connector. The value of the Input EMS Default Connector server property is the name of the JMS via JNDI Connector. JMS connector attributes like initial context factory and JNDI provider URL are defined on the CONNECTOR MANAGEMENT page of the Manager (Web) interface.
Default Connector
Under Central Function > Messaging > Output EMS. The name of the EMS topic connection factory to be used for creating topics to send change notification messages from TDV to subscribed clients. Individual topics are created dynamically based on client subscription requests. Data source specific EMS Connectors and topics can be defined to override the default connector. The value of the Output EMS Default Connector is the name of the JMS via JNDI Connector.
Error Handling Procedure
The name of the procedure to call in case an invalid message has been received. The procedure must accept three arguments: a string value for the error, a string value for the offending message, and a timestamp for the time at which the error was reported.
Expiration Period
The number of hours a client subscription remains valid without renewal to monitor a view for changes. Client subscription renewals before the expiration period has elapsed result in extensions that last for another expiration period. The expiration period begins when the client subscription is created and it is reported to the client subscriber.
In Transit Event Queue
Under Central Function > Messaging > Internal EMS. If TDV-Managed Destinations is set to false, this parameter must be set to a valid queue created to host in-transit change events. The In Transit Event Queue is used to ensure fault tolerance so that if a server instance crashes, event processing can resume, starting from the last successfully processed message.
Include Column Names
Under Central Function > Messaging > Message Format. The following example shows an update message (“U”) with a format that includes both the rank (“r”) and the column names (“n”):
<U a="true">
<k r="0" n="Column Name 0">value0</k>
<k r="1" n="Column Name 1">value1</k>
<c r="2" n="Column Name 2">
<n>newvalue2</n>
<o>oldvalue2</o>
</c>
<c r="3" n="Column Name 3">
<n>newvalue3</n>
<o>oldvalue3</o>
</c>
<c r="4" n="Column Name 4">
<n>newvalue4</n>
</c>
<c r="5" n="Column Name 5">
<n>newvalue5</n>
</c>
</U>
Include non-Key Deleted Values
Under Central Function > Messaging > Message Format. Change notification messages always include a primary key that might have one or many columns to ensure a unique key on which create, update, and delete operations were detected. For Delete operations, the message setting can be set to include only key identifying values, or all values, of the row that has been deleted.
If set to true, extraneous column information is included in the change notification message, as in the following example where a delete operation, <D>, includes the key columns (“k”), and non-key values {value3, value4, xsi:nil=”true”}:
<ops>
<D>
<k r=“0” n=“Column Name 0”>value1</k>
<k r=“1” n=“Column Name 1”>value2</k>
<c r=“2” n=“Column Name 2”>value3</c>
<c r=“3” n=“Column Name 3”>value4</c>
<c r=“4” n=“Column Name 4” xsi:nil=“true”></c>
</D>
</ops>
If set to false, the “c” columns would not appear in the message.
Include non-Updated Values
Under Central Function > Messaging > Message Format. When set to false, change notification messages exclude values that are not changed since the last checkpoint of the table being monitored.
For example:
<U a="true">
<k r="0" n="Column Name 0">value0</k>
<k r="1" n="Column Name 1">value1</k>
<c r="2" n="Column Name 2">
<n>newvalue2</n>
<o>oldvalue2</o>
</c>
<c r="3" n="Column Name 3">
<n>newvalue3</n>
<o>oldvalue3</o>
</c>
</U>
Include Old Updated Values
Under Central Function > Messaging > Message Format. If set to true, change notification messages include the old values that are being replaced.
For example, this message highlights the old values, (<o> </o>), that would be omitted if the property were set to false.
<U a="true">
<k r="0" n="Column Name 0">value0</k>
<k r="1" n="Column Name 1">value1</k>
<c r="2" n="Column Name 2">
<n>newvalue2</n>
<o>oldvalue2</o>
</c>
<c r="3" n="Column Name 3">
<n>newvalue3</n>
<o>oldvalue3</o>
</c>
</U>
Logging Options
Parameter group. Typically, logging options are set to false. Log entries and events can be found in the TDV events log (cs_server_events.log) and/or server log (cs_server.log) files present in the server <TDV_install_dir>/logs directory. Each of the following logging options can be turned on (true) or off (false):
Administration—CMS installation or uninstallation, CMS start or stop.
Caching—Logging for incrementally maintained caching of views.
Change Inference—This setting logs messages received through connected EMS topics. The Input EMS Default Connector and change messages are passed from CDC when triggered by changes to watched data source tables. This setting does not show change data in the logs.
Change Inference Messages—This setting logs more detailed messages (including data changes) received through connected EMS topics. The messages logged by this setting can help verify whether change data capture messaging is arriving to the EMS topics and connectors currently listening for change messaging.
Data Sources—This setting logs activities on the push-based incremental caching data sources. Metadata Inference—Information captured by this log setting shows dependency analysis messages.
Subscriptions—Subscription requests, unsubscribe, and renew subscription requests are logged when this setting is true.
Message Format
All of the messaging parameters can be turned on (true) or off (false). The parameter settings affect the content of the change notification message format. Message formatting is a global setting that affects all change notification messaging received by subscribed clients.
Message Handling
Correct change notification is dependent on correct change messaging sent from the monitored data source tables. Messaging ensures that incrementally maintained caches and subscribed users have notification of changes in the source data. If messages from the monitored data sources are malformed or lacking in content, the Change Management Service might treat the message as a systemic error requiring manual assessment and reconfiguration, generate logging errors (in cs_server.log), and possibly abort. If messaging errors occur, check the CMS server log file, and check the Oracle GoldenGate *.prm parameter file for configuration.
PROCEDURE OnError(IN ex VARCHAR(2147483647), IN msg VARCHAR(2147483647), IN t TIMESTAMP)
BEGIN
-- Add your code here
CALL /lib/debug/Log(concat('M5 Test[GG erroneous message]---Exception: ',ex));
CALL /lib/debug/Log(concat('M5 Test[GG erroneous message]---Received message: ',msg));
CALL /lib/debug/Log(CAST(concat('M5 Test[GG erroneous message]---Time: ',t) AS VARCHAR(255)));
END
Metadata Inference
For a description, see under parameter group Logging Options.
On Error Procedure
Sets a procedure to execute when a messaging error occurs. Specify the full path name of the TDV Server procedure to call if an invalid message is encountered. The procedure specified must accept three input arguments: a string value for the error, a string value for the offending message, and a timestamp for the time at which the error is reported.
Persistence Store
The TDV resource path name that points to a relational data source container that should be used to host a subscription store table, which is created and maintained by CMS. On application of a valid TDV persistence store location, CMS creates the cis_cms_appl_subs table. That table records client invocations of cms_client_subscribe with data such as the Subscription ID, Application ID, an encoded expiration, the full path of the subscribed view, and subscribed columns if different from the full view.
Because the persistence store, cis_cms_appl_subs table, should not be shared between TDV nodes, the Persistence Store target setting should be changed after synchronization by backup server import.
Queue Connector
Under Central Function > Messaging > Internal EMS. The name of the JMS Connector to be used by CMS to create an in-transit event queue. The in-transit event queue is used to maintain in-transit change events in a fault-tolerant manner, while they are being processed by the Central Event server. The value of the Internal EMS Queue Connector server property is the name of the JMS via JNDI Connector. A new or a changed Queue Connector setting requires a CMS restart to initialize the in-transit queue.
Reconnection Attempt Count
For a description, see under parameter group Tibco.
Reconnection Attempt Delay
For a description, see under parameter group Tibco.
Reconnection Attempt Timeout
For a description, see under parameter group Tibco.
Security Domain
Under Central Function > Messaging > Output EMS. The LDAP domain value that can be used to restrict topic connection to permitted groups and users for the subscribed view.
Started
Under Central Function. This setting is an indicator that shows whether CMS is started or not. It should not be modified because the value is not a switch. It is an indicator provided to show CMS status. CMS can be started and stopped with the procedures cms_admin_start and cms_admin_stop.
Stop on Any Error
Under Central Function > Fault Tolerance > Message Handling. CMS aborts on receiving source change messages with an invalid message structure. This flag specifies whether CMS aborts if any other types of errors are detected in a source change message notification. Invalid GG configuration is a systemic error.
Partial compliance with the expected change notification message schema is a more serious error than inadvertent messages. Some data type mismatches are handled, but a mismatch invalidates all derived incremental caches and sends a notification to all subscribed clients (<ops/>, set with a message property of aborted=”true”) to signify a break in the monitored data.
When Stop on Any Error is set to false, most messaging errors are still serious, and such errors invalidate all incrementally maintained caches, subscription failure messages, and a purposeful stop of CMS. If a message significantly deviates from the expected CMS schema and is inserted into a monitored input topic or queue, that message is ignored.
Subscriptions
For a description, see under parameter group Logging Options.
Tibco
Parameter group. These optional settings override the TIBCO EMS connection factory settings, so that CMS can manage timing and number of connection attempts. The switch from a primary to a backup EMS can initiate a large number of connection and reconnection attempts that can exceed the number allowed.
Connection Attempt Count—Number of attempts made to connect to the JMS server.
Connection Attempt Delay—Milliseconds to wait before the next connection is made.
Connection Attempt Timeout—Milliseconds the connection factory waits before declaring a failure if the attempt is unsuccessful.
Reconnection Attempt Count—Number of attempts to make to reconnect to the JMS server. (TIBCO has separate connect and reconnect attempt parameters.)
Reconnection Attempt Delay—Milliseconds to wait before the next connection is made.
Reconnection Attempt Timeout—Milliseconds the connection factory waits before declaring a failure.
For hard connection failures, problems can be reported earlier than these JMS vendor settings indicate.
Topic Connector
Under Central Function > Messaging > Internal EMS. If TDV-Managed Destinations is set to false, this parameter must be set to a valid topic connector for TDV to manage transient cache buffers, which might be needed while an incrementally maintained data cache is being initialized.
Transient Cache Buffering Topic
Under Central Function > Messaging > Internal EMS. If TDV-Managed Destinations is set to false, this parameter must be set to a valid topic so that a transient cache buffer can be set up to provide a temporary topic to handle change messages during cache initialization. The Central Event Server uses this topic to handle change notifications that occur while the cache table is being created and loaded for the first time.