OCI GoldenGate in Practice — Volume I, Part 2 of 2: Building and Proving the Replication Pipeline

From runtime DB Connections and TRANDATA to Integrated Extract, Parallel Replicat, DML validation, native statistics, and cost control.

This article completes Volume I of the three-volume OCI GoldenGate in Practice field series. Volume I documents a complete, field-tested Autonomous Database replication PoC and is published in two parts because the evidence and operational detail are too extensive for a single Medium post.

Volume I, Part 1 established and validated the secure foundation: a private deployment, OCI IAM access, the GGADMIN database account, an External KMS-backed Vault secret, runtime secret access through a dynamic group, an assigned Autonomous Database connection, and a successful network-level plus application-level connection test.

This second part starts exactly where Part 1 ended: inside the OCI GoldenGate Deployment Console. It activates the runtime database session, creates the checkpoint table, enables TRANDATA, configures the Integrated Extract and Parallel Nonintegrated Replicat, starts the pipeline, executes the INSERT/UPDATE/DELETE tests, and closes with native product evidence and cost-management guidance.

The wider series will then continue with Volume II, provisioning and preparing a DB system in Oracle Base Database Service and validating replication from Autonomous Database to that co-managed target, and Volume III, focused on security, observability, and operational resilience: OCI IAM, the four GoldenGate deployment roles, OCI Logging, OCI Audit, backups, diagnostics, private connectivity, monitoring, recovery, and least privilege.

All names, addresses, OCIDs and environment-specific identifiers have been genericised. Figure numbering continues from Part 1. Figures 33–51 are sanitised screenshots from the PoC; sensitive values have been redacted.

Figure numbering continues from Part 1: Figures 33–51 are sanitised screenshots from the PoC, with sensitive values redacted. .

Read Volume I, Part 1 — Secure Foundations for an Autonomous Database PoC

Operational handoff — scope and evidence model

Volume I, Part 1 ended after the OCI Cloud Console had proved that the assigned Autonomous Database connection was reachable and usable from the private OCI GoldenGate deployment. Part 2 deliberately changes viewpoint: the Cloud Console gives way to the Deployment Console. The work now takes place inside the Deployment Console, where a synchronised connection becomes an active database session and where the service tables, Extract, trail, and Replicat are created. · Source: Explore the OCI GoldenGate deployment console

What this part proves

This part proves a narrowly defined but complete change-data-capture path: committed INSERT, UPDATE, and DELETE operations on GGTEST.T1 are captured by Integrated Extract EXTT1, written to local trail ea, read by Parallel Replicat REPT2 in nonintegrated mode, and applied to GGTEST.T2. The proof combines configuration evidence, runtime state, DML verification, Replicat counters, and the visible process report. · Source: OCI GoldenGate overview · About Parallel Replicat

What this part does not claim

The PoC does not constitute a throughput benchmark, a failover test, a zero-data-loss certification, or a production-readiness assessment. It does not measure end-to-end lag with a heartbeat table, and it does not perform an initial load of rows that existed before capture began. The observed ~0.1 s value is the Extract capture lag shown by the console, not a measured source-to-target service-level objective. · Source: Monitor performance using the Deployment Console · Manage heartbeat tables

Evidence hierarchy used in this article

The evidence is read in layers. A successful Cloud Console connection test proves reachability and authentication from the assigned deployment. The Connected runtime state proves that the synchronised credential can establish a database session inside the deployment. Running Extract and Replicat states prove process activation. SQL verification proves data-state convergence for the tested row. Finally, Replicat Statistics provide native product counters that match the three committed DML transactions. No single screenshot is treated as sufficient on its own. · Source: Troubleshoot using the OCI GoldenGate Deployment Console · Monitor performance using the Deployment Console

Validated prerequisites inherited from Part 1

Before entering the runtime console, Volume I, Part 1 had already validated the following prerequisites:

• the private OCI GoldenGate deployment was active and accessible through OCI IAM;
• GGADMIN was unlocked and aligned with the password held in the Vault secret;
• the External KMS-backed secret was Active and readable by the deployment resource principal;
• the Autonomous Database connection was created and assigned to the deployment;
• Test connection passed both the network-level and application-level checks from the assigned deployment.

The next step is therefore not another test from the Cloud Console: it is the operational use of the synchronised connection inside the Deployment Console.

Oracle references

• Explore the OCI GoldenGate deployment console
• Monitor performance using the Deployment Console
• Troubleshoot using the OCI GoldenGate Deployment Console

12 · Deployment Console — DB Connections and service tables

The Test connection has validated network and authentication from the deployment. The Connected state in the Deployment Console is a complementary operational verification: it confirms that the connection synchronised into the runtime is available for GoldenGate operations, and it unlocks the operations that prepare replication — Checkpoint, TRANDATA, Heartbeat. · Source: Connect to Oracle Autonomous Database · Explore the deployment console

