Oracle Database 19.31 Patch Hold: What DBAs on Exadata 25.2 Need to Know

If you’ve been trying to download the latest Oracle Database 19.31 Release Update (RU) lately and found the download pages curiously empty, you aren't alone. Oracle has officially placed a temporary hold on this specific RU for Exadata environments.

The move comes after several customers reported intermittent internal errors specifically when running 19.31 on Exadata System Software 25.2. Here is a breakdown of what happened, why it matters, and how to keep your systems stable.

What’s the Problem?
Oracle recently published a My Oracle Support (MOS) advisory regarding a conflict between the 19.31 DBRU and the newer Exadata 25.2 software stack. It appears that a specific optimization path related to temporary tablespace processing is triggering internal failures during SQL execution.

Because the issue is severe enough to cause application instability, Oracle took the proactive step of removing the 19.31 patch binaries while they work on a corrected revision.
Key Symptoms to Watch For:
If you are already on this combination, you might see a spike in:

• ORA-00600 internal errors (specifically signatures like QERHNITERATEOVERBUFFERS.1 or kcblsltio_1)
• Unexpected SQL statement failures and session terminations
• Background process crashes that disrupt application uptime

Issues specifically during heavy ETL, analytics, or workloads that lean hard on temporary segments.

Workaround: Disabling the Optimization
If you have already deployed 19.31 to your Exadata 25.2 environment, you don't necessarily need to roll back immediately. Oracle has provided a "hidden parameter" workaround that disables the problematic optimization path.

To mitigate the risk immediately, run the following:
-- For the current instance
alter system set "_kcfis_fctempopt_mode" = 0;

-- For RAC environments (persistent across nodes)
alter system set "_kcfis_fctempopt_mode" = 0 scope=both sid='*';

Note: As with any hidden parameter, make sure to document this in your operational runbook and monitor performance. Once Oracle releases the corrected RU, you will likely need to unset this parameter.

Who is Affected?
The good news is that this is a relatively narrow issue. It currently only impacts:
Database Version: 19.31
Infrastructure: Exadata System Software 25.2.*
If you are running 19.31 on standard Linux/Unix servers, or if your Exadata units are on older software versions, you are likely in the clear.

reference: We released a MOS Note with detailed information: (KB888427) Oracle Database 19.31 Patch Hold Due to ORA-00600 Errors on Exadata 25.2: 

Oracle 26 AI New DB Parameter CALENDAR_FISCAL_YEAR_START

Business doesn’t follow the January to December calendar, but the database does. Every time you build a report, a dashboard, or even a simple query, you end up rewriting the same fiscal logic again and again.
Some teams maintain calendar tables. Others push the logic into BI tools. In many cases, it ends up duplicated across ETL pipelines, reports, and applications. And sooner or later, something goes out of sync.

Oracle 26ai introduces a small but very practical fix for this: CALENDAR_FISCAL_YEAR_START.
Checking the Parameter
show parameter CALENDAR_FISCAL_YEAR_START
NAME                       TYPE   VALUE 
-------------------------- ------ ----- 
calendar_fiscal_year_start string       

At this point it’s unset, which means Oracle is still operating on the standard calendar year.

Set the start of the fiscal year to June 1:
ALTER SESSION SET CALENDAR_FISCAL_YEAR_START = '01-JUN-2026', 'DD-MON-YYYY';

Only the month and day really matter, so this works as well:
ALTER SESSION SET CALENDAR_FISCAL_YEAR_START = '01-JUN', 'DD-MON';

Now let’s see how Oracle interprets dates once this is set.
Check June 15, 2026:
SELECT FISCAL_QUARTER('15-JUN-2026');
FISCAL_QUARTER
-------------
Q1-FY2027

And May 15, 2026:
SELECT FISCAL_QUARTER('15-MAY-2026');
FISCAL_QUARTER
-------------
Q4-FY2026

This is exactly how most organizations expect fiscal periods to behave when the year starts in June.

Why This Actually Matters:
This parameter removes a lot of quiet complexity that has been sitting in systems for years.
First, it cleans up SQL. You don’t need CASE statements or custom logic just to determine fiscal quarters. The database understands it natively.
Second, it brings consistency. Instead of every layer calculating fiscal periods differently, the logic lives in one place. That alone eliminates a lot of subtle reporting issues.
Third, it simplifies data pipelines. There’s no need to maintain fiscal calendar tables or transformation logic in ETL jobs. Less code, fewer moving parts, fewer things to break.

Oracle AI World 2025: What Really Stood Out This Year

Oracle AI World 2025 felt different. Not just because the event got a new name, or because it took over Las Vegas with thousands of attendees, or even because there were two new CEOs at the helm. It felt different because Oracle finally showed what it looks like when a company built on enterprise data decides to go all-in on AI.

Most people still think of Oracle as “the database company.” And sure—that’s part of its DNA. But this year’s event made one thing very clear:Oracle is no longer just storing enterprise data. It’s activating it. With AI. Everywhere.

Below is my take on the biggest announcements, the boldest ideas, and why Oracle AI World 2025 may be one of the company’s most important conferences in years.

Big Announcements You Should Know About
AI Agent Marketplace
This was one of the most talked-about launches—an online store of pre-built AI agents that plug directly into Fusion Apps.
And these aren’t little chatbots. These are real workflow-level agents built by partners like Deloitte, Accenture, Stripe, IBM, and others.
Think of it like an App Store, but for enterprise AI automation.

AI Agent Studio  & Agent Hub
AI Agent Studio is basically the design room where you build or fine-tune AI agents for Oracle Fusion Cloud Applications. You don’t need to be a hardcore developer—it's built for no-code/low-code creation.
You can start with Oracle’s pre-built agent templates or build your own from scratch. These agents can do everything from predicting equipment failures to summarizing meetings to handling procurement tasks.
Because it’s tightly connected to Fusion Apps, the agents can securely tap into real business data and take real actions. Developers and admins use the Studio to build and deploy, while business users simply interact with the agents through AI Chat or Ask Oracle right inside their Fusion screens.

