Monday, April 13, 2026

HA (High Availability ) vs DR (Disaster Recovery) – What’s the Difference ?

 

HA vs DR – What’s the Difference?

HA and DR solve different problems.
Many outages happen because teams assume one replaces the other.


1. Simple One‑Line Difference (Easy to Remember)

AspectHigh Availability (HA)Disaster Recovery (DR)
PurposeSurvive local failuresSurvive site‑level disasters
ScopeSame data center / regionDifferent data center / region
DowntimeSeconds to minutesMinutes to hours
Data LossNoneLow to none
AutomationVery highMedium to high

📌 Key rule

HA handles “small failures often”
DR handles “big failures rarely”


2. High Availability (HA) – Deep Explanation

✅ What HA Protects Against

  • Database instance crash
  • Node / VM failure
  • OS kernel panic
  • Network card failure
  • Storage path failure

HA does NOT protect against

  • Data center fire/flood
  • Power grid failure
  • Region‑wide network outage
  • Human error affecting entire site

3. Oracle HA – How It Works

Example: Oracle RAC (Classic HA)

Users
  │
Load Balancer
  │
┌───────────────┐
│ Oracle RAC    │  Same Data Center
│ Node 1        │
│ Node 2        │
│ Shared Storage│
└───────────────┘

What Happens During Failure?

  • Node 1 crashes
  • Node 2 continues serving traffic
  • Sessions failover automatically
  • Downtime: seconds

This is High Availability


Oracle HA Tools

  • Oracle RAC
  • Oracle Restart
  • ASM redundancy
  • FAN / TAF
  • Application Continuity

HA Metrics

  • RTO: Seconds
  • RPO: Zero
  • Geography: Single site

4. Disaster Recovery (DR) – Deep Explanation

✅ What DR Protects Against

  • Data center outage
  • Fire, flood, earthquake
  • Power grid failure
  • Ransomware
  • Massive human error

DR does NOT protect against

  • Single node crash (too slow)
  • Local HA events

5. Oracle DR – How It Works

Example: Oracle Data Guard

Primary Data Center
┌────────────────────┐
│ Oracle DB Primary  │
└─────────┬──────────┘
          │ Redo Apply
DR Data Center
┌─────────▼──────────┐
│ Oracle Standby DB  │
└────────────────────┘

What Happens During Failure?

  • Primary site is lost
  • Standby is activated
  • Applications reconnect
  • Downtime: minutes

This is Disaster Recovery


Oracle DR Tools

  • Oracle Data Guard (sync/async)
  • Active Data Guard
  • Fast‑Start Failover (FSFO)
  • RMAN backups (last resort)

DR Metrics

  • RTO: Minutes–Hours
  • RPO: Seconds–Minutes
  • Geography: Separate site / region

6. HA vs DR – Side‑by‑Side Technical Comparison

DimensionHADR
DistanceMetersKilometers
Failure FrequencyHighLow
AutomationAutomaticSemi/automatic
CostMediumHigh
ComplexityInfrastructureOperations + Infrastructure
ExampleRACData Guard

7. Real‑World Example (Very Important)

Scenario: Payroll System on Oracle

✅ With HA only (RAC)

  • DB node crashes → system survives
  • Storage fails → system survives
  • Entire DC power down → system DOWN

❌ DR needed


✅ With DR only (Data Guard)

  • DB node crashes → outage until restart
  • OS hung → outage
  • Whole DC lost → system recovered

❌ HA needed


✅ With HA + DR (Correct Design)

     Users
       │
Application Layer (retry & continuity)
       │
────────── Primary Site ──────────
 Oracle RAC (HA)
       │
   Sync/Async Redo
────────── DR Site ──────────
 Data Guard Standby (DR)

✅ Node failure → RAC
✅ DB crash → RAC
✅ Site failure → DG

📌 This is enterprise‑grade resilience


8. Common Misconceptions (Audit Findings)

❌ “We have RAC, so DR is not needed”
✅ RAC ≠ site failure protection

❌ “We have DR, so HA is unnecessary”
✅ DR failover is too slow for local failures