Figure 33 — Deployment Console → DB Connections: the connection with the full string (protocol=tcps, port=1522, service_name …atpdemo_low, TCPS/mTLS wallet, SSL_SERVER_DN_MATCH=TRUE).

Reading Figure 33. The connection appears in the deployment console with the alias conn-atp-ggadmin and UserID ggadmin. This is the view internal to the deployment's runtime, distinct from the OCI management console.

The connection string reveals a TCPS/mTLS connection: protocol=tcps, port=1522, a service_name ending in atpdemo_low, and the automatically managed wallet. It is the typical profile of an Autonomous target.

The SSL_SERVER_DN_MATCH=TRUE parameter enforces verification of the server certificate's Distinguished Name: the client checks that the certificate presented by the database matches the expected one, preventing man-in-the-middle attacks. It is a channel-security guarantee.

The _low service in the observed connect descriptor is the consumer group selected for this PoC. Autonomous Database exposes multiple services with different concurrency and priority characteristics; the screenshot proves which service the connection used, but it should not be read as a universal recommendation for every GoldenGate workload. Service selection must be validated against workload volume, concurrency, and operational objectives. · Source: Predefined Database Service Names for Autonomous AI Database

This string, retrieved automatically by OCI when the connection was created, confirms that all the secure-connectivity parameters towards the ATP-S are correct: port, protocol, wallet and server-certificate verification.

Figure 34 — Console note: to manage Checkpoint, Transaction Information and Heartbeat, you must first Connect.

Reading Figure 34. The console points out that, in order to manage the service tables — Checkpoint, Transaction Information (TRANDATA) and Heartbeat — you must first connect to the database using the dedicated icon. This is the gesture that activates the connection at runtime.

This note introduces the three fundamental operations that will enable replication. Before they can be used, the connection must move from the “present” state (configured) to the “active” state (established at runtime), through the Connect action.

Connect is the action that makes the deployment’s runtime actually establish the session with the database, using the connection’s credential and wallet. Only after Connect do the service-table operations become available.

This separation between a configured connection and an active connection is consistent with the deployment model: configuration is persistent, but the runtime session must be established explicitly whenever database work is needed.

The next screen shows the result of Connect: the Connected state and the availability of the service tables, starting with the Checkpoint.

Figure 35 — Connection established (Connected) towards ATPDEMO; the Checkpoint section is available (still “No data to display”: to be created).

Reading Figure 35. The Connected state towards ATPDEMO operationally confirms that the connection synchronised into the runtime is available for GoldenGate operations. It is complementary to the Test connection of the previous chapter: there, network and authentication from the deployment; here, the actual use of the session for the service-table operations.

The menu now exposes the three key operations. The Checkpoint table is where the Replicat will record the point up to which it has applied changes, so it can safely resume after a stop or a crash; in the figure it is still empty (“No data to display”) because it has yet to be created.

Transaction Information (TRANDATA) enables table-level supplemental logging on the source objects, recording in the redo stream the key columns needed to resolve UPDATE and DELETE on the target. It will be the first operational step of the replication phase.

The Heartbeat table is a diagnostic table which, through timestamps that traverse the whole pipeline (Extract → trail → Replicat), measures end-to-end lag per stage. It is the foundation of performance monitoring in production.

The Connected state validates at runtime the whole configuration built so far — the secret read from the external Vault, the private network, mTLS authentication — and clears the way for creating the service tables and the processes. It is the starting line of the replication phase described in the following chapters.

The checkpoint table is created from this menu with a precise procedure, reported below exactly as executed in the PoC. The table is created in the target’s GGADMIN schema and will later be selected in the Replicat wizard. · Source: Connect to Oracle Autonomous Database · Add a Replicat for Autonomous AI Database

-- Deployment Console → DB Connections → connection → Checkpoint menu
Checkpoint  →  +  (Add Checkpoint)
  Checkpoint Table:  GGADMIN.GGCHECKPOINT
  →  Submit
-- the table appears in the list; it will be selected in step 2 of the Replicat wizard

ORACLE NOTE — connections must be created and modified through the OCI control plane — the Oracle Cloud Console, the OCI CLI, the SDKs and REST API, or Terraform and Resource Manager, which expose the connection as a managed OCI resource. What must never be done is creating or editing them from the Credentials screen of the deployment console: the control plane synchronises credentials into the deployment automatically, and a manual change on the deployment side would be overwritten or leave the two out of alignment.

KEY POINT — The Connected state validates the entire configuration at runtime (secret from the external Vault, network, mTLS authentication) and clears the way for creating the service tables and the Extract/Replicat processes.

12.1 Oracle references

• Connect to Oracle Autonomous Database
• Explore the deployment console
• GoldenGate connectivity
• Enabling Table-level Supplemental Logging
• ADD SCHEMATRANDATA

13 · Supplemental logging (TRANDATA)

