🟥 Oracle Exadata – Architecture, Performance & Exploitation

Thématique complète “terrain” : panorama → architecture → Smart Scan → RAC/ASM → perf → monitoring → HA → sécurité → patching → run quotidien. Objectif : une base IDEO-Lab lisible, actionnable, et réutilisable en prod.

Introduction & Philosophie

Pourquoi Exadata existe, mythes, ROI réel (Smart Scan / IORM / Flash / réseau), et quand ne pas l’utiliser.

VisionROIGo/No-Go

Page

Panorama Exadata

Database Machine, modèles (on-prem / ExaCS / C@C), générations, racks (Full → Eighth), HC vs EF.

ModèlesGénérationsSizing

Page

1.2

Audit Infrastructure

Audit Infrastructure & Configuration Physique.

ModèlesGénérationsSizing

Page

Architecture Globale

Compute nodes, Storage Cells, fabric RoCE/IB, flux SQL→Cells→DB, principes scale-out.

ComputeCellsFabric

Page

Réseau (RoCE / InfiniBand)

RDMA, latence, bande passante, interconnect RAC, erreurs qui détruisent l’offload.

RDMALatencyInterconnect

Page

RAC & Services

Pourquoi Exadata = RAC “by design”, services, équilibrage, Cache Fusion, anti-skew.

RACServicesCache Fusion

Page

Smart Scan & Offload

Le cœur Exadata : offload, bloom filters, éligibilité SQL, pièges, KPI “efficacité”.

Smart ScanOffloadKPI

Page

Storage Software, ASM & GI

Cell Server, ASM diskgroups, redundancy, Grid Infrastructure, iDB, gouvernance du stockage.

CellOSASMGI

Page

Flash / Cache / Hiérarchie

Smart Flash Cache, Flash Log, PMEM (selon génération), patterns OLTP vs DW.

FlashPMEMLatency

Page

Performance & Tuning

SQL éligible, partitionnement, index vs full scan, parallélisme, stats & optimizer Exadata-aware.

SQLPQStats

Page

Monitoring & Observabilité

OEM, AWR/ASH, Cell metrics, offload %, interconnect, latences, dashboards “prod”.

AWROEMCells

Page

HA, DR & Backup

RAC, Data Guard, RMAN, tests de restauration, RPO/RTO, patterns “critique”.

Data GuardRMANRTO/RPO

Page

Sécurité

TDE, accès Cell/DB, séparation des rôles, patch sécurité, bastion, audit & traçabilité.

TDERBACAudit

Page

Patching & Maintenance

Rolling patch, exachk, patch bundles, drift, fenêtre de maintenance, validations post-patch.

exachkRollingDrift

Page

Exploitation quotidienne (RUN)

Checks quotidiens, incidents types, runbooks, outillage (cellcli/dcli/oem), capacity planning.

RunbookIncidentsCapacity

Page

0) Introduction – Philosophie Exadata

Exadata = “Function Shipping”

Exadata n’est pas “un SAN rapide”. C’est un système conçu pour exécuter une partie du travail SQL au plus près des données : filtres, projections, certaines jointures/agrégations, compression, cache… afin de réduire drastiquement l’I/O et le trafic réseau.

Slogan terrain :
                            - Architecture classique : on "transporte" des blocs, puis on filtre côté DB.
                            - Exadata : on filtre au storage, puis on remonte le résultat utile.

Image : à remplacer par ton visuel Exadata (rack / schéma high-level). Chemin proposé : /static/img/oracle/exadata/exadata_hero.png

Diagramme (modèle mental)

(Mermaid) Si ta base n’embarque pas Mermaid, garde ce bloc : il sert de placeholder propre.

Mythes fréquents

Mythe	Réalité terrain	Action
“Exadata = plus besoin de tuning”	Non. Exadata amplifie les bons patterns, mais les anti-patterns restent pénalisants.	Revoir SQL, stats, partitions, parallélisme, modèle.
“Tout passe en Smart Scan”	Non. Certaines requêtes ne sont pas éligibles (row-by-row, fonctions, conversions, etc.).	Mesurer l’offload réel + corriger les bloqueurs.
“Exadata = stockage”	Non. Sans réseau RDMA sain + cells bien configurées, tu perds le ROI.	Monitorer interconnect + cells + erreurs réseau.

Sweet spots

DW / scans massifs : Smart Scan + HCC = ROI énorme.
Consolidation : isolation via IORM/QoS, densité.
OLTP critique : faible latence + flash/log.
Workload mixte : batch sans tuer la prod (si IORM bien posé).

Anti-patterns

Micro-DB isolée (50–100 Go) sur Exadata “juste pour le prestige”.
Appli 100% row lookup (petits selects unitaires) sans scans utiles.
Organisation incapable de patcher/tester/restaurer (risque majeur).
Pas d’exploitation des features (0 offload, IORM absent).

Règle simple :
                            Si Smart Scan + IORM + Flash n'apportent rien → Exadata est sous-utilisée (ROI perdu).

Checklist “10 minutes” (avant de parler tuning)

Bloc	Question	Signal rouge
Offload	Le % Smart Scan est-il significatif sur les requêtes “DW-like” ?	0% ou “offload inefficace”.
RAC	Les services répartissent-ils la charge ?	Un nœud chaud, l’autre froid.
Réseau	RDMA / interconnect sans erreurs ?	Drops, retransmits, latence anormale.
Patching	exachk OK, patch level cohérent ?	Drift, retard de patch important.
Restore	Restore testé (RPO/RTO réel) ?	“Jamais testé”.

1) Panorama : L'Écosystème Exadata

Qu'est-ce qu'une "Database Machine" ?

Ce n'est pas "du hardware certifié". C'est une stack logicielle et matérielle co-ingéniée.

1. Database Awareness Le stockage (Cells) "comprend" le SQL Oracle.
2. Scale-Out Architecture Ajout de puissance (Compute) ou de capacité (Cell) à chaud.
3. Unification Même machine pour OLTP (Latence flash) et DWH (Throughput).

Évolution Majeure (The RoCE Turning Point)

Génération	Innovation Clé	Impact
V2 -> X8	InfiniBand (40Gb)	L'ère classique. Performant mais réseau propriétaire.
X8M / X9M	RoCE v2 + PMEM	Abandon InfiniBand. Latence < 19µs. Accès mémoire direct.
X10M	AMD EPYC + DDR5	Densité cœurs explosive (190 cores/server). Fin du PMEM (RAM DDR5 suffit).

La Stack Intégrée