❌ “Availability % is the same as DR”
✅ Availability ≠ recoverability


9. Architectural Rule of Thumb (Remember This)

HA keeps the system running
DR brings the system back


10. Interview‑ & Review‑Ready Answer (Use This)

“High Availability addresses localized infrastructure failures within a site using technologies like Oracle RAC to provide automatic and immediate recovery. Disaster Recovery addresses catastrophic site‑level failures using geographically separated systems such as Oracle Data Guard, focusing on business continuity rather than instant recovery.”


11. One‑Line Executive Summary

HA = protect uptime
DR = protect the business

Oracle Database Resiliency Building Blocks and Availability Architecture - Part 3

 

1. What Does 8‑Nines Mean in Reality?

AvailabilityMax Downtime / Year
99.999% (5‑nines)~5.26 minutes
99.9999% (6‑nines)~31.5 seconds
99.99999% (7‑nines)~3.15 seconds
99.999999% (8‑nines)~315 milliseconds

Important reality check:
315 milliseconds per year is less than a single TCP retry, GC pause, storage hiccup, or cluster reconfiguration.


2. Why Oracle (or Any RDBMS) Cannot Truly Reach 8‑Nines

Hard Physical Constraints

Even with perfect design, you cannot eliminate:

  • CPU scheduling jitter
  • Kernel context switches
  • Network packet loss / retransmission
  • Storage micro‑latency spikes
  • Cluster membership rebalancing
  • Planned operations (patching, cert rotation)

📌 Any one of these already exceeds the 315 ms annual budget.


3. Maximum Practical Oracle Availability (Real World)

This is the absolute upper bound Oracle can practically reach:

~5‑nines (sometimes stretched to “6‑nines” on paper)

And even that requires exceptional discipline.


4. “Would‑Be” 8‑Nines Oracle Architecture (Theoretical)

If someone asks for 8‑nines, this is what they are implicitly demanding — even though it still won’t truly reach it.

Extreme Oracle MAA++ Architecture

Global Traffic Manager (Anycast / DNS / GSLB)
        │
Active‑Active Application Tier (Stateless)
        │
───────────────── Region A ─────────────────
   Oracle RAC (4–8 nodes)
   Persistent Memory (PMEM)
   Zero‑latency Storage
        │
Synchronous Redo Replication
        │
───────────────── Region B ─────────────────
   Oracle RAC (4–8 nodes)
   Active Data Guard
        │
Bidirectional Logical Replication
(Oracle GoldenGate Active‑Active)

Required Components (All Mandatory)

LayerRequirement
DBRAC + ADG + GoldenGate
ReplicationActive‑Active logical replication
StoragePMEM / NVMe‑oF
Network<1 ms RTT, zero packet loss
AppFully idempotent, retry‑safe
OpsNo humans in the loop
PatchingRolling, non‑blocking
MonitoringPredictive, not reactive

🔴 Even this still breaks the 315 ms/year limit due to physics.


5. Oracle‑Specific Limits You Cannot Bypass

RAC Limits

  • Global Cache transfers cause micro‑stalls
  • Node eviction events
  • CRSD reconfigurations

Data Guard Limits

  • Sync redo still involves network IO
  • FSFO detection time > hundreds of ms

GoldenGate Limits

  • Transaction ordering conflicts
  • Commit coordination delays
  • Metadata checkpoints

📌 Oracle itself never claims beyond five‑nines for database availability.


6. What “8‑Nines” Actually Means in Practice (Translation)

When business says 8‑nines, they usually mean:

What They SayWhat They Actually Want
8‑ninesNo visible user errors
Always onAutomatic failover
Zero downtimeZero manual intervention
No outagesGraceful degradation

This is an application‑experience goal, not a database SLA.


7. Correct Way to Respond as a Database Architect

✅ Architecture‑Correct Statement (Use This)

“99.999999% availability is not technically achievable for a stateful RDBMS due to physical and operational constraints. The highest practical availability achievable with Oracle is five‑nines, provided RAC, Data Guard, automated failover, and application continuity are all implemented.”

✅ Offer a Better Metric