GoldenGate captures changes from the redo logs. For UPDATE and DELETE statements to be reconstructable and re-applicable on the target, the source database must record a minimum set of identifying columns in the redo stream. The documentation prescribes enabling supplemental logging on the source for unidirectional replication; in our test, therefore, only on T1. · Source: Enabling Table-level Supplemental Logging · Add an Extract for Oracle AI Database

Figure 36 — “Add Table Trandata” panel: Table Name GGTEST.T1, Scheduling Columns enabled, Prepare CSN Mode = nowait, Column List empty.

Reading Figure 36. The panel asks for the object name and a few logging options. The Table Name field contains GGTEST.T1 — the schema followed by the table name: logging is enabled on the single source table of the test.

With Scheduling Columns enabled, GoldenGate requests supplemental logging for the columns it uses to identify rows and preserve dependency-aware scheduling. In this PoC, the decisive condition is that GGTEST.T1 has the primary key ID, which the subsequent verification screen detects explicitly. The option therefore supports correct UPDATE and DELETE identification without requiring ALLCOLS. · Source: ADD TRANDATA

The Column List field stays empty: its sole purpose is to log non-key columns (the COLS option, useful for filters or KEYCOLS). Replicating only ID and NAME, with ID as the key, no additional columns need logging.

The Prepare CSN Mode is left at nowait, as observed in the console. PREPARECSN is primarily relevant when source objects must be prepared for instantiation metadata used with an initial-load workflow. This PoC does not perform an initial load, so the field is recorded for reproducibility but is not presented as a functional prerequisite of the three DML tests. · Source: ADD TRANDATA · Automatic per-table instantiation

These choices configure TRANDATA for the bounded test without enabling ALLCOLS or adding a custom COLS list. GoldenGate logs the primary key unconditionally and, where present, the unique-key and foreign-key scheduling columns conditionally; Figure 37 confirms that ID was detected as the key for GGTEST.T1.

Figure 37 — TRANDATA verification: the search confirms the GGTEST.T1 row with Scheduling Columns enabled and the detected key “ID”.

Reading Figure 37. The previous screen does not refresh automatically after Submit; to confirm the outcome you use the search field. It is a console behaviour worth knowing, so as not to conclude — wrongly — that the operation failed.

Searching for the table, the GGTEST.T1 row appears with the Supplemental Logging Options active and, above all, with the detected key "ID" in the corresponding column. This is the explicit confirmation of success.

The detection of the “ID” key is the most important element: it proves that GoldenGate has correctly identified the table’s primary key. It is precisely thanks to this key that, on the target, the Replicat will know which row to update or delete.

Without a detected key, UPDATE and DELETE on the target would be problematic: GoldenGate could not uniquely identify the row to modify. The presence of the “ID” key guarantees that modification operations apply correctly.

This verification closes the source preparation: table-level supplemental logging is active on T1, with the necessary key recorded. The database is now ready to supply the Extract with all the change data it needs.

ORACLE NOTE — Oracle recommends, where possible, ADD SCHEMATRANDATA (schema level) over ADD TRANDATA (table level): schema-level logging keeps replication continuous even for objects created later, via wildcards, and automatically reflects key changes. For a targeted test on a single, static table, the Table level is adequate.

13.1 Oracle references

• Enabling Table-level Supplemental Logging
• ADD SCHEMATRANDATA
• Add an Extract for Oracle AI Database
• Enable TRANDATA / SCHEMATRANDATA
• Prepare Oracle Database

14 · Creating the Extract (EXTT1)

The Extract captures changes from the source and writes them into a trail file. It is created from the Home page (Extracts → Create) through a four-step wizard. An Integrated Extract is adopted — the recommended type for Oracle databases, being integrated with the logmining server. · Source: Add an Extract for Oracle AI Database · Add Extract (eeske) · Prepare Oracle Database

14.1 Step 1 — Extract Information

Figure 38 — Step 1: Extract Type = Integrated Extract, Process Name = EXTT1.

Reading Figure 38. The first step defines the process’s identity. The selected type is Integrated Extract: it is integrated with the database’s logmining server, which supplies it with change records reliably and in order. It is the recommended type for Oracle databases.

The alternative, Initial Load Extract, serves the one-off initial loading of pre-existing data, not the continuous capture of changes. For our test’s real-time replication, the Integrated Extract is the correct choice.

The Process Name is EXTT1, respecting the documented limit of 8 characters for an Extract's name. A longer name would be rejected: it is a constraint worth knowing when choosing naming conventions.

The Downstream Capture option remains disabled: capture happens on the same database that hosts the source, not on a remote staging database. Downstream is for scenarios where the mining workload should be offloaded onto a dedicated database — not relevant here.

In short, the first step fixes the Extract’s identity: an Integrated Extract named EXTT1 — the recommended configuration for real-time capture from an Oracle database.

14.2 Step 2 — Extract Options

