Why APEX 26.1?

 

Why APEX 26.1? 🚀

Oracle APEX 26.1 is all about building better applications faster—with less code and more intelligence.

In this session, we’ll take a quick look at what’s new in APEX 26.1 and, wherever possible, demonstrate these capabilities in action.

🔹 Build applications faster
Speed up application development with new capabilities designed to reduce development effort.

🤖 Leverage AI to accelerate development
Explore how AI can help developers move faster, generate solutions, and focus more on business value.

⚡ Increase productivity with App Builder enhancements
New improvements make the development experience smoother and more productive.

🤝 Simplify collaboration with APEXlang
Discover how APEXlang can make it easier for teams to work together and communicate around application development.

🧩 Write less code with declarative features
Do more through APEX’s low-code, declarative approach—reducing the need for custom code.

🌍 90+ community-driven improvements
APEX 26.1 also brings a wide range of improvements inspired by the Oracle APEX community and real-world developer feedback.

🎯 Why should you care?
Because APEX continues to evolve beyond just being a low-code platform—it is becoming a powerful environment for building modern, intelligent, and enterprise-ready applications faster.

Join us to explore “Why APEX 26.1?” with a practical look at the latest features and improvements.

#OracleAPEX #APEX261 #Oracle #LowCode #AI #ApplicationDevelopment #OracleDatabase #Cloud #Developers #APEXCommunity #EnterpriseApplications #LowCodeDevelopment

🚀 LIVE ONLINE WEBINAR | Enterprise Manager 24ai — Is It the BIG SHOT?

Oracle Enterprise Manager has been a trusted companion for DBAs for years. But with Enterprise Manager 24ai, things are getting even more interesting. 🤖🚀

So, the big question is:

🔥 Enterprise Manager 24ai — Is It Really the BIG SHOT?

Join me for an interactive session where we’ll go beyond the feature list and explore what EM 24ai actually brings to the table for DBAs, Cloud DBAs, and IT Operations teams.

🎯 What we’ll explore:

• What’s new in Enterprise Manager 24ai?
• AI-driven monitoring and intelligent insights
• Database monitoring & performance management
• Automation and day-to-day DBA operations
• Hybrid & Cloud database management
• Real-world use cases from 10+ years of OEM experience
• How EM can make a DBA’s life easier
• And the big question — Is EM 24ai really the BIG SHOT? 😎

🎙️ Speaker:
Shashi Ranjan Singh
Lead Cloud DBA | 10+ Years of Oracle Enterprise Manager Experience
🏆 Oracle ACE Pro Member
☁️ Lead Cloud DBA
💡 Oracle DBA & Automation Enthusiast

📅 Date: Sunday, 18th September 2026
⏰ Time: 11:00 AM IST
💻 Mode: Online Webinar

📩 To Register:
shashidba1208@gmail.com

Whether you are an Oracle DBA, Cloud DBA, IT Operations professional, or simply curious about where Enterprise Manager is heading — this session is for you!

👉 Come with your questions. Leave with practical insights.

Enterprise Manager 24ai — Is it the BIG SHOT?
Let’s find out together! 🚀

#Oracle #OracleEnterpriseManager #OEM24ai #EnterpriseManager #OracleDBA #CloudDBA #DatabaseAdministration #OracleACE #OracleACEPro #DBACommunity #AIOUG #Webinar #OracleDatabase #Automation #AI #CloudComputing

The Migration Project That Changed My Career

After almost 5 years of my Oracle journey, I joined HCL and got the opportunity to work on a Database Migration Project.

At that time, I didn't realize how important this project would become in my career.

Looking back now, I can confidently say — this project was one of the biggest turning points in my Oracle journey.

It was not just about migrating databases from one place to another. It was where I got the chance to learn the complete lifecycle of an Oracle database.

DB Creation? ✅
Schema creation? ✅
Objects? ✅
Data Guard setup and troubleshooting? ✅
GoldenGate setup and maintenance? ✅
OEM setup and monitoring? ✅
RMAN backup and restore? ✅
ZDLRA? ✅
PSU patching? ✅
Database upgrades? ✅

Honestly, you name an Oracle technology or activity, and somehow it was part of that migration project! 😄

And that's what made the project so special for me.

I learned not only how to perform these activities, but also why they matter in a real production environment. I learned how to troubleshoot when things don't go as planned, how to handle critical databases, and most importantly, how to take ownership.