graph BT subgraph "Database Server" A[Oracle DB Instance] B[ASM Instance] end subgraph "Network" C{RoCE / RDMA} end subgraph "Storage Server" D[Cell Services - Offload] E[Flash Cache / NVMe] F[Disques Durs - HC] end A -->|iDB Protocol| C C --> D D --> E E --> F style C fill:#b3e5fc,stroke:#333 style D fill:#ffccbc,stroke:#333

Le protocole iDB transporte les intentions SQL, pas juste des blocs.

Même hardware, modèles financiers différents. Que ce soit chez vous ou dans le cloud, c'est le même code Exadata.

Modèle	Location	Gestion Infra	Gestion DB	Cas d'usage idéal
On-Premises	Datacenter Client	Client	Client	Souveraineté totale, isolation physique stricte, CapEx.
Cloud@Customer (ExaC@C)	Datacenter Client	Oracle	Client	"Cloud derrière mon firewall". Latence locale + Modèle OpEx (Pay-per-use).
Exadata Cloud Service (ExaCS)	OCI Public Region	Oracle	Client	Projets agiles, besoins élastiques, Disaster Recovery dans le cloud.
Autonomous (ADB-D)	OCI ou C@C	Oracle	Auto + Oracle	Serverless, patching zéro downtime, Dev/Test rapide.

⚠️ Point de vigilance C@C / OCI : Dans les modèles Cloud, vous n'avez pas d'accès root sur les Storage Cells ni sur les switchs. L'audit infrastructure (vu en Modal 2) est limité aux APIs fournies par Oracle.

HC vs EF : Le grand dilemme

Le choix se fait à l'achat du rack et conditionne la performance pour 5 ans.

HC (High Capacity)

Disques : 12x 18TB HDD + 4x NVMe Flash (Cache).
Ratio : Enorme stockage froid, Cache chaud limité.
Usage : DWH massif, Archivage, Consolidation généraliste.
Smart Scan : Vital ici pour éviter de lire les HDD.

EF (Extreme Flash)

Disques : 100% NVMe Flash. Aucun HDD mécanique.
Ratio : IOPS démentiels, Latence < 1ms garantie.
Usage : OLTP critique, Trading, Applications temps réel.
Smart Scan : Ultra rapide (débit de la flash).

Sizing & Elasticité

Taille	Compute Nodes	Storage Cells	Note
Base System	2	3	Le minimum vital pour la redondance (High Redundancy ASM = 3 copies).
Quarter Rack	2	3	Souvent le point de départ historique.
Elastic Expansion	+1	+1	Depuis X8M, on ajoute les serveurs à l'unité. Plus de "Half Rack" figé.

Capacity on Demand (CoD) :
Sur les Compute Nodes, vous pouvez activer moins de cœurs CPU que le physique (ex: activer 10 cœurs sur 64) pour limiter le coût des licences Oracle Database.

2) Architecture Globale : Le "Split-Brain" Intelligent

Séparation des Pouvoirs

Exadata sépare le SQL (Cerveau) du Stockage (Muscle).

Couche	Composants & OS	Responsabilités Clés
Compute Nodes (Database Servers)	Oracle Linux (UEK) Grid Infra + RDBMS	- Gestion des sessions & Transactions (ACID) - Parsing SQL & Optimiseur - N'a PAS de disques de données locaux
Storage Cells (Exadata Servers)	CellOS (Optimized) CellSRV Process	- Servir les blocs (I/O classique) - Exécuter le SQL (Smart Scan) - Gérer le Flash Cache & IORM
Unified Fabric	Switchs RoCE (Ethernet) ou InfiniBand	- Zero-Loss Network - Bande passante massive (100Gb/s par port)

Topologie Physique

Architecture "Spine-Leaf" interne

[DB NODE 1]══╦══[DB NODE 2]
      ║      ║ (RoCE 100Gb)
 ╔════╩══════╩════╗
 ║  SWITCH FABRIC ║
 ╚════╦══╦══╦══╦══╝
      ║  ║  ║  ║
   [CELL][CELL][CELL]...

Note : Les Compute Nodes ne sont jamais connectés directement aux disques. Tout passe par le réseau.

Le Changement de Paradigme : Function Shipping

Protocole iDB

Architecture classique : "Donne-moi le bloc".
Exadata : "Exécute ce prédicat".

Scénario : SELECT * FROM sales WHERE amount > 1000

DB Server : Parse la requête.
Envoi (iDB) : Envoie le prédicat (> 1000) aux Cells.
Cell Server : Scanne et filtre localement.
Retour : Renvoie uniquement les lignes utiles.

DB Node
Oracle Kernel

"Je veux les ventes > 1000€"

iDB Request (SQL)

Result Set (Lignes)

Cell Node
Smart Scan

Filtre appliqué ici !
(Offload)

Le flux ne transporte pas de blocs inutiles.

Le Secret de la Latence : RDMA

Concept	Description Technique
Kernel Bypass	Les données ne passent pas par le noyau OS. L'appli parle direct à la carte réseau.
Zero-Copy	Copie directe Mémoire Cell ➝ Mémoire DB. Pas de buffers OS.
Protocoles	- InfiniBand (IB) : Legacy (Jusqu'à X8). - RoCE v2 : Ethernet standard + RDMA.

Latence I/O (Read)
< 19 µs
(Vs 500µs sur SAN classique)

ASM : L'Virtualisation du Stockage

Redondance ASM

High Redundancy 3 Copies
Normal Redundancy 2 Copies

ASM écrit les blocs sur différentes Cells pour garantir la survie des données même si un serveur entier brûle.

Hiérarchie Logique

[HDD Physique / NVMe] (Hardware)
  ↳ Cell Disk (LUN Logique CellOS)
    ↳ Grid Disk (Partition présentée)
      ↳ ASM DiskGroup (DATA, RECO)

Le découpage logique permet d'isoler les I/O (IORM) entre différentes bases sur le même disque.

3) Le Système Nerveux : Réseau & RDMA

Pourquoi le TCP/IP classique tue la performance ?

Sur un réseau 100Gb classique, le CPU passerait 50% de son temps à traiter les interruptions réseau (IRQ) et copier des buffers mémoire.

La solution RDMA (Remote Direct Memory Access) :
Permet à la carte réseau (HCA) d'écrire directement dans la RAM du serveur distant sans réveiller le CPU distant.