Figure 39 — Step 2: Source Credentials (Domain OracleGoldenGate, Alias conn-atp-ggadmin), Extract Trail Name = ea, Share = Automatic.

Reading Figure 39. The second step links the Extract to the source and defines the trail. Under Source Credentials you choose the Domain OracleGoldenGate and the Alias conn-atp-ggadmin (a required field): it is the connection already assigned to the deployment — the one the Extract will use to read the database.

The Extract Trail Name field is ea, a two-character name: it will be the file into which the Extract writes the captured changes. This very name will have to be referenced by the Replicat; it is the physical coupling point of the pipeline.

The other parameters stay at their appropriate defaults: Begin = Now (capture starts from this moment, not from a point in the past), Trail Size = 2000 MB (maximum size of each trail file before rollover), Encryption Profile = LocalWallet and Encryption Algorithm = NONE.

Under Registration Options, Share = Automatic leaves to the system the choice of how the logmining server's dictionary is shared. It is the recommended default for a standard Extract and requires no manual intervention, simplifying the configuration.

These choices define a standard, well-configured Extract: hooked to the correct connection, with an identified trail, capturing from the outset. The consistency of the trail name with the one we will set in the Replicat is the element demanding the greatest attention.

14.3 Step 3 — Managed Options

Figure 40 — Step 3: Default profile; “Critical to deployment health” flag disabled.

Reading Figure 40. The third step governs the process’s automatic start and restart, and it is optional: the documentation itself marks it as such. For the PoC the Default profile is kept, with no particular auto-start or auto-restart policies.

The “Critical to deployment health” flag is left disabled. This choice has a precise practical consequence: the process’s metrics will not appear in the Cloud Console dashboard, which shows them only for processes marked as critical.

The metrics will remain fully visible in the Deployment Console, where we will read them (Statistics, Report). The choice therefore does not limit our ability to monitor the test — only the visibility in the OCI management dashboard.

For a production environment one would consider marking the processes as critical, to obtain their aggregated metrics in the Cloud Console and to enable any alarms. For a PoC, the Default profile is sufficient and reduces the variables in play.

In short, the Managed Options stay at their defaults because the PoC requires no auto-restart policies: the choice keeps behaviour predictable, and the metrics remain readable in the Deployment Console.

14.4 Step 4 — Parameter File

The final step displays the parameter file. The console generates its header automatically; only the clause indicating which table to capture is added to the editable pane. · Source: Add an Extract for Oracle AI Database · Add Extract (eeske)

--- Auto generated Parameter File ---
EXTRACT EXTT1
USERIDALIAS conn-atp-ggadmin DOMAIN OracleGoldenGate
EXTTRAIL ea
--- End of auto generated Parameter File ---

TABLE GGTEST.T1;   <-- added line

Figure 41 — Step 4: TABLE GGTEST.T1; is added to the auto-generated file to designate the source object.

Reading Figure 41. The grey pane at the top is the automatically generated file and must not be touched: it contains the process declaration (EXTRACT EXTT1), the connection alias (USERIDALIAS) and the trail (EXTTRAIL ea). These are the essential directives binding the process to the source and to the trail.

In the editable pane below, only what is missing is entered: the clause TABLE GGTEST.T1;, which tells the Extract which table to capture. Without this line, the Extract would not know what to replicate.

The notice at the bottom warns to add only additional configuration: duplicates can cause problems. Repeating lines already present in the auto-generated header (a second EXTTRAIL, for example) would produce parsing errors or unexpected behaviour.

The TABLE schema.table; syntax is GoldenGate's standard way of specifying the objects to capture. Wildcards can be used to capture multiple tables, but for the test a single explicit table is the clearest, most verifiable choice.

With this line added, the parameter file is complete: the Extract knows where to read from (the connection), where to write to (the ea trail), and what to capture (table T1). It is ready to be created.

Figure 42 — Outcome: Extracts — Stopped = 1. The Extract is created but not started; no Critical Events.

Reading Figure 42. The Home page now reads Extracts — Stopped = 1: Extract EXTT1 exists but is idle. This is not a problem — it is a deliberate choice.

The Extract was created with Create rather than Create and Run: this registers it without starting it. The reason is to control the start-up order — first prepare the Replicat, then start the Extract — as we shall see in the following chapters.

The Failed column at zero and the absence of Critical Events confirm that creation completed without errors. A failed Extract would appear in the Failed column or generate critical events, both absent here.

The Stopped state is therefore the expected, correct state at this point: the Extract is configured and ready, waiting to be started at the appropriate moment. Meanwhile, we proceed to create the Replicat.

In short, the Extract has been created but deliberately not started, in order to control the processes’ start-up order: first the Replicat is prepared, then the Extract is started.

14.5 Oracle references

• Add an Extract for Oracle AI Database
• Prepare Oracle Database
• Add Extract (eeske)
• Prepare DB user (23ai)
• Which Replicat to choose (blog)

