The GETUPDATEBEFORES parameter indicates that the before images of updated columns are included in the records that are processed by Oracle GoldenGate.
The BROFF value turns off Bounded Recovery for the run and for recovery. The BR BROFF parameter controls the Bounded Recovery (BR) feature. The EXTRAIL parameter identifies the trail as dirdat/cs. The recoveryOptions OverwriteMode line indicates that the extract overwrites the existing transaction data in the trail after the last write-checkpoint position, instead of appending the new data. The user that the Coherence CacheStore is logged in as is csdemo. For example, the following command instructs GoldenGate extract process to ignore changes to the database tables made by the Coherence CacheStore user logged in as csdemo.Įxample 7-7 illustrates a sample extract. The TranLogOptions excludeUSER command can be used on the command line or in a ggsci script. This avoids GoldenGate processing any changes made to the database by Coherence that are already in the cache. The ADD EXTRACT command automatically uses the cs-cap.prm file as the source of parameters, so a PARAMS dirprm/cs-cap.prm, statement is not necessary.Ĭonfigure GoldenGate to ignore changes made by the user that the Coherence CacheStores are logged in as. The start command starts the cs-cap.ggsci script. A trail is added at dirdat/cs from the extract cs-cap file. An extract named cs-cap is created using parameters from the dirprm/cs-cap.prm file.
Note that the rm -f command is platform-specific. The SHELL command deletes all trail files in the dirdat directory to ensure that if the extract is being recreated, there will be no old trail files. The ADD TRANDATA command instructs the extract that tables named csdemo* should be monitored for changes. It stops and deletes any running extract named cs-cap. The script starts the manager and logs into the database. For example, to monitor changes to tables in the csdemo schema, use the following command:Įxample 7-6 illustrates a sample ggsci script named cs-cap.ggsci. The ADD TRANDATA command can be used on the command line or as part of a ggsci script. Indicate the table that you want to monitor for changes by using the ADD TRANDATA command. The application client detects the change in cache. GoldenGate detects the database change which is then propagated to the Coherence cache by HotCache. As part of its operation, assume that the application performs repeated queries on the cache.Ī third-party application performs a direct database update. If changes occur during cache warming, then they will be applied to the cache once HotCache is started so no changes are lost. Start HotCache so that it can propagate changes in the trail file into the cache. Start the Coherence cache server and warm the cache, if required. These changes will be placed into a "trail file".
GoldenGate monitors the transaction log for changes of interest. Start GoldenGate-see "Starting the Application" in Administering Oracle GoldenGate Adapters for details. The following scenario describes how HotCache could be used to work with the database and with applications that use Coherence caches. The configuration can be captured in XML exclusively or in XML with annotations.
Standard JPA is used to capture the mappings from database data to Java objects. HotCache can be added to any Coherence application. Low latency is assured because the data is pushed when the change occurs in the database. HotCache employs an efficient push model which processes only stale data. HotCache solves this problem by monitoring the database and pushing any changes into the Coherence cache. Third-party updates to the database can cause Coherence applications to work with data which could be stale and out-of-date.
0 kommentar(er)