“Instead of availability percentage, we recommend defining success using RTO (seconds), RPO (zero), and user‑perceived errors, which is how real‑world resilience is measured.”


8. Final Truth (Very Important)

Availability above five‑nines is no longer a database problem.
It becomes:

  • An application design problem
  • A business expectation problem
  • A physics problem

Oracle can be part of the solution —
but it cannot bend time, networks, or matter.

Oracle Database Resiliency Building Blocks and Availability Architecture - Part 2



What Does Nines Mean in Reality?

AvailabilityMax Downtime / Year
99.999% (5‑nines)~5.26 minutes
99.9999% (6‑nines)~31.5 seconds
99.99999% (7‑nines)~3.15 seconds
99.999999% (8‑nines)~315 milliseconds

 

1. RTO / RPO → Oracle Architecture Mapping (Very Important)

Availability numbers are meaningless unless tied to RTO & RPO

Definitions (quick refresher)

  • RTO (Recovery Time Objective)
    → How long the system can be down
  • RPO (Recovery Point Objective)
    → How much data loss is acceptable

Availability vs RTO/RPO

AvailabilityRTORPOWhat Business Is Really Asking For
99.9%1–8 hrsHours“Recover today is fine”
99.99%5–30 minsSeconds–Minutes“Don’t lose much data”
99.999%Seconds–1 minZero / Near‑Zero“Users must not notice”

Oracle Architecture Required (Truth Table)

RTORPORequired Oracle Architecture
HoursHoursRMAN backups only
<1 hr<15 minData Guard (async)
<30 minNear‑zeroData Guard (sync)
SecondsZeroRAC + ADG + FSFO
SecondsZero + no app errorsRAC + ADG + FSFO + App Continuity
Zero downtime upgradesZeroAdd GoldenGate

📌 Key Insight (Interview / Review Gold):

“Five‑nines availability is achieved by eliminating manual decision points, not by adding more hardware.”


2. Oracle MAA Architecture – Clear Mental Diagram

✅ 99.99% Architecture (Most Enterprises)

           ┌──────────────────────────┐
           │        Application        │
           └──────────┬───────────────┘
                      │
          ┌───────────▼───────────┐
          │   Oracle RAC (2 nodes) │  Primary Site
          │   Shared Storage       │
          └───────────┬───────────┘
                      │ Redo Apply
          ┌───────────▼───────────┐
          │ Data Guard Standby     │  DR Site
          │ (Physical Standby)     │
          └───────────────────────┘

Characteristics

  • Node failure → handled by RAC (seconds)
  • DB corruption → failover to standby (minutes)
  • Site outage → manual / semi‑automatic failover

✅ 99.999% Mission‑Critical Architecture

                        ┌────────────────────┐
                        │    Applications    │
                        │ (App Continuity +  │
                        │  FAN enabled)      │
                        └─────────┬──────────┘
                                  │
            ┌─────────────────────▼─────────────────────┐
            │          Oracle RAC (3+ nodes)             │
            │          Primary Data Center               │
            └─────────────────────┬─────────────────────┘
                                  │ SYNC Redo
            ┌─────────────────────▼─────────────────────┐
            │       Active Data Guard Standby             │
            │       (Read-only workloads)                 │
            └─────────────────────┬─────────────────────┘
                                  │
                    ┌─────────────▼─────────────┐
                    │ FSFO Observer (3rd site)  │
                    │ Automatic Failover        │
                    └───────────────────────────┘

Optional extension

GoldenGate  →  zero-downtime migrations / upgrades

3. What Each Oracle Feature Buys You (Architect View)

FeatureEliminates Which Failure
Oracle RestartInstance crash
RACNode / instance failure
Data GuardDB corruption / site loss
Active Data GuardStandby query load + faster recovery
FSFOHuman decision delay
App ContinuityUser-visible errors
RMANLogical & catastrophic disasters

4. Common Mistakes (Seen in Audits)

❌ “We have RAC, so we are five‑nines”
✅ RAC ≠ DR ≠ five‑nines

❌ “Manual DG failover is acceptable”
✅ Manual failover ≠ five‑nines