Caractéristique	TCP/IP (Standard)	RDMA (Exadata)
Chemin CPU	Lourd (Kernel space -> User space copy)	Kernel Bypass (Zero-Copy)
Latence	~200µs - 500µs	< 20µs (Comme un accès mémoire local)
Usage CPU	Élevé (Traitement paquets)	Quasi Nul (Offloadé sur la carte)

La Pile Protocolaire

Standard TCP

Application

Sockets

TCP / IP Driver

NIC Driver

Hardware

RDMA (Exadata)

Application

BYPASS OS!

Hardware (HCA)

L'Évolution : De l'InfiniBand au RoCE

Current Standard: 100Gb RoCE

InfiniBand (Legacy) (V2 -> X8)

Techno : Réseau propriétaire Lossless.
Débit : QDR (40Gb) -> EDR (100Gb).
Topologie : Subnet Manager requis.
Inconvénient : Câbles et switchs spécifiques, difficile à intégrer au réseau d'entreprise.

RoCE v2 (Modern) (X8M -> X10M)

Techno : RDMA over Converged Ethernet (UDP).
Débit : 100Gb -> 200Gb+.
Standard : Utilise des switchs Ethernet et câblage standard.
Secret : Utilise PFC (Priority Flow Control) pour garantir "Zero Packet Loss" sur Ethernet.

PFC (Priority Flow Control) est critique : Si vous connectez un Exadata RoCE à votre réseau core, les switchs en amont DOIVENT supporter et configurer PFC correctement (CoS bits). Sinon, perte de paquets = effondrement des perfs.

Architecture Physique & Redondance

Câblage Interne Rack (Spine/Leaf)

[LEAF SWITCH 1] <===ISL===> [LEAF SWITCH 2]
      |    |                    |    |
      |    +--------------------+    |
      |                              |
 [DB NODE (Active/Active Bonding)]
    Port 1 (re0) --------> Switch 1
    Port 2 (re1) --------> Switch 2

Active-Active : Les 2 ports 100Gb sont utilisés simultanément (200Gb total).

Réseaux Séparés (Isolation)

Client Network Ethernet 10/25Gb
Private Network (RoCE/IB) Interconnect + Storage
Management (ILOM) 1Gb Ethernet

Le trafic d'application (Client) ne touche jamais le réseau de stockage (Private).

Quand le réseau tousse, la base s'étouffe

Symptôme Oracle	Cause Réseau Possible	Outil / Commande
Wait: `gc cr block 2-way` (Cluster)	Latence Interconnect élevée, perte paquets.	`oswatcher` (netstat), `traceroute`
Smart Scan lent ou désactivé	Lien RoCE "Flapping" ou congestionné.	`cellcli -e list metriccurrent attributes name, metricvalue where name like '.I_MB_S.'`
Crash Node (Eviction)	Heartbeat réseau manqué > 30s.	`/var/log/messages`, CSSD log.

Check Instantané : # dcli -g cell_group "netstat -s | grep 'packet receive errors'" Ce chiffre doit être à 0 ou stable. S'il augmente chaque seconde, appelez le support réseau.

4) RAC Exadata : Cache Fusion sous Stéroïdes

Philosophie "Shared Everything"

Contrairement aux clusters "Sharding" (où chaque nœud possède ses données), dans RAC, tous les nœuds voient toutes les données simultanément.

Le challenge : Si le Nœud 1 modifie la ligne "Client A" et que le Nœud 2 veut la lire, il faut se synchroniser à la microseconde près pour éviter la corruption. C'est le rôle du GCS (Global Cache Service).

Grid Infrastructure (GI) Le fondement Gère le Clusterware + ASM. Démarre avant la DB.
Voting Disks Stockés sur les Cells Les disques "témoins" qui décident qui survit en cas de coupure réseau.
Interconnect RoCE / IB Le canal privé vital pour le "Heartbeat" et les échanges de blocs.

La "Cuisine" RAC

Imaginez une cuisine avec 4 chefs (Nœuds) travaillant sur le même plan de travail.

Classique : Le chef A crie au chef B de lui passer le sel.
Exadata : Le chef A tend le bras et prend le sel dans la main du chef B sans même lui parler (RDMA).

Cache Fusion : Transférer la RAM, pas le Disque

Latence critique

Instance 1

Dirty Block X

Possède le bloc (Lock Exclusive)

RDMA Transfer

Instance 2

Reçoit Bloc X

Demande le bloc (Select)

Les Wait Events à surveiller (AWR)

Wait Event	Signification	Action
`gc cr block 2-way`	Lecture saine via Cache Fusion.	Normal si < 1ms.
`gc current block busy`	Contention. Nœud 1 tient le verrou, Nœud 2 attend.	Tuner l'appli (Hot blocks).
`gc lost blocks`	DANGER. Perte paquets réseau.	Vérifier Switchs / Câbles.

L'impact applicatif : Si votre application fait des UPDATE sur la même table depuis tous les nœuds en même temps, Cache Fusion va saturer.
Solution : Partitionner les workloads par Service.

Services : Ne JAMAIS utiliser le service par défaut

Le service par défaut (db_unique_name) ne permet ni HA, ni contrôle, ni statistiques précises.

Création d'un Service "Gold" (srvctl)

srvctl add service -db PROD \
  -service GOLD_APP \
  -preferred INST1,INST2 \
  -available INST3,INST4 \
  -clbgoal LONG -rlbgoal SERVICE_TIME \
  -failovertype AUTO -commit_outcome TRUE

Concepts Clés

Preferred vs Available :
Définit sur quels nœuds le service tourne en temps normal vs en cas de panne.
Application Continuity (AC) :
Rejoue les transactions in-flight en cas de crash d'un nœud. L'utilisateur ne voit pas l'erreur.

Répartition de charge

Client-Side LB : Le TNSNAMES choisit une IP au hasard.
Server-Side LB : Le Listener redirige vers l'instance la moins chargée (LBA).

Node Eviction (Le crash du nœud)

Pour protéger l'intégrité des données, si un nœud ne répond plus ("Split-Brain"), le cluster doit le tuer (Reboot immédiat).

Le Juge	Mécanisme
Network Heartbeat	Chaque seconde, les nœuds se disent "Je suis vivant" via l'interconnect. Si silence > 30s (`misscount`) -> Eviction.
Disk Heartbeat	Chaque nœud écrit sur le Voting Disk (sur les Cells). Si un nœud ne peut plus écrire -> Il se suicide.

Où chercher la cause ?

alert.log (Database) : "IPC Send timeout"
/var/log/messages (OS) : Problèmes réseau ou kernel panic.
cssd.log (Grid) : Le journal détaillé du Clusterware qui explique qui a tué qui.