There were long days, challenging migrations, unexpected issues, troubleshooting calls and plenty of learning along the way.

But every challenge added something to my experience.

That project gave me a strong foundation, and many of the things I learned there are still helping me today.

Five years into my Oracle journey, I thought I was just joining another project.

I didn't know I was joining a project that would shape the next chapter of my career.

Even today, I am still counting the lessons from that project. ❤️

Sometimes, a project is more than just a project.
Sometimes, it becomes a part of your career story.

#OracleDBA #OracleDatabase #DatabaseMigration #HCL #DataGuard #GoldenGate #OEM #RMAN #ZDLRA #OracleCommunity #DBALife #CareerJourney #LearningNeverStops

Fun Fact: How My DBA Journey Started 😄

 

12 years ago, I started my journey as a DBA — with absolutely zero knowledge about Oracle. 😄

One of my old friends suggested my name for a DBA role and referred me for the opportunity. I still remember asking him:

“What exactly is a DBA?” 🤔

And his answer?

“Data Browse Associates.” 😂

I believed him!

It took me almost 2–3 months to finally realize that DBA actually meant Database Administrator. 🤣

What started as a referral, without even knowing what Oracle or DBA really meant, slowly turned into a journey of learning, troubleshooting, late-night production calls, database outages, Data Guard, RAC, GoldenGate, performance tuning, and countless “ORA-” errors. 😅

Looking back after 12 years, it’s amazing to think that a simple recommendation from an old friend completely changed my career.

Sometimes, the best journeys start when you don't even know where you're going. ❤️

And yes… I still remember “Data Browse Associates.” 😂

#OracleDBA #OracleDatabase #DBALife #12Years #CareerJourney #FunFact #DatabaseAdministrator #OracleCommunity

ORA-19809: Limit Exceeded for Recovery Files

 

Error

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim xx bytes disk space from xx limit

---

What does this error mean?

This error means the Fast Recovery Area (FRA) has become full.

Oracle stores the following files in the FRA:

• Archive Logs
• Flashback Logs
• RMAN Backups
• Control File Autobackups
• Incremental Backups

When the FRA reaches its configured size (DB_RECOVERY_FILE_DEST_SIZE), Oracle cannot create new archive logs. As a result:

• Database transactions may stop
• Log switches fail
• RMAN backups fail
• Data Guard redo transport may stop

This is one of the most common production issues for Oracle DBAs.

---

Symptoms

You may see errors like:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 104857600 bytes disk space

ORA-16038: log cannot be archived

ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.

Users may report:

• Application is hanging
• Database is not responding
• New transactions are failing

---

Step 1: Check FRA Usage

-- Size, usage, Reclaimable space used
SELECT
ROUND((A.SPACE_LIMIT / 1024 / 1024 / 1024), 2) AS FLASH_IN_GB,
ROUND((A.SPACE_USED / 1024 / 1024 / 1024), 2) AS FLASH_USED_IN_GB,
ROUND((A.SPACE_RECLAIMABLE / 1024 / 1024 / 1024), 2) AS FLASH_RECLAIMABLE_GB,
SUM(B.PERCENT_SPACE_USED) AS PERCENT_OF_SPACE_USED
FROM
V$RECOVERY_FILE_DEST A,
V$FLASH_RECOVERY_AREA_USAGE B
GROUP BY
SPACE_LIMIT,
SPACE_USED ,
SPACE_RECLAIMABLE ;

Example:

FLASH_IN_GB FLASH_USED_IN_GB FLASH_RECLAIMABLE_GB PERCENT_OF_SPACE_USED ----------- ---------------- -------------------- ---------------------        1024           351.01               339.91                 34.28

---

Step 2: Check Archive Destination

ARCHIVE LOG LIST;

or

show parameter db_recovery_file_dest
SQL> SQL> SQL>
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +RECO_FLEXSAND01
db_recovery_file_dest_size           big integer 2T

---

Step 3: Check FRA File Usage

-- FRA Occupants
SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;
SQL> SQL> SQL>
FILE_TYPE               PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES     CON_ID
----------------------- ------------------ ------------------------- --------------- ----------
CONTROL FILE                             0                         0               1          0
REDO LOG                                 0                         0               0          0
ARCHIVED LOG                            .5                         0              64          0
BACKUP PIECE                           .02                       .02               7          0
IMAGE COPY                               0                         0               0          0
FLASHBACK LOG                        16.62                     16.58            1734          0
FOREIGN ARCHIVED LOG                     0                         0               0          0
AUXILIARY DATAFILE COPY                  0                         0               0          0
 