❌ “Storage is highly available”
✅ Most outages are DB bugs, patches, humans

❌ “Five‑nines requested because business asked”
✅ Ask for RTO/RPO, not availability %


5. Audit‑Ready / Architecture Review Language (Reuse This)

You can literally paste these:

Availability Statement

“The database architecture aligns with Oracle Maximum Availability Architecture (MAA) principles and is designed to meet an RTO of <X> minutes and an RPO of <Y> seconds through RAC and Data Guard.”

DR Statement

“Site‑level resilience is achieved using Oracle Data Guard with synchronous redo transport and automated failover using Fast‑Start Failover.”

Risk Statement (Very Powerful)

“Achieving five‑nines availability requires application‑level continuity and operational automation. Without these, practical availability remains closer to four‑nines.”

Cost Justification

“The marginal cost of moving from 99.99% to 99.999% availability is disproportionately high due to operational and application complexity rather than database licensing alone.”

Oracle Database Resiliency Building Blocks and Availability Architecture - PART 1

 

1. What the “Nines” Mean (Availability vs Resiliency)

Availability is usually expressed as:

AvailabilityCommon NameAllowed Downtime / Year
99.9%Three‑nines~8.76 hours
99.99%Four‑nines~52.6 minutes
99.999%Five‑nines~5.26 minutes

👉 Higher nines = less tolerated downtime = much higher architectural complexity and cost


2. Oracle Database Resiliency Building Blocks

Before mapping architectures, these are the Oracle tools used:

  • Oracle Restart – single-node auto-restart
  • Oracle RAC – node-level high availability
  • Oracle Data Guard (DG) – site-level DR (physical standby)
  • Active Data Guard (ADG) – read-only standby + faster failover
  • Fast-Start Failover (FSFO) – automatic DG failover
  • Oracle GoldenGate – logical replication, near-zero data loss
  • Application Continuity / FAN – application resilience
  • Backup & Recovery (RMAN) – last line of defense

3. 99.9% Availability Architecture (Basic HA)

✅ Typical Scenario

  • Internal applications
  • Batch workloads
  • Non-customer-facing systems

🏗️ Oracle Architecture

  • Single Instance Oracle DB
  • Optional:
    • Oracle Restart
    • VM-level HA
  • Backups using RMAN
  • Manual recovery or failover

🔴 Failure Impact

Failure TypeOutcome
DB crashMinutes to hours
OS crashManual restart
Site failureRestore from backup

✅ Summary

  • Low cost
  • Manual intervention
  • Downtime acceptable

4. 99.99% Availability Architecture (Enterprise HA / DR)

✅ Typical Scenario

  • Core enterprise systems
  • ERP, HR, reporting platforms
  • Medium RTO / low RPO

🏗️ Oracle Architecture

Primary Site

  • Oracle RAC (2+ nodes)

DR Site

  • Oracle Data Guard (Physical Standby)
  • Optional Active Data Guard

Automation

  • Data Guard Broker
  • Semi‑automatic failover

🔴 Failure Impact

Failure TypeDowntime
Instance failureSeconds (RAC failover)
Node failureSeconds
DB corruptionMinutes
Site failure5–30 minutes

✅ Summary

  • Zero or near‑zero data loss
  • Fast failover
  • Moderate cost
  • Standard Oracle MAA pattern

5. 99.999% Availability Architecture (Mission‑Critical / Always‑On)

✅ Typical Scenario

  • Banking, trading, telecom
  • Customer-facing 24×7 platforms
  • Regulatory & SLA‑driven systems

🏗️ Oracle Architecture (MAA – Advanced)

Primary Site

  • Oracle RAC (3+ nodes)
  • Enterprise storage with redundancy

Standby Site

  • Active Data Guard with:
    • Fast-Start Failover (FSFO)
    • Observer on third site
  • Or Oracle GoldenGate (for near-zero downtime)

Application Layer

  • Application Continuity
  • FAN / TAF enabled

🔴 Failure Impact

Failure TypeDowntime
Instance failure<5 seconds
Node failure<10 seconds
DB failureAutomatic failover (seconds)
Site failure<1–2 minutes