5) Smart Scan : Le "Secret Sauce" Exadata

La Condition Sine Qua Non : Direct Path Read

Règle d'or : Le Smart Scan ne fonctionne JAMAIS si les données passent par le Buffer Cache (SGA). Il nécessite une lecture asynchrone directe du disque vers la mémoire privée du processus (PGA).

Le processus :

L'optimiseur choisit un Full Table Scan (ou Fast Full Index Scan).
Oracle décide de bypasser le cache (car table trop grosse).
Il envoie un paquet iDB contenant le SQL (Prédicats + Colonnes).
La Cellule lit, filtre, et renvoie un Result Set compacté.

Fonction Offloadée	Gain
Predicate Filtering	Seules les lignes `WHERE zone='EU'` remontent.
Column Projection	Seules les colonnes `SELECT id, nom` remontent (pas les 200 autres).
Encryption Decrypt	Le déchiffrement TDE se fait sur le CPU de la Cell (gratuit pour la DB).

Comparatif Flux I/O

Standard SAN

DB Server CPU

Trash Data

Good Data

100% Data Transfer

Storage

Exadata Smart Scan

DB Server CPU

Good Data Only

~5% Data Transfer

Exadata Cell (Filter Here)

Les Accélérateurs Invisibles

1. Storage Indexes (SI)

Une structure en mémoire sur la Cellule (pas sur disque !) qui maintient les valeurs Min/Max pour chaque 1MB de données.

But : I/O Avoidance. Si je cherche ID=50 et que le SI dit "Bloc A : Min 100, Max 200", on ne lit même pas le bloc.
Maintenance : Automatique et transparente.
Note : Redoutable sur les colonnes de dates ou séquences.

2. Bloom Filters

Transforme une Jointure (Join) en Filtre (Scan).

Hash Join : T1 (Petit) JOIN T2 (Gros)
1. DB crée un vecteur binaire (Bloom) des clés de T1.
2. DB envoie ce vecteur aux Cells.
3. Cells scannent T2 et éliminent tout ce qui ne matche pas le vecteur.

Résultat : On ne remonte pas les lignes de T2 qui ne se joindront pas.

Autres formats supportés : JSON, XML, LOBs (SecureFiles) bénéficient aussi de l'offloading (parsing JSON fait sur la Cell !).

Prouver l'efficacité (ou l'inefficacité)

Niveau	Indicateur Clé	Interprétation
Session (V$)	`cell smart table scan`	Wait event qui confirme l'activité Smart Scan.
SQL Monitor	Col `IO_INTERCONNECT_BYTES` vs `IO_CELL_OFFLOAD_ELIGIBLE_BYTES`	Le ratio entre les deux donne le % d'économie.
Global (AWR)	"Cell Efficiency Ratio"	Si > 10, c'est excellent (10x moins de trafic).

Le Calcul de l'Efficacité

95%
Gain Typique DWH

Formule :
(Eligible_Bytes - Return_Bytes) / Eligible_Bytes * 100

Exemple : J'ai scanné 1TB sur disque (Eligible), j'ai renvoyé 50GB au réseau (Return).
Gain = (1000 - 50) / 1000 = 95% Offload.

Pourquoi mon Smart Scan ne part pas ?

C'est la question n°1 du DBA Exadata. Voici la checklist de survie.

1. La table est trop petite

Oracle préfère la mettre en cache (Buffer Cache).
Fix : Forcer avec _serial_direct_read=true (pour test uniquement).

2. Row Chaining (Lignes chaînées)

Si une ligne est éclatée sur plusieurs blocs, la Cellule ne peut pas la reconstruire. Elle renvoie le bloc brut à la DB.
Fix : Reorg de la table.

3. Types de données complexes

Les colonnes LONG (obsolète) ou certains types ADT (User Types) bloquent l'offload.

4. Diskgroup Attribute 'compatible.rdbms'

Si la version ASM est trop vieille par rapport à la DB, certaines fonctions d'offload sont désactivées.

6) Storage Software, ASM & Gouvernance

Anatomie d'une Cellule

Ce n'est pas un simple "Linux". C'est un OS durci avec 3 processus clés qui gèrent l'intelligence.

Processus	Rôle Critique
CELLSRV	Le Cerveau. Multithreaded server. - Traite les requêtes iDB (Smart Scan). - Gère IORM (Priorité I/O). - Gère le Flash Cache.
MS	Management Server (Java). - Interface de gestion (CellCLI). - Envoie les alertes (SNMP/SMTP) en cas de panne disque.
RS	Restart Server. - "Watchdog" qui surveille CELLSRV et MS. - Les redémarre s'ils plantent (Haute Dispo locale).

Architecture Logicielle

Network (RoCE/IB)

CELLSRV
(I/O & SQL)

MS (Admin)

RS (Watchdog)

OS Kernel (Linux) + Drivers

Hardware (Flash / HDD)

De l'Hardware à la Database : La Poupée Russe

Redundancy: HIGH (3x) / NORMAL (2x)

Concept Grid Disk : Exadata découpe physiquement les disques. Les premiers secteurs (les plus rapides sur HDD) sont souvent réservés au groupe DATA, le reste pour RECO.

DATA (DG) : Contient les datafiles, redo logs actifs, OCR, Voting Disk.
RECO (DG) : Contient la Flashback Area, Archived Logs, Backups.
SPARSE (Optionnel) : Pour les clones Exadata Snapshots.

Flux d'Abstraction

ASM DISKGROUP (Logical)
Visible par la DB (ex: +DATA)

Grid Disk 1

Grid Disk 2

Grid Disk N...

Cell Disk (LUN)

HARDWARE (Physical)
NVMe Flash / HDD 18TB

IORM : Le Policier du Stockage

Sans IORM, une base de développement qui lance un gros rapport peut saturer les disques et tuer la Prod. IORM gère la QoS au niveau du stockage.

Les 2 Modes

Inter-Database : Répartition entre plusieurs bases (ex: PROD=70%, DEV=30%).
Intra-Database : Répartition interne (ex: Utilisateur batch vs Utilisateur interactif) via DBRM.

Visualisation Allocation I/O

PROD (60%)

UAT (30%)

DEV (10%)

Si PROD n'utilise pas ses 60%, UAT et DEV peuvent récupérer le "mou". Dès que PROD en a besoin, IORM throttle les autres immédiatement.