If the Studio is where you build, Agent Hub is where you run and scale.
Agent Hub, part of OCI Generative AI, helps enterprises manage, monitor, secure, and expand their AI agents across the organization. It includes an AI Agent Marketplace (so you can pull in new, pre-built agent capabilities from Oracle partners) and support for a wider range of LLMs to power more sophisticated behaviors.

Database 26ai: Oracle Rewrites Its Engine for the AI Era
The upgrade from 23ai to 26ai isn’t incremental—it’s a reinvention.

Key takeaways:

• Vector and RAG are built into the engine
• Iceberg support brings openness
• It reduces data duplication
• It enables in-database AI agents
• It’s the foundation for Oracle’s new AI lakehouse

Some people say Oracle is behind Snowflake or Databricks in vectors/RAG.
But Oracle made a simple point:

If your entire business runs on Oracle data, do you want to move it to a new AI store…
or just bring AI to where the data already lives?

OCI Infrastructure & The Zettascale Supercomputer
OCI Dedicated Region25: Bringing an entire OCI region into as little as three racks for sovereign cloud, low-latency, and regulatory control.

NVIDIA Zettascale10 AI Supercomputer: A stunning commitment to scale, announcing a potential world-largest cloud-based supercomputer with hundreds of thousands of NVIDIA GPUs and 16 zettaFLOPS peak performance, built on Oracle’s low-latency Acceleron RoCE network.

Oracle AI Data Platform :
Oracle unveiled its new Autonomous AI Lakehouse—open, multicloud, Iceberg-native, and deeply integrated with Database 26ai.
Everyone is building a lakehouse these days, but Oracle’s spin is unique:
Most vendors approach AI from the unstructured-storage angle.
Oracle approaches it from the structured-enterprise-data angle.

Fusion Apps: AI at No Extra Cost (Yes, Really)
Here’s the part that shocked a lot of people:
Oracle is bundling 600+ AI agents and 100+ new AI features directly into Fusion Apps for no additional license fee.
No AI surcharge.
No per-user pricing.
No “AI edition.”

Final Thoughts: Oracle Is Playing the Long Game
Oracle AI World 2025 felt like a company fully aligned around AI—from Larry’s long-term industry vision to Clay’s infrastructure strategy to Sicilia’s application intelligence.

If you’re an enterprise already in the Oracle ecosystem, the value story is compelling:

• AI agents included
• AI in the database
• AI in the lakehouse
• AI in every Fusion workflow
• AI-ready cloud infrastructure
• Multicloud flexibility

Oracle AI World 2025 made one thing clear: Oracle is no longer just keeping up in the AI race—it’s shaping its own lane.
 

Adding some of my favorite photos from Oracle AI World 2025. Speaking at the event was truly a highlight for me. 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

Co-presented "Oracle AI Database Cloud Service: What's New and What's Next" alongside Binoy Sukumaran and Tushar Pandit.  

 

 

 

 

 

 

 

 

 

 

 

 

Guest Speaker : Modern DevX OraOperator + AI Centric App Development with Oracle Database 23ai  

 

 

 

 

 

 

 

 

DML Error Logging

What Is DBMS_ERRLOG?
DBMS_ERRLOG is a built-in Oracle package that helps you manage errors during DML operations (like INSERT, UPDATE, or DELETE). Its core function is to create and use an error logging table. Instead of failing the entire statement when it encounters a bad row, database simply logs the error and moves on to the next one. 

How Does It Work?
The process is simple and involves two main steps:
    Create an Error Logging Table: use the DBMS_ERRLOG.CREATE_ERROR_LOG procedure to create a table that will store information about any rows that fail your DML statement. only need to do this once for each target table.
    Enable Error Logging in Your DML Statement: add the LOG ERRORS clause to your INSERT, UPDATE, or DELETE statement. This tells the database to use the error logging table  created.

Lets try sample table
SQL> CREATE TABLE contacts (
    contact_id NUMBER PRIMARY KEY,
    first_name VARCHAR2(50),
    last_name VARCHAR2(50)
);  

Table created.
Create an error log table for the contacts table using the DBMS_ERRLOG.CREATE_ERROR_LOG procedure. This only needs to be done once per target table.
SQL> BEGIN
  DBMS_ERRLOG.CREATE_ERROR_LOG('contacts', 'contacts_err_log');
END;
/  
PL/SQL procedure successfully completed.

Insert data to contacts table
SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (1, 'John', 'Doe') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (2, NULL, 'Smith') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (1, 'Jane', 'Doe') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
0 rows created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (3, 'Peter', 'Jones') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> commit;
Commit complete.
Lets check error details from error log table:
SQL> SELECT *  FROM contacts_err_log;
   ORA_ERR_NUMBER$ ORA_ERR_MESG$                                                            ORA_ERR_ROWID$         OR ORA_ERR_TAG$                 CONTACT_ID               FIRST_NAME     LAST_NAME
------------------ ------------------------------------------------------------------------ ---------------------- -- ---------------------------- ------------------------ -------------- ----------------
                 1 ORA-00001: unique constraint (SYS.SYS_C008882) violated                                         I  bulk_insert_test             1                        Jane           Doe

The output will show you the specific error codes and messages for each failed row, allowing you to easily identify and correct the data issues.

Oracle Optimizer Hints

What Exactly is an Optimizer Hint?
A hint is a comment placed within an SQL statement (after SELECT, UPDATE, INSERT, MERGE, or DELETE) that instructs the Cost-Based Optimizer (CBO) to use a particular execution approach, even if the CBO might calculate that path to be more "expensive."
Hints are enclosed in special comment syntax: /*+ hint_name(arguments) */.
For example, to prioritize the fastest return of the first 10 rows:
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name FROM employees;
While powerful for testing and troubleshooting, remember: hints are extra code to manage and can become obsolete or even detrimental after database changes. For long-term stability, tools like SQL Plan Baselines are often preferred.