✅ Summary

  • Automatic failover
  • Near-zero downtime
  • Zero or near-zero data loss
  • High cost & complexity
  • Requires disciplined operations

6. Side‑by‑Side Comparison (Oracle Focused)

Aspect99.9%99.99%99.999%
Oracle RAC
Data Guard
Active Data GuardOptional
GoldenGateOptional / ✅
Auto FailoverPartial
Manual OpsHighMediumVery Low
CostLowMediumVery High

7. Key Design Insight (Important)

You don’t achieve five‑nines by just adding technology.
You achieve it by combining:

  • Correct Oracle architecture
  • Application design
  • Network redundancy
  • Storage resilience
  • Well‑tested DR drills
  • Operational maturity

Most outages at 99.999% scale are human or process‑driven, not Oracle failures.

Wednesday, April 8, 2026

Oracle Data Guard 26ai New Features and Enhancements

 Oracle Data Guard 26ai (and 21c onwards) 

  • Faster role transitions – Reduces switchover and failover time by optimizing role change workflows
  • Minimized stall in Maximum Performance – Lowers commit latency while maintaining near‑real‑time protection.
  • Choice of Lag Type for Fast‑Start Failover – Allows failover decisions based on apply lag or transport lag.
  • Faster DML Redirection – Improves performance when redirecting writes during role transitions.
  • Fast‑Start Failover Observer Priority (21c) – Enables prioritized observers to control failover decisions.
  • Up to four Fast‑Start Failover Observers (21c) – Provides higher availability by supporting multiple observers.
  • Rolling Upgrade with Application Continuity – Enables zero‑downtime upgrades while preserving session state.
  • Multiple ASYNC connections – Improves redo transport throughput and resiliency with parallel async paths.
  • Automatic preparation of primary and standby – Automates configuration steps to simplify Data Guard setup.
  • Data Guard Broker PL/SQL API – Allows programmatic management and automation of Data Guard operations.
  • SQLcl support for Data Guard commands (21c) – Enables managing Data Guard directly from SQLcl.
  • ORDS support for Data Guard (21c) – Exposes Data Guard management and monitoring via REST APIs.
  • Show / edit all members at once – Simplifies configuration by allowing bulk updates across members.
  • JSON output for DGMGRL – Provides machine‑readable output for easier integration and automation.
  • Prevent standby databases from becoming primary – Enforces role protection to avoid unintended failovers.
  • Configuration and member tagging – Improves organization and identification of Data Guard components.
  • Automatic standby tempfile creation – Automatically synchronizes tempfiles between primary and standby.
  • PDB Recovery Isolation – Enables recovery operations at the individual PDB level without affecting others.
  • Easy AWR snapshots on the standby – Simplifies performance diagnostics directly on standby databases.
  • Strict database validation – Ensures configuration correctness before switchover or failover operations.
  • Switchover and Failover Readiness – Clearly reports whether the environment is safe for role transitions.
  • Easier tracking of role transitions – Enhances visibility and auditing of role change events.
  • New view V$DG_BROKER_PROPERTY – Provides real‑time visibility into Data Guard Broker properties.
  • New command: VALIDATE DGConnectIdentifier – Verifies network connectivity used by Data Guard.
  • Easier checking of Fast‑Start Failover configurations – Simplifies validation of FSFO setup and health.
  • Fast‑Start Failover Lag Histogram – Visualizes redo lag trends to fine‑tune failover settings.
  • Enhanced observer diagnostic – Improves troubleshooting with richer observer health and status data.
  • Fast‑Start Failover Configuration Validation – Proactively detects configuration issues before failures occur.
  • Offload AI Inference and Vector Search to Oracle Active Data Guard – Runs AI and vector workloads on standby to offload the primary.

Monday, March 23, 2026

Key Differences & 19c Best Practices (AMM and ASMM)

Key Differences between AMM and ASMM & 19c Best Practices


AMM (Automatic Memory Management) -  (MEMORY_TARGET):

How it works: Oracle automatically distributes memory between SGA and PGA.


Pros: Simplest to configure; dynamic resizing across both areas.