Objectif "Low Latency" : Par défaut, Exadata privilégie la latence (OLTP). Pour les bases purement Batch, on peut changer l'objectif en "Auto" ou "Balanced".

L'Arsenal de l'Admin : CellCLI & DCLI

Action	Commande (Exemple)	Scope
Vérifier disques physiques	`list physicaldisk attributes name,status`	Hardware
Vérifier Flash Cache	`list flashcache detail`	Performance
Créer Grid Disks	`create griddisk all harddisk prefix=DATA, size=500G`	Configuration
Configurer IORM	`alter iormplan objective=auto`	Gouvernance
Exécuter sur TOUT le rack	`dcli -g cell_group "cellcli -e list celldisk"`	Distribué

# Exemple : Voir l'économie Smart Scan
CellCLI> list metriccurrent attributes name, metricvalue
where name like '.*IO_SAVED_W.*'

7) La Hiérarchie Mémoire : Flash, Log & PMEM

Le Principe du Tiering

Exadata déplace automatiquement les données chaudes vers les médias les plus rapides. C'est transparent pour l'application.

"Heat Map" Interne : Le logiciel CellSRV analyse les fréquences d'accès. Un bloc lu fréquemment est promu en Flash Cache. Un bloc froid reste sur HDD (Modèle High Capacity).

RAM (Compute)
< 1 µs

PMEM (Data Accelerator)
< 19 µs (RDMA)

NVMe Flash Cache
~100 µs

HDD (High Capacity)
~8 ms (Mécanique)

Smart Flash Cache : Bien plus qu'un cache disque

Mode: WriteBack (Recommandé)

WriteThrough vs WriteBack

WriteThrough (Mode Safe) : On écrit sur HDD, puis on copie en Flash pour les lectures futures. Les écritures sont lentes (vitesse HDD).
WriteBack (Mode Turbo) : On écrit directement en Flash. La donnée est considérée comme "sauvegardée". Elle est descendue sur HDD plus tard (Lazy write).
Boost massif des IOPS en écriture !

Columnar Flash Cache

Pour les données compressées HCC, Exadata reformate automatiquement les données en pur format colonnaire lorsqu'elles entrent dans le Flash Cache.
Résultat : Les Scans analytiques en Flash sont fulgurants.

Commande Check : cellcli -e list flashcache detail
Vérifiez la ligne effectiveCacheSize vs size. Si la différence est grande, vous avez des secteurs défectueux ou réservés.

Smart Flash Log : Sauver le COMMIT

Le goulot d'étranglement n°1 des bases OLTP est le log file sync (attente de l'écriture du Redo Log sur disque pour valider le Commit).

La Course à l'Écriture (Race Condition)

LGWR (DB) Envoie le Redo Block

Flash Log (Gagnant !)

HDD Disk (Trop lent)

Le premier qui finit envoie l'ACK. Exadata annule l'autre I/O.

Gain : Élimine les pics de latence (Outliers). Si le disque mécanique est occupé, le Flash prend le relais instantanément.

Taille : Petit (512MB par Cell). C'est un buffer circulaire temporaire.
Hardware : Utilise une zone réservée haute endurance de la carte Flash.

Persistent Memory (PMEM) : Le chaînon manquant

Specifique X8M / X9M

Sur les générations X8M et X9M, Oracle a ajouté Intel Optane DC PMEM (1.5TB par Cell). Ce n'est pas de la RAM (elle garde les données OFF) mais c'est aussi rapide.

Fonctionnalité PMEM	Rôle
PMEM Cache (Data Accelerator)	Cache de lecture ultra-rapide. RDMA lit directement ici sans toucher au CPU de la Cell.
PMEM Log (Commit Accelerator)	Écriture des Redo Logs 8x plus rapide que la Flash.

Note X10M (2023+)

Sur la Génération X10M, PMEM a été supprimé.
Pourquoi ? Les nouveaux CPU AMD EPYC + RAM DDR5 + RoCE optimisé sont devenus si rapides que le PMEM n'apportait plus de gain significatif.
Exadata Smart Exadata RDMA Memory (XRM) utilise désormais la RAM standard pour ces fonctions.

8) Tuning : Oubliez vos vieux réflexes !

Le "Tipping Point" a changé

Sur une base classique, si vous lisez > 5% d'une table, l'index devient plus lent que le Full Scan. Sur Exadata, grâce au Smart Scan, ce seuil est beaucoup plus bas (parfois 0.1% !).

Ménage des Index : Sur Exadata, on supprime souvent 50% des index (surtout les index composites ou peu sélectifs). Ils ralentissent les DML et ne battent pas le Smart Scan.

Scénario	Stratégie Gagnante	Pourquoi ?
Single Row Lookup `WHERE ID = 123`	INDEX (Unique)	Smart Scan ne battra jamais l'accès direct RowID pour 1 ligne.
Reporting / Analytics `WHERE DATE > '2023...'`	FULL SCAN (Smart)	Le débit (GB/s) écrase la latence des "Random Reads" d'index.
Low Cardinality `WHERE STATUS = 'CLOSED'`	FULL SCAN (Smart)	Les Storage Indexes filtrent ça gratuitement.

Graphique de Coût (Conceptual)

Coût Index

Coût Smart Scan

Exadata Point

Volume de données sélectionné (%)

Parallel Query : La puissance brute

Auto DOP

Le Risque

Si vous laissez PARALLEL_DEGREE_POLICY = MANUAL et que les développeurs mettent des hints /*+ PARALLEL(64) */, 3 requêtes suffisent à mettre le serveur à genoux (CPU Starvation).

Best Practices Exadata

Activer Auto DOP : PARALLEL_DEGREE_POLICY = AUTO. Laisse Oracle calculer le degré idéal selon la taille de la table.
Parallel Statement Queuing : Si le serveur est chargé, la requête attend son tour (FIFO) au lieu de tuer le CPU.

Flux Parallel Query + Direct Path

PX Coord

Slave 1

Slave 2

Slave 3

Direct Path Read (Cells)

Chaque Slave Process (PX) ouvre sa propre connexion directe aux Cells. Le débit est multiplié par le nombre de Slaves.

Informer l'Optimiseur (CBO)

Si l'optimiseur croit qu'il tourne sur des disques lents, il choisira toujours des index. Il faut lui dire "Je suis sur Exadata".