15 · Creating the Replicat (REPT2)

The Replicat reads the operations from the trail and applies them to the target. Before creating it, the documentation recommends a checkpoint table (in the target’s GGADMIN schema), which enables safe restart after an interruption without re-applying transactions. · Source: Add a Replicat for Autonomous AI Database · Add a Replicat for Oracle AI Database · Which Replicat to choose (blog)

15.1 Step 1 — Replicat type

Figure 43 — Step 1: Parallel Replicat in Nonintegrated mode, Process Name = REPT2.

Reading Figure 43. OCI GoldenGate offers four Replicat types: Parallel, Integrated, Nonintegrated and Coordinated. The choice is the most consequential technical decision in this wizard, because it determines how transactions will be applied on the target.

The Parallel Replicat in Nonintegrated mode is adopted — the configuration Oracle recommends for high performance on OLTP workloads: it applies transactions in parallel while preserving their order and dependencies. The choice should be re-evaluated when integrated-apply features (procedural replication, CDR) are required — none of which this PoC uses.

The Process Name is REPT2. Oracle documents a five-character maximum for Parallel Replicat group names and for the OCI creation workflow. Although the generic REST path parameter accepts up to eight characters, that schema-level limit must not be read as overriding the mode-specific Parallel Replicat constraint; REPT2 satisfies the applicable five-character limit. · Source: Add a Replicat for Oracle AI Database · Oracle GoldenGate REST API — Create Replicat

Nonintegrated mode means the Replicat handles the apply on the process side, without delegating it to an apply server inside the database (as the Integrated type would). For the majority of workloads, including ours, this is the optimal configuration.

An Integrated or Parallel Integrated Replicat would be considered when features such as procedural replication, integrated apply, or automatic conflict management (CDR) are required. This PoC requires none of those capabilities, so Parallel Nonintegrated is the appropriate high-performance choice.

15.2 Step 2 — Replicat Options

Figure 44 — Step 2: Replicat Trail Name = ea (identical to the Extract’s trail), Target Credentials and Checkpoint Table.

Reading Figure 44. The crucial point of this step is trail alignment: the Replicat Trail Name must be ea — exactly the same name as the trail written by the Extract. It is from that file that the Replicat reads the operations to apply.

A different trail name would be the most insidious mistake: the Replicat would sit waiting for data on a file that nothing feeds, with no obvious errors, while the Extract wrote to another file. The pipeline would be silently broken.

Under Target Credentials, the Domain OracleGoldenGate and the Alias conn-atp-ggadmin are specified: the same connection as the Extract's, because in this test source and target live in the same database. The Replicat uses it to write to T2.

The Checkpoint Table created on the target is then selected: it is the table in which the Replicat records its read position in the trail, so it can restart safely after a stop or a crash, neither re-applying nor losing transactions.

The combination of these three elements — the correct trail, the target credentials, the checkpoint table — configures a robust Replicat: it knows where to read from, where to write to, and how to resume after an interruption. Trail alignment remains the element to verify with the utmost care.

KEY POINT — Aligning the trail name (ea) between Extract and Replicat is what physically closes the pipeline: the Extract writes to ea, the Replicat reads from ea. A different name would silently break the flow.

15.3 Step 3 — Managed Options

Figure 45 — Step 3: Default profile, as for the Extract.

Reading Figure 45. As with the Extract, the automatic start and restart parameters are optional; the Default profile is kept and the critical flag stays disabled. The symmetry with the Extract is not accidental.

Both processes share the same management model: keeping the defaults on both reduces the variables in play during the test and makes the pipeline’s behaviour more predictable and easier to diagnose.

Here too, the disabled “Critical to deployment health” flag implies that the Replicat’s metrics will not appear in the Cloud Console but remain visible in the Deployment Console, where we will read the Statistics — the single most important datum for validating the replication.

For a PoC, this minimal configuration is the right choice: it avoids introducing auto-restart policies that could mask behaviours we specifically want to observe in a controlled manner during the test.

In short, the Replicat’s Managed Options mirror the Extract’s for symmetry: defaults on both processes, so the pipeline behaves predictably and diagnosably.

15.4 Step 4 — Parameter File

The auto-generated file proposes a catch-all mapping, which must be replaced with the test’s precise mapping: from source T1 to target T2. · Source: Add a Replicat for Autonomous AI Database · Add a Replicat for Oracle AI Database

--- Auto generated Parameter File ---
REPLICAT REPT2
USERIDALIAS conn-atp-ggadmin DOMAIN OracleGoldenGate
--- End of auto generated Parameter File ---

MAP GGTEST.T1, TARGET GGTEST.T2;   <-- mapping

Figure 46 — Step 4: the default mapping MAP *.*, TARGET *.*; is replaced with MAP GGTEST.T1, TARGET GGTEST.T2;.