Cons: Incompatible with HugePages, which are crucial for performance in large systems. Can have issues with /dev/shm on Linux.


Recommendation: Suitable for testing or small instances (< 4GB SGA).


ASMM (Automatic Shared Memory Management) - (SGA_TARGET):

How it works: Oracle automatically tunes SGA components (buffer cache, shared pool) but PGA is managed separately.


Pros: Recommended for production; supports HugePages for better performance, reduces OS paging.


Cons: Requires manual tuning of PGA_AGGREGATE_TARGET.


19c Context: Oracle 19c generally recommends ASMM (using SGA_TARGET and PGA_AGGREGATE_TARGET) for production environments over AMM to ensure optimal memory management and stability


Which is better for minimizing swap usage? ASMM vs AMM

Which is better for minimizing swap usage?


 AMM (Automatic Memory Management)

  • MEMORY_TARGET 

 ASMM (Automatic Shared Memory Management) 

  • SGA_TARGET


In most real-world Oracle deployments, using manual memory management (i.e., SGA_TARGET + PGA_AGGREGATE_TARGET) results in lower swap usage than MEMORY_TARGET / MEMORY_MAX_TARGET.


Why MEMORY_TARGET causes more swap usage

Automatic Memory Management (AMM), which uses:


MEMORY_TARGET

MEMORY_MAX_TARGET


requires a Linux system to allocate a large shared memory segment plus additional OS memory for management.

On Linux, AMM uses /dev/shm (tmpfs), and if its size is less than MEMORY_TARGET, Oracle falls back to regular pages, increasing swap pressure.

Problems with MEMORY_TARGET:


Tends to cause kernel swapping due to dynamic resizing of SGA/PGA.

Additional overhead for memory rebalancing.

On NUMA servers, AMM can mismatch memory locality → more swap.

Oracle itself recommends NOT using AMM on production systems.


Oracle Docs: AMM is mainly recommended for small dev/test systems, not production.


Why SGA_TARGET results in lower swap usage

SGA_TARGET uses Automatic Shared Memory Management (ASMM).

Memory is allocated in huge pages (if enabled), giving performance and eliminating swap spikes.

With:


SGA_TARGET (or even SGA_MAX_SIZE)

PGA_AGGREGATE_TARGET


Oracle uses memory more predictably:


Benefits:


Stable memory footprint → no resizing storms.

Huge Pages support → swap is effectively zero.

No tmpfs (/dev/shm) dependency.

Fits well with modern Linux kernel memory management.


Oracle recommends ASMM for production databases.


Winner for swap control: SGA_TARGET (ASMM) If your goal is:

  •  avoid swap
  •  maintain predictable memory usage
  •  use huge pages
  •  ensure performance stability

Use SGA_TARGET + PGA_AGGREGATE_TARGET (ASMM).


Recommended Production Setup:


MEMORY_TARGET=0

MEMORY_MAX_TARGET=0


SGA_TARGET=<value>

SGA_MAX_SIZE=<value>


PGA_AGGREGATE_TARGET=<value>


Enable Huge Pages on Linux for optimal performance.


Monday, March 16, 2026

Oracle AI Database Free support Platforms and Connectivity

Oracle AI Database 26ai – Supported Free Platforms


The Oracle AI Database 26ai Free tier can be deployed on the following platforms:


  • Oracle Linux 8 (OL8 / RHEL 8)
  • Oracle Linux 9 (OL9 / RHEL 9)
  • Oracle Linux 8 for ARM (aarch64)
  • Docker / Podman
  • Oracle VirtualBox
  • Microsoft Windows (64‑bit)



Client Tools and Languages for Connecting to Oracle AI Database Free

You can connect to Oracle AI Database Free using a wide range of tools and programming languages:

Database Tools


  • SQLcl
  • SQL*Plus


Programming Languages


  • Java
  • Python
  • Node.js
  • C# / .NET
  • PHP
  • Ruby
  • Go



Official Reference

For detailed setup instructions and downloads, please refer to the official Oracle page:

🔗 https://www.oracle.com/in/database/free/get-started/