Action	Commande / Paramètre	Effet
System Stats	`dbms_stats.gather_system_stats('EXADATA')`	Calibre la vitesse I/O (MBRC) et CPU. Indispensable post-installation.
Optimizer Index Cost	`OPTIMIZER_INDEX_COST_ADJ`	Sur Exadata, on le laisse souvent par défaut (100) ou on l'augmente pour favoriser les Scans.
Real-Time Stats	(Auto en 19c)	Évite les mauvais plans sur les tables qui changent brutalement de volume (Bulk Insert).

Astuce : Utilisez DBMS_STATS.GATHER_TABLE_STATS avec METHOD_OPT=>'FOR ALL COLUMNS SIZE 1' (pas d'histogrammes) par défaut, et ajoutez des histogrammes uniquement là où c'est prouvé nécessaire (Skewed data). Les histogrammes coûtent cher au parsing.

Zone Maps & Partitionnement

L'Exadata adore les données physiquement triées.

Clustering Factor

Si vous chargez vos données triées par date (ou par ID), les Storage Indexes deviennent ultra-efficaces (Min/Max disjoints).
Commande : ALTER TABLE ... ADD CLUSTERING BY LINEAR ORDER (col)... (Attribute Clustering).

Partition Pruning

Le Partitionnement reste vital. Exadata scannera une partition de 10GB en < 1s.
Ne partitionnez pas trop fin (évitez les millions de partitions de 1MB). Visez des partitions de quelques GB.

9) Monitoring : Piloter la Bête

Les 3 Piliers de l'Observabilité Exadata

Ne regardez pas que le CPU DB. Regardez si le stockage travaille pour vous.

Domaine	Métrique Clé	Seuil d'Alerte
1. Offload	`Cell Efficiency Ratio`	< 2x (Sur Data Warehouse). Signifie que vous rapatriez trop de données brutes.
2. Latence I/O	`Cell Flash Cache Read Latency`	> 1ms (En moyenne). Indique saturation ou usure Flash.
3. Santé Hw	`Predictive Failure` (Disques)	Dès apparition. Remplacement immédiat requis.

La Métrique "North Star"

95%

I/O Offloaded

Objectif : > 80% pour DWH/Analytics

Lire un AWR "Exadata Style"

Section: Exadata Statistics

Top 3 Sections à vérifier

Exadata Smart Scan Efficiency :
Regardez "Flash Cache Hit %" (Doit être proche de 100% pour OLTP).
Top IO Reasons :
Est-ce du Smart Scan ou du Single Block Read (Index) ?
Exadata Flash Log :
Vérifiez "Writes prevented from going to disk". Si bas, le Flash Log ne sert à rien.

SQL Monitor (Active Report)

C'est l'outil ultime pour debugger une requête lente.

Cherchez la barre bleue "Cell Offload".
Si la barre est 100% verte (CPU DB), le Smart Scan n'a pas fonctionné !

10%

90% Saved

Mode Hacker : CellCLI en temps réel

Quand OEM est trop lent ou moyenné, allez à la source sur les Storage Cells.

root@cel01 ~ # cellcli

# 1. Voir la charge I/O actuelle (IOPS/MBPS)
CellCLI> list metriccurrent attributes name, metricvalue
where name like 'I_.*_S'

# 2. Voir si le Flash Cache sature
CellCLI> list metriccurrent attributes name, metricvalue
where name like 'FC_BY_USED'

# 3. Voir les erreurs Hardware
CellCLI> list alerthistory where severity='critical'

Astuce DCLI : Utilisez dcli -g cell_group "..." pour interroger les 14 cellules d'un coup et grepper le résultat. Indispensable pour voir si UNE cellule est plus lente que les autres (Skew).

Ce que votre Chef veut voir (OEM Dashboard)

Zone 1 : Santé Physique

Cells Up
14/14

Disks
OK

Temp
24°C

Zone 2 : Performance ROI

25 GB/s
Débit Scan

92%
Flash Hit

0.5ms
Latence

Le rapport mensuel (Capacity Planning)

Projection remplissage ASM (DATA) Quand acheter une extension ?
Top Databases par I/O Qui consomme la machine ? (Facturation interne)

10) HA, DR & Backup : La Forteresse MAA

Survivre à la panne d'un composant

Exadata est conçu pour qu'aucun composant unique (SPOF) ne puisse arrêter le service. Tout est redondant.

Panne	Mécanisme de Survie	Impact Utilisateur
Perte 1 Compute Node	RAC (Cache Fusion) Les connexions basculent (TAF/FAN) sur les nœuds survivants.	Micro-gel (sec) pour le replay des transactions (Application Continuity).
Perte 1 Storage Cell	ASM Redundancy ASM redirige les lectures vers les miroirs sur les autres Cells.	Transparent (légère baisse perf I/O le temps du rebalance).
Perte 1 Switch RoCE	Active-Active Bonding Le trafic passe instantanément sur le 2ème switch.	Aucun (Zéro interruption).

Le Concept "Instant Failure Detection"

Différence Clé :
Sur un SAN classique, le serveur attend le timeout TCP (souvent 30s-60s) pour déclarer le disque mort.
Sur Exadata, la Cellule mourante envoie un message "Je meurs !" (si possible) ou le switch notifie la coupure en < 1s.

Cell 1 OK

Cell 2 DEAD

Cell 3 OK

ASM Rebalance démarre immédiatement

Data Guard : L'Assurance Vie

Active Data Guard (ADG) recommandé

Modes de Protection

Max Protection (SYNC)
Zéro perte de données (RPO=0). Si la Standby tombe, la Prod s'arrête.
Risqué si réseau instable.
Max Availability (SYNC)
RPO=0 tant que possible. Si Standby tombe, la Prod continue (devient Async).
Max Performance (ASYNC)
Standard du marché. RPO ~quelques secondes. Aucun impact perf Prod.

Architecture Active Data Guard

PRIMARY
Read/Write

Redo Stream

STANDBY
Read Only

Pourquoi "Active" ?
La Standby est ouverte en lecture pendant qu'elle applique les logs. Idéal pour décharger les rapports lourds (Offload) de la Prod.

Backup : RMAN sur Stéroïdes

Technologie	Avantage Exadata
Incremental Backup	Block Change Tracking (BCT) : Le fichier BCT est stocké sur Flash. RMAN ne lit QUE les blocs modifiés. Backup incrémental ultra-rapide.
Validation	HARD (Hardware Assisted Resilient Data) : La Cellule vérifie le checksum des blocs avant de les écrire sur disque. Corruption logique impossible.
ZDLRA (Recovery Appliance)	"Le Backup infini". On envoie juste le Redo en temps réel. RPO sub-seconde. Restauration virtuelle Full instantanée.