Types of Hints: Scope of Influence
Oracle hints are categorized by the scope of the SQL they affect, determining the specific part of the statement they influence:
    Single-Table Hints: These are specified on a single table or view within the query. They are used to influence operations directly against that specific object. An example is the INDEX hint, which instructs the optimizer to use a particular index when accessing the table.
    Multi-Table Hints: Similar to single-table hints, but they can specify one or more tables or views, often to influence the relationship or order between them. The LEADING hint is a prime example, used to enforce a specific order in which tables are joined. Note that a hint like USE_NL(table1 table2) is often just a shorthand for two single-table hints.
    Query Block Hints: These hints operate on an entire query block, such as the main query or a named subquery. They typically affect transformations or high-level execution strategies for that block. Examples include STAR_TRANSFORMATION and UNNEST.
    Statement Hints: These apply to the entire SQL statement, regardless of complexity or query blocks. They often control global execution parameters. The ALL_ROWS hint, which optimizes for best overall throughput rather than fastest initial response, is a common statement hint.

Hints by Category:
Oracle's many hints are logically grouped into categories, providing granular control over different phases of query optimization and execution:
1. Hints for Optimization Approaches and Goals:
These hints set the overarching objective for the optimizer, overriding the session or system settings:
    ALL_ROWS
    FIRST_ROWS(n)
2.Hints for Enabling Optimizer Features
This hint allows you to maintain plan stability across database versions:
    OPTIMIZER_FEATURES_ENABLE
3.Hints for Access Paths
These hints instruct the optimizer to use a specific method for accessing data in a table:
    FULL
    CLUSTER
    HASH
    INDEX and NO_INDEX
    INDEX_ASC and INDEX_DESC
    INDEX_COMBINE
    INDEX_JOIN
    INDEX_FFS and NO_INDEX_FFS
    INDEX_SS and NO_INDEX_SS
    INDEX_SS_ASC and INDEX_SS_DESC
4.Hints for Join Orders
These hints suggest the order in which tables should be joined:
    LEADING
    ORDERED
5.Hints for Join Operations
These hints instruct the optimizer on the algorithm to use for joining tables:
    USE_NL and NO_USE_NL
    USE_NL_WITH_INDEX
    USE_MERGE and NO_USE_MERGE
    USE_HASH and NO_USE_HASH
6.Hints for Online Application Upgrade
These specialized hints manage concurrency during Edition-Based Redefinition (EBR) upgrades:
    CHANGE_DUPKEY_ERROR_INDEX
    IGNORE_ROW_ON_DUPKEY_INDEX
    RETRY_ON_ROW_CHANGE
7.Hints for Parallel Execution
These hints control whether and how the SQL statement should be executed in parallel:
    PARALLEL and NO_PARALLEL
    PARALLEL_INDEX and NO_PARALLEL_INDEX
    PQ_DISTRIBUTE
8.Hints for Query Transformations
These hints allow you to enable or disable specific logical rewrites of the SQL statement:
    NO_QUERY_TRANSFORMATION
    USE_CONCAT
    NO_EXPAND
    REWRITE and NO_REWRITE
    MERGE and NO_MERGE
    STAR_TRANSFORMATION and NO_STAR_TRANSFORMATION
    FACT and NO_FACT
    UNNEST and NO_UNNEST
9.Additional Hints
This is a collection of hints for various other specific needs and behaviors:
    APPEND, APPEND_VALUES, and NOAPPEND
    CACHE and NOCACHE
    PUSH_PRED and NO_PUSH_PRED
    PUSH_SUBQ and NO_PUSH_SUBQ
    QB_NAME
    CURSOR_SHARING_EXACT
    DRIVING_SITE
    DYNAMIC_SAMPLING
    MODEL_MIN_ANALYSIS

A key addition in Oracle Database 23ai is related to vector data processing, essential for AI-driven similarity searches:
    VECTOR_INDEX_SCAN: This hint instructs the optimizer to explicitly use a Vector Index to satisfy the query. This is vital for accelerating similarity searches on vector data, ensuring the database leverages its specialized vector processing capabilities for these modern data types.
    
    

What is "enq: TX - index contention"?

At its core, "enq: TX - index contention" signifies that multiple sessions are trying to acquire a Transaction (TX) enqueue on the same index block concurrently. An enqueue is a locking mechanism used by Oracle to protect shared resources. When sessions are waiting on a TX enqueue for an index, it means they are effectively "stuck" trying to modify (insert, update, or delete) rows that would impact the same small portion of an index.  

Think of it like this: Imagine a very popular book in a library. Many people want to borrow it, but there's only one copy. Everyone lines up, waiting for their turn. In our database analogy, the "book" is a specific index leaf block, and the "people" are concurrent transactions trying to write to it. The "line" is the "enq: TX - index contention" wait.

The Root Causes: Why Does This Happen?
"enq: TX - index contention" isn't random; it stems from specific access patterns that create "hot spots" within your indexes.

1. The Monotonically Increasing Key (The Most Common Culprit)
This is by far the leading cause. When you have an index built on a column whose values are always increasing, like:
    Sequence-generated Primary Keys (e.g., ID NUMBER DEFAULT MY_SEQ.NEXTVAL)
    DATE or TIMESTAMP columns using SYSDATE / SYSTIMESTAMP
    Application-generated unique identifiers that increment sequentially

Every new INSERT operation will attempt to add a new entry to the "right-hand side" or the highest value end of the index. If you have many sessions inserting concurrently, they all converge on the same few index leaf blocks at the "end" of the index. This creates a severe bottleneck as sessions contend for exclusive access to these blocks, leading to:
    Frequent Block Splits: As the hot block fills up, Oracle has to split it into two blocks to make room for new entries. This is an expensive operation and exacerbates contention.
    Increased Buffer Cache Activity: The hot block is constantly being read into and written from the buffer cache.
    High Interconnect Traffic (in RAC): In a RAC environment, these hot blocks are constantly "ping-ponging" between instances as different nodes try to insert into them, leading to high "gc buffer busy" waits in addition to "enq: TX" waits.