Thursday, March 12, 2026

How to switch/connect with other database (demo)?

 


postgres=#

postgres=#

postgres=#

postgres=# \c demo

You are now connected to database "demo" as user "postgres".

demo=#

demo=#

demo=# \l demo

 demo | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           |


How to create database in PostgreSQL ?

 

postgres=#

postgres=#

postgres=# create database demo;

CREATE DATABASE

postgres=#

postgres=# \l

 demo      | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           |

 postgres  | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           |

 template0 | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           | =c/postgres          +

           |          |          |                 |                    |                    |        |           | postgres=CTc/postgres

 template1 | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           | =c/postgres          +

           |          |          |                 |                    |                    |        |           | postgres=CTc/postgres


postgres=#

PostgreSQL : 'more' is not recognized as an internal or external command, operable program or batch file.

 postgres=#

postgres=#

postgres=#

postgres=# \l

'more' is not recognized as an internal or external command,

operable program or batch file.

postgres=#

postgres=#



postgres=# \l

'more' is not recognized as an internal or external command,

operable program or batch file.

postgres=#




This happens in psql on Windows when the MORE command is missing or overridden in the system PATH.

psql uses the system pager (more) to display long output like \l, \dt, etc.



postgres=#

postgres=# \pset pager off

Pager usage is off.

postgres=#

postgres=# \l

                                                            List of databases

   Name    |  Owner   | Encoding | Locale Provider |      Collate       |       Ctype        | Locale | ICU Rules |   Access privileges

-----------+----------+----------+-----------------+--------------------+--------------------+--------+-----------+-----------------------

 postgres  | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           |

 template0 | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           | =c/postgres          +

           |          |          |                 |                    |                    |        |           | postgres=CTc/postgres

 template1 | postgres | UTF8     | libc            | English_India.1252 | English_India.1252 |        |           | =c/postgres          +

           |          |          |                 |                    |                    |        |           | postgres=CTc/postgres

(3 rows)


postgres=#

postgres=#

Wednesday, March 11, 2026

Important Oracle Database License Audit Checklist

 Oracle Database License Audit Checklist 


1. Perform a Comprehensive Oracle Environment Inventory (On‑Prem & Cloud)

  • Catalog every Oracle database deployment, including production, development, testing, and disaster‑recovery environments.
  • Include all infrastructure types: physical servers, virtual machines, containers, and cloud-hosted databases.
  • Record the database edition (Standard Edition, Enterprise Edition) and version (e.g.11g,19c, 21c).



2. Verify License Entitlements and Agreements

  • Map each deployment to its corresponding license type (NUP, Processor‑based).
  • Use Oracle’s Core Factor Table to correctly calculate processor requirements.
  • Review legacy contracts, existing ULAs, and any embedded licensing rights that may impact compliance.



3. Assess Feature and Option Usage

  • Use automated tools/scripts to detect usage of chargeable features such as RAC, Partitioning, Advanced Compression, etc.
  • Confirm that all enabled features are properly licensed or disable those not in use.



4. Evaluate Virtualization and Cloud Architectures

  • Track virtual machine movement across hypervisors (e.g. VMware vSphere, Nutanix ).
  • Ensure hard partitioning or affinity rules are documented and enforced where required.
  • Review Oracle workloads running on public cloud IaaS platforms like AWS, Azure, or OCI to confirm licensing alignment.



5. Prepare an Accurate and Audit‑Ready Data Package

  • Validate all data generated by LMS (License Management Services) scripts before sharing externally.
  • Avoid running Oracle‑provided audit scripts without expert review.
  • Document all licensing interpretations, configuration decisions, and control measures for audit transparency.



Note :- 

We have to very careful run any script in environment before review with experts ...... 

Monday, February 16, 2026

Use Cases of Oracle Grid Control

 

Use Cases of Oracle Grid Control 

Oracle Grid Control was designed for centralized management of on‑premise Oracle IT infrastructure, especially when organizations had many databases, middleware servers, and hosts.

1. Centralized Monitoring of Large On‑Prem Environments