Le test qui sauve : RMAN> RESTORE DATABASE VALIDATE; Avoir un backup c'est bien. Savoir qu'il est lisible, c'est mieux. Cette commande lit tout le backup sans rien écrire. À planifier mensuellement.

Quelle médaille pour votre architecture ?

Oracle classifie la résilience selon 4 niveaux MAA (Maximum Availability Architecture).

BRONZE Single Instance / RAC One Node
Dev/Test. Redémarrage requis en cas de crash.
SILVER RAC + Application Continuity
Standard Prod. Tolérance panne nœud. RPO=0 localement. Pas de DR.

GOLD Silver + Data Guard (Async)
Protection contre désastre site (Incendie/Inondation). RPO > 0.
PLATINUM Gold + GoldenGate / Active DG Sync
Zéro downtime, Zéro perte de données, maintenance rolling sans arrêt. Le Graal bancaire.

11) Sécurité : La Forteresse Numérique

Architecture Sécurisée par Défaut

Exadata applique le principe de moindre privilège à chaque couche matérielle et logicielle.

Couche	Mesure de Sécurité Clé
Réseau Physique	Isolation RoCE/IB : Le réseau de stockage est 100% privé. Aucune adresse IP routable depuis l'extérieur. Impossible d'attaquer les disques directement.
OS (Linux)	Minimal Image : Oracle Linux est livré durci (services inutiles désactivés). Accès SSH restreint.
Stockage (Cells)	ASM Scoped Security : Seuls les serveurs DB authentifiés (via clés InfiniBand/RoCE) peuvent monter les disques ASM.

L'Oignon de Sécurité

Database (Users/Roles)

OS (Users/Groups)

Network (Isolation)

AIL (Authorized IP List) : Sur Exadata Cloud@Customer, vous devez déclarer explicitement les IPs autorisées à se connecter via la console OCI. Tout le reste est bloqué.

TDE (Transparent Data Encryption) : "Gratuit" sur Exadata

Hardware Accelerated

Sur un serveur standard, chiffrer la base consomme 10-20% de CPU pour déchiffrer chaque bloc lu.
Sur Exadata, ce travail est déporté (Offloadé) sur les Storage Cells.

Le Flux Sécurisé

Donnée stockée chiffrée sur disque (AES-256).
Smart Scan lit le bloc chiffré.
Cell CPU déchiffre le bloc en mémoire.
Cell CPU applique le filtre SQL (Where clause).
Seules les lignes résultantes (en clair ou chiffrées selon le besoin) remontent.

Comparatif Impact CPU DB

Standard

CPU Surchargé

Exadata

CPU DB Libre

Le déchiffrement est géré par les instructions AES-NI des processeurs Cell.

Séparation des Devoirs (Separation of Duties)

Rôle	Utilisateur OS	Périmètre
Compute Admin	`root` (Sur Compute)	Patching OS, Réseau client, Sysctl.
Database Admin	`oracle` / `grid`	Création DB, Tuning, Backup, Data Guard.
Cell Admin	`celladmin` / `root` (Cell)	Gestion disques physiques, IORM, Flash Cache.

Cloud vs On-Prem :
En mode Cloud@Customer ou OCI, vous n'avez PAS d'accès root aux Storage Cells, ni aux Switchs. La gestion est assurée par Oracle (Ops Automation). Vous êtes Admin de la DB, pas du Hardware.

Prouver la conformité

ExaChk Security Profile :
L'outil ExaChk contient un profil STIG / CIS. Lancez-le pour voir les écarts de sécurité.
./exachk -profile security
Unified Auditing :
Activé par défaut en 19c+. Capture les logins, les DDL et les accès sensibles.
Audit Vault (AVDF) :
Recommandé pour centraliser les logs d'audit hors de l'Exadata (inviolabilité des preuves).

Patching Trimestriel

Oracle publie les QFSD (Quarterly Full Stack Download) chaque trimestre. Inclut : Firmware, OS, Grid, DB.
Retard > 6 mois = Risque critique.

12) Patching & Maintenance : L'Art du "Zero Downtime"

QFSD : Quarterly Full Stack Download

Une seule source de vérité

Sur Exadata, on ne patche pas "un bout". On applique une image trimestrielle validée par Oracle qui contient tout.

Composant	Impact Patching	Fréquence
Storage Cells	Reboot Cellule (Transparent si Redundancy OK).	Trimestriel
Switchs (IB/RoCE)	Reboot Switch (Transparent via Bonding).	Trimestriel (souvent sauté si pas de CVE).
Compute Nodes (DomU)	Reboot Serveur (Transparent via RAC).	Mensuel/Trimestriel (OS + GI + DB).
Firmware Disques	Inclus dans le patch Cell.	Automatique au reboot Cell.

Le Cycle de Vie Idéal

1. Download QFSD (M-1)

2. Test sur Dev/Uat (M)

3. Prod : Cells & Switchs

4. Prod : Compute (DB)

Toujours commencer par le Stockage/Réseau avant la Base.

Rolling Patching : La danse des nœuds

L'objectif : L'application ne doit jamais voir une coupure de service, juste une baisse de capacité temporaire.

Node 1

PATCHING...

Services déplacés

Service Relocation

Node 2

ACTIVE

100% Traffic

Le Danger "Non-Rolling" :
Si vous patchez l'ASM/Grid en mode "Non-Rolling" (option par défaut de certains outils si mal configurés), TOUT LE CLUSTER S'ARRÊTE. Vérifiez toujours vos fichiers de réponse (patchmgr -rolling).

L'outil Roi : patchmgr

Command Line Interface

root@adm01 ~ #

# 1. Pré-check des cellules (Ne touche à rien)
./patchmgr -cells cells_group -patch_check_prereq -rolling

# 2. Patching réel (Une par une)
./patchmgr -cells cells_group -patch -rolling

# 3. Rollback en cas de désastre
./patchmgr -cells cells_group -rollback -rolling

DCLI (Distributed CLI)
L'ami fidèle pour vérifier les versions partout.
dcli -g all_group "imageinfo"

OEDA (Deployment Assistant)
Utilisé pour générer les fichiers de config XML initiaux, mais aussi pour les upgrades majeurs.

Exachk : Le "Go / No-Go"

Ne lancez jamais un patch sans un rapport Exachk vert (score > 90/100).

Hardware Audit : Vérifie batteries RAID, ventilateurs, disques dégradés.
Soft Config : Vérifie paramètres kernel, limites utilisateurs, best practices.
Firmware Drift : Compare vos versions actuelles avec la matrice de compatibilité Oracle.