8 rows selected.

---

Solution 1: Increase FRA Size (Recommended)

If storage is available:

Check current value:

SHOW PARAMETER db_recovery_file_dest_size;
Increase FRA:
alter system set db_recovery_file_dest='+RECO_FLEXSAND01' scope=both sid='*';
alter system set db_recovery_file_dest_size=1536G scope=both sid='*';
Verify:
SHOW PARAMETER db_recovery_file_dest_size;

SQL> show parameter db_reco
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      +RECO_FLEXSAND01
db_recovery_file_dest_size           big integer 1536G
SQL>

---

Solution 2: Delete Old Archive Logs Using RMAN

Open RMAN:

rman target /

Delete expired archives:

DELETE EXPIRED ARCHIVELOG ALL;

Delete archives older than 7 days:

DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';

Delete archives already backed up once:

DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DISK;

---

Solution 3: Crosscheck RMAN Repository

Sometimes RMAN thinks files exist when they have already been deleted.

CROSSCHECK ARCHIVELOG ALL;

DELETE EXPIRED ARCHIVELOG ALL;

---

Solution 4: Remove Obsolete Backups

DELETE OBSOLETE;

This removes backups that are no longer required based on the RMAN retention policy.

---

Solution 5: Disable Flashback (If Not Required)

Check status:

SELECT FLASHBACK_ON FROM V$DATABASE;

Disable:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE FLASHBACK OFF;
ALTER DATABASE OPEN;

Note: Disable Flashback only if your recovery strategy allows it.

---

Solution 6: Move FRA to a Larger Disk

alter system set db_recovery_file_dest='+FRA' scope=both sid='*';

---

Verify the Issue is Resolved

Check FRA usage again:

SELECT
SPACE_LIMIT/1024/1024 AS FRA_SIZE_MB,
SPACE_USED/1024/1024 AS USED_MB
FROM V$RECOVERY_FILE_DEST;

Force an archive log:

ALTER SYSTEM SWITCH LOGFILE;

If the command succeeds without errors, the issue is resolved.

---

Preventive Actions:

• Monitor FRA usage in OEM or a monitoring tool.
• Configure alerts when FRA usage exceeds 80%.
• Schedule regular RMAN backup and archive log cleanup jobs.
• Periodically review backup retention policies.
• Ensure sufficient FRA capacity based on archive log generation.

Oracle Database: Convert Between ARCHIVELOG and NOARCHIVELOG Mode

 Step-by-Step Guide 

---

Purpose

This document explains how to convert an Oracle database:

• From NOARCHIVELOG to ARCHIVELOG
• From ARCHIVELOG to NOARCHIVELOG

The steps are written in simple language so beginners and production DBAs can easily understand the process.

---

What is ARCHIVELOG Mode?

When the database runs in ARCHIVELOG mode, Oracle saves a copy of every completed redo log before it is reused.

These archive logs are required for:

• Database backup and recovery
• Point-in-Time Recovery (PITR)
• RMAN Online Backup
• Oracle Data Guard
• Flashback Database

Without archive logs, recovery options are very limited.

---

Step 1: Check the Current Database Mode

Connect to the database.

sqlplus / as sysdba

Run:

archive log list;

SELECT log_mode FROM v$database;

---

Scenario 1: Convert NOARCHIVELOG to ARCHIVELOG

Step 1: Configure Archive Log Location

Choose a location where archive logs will be stored.

Example:

ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/archive'
SCOPE=SPFILE;

You can verify:

SHOW PARAMETER log_archive_dest;

---

Step 2: Shutdown the Database

SHUTDOWN IMMEDIATE;

For RAC
srvctl stop database -d <DBNAME>

---

Step 3: Start Database in Mount Mode

STARTUP MOUNT;

For RAC
srvctl start database -d <DBNAME> -o mount

---

Step 4: Enable ARCHIVELOG Mode

sqlplus / as sysdba
select name, open_mode from v$database;
ALTER DATABASE ARCH0IVELOG;

---

Step 5: Open the Database

ALTER DATABASE OPEN;

For RAC
srvctl stop database -d <DBNAME>
srvctl start database -d <DBNAME>

---

Step 6: Verify ARCHIVELOG Mode

ARCHIVE LOG LIST;

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u01/app/oracle/archive