Reading Figure 46. The auto-generated file proposes MAP *.*, TARGET *.*;, a broad wildcard mapping across all matched source schemas and tables. For this bounded PoC it must be replaced with the explicit mapping MAP GGTEST.T1, TARGET GGTEST.T2;.This line is what defines the meaning of the replication: what goes where.

The MAP source, TARGET target; syntax is the heart of Replicat configuration: it allows mapping tables with different names (T1 → T2), applying transformations, filters and conflict rules. Here we use it in its simplest form — one table to another.

Leaving the default mapping would be a mistake in a real environment: it would replicate unwanted objects, with potentially harmful effects on the target. Substituting the precise mapping is therefore an essential step, not an optional one.

With this line, the Replicat’s parameter file is complete. The process is created with “Create and Run”, so it starts immediately at the end of the wizard — unlike the Extract, which had only been created.

Figure 47 — Outcome: Replicats — Running = 1. Replicat REPT2 is active; the Extract is still Stopped.

Reading Figure 47. The Home page now shows Replicats — Running = 1: REPT2 has started and is listening on the trail. It was created with “Create and Run”, so it started at once.

The Extract, by contrast, is still Stopped. This intermediate state — Replicat active, Extract idle — is entirely normal and intentional: the Replicat can happily wait for data to begin arriving in the trail.

A Replicat listening on a trail that is not yet being fed raises no errors: it simply has nothing to apply until the Extract starts writing. It is passive waiting, not an anomaly.

This sequence — the Replicat listening first, the Extract feeding afterwards — is the reason the Extract had been created without being started. In the next chapter the Extract is started, the pipeline closes, and the Replicat stands ready to consume the first trail records immediately.

In short, the Replicat is already active and listening on the ea trail while the Extract remains idle: a correct intermediate state, resolved by starting the Extract in the following chapter.

15.5 Oracle references

• Add a Replicat for Autonomous AI Database
• Which Replicat to choose (blog)
• Add a Replicat for Oracle AI Database
• Connect to Autonomous Database

16 · Starting the pipeline

With the Replicat listening, the Extract is started (Extracts → EXTT1 → Start). From this moment the pipeline is complete: the Extract produces the trail records, the Replicat consumes them. · Source: Explore the deployment console · Monitor performance (console)

Figure 48 — EXTT1 detail page in the Running state: lag ~0.1 seconds, trail ea, masterkey OGG_DEFAULT_MASTERKEY.

Reading Figure 48. The detail page confirms that EXTT1 is now Running (green tick) and reports telling metrics. The “Running for … seconds” state indicates how long the process has been active, and a lag of roughly 0.1 seconds signals a negligible capture delay.

Such a low lag means the Extract is capturing changes almost instantaneously relative to when they occur in the database. It is the marker of a healthy, real-time capture with no accumulating delay.

The trail shown is ea, the very one the Replicat is reading: visual confirmation that the two processes are hooked to the same file. This is the alignment we paid attention to during the Replicat's creation.

The database reference through the connection (OracleGoldenGate:conn-atp-ggadmin) completes the picture; the page also shows the deployment's default masterkey OGG_DEFAULT_MASTERKEY. Since Encryption Algorithm = NONE was selected in the Extract wizard, this reference must not be read as evidence of applicative encryption of the ea trail.

This screen shows that, at the moment captured, EXTT1 was running, connected, and writing to trail ea, with an observed capture lag of approximately 0.1 seconds.

Figure 49 — Console Home: Extracts Running = 1 and Replicats Running = 1, zero Failed, zero Critical Events.

Reading Figure 49. This is the snapshot of a complete, healthy pipeline: both Running counters read 1, the Failed and Stopped columns are at zero, and the Critical Events table reports nothing.

Extract and Replicat both Running means the chain is closed: the Extract captures and writes to the trail, the Replicat reads from the trail and applies. Subsequent committed DML on T1 that is supported and matched by the configured TABLE and MAP clauses is now eligible to traverse the flow to T2.

The absence of Failed processes guarantees that no error has interrupted the configuration. Had a process abended, it would appear in the Failed column, and the pipeline would not be reliable.

The empty Critical Events table confirms there are no deployment-level critical events: no resource, connectivity or configuration problem requiring attention. The deployment is healthy.

It is the ideal state before starting the functional tests: the engine is ready, healthy and waiting for data. The next chapter runs the DML operations on T1 and verifies that they are reflected on T2, putting this pipeline to the test.

KEY POINT — The start-up sequence used in this PoC placed the Replicat in a waiting state first and started the Extract afterwards. The flow then closed immediately, with an Extract capture lag of ~0.1 s observed in the console.

16.1 Oracle references

• Explore the deployment console
• Monitor performance (console)
• Troubleshoot using logs
• Get started

17 · End-to-end DML validation