AHF (Auto Health Framework)

Score Santé

98/100

Si < 100, lisez les "FAIL" et "WARNING". Un warning ignoré aujourd'hui est un crash patch demain.

La Validation Post-Patch :
1. imageinfo : Version OK ? Status 'success' ?
2. crsctl stat res -t : Toutes les ressources DB et Grid sont ONLINE ?
3. cellcli ... list flashcache : Le cache est-il remonté ?

13) Exploitation (RUN) : Garder la Bête en Cage

Le "Café-Check" du DBA Exadata

Avant de regarder les bases, regardez la machine. Si l'Exadata va mal, toutes les bases iront mal.

Composant	Check Rapide	Cible
Hardware Global	`dcli ... cellcli -e list cell attributes metricState`	Tous à 0 (Pas d'alerte).
ASM Balance	Vérifier le déséquilibre (Imbalance) entre disques.	< 5%. Si >, un Rebalance est en cours ou bloqué.
Performance Flash	Vérifier les "Flash Cache Evictions" (Keep vs Default).	Pas d'éviction massive sur le pool Keep.
Backups	Rapport ZDLRA ou RMAN.	100% Success (Exadata pardonne mal le retard de backup des archivelogs).

La Commande "Météo"

# Vérifier toutes les alertes ouvertes
dcli -g all_group -l root "cellcli -e list alerthistory where severity='critical' and metricState='warning'"

Objectif :
Le résultat doit être VIDE. Une alerte hardware sur Exadata ne s'ignore pas.

Guide de Survie : Top 3 Incidents

Troubleshooting

Cause probable : Disque dur mécanique sollicité (Smart Scan désactivé ou Flash Cache saturé).
Action : 1. Vérifier si une requête fait du "Cell Single Block Physical Read" massif.
2. Vérifier si le Flash Cache est en mode "Write Through" (dégradé).
3. Tuer la session coupable ou activer IORM.

Symptôme : Un nœud reboot tout seul.
Cause probable : LMS (Lock Manager) n'a pas répondu assez vite (CPU Starvation) ou perte Interconnect.
Check : Logs oswatcher (netstat/top) au moment du crash. Chercher "Packet Loss" sur les switchs.

La trousse à outils du Chef (DCLI)

DCLI (Distributed CLI) est votre meilleur ami pour gérer 14 serveurs comme un seul.

Syntaxe Vitale

dcli -g [GROUP_FILE] -l [USER] "[COMMAND]"

-g cell_group : Cible toutes les Storage Cells.
-g dbs_group : Cible tous les Compute Nodes.
-k : Échange les clés SSH (Premier setup).

Exemples One-Liner Check Date/Heure partout
dcli -g all_group "date"

Chercher un fichier log
dcli -g dbs_group "ls -l /var/log/messages"

Restart Services (A utiliser avec prudence !)
dcli -g cell_group "cellcli -e alter cell restart services all"

Ne jamais être pris au dépourvu

Règle des 80% (ASM)

Used (70%)

Buffer (15%)

Free (15%)

Pourquoi ? Si un disque lâche, ASM doit copier les données sur l'espace libre (Rebalance). Si vous êtes à 95%, le Rebalance échoue et vous perdez la redondance.

Le KPI "Flash Cache Wear"

Les cartes Flash s'usent en écrivant. Surveillez l'attribut enduranceLevel.
Si < 10%, planifiez le remplacement matériel préventif avec Oracle Support.

Tendance : Ne regardez pas juste le snapshot actuel. Regardez le delta mensuel.
"À +500GB/mois, le Diskgroup DATA sera plein dans 4 mois." -> C'est ça, la valeur ajoutée du RUN.

1.2) Audit Infrastructure & Santé

Check-up Vital (Avant tout Tuning)

Une Exadata malade physiquement ne performera jamais, quel que soit le tuning SQL.

L'impératif Exachk (AHF) :
Ne touchez à rien tant que le score Exachk est < 90/100. Il vérifie 1000+ points (Firmware disques, cohérence versions, paramètres kernel cachés).

Cible	Commande Audit	Signal d'Alarme
Versions Image	`imageinfo` (via dcli)	Écart de version entre les nœuds (Drift).
Hardware	`ilomconf` / `ipmitool`	DIMM défectueuse, PSU en échec, Temp > seuil.
Patching	`exadbcpatchmulti`	Patch QFSD vieux de > 6 mois (Risque sécurité + bugs).

Séquence de Patching (Ordre Vital)

1. Check Hardware (Pre-flight)

2. Update Cells (Storage)

3. Update Switches (Network)

4. Update Compute (DB Nodes)

Jamais la DB avant le Storage !

Audit CellCLI : Le Cœur du Réacteur

Critique

1. État Physique Disques

dcli -g cell_group "cellcli -e list physicaldisk attributes name,status,errCount where status!='normal'"

❌ Predictive Failure : Disque à changer immédiatement.
❌ Poor Performance : Disque lent qui freine tout le système.

2. État Logique Flash

cellcli -e list flashcache detail

🔍 Status : Doit être NORMAL.
📉 Mode : WriteBack (Recommandé) vs WriteThrough.

Le Piège de l'Imbalance :
Si une Cellule est pleine à 90% et les autres à 40%, ASM écrit moins vite (latence).
Commande : list celldisk attributes name, freeSpace, size

Le Système Nerveux (RoCE/IB)

Si le réseau tousse (erreurs physiques), le Smart Scan se désactive.

Problème	Symptôme Technique	Impact Utilisateur
Lien Flapping	Logs switch : `LinkUp / LinkDown` répétitifs.	Latences erratiques, Node Eviction (Crash).
Congestion	Compteurs `SymbolErrors` ou `VL15Dropped` élevés.	Effondrement du débit Smart Scan.
Mauvais Routing	Topologie incorrecte (vérifier via `ibnetdiscover` ou équivalent RoCE).	Bande passante divisée par 2.

La Commande Secrète : # imageinfo -netCheck
Lance une validation interne complète de la topologie réseau, des versions firmware switchs et des câbles, le tout en une ligne.

Optimisation OS (Oracle Linux)

HugePages OBLIGATOIRE
Swap Usage Proche de 0
NTP / Chrony Synchro critique pour RAC
Hyper-Threading ON (Par défaut)

Règle d'Or :
Sur Exadata, on ne modifie JAMAIS sysctl.conf à la main.
On utilise OEDA ou les scripts de validation Oracle.