SELECT log_mode FROM v$database;

ARCHIVELOG

---

Step 7: Test Archive Log Generation

Force a log switch.

ALTER SYSTEM SWITCH LOGFILE;

Check generated archive logs.

ARCHIVE LOG LIST;

Or at the OS level:

ls -ltr /u01/app/oracle/archive

You should see a new archive log file.

---

Scenario 2: Convert ARCHIVELOG to NOARCHIVELOG

---

Step 1: Shutdown Database

SHUTDOWN IMMEDIATE;

For RAC
srvctl status database -d <DBNAME>
srvctl stop database -d <DBNAME>

---

Step 2: Start Database in Mount Mode

STARTUP MOUNT;

For RAC
srvctl start database -d <DBNAME> -o mount

---

Step 3: Disable ARCHIVELOG

ALTER DATABASE NOARCHIVELOG;

---

Step 4: Open the Database

ALTER DATABASE OPEN;

For RAC
srvctl stop database -d <DBNAME>
srvctl start database -d <DBNAME>

---

Step 5: Verify Database Mode

ARCHIVE LOG LIST;

SELECT log_mode FROM v$database;

---

Estimate Archive Log Space Requirement

Use the following query to estimate daily archive log generation:

SELECT A.*,
ROUND(A.Count# * B.AVG# / 1024 / 1024 / 1024) AS Daily_Avg_GB
FROM
(
    SELECT
        TO_CHAR(first_time,'YYYY-MM-DD') DAY,
        COUNT(*) Count#,
        MIN(recid) Min#,
        MAX(recid) Max#
    FROM v$log_history
    GROUP BY TO_CHAR(first_time,'YYYY-MM-DD')
) A,
(
    SELECT
        AVG(bytes) AVG#
    FROM v$log
) B
ORDER BY DAY;

This helps estimate how much storage is needed for archive logs each day.

Oracle Grid Infrastructure Rolling Upgrade from 19c to Oracle AI Database 23.26

---

Document Information

Item	Details
Upgrade Type	Rolling Grid Infrastructure Upgrade
Source Version	Oracle Grid Infrastructure 19c (19.31 RU)
Target Version	Oracle AI Database Grid Infrastructure 23.26
Platform	Oracle Linux 8
Cluster Type	Two-Node Oracle RAC
Downtime	Database downtime required; Cluster services upgraded in rolling mode
Upgrade Method	Out-of-Place Upgrade

---

1. Purpose

This document describes the procedure for upgrading Oracle Grid Infrastructure from Oracle Database 19c to Oracle AI Database Grid Infrastructure 23.26 using an out-of-place rolling upgrade.

The objective is to introduce the new Grid Infrastructure software while preserving the existing Oracle Home until the upgrade is fully validated. This approach minimizes operational risk and provides a rollback option if required.

---

2. Environment Details

Component	Value
Current GI Home	/u01/app/19.3.0/grid
New GI Home	/u01/app/26.0.0/grid
Grid Base	/u01/app/26aigrid
ASM Storage	Oracle ASM
Cluster Nodes	ricsand03t, ricsand04t
Oracle Linux	8.x
Grid Owner	grid
Inventory Owner	oinstall

---

3. Pre-Upgrade Activities

Before starting the upgrade, perform the following validations.

Verify Cluster Version

crsctl query crs activeversion -all
crsctl query crs softwareversion -all

Expected Output

Oracle Clusterware active version : 19.0.0.0.0
Oracle Clusterware software version : 19.0.0.0.0

This confirms that every node in the cluster is running the same Grid Infrastructure version before beginning the upgrade.

---

4. Verify ASM Compatibility

Login as the Grid user.

sqlplus / as sysasm

Check the ASM compatibility attributes.

SELECT
    name,
    compatibility,
    database_compatibility
FROM v$asm_diskgroup;

Example

DATA
OCR
RECO

If the compatible.rdbms attribute is lower than 19.0.0.0.0, update it before continuing.

ALTER DISKGROUP DATA
SET ATTRIBUTE 'compatible.rdbms'='19.0.0.0.0';

Repeat the command for all ASM disk groups.

This step ensures the disk groups meet the minimum compatibility requirements for the upgrade.

---

5. Create New Grid Infrastructure Home

Create a new Oracle Home instead of upgrading the existing one.

On both cluster nodes:

mkdir -p /u01/app/26aigrid
mkdir -p /u01/app/26.0.0/grid

chown grid:oinstall /u01/app/26aigrid
chown root:oinstall /u01/app/26.0.0
chown grid:oinstall /u01/app/26.0.0/grid

Keeping the new software in a separate Oracle Home provides an easy rollback path if the upgrade cannot be completed successfully.

---

6. Copy and Extract Oracle Grid Software

Copy the installation archive into the new Grid Home.

cp LINUX.X64_2326100_grid_home.zip /u01/app/26.0.0/grid

Change ownership.

chown grid:oinstall LINUX.X64_2326100_grid_home.zip

Login as the Grid user.

su - grid

Extract the software.

cd /u01/app/26.0.0/grid

unzip LINUX.X64_2326100_grid_home.zip

At this stage, the new Grid Infrastructure home is ready for validation.

---

7. Run Cluster Verification Utility (CVU)

Before upgrading, Oracle strongly recommends validating the environment using CVU.

Execute:

/u01/app/26.0.0/grid/runcluvfy.sh \
stage -pre crsinst \
-upgrade \
-rolling \
-src_crshome /u01/app/19.3.0/grid \
-dest_crshome /u01/app/26.0.0/grid \
-dest_version 23.26.1.0.0 \
-fixup \
-verbose

The utility verifies:

• Operating system compatibility

• Network configuration

• ASM configuration

• OCR and Voting Disk health

• User equivalence

• Required packages

• Kernel parameters

• Disk permissions

• Time synchronization

• Cluster integrity

The validation should complete with:

Pre-check for cluster services setup was successful.

Any reported failures should be resolved before continuing with the upgrade.

---

8. Perform a Dry Run

Run the installer in validation mode.

export DISPLAY=<display_server>

./gridSetup.sh -dryRunForUpgrade

The dry run simulates the upgrade without modifying the existing cluster configuration.

This step confirms that all prerequisites have been satisfied before the actual upgrade begins.

---

9. Stop All RAC Databases

Stop every database managed by Clusterware.

srvctl stop database -d cjordt1

srvctl stop database -d ctjswing

Verify that no databases remain online before proceeding.

---

10. Start the Grid Infrastructure Upgrade

Launch the installer.

/u01/app/26.0.0/grid/gridSetup.sh

Select:

• Upgrade Oracle Grid Infrastructure

• Rolling Upgrade

• Existing Cluster

• New Oracle Home

The installer performs prerequisite checks before copying the new binaries.

When prompted, execute the generated root scripts on each node in the order specified by the installer.

---

11. Root Script Execution

Execute as root.

/u01/app/26.0.0/grid/root.sh

The installer upgrades one node at a time while keeping cluster services available on the remaining node.

Monitor the progress until both nodes complete successfully.

---

12. Post-Upgrade Validation

Verify the active Clusterware version.

crsctl query crs activeversion

Verify the software version.

crsctl query crs softwareversion

Check Cluster Resources.

crsctl stat res -t

Verify ASM.

srvctl status asm -detail

Display ASM Disk Groups.

asmcmd lsdg

Verify SCAN Listener.

srvctl status scan

Validate OCR.

ocrcheck

Verify Voting Disk.

crsctl query css votedisk

All resources should report ONLINE, and OCR and Voting Disks should be healthy.

---

13. Post-Upgrade Health Check

After the upgrade:

• Confirm Clusterware is running on all nodes.

• Verify ASM instances are mounted.

• Ensure OCR and Voting Disks are healthy.

• Start all RAC databases.

• Validate SCAN listeners and VIPs.

• Confirm application connectivity.

• Review Grid Infrastructure alert logs for unexpected errors.

• Monitor cluster stability for several hours after the upgrade.

---

14. Rollback Strategy

Because this is an out-of-place upgrade, the original 19c Grid Home remains intact until the upgrade is finalized.

If a critical issue is encountered before completing the upgrade, Oracle supports rolling back to the previous Grid Infrastructure home by following the documented rollback procedure. Rollback should only be performed after reviewing the installer logs and Oracle Support recommendations.

---

15. Best Practices

• Perform a full OCR backup before the upgrade.

• Verify recent RMAN backups for all databases.

• Run CVU until all mandatory checks pass.

• Keep the existing Grid Home unchanged until validation is complete.

• Upgrade during a planned maintenance window with application teams on standby.

• Validate CRS, ASM, OCR, Voting Disk, and SCAN services before releasing the environment to users.

• Archive installer logs and upgrade reports for audit and future reference.