Tracking Change Events

Tracking change events are caused on a secondary when tracking is enabled or disabled. The SDSEventTypes category SDS_TrackingStopped or SDS_TrackingStarted global constant defines the eventType used in of the notification.

When the eventType is SDS_TrackingStopped, the userInfo parameter contains zero (0) if you disabled tracking or it contains an error code if an error caused the halting of tracking.

You can call the JadeDatabaseAdmin class sdsAuditStopTracking method if you want to specify a system event number that is returned in the userInfo parameter of your user notification method when an SDS_TrackingStopped event occurs because of a programmatic, RPS node, or SDS Administration utility action or tracking is halted because of an error, to notify subscribers that tracking has been disabled.

When the sdsAuditStopTracking method is invoked on the primary, it causes a Stop Tracking audit record to be written to the current journal. When this record is replayed on an RPS node or on an SDS secondary, tracking halts at that point in the audit trail.

Tracking change events are not notified on the primary. On a primary, the userInfo parameter contains the name of the secondary whose transfer has halted. The application can then use that name to obtain a secondary proxy and therefore the error state. On a secondary, the userInfo parameter contains an error code that signifies the reason why journal transfer halted.

The scope parameter of the JadeDatabaseAdmin class sdsAuditStopTracking method determines the type of secondary databases that actions the stop tracking command, and is represented by the SDSStopTrackingCodes category global constants listed in the following table.

Global Constant	Integer Value	Description
SDS_AuditStopTrackingAll	1	Stops tracking on all JADE and RPS secondary databases
SDS_AuditStopTrackingNative	2	Stops tracking on JADE native secondary databases
SDS_AuditStopTrackingRdb	3	Stops tracking on RPS secondary databases

The reason parameter of the JadeDatabaseAdmin class getReasonTrackingStoppedString and sdsAuditStopTracking methods determine the reason tracking was disabled, and is represented by the SDSStopTrackingCodes category global constants listed in the following table. This value is audited and passed to subscribers to the SDS_TrackingStopped system event in the userInfo parameter of the associated userNotify callback method.

Global Constant	Integer Value
SDS_ReasonAdminAudited	1
SDS_ReasonAdminDirect	2
SDS_ReasonAutoUpgradeMismatch	6
SDS_ReasonDeltaModeEntered	12
SDS_ReasonEnablingDbCrypt	13
SDS_ReasonErrorHalt	8
SDS_ReasonRestart	10
SDS_ReasonRpsAdminHalt	4
SDS_ReasonRpsReorgHalt	9
SDS_ReasonRpsRestart	11
SDS_ReasonRpsSnapshot	3
SDS_ReasonTakeover	7
SDS_ReasonTransition	5

The SDS_ReasonTakeover value indicates that tracking stopped during a takeover operation and the SDS_ReasonRpsReorgHalt value indicates that tracking stopped at transition. The SDS_ReasonErrorHalt value indicates that tracking halted due to an error condition (the error code is saved in the SDSSecondary or SDSSecondaryProxy dynamic lastErrorCode attribute).

The SDS_ReasonRestart value indicates that tracking stopped and then restarted when the connection with the primary was lost. The SDS_ReasonRpsRestart value indicates that a condition arose in processing on a primary causing JOM callbackID=2 audit records to be audited for replay purposes, triggering the shut down of applications running from affected schemas when it is replayed on a native or RPS secondary. On an RPS secondary, there is an additional requirement to restart the Datapump application to allow the kernel to close user class agents it may have in use as a result of the replication process. Tracking and the Datapump application are then restarted.

The journal and offset output parameters of the sdsAuditStopTracking method contain the journal number and byte offset within the journal of the Stop Tracking audit record. These two values together comprise a Log Sequence Number (LSN). When tracking is restarted on the secondary or RPS node, it resumes at the next audit record.

The RPSTransitionHaltCode category provides global constants that enable you to determine whether the Relational Population Service (RPS) table alter script will be loaded automatically or whether manual action is required from the RDB administrator when a schema instantiation is replayed by an RPS node and the Datapump application and database tracking are halted to achieve a schema transition.

When the event RPS_SchemaTransition (event type 220) is caused on the system instance, the userInfo parameter passed to the userNotification callback method contains one of the global constants listed in the following table.

Global Constant	Integer Value	Description
RPS_HaltNoScript	0	Changes do not affect RDB, so no script was generated
RPS_HaltAutoScript	1	An automatic initiate alter script was generated (will be automatically loaded by the Datapump application if configured to automatically restart)
RPS_HaltManualScript	2	A manual alter script was generated (requires administration user intervention to apply changes to RDB before tracking can be resumed)
RPS_HaltMappingDeleted	3	The RPS mapping was deleted on the primary database, rendering the RPS node and associated RDB defunct

The RPS_SchemaTransition event is represented by a global constant in the SDSEventTypes category.