The three fundamental DML operations are executed on source T1, each followed by a verification of its reflection on T2. This section validates online change capture, not initial instantiation. The test therefore uses a new row (ID = 3) and commits each operation explicitly. Rows that existed before the chosen capture start point are not made consistent merely by starting Extract and Replicat; a production migration must establish target instantiation separately and then coordinate the CDC start position. · Sources: OCI GoldenGate overview · Automatic per-table instantiation · Monitor performance (console)

17.1 Test method and transaction boundaries

Each test consists of one source DML statement, an explicit COMMIT, and a target-side query. The commit boundary matters: Extract mines committed database changes, and Replicat applies the resulting trail records according to transaction semantics. The sequence INSERT → UPDATE → DELETE also exercises progressively stronger requirements: basic capture, row identification through supplemental logging, and final removal of the same key. · Source: Transaction log settings and requirements · TABLE and MAP parameters

17.2 INSERT

INSERT INTO ggtest.t1 VALUES (3, 'topolino');
COMMIT;
SELECT * FROM ggtest.t2;   -- row (3,topolino) appears in T2

Outcome: the row inserted into T1 appears in T2. Replication of the insert is confirmed. The Extract captured the operation from the redo stream, wrote it into the ea trail, and the Replicat applied it to T2 in near-real-time. · Source: Monitor performance (console) · Troubleshoot using logs

17.3 UPDATE

UPDATE ggtest.t1 SET name = 'minnie' WHERE id = 3;
COMMIT;
SELECT * FROM ggtest.t2 WHERE id = 3;   -- name becomes minnie in T2

Outcome: the value updated in T1 is reflected in T2. This is where the “ID” key recorded by TRANDATA does its work: it lets the Replicat pinpoint exactly which row to modify on the target. Replication of the update is confirmed. · Source: Enabling Table-level Supplemental Logging · Enable TRANDATA / SCHEMATRANDATA

17.4 DELETE

DELETE FROM ggtest.t1 WHERE id = 3;
COMMIT;
SELECT * FROM ggtest.t2 WHERE id = 3;   -- 0 rows in T2

Outcome: the deletion in T1 removes the row in T2 as well. Here too the “ID” key is essential to identify the row to remove. Replication of the delete is confirmed, completing the verification of the three fundamental DML operations. · Source: Enabling Table-level Supplemental Logging · Enable TRANDATA / SCHEMATRANDATA

NOTE — EVIDENCE — Evidence available for this phase: the executed scripts and the native GoldenGate counters of the next chapter (Inserts/Updates/Deletes = 1/1/1, Discards = 0). Evidence not retained: the SQL screenshots of T2’s content after each DML were not captured during the test; if re-captured, they should be inserted next to the respective paragraphs.

RESULT — All three operations were replicated from T1 to T2 with near-real-time behaviour: the quantitative value observed is the Extract capture lag (~0.1 s in the console); end-to-end lag to T2 was not instrumentally measured (no heartbeat table configured in the test). The Extract → ea trail → Replicat pipeline applied insert, update and delete while maintaining consistency for the tested row and the three committed DML operations.

18 · Objective evidence on the dashboard

Beyond verification with queries, the console offers two instruments that document the replication objectively: the Replicat’s Statistics, which expose the counts of applied operations, and the process Report file, which contains the runtime log. · Source: Monitor performance (console) · Troubleshoot using logs

18.1 Replicat Statistics

Figure 50 — REPT2 Statistics: mapping T1 → T2 with Inserts = 1, Updates = 1, Deletes = 1, Conflicts = 0/0/0, Total transactions = 3.

Reading Figure 50. This is the strongest native product evidence retained for the test: the Replicat counters numerically corroborate the three committed DML operations. The Table Statistics table shows, for the mapping from GGTEST.T1 to …GGTEST.T2, the counts of the operations actually applied.

The values Inserts = 1, Updates = 1, Deletes = 1 coincide exactly with the three DML statements executed in the test. Every operation performed on T1 was applied once to T2: none lost, none duplicated.

The Upserts, Truncates, Ignores and Discards columns are at zero: there were no operations of those kinds and no discarded records. A discard would indicate a row the Replicat failed to apply — a situation absent here.

All three conflict counters displayed by the Statistics page are zero (0/0/0). In a clean unidirectional replication such as this, the absence of conflicts is the expected result.

At the bottom, Total transactions = 3 closes the account: the test’s three DML transactions (insert, update, delete) were all processed. The numbers match what was executed down to the single event, which corroborates correct operation for the bounded test case.

POC TEST — 1 insert + 1 update + 1 delete = 3 transactions, zero conflicts, zero discards. It is the product-level corroboration that the bounded INSERT/UPDATE/DELETE test completed without recorded discards or conflicts.

18.2 Process Report file

Figure 51 — REPT2.rpt Report file: header with version 23.26.2.0.2, operating system, PID and, in the visible portion, INFO-type messages. Alongside, the REPT2.dsc Discard file.

Reading Figure 51. The Report file is the process’s runtime log; the figure shows a portion of it. The header reports the exact GoldenGate version (23.26.2.0.2), the operating system, the node and the process PID, followed by the execution messages with timestamps and OGG codes.

In the visible excerpt the displayed messages are of type INFO. An abend (abnormal end) would signal the process’s abnormal termination and would appear with a specific error code; no ERROR or ABEND entry is visible in that excerpt, and the screenshot alone does not attest the complete report.

The Report file is the first place to consult when problems arise: errors, warnings and the process’s periodic statistics appear here. Knowing how to read it is fundamental to troubleshooting in production.

Worth noting, in the Discard Files pane, is the REPT2.dsc file. Its mere presence in the list does not prove its content: the native evidence of the absence of discarded records is the Discards = 0 value in the Statistics. The discard file would contain the rows the Replicat failed to apply.

Together, the Replicat Statistics and the visible report excerpt corroborate the successful execution of the bounded INSERT/UPDATE/DELETE test. The screenshot does not attest the complete report; doing so would require exporting the file or running a complete search for ERROR, WARNING, ABEND and OGG- codes.

ORACLE NOTE — For continuous lag monitoring, the heartbeat table and the Performance Metrics Service are used; in the Cloud Console, metrics appear only for processes marked “Critical to deployment health”.

18.3 Oracle references

• Monitor performance (console)
• Troubleshoot using logs
• Explore the deployment console
• Manage peer deployments (HA/DR)
• Manage deployment backups

19 · Cost management

Billing is based on OCPUs consumed per minute according to the configured base value. With Auto Scaling disabled, you are billed for the base OCPU count whether the processes are running or idle. This point carries important practical consequences at the end of a test. · Source: OCI GoldenGate pricing · OCPU management and billing · OCPU billing (wcpum) · Manage deployments

The following figures are a dated example from the Oracle Cost Estimator for the EU area (estimate captured on 21 July 2026, EUR, 744 hours/month assumed, contractual discounts and taxes excluded). Readers should verify current pricing before using the numbers for budgeting: License-Included at €1.250013 per OCPU-hour and BYOL at €0.300018 per OCPU-hour. On a continuous monthly basis (744 hours), 1 OCPU costs roughly €930 with License-Included and roughly €223.21 with BYOL; the PoC, with 1 BYOL OCPU used in sessions (~80 hours), lands in the region of €24. · Source: OCI GoldenGate pricing · OCPU management and billing · OCPU billing (wcpum)

ORACLE NOTE — The Stop is performed from the OCI Cloud Console (not from the internal Deployment Console): Deployments page → select gg-demo → Actions menu → Stop. While the deployment is stopped, the Deployment Console is not accessible: this is expected behaviour.

19.1 Oracle references

• OCPU management and billing
• Manage deployments
• OCPU billing (wcpum)
• Manage deployment backups
• Manage peer deployments (HA/DR)

20 · Conclusions

The Proof of Concept has demonstrated, end to end and with verifiable evidence, OCI GoldenGate’s ability to replicate changes between two Oracle tables in near real time, starting from a connection to Autonomous Database authenticated as GGADMIN, with the password held in a secret encrypted by an external KMS key and governed by IAM policies scoped for the PoC, with tighter least-privilege hardening recommended for pilot and production. · Source: OCI GoldenGate overview · Connect to Autonomous Database · Get started

The entire journey — architecture, provisioning, Identity Domain, database, Vault/secret, policies, connection, tests, TRANDATA, Extract, Replicat, start-up and DML validation — has been documented screen by screen, with every choice justified and anchored to the Oracle documentation. The replication cycle came out clean: 1 insert, 1 update, 1 delete, 0 conflicts, 0 discards, near-real-time behaviour (capture lag ~0.1 s observed). · Source: Monitor performance (console) · Get started · Explore the deployment console

FINAL SUMMARY — OCI GoldenGate successfully replicated INSERT, UPDATE and DELETE from source to target, with numerical confirmation in the Statistics and no errors or abends in the visible report excerpt. The complete chain — security (Vault/secret/IAM), networking (private mTLS), capture (Extract), transport (trail) and apply (Replicat) — was validated in the field.

Next in the series

With Volume I complete, the next article will move from the single-Autonomous-Database laboratory topology to a cross-service database topology. Volume II will provision and prepare a DB system in Oracle Base Database Service, create and assign the OCI GoldenGate target connection, and validate replication from Autonomous Database to that co-managed database target. The comparison will make explicit what Autonomous Database pre-provisions and what must instead be configured on the DB system. Volume III will then consolidate the production controls: OCI IAM and separation of duties, the Security, Administrator, Operator, and User deployment roles, OCI Logging Process and Error logs, OCI Audit as a distinct control-plane evidence source, backups and diagnostics, private connectivity, monitoring, recovery, and least privilege.