Grid Control provides a single-window solution for monitoring multiple Oracle databases, WebLogic servers, hosts, and even some non-Oracle technologies (IBM WebSphere, SQL Server, etc.) in one place.

2. End-to-End Application & Service Monitoring

It includes service-level management, real user monitoring, and deep diagnostics for multi-tier applications—ideal for environments needing SLA visibility.

3. Database Performance Diagnostics (11g Features)

For Oracle Database 11g Release 2, Grid Control provides:

  • Enhanced performance pages
  • ADDM integration
  • Real-time SQL monitoring
  • Parallel SQL tuning

4. Real Application Clusters (RAC) & High Availability Management

Use cases include:

  • Managing policy-managed RAC databases
  • Auto-discovery of RAC nodes
  • Monitoring Oracle Clusterware and Grid Infrastructure

5. Configuration, Provisioning, and Lifecycle Management

Grid Control supports configuration management, provisioning, and patching in on‑prem environments.

6. Modeling IT Environment & Service-Level Management

Advanced use cases include:

  • Modeling composite services
  • Service-level agreements (SLAs)
  • Root-cause analysis for service failures

Ideal For:

✔ Large on‑prem Oracle estates
✔ Mixed orchestration environments (DB + WebLogic + Hosts)
✔ Traditional data centers without cloud
✔ RAC-heavy deployments
✔ Organizations needing SLA and service monitoring


Use Cases of Oracle Cloud Control (OEM 12c/13c)

Oracle Cloud Control expands on Grid Control by adding cloud, engineered systems, automation, and lifecycle capabilities.

1. Managing Entire Enterprise + Cloud Infrastructure

Cloud Control is Oracle’s integrated platform for monitoring databases, engineered systems, applications, middleware, hardware, and cloud environments centrally.

2. Hybrid & Cloud Management

It provides capabilities for:

  • Oracle Cloud (OCI) monitoring
  • Hybrid deployments (on‑prem + cloud)
  • Cloud automation, configuration, and provisioning

3. Full Lifecycle Management & Automation

Cloud Control offers automated:

  • Configuration management
  • Provisioning
  • Patch automation
  • Compliance assessment

4. Engineered Systems (Exadata, ZDLRA) Management

Cloud Control supports Oracle engineered systems for:

  • Hardware health monitoring
  • Exadata cell and storage metrics
  • Database machine-level performance
    (Engineered systems management is explicitly part of Cloud Control’s scope.)

5. Deep Diagnostics & Tuning via Licensed Packs

Cloud Control integrates advanced features when packs are enabled:

  • Diagnostics Pack (AWR/ASH integration)
  • Tuning Pack
  • Lifecycle Management Pack

6. Compliance & Security Monitoring

Cloud Control supports compliance frameworks and access control management for enterprise governance—e.g., SOX, security baselines.

7. Managing Large Fleets at Scale

Includes support for:

  • Fleet Maintenance
  • Mass agent deployment
  • Drift analysis
  • Enterprise-wide policy enforcement

Ideal For:

✔ Multi-datacenter enterprises
✔ Cloud + on‑prem hybrid environments
✔ Exadata and engineered systems
✔ Large fleet automation & compliance
✔ Organizations needing advanced diagnostics and tuning


🆚 Summary: When to Use What

RequirementGrid ControlCloud Control
Large on‑prem infrastructure
Hybrid / Cloud environments
Engineered systems (Exadata)Limited✔ Full support
Advanced automation & provisioningModerate✔ Extensive
SLA, service modeling✔ Enhanced
Diagnostics, Tuning PacksAvailable✔ Fully integrated
Modern UI, plugin architectureLegacy✔ Modern extensible

🎯 Short Answer

  • Grid Control → Best for older, fully on‑premises Oracle environments needing centralized monitoring and basic lifecycle management.
  • Cloud Control → Best for modern enterprises requiring cloud integration, engineered systems support, automation at scale, and advanced diagnostics/compliance.

HA (High Availability ) vs DR (Disaster Recovery) – What’s the Difference ?

  HA vs DR – What’s the Difference? HA and DR solve different problems. Many outages happen because teams assume one replaces the other. 1. ...