Example Scenario:
Imagine an ORDER table with ORDER_ID as a primary key, populated by ORDER_SEQ.NEXTVAL. In a busy e-commerce application, hundreds of orders are placed per second. Each INSERT INTO ORDERS (ORDER_ID, ...) attempts to write a new, higher ORDER_ID into the ORDER_PK index. All these inserts bottleneck on the same few index leaf blocks, resulting in "enq: TX - index contention."

2. Heavy Deletes Followed by Inserts (Index Fragmentation)
While less common than monotonic keys, this can also contribute. If you perform large-scale DELETE operations on a table, the index entries are marked as deleted but the space isn't immediately reclaimed. Subsequent INSERT operations might then try to reuse this freed space. If many concurrent sessions are attempting to insert into these "fragmented" or "sparse" index blocks, it can lead to contention as they fight for ITL (Interested Transaction List) slots or space within those blocks.

3. Low PCT_FREE for the Index
PCT_FREE specifies the minimum percentage of free space reserved in each data block for future updates. While more critical for data blocks, a very low PCT_FREE on an index could theoretically contribute to contention if updates to existing index entries cause the blocks to become excessively full, leading to more frequent splits or difficulty in allocating ITL slots for concurrent transactions. This is a less frequent direct cause but can be a contributing factor.
The Impact: How Does It Hurt Performance?
The consequences of "enq: TX - index contention" are significant:
    Reduced Throughput: Transactions wait, slowing down overall DML operations.
    Increased Response Times: User experience suffers as applications become sluggish.
    High CPU Utilization: Index block splits, consistent read generation, and frequent buffer cache operations consume more CPU.
    Increased I/O (Indirectly): While primarily a CPU/contention issue, increased block splits can indirectly lead to more I/O.
    RAC-Specific Woes: In RAC, this contention translates directly to high "gc buffer busy" waits, as instances spend excessive time transferring the same hot blocks back and forth across the interconnect.

The Fixes: Solutions to Alleviate Index Contention
Once you've identified "enq: TX - index contention" as a problem (typically via AWR reports showing high waits for this event and pinpointing the exact index), here are the most effective strategies:

Solution 1: Reverse Key Indexes (The Go-To for Monotonic Keys)
    A reverse key index physically reverses the byte order of the column's values before storing them in the index. This effectively scrambles the sequence of monotonically increasing keys, distributing them randomly across the index's leaf blocks instead of concentrating them at one end.
    When to Use: Ideal for indexes on sequence-generated primary keys or other monotonically increasing values where range scans are not critical.
    -- Original index (if it exists)
    DROP INDEX my_table_pk;
    -- Create a reverse key index
    CREATE UNIQUE INDEX my_table_pk ON my_table (id) REVERSE;
    Pros: Highly effective at eliminating hot blocks and reducing contention for inserts.
    Cons: Significantly degrades performance for index range scans (e.g., WHERE ID BETWEEN 100 AND 200). This is because the values are no longer stored in logical order. You would need to perform a full index scan or a full table scan for such queries, which can be much slower.
    Consideration: Use this only if your application primarily performs direct lookups (WHERE ID = 123) and high-volume inserts. If range scans are frequent, look at other solutions first.

Example:
If ORDER_ID is a sequence, creating CREATE UNIQUE INDEX ORDER_PK ON ORDERS (ORDER_ID) REVERSE; would distribute new order inserts across the index. Queries like SELECT * FROM ORDERS WHERE ORDER_ID = 54321; would still be efficient, but SELECT * FROM ORDERS WHERE ORDER_ID BETWEEN 1000 AND 2000; would likely be slow.

Solution 2: Hash Partitioned Global Indexes (Requires Partitioning License)
    Concept: If you have the Oracle Partitioning option, you can create a Global Hash Partitioned Index. Oracle applies a hash function to the index key, distributing the index entries across multiple partitions. This effectively spreads out the hot spot caused by monotonic keys over multiple physical index segments.
    When to Use: When you need the benefits of distributing contention but also require efficient range scans (which reverse key indexes sacrifice).

    -- Assuming MY_TABLE is already hash partitioned by some column,
    -- or you just want to partition the index itself.
    CREATE UNIQUE INDEX my_table_pk ON my_table (id)
    GLOBAL PARTITION BY HASH (id)
    (
        PARTITION p1,
        PARTITION p2,
        PARTITION p3,
        PARTITION p4
    );

    Pros: Excellent for distributing inserts and maintaining good range scan performance.
    Cons: Requires the Oracle Partitioning option (additional license). Can be more complex to manage than simple indexes.

Solution 3: Increase Sequence CACHE Size
    If your index key is derived from a sequence (e.g., MY_SEQ.NEXTVAL), increasing the CACHE size for that sequence can help. Instead of fetching one number at a time, each session (or instance in RAC) can fetch a block of numbers (e.g., 100 or 1000). This reduces the contention on the sequence object itself. More importantly, in RAC, using CACHE with NOORDER allows different instances to use different ranges of sequence numbers simultaneously, indirectly distributing the inserts across the index.
    When to Use: Always consider this if sequences are generating your contended keys.
    ALTER SEQUENCE my_schema.my_sequence CACHE 1000 NOORDER;
    (Adjust 1000 based on your concurrency, often 10000 or more for very high volumes).
    Pros: Simple to implement, no impact on index scan performance.
    Cons: Does not directly address the index block contention but reduces pressure on the sequence and can help distribute inserts if combined with other factors like different session start times. It's more of a complementary solution.

Solution 4: Rebuild/Shrink Indexes After Large Deletes
If your contention arises after massive DELETE operations (which leave "holes" in the index), rebuilding or shrinking the index reclaims the space and reorganizes the index structure. This can reduce contention by ensuring blocks are full and contiguous, minimizing splits when subsequent inserts occur.
    When to Use: After significant data purges.

    ALTER INDEX my_schema.my_index REBUILD ONLINE; -- Rebuilds index
    -- OR
    ALTER INDEX my_schema.my_index SHRINK SPACE; -- Shrinks index (less disruptive)

    Pros: Reclaims space, improves index efficiency, can reduce future block splits.
    Cons: Rebuilds can be resource-intensive and lock the index (though ONLINE mitigates this).

Solution 5: Increase PCT_FREE for the Index (Less Common Primary Fix)
PCT_FREE reserves space within blocks. If index blocks are consistently filling up too fast, increasing PCT_FREE provides more space for new entries and ITL slots, potentially reducing immediate contention.

When to Use: If analysis shows contention is due to rapid block filling and ITL waits.
    ALTER INDEX my_schema.my_index PCTFREE 20; -- Default is 10
    Pros: Simple change.
    Cons: Can increase index size (less efficient storage), and often not the primary solution for monotonic key contention.

Global Hash-Partitioned Index

What is a Global Hash-Partitioned Index?
A global index is a single index structure that spans across all partitions of a partitioned table. It's not tied to the table's partitioning strategy.

Hash Partitioning: The index itself is divided into a fixed number of partitions using a hash algorithm on the index key. This aims to distribute index entries evenly across these index partitions.
Independence from Table Partitioning: The partitioning of a global index does not necessarily align with the partitioning of the underlying table. You can have a range-partitioned table with a hash-partitioned global index, for example.
Supports Unique Constraints: Global indexes can enforce unique constraints across the entire table, even if the table is partitioned. This is a key advantage over local indexes in certain scenarios where the unique key doesn't include the table's partition key.

How do Global Hash-Partitioned Indexes Improve Performance?
Global hash-partitioned indexes are particularly beneficial in specific scenarios, primarily by:
Reducing Contention for "Hot Blocks" (Especially during Inserts):
In OLTP (Online Transaction Processing) environments, where there are a high number of concurrent inserts into a table, especially when the indexed column is a sequence-generated primary key (e.g., an IDENTITY column or a sequence NEXTVAL), a standard B-tree index can become a "hot spot." This is because new entries are constantly being added to the "rightmost" leaf block of the index, leading to contention for that single block.

Hash partitioning distributes these new index entries across multiple index partitions (and thus multiple physical blocks) based on the hash of the key. This spreads the insert workload, reducing contention, "buffer busy waits," and improving overall insert throughput. This is often referred to as addressing the "90-10 split problem."
Improving Point Queries:
For equality queries (e.g., WHERE index_column = :value), the database can quickly calculate the hash of the value and go directly to the specific index partition where that value's entry is located. This allows for efficient access to data, often with fewer logical I/Os compared to a non-partitioned index on a very large table, as the index tree to traverse within a partition is smaller.
Facilitating Parallelism:
While not as inherently parallel for range scans as local non-prefixed indexes, global hash-partitioned indexes can still benefit from parallel query execution for certain operations, as the workload can be distributed across the index partitions.
Managing Large Indexes:
Partitioning a very large index into smaller, more manageable pieces can simplify maintenance tasks (e.g., rebuilding a single partition instead of the entire index), though global indexes do require more manual maintenance if table partitions are dropped or added, as the global index may become unusable and need rebuilding or UPDATE INDEXES clause to stay valid.

When to Consider Using Global Hash-Partitioned Indexes:
High-volume OLTP systems: Especially when suffering from "hot block" contention on indexes due to sequential key generation.
Indexes on non-partitioning key columns: 

When you need a unique constraint or fast access on columns that are not part of the table's partitioning key.
Queries primarily involving equality (=) or IN list predicates: These types of queries can leverage partition pruning on the index. Range predicates (like BETWEEN, >, <) generally won't benefit from hash partition pruning on the index side.
When even data distribution is crucial: Hash partitioning aims to distribute data evenly, which can be beneficial for load balancing. For optimal distribution, the number of hash partitions should ideally be a power of 2 (e.g., 2, 4, 8, 16, 32).
When the partitioning key column has high cardinality and is fairly unique.

Potential Drawbacks and Considerations:
No Partition Pruning for Range Scans: 

A significant limitation is that global hash-partitioned indexes typically do not benefit from partition pruning for range queries. If your queries frequently use BETWEEN, >, or < on the indexed column, a different index strategy (like a global range-partitioned index or a local index if applicable) might be more suitable.

Maintenance Overhead: 

When table partitions are dropped or truncated, global indexes (both hash and range) can become UNUSABLE and require rebuilding or an UPDATE INDEXES clause during the table partition operation. This can lead to downtime for large indexes. Local indexes are often preferred for tables where partitions are frequently added/dropped (e.g., historical data).
Choosing the Right Partitioning Key: Just like with table partitioning, selecting an appropriate partitioning key for the index is crucial for achieving even data distribution and performance benefits. A poor choice can lead to skewed data and "hot" index partitions, negating the benefits.
Complexity: Managing partitioned indexes adds a layer of complexity to database administration.

Move ExaWatcher Logs to Different Directory in Exacs

1.Create Directory for exawatcherlogs under /u02
mkdir -p /u02/exawatcherlogs
cd /u02
chown exawatch:exawatch exawatcherlogs

2. Backup Config File
cp /opt/oracle.ExaWatcher/ExaWatcher.conf /opt/oracle.ExaWatcher/ExaWatcher.conf_bkp

3.Modify config file with new log location
cat /opt/oracle.ExaWatcher/ExaWatcher.conf
<ResultDir> /opt/oracle.ExaWatcher/archive  to <ResultDir> /u02/exawatcherlogs

4. Stop ExaWatcher
systemctl stop exawatcher
ps -ef | grep -i exawatch

5. Start Exawatcher
/opt/oracle.ExaWatcher/ExaWatcher.sh --fromconf
systemctl start exawatcher

OCI Grid Upgrade/Patch using Image Copy

High level Steps:

1.Check The Current Grid Version Across Cluster Nodes

    dbaascli grid getDetails

2.List The Available Grid Software Images

    dbaascli cswlib showImages --product grid

3.Create A Patched Image Copy

    dbaascli grid patch --targetVersion 19.18.0.0.0 --createImage

4.Patch Grid Using image Copy

    dbaascli grid patch --targetVersion 19.18.0.0.0 --imageLocation /u02/app_acfs/exapatch/custom_images/grid1918_2023-04-03_09-17-56-PM.zip

5.Verify Grid Version Across Cluster Nodes

    dbaascli grid getDetails

 

Complete Steps with log:

1.Check the current grid version across cluster nodes

[root@ociexacsdbnode-qdhic1 ~]#  dbaascli grid getDetails

DBAAS CLI version 23.1.2.0.0

Executing command grid getDetails

Job id: a620ddd4-af0a-4839-816b-41e3e13a5940

Session log: /var/opt/oracle/log/grid/getDetails/dbaastools_2023-04-03_09-10-27-PM_207269.log

{

  "createTime" : 1679423425000,

  "updateTime" : 1679423425000,

  "scanListenerTCPPorts" : [ 1521 ],

  "scanListenerTCPSPorts" : [ 2484 ],

  "giNodeLevelDetails" : {

    "ociexacsdbnode-qdhic4" : {

      "nodeName" : "ociexacsdbnode-qdhic4",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.17.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic3" : {

      "nodeName" : "ociexacsdbnode-qdhic3",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.17.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic2" : {

      "nodeName" : "ociexacsdbnode-qdhic2",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.17.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic1" : {

      "nodeName" : "ociexacsdbnode-qdhic1",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.17.0.0.0",

      "status" : null

    }

  },

  "messages" : [ ]

}

dbaascli execution completed

[root@ociexacsdbnode-qdhic1 ~]#

 

2.List the available grid software images

[root@ociexacsdbnode-qdhic1 ~]# dbaascli cswlib showImages --product grid

DBAAS CLI version 23.1.2.0.0

Executing command cswlib showImages --product grid

Job id: efc52b92-af8f-4124-8eaf-69120c4c79a4

Session log: /var/opt/oracle/log/cswLib/showImages/dbaastools_2023-04-03_09-11-02-PM_210597.log

Log file location: /var/opt/oracle/log/cswLib/showImages/dbaastools_2023-04-03_09-11-02-PM_210597.log

############ List of Available grid Artifacts  #############

1.IMAGE_TAG=grid_19.18.0.0.0

  VERSION=19.18.0.0.0

  DESCRIPTION=19c JAN 2023 GI Image

2.IMAGE_TAG=grid_19.17.0.0.0

  VERSION=19.17.0.0.0

  DESCRIPTION=19c OCT 2022 GI Image

3.IMAGE_TAG=grid_19.16.0.0.0

  VERSION=19.16.0.0.0

  DESCRIPTION=19c JUL 2022 GI Image

4.IMAGE_TAG=grid_19.15.0.0.0

  VERSION=19.15.0.0.0

  DESCRIPTION=19c APR 2022 GI Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.

dbaascli execution completed

[root@ociexacsdbnode-qdhic1 ~]#

 

3.Create a patched image Copy

[root@ociexacsdbnode-qdhic1 ~]# dbaascli grid patch --targetVersion 19.18.0.0.0 --createImage

DBAAS CLI version 23.1.2.0.0

Executing command grid patch --targetVersion 19.18.0.0.0 --createImage

Job id: 2895b0d4-3869-4a8b-a806-342b7a2f420e

Session log: /var/opt/oracle/log/grid/patch/dbaastools_2023-04-03_09-16-14-PM_243786.log

Loading PILOT...

Session ID of the current execution is: 354

Log file location: /var/opt/oracle/log/grid/patch/pilot_2023-04-03_09-16-17-PM_244709

-----------------

Running initialization job

Completed initialization job

-----------------

Running validate_target_version job

Completed validate_target_version job

-----------------

Running validate_target_image_location job

Completed validate_target_image_location job

-----------------

Running validate_backup_locations job

Completed validate_backup_locations job

-----------------

Running validate_source job

Completed validate_source job

-----------------

Running validate_disk_space job

Completed validate_disk_space job

-----------------

Running unpackage_patches job

Completed unpackage_patches job

-----------------

Running create_temp_locations job

Completed create_temp_locations job

-----------------

Running copy_source_home job

Completed copy_source_home job

-----------------

Running unlock_temp_home job

Completed unlock_temp_home job

-----------------

Running attach_temp_home job

Completed attach_temp_home job

-----------------

Running replace_opatch job

Completed replace_opatch job

-----------------

Running check_patch_conflict job

Completed check_patch_conflict job

-----------------

Running rollback_conflicting_patches job

Completed rollback_conflicting_patches job

-----------------

Running apply_oneoffs_prepatch job

Completed apply_oneoffs_prepatch job

-----------------

Running apply_ru job

Completed apply_ru job

-----------------

Running apply_oneoffs_postpatch job

Completed apply_oneoffs_postpatch job

-----------------

Running create_gold_image job

Image location: /u02/app_acfs/exapatch/custom_images/grid1918_2023-04-03_09-17-56-PM.zip

Completed create_gold_image job

-----------------

Running cleanup job

Completed cleanup job

dbaascli execution completed

You have new mail in /var/spool/mail/root

[root@ociexacsdbnode-qdhic1 ~]#

Note:It is better to stop databases before starting patching and start them after patching is complete. This will save time during patch.

4.Patch Grid Using image Copy

[root@ociexacsdbnode-qdhic1 ~]# dbaascli grid patch --targetVersion 19.18.0.0.0 --imageLocation /u02/app_acfs/exapatch/custom_images/grid1918_2023-04-03_09-17-56-PM.zip

DBAAS CLI version 23.1.2.0.0

Executing command grid patch --targetVersion 19.18.0.0.0 --imageLocation /u02/app_acfs/exapatch/custom_images/grid1918_2023-04-03_09-17-56-PM.zip

Job id: 25979ce4-007c-48a1-a2e6-89c8b9bf2acf

Session log: /var/opt/oracle/log/grid/patch/dbaastools_2023-04-03_09-40-19-PM_24484.log

Loading PILOT...

Session ID of the current execution is: 355

Log file location: /var/opt/oracle/log/grid/patch/pilot_2023-04-03_09-40-22-PM_24962

-----------------

Running initialization job

Completed initialization job

-----------------

Running validate_nodes job

Completed validate_nodes job

-----------------

Running validate_image_location job

Completed validate_image_location job

-----------------

Running validate_target_version job

Completed validate_target_version job

-----------------

Running validate_backup_locations job

Completed validate_backup_locations job

-----------------

Running validate_source_home job

Completed validate_source_home job

-----------------

Running validate_creg_file_existence job

Completed validate_creg_file_existence job

-----------------

Running validate_crs_stack_state job

Completed validate_crs_stack_state job

-----------------

Running validate_databases job

Completed validate_databases job

-----------------

Running validate_disk_space job

Completed validate_disk_space job

-----------------

Running validate_perm_on_dir job

Completed validate_perm_on_dir job

-----------------

Running validate_users_umask job

Completed validate_users_umask job

-----------------

Running unpackage_image job

Completed unpackage_image job

-----------------

Running validate_image_product job

Completed validate_image_product job

-----------------

Running validate_image_version job

Completed validate_image_version job

-----------------

Running validate_image_patches job

Completed validate_image_patches job

-----------------

Running acquire_lock job

Completed acquire_lock job

-----------------

Running create_global_backup_loc job

Completed create_global_backup_loc job

-----------------

Running rotate_image_backup job

Completed rotate_image_backup job

-----------------

Running backup_image job

Completed backup_image job

-----------------

Running rotate_config_backup job

Completed rotate_config_backup job

-----------------

Running backup_config-ociexacsdbnode-qdhic1 job

Completed backup_config-ociexacsdbnode-qdhic1 job

-----------------

Running save_local_backup-ociexacsdbnode-qdhic1 job

Completed save_local_backup-ociexacsdbnode-qdhic1 job

-----------------

Running stop_db_instances-ociexacsdbnode-qdhic1 job

Completed stop_db_instances-ociexacsdbnode-qdhic1 job

-----------------

Running run_rootcrs_prepatch-ociexacsdbnode-qdhic1 job

Completed run_rootcrs_prepatch-ociexacsdbnode-qdhic1 job

-----------------

Running stop_tfa-ociexacsdbnode-qdhic1 job

Completed stop_tfa-ociexacsdbnode-qdhic1 job

-----------------

Running detach_source_home-ociexacsdbnode-qdhic1 job

Completed detach_source_home-ociexacsdbnode-qdhic1 job

-----------------

Running clean_source_home-ociexacsdbnode-qdhic1 job

Completed clean_source_home-ociexacsdbnode-qdhic1 job

-----------------

Running set_source_home_ownership-ociexacsdbnode-qdhic1 job

Completed set_source_home_ownership-ociexacsdbnode-qdhic1 job

-----------------

Running move_image_software_to_source_home-ociexacsdbnode-qdhic1 job

Completed move_image_software_to_source_home-ociexacsdbnode-qdhic1 job

-----------------

Running install_source_home-ociexacsdbnode-qdhic1 job

Completed install_source_home-ociexacsdbnode-qdhic1 job

-----------------

Running set_inventory_crs_flag-ociexacsdbnode-qdhic1 job

Completed set_inventory_crs_flag-ociexacsdbnode-qdhic1 job

-----------------

Running relink_with_rac_on-ociexacsdbnode-qdhic1 job

Completed relink_with_rac_on-ociexacsdbnode-qdhic1 job

-----------------

Running unpackage_config_files-ociexacsdbnode-qdhic1 job

Completed unpackage_config_files-ociexacsdbnode-qdhic1 job

-----------------

Running software_root_script-ociexacsdbnode-qdhic1 job

Completed software_root_script-ociexacsdbnode-qdhic1 job

-----------------

Running root_script_init-ociexacsdbnode-qdhic1 job

Completed root_script_init-ociexacsdbnode-qdhic1 job

-----------------

Running run_rootcrs_postpatch-ociexacsdbnode-qdhic1 job

Completed run_rootcrs_postpatch-ociexacsdbnode-qdhic1 job

-----------------

Running start_db_instances-ociexacsdbnode-qdhic1 job

Completed start_db_instances-ociexacsdbnode-qdhic1 job

-----------------

Running disable_diagsnap-ociexacsdbnode-qdhic1 job

Completed disable_diagsnap-ociexacsdbnode-qdhic1 job

-----------------

Running restore_tfa_status-ociexacsdbnode-qdhic1 job

Completed restore_tfa_status-ociexacsdbnode-qdhic1 job

-----------------

Running post_patch_updates-ociexacsdbnode-qdhic1 job

Completed post_patch_updates-ociexacsdbnode-qdhic1 job

-----------------

Running remove_local_backup-ociexacsdbnode-qdhic1 job

Completed remove_local_backup-ociexacsdbnode-qdhic1 job

-----------------

Running cleanup-ociexacsdbnode-qdhic1 job

Completed cleanup-ociexacsdbnode-qdhic1 job

-----------------

Running backup_config_on_node-ociexacsdbnode-qdhic2 job

Completed backup_config_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running save_local_backup_on_node-ociexacsdbnode-qdhic2 job

Completed save_local_backup_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running stop_db_instances_on_node-ociexacsdbnode-qdhic2 job

Completed stop_db_instances_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic2 job

Completed run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running stop_tfa_on_node-ociexacsdbnode-qdhic2 job

Completed stop_tfa_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running stop_processes_on_node-ociexacsdbnode-qdhic2 job

Completed stop_processes_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running remove_home_on_node-ociexacsdbnode-qdhic2 job

Completed remove_home_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running copy_patched_home_from_local_node-ociexacsdbnode-qdhic2 job

Completed copy_patched_home_from_local_node-ociexacsdbnode-qdhic2 job

-----------------

Running unpackage_config_backup_on_node-ociexacsdbnode-qdhic2 job

Completed unpackage_config_backup_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic2 job

Completed run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running start_db_instances_on_node-ociexacsdbnode-qdhic2 job

Completed start_db_instances_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running disable_diagsnap_on_node-ociexacsdbnode-qdhic2 job

Completed disable_diagsnap_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running restore_tfa_status_on_node-ociexacsdbnode-qdhic2 job

Completed restore_tfa_status_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running post_patch_updates_on_node-ociexacsdbnode-qdhic2 job

Completed post_patch_updates_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running remove_local_backup_on_node-ociexacsdbnode-qdhic2 job

Completed remove_local_backup_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running remove_local_patched_home_on_node-ociexacsdbnode-qdhic2 job

Completed remove_local_patched_home_on_node-ociexacsdbnode-qdhic2 job

-----------------

Running backup_config_on_node-ociexacsdbnode-qdhic3 job

Completed backup_config_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running save_local_backup_on_node-ociexacsdbnode-qdhic3 job

Completed save_local_backup_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running stop_db_instances_on_node-ociexacsdbnode-qdhic3 job

Completed stop_db_instances_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic3 job

Completed run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running stop_tfa_on_node-ociexacsdbnode-qdhic3 job

Completed stop_tfa_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running stop_processes_on_node-ociexacsdbnode-qdhic3 job

Completed stop_processes_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running remove_home_on_node-ociexacsdbnode-qdhic3 job

Completed remove_home_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running copy_patched_home_from_local_node-ociexacsdbnode-qdhic3 job

Completed copy_patched_home_from_local_node-ociexacsdbnode-qdhic3 job

-----------------

Running unpackage_config_backup_on_node-ociexacsdbnode-qdhic3 job

Completed unpackage_config_backup_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic3 job

Completed run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running start_db_instances_on_node-ociexacsdbnode-qdhic3 job

Completed start_db_instances_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running disable_diagsnap_on_node-ociexacsdbnode-qdhic3 job

Completed disable_diagsnap_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running restore_tfa_status_on_node-ociexacsdbnode-qdhic3 job

Completed restore_tfa_status_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running post_patch_updates_on_node-ociexacsdbnode-qdhic3 job

Completed post_patch_updates_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running remove_local_backup_on_node-ociexacsdbnode-qdhic3 job

Completed remove_local_backup_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running remove_local_patched_home_on_node-ociexacsdbnode-qdhic3 job

Completed remove_local_patched_home_on_node-ociexacsdbnode-qdhic3 job

-----------------

Running backup_config_on_node-ociexacsdbnode-qdhic4 job

Completed backup_config_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running save_local_backup_on_node-ociexacsdbnode-qdhic4 job

Completed save_local_backup_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running stop_db_instances_on_node-ociexacsdbnode-qdhic4 job

Completed stop_db_instances_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic4 job

Completed run_rootcrs_prepatch_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running stop_tfa_on_node-ociexacsdbnode-qdhic4 job

Completed stop_tfa_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running stop_processes_on_node-ociexacsdbnode-qdhic4 job

Completed stop_processes_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running remove_home_on_node-ociexacsdbnode-qdhic4 job

Completed remove_home_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running copy_patched_home_from_local_node-ociexacsdbnode-qdhic4 job

Completed copy_patched_home_from_local_node-ociexacsdbnode-qdhic4 job

-----------------

Running unpackage_config_backup_on_node-ociexacsdbnode-qdhic4 job

Completed unpackage_config_backup_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic4 job

Completed run_rootcrs_postpatch_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running start_db_instances_on_node-ociexacsdbnode-qdhic4 job

Completed start_db_instances_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running disable_diagsnap_on_node-ociexacsdbnode-qdhic4 job

Completed disable_diagsnap_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running restore_tfa_status_on_node-ociexacsdbnode-qdhic4 job

Completed restore_tfa_status_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running post_patch_updates_on_node-ociexacsdbnode-qdhic4 job

Completed post_patch_updates_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running remove_local_backup_on_node-ociexacsdbnode-qdhic4 job

Completed remove_local_backup_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running remove_local_patched_home_on_node-ociexacsdbnode-qdhic4 job

Completed remove_local_patched_home_on_node-ociexacsdbnode-qdhic4 job

-----------------

Running cleanup_patched_home_backup job

Completed cleanup_patched_home_backup job

-----------------

Running post_patch_validation job

Completed post_patch_validation job

-----------------

Running update_creg job

Completed update_creg job

-----------------

Running release_lock job

Completed release_lock job

-----------------

Running generate_system_details job

Completed generate_system_details job

dbaascli execution completed

You have new mail in /var/spool/mail/root

 

5.Verify Grid Version Across Cluster Nodes

[root@ociexacsdbnode-qdhic1 ~]# dbaascli grid getDetails

DBAAS CLI version 23.1.2.0.0

Executing command grid getDetails

Job id: 043f2f65-2ba9-49bb-954a-e21ae0acb78f

Session log: /var/opt/oracle/log/grid/getDetails/dbaastools_2023-04-03_10-56-47-PM_351301.log

{

  "createTime" : 1680585364000,

  "updateTime" : 1680585364000,

  "scanListenerTCPPorts" : [ 1521 ],

  "scanListenerTCPSPorts" : [ 2484 ],

  "giNodeLevelDetails" : {

    "ociexacsdbnode-qdhic4" : {

      "nodeName" : "ociexacsdbnode-qdhic4",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.18.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic3" : {

      "nodeName" : "ociexacsdbnode-qdhic3",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.18.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic2" : {

      "nodeName" : "ociexacsdbnode-qdhic2",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.18.0.0.0",

      "status" : null

    },

    "ociexacsdbnode-qdhic1" : {

      "nodeName" : "ociexacsdbnode-qdhic1",

      "homePath" : "/u01/app/19.0.0.0/grid",

      "version" : "19.18.0.0.0",

      "status" : null

    }

  },

  "messages" : [ ]

}

dbaascli execution completed

[root@ociexacsdbnode-qdhic1 ~]#