Product evolution

AI integration in Oracle Enterprise Manager 24ai was quite evolving rapidly.

• Ask EM
  Was first introduced with Enterprise Manager 24ai Release 1 Update 4.
  Dependent of OCI Ops Insight for the chatbot functionality and processing.
• Oracle AI Database Assistant
  Was introduced in Enterprise Manager 24ai Release 1 Update 10.
  Replacing Ask EM
  Use of LLM provider: OCI GenAI or BYO LLM
• MCP server
  Enterprise Manager 24ai Release 1 Update 12 is now integrating a MCP server which will bring a brand of new possibilities.
  The MCP server is directly built in OEM.
• Finally Enterprise Manager 24ai Release 1 Update 13 will bring a new good feature:
  Autocompletion suggestions. We just write on the prompt “oracle databases” and many suggestions might come : “Show Oracle Databases by average active sessions” or “Show Oracle Databases by CPU time”

In a nutshell

Oracle AI Database Assistant will help me interacting with OEM with Natural-Language questions, like “What happened to prod?”. The assistant will then understand my question and retrieves data directly from OMR (Oracle Management Repository). OMR is storing all data for all my targets related to their health, issues and performance.

Oracle AI Database Assistant no longer depends on OCI Ops Insight. OCI Ops Insights subscription is not needed any more.

Oracle AI Database Assistant will use LLM (Large-Language Model). Multiple LLM are supported:

• You can use the one from Enterprise Manager, so OEM as provider. Oracle AI Database Assistant will access directly OCI Generative AI.
• Or you can bring your own LLM Provider. Two Models are supported : OpenAI or Ollama. To use external LLM provider you will need some additional access between OMS server and OCI.

Prerequisites

There is a few prerequisites to configure and use Oracle AI Database Assistant. I will remind them here, but please refer to my other blogs explaining how to configure Oracle AI Database Assistant for guidance with screenshots.

• Log as SYSMAN for configuring Oracle AI Database Assistant
• Choice in LLM provider
• To use Enterprise Manager provider one account in a supported region is needed
  • Japan Central (Osaka): ap-osaka-1
  • Germany Central (Frankfurt): eu-frankfurt-1
  • Brazil East (Sao Paulo): sa-saopaulo-1
  • UK South (London): uk-london-1
  • US Midwest (Chicago): us-chicago-1
• Oracle AI Database Assistant to be enabled in Enterprise Manager
  • Activated per default
  • Command line
    emctl set property -name enable_genai_assistant -value false|true
• OCI policies so that Enterprise Manager can access the OCI Generative AI service
  allow group to manage opsi-genai-em-session in compartment
allow group to use generative-ai-family in compartment
• An OCI Named Credential for communication with OCI LLM service
  • Use of Enterprise Manager LLM provider
  • OCI Authentication through API key

With Oracle AI Database Assistant, you can bring your own LLM Provider:

• Bring-Your-Own LLM Providers
• OpenAI or Ollama
• API Key for LLM provider authentication
• Name of the model to be used
• Model endpoint URL
  • OMS property oracle.sysman.llm.provider.allowedProviderUrls
• Network connectivity between OMS and the provider endpoint

And what about the cost? Oracle AI Database Assistant includes a complimentary allocation of AI tokens for OCI Generative AI models. The cost can be visible through the OCI Ops Insights service.Once the allocated tokens are consumed, extended cost charged to the OCI account based on the AI model and the OCI region. See following oracle documentations:
https://www.oracle.com/cloud/price-list/#pricing-ai
https://docs.oracle.com/en-us/iaas/Content/generative-ai/home.htm

Let’s do some further tests!

Let’s have fun and test the Oracle AI Database Assistant, now I could configure it.

Asking for targets…

I first asked about status summary for all my targets. Answer was coherent with the OEM summary dashboard.

I then asked to list the target that are down, which of course is ok as the host was not up and running.

I then started the lab node.

I confirmed there is no more target down.

I can see that no more targets are down. I took the opportunity to test the language wording, and as we can see, Oracle AI Database Assistant was not able to understand the situation, and my question “and now?” referring to make it (we would have been attracted to write him, but let’s use it ) understand that I wanted the same previous questions was not understandable. We can only use specific OEM language.

I could list the targets that are up. What is cool is that I do not need to make full sentences. “List target up” was enough for the assistant to understand the question.

I could also ask to filter on host type, which was successfully.

Asking for documentation…

As we can see, the assistant will not provide me any OEM documentation, and the expected prompt stick on OEM data model language.

Asking for incidents…

I could also successfully list open incidents.

Asking for databases status…

I could list database target status, and also the assistant understand pdb, pluggable database.

Asking the assistant to list databases that have currently problems, I could get as answer… All databases. We can easily understand that the assistant take word that it understands and that it can put in correlation with any data from the OMR without making a full analyse of the full question.

Asking for critical alerts…

I could also ask the assistant to list the critical alerts. This was working as expected. I was only a quite of surprised that asking the same for the last 24 hours, I got no data displayed. Which is incoherent knowing I have one running… We can see that the “last 24 hours” has been understood, as the filter “Last 24 hours” appeared.

I stopped BITS999P_PDB1 Pluggable Database to see if it will been displayed in the critical alerts.

Stopping PDB:

[oracle@svl-orap-chz0-cl1n1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Sep 22 13:18:36 2026
Version 19.31.0.0.0

Copyright (c) 1982, 2026, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.31.0.0.0

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     2 PDB$SEED               READ ONLY  NO
     3 BITS999P_PDB1          READ WRITE NO

SQL> alter session set container=BITS999P_PDB1;

Session altered.

SQL> alter pluggable database close abort;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     3 BITS999P_PDB1          MOUNTED

Let’s check the critical alerts again.

Working as expected. I could even be more precise filtering on pluggable database only.

I restarted the PDB:

SQL> alter pluggable database open;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     3 BITS999P_PDB1          READ WRITE NO
SQL>

And I could confirm the alerts disappeared.

Oh by the way, now my Data Guard alerts for last 24 hours filter is working. No idea why.

Asking what happened to my database…

I can ask what happened to a specific database in the last night, and the answer is totally coherent. We can see how the filters are appearing according to the content of my prompt: “Pluggable Database”, “BITS999P_PDB1”, “Last 1 day”.

Asking what happened to the PDB in the last 2 years, the filter automatically applied is “Last 60 minutes”. This might be related to a purge parameter, I guess… I have no explanation so far.

Asking what is the status of BITS999P_PDB1, we can see that the assistant did not understand the question, but added some drop-down list, where I can choose data.

Which will give me the possibility to get some valid information.

I could also successfully query what happened to the PDB in a time frame. Which is a very good added value.

Asking for tablespace usage…

I also asked for pluggable database tablespace usage, for the same PDB. I could get an answer, which really is not that readable.

But the more surprising is the assistant might not be so trustable. Let me explain why. Later on, I could see get coherent results for target status, incidents, but I could not get any information any more for the tablespace usage.

Even if the metrics are available in OEM, see next pictures.

To wrap up…

Following is the pros and cons I see in this new Oracle AI assistant.

When I think it is a good startup, with an assistant that will help to get more quickly the health, issue and performance on any target monitored by OEM, the tool still need to improve the stability and the trust we can put on him.

L’article AI meets OEM, let’s test Oracle AI Database Assistant est apparu en premier sur dbi Blog.

Indeed, a fresh extract writing to the same trail name/path keeps appending after the old sequence numbers instead of restarting at 000000000. A fresh replicat starts reading from 000000000 by default. If you don’t remove the trail files when re-creating an extract and replicat pair, the extract will do its job. However, the new replicat has no way to tell leftover files apart from new ones. It will read whatever is still sitting in 000000000 and onward as if it were live data.

The adminclient does have a command for this, PURGE EXTTRAIL, but it only works once nothing is using the trail anymore:

OGG (http://vmogg:7810 ogg_test_01) 3> purge exttrail PDB1/aa

Error: Cannot purge trail 'PDB1/aa', the trail is in use by EXTRACT 'EOGG375'

From the adminclient, you need to delete the extract first. Then, PURGE EXTTRAIL removes every sequence file and the trail resource:

OGG (http://vmogg:7810 ogg_test_01) 2> purge exttrail PDB1/aa
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'.
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.
[...]
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000035'. Purge rule: Purging all files for trail 'PDB1/aa'.

So from an interactive session, PURGE EXTTRAIL is the easy way. But when automating, the REST API is often easier to handle, so let’s see how it should be done with it.

Deleting a trail

Calling the DELETE /services/{version}/trails/{trail} endpoint seems like a good call. Let’s try this first, on a trail still attached to a stopped (but not deleted) extract, using the delete_trail method of the oggrestapi Python package:

from oggrestapi import OGGRestAPI

client = OGGRestAPI(
    url="http://vmogg:7810",
    username="ogg",
    password="ogg"
)

client.delete_trail(trail="aa", path_query="PDB1")

RuntimeError: ERROR (code 400) - http://vmogg:7810/services/v2/trails/aa: Unable to delete trail resource 'PDB1/aa' because there are processes using it.

This is expected: a trail still referenced by a process cannot be deleted. Delete the extract, then retry:

RuntimeError: ERROR (code 500) - http://vmogg:7810/services/v2/trails/aa: There was a problem updating the Administration Service resources.

On a non-empty trail, once the process that was using it is gone, this call still fails with an OGG-30375 error (code 500) and a generic There was a problem updating the Administration Service resources.

To delete a trail with the GoldenGate REST API, you must first empty the trail sequence. Once the trail sequence is empty, the trail resource is automatically deleted. The method delete_trail_sequence_collection(), mapping DELETE /services/{version}/trails/{trail}/sequences, does this in one call: it takes a sequence range, first and last, as named keyword arguments:

result = client.delete_trail_sequence_collection(
    trail="aa",
    path="PDB1",
    first=0,
    last=999999999
)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'."), ('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'.")]

An oversized value for last is a safe way to delete “everything”. Both first and last are required: omitting either one fails with an OGG-12104 error (no “from first to the end” shortcut).

Background operations of PURGE EXTTRAIL

PURGE EXTTRAIL from the adminclient does not call this endpoint. Tracing its requests through restapi.log shows it calling the generic command endpoint instead, POST /services/{version}/commands/execute, equivalent of the execute_command method, with a purge command:

data = {
    "name": "purge",
    "purgeType": "trails",
    "trails": [{"name": "aa", "path": "PDB1"}],
    "useCheckpoints": False,
    "keep": [{"type": "min", "units": "files", "value": 0}],
}

result = client.execute_command(data=data)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-00957', "Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'."), ('OGG-00957', "Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.")]

keep with value: 0 means “keep zero files”, or purge everything. It has the same end result as delete_trail_sequence_collection(), but with one OGG-00957 message per file instead of the range-clamp/success pair.

Whether it’s from the adminclient or with the REST API, the procedure to delete trail files is the same: make sure processes are deleted before deleting their trail files, and delete them one by one or with a purge command.

L’article Deleting GoldenGate Trail Files via the REST API (OGG-30375) est apparu en premier sur dbi Blog.

Eighty-one hours. For one table. There were five more behind it.

SSMA is well documented but migrations at this scale are not done often enough to have plenty of materials. Most of what you find is either a step-by-step guide against a sample database, or a vendor case study with no numbers in it. This post has the numbers, in the order I actually got them, including the ones I got wrong first.

To keep my sanity through a long and intricate migration, I kept a logbook. This first part is about getting the data across: the brief, the type negotiation, and the settings that took the load from 788 rows per second to 42,170. Part 2 picks up exactly where this one stops, with 3.2 TB sitting in heaps and not a single index on it.

Day 1. The brief, and the one sentence that mattered

An Oracle 19c production database running an asset management package, to be archived into SQL Server 2025 Standard Edition. Roughly 5,600 tables, 4,800 views, a little under 5 TB depending on how you count (more on that later).

Three facts shaped everything that followed.

The target is read-only. Nothing will ever write to it once the load is finished, because the whole point of the exercise is to keep fifteen years of records available to people who need to look something up rather than to keep an application running. Auditors come by, rarely and unpredictably, to find one specific row.

That is the entire performance requirement, and it decided more of this project than any measurement did. It is why the indexes are broad rather than targeted at known queries, why PAGE compression costs nothing here, why 25,000 triggers went straight in the bin, and why two views that take thirty seconds are perfectly acceptable. Every one of those decisions comes back later in this series.

The freeze has no deadline. This is unusual enough to state plainly. Most migrations are built around a cutover window measured in hours, and every technical decision bends to it. Here the source was frozen since the beginning and simply stayed frozen.

The data travels in two hops, which becomes the story of the whole load:

Getting in without asking for the keys

The source is critical production, so the migration account got the minimum that actually works: CREATE SESSION, dictionary read, and SELECT on the tables in scope.

SSMA also asks for CREATE ANY PROCEDURE, CREATE ANY TYPE and CREATE ANY TRIGGER. Those three serve server-side extraction and SSMA’s own testing feature and at the end of the project a single DROP USER <user_name> CASCADE removes the whole thing.

There is a decision hiding here that is worth making deliberately. SELECT ANY TABLE is convenient and gives your account read access to the entire database, including schemas you are not migrating. Granting SELECT table by table on the schemas in scope is more work and produces an auditable perimeter.

Day 2. Negotiating with numbers

We agreed the type mapping with the client before converting anything, which I recommend for the political reasons as much as the technical ones:

38 digits against 51

Then the conversions started failing on decimal overflow, and the reason is more interesting than “the numbers were too big“.

Oracle NUMBER without precision is a floating decimal: 38 significant digits, with an exponent range running from 1e-130 to just under 1e126. SQL Server DECIMAL is fixed point: the precision bounds the magnitude. DECIMAL(38,0) stops at 1e38 and there is no exponent to escape with.

So the values that broke were not unusually precise, they were unusually large. A value carrying 51 digits and two significant figures is perfectly ordinary in Oracle, sails through every constraint it meets on the way out, and then has no DECIMAL representation waiting for it at the other end.

The answer is FLOAT, which is also a floating type and reaches ±1.79e308. Eleven tables were reloaded after switching the mapping.

Be careful what you promise the client here, because FLOAT keeps 15 significant digits, not 38. For the values that actually overflowed, large magnitude and few significant figures, the loss is zero. For a value in those columns carrying more than 15 significant digits, the loss is real. That is countable rather than arguable, so count it before you write the reassuring email.

25,000 triggers, none converted

The source carried roughly 25,000 triggers, almost all in one schema. I converted none of them and unticked them all before Convert Schema.

The reasoning fits in one line: on a read-only database, a trigger never fires. Converting and testing 25,000 objects that will never execute would have consumed weeks and produced nothing.

Tables went first, with their types and sequences, to unblock the data migration. Packages, views and procedures came later. Indexes are not a separate step: SSMA converts them alongside their table, turning bitmap indexes into nonclustered ones, handling function-based indexes case by case, and skipping XMLTYPE indexes entirely.

Then 103 tables failed extraction with ORA-00904, all because of hidden SYS_C…$ columns left behind by function-based indexes. I had already set “Ignore hidden system columns” to Yes, which is why this took longer than it should have: in our project that option governed schema conversion and did not stop the extraction from asking for the column. The fix is a custom select that aliases NULL into the missing name (see my previous blog about this problem).

Day 3. Turning everything off

The loading method is three switches and a recovery model.

Disable the nonclustered indexes. A disabled index stores nothing and is not maintained row by row during the load.

Disable the foreign keys with NOCHECK CONSTRAINT.

Drop the clustered primary keys on the largest tables and load into heaps.

Then set the recovery model to SIMPLE. With heaps and bulk insert, logging is already minimal.

The script that does this across every schema needs to be restartable and needs to log what it did. A load that runs for days will be interrupted, and you want to know exactly which of 22’000 indexes were disabled when it was.

Script to disable all nonclustered indexes:

USE <DB_NAME>;  
GO
  
  
IF OBJECT_ID(N'tempdb..#Schemas') IS NOT NULL DROP TABLE #Schemas;
CREATE TABLE #Schemas (schema_name sysname PRIMARY KEY);
  
INSERT INTO #Schemas (schema_name) VALUES (N'<SCHEMA_NAME>'); --Insert your schema name here
    ;
  
SELECT schema_name AS schemas_a_traiter FROM #Schemas;
GO
  
  
-- Disable all NC Indexes
 
SET NOCOUNT ON;
DECLARE @Execute bit = 0;   -- 0 = preview ; 1 = execute
  
DECLARE @cmd nvarchar(max);
DECLARE @n   int = 0;
  
DECLARE idx_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT N'ALTER INDEX ' + QUOTENAME(i.name)
         + N' ON ' + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name)
         + N' DISABLE;'
    FROM   sys.indexes  i
    JOIN   sys.tables   t ON i.object_id = t.object_id
    JOIN   sys.schemas  s ON t.schema_id = s.schema_id
    WHERE  s.name IN (SELECT schema_name FROM #Schemas)
      AND  i.type_desc            in (N'NONCLUSTERED') 
      AND  i.is_disabled          = 0                
    ORDER BY s.name, t.name, i.name;
  
OPEN idx_cur;
FETCH NEXT FROM idx_cur INTO @cmd;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @n += 1;
    PRINT @cmd;
    IF @Execute = 1
    BEGIN
        BEGIN TRY
            EXEC sys.sp_executesql @cmd;
        END TRY
        BEGIN CATCH
            PRINT N'   -- ECHEC : ' + ERROR_MESSAGE();
        END CATCH
    END
    FETCH NEXT FROM idx_cur INTO @cmd;
END
CLOSE idx_cur;
DEALLOCATE idx_cur;
  
PRINT N'---';
PRINT CONVERT(nvarchar(10), @n) + N' index nonclustered '
    + CASE WHEN @Execute = 1 THEN N'disabled.' ELSE N'te be disabled (preview).' END;
GO
  
  
----------------------------------------------
 
 
SET NOCOUNT ON;
DECLARE @Execute bit = 0;   -- 0 = preview ; 1 = executer
  
DECLARE @cmd nvarchar(max);
DECLARE @n   int = 0;
  
DECLARE fk_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT N'ALTER TABLE ' + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name)
         + N' NOCHECK CONSTRAINT ' + QUOTENAME(fk.name) + N';'
    FROM   sys.foreign_keys fk
    JOIN   sys.tables  t ON fk.parent_object_id = t.object_id
    JOIN   sys.schemas s ON t.schema_id = s.schema_id
    WHERE  s.name IN (SELECT schema_name FROM #Schemas)
      AND  fk.is_disabled = 0;
  
OPEN fk_cur;
FETCH NEXT FROM fk_cur INTO @cmd;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @n += 1;
    PRINT @cmd;
    IF @Execute = 1
    BEGIN
        BEGIN TRY EXEC sys.sp_executesql @cmd; END TRY
        BEGIN CATCH PRINT N'   -- FAILED: ' + ERROR_MESSAGE(); END CATCH
    END
    FETCH NEXT FROM fk_cur INTO @cmd;
END
CLOSE fk_cur;
DEALLOCATE fk_cur;
  
PRINT N'---';
PRINT CONVERT(nvarchar(10), @n) + N' FK '
    + CASE WHEN @Execute = 1 THEN N'disabled.' ELSE N'to be disabled (preview).' END;
GO 

There is a second script that puts all of this back, with PAGE compression, once the data is in. It belongs with the rebuild rather than with the load, so it is in part 2.

Day 4. ×53, on the same architecture

The first load ran client-side: the hop server reads from Oracle and writes to SQL Server.

On the SQL Server side the dominant wait was ASYNC_NETWORK_IO, which is the engine telling you it has finished its work and is sitting there waiting for the next batch to arrive. Meanwhile CPU and memory on the hop VM stayed low throughout. Nothing anywhere in the chain was short of power; the pipeline was simply underfed.

The answer for this was not a different architecture (with for example a linked server directly from Oracle to SQL Server), it was three settings on the one I already had.

Load into heaps with the nonclustered indexes disabled. Parallelise across tables, not within one, which is the part most people have backwards about SSMA: Thread Count 14 with Table lock = No, because TABLOCK plus multithreading deadlocks. Batch size at 200’000.

Measured with the two-timestamp method: 7,000,000 rows in 166 seconds, about 42,170 rows per second. Against 788, that is ×53.

It is worth being explicit about why write-side changes fixed a network wait, because the two do not obviously connect. Of the three levers only one touches writing. Parallelising across tables fills a pipe that was carrying a single stream and fast writes remove the back-pressure that was leaving the sender idle.

Two volumetry traps

Ranking tables by dba_segments with segment_type = 'TABLE' ignores LOBs, which live in their own segment. One table that looked unremarkable carried 123 GB of LOB. Redo the ranking with LOB segments included before you plan anything. And row count does not rank the same way as volume. One table held 2.8 billion rows in 67 GB. Another held a tenth of that in fourteen times the space.

What I would tell the next person, about the load

The bottleneck was the feed rate rather than the hardware. 788 rows per second, with ASYNC_NETWORK_IO at the top of the wait list, on a chain where nothing was short of CPU or memory. Three settings took it to 42,170: heaps, disabled indexes and parallelism across tables. Reach for the settings before you reach for a new architecture, because the new architecture takes a week to build and may not be the thing that was slow.

On types, the failure was one of magnitude and not of precision, which is worth knowing before you try to diagnose it. Oracle NUMBER is a floating decimal whose exponent runs far past anything DECIMAL can address, so a value with 51 digits and two significant figures breaks a conversion that a value with 38 significant digits survives without trouble. And when you move those columns to FLOAT, count what you are actually giving up before you write the email saying nothing was lost.

At this point the data is across and the database is useless. Every nonclustered index is disabled, the largest tables have no primary key, the foreign keys are off, and none of the four thousand views compile. Part 2 is about putting all of that back.

L’article Archiving 5 TB from Oracle into SQL Server: a migration logbook (part 1) est apparu en premier sur dbi Blog.

One of our customers needed to archive a 4T Oracle database. Several options have been chosen, one of them being archiving the data to SIARD format using SIARD Suite from Swiss Federal Archives. This blog posts explains the basics: what SIARD Suite is, how it works, and examples in command line mode.

Meeting SIARD Suite

SIARD Suite is software developed and made freely available by Swiss Federal Archives for long-term archiving of data stored in the following relational database management systems:

• MS Access 2007 or newer
• DB/2 or newer
• MySQL (or MariaDB) 5.5 or newer
• Oracle 10 or newer
• PostgreSQL 11 or newer
• SQL Server 2012 or newer

Data is extracted and stored in a custom SIARD format based on XML, SQL:2008, UNICODE and ZIP64 standards, thus enabling long-term storage of data archives (often required by audit projects, governance and legal frameworks).

Archive data files can later on be used to load the data in a new database if required.

The software can be downloaded from GitHub through this link.

Concepts

Archived data is stored in an XML files collection conforming to SQL:2008 standard.

Code and custom application objects are not extracted. However, table and columns definition are exported as XML metadata. BLOBs and CLOBs are stored as binary files outside of the XML files.

To unload more metadata, database features can be used such as Data Pump or DBMS_METADATA package procedures/functions when dealing with an Oracle database as the source database.

Basic principles of database archiving with SIARD Suite

The following list summarizes what to take into account and anticipate before starting a new archiving project:

• clearly define the data archiving scope: which tables, views or schemas, which records, and so on
• create a dedicated user with the least privileges (typically read-only) on the objects belonging to the archiving scope
• create views in case you need to filter data (columns and/or rows) to be archived
• the source database must be frozen during archiving jobs (use whatever features the source database provides to bring the database in such a state)
• to check thoroughly the end result of the archiving jobs, load the archive data into another database
• define additional metadata to archive based on your specific business needs ; this will later (think of several years in the future) lead to a better understanding of data archives : PL/SQL code, application documentation, data model entity-relation diagrams, and so on.

How SIARD Suite works

SIARD Suite is a JavaFX application, requiring JRE17 with JavaFX support in its latest release (v2.2.167) and can be used on Windows, Linux and MacOS.

Based on our experience, it is recommended to download the binary file with the right Java version embedded (always better not having to manage a separate stack).

There are two interfaces available:

• Graphical User Interface (GUI)
• Command Line Interface (CLI)

Take care, if you are planning to use the CLI, to not use “native” binaries because they don’t include the CLI.

Application installation

Binary files are downloaded as ZIP files and can be installed anywhere on your system. For our customer project, we decided to create a separate Virtual Machine with adequate storage space thanks to the high performance link between the two VMs.

Once SIARD Suite has been unzipped, the directory looks like:

SIARD-Suite.2.2.161-linux
├── bin
├── conf
├── legal
├── lib
└── release

As expected, the bin directory contains all relevant utilities to perform the archiving or loading jobs:

SIARD-Suite.2.2.161-linux/bin
├── java
├── jfr
├── jrunscript
├── keytool
├── siard-from-db
├── siard-from-db.bat
├── SIARD-Suite
├── SIARD-Suite.bat
├── siard-to-db
└── siard-to-db.bat

Command line interface

‘siard-from-db’ utility

Using the ‘siard-from-db’ utility is quite straightforward since there is no fine grained configurations/options/parameters to choose from:

siard-from-db [-h] | [-o] [-v] [-l=<login timeout>] [-q=<query timeout>] [-i=<import
meta data>] [-x=<external lob folder>] [-m=<mime type>] -j=<JDBC URL> -u=<database
user> -p=<database password> -s=<siard file> -e=<export meta data>"

The following table, pulled from the SIARD Suite documentation, details each parameter’s goal and usage pattern:

For instance, to extract the Oracle HR sample schema, we could use the following command:

./siard-from-db -l=10 -q=120 \
-j=jdbc:oracle:thin:@[hostname|ip]:listening_port/pdb_name \
-u=hr -p=hr_password -s=hr.siard -e=hr_metadata.xml

The archive job produces the following two files:

Running the Linux ‘file’ command on the ‘hr.siard’ file confirms it is a Zip archive file:

file hr.siard
hr.siard: Zip archive data, at least v2.0 to extract

Listing the content of the archive file returns:

unzip -l hr.siard
Archive:  hr.siard
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  07-27-2026 08:15   content/
        0  07-27-2026 08:16   content/schema0/
        0  07-27-2026 08:16   content/schema0/table0/
        0  07-27-2026 08:16   content/schema0/table1/
        0  07-27-2026 08:16   content/schema0/table2/
        0  07-27-2026 08:16   content/schema0/table3/
        0  07-27-2026 08:16   content/schema0/table4/
        0  07-27-2026 08:16   content/schema0/table5/
        0  07-27-2026 08:16   content/schema0/table6/
     1595  07-27-2026 08:16   content/schema0/table0/table0.xml
     4857  07-27-2026 08:16   content/schema0/table0/table0.xsd
     1884  07-27-2026 08:16   content/schema0/table1/table1.xml
     4910  07-27-2026 08:16   content/schema0/table1/table1.xsd
    19577  07-27-2026 08:16   content/schema0/table2/table2.xml
     5323  07-27-2026 08:16   content/schema0/table2/table2.xsd
     1786  07-27-2026 08:16   content/schema0/table3/table3.xml
     4909  07-27-2026 08:16   content/schema0/table3/table3.xsd
     1345  07-27-2026 08:16   content/schema0/table4/table4.xml
     4951  07-27-2026 08:16   content/schema0/table4/table4.xsd
     2740  07-27-2026 08:16   content/schema0/table5/table5.xml
     5036  07-27-2026 08:16   content/schema0/table5/table5.xsd
      455  07-27-2026 08:16   content/schema0/table6/table6.xml
     4793  07-27-2026 08:16   content/schema0/table6/table6.xsd
        0  07-27-2026 08:16   header/
        0  07-27-2026 08:16   header/siardversion/
        0  07-27-2026 08:16   header/siardversion/2.2/
    38441  07-27-2026 08:16   header/metadata.xsd
     4825  07-27-2026 08:16   header/table.xsd
    32980  07-27-2026 08:16   header/metadata.xml
---------                     -------
   140407                     29 files

For each table, SIARD Suite generates an XML file containing the data unloaded from the database and an XSD file with the XML schema definition used.

The header/metadata.xml file contains the list of schemas, list of tables, list of table columns, and so on.

Here is an extract from header/metadata.xml file produced by the HR archiving job:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<siardArchive xmlns="http://www.bar.admin.ch/xmlns/siard/2/metadata.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.2" xsi:schemaLocation="http://www.bar.admin.ch/xmlns/siard/2/metadata.xsd metadata.xsd">
    <dbname>(...)</dbname>
    <dataOwner>(...)</dataOwner>
    <dataOriginTimespan>(...)</dataOriginTimespan>
    <producerApplication>SiardFromDb 2.2.26 Swiss Federal Archives, Berne, Switzerland, 2008-2016</producerApplication>
    <archivalDate>2026-07-27Z</archivalDate>
    <messageDigest>
        <digestType>MD5</digestType>
        <digest>8DC757A5338AA000234CC6199FEFE0AA</digest>
    </messageDigest>
    <clientMachine>srvsiard</clientMachine>
    <databaseProduct>Oracle Oracle AI Database 26ai Enterprise Edition Release 23.26.2.0.0 - Production</databaseProduct>
    <connection>jdbc:oracle:thin:@xxx.xxx.xxx.xxx:yyyy/pdb_name</connection>
    <databaseUser>HR</databaseUser>
    <schemas>
        <schema>
            <name>HR</name>
            <folder>schema0</folder>
            <tables>
                <table>
                    <name>COUNTRIES</name>
                    <folder>table0</folder>
                    <description>country table. References with locations table.</description>
                    <columns>
                        <column>
                            <name>COUNTRY_ID</name>
                            <type>CHAR(2)</type>
                            <typeOriginal>CHAR(2)</typeOriginal>
                            <nullable>false</nullable>
                            <description>Primary key of countries table.</description>
                        </column>
                        <column>
                            <name>COUNTRY_NAME</name>
                            <type>VARCHAR(60)</type>
                            <typeOriginal>VARCHAR2(60)</typeOriginal>
                            <description>Country name</description>
                        </column>
                        <column>
                            <name>REGION_ID</name>
                            <type>FLOAT(38)</type>
                            <typeOriginal>NUMBER</typeOriginal>
                            <description>Region ID for the country. Foreign key to region_id column in the departments table.</description>
                        </column>
                    </columns>
                    <primaryKey>
                        <name>COUNTRY_C_ID_PK</name>
                        <column>COUNTRY_ID</column>
                    </primaryKey>
                    <foreignKeys>
                        <foreignKey>
                            <name>COUNTR_REG_FK</name>
                            <referencedSchema>HR</referencedSchema>
                            <referencedTable>REGIONS</referencedTable>
                            <reference>
<column>REGION_ID</column>
<referenced>REGION_ID</referenced>
                            </reference>
                            <deleteAction>RESTRICT</deleteAction>
                            <updateAction>CASCADE</updateAction>
                        </foreignKey>
                    </foreignKeys>
                    <rows>25</rows>
                </table>
                <table>
                    <name>DEPARTMENTS</name>
                    <folder>table1</folder>
                    <description>Departments table that shows details of departments where employees\u000Awork. references with locations, employees, and job_history tables.</description>
                    <columns>
                        <column>
                            <name>DEPARTMENT_ID</name>
                            <type>SMALLINT</type>
                            <typeOriginal>NUMBER(4,0)</typeOriginal>
                            <nullable>false</nullable>
                            <description>Primary key column of departments table.</description>
                        </column>
                        <column>
                            <name>DEPARTMENT_NAME</name>
                            <type>VARCHAR(30)</type>
                            <typeOriginal>VARCHAR2(30)</typeOriginal>
                            <nullable>false</nullable>
                            <description>A not null column that shows name of a department. Administration,\u000AMarketing, Purchasing, Human Resources, Shipping, IT, Executive, Public\u000ARelations, Sales, Finance, and Accounting.\u0020</description>
                        </column>
                        <column>
                            <name>MANAGER_ID</name>
                            <type>INT</type>
                            <typeOriginal>NUMBER(6,0)</typeOriginal>
                            <description>Manager_id of a department. Foreign key to employee_id column of employees table. The manager_id column of the employee table references this column.</description>
                        </column>
                        <column>
                            <name>LOCATION_ID</name>
                            <type>SMALLINT</type>
                            <typeOriginal>NUMBER(4,0)</typeOriginal>
                            <description>Location id where a department is located. Foreign key to location_id column of locations table.</description>
                        </column>
                    </columns>
                    <primaryKey>
                        <name>DEPT_ID_PK</name>
                        <column>DEPARTMENT_ID</column>
                    </primaryKey>
                    <foreignKeys>
                        <foreignKey>
                            <name>DEPT_MGR_FK</name>
                            <referencedSchema>HR</referencedSchema>
                            <referencedTable>EMPLOYEES</referencedTable>
                            <reference>
<column>MANAGER_ID</column>
<referenced>EMPLOYEE_ID</referenced>
                            </reference>
                            <deleteAction>RESTRICT</deleteAction>
                            <updateAction>CASCADE</updateAction>
                        </foreignKey>
                        <foreignKey>
                            <name>DEPT_LOC_FK</name>
                            <referencedSchema>HR</referencedSchema>
                            <referencedTable>LOCATIONS</referencedTable>
                            <reference>
<column>LOCATION_ID</column>
<referenced>LOCATION_ID</referenced>
                            </reference>
                            <deleteAction>RESTRICT</deleteAction>
                            <updateAction>CASCADE</updateAction>
                        </foreignKey>
                    </foreignKeys>
                    <rows>27</rows>
                </table>

Complete metadata include definitions for:

• tables
• columns
• descriptions
• primary keys
• foreign keys
• check constraints
• triggers
• views
• procedures/functions (name and parameters but not the code)

Important note: as already mentioned, the tool doesn’t provide fine grained tuning of archiving jobs: extraction scope is based on the security perimeter of the user performing the job, which metadata is unloaded is fixed by the tool and data is fully extracted (no way to filter with utility parameters).

That said, you can use the source database features to configure more fine grained behaviour, for instance by:

• creating a dedicated user
• defining user permissions tailored to the archiving scope defined
• creating views for column or row filtering purposes

To get an idea of how big an archive file can be when exporting a big table, we made a first test with a three columns table containing 26,300,300 rows and whose segment size is 50G: the archive file size is 27G. During the tests, other intermediary sizes were used for the table and each time, the archive file was a little more than 50% of the segment size.

What’s next

In upcoming blog posts, we will dive in the GUI interface and the various challenges encountered on real schemas.

L’article Archiving Oracle databases with SIARD Suite est apparu en premier sur dbi Blog.

In the context of Oracle Database Aplliances, you might need to remove an old Oracle Database Home (For instance 12c), while the ODA is already on a recent patch level.

For instance in my case : In an ODA patching operation, the appliance was already running 19.26 patchlevel On Oracle Linux 8.10, while an unused Oracle Database 12.2 home was still registered:

[root@server-oda1 ~]# odacli list-dbhomes

ID                                    Name               DB Version          DB Edition Home Location                                               Status
------------------------------------- ------------------ ------------------- ---------- ----------------------------------------------------------- ----------
de8c09c9-beaf-4a0d-937b-02cace2e0121 OraDB12201_home1   12.2.0.1.220118     EE         /u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1        CONFIGURED
a0d28b10-07a4-4c43-8504-751245ddd2c3 OraDB19000_home5   19.26.0.0.250121    EE         /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_5        CONFIGURED

No database was using the 12c home anymore, so it could safely be removed before continuing with the patching.

Let’s use the normal procedure :

[root@server-oda1 ~]# odacli delete-dbhome -i de8c09c9-beaf-4a0d-937b-02cace2e0121

The job fails almost immediately:

[root@server-oda1 ~]# odacli describe-job -i 8e725314-aaea-4f6a-bc7b-e820bb3ffbce

Job details
----------------------------------------------------------------
                     ID:  8e725314-aaea-4f6a-bc7b-e820bb3ffbce
            Description:  Database Home OraDB12201_home1 Deletion with ID de8c09c9-beaf-4a0d-937b-02cace2e0121
                 Status:  Running
                Created:  April 29, 2026 09:54:15 CEST
                Message:

Task Name                                Start Time                               End Time                                 Status
---------------------------------------- ---------------------------------------- ---------------------------------------- ----------------
Validate DB Home                         April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:15 CEST             Success
de8c09c9-beaf-4a0d-937b-02cace2e0121
for deletion

[root@server-oda1 diag]# odacli describe-job -i 8e725314-aaea-4f6a-bc7b-e820bb3ffbce

Job details
----------------------------------------------------------------
                     ID:  8e725314-aaea-4f6a-bc7b-e820bb3ffbce
            Description:  Database Home OraDB12201_home1 Deletion with ID de8c09c9-beaf-4a0d-937b-02cace2e0121
                 Status:  Failure (To view Error Correlation report, run "odacli describe-job -i 8e725314-aaea-4f6a-bc7b-e820bb3ffbce --ecr" command)
                Created:  April 29, 2026 09:54:15 CEST
                Message:  DCS-10001:Internal error encountered: PRGH-1010 : Removal of Oracle home /u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1 failed
PRCZ-4001 : failed to execute command "/u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1/deinstall/deinstall" using the privileged execution plugin "odaexec" on nodes "server-oda1" within 4,000 seconds
PRCZ-2103 : Failed to execute command "/u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1/deinstall/deinstall" on node "server-oda1" as user "oracle". Detailed error:
Checking for required files and bootstrapping ...
Please wait ...
Location of logs /u01/app/oraInventory/logs/

############ ORACLE DECONFIG TOOL START ############


######################### DECONFIG CHECK OPERATION START #########################
## [START] Install check configuration ##


Checking for existence of the Oracle home location /u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1
Oracle Home type selected for deinstall is: Oracle Real Application Cluster Database
Oracle Base selected for deinstall is: /u01/app/odaorabase/oracle
Checking for existence of central inventory location /u01/app/oraInventory
Checking for existence of the Oracle Grid Infrastructure home /u01/app/19.26.0.0/grid
The following nodes are part of this cluster: server-oda1
ERROR: null.

Task Name                                Start Time                               End Time                                 Status
---------------------------------------- ---------------------------------------- ---------------------------------------- ----------------
DbHome service deletion for              April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:30 CEST             Failure
de8c09c9-beaf-4a0d-937b-02cace2e0121
DbHome service deletion for              April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:30 CEST             Failure
de8c09c9-beaf-4a0d-937b-02cace2e0121
Validate DB Home                         April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:15 CEST             Success
de8c09c9-beaf-4a0d-937b-02cace2e0121
for deletion
Setting up SSH equivalence               April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:15 CEST             Success
Setting up SSH equivalence               April 29, 2026 09:54:15 CEST             April 29, 2026 09:54:15 CEST             Success
Deleting DB Home by RHP                  April 29, 2026 09:54:16 CEST             April 29, 2026 09:54:30 CEST             Failure

There are “harsh” solutions provided online, I would not talk about here, because I don’t want to spread risky stuff.

However, understanding the issue provides us with a “clean” workaround :

The important point here is that odacli delete-dbhome eventually calls the standard Oracle 12.2 deinstall utility.

And as you most probably already know, the 12c deinstallation stack prerequisite checks expects by default the Oracle Linux 7 version. and the well known CV_ASSUME_DISTID environment variable is usually used to fix that.

The Workaround

The workaround is exactly positionning the CV_ASSUME_DISTID to OL7 (Oracle Linux 7)

CV_ASSUME_DISTID=OL7

Because the deinstallation process is launched internally by odacli, simply exporting the variable in my current shell would not guarantee that it would be inherited by the process started by ODA.

I therefore added it directly to the 12c deinstall script:

[oracle@server-oda1 ~]# sed -i '1a export CV_ASSUME_DISTID=OL7' /u01/app/odaorahome/oracle/product/12.2.0.1/dbhome_1/deinstall/deinstall

This is obviously a workaround rather than a change that should be applied blindly to every environment. Before using it, make sure that the DB Home is no longer used by any database and that the failure is actually related to the legacy prerequisite checks.

Deleting the DB Home Again

After adding the environment variable, I simply restarted the ODA deletion:

[root@server-oda1 ~]# odacli delete-dbhome -i de8c09c9-beaf-4a0d-937b-02cace2e0121
Job details
----------------------------------------------------------------
                     ID:  21c05801-e3fb-4cdb-bf40-36e6dc1e0157
            Description:  Database Home OraDB12201_home1 Deletion with ID de8c09c9-beaf-4a0d-937b-02cace2e0121
                 Status:  Running
                Created:  April 29, 2026 09:57:01 CEST
                Message:

Task Name                                Start Time                               End Time                                 Status
---------------------------------------- ---------------------------------------- ---------------------------------------- ----------------
Validate DB Home                         April 29, 2026 09:57:01 CEST             April 29, 2026 09:57:01 CEST             Success
de8c09c9-beaf-4a0d-937b-02cace2e0121
for deletion
Setting up SSH equivalence               April 29, 2026 09:57:01 CEST                                                      Running

[root@server-oda1 diag]# odacli describe-job -i 21c05801-e3fb-4cdb-bf40-36e6dc1e0157

Job details
----------------------------------------------------------------
                     ID:  21c05801-e3fb-4cdb-bf40-36e6dc1e0157
            Description:  Database Home OraDB12201_home1 Deletion with ID de8c09c9-beaf-4a0d-937b-02cace2e0121
                 Status:  Success
                Created:  April 29, 2026 09:57:01 CEST
                Message:

Task Name                                Start Time                               End Time                                 Status
---------------------------------------- ---------------------------------------- ---------------------------------------- ----------------
Validate DB Home                         April 29, 2026 09:57:01 CEST             April 29, 2026 09:57:01 CEST             Success
de8c09c9-beaf-4a0d-937b-02cace2e0121
for deletion
Setting up SSH equivalence               April 29, 2026 09:57:01 CEST             April 29, 2026 09:57:01 CEST             Success
Setting up SSH equivalence               April 29, 2026 09:57:01 CEST             April 29, 2026 09:57:01 CEST             Success
Deleting DB Home by RHP                  April 29, 2026 09:57:02 CEST             April 29, 2026 09:57:49 CEST             Success

Finally, verify that the old Oracle Home is no longer registered in ODA:

[root@server-oda1 ~]# odacli list-dbhomes

ID                                    Name               DB Version          DB Edition Home Location
------------------------------------- ------------------ ------------------- ---------- ---------------------------------------------------
a0d28b10-07a4-4c43-8504-751245ddd2c3 OraDB19000_home5   19.26.0.0.250121    EE         /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_5

Conclusion

This issue is a good reminder of the importance of keeping Oracle Database Appliance environments up to date and within Oracle’s supported compatibility matrix.

When legacy Database Homes remain on an ODA that has already moved to a newer operating system and appliance software stack, compatibility gaps can appear and eventully cause issues.

L’article Deleting an Oracle 12c DB Home on a Recent ODA est apparu en premier sur dbi Blog.

With VirtualBox you can take snapshots of the current state (without snapshot functionality of a filesystem like btrfs)

This kind of snapshot will create a kind of differential file and the original file will be untouched.

$  ls -lh ol9.vdi Snapshots/\{dfef3efe-1a67-466d-b968-835d7c2c915b\}.vdi
-rw------- 1 mnb mnb 463M Sep 25 17:55 '/Snapshots/{dfef3efe-1a67-466d-b968-835d7c2c915b}.vdi'
-rw------- 1 mnb mnb 9.5G Sep 25 17:52  ol9.vdi

Every changed block is written to this difference file in the Snapshot/ directory.

If you will do tests with always the same starting point, and after the test you will go back to the snapshot (restore). For this scenario it is a good solution. Virtualbox only needs to delete the differential file.

But if you take a snapshot before an upgrade, and if it is successful, you will keep this state and delete the snapshot state. For this scenario, VirtualBox has to copy all the blocks from the differential file back to the original file (ol9.vdi), which can be very time-consuming after patching big software (e.g. the OS or Oracle database).

You can also clone a VM with VirtualBox. You have the choice of a full- and a linked-clone. The full clone will create an independent copy of the disk files. The linked clone is only a snapshot of the disks of the source VM. So, the original disk will no longer be changed, but the original and the cloned VM will have an individual differential file in Snapshots/

ol9/ol9.iso  # will no longer be changed
ol9/Snapshots/{xxxxxxxxxxx}.vdi
ol9clone/Snapshots/{xxxxxxxxxxx}.vdi

This type of clone we should only use for short-term usage. Create a snapshot of the production, do some tests, and afterwards, immediately delete it! But after deleting the clone, you have to do a cleanup with the original VM. On the original VM, the snapshot is not deleted! (if you forget to delete it, you will need more and more diskspace…)

But is there a better solution? Yes, if you are using Linux. Use filesystem based file-snapshots.

Snapshots with btrfs

Some Linux filesystems with snapshots

• OCFS2: I used it often in the past, it works very well, but is not widely used. It is a cluster filesystem, but it can also be used for single-hosts.
• OpenZFS: I never used it.
• btrfs: Available in most Linux distributions (*) with subvolume snapshots. In this blog post I will show the examples with btrfs.

(*) Btrfs is no longer included in RedHat Enterprise linux and 1:1 forks like Rocky Linux. With these distributions, you can use the kernel from https://elrepo.org/. I used the “ml” Kernel and it worked well.
In Fedora (the development release of RedHat) btrfs is included. That means, there are political, not technical reasons that RedHat no longer delivers the modules for btrfs…
In Oracle Linux OL (also a RedHat fork) it is available with the UEK-kernel (a more modern Kernel than the RedHat Kernel). OL is freely available at https://yum.oracle.com.
SuSE uses btrfs as the default root filesystem.

A good overview of btrfs you will get with this SuSE article.

Your VMs are located in a directory. If you create a VM, you will specify the name and a directory (VM Folder)

Then, it creates the VM (virtual disks and configuration file) in the subdirectory /u00/virtualbox/vm1/

Snapshots with btrfs works with subvolumes. For us, for the application, a subvolume is visible as a directory. We can mount such a subvolume separately. And important for our use-case: we can create a snapshot of a subvolume.

[root@ltp14 virtualbox]  btrfs subvolume list .
ID 264 gen 1015763 top level 5 path virtualbox/olvmm01
ID 289 gen 1015763 top level 5 path virtualbox/winxp_2023-06-26
ID 290 gen 1015763 top level 5 path virtualbox/winxp
ID 292 gen 1015783 top level 5 path virtualbox/ol9
ID 307 gen 1015763 top level 5 path virtualbox/ubuntu2204
ID 354 gen 1015763 top level 5 path virtualbox/ol9a
ID 362 gen 1015763 top level 5 path virtualbox/ol9b

As you can see, most of my VMs are installed in subvolumes. I created a master image ol9, and ol9a and ol9b are snapshots of ol9 used for the “clone” functionality. And from my good old winxp installation i created a snapshot winxp_2023-06-26 which can be used similar to the “Snapshot” of virtualbox.

Difference of VirtualBox and btrfs

But what is the difference? As we have seen before, VirtualBox stores changed blocks in a separate file. If we access a virtual disk, we have to access 2 files. First check, if the block is in the snapshot file, and if not, take the unchanged block from the (no longer changed) original.

Btrfs is a copy-on-write filesystem. If we change a block, it will not change the current block on disk, instead, it allocates a new block and releases the old one. In case a snapshot exists, it will not release the old block as long as it is assigned in another snapshot.

[root@ltp14 virtualbox]  btrfs subvolume snapshot vm1 vm2

After we created the subvolume vm2 as a snapshot of subvolume vm1, fileA in both subvolumes share the same disk blocks, which is recorded in the inodes (mapping table between file and disk blocks). Of course, we can rename one of “FileA”, its inode assignment remains unchanged. If you update block 3 and 4 of fileA in vm1, then 2 new blocks are allocated (green, orange). If you update block 4 in vm2, then also a new block (light blue) is allocated and the old block (with white “x”) is deallocated (unused) because it is no longer allocated in any other snapshot.

For us, for the application, there are 2 independent files. There is no “original” and a snapshot file.

Snapshots

Subvolumes

Now, let’s see how to replace VirtualBox snapshot functionality by btrfs snapshots. Fist of all, we need a subvolume of our VM. Unfortunately, we can not convert an existing directory directly to a subvolume. We have to move the files in a subvolume.

[root@ltp14 virtualbox]  btrfs subvolume create vm1sub
Create subvolume './vm1sub'
[root@ltp14 virtualbox]  chown mnb:mnb vm1sub/  #subvols are created as root
[root@ltp14 virtualbox]  mv -v vm1/* vm1sub/
copied 'vm1/vm1.nvram' -> 'vm1sub/vm1.nvram'
removed 'vm1/vm1.nvram'
copied 'vm1/vm1.vbox' -> 'vm1sub/vm1.vbox'
removed 'vm1/vm1.vbox'
copied 'vm1/vm1.vbox-prev' -> 'vm1sub/vm1.vbox-prev'
removed 'vm1/vm1.vbox-prev'
copied 'vm1/vm1.vdi' -> 'vm1sub/vm1.vdi'
removed 'vm1/vm1.vdi'
[root@ltp14 virtualbox]  rmdir vm1
[root@ltp14 virtualbox]  mv vm1sub vm1
[root@ltp14 virtualbox]  btrfs subvolume list . |grep vm1
ID 367 gen 1016224 top level 5 path virtualbox/vm1
[root@ltp14 virtualbox]

Afterwards, we can use the VM as before.

Create a snapshot

Now we will create a snapshot of it. Ideally we stop it before the snapshot. If we snapshot a running VM, there may be some application inconsistencies. For Oracle databases, do an “alter database begin backup” before and end backup afterwards keeping the database recoverable. What we can not do with btrfs, is the snapshot of the memory, so we can not restore it “running”. VirtualBox can do that, but it is not “online”, Our VM is freezed during the time of the snapshot.

[root@ltp14 virtualbox]   sudo -u mnb vboxmanage controlvm vm1 shutdown  #or poweroff
[root@ltp14 virtualbox]  time  btrfs subvolume snapshot vm1 vm1_snap01
Create snapshot of 'vm1' in 'vm1_snap01'

real    0m0.030s
user    0m0.000s
sys     0m0.016s
[root@ltp14 virtualbox]  sudo -u mnb vboxmanage startvm vm1

Delete a snapshot

To delete a snapshot means, remove the subvolume of the old state. The big advantage compared to VirtualBox is, that we do not have to wait until the changed blocks are copied back in the “original” file. With btrfs, this is done “online” without influence of our running VM.

[root@ltp14 virtualbox]  btrfs subvolume delete vm1_snap

Restore a snapshot

To restore a snapshot means, renaming the subvolumes:

[root@ltp14 virtualbox]  sudo -u mnb vboxmanage controlvm vm1 poweroff
[root@ltp14 virtualbox]  mv vm1 vm1_bck
[root@ltp14 virtualbox]  btrfs subvolume snapshot vm1_snap01 vm1  #now the vm can be restarted
[root@ltp14 virtualbox]  btrfs subvolume delete vm1_bck  # (*)
Delete subvolume 367 (no-commit): '/u00/virtualbox/vm1_bck'

(*) in VirtualBox restoring a snapshot asks for “Create a snapshot of the current machine state” De-selecting this option is similar to delte the subvolume. And instead of “Create a snapshot…”, simply keep the renamed subvolume.

The “delete” snapshot of VirtualBox is equivalent to delete the current subvolume and rename the old subvolume back to the original name.

[root@ltp14 virtualbox]  sudo -u mnb vboxmanage controlvm vm1 poweroff
[root@ltp14 virtualbox]  btrfs subvolume delete vm1_snap
[root@ltp14 virtualbox]  mv vm1_snap vm1

Clone

The next subject is to clone a VM. I will demonstrate that by creating a master/template VM of Oracle Linux 10 (OL10) and then to create clones of it for different purposes.

Create a master VM

To define the VM you can start with the VirtualBox GUI. That will create the definition and an empty virtual disk. As described above, we will move it afterwards to a subvolume, then install and configure OL10 like every other VM.

After you have prepared the VM as a master-VM, that means you have installed all software you need in each clone, especially the VirtualBox tools, stop it and create clones.

Create a new VM from the master-VM

From the point of view of virtualbox, we create a full clone. From the point of view of the filesystem, it is similar to a linked clone (each VM stores its own modified blocks. But the old blocks are released when both VM’s have changed these blocks).

We create a subvolume ol10a from ol10, then we remove all files in ol10a, except the disk image. This, we rename to ol10a.vdi. VirtualBox tracks the file by an uuid, so we have to set a new uuid for the cloned disk.

Tip: look at the space consumption before and after cloning (df -k).

[root@ltp14 virtualbox]   btrfs subvolume snapshot ol10 ol10a
Create snapshot of 'ol10' in 'ol10a'
[root@ltp14 virtualbox]  cd ol10a/
[root@ltp14 ol10a]  ls -l
total 3383436
drwx------ 1 mnb mnb         16 Sep 28 11:55 Logs
-rw------- 1 mnb mnb       4138 Sep 28 12:58 ol10.vbox
-rw------- 1 mnb mnb       6432 Sep 28 12:55 ol10.vbox-prev
-rw------- 1 mnb mnb 3466592256 Sep 28 12:58 ol10.vdi
[root@ltp14 ol10a]   rm -f *.vbox* Logs/*
[root@ltp14 ol10a]   mv ol10.vdi ol10a.vdi
[root@ltp14 ol10a]   VBoxManage internalcommands sethduuid /u00/virtualbox/ol10a/ol10a.vdi
UUID changed to: 81927ab2-e2ac-4143-9077-98af702ec82d

Afterwards, you can create a new VM with the GUI. But do not create an new disk. Attach the existing cloned disk.

You can also create the VM on commandline which is recommended if you need many clones. You can do it with your useraccount, or if you prefer to do all steps as root, with “sudo -u your_username”. First, create the VM, then attach/modify the desired virtual hardware (disk-controllers, ram, cpus, network, and attach the cloned virtual disk to a controller).

root@ltp14 ol10a]  sudo -u mnb  VBoxManage  createvm --name ol10a --basefolder /u00/virtualbox/ol10a --register
Virtual machine 'ol10a' is created and registered.
UUID: d983c059-2e2f-4e89-bad0-fd3676d567c7
Settings file: '/u00/virtualbox/ol10a/ol10a/ol10a.vbox'
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage modifyvm ol10a --memory 4096 --cpus 2 --ostype Oracle10_64 --vram 4
[root@ltp14 ol10a]  sudo -u mnb VBoxManage storagectl ol10a --name "SATA Controller" --add sata --controller IntelAhci
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage storagectl ol10a --name "IDE Controller" --add ide --controller PIIX4
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage storageattach ol10a --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium /u00/virtualbox/ol10a/ol10a.vdi
[root@ltp14 ol10a]  sudo -u mnb   VBoxManage modifyvm ol10a --nic1 hostonly --hostonlyadapter1 vboxnet0
[root@ltp14 ol10a]  sudo -u mnb VBoxManage modifyvm ol10a --nic2 nat

Now you are ready to boot your cloned VM ol10a. This can be done from commandline (as your user) or in the VirtualBox GUI. After booting, log in and change immediately the hostname. Afterwards, adapt the clone for your needs.

hostnamectl hostname ol10a

L’article Snapshots with VirtualBox and btrfs est apparu en premier sur dbi Blog.

But when migrating a database or just performing the initial load of a single table to prepare a GoldenGate replication, the known procedure is very often still the old one: start an extract, note down an SCN, run expdp with FLASHBACK_SCN=<that SCN>, import the data on the target, and finally start a replicat with the AFTERCSN clause.

It takes a long time to get used to new habits, so let’s refresh your memory, explaining how instantiation CSN work in GoldenGate.

Historic FLASHBACK_SCN + AFTERCSN initial load

Historically, precise instantiation of a table worked like this:

• START EXTRACT. It is the first step, to ensure that no transaction is lost.
• Wait for long running transactions to be committed.
• Select an SCN, which should not be prior to the registration SCN of the extract.
• Export the data with expdp ... FLASHBACK_SCN=<scn> so the dump is consistent.
• Import the data with impdp on the target.
• Start the replicat with the AFTERCSN <csn> clause, so the replicat does not replicate anything committed at or before the instantiation CSN.

While still perfectly valid, and even necessary under certain conditions, this method becomes hard to operate on complex replications or when the size of the database increases:

• UNDO retention: very often, using the FLASHBACK_SCN clause will generate ORA-01555: snapshot too old errors.
• Splitting the initial load is not possible, since the AFTERCSN clause will apply on the whole replicat.

Instantiation CSN in practice

GoldenGate instantiation CSN provides a simple solution: a per table instantiation CSN, on the target database, instead of a single one applied on the replicat.

This instantiation CSN is stored on the target database in the DBA_APPLY_INSTANTIATED_OBJECTS table, with one row per source object.

SET PAGES 100 LINES 200
COL source_object_owner FORMAT A20
COL source_object_name FORMAT A30
COL instantiation_scn FORMAT 999999999999999
SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
ORDER BY 1, 2;

This table is populated by Data Pump, and is then read by GoldenGate. When applying changes, a replicat will compare the commit CSN of a record to the table’s instantiation CSN. If the commit CSN is higher, the transaction will be discarded.

Because the comparison is done for every table, there is no need for them to share one instantiation CSN using FLASHBACK_SCN.

Why FLASHBACK_SCN is no longer required

The instantiation CSN is the read-consistent SCN as of which Data Pump reads the table during export. It is stored in the dump and imported on the target when using impdp. It does not come from when the source table is prepared with PREPARECSN. PREPARECSN is what makes the table eligible for instantiation CSN.

Let’s see the difference with three different scenarios:

• Standard initial load without FLASHBACK_SCN
• Historic method with FLASHBACK_SCN
• Instantiation with PREPARECSN NONE

I will use the same two tables, HR.EMPLOYEES and HR.DEPARTMENTS.

ENABLE_INSTANTIATION_FILTERING vs ATCSN/AFTERCSN

Before running the three scenarios, here is what the instantiation filtering replaces:

1. Prepare the tables on the source

Using ADD SCHEMATRANDATA, we will start by preparing the table on the source. The full clause is ADD SCHEMATRANDATA <schema_name> PREPARECSN {WAIT | LOCK | NOWAIT | NONE}, and NOWAIT is the default. In other words, ADD SCHEMATRANDATA prepares tables for instantiation whether you include PREPARECSN or not.

OGG> DBLOGIN USERIDALIAS gg_source DOMAIN OracleGoldenGate
OGG> ADD SCHEMATRANDATA HR
2026-07-26 09:41:07  INFO    OGG-01788  SCHEMATRANDATA has been added on schema HR.
2026-07-26 09:41:07  INFO    OGG-10154  Schema level PREPARECSN set to mode NOWAIT on schema HR.

If you do not want instantiation CSN filtering for a schema, you can opt out explicitly with ADD SCHEMATRANDATA HR PREPARECSN NONE. It is the only way to get a table with zero rows in dba_apply_instantiated_objects after a load. Everything else on this page happens by default.

The full clause, PREPARECSN {WAIT | LOCK | NOWAIT | NONE}, controls how invasive the preparation is on a live table:

For an OLTP table with a lot of concurrent DML, WAIT or LOCK can stall application sessions while GoldenGate waits for or takes the lock. NOWAIT is almost always the correct option.

Confirm both tables are prepared:

OGG> INFO SCHEMATRANDATA HR
Schema HR has 2 prepared tables for instantiation.

2. Start the extract

Capture has to be running before the export, so that any change committed during and after the dump is safely in the trail:

OGG> START EXTRACT EXTA

3. Wait for long running transactions to finish

A transaction that began before the extract could be missed, so wait for every long running transaction to finish before exporting. See Checking Long Running Transactions in GoldenGate for how to list them with the adminclient and the REST API.

4. Export without FLASHBACK_SCN

expdp hr/*** dumpfile=hr.dmp schemas=HR

Without the FLASHBACK_SCN clause, each table’s boundary will be the SCN as of which Data Pump reads it during the export, recorded automatically because the table was prepared with PREPARECSN.

5. Import on the target

impdp gg_target/*** dumpfile=hr.dmp full=y

As part of this import, Data Pump populates dba_apply_instantiated_objects for every prepared table it loads. No extra option is needed.

6. Retrieve the instantiation CSN for each table

Let’s query the table that replaces the SCN you used to write down by hand:

SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'HR'
ORDER BY 1, 2;

SOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN
-------------------- ------------------- -----------------
HR                   DEPARTMENTS                  17662585
HR                   EMPLOYEES                    17662582

The two tables come from the same export, but with two different INSTANTIATION_SCN. Without FLASHBACK_SCN on the export, each table was read (and stamped) at its own point as the dump progressed. That per-table granularity is the entire point, and it is exactly what a single AFTERCSN could never express.

7. Configure the replicat and start it, without AFTERCSN

REPLICAT REPA
DBOPTIONS ENABLE_INSTANTIATION_FILTERING
USERIDALIAS gg_target DOMAIN OracleGoldenGate
MAP HR.*, TARGET HR.*;

OGG> START REPLICAT REPA

DBOPTIONS ENABLE_INSTANTIATION_FILTERING tells the replicat to look each table’s boundary in dba_apply_instantiated_objects instead of expecting an AFTERCSN on the start command. The replicat discards trail records committed at or before its own boundary and applies everything after it. Both tables are in sync with the source, with no flashback SCN ever chosen.

Same initial load with FLASHBACK_SCN

Let’s run the same initial load again for a second schema, but add FLASHBACK_SCN to the export and watch what changes in the instantiation table. Pick an SCN and pass it to expdp:

expdp system/*** schemas=HR2 flashback_scn=17663448 dumpfile=hr2.dmp
impdp system/*** dumpfile=hr2.dmp full=y

Then the same step 6 query against the target:

SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'HR2'
ORDER BY 1, 2;

SOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN
-------------------- ------------------- -----------------
HR2                  DEPARTMENTS                  17663448
HR2                  EMPLOYEES                    17663448

This time, both tables carry the same instantiation CSN, and it is exactly the FLASHBACK_SCN (17663448). FLASHBACK_SCN pins the whole export to one consistent point in time, so Data Pump stamps every table in the dump with that single SCN. Please note that FLASHBACK_SCN is still not required for the instantiation mechanism to work. It only gives a consistent export.

Same initial load with PREPARECSN NONE

Let’s see what happens when we disable instantiation, by preparing a third schema with PREPARECSN NONE and run the same export and import:

OGG> ADD SCHEMATRANDATA HR3 ALLCOLS, PREPARECSN NONE
INFO OGG-10154  Schema level PREPARECSN set to mode NONE on schema "HR3"
OGG> INFO SCHEMATRANDATA HR3
Schema "HR3" has 0 prepared tables for instantiation

expdp system/*** schemas=HR3 dumpfile=hr3.dmp
impdp system/*** dumpfile=hr3.dmp full=y

The import succeeds and the rows land on the target as normal, but the instantiation table stays empty for this schema:

SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'HR3';

no rows selected

In that case, a replicat running with DBOPTIONS ENABLE_INSTANTIATION_FILTERING would find no boundary for these tables and therefore would not filter them. It would apply every trail record it sees, including changes the dump already contains.

The boundary outlives the schema

dba_apply_instantiated_objects is independent from the schema it describes. Dropping the target schema with DROP USER ... CASCADE and recreating it does not clear its row:

SQL> DROP USER hr4 CASCADE;

User dropped.

SQL> CREATE USER hr4 IDENTIFIED BY Welcome1;

User created.

SQL> SELECT source_object_owner, source_object_name, instantiation_scn
     FROM dba_apply_instantiated_objects WHERE source_object_owner='HR4';

SOURCE_OBJECT_OWNER  SOURCE_OBJECT_NAME  INSTANTIATION_SCN
-------------------- ------------------- -----------------
HR4                  EMPLOYEES                    52356545

A stale boundary from a previous initial load can silently attach itself to the next import of an object with the same name. The same table, re-imported a second time from a dump whose source was never prepared with PREPARECSN, does not delete the row from the first prepared initial load.

A replicat with ENABLE_INSTANTIATION_FILTERING reading this table afterward would filter every record against a boundary that has no relationship to what the last import actually put on the target.

A command exists in the adminclient to clear the instantiation table:

OGG> DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate
OGG> CLEAR INSTANTIATION CSN FOR hr.employees FROM PDB_SOURCE
INFO OGG-10464  Instantiation CSN has been cleared successfully.

SQL> SELECT source_object_owner, source_object_name, instantiation_scn
     FROM dba_apply_instantiated_objects WHERE source_object_owner='HR';
no rows selected

Remember to check the dba_apply_instantiated_objects view before reusing a target schema name for an initial load.

When should I still set instantiation SCN by hand ?

There are multiple scenarios where automatic instantiation filtering does not work.

• If your initial load is not done by Data Pump. GoldenGate initial extract, a manual INSERT ... SELECT over a database link, transportable tablespaces, do not alter the dba_apply_instantiated_objects view.
• If the workload during the initial load is not just DML. Instantiation filtering does not work on DDL, for instance.

In that case, you can either go back to the FLASHBACK_SCN method, or set the instantiation CSN by hand in the adminclient:

OGG> DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate
OGG> SET INSTANTIATION CSN FOR hr.legacy_orders CSN 12345678 FROM PDB_SOURCE

Common questions

A table added after PREPARECSN never gets a boundary

If a table is created on the source after you ran ADD SCHEMATRANDATA HR, it is not part of that preparation. Exporting it later with expdp means Data Pump has no CSN bookkeeping to carry into the dump, and dba_apply_instantiated_objects is not populated during import. The fix is to run ADD TRANDATA ... before exporting it.

Removing the parameter once instantiation is complete

DBOPTIONS ENABLE_INSTANTIATION_FILTERING can be removed from the replicat parameter file once it has processed every transaction past the instantiation CSN of every table it maps (there is no harm in leaving it in indefinitely).

Summary

• The instantiation CSN is a per-table replication boundary, stored in dba_apply_instantiated_objects on the target, compared against each record’s commit CSN.
• Data Pump stamps it automatically on impdp, because ADD SCHEMATRANDATA/ADD TRANDATA prepare tables for instantiation by default (PREPARECSN NOWAIT). Use PREPARECSN NONE to not use instantiation SCN.
• Because that boundary is per table and set by Data Pump, FLASHBACK_SCN and AFTERCSN are no longer needed just to define where the dump ends and replication begins. Retrieve the boundary with a query instead of tracking an SCN by hand.
• FLASHBACK_SCN still has a use (making one large export internally consistent), but it is no longer needed just to drive the replication boundary. Data Pump records that boundary either way.
• The boundary outlives the schema it describes. Dropping and recreating a target schema does not clear its row in dba_apply_instantiated_objects. Check the view, and use CLEAR INSTANTIATION CSN if you see stale rows.

L’article GoldenGate Instantiation CSN Explained est apparu en premier sur dbi Blog.

New AI Service in GoldenGate 26ai

The AI Service is a Service Manager-level microservice, not a deployment-level one. Extract, replicat, Distribution and Receiver services belong to a deployment. The AI Service belongs to the Service Manager and is shared by every deployment on the host.

If you already use GoldenGate 26ai, you probably know that the AI Service has its own binary:

[oracle@vmogg bin]$ ps -ef|grep AIService
oracle     60905   60721  0 20:50 ?        00:00:00 /u01/app/oracle/product/ogg_23.26.3.0.3/bin/AIService

The AI Service holds two kinds of objects:

• Providers (one per external AI service): a base URL and authentication details.
• Models (one per embedding model you want to call): attached to a provider.

None of this is stored in a deployment. This means that when configuring the AI Service, you only need to configure it once for all your deployments. It also means that every deployment can access every AI model you register.

Four providers are supported with GoldenGate 26ai: Google Gemini, OpenAI, OCI Generative AI and Voyage AI. They can all do the same thing with GoldenGate. On top of this, you can also configure local models.

Getting a free Gemini API key

The first step when setting up a Gemini AI Service in GoldenGate is to retrieve the Gemini API key. You can create one for free in Google AI Studio, at aistudio.google.com/apikey:

• Sign in with a Google account and open the API keys page.

• Click on Create API key.

• Copy the key.

There are two things you should know before using this key for GoldenGate.

• Every Gemini API key is associated with a Google Cloud project. If you have multiple projects, make sure to select a project where the Gemini API is enabled (see below):

• Check the rate limits at aistudio.google.com/rate-limit before sizing anything. Requests per minute, tokens per minute or requests per day are all important metrics that you should keep an eye on.

On the free tier, the daily request will most likely be the limited factor. But if the data you are embedding is large, you will be affected by the tokens limit.

For a lab, the default project and the key you just created are enough. For anything else, create the key in a dedicated Google Cloud project so quota and billing are isolated. A key created through AI Studio is already restricted to the Gemini API by default, so there is nothing extra to configure there.

GoldenGate prerequisites before using the AI Service

• Outbound connectivity: An HTTP proxy should be used for an AI service outside your network. If your GoldenGate host reaches the Internet through one, set HTTPS_PROXY from the Service Manager Configuration page (in Deployments > ServiceManager > Configuration), as an Environment Variable.

• CA certificates: Oracle requires the use of CA certificates when connecting to any AI service provider, so the provider’s TLS chain has to be trusted by the Service Manager. Pull the chain with the following command:

openssl s_client -showcerts -connect generativelanguage.googleapis.com:443

Then, add the CA certificates from the Service Manager certificate management page. The procedure is described in a blog about registering certificate in GoldenGate from the web UI. If you skip this step, you will receive the following error when trying to use the AI Service from a replicat:

2026-09-12T08:20:54.578+0000  WARNING OGG-30679  Oracle GoldenGate Delivery for Oracle, REPAI.prm:  Response from EMBED endpoint using model gemini_embed returned error: code REMOTE_INFERENCE_FAILED, message 'SSL connection unexpectedly closed'.

Registering the provider

Again, everything happens in the Service Manager web UI.

• Log in to the Service Manager and open the AI Service page.

• In the Providers section, click + and pick the provider type. For this blog, we will use Gemini. Fill in the form and submit.

For Gemini, you just need a URL and a key:

Keep the base URL, ending with /v1beta. Gemini embedding calls are a POST to /v1beta/models/<model>:embedContent, so the model-specific part of the path belongs to the model definition, not the provider.

Registering the model

Still on the same AI Service page, in the Models section, click +, fill in the form and submit:

Here is the meaning of each name given above:

• Remote Model Name is the name known by the provider.
• Model ID is what will be used in the replicat when using @AISERVICE.
• Model Name is just there for you to organize your models.

gemini-embedding-001 is the current general embedding model from Google. It defaults to 3072 dimensions and accepts anything from 128 to 3072 through the request’s output_dimensionality, with 768, 1536 and 3072 as the recommended values. Querying the model directly (GET /v1beta/models/gemini-embedding-001) gives its input limit:

{
    "name": "models/gemini-embedding-001",
    "inputTokenLimit": 2048,
    "outputTokenLimit": 1,
    "supportedGenerationMethods": [
        "embedContent",
        "countTextTokens",
        "countTokens",
        "asyncBatchEmbedContent"
    ]
}

One note on Maximum Input Characters: when I write these lines (September 2026, version 23.26.3), I still have an ongoing support request with Oracle about this parameter. The description of the parameter is straightforward, but the feature does not work. No matter the size of the input, everything will be passed to the AI Service, and to the AI model. This means that you could very quickly reach token limits if you don’t pay attention. Until this bug is resolved, do not expect this feature to work as intended.

Once a provider is enabled, the AI Service appears in the Services list on the Service Manager home page, the models become visible under the AI Service entry of the Microservices portal navigation, and they show up on a replicat’s Parameters page.

Calling Gemini from a GoldenGate replicat

Here is the syntax for the AISERVICE:

@AISERVICE(embed, <model_id>, <column_name>)

Three arguments are needed:

• The capability, embed, is the only option available for now.
• The Model ID, as registered in the AI Service (not the Model Name!)
• One source column. It cannot be a concatenation of columns. If you try to pass first_column || ' ' || second_column through the AI Service, you will get this error:

2026-09-12 08:00:12  WARNING OGG-30081  Error in COLMAP clause. Invalid column mapping function or argument found in the COLMAP clause..
..._embed', name || ' - ' || desc...
                 ^.
2026-09-12 08:00:12  ERROR   OGG-00919  Error in COLMAP clause.

Here is an example of a replicat parameter file using AISERVICE:

REPLICAT repai
USERIDALIAS target_pdb26 DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP PDB1.APP_PDB1.products, TARGET PDB26.APP_PDB26.products,
COLMAP (
    USEDEFAULTS,
    desc_vector = @AISERVICE(embed, 'gemini_embed', description));

The target column has to exist first

If you edit an existing replicat file to add an embedding, you must create the column on the target first. The AI Service will not create it. The column should be an Oracle VECTOR, and its dimension count has to match what the model returns.

ALTER TABLE app_pdb26.products
ADD (desc_vector VECTOR(3072, FLOAT32));

Using the default output of gemini-embedding-001 gives VECTOR(3072, FLOAT32). The dimension shouldn’t be changed later.

OGG-30679 when the key is wrong

Registering a provider or a model with a bad key produces no error at all, since nothing calls the provider at that point. Starting a replicat does not call it either, if there is no data waiting to be applied. It only happens when an @AISERVICE mapping processes a row.

An invalid key comes back as HTTP 400, not 401, with API_KEY_INVALID in the details. This is the full record from ggserr.log:

2026-09-12T09:26:59.205+0000  WARNING OGG-30679  Oracle GoldenGate Delivery for Oracle, REPAI.prm:  Response from EMBED endpoint using model gemini_badkey_model returned error: code REMOTE_INFERENCE_FAILED, message 'HTTP 400 - Bad Request: {
    "error": {
        "code": 400,
        "message": "API key not valid. Please pass a valid API key.",
        "status": "INVALID_ARGUMENT",
        "details": [
        {
            "@type": "type.googleapis.com/google.rpc.ErrorInfo",
            "reason": "API_KEY_INVALID",
            "domain": "googleapis.com",
            "metadata": {
            "service": "generativelanguage.googleapis.com"
            }
        },
        {
            "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
            "locale": "en-US",
            "message": "API key not valid. Please pass a valid API key."
        }
        ]
    }
    }
    '.

An OGG-30679 error also happens when a key is in a Google Cloud project which has not enabled the Generative Language API. This returns PERMISSION_DENIED (403). Here is the full ggserr.log record:

2026-09-12T09:27:16.666+0000  WARNING OGG-30679  Oracle GoldenGate Delivery for Oracle, REPAI.prm:  Response from EMBED endpoint using model gemini_noaccess_model returned error: code REMOTE_INFERENCE_FAILED, message 'HTTP 403 - Forbidden: {
    "error": {
        "code": 403,
        "message": "Gemini API has not been used in project 293237196494 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/generativelanguage.googleapis.com/overview?project=293237196494 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
        "status": "PERMISSION_DENIED",
        "details": [
        {
            "@type": "type.googleapis.com/google.rpc.ErrorInfo",
            "reason": "SERVICE_DISABLED",
            "domain": "googleapis.com",
            "metadata": {
            "serviceTitle": "Gemini API",
            "consumer": "projects/293237196494",
            "containerInfo": "293237196494",
            "activationUrl": "https://console.developers.google.com/apis/api/generativelanguage.googleapis.com/overview?project=293237196494",
            "service": "generativelanguage.googleapis.com"
            }
        },
        {
            "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
            "locale": "en-US",
            "message": "Gemini API has not been used in project 293237196494 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/generativelanguage.googleapis.com/overview?project=293237196494 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
        }
        ]
    }
    }
    '.

When registering a model/provider, you will not get an error if it is not correctly configured. Running a replicat with an @AISERVICE mapping is the only test which can validate your model registration.

Replication example

Here is an EXTAI/REPAI replication example, inserting into APP_PDB26.products_src on the source:

INSERT INTO app_pdb26.products_src (id, name, description)
VALUES (9701, 'GoldenGate 26ai Live Demo Mug', 'A ceramic mug for GoldenGate engineers, printed with the AI Service architecture diagram.');
COMMIT;

On the target, a VECTOR(3072, FLOAT32) column is populated by Gemini:

SELECT id, name, VECTOR_DIMS(desc_vector) AS dims FROM app_pdb26.products WHERE id = 9701;

        ID NAME                            DIMS
---------- ------------------------------ -----
      9701 GoldenGate 26ai Live Demo Mug   3072

# Vector content
[-1.34540349E-002,1.69963725E-002,2.44766194E-002,-6.56813234E-002,-5.2943374E-003,-2.17550527E-003,1.45018185E-002,-1.24750044E-002,1.46362577E-002,...

The vector has 3072 dimensions, matching the default output of gemini-embedding-001.

To summarize

To set up Gemini in GoldenGate 26ai, you need to:

1. Create the API key at aistudio.google.com/apikey. The project must have the Gemini API enabled.
2. Set HTTPS_PROXY for the Service Manager if the host goes out through a proxy, and register the provider’s CA chain in the Service Manager.
3. Add the provider in AI Service, with the base URL https://generativelanguage.googleapis.com/v1beta and the API key.
4. Add the model, with gemini-embedding-001 as the Remote Model Name
5. Add the VECTOR column to the target table before altering the replicat parameter file, sized based on the dimension of the model output.
6. Add one COLMAP line, USEDEFAULTS and col = @AISERVICE(embed, <model_id>, <column_name>), with a single column as the third argument.
7. Apply one row and check the target column. Until this happens, you cannot be sure that your replicat will behave as intended.

L’article GoldenGate 26ai AI Service: Full Setup With a Free Gemini Key est apparu en premier sur dbi Blog.

You are using 2 or more LDAP servers for Oracle name resolution to be highly available?
Do you kown what happens if an ldap server is down or not reachable? You probably expect that it tries the next one?

Short answer: Yes, but probably not with a behavior you expect…

Let’s see my test configuration There are 2 ldap servers ol9a and ol9b. For the setup, see my former blog post: Setup an LDAP server for Oracle naming on Enterprise Linux 9

# ldap.ora
DIRECTORY_SERVERS=(ol9a:389:636,ol9b:389:636)
DEFAULT_ADMIN_CONTEXT = "dc=dbi-services,dc=com"
DIRECTORY_SERVER_TYPE = OID

# sqlnet.ora
NAMES.DEFAULT_DOMAIN=dbi-services.com
NAMES.DIRECTORY_PATH=(LDAP)

With NAMES.DIRECTORY_PATH=(LDAP) we enforce to only use LDAP. Often, you will allow other methods like (LDAP,TNSNAMES,EZCONNECT). Oracle tries the name resolution in this order.

Tests with an Oracle client installation (tnsping)

Now let’s see what happens if ldap is not reachable. Note the difference: “server” refers to the ldap server process, “host” refers to the machine on which the ldap server runs (If the server is up, then logically the host is also up). “down” of a host is from the Oracle-client’s point of view and means that it is unreachable (will not respond), regardless of whether it is a host problem or just a network interruption. “1st” means the 1st host/server in the DIRECTORY_SERVERS parameter (in the example ora9a).

time tnsping DB1970

We remember: the order is DIRECTORY_SERVERS=(ol9a:389:636,ol9b:389:636)

Both up

If both ldap servers are up, we get an answer in a fraction of a second (as expected).

2nd down

If the 2nd server/host (ora9b) is down, we get an answer in a fraction of a second. I repeated this test several times, and it always responds immediately. That means, there is no round-robin selection of the servers in place.

1st down

if the 1st ldap server on ora9a is down (the process, not the host), we get the answer within a fraction of a second from ora9b. the Oracle client immediately detects that there is no ldap server running (error “Connection refused” on ldap port).

But if the host itself does not respond (stopped, network interruption), then the Oracle client has to wait for a timeout and that is usually more than 10 seconds. Did you expect that? Most customers have never noticed this problem as they have never had an LDAP host failure.

Used LDAP adapter to resolve the alias
Attempting to contact (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=ltp14s-i)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=DB1970A.erfinder)))
OK (30 msec)

real    0m15.090s

Is that acceptable for your application to wait for >10 seconds? For an interactive login once a day, it is annoying, but probably OK. But with applications that make thousands of short-term logins? In the worst case, the application will get a timeout.

Configuration optimization

Can we get around this long timeout? Yes, we can. Add the following parameter to sqlnet.ora:

NAMES.LDAP_CONN_TIMEOUT=1  #value in seconds

time tnsping db1970

TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 18-SEP-2026 16:46:37

Copyright (c) 1997, 2019, Oracle.  All rights reserved.

Used parameter files:
/u00/app/oracle/network/admin/ldap/sqlnet.ora

Used LDAP adapter to resolve the alias
Attempting to contact (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=ltp14s-i)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=DB1970A)))
OK (10 msec)

real    0m1.040s

Note: the timeouts may have some variations (after a few calls, the timeout was reduced to about 3 seconds for me).
The value OK (10 msec) refers only to the time for the listener connect, not for the name resolution. The output of time includes the total time of the tnsping execution.

Conclusion:

• We can configure the ldap failover timeout in seconds. Minimum is 1 second, default seems to be 10-15 sec.
• Timeouts only happen when the host is unreachable, not when the LDAP server (software) is stopped.
• LDAP servers are used in the order of the DIRECTORY_SERVERS parameter. There is no round-robin for load-balancing.

Tests with Java/JDBC

To do the tests with Java jdbc, I will use Oracle’s SQL Developer .

I create a new connection using “Custom JDBC” and add the following string:

jdbc:oracle:thin:@ldap://ol9a:389/DB1970,cn=OracleContext,dc=dbi-services,dc=com ldap://ol9b:389/DB1970,cn=OracleContext,dc=dbi-services,dc=com

The behavior is like before. But wait… it isn’t!
I have now noticed that the ldap servers are used round-robin. Sometimes the connect is instantaneous, sometimes it takes the time of the timeout to failover to the other server.

The jdbc:thin driver does not use our sqlnet.ora settings. So how can we configure this in Java? Fortunately there is a connection property
com.sun.jndi.ldap.connect.timeout
In sqldeveloper you will configure it in the “Advanced” tab:

With JDBC, the values are in milliseconds. Thus, in contrast to the normal client, we can also specify values of less than 1 second (in the example 500 = 0.5 sec.).

In sqldeveloper it works. Does it also work with a “normal” java program (thanks to duck.ai to generate me the code). The class is named T (like Test).

// T.java
import java.sql.*;
import java.util.Properties;

class T {
  public static void main(String[] args) throws Exception {
    String url =
        "jdbc:oracle:thin:@ldap://ol9a:389/DB1970,cn=OracleContext,dc=dbi-services,dc=com ldap://ol9b:389/DB1970,cn=OracleContext,dc=dbi-services,dc=com";

    Properties env = new Properties();
    env.put("user", "system");
    env.put("password", "SystemPassword");
    env.put("com.sun.jndi.ldap.connect.timeout", "2000");

    try (Connection c = DriverManager.getConnection(url, env);
         Statement s = c.createStatement();
         ResultSet r = s.executeQuery("select host_name from v$instance")) {
      if (r.next())
        System.out.println(r.getString(1));
    }
  }
}

Then run the program

 $ORACLE_HOME/jdk/bin/javac -cp $ORACLE_HOME/jdbc/lib/ojdbc8.jar T.java
 time $ORACLE_HOME/jdk/bin/java -cp $ORACLE_HOME/jdbc/lib/ojdbc8.jar:. T

We will see the same round-robin behavior as in sqldeveloper. Sometimes it takes 0.04-0.6 seconds (tries ol9b first), sometimes it takes 2.05-2.6 seconds (tries ol9a, wait configured timeout of 2sec. , try ol9b and connect)

Conclusion:

• We can configure the ldap failover timeout in milliseconds (in contrast to seconds with OCI client like sqlplus)
• Timeouts only happen when the host is unreachable, not when the LDAP server (software) is stopped.
• LDAP servers defined in the DIRECTORY_SERVERS parameter are used in a rond-robin order which is ideal for load-balancing.

General remarks and conclusions

• a timeout does not occur when the ldap service is stopped. The client immediately receives an error message from the host and can ask the other ldap
• If the first ldap server does not know the requested name, it will not try other ldap servers, but will try (if configured in names.directory_path) other naming methods (e.g. tnsnames.ora)
• The configured timeout is the maximum timeout. If it finds out that the host is not reachable, it tries the next one (e.g. the hostname is unknown).

For normal sql*net clients using the *.ora files (TNS_ADMIN / …/network/admin; see my blog post), you can configure the timeout in sqlnet.ora

NAMES.LDAP_CONN_TIMEOUT=1  #value in seconds

For Java JDBC clients, set the property

com.sun.jndi.ldap.connect.timeout=1000  #value in milliseconds

L’article Oracle LDAP Timeouts est apparu en premier sur dbi Blog.

This blog covers multiple aspects, including latest changes introduced in GoldenGate 26ai:

• Difference between extract and replicat filtering
• DDL filtering model and syntax
• AND/OR logic
• DDLOPTIONS parameter
• Tag-based filtering (EXCLUDETAG/INCLUDETAG)
• Edge cases

Extract vs Replicat DDL filtering

Before diving into the syntax, you should understand that DDL filtering means something different for an extract and a replicat.

For an extract, filtering controls what gets written to the trail file. If a DDL statement is excluded at the extract level, it is gone forever, and will never reach any downstream replicat. This makes extract-level filtering absolute and decisive. On the other side, it keeps trail files smaller and ensures no downstream replicat ever sees unwanted DDL.

For a replicat, filtering controls what gets applied to the target database. In that case, the DDL statement is considered to be already in the trail file. The replicat simply chooses to apply it or skip it. This gives more flexibility. For instance, multiple replicats can read the same trail and each apply a different subset of DDL. Of course, the trail files are larger, and generate more I/O.

This does not mean that you should choose one or another. A common use case is to do generic filtering at the extract level (removing clearly irrelevant DDL like CREATE USER or GRANT), and more targeted filtering for each replicat (for example, suppressing TRUNCATE on a target holding additional rows).

Enabling DDL Replication

DDL replication is disabled by default. You must explicitly enable it in both extract and replicat parameter files.

The simplest form is:

DDL

This enables DDL replication with no filtering. All DDL is captured (extract) or applied (replicat). In practice this is almost never what you want. You will almost always pair it with INCLUDE or EXCLUDE clauses.

Scopes: MAPPED, UNMAPPED, OTHER, ALL

Every DDL statement GoldenGate encounters is classified into one of four scopes based on whether the object it operates on matches your TABLE (extract) or MAP (replicat) parameter list.

If you do not specify a scope, GoldenGate defaults to ALL.

Example

With this extract parameter file:

EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
DDL INCLUDE ALL
TABLE APP_SCHEMA.*;

• CREATE TABLE APP_SCHEMA.ORDERS (...) is MAPPED (matches APP_SCHEMA.*)
• CREATE TABLE AUDIT_SCHEMA.LOGS (...) is UNMAPPED (does not match APP_SCHEMA.*)
• GRANT SELECT ON APP_SCHEMA.ORDERS TO READONLY is MAPPED (a GRANT on a specific object follows that object’s own scope, not OTHER. OTHER is only for DDL with no target object at all, like CREATE USER)

Switching to DDL INCLUDE MAPPED would capture the first and third statements.

The DDL statement’s scope depends on the operation: see “Interaction with TABLE and MAP Parameters” below for more details.

Filter Keywords

On top of scope filtering, you can also filter DDL by object type, operation type, object name, and DDL text content. These filters are specified as comma-separated conditions within a single DDL clause. All conditions in a single clause are added together (logical AND).

OBJTYPE

Filters by the type of database object the DDL operates on.

Common Oracle object types: TABLE, INDEX, SEQUENCE, VIEW, PROCEDURE, FUNCTION, TRIGGER, PACKAGE, TYPE, SYNONYM, DATABASE LINK, TABLESPACE, USER.

-- Only capture DDL on tables
DDL INCLUDE MAPPED, OBJTYPE 'TABLE'

-- Only capture DDL on indexes
DDL INCLUDE MAPPED, OBJTYPE 'INDEX'

OPTYPE

Filters by the type of DDL operation.

Common operation types: CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE, COMMENT.

-- Only capture CREATE TABLE statements
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE

-- Exclude DROP operations on all object types
DDL EXCLUDE MAPPED, OPTYPE DROP

OPTYPE RENAME exists and works, but classification depends on the exact SQL used. A RENAME old TO new; statement matches OPTYPE RENAME (GoldenGate logs OGG-10457 DDL RENAME found ... RENAME converted to ALTER TABLE while writing it, then classifies the resulting OGG-10451/OGG-10452 line as optype [RENAME]). But ALTER TABLE ... RENAME TO ... (the form most people write, since RENAME cannot be schema-qualified) matches OPTYPE ALTER instead, with no RENAME classification and no conversion message at all.

OBJNAME

Filters by object name. Supports wildcards (* for any sequence of characters, ? for a single character). For Oracle, use the schema.object format, or container.schema.object in multitenant. Write the value with no quotes at all. OBJNAME 'APP_SCHEMA.*' (single-quoted) abends with OGG-06377 Single quote marks cannot be used to delimit OBJNAME, and OBJNAME "APP_SCHEMA.*" (double-quoted) abends differently, with OGG-06585 No schema is specified. A double-quoted value is taken as one literal token and never splits on its dot into schema and object.

-- Only capture DDL for tables starting with ORD_ in APP_SCHEMA
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OBJNAME APP_SCHEMA.ORD_*

-- Exclude DDL on any staging table
DDL EXCLUDE MAPPED, OBJNAME APP_SCHEMA.*_STG

INSTR

Filters based on whether a literal string appears anywhere in the DDL text (case-sensitive). This is especially useful for excluding certain kinds of DDL.

-- Exclude any DDL containing NOLOGGING
DDL EXCLUDE MAPPED, INSTR 'NOLOGGING'

-- Exclude DDL referencing a specific tablespace by name
DDL EXCLUDE MAPPED, INSTR 'ARCHIVE_TBS'

INSTRWORDS

Similar to INSTR, but performs word-level matching. The order of the words does not matter, and partial matches within longer words are not counted.

-- Exclude DDL that contains both the words COMPRESS and OLTP (in any order)
DDL EXCLUDE MAPPED, INSTRWORDS 'COMPRESS OLTP'

EVENTACTIONS

Unlike the keywords above, EVENTACTIONS is not specific to DDL: it is a general GoldenGate keyword also usable on TABLE and MAP clauses, for triggering an action (REPORT, LOG, and others) whenever a record matches that clause. It happens to be usable inside a DDL clause too, comma-separated alongside OBJTYPE/OPTYPE/OBJNAME/INSTR like any other filter keyword, and it comes with real, DDL-specific behavior worth knowing.

EVENTACTIONS (REPORT) forces the same DDL replication statistics block that DDLOPTIONS REPORT writes on demand (see the DDLOPTIONS section below). However, it only works on an INCLUDE clause:

DDL INCLUDE MAPPED, EVENTACTIONS (REPORT)

2026-09-05 11:52:47  INFO    OGG-01487  DDL found, operation [create table ddltest.evt1 (id number) (size 37)], start SCN [24368602], commit SCN [24368634] instance [ (1)], DDL seqno [0], marker seqno [0].

2026-09-05 11:52:47  INFO    OGG-10451  DDL operation included [INCLUDE MAPPED, EVENTACTIONS (REPORT)], optype [CREATE], objtype [TABLE], catalog "PDB1", objowner "DDLTEST", objname "EVT1".

***********************************************************************
*                   ** Run Time Statistics **                         *
***********************************************************************


Report at 2026-09-05 11:52:47.388472 (activity since 2026-09-05 11:50:36.261708)

Output to dt:



DDL replication statistics:

                    Operations:         0
             Mapped operations:         0
           Unmapped operations:         0
              Other operations:         0
           Excluded operations:         0


No records extracted.

This is verbose. A second CREATE TABLE matching the same clause produced a second, identical-shaped block right after its own OGG-10451 line. This means that every matching DDL gets its own full statistics dump on top of the usual OGG-01487/OGG-10451/OGG-10452 lines. On a replication with any real amount of DDL traffic, this multiplies report file growth well past what plain DDLOPTIONS REPORT alone produces. Try to restrict EVENTACTIONS (REPORT) to a narrow INCLUDE clause: a specific OBJTYPE, OPTYPE, or OBJNAME you want to log in the report file.

DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, OPTYPE TRUNCATE, EVENTACTIONS (REPORT)

AND/OR Logic

Only one DDL parameter is allowed per parameter file. A parameter file with two separate DDL lines abends at startup with OGG-00403 There can be only one DDL filtering statement: “Only one DDL parameter can be used in a parameter file, but you can combine multiple inclusion and exclusion options to filter the DDL to the required level.” Everything below happens inside that single DDL parameter: each clause after the first drops the leading DDL keyword and starts directly with INCLUDE or EXCLUDE, and the whole thing is continued with &.

AND: conditions within a single DDL clause

A DDL statement must satisfy all conditions to match.

-- Capture only CREATE TABLE in APP_SCHEMA (all three conditions must be true)
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE, OBJNAME APP_SCHEMA.*

A DROP TABLE APP_SCHEMA.ORDERS would not match this clause because OPTYPE DROP is different from OPTYPE CREATE.

OR: multiple INCLUDE/EXCLUDE clauses

Only one DDL parameter is allowed per parameter file, but that parameter can carry multiple INCLUDE/EXCLUDE clauses, separated with &. Multiple INCLUDE clauses are evaluated as a logical OR: a DDL statement is captured if it matches any INCLUDE clause. The indentation is optional.

-- Capture CREATE TABLE or CREATE SEQUENCE (either clause is sufficient)
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE

EXCLUDE always wins over INCLUDE

If a DDL statement matches both an INCLUDE clause and an EXCLUDE clause, the EXCLUDE wins. This lets you set broader INCLUDE rules and choose specific exceptions. An EXCLUDE clause always needs a corresponding INCLUDE clause in the same DDL parameter, it cannot stand alone.

-- Include all MAPPED DDL, but exclude TRUNCATE
DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, OPTYPE TRUNCATE

A lone EXCLUDE clause with no corresponding INCLUDE still abends (OGG-06374 Invalid DDL statement: No INCLUDE). EXCLUDE narrows an INCLUDE; it cannot stand alone. Every multi-clause example in this post uses this single-DDL-parameter, &-continued form.

Filtering Examples

You can build nearly all sorts of DDL filtering in GoldenGate. But you should always ensure that they are relevant to the workload on the source and target databases !

Example 1: Structural DDL only, no destructive operations

Goal: replicate CREATE and ALTER on tables and sequences, but never DROP or TRUNCATE.

DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE ALTER

Any DROP TABLE, TRUNCATE TABLE, or DROP SEQUENCE on a mapped object will be silently ignored.

Example 2: Everything except NOLOGGING directives

Here, the goal is to replicate all MAPPED DDL, but exclude any DDL containing the NOLOGGING directive.

DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, INSTR 'NOLOGGING'

Example 3: Replicat applies only a subset of a rich trail

If a trail was generated with DDL INCLUDE ALL at the extract level, and you need the replicat to apply only CREATE TABLE and ALTER TABLE on mapped objects:

DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER
MAP APP_SCHEMA.*, TARGET TARGET_SCHEMA.*;

All other DDLs in the trail (DROP, TRUNCATE, index changes, sequences) are skipped by this replicat.

Example 4: Mapped objects plus a specific unmapped schema

-- Capture DDL for APP_SCHEMA (mapped) and also for SHARED_SCHEMA (not in the TABLE filtering)
DDL INCLUDE MAPPED &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.* &
    EXCLUDE MAPPED, OPTYPE TRUNCATE &
    EXCLUDE UNMAPPED, OPTYPE DROP
TABLE APP_SCHEMA.*;

DDLOPTIONS parameter

DDLOPTIONS often comes with DDL and controls what happens when DDL is processed. It is a global setting which applies to all DDL replication.

REPORT

Writes each DDL statement encountered (whether included or excluded) to the extract or replicat report file.

DDLOPTIONS REPORT

With DDL INCLUDE ALL, a CREATE TABLE DDLTEST.PROMOTIONS on the source produces entries like these in the report file:

2026-09-05 16:10:12  INFO    OGG-01487  DDL found, operation [create table ddltest.promotions (id number, discount number) (size 60)], start SCN [23026101], commit SCN [23026117] instance [ (1)], DDL seqno [0], marker seqno [0].
2026-09-05 16:10:12  INFO    OGG-10451  DDL operation included [INCLUDE ALL], optype [CREATE], objtype [TABLE], catalog "PDB1", objowner "DDLTEST", objname "PROMOTIONS".

This is very useful for testing, or when the DDL volume is low. However, never include DDLOPTIONS REPORT if you have a lot of DDLs. Your report files will grow without control.

A running process also keeps a running count of DDL statements by scope, separate from the per-statement DDLOPTIONS REPORT lines above. Request it on demand with SEND EXTRACT <name>, REPORT (or SEND REPLICAT <name>, REPORT) through the adminclient. It also gets written automatically whenever the process stops.

***********************************************************************
*                   ** Run Time Statistics **                         *
***********************************************************************

Report at 2026-09-05 11:34:23.315905 (activity since 2026-09-05 11:31:27.204191)

DDL replication statistics:

                    Operations:         1
             Mapped operations:         1
           Unmapped operations:         0
              Other operations:         0
           Excluded operations:         0

The report (Mapped/Unmapped/Other/Excluded) mirrors the scope model from the “Scopes” section above, so it is a quick way to check whether your filtering is doing what you expect without scrolling through every individual OGG-01487/OGG-10451/OGG-10452 line.

DDLERROR (Replicat only)

Controls what happens when a DDL statement fails on the target. The default is to abend.

DDLERROR DEFAULT DISCARD

DDLERROR is a top-level parameter, not a DDLOPTIONS sub-keyword. As you can imagine, use DISCARD with caution. It could silently leave the target schema out of sync.

Tag-Based DDL Filtering: EXCLUDETAG and INCLUDETAG

Oracle GoldenGate 26ai adds a second, independent filtering layer on top of everything above. You can now filter by tag rather than by scope or object. Every DDL statement GoldenGate encounters carries a tag identifying its origin.

By default, an extract applies DDLOPTIONS EXCLUDETAG +, which excludes all tagged DDL unless a tag is explicitly allowed with INCLUDETAG:

-- Exclude every tagged DDL statement by default (implicit default)
DDLOPTIONS EXCLUDETAG +

-- Explicitly allow DDL carrying tag 00 (Data Pump)
DDLOPTIONS INCLUDETAG 00

The practical impact is on tools that stamp a session tag on the DDL they issue. For instance, impdp tags its DDL with tag 00. Under GoldenGate 26ai default behavior, that DDL is excluded from replication unless the extract explicitly adds DDLOPTIONS INCLUDETAG 00. Please note that this is a behavioral change from earlier versions of GoldenGate. Before, impdp DDL was captured without any extra configuration needed. If an import via impdp is expected to replicate its DDL, check for this setting before assuming the default behavior still applies.

EXCLUDETAG/INCLUDETAG do not replace the scope and filter-keyword model. A DDL statement still has to pass the DDL INCLUDE/DDL EXCLUDE scope and keyword filtering described above. Both filtering systems have to allow the DDL.

Interaction with TABLE and MAP Parameters

Here are the scope (MAPPED/UNMAPPED/…) assignment rules for standard TABLE DDL.

Edge Cases

DDL errors from cascading object dependencies

Some DDL operations have cascading effects that GoldenGate does not replicate automatically.

DROP TABLE DDLTEST.CUSTOMERS CASCADE CONSTRAINTS;

2026-09-05 20:23:38  INFO    OGG-00482  DDL found, operation [drop table ddltest.customers cascade constraints].
2026-09-05 20:23:38  INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [drop table "DDLTEST_TGT"."CUSTOMERS" cascade constraints].
2026-09-05 20:23:38  INFO    OGG-10451  DDL operation included [INCLUDE MAPPED], optype [DROP], objtype [TABLE], catalog "PDB1", objowner "DDLTEST_TGT", objname "CUSTOMERS".
2026-09-05 20:23:38  INFO    OGG-00484  Executing DDL operation.
2026-09-05 20:23:38  INFO    OGG-00483  DDL operation successful.

SELECT object_name, object_type, status FROM dba_objects WHERE owner = 'DDLTEST_TGT' AND object_name = 'CUSTOMERS_V';

OBJECT_NAME    OBJECT_TYPE  STATUS
-------------- ------------ -------
CUSTOMERS_V    VIEW         INVALID

Complete Parameter File Examples

Here is an example of an extract/replicat pair, and how you could build complex DDL handling.

EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1

-- Capture structural DDL on mapped objects, exclude storage directives,
-- and also capture DDL on a shared utility schema not in the TABLE list
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE RENAME &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE ALTER &
    EXCLUDE MAPPED, INSTR 'NOLOGGING' &
    EXCLUDE MAPPED, INSTR 'COMPRESS' &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.*, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.*, OBJTYPE 'TABLE', OPTYPE ALTER

-- Write DDL activity to the report file for auditing
DDLOPTIONS REPORT

TABLE APP_SCHEMA.*;
TABLE SHARED_SCHEMA.*;

REPLICAT REP
USERIDALIAS target_db DOMAIN OracleGoldenGate

-- Apply only CREATE and ALTER TABLE on mapped objects, plus shared-schema DDL;
-- skip sequences, drops, truncates, etc.
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJNAME SHARED_SCHEMA.*

-- Write DDL activity to report file
DDLOPTIONS REPORT

-- Write discarded/failed DDL to discard file rather than abending
DDLERROR DEFAULT DISCARD

MAP APP_SCHEMA.*, TARGET TARGET_SCHEMA.*;
MAP SHARED_SCHEMA.*, TARGET SHARED_SCHEMA.*;

Summary

DDL filtering in GoldenGate is a layered system:

• Scope (MAPPED/UNMAPPED/OTHER/ALL) restricts DDL replication, based on your TABLE/MAP configuration
• Filter keywords (OBJTYPE, OPTYPE, OBJNAME, INSTR, INSTRWORDS) restricts DDL replication within the scope
• Only one DDL parameter is allowed per parameter file, but it can carry multiple INCLUDE/EXCLUDE clauses continued with &. AND logic applies within a single clause, while OR logic applies across clauses. EXCLUDE always wins over INCLUDE and always needs a corresponding INCLUDE
• DDLOPTIONS controls what happens when DDL is captured or replicated.
• Extract filtering is irreversible. You should filter at the replicat level when multiple replicats need different DDL settings.

L’article DDL Filtering in GoldenGate Extract and Replicat est apparu en premier sur dbi Blog.