🟥 Oracle Exadata – Audit Framework & Production Checklist

0️⃣ Introduction : La Philosophie Exadata

Lecture : 10 min

Exadata ≠ Gros Serveur

L'erreur numéro 1 est de penser qu'Exadata est simplement un serveur très puissant avec beaucoup de disques.

L'Analogie de la Formule 1 :
Imaginez que vous voulez aller vite.

Approche Traditionnelle (Build Your Own) : Vous achetez le moteur chez Ferrari, le châssis chez Renault, les pneus chez Michelin. Vous passez 6 mois à essayer de faire tout tenir ensemble. C'est du "Tuning".
Approche Exadata (Engineered System) : Vous achetez une Formule 1 où chaque boulon, chaque ligne de code du firmware disque et chaque instruction du CPU a été conçu pour travailler ensemble.

Exadata est une "Database Machine". C'est la seule architecture où le logiciel de base de données (Oracle Database) sait exactement sur quel matériel il tourne et parle directement au stockage via un protocole propriétaire (iDB - Intelligent Database Protocol).

Le changement de paradigme

Dans une architecture classique, le stockage est "bête". Il donne des blocs au serveur.
Dans Exadata, le stockage est "intelligent". Il comprend le SQL.

[Image suggérée : Comparaison visuelle "Dumb Storage" vs "Smart Storage"]
Illustration montrant un tuyau saturé de données inutiles vs un tuyau fin avec uniquement les résultats utiles.

Identité Exadata

💿 Hardware : Serveurs standards x86 (Compute + Storage) reliés par un réseau ultra-rapide (RoCE/InfiniBand).
🧠 Software : Oracle Linux + Exadata Storage Software (CellOS). C'est ici que réside la magie.
🚀 Objectif : Réduire les I/O physiques drastiquement via le Smart Scan.

100x
Accélération potentielle des requêtes analytiques

Le goulot d'étranglement historique (The I/O Bottleneck)

Depuis 30 ans, les CPU deviennent de plus en plus rapides (loi de Moore), mais les disques durs physiques (et même les SSD) restent lents à déplacer des données vers la mémoire du serveur.

Diagramme : Le problème du "Data Shipping" classique

graph LR subgraph "Serveur Base de Données" A[SQL: SELECT * FROM VENTES WHERE ANNEE=2024] B[Filtrage CPU DB] end subgraph "SAN Traditionnel" C[Disques / Storage Array] end A -- Demande TOUS les blocs de la table --> C C -- Envoie 100% des données (Même 2020, 2021...) --> B B -- Jette 90% des données (Gaspillage) --> D[Résultat] style A fill:#f9f,stroke:#333 style C fill:#ccf,stroke:#333

Dans le modèle classique, on déplace des montagnes de données pour n'en garder qu'un caillou.

Approche Traditionnelle (SAN)	Vs	Approche Exadata (Function Shipping)
Le stockage envoie des blocs bruts.		Le stockage traite le SQL et envoie des lignes/colonnes.
Le goulot est le câble Fibre Channel (HBA).		Le traitement est fait localement sur les CPU du stockage (Offload).
La base de données consomme son CPU pour filtrer les données.		Le CPU de la base de données ne reçoit que le résultat utile.

Les 3 couches physiques

Un Exadata est un rack pré-câblé composé de trois éléments distincts :

Database Nodes (Compute)

C'est là que tourne l'instance Oracle (SGA, PGA, Background processes). C'est le "cerveau" SQL.

Cell Nodes (Storage Servers)

Des serveurs x86 remplis de disques (NVMe/Flash/HDD) qui exécutent le logiciel Exadata Storage Server. Ils font le "sale boulot" de filtrage.

Unified Fabric (RoCE)

Le réseau interne ultra-rapide (100Gbps+) qui utilise RDMA (Remote Direct Memory Access) pour une latence proche de zéro.

[Image: Schéma Rack Exadata]

[COMPUTE 1] [COMPUTE 2]
 | |
 +------------+
 | SWITCHES |
 +------------+
 | | | |
 [CELL 1] [CELL 2] [CELL 3]

Architecture Scale-Out : On peut ajouter des Computes ou des Cells indépendamment.

Concept Clé : ASM Intelligent

ASM (Automatic Storage Management) ne voit pas les disques individuellement. Il voit une "GRID DISK". Exadata utilise ASM pour dupliquer les données (Redundancy HIGH ou NORMAL) afin qu'une Cellule entière puisse brûler sans perte de service.

Quand utiliser Exadata (et quand fuir)

Sweet Spots (Idéal)

Data Warehousing (DWH) : Le roi absolu. Smart Scan scanne des Téracoctets en secondes.
Consolidation massive : Mettre 500 bases de données sur un seul rack grâce à l'isolation des ressources (IORM).
OLTP Critique : Grâce au Flash Cache et à la faible latence du réseau RoCE/InfiniBand.
Workloads Mixtes : Faire du reporting sur la base de prod sans tuer les transactions (grâce à IORM).

Anti-Patterns (À éviter)

Stockage de fichiers plats : Exadata n'est pas un NAS pour stocker des PDF ou des images. C'est cher le Go !
Micro-bases isolées : Acheter un 1/4 rack pour une base de 50Go est un non-sens économique.
Applications mal codées (Row-by-Row) : Si votre appli fait 1 million de `SELECT ... WHERE ID = ...` (Single Row Lookup), le Smart Scan ne s'active pas. Exadata sera rapide, mais sous-utilisé.

La commande à connaître

Pour vérifier si vous êtes sur une Exadata via SQL :

SELECT * FROM v$cell_state;

Si cette vue retourne des lignes, félicitations, vous êtes aux commandes d'une Exadata.

Quick Audit Exadata (30–45 min)

Checklist ultra-rapide

Bloc	À vérifier	Signal rouge
Architecture	Compute/Cells/RoCE, modèle rack, HC vs EF, séparation réseaux.	Exadata utilisé “comme un SAN”, pas de offload.
Smart Scan	% offload, SQL éligibles, full scans utiles vs subis.	0% offload, offload inefficace, projections/filters non pushdown.
I/O & Flash	Smart Flash Cache, latence, hotspots, IORM.	Flash “inutile”, IORM non configuré, OLTP pénalisé.
RAC	Balance interconnect, Cache Fusion, skew, services.	Sessions concentrées sur un nœud, latence interconnect.
Patching	ExaChk, rolling patch GI/RDBMS/Cell, dérives.	Retard important, erreurs ExaChk ignorées.
Backup	RMAN, tests restore, RPO/RTO, ZDLRA si présent.	“On n’a jamais testé la restauration”.

Sortie attendue

Top 5 risques (tech + run)
Top 5 quick wins
Plan d’action 30 / 90 / 180 jours

Phrase clé

Exadata n’est pas “un stockage rapide”.
                        C’est un moteur DB + stockage + réseau conçu pour exécuter du SQL au plus près des données.
                        Si Smart Scan / HCC / IORM ne servent pas, 70% du ROI est perdu.

1) Cadre & Périmètre de l’Audit

Objectifs

Évaluer performance réelle (DB + cells + réseau), pas uniquement le SQL.
Mesurer la conformité (patching, ExaChk, bonnes pratiques).
Identifier anti-patterns : Exadata sous-utilisé / mal configuré.
Produire un plan d’actions priorisé : risques → quick wins → chantiers.

Périmètre recommandé

Domaine	Inclus
Infra Exadata	Compute, Cells, RoCE/IB, bandes passantes, latences.
Oracle	DB, RAC, ASM, paramètres, services, workloads.
Run	Outils, observabilité, procédures, patching, capacity.
HA/Backup	RMAN, tests restore, DG, RPO/RTO.

Livrables

Executive summary (risques + décisions)
Grille d’audit détaillée + preuves
Plan d’action 30/90/180 jours
Annexes : commandes / exports / captures / AWR/ASH si dispo

2) Contexte & Workloads

Cartographier le workload (avant toute conclusion)

Type	Caractéristiques	Focus audit
OLTP	latence, commits, pics, contention	IORM, log sync, hotspots, RAC services
DW	scans, agrégations, parallélisme	Smart Scan, HCC, Storage Index, PQ
Mixte	concurrence batch + front	QoS (IORM), séparation ressources
Consolidation	multi-bases sur un rack	isolation workload, capacity planning

Questions “DSI” (à cadrer)

1) Qu’est-ce qui coûte le plus cher : latence OLTP ou durée batch ?
                        2) Les pics sont-ils quotidiens / hebdo / fin de mois ?
                        3) Quel est le RPO/RTO exigé ?
                        4) Quel est le niveau de tolérance au risque “patching” ?
                        5) Exadata est-il on-prem, Cloud@Customer, OCI ?

3) Architecture Exadata (Vue Système)

Triptyque Exadata

Compute Nodes  (DB/RAC/ASM)
                        ↓  RoCE/InfiniBand (RDMA faible latence)
                        Storage Cells  (Smart Scan / Storage Index / HCC / IORM / Flash)

Compute : exécution Oracle + RAC + ASM.
Cells : stockage + “intelligence” (offload SQL).
Réseau : RDMA = perf, Cache Fusion, offload efficace.

Points d’audit

Item	Pourquoi
Modèle rack	Capacités, options flash, réseau (X9M/X10M).
HC vs EF	Alignement usage (DW vs OLTP).
Séparation réseaux	Client / interconnect / backup.
Évolutivité	Scale-out compute/cells, limites réelles.

1️⃣ Architecture Hardware : Le Moteur sous le Capot

Focus : X8M / X9M / X10M

L'Anatomie d'un Rack

Un Exadata n'est pas un assemblage aléatoire. C'est une configuration figée et validée.

Scalabilité "Elastic" : Historiquement, on achetait des 1/8, 1/4, 1/2 racks. Aujourd'hui (depuis X8M), la configuration est Elastic. Vous commencez petit (ex: 2 Computes + 3 Cells) et vous ajoutez des serveurs à l'unité selon le besoin (plus de CPU ? Ajouter un Compute. Plus de disque ? Ajouter une Cell).

Composant	Quantité Min	Rôle Principal
Database Servers	Min 2	Exécutent Oracle Grid Infra + RDBMS. Consomment le stockage.
Storage Servers (Cells)	Min 3	Stockent les données + Exécutent SQL Offload.
RoCE Switches	2 (Redondance)	Connectent tout le monde à 100 Gbps (interne).
Management Switch	1	Pour l'administration (ILOM) - Réseau Ethernet classique.

Schéma Physique Simplifié

[SWITCH RoCE A] ==== [SWITCH RoCE B]
    |      |                |
 [DB NODE 1] <-----------> [DB NODE 2]
    |      |                |
 ------------------------------------
  |      |      |      |      |
 [CELL 1] [CELL 2] [CELL 3]...

Tout le monde parle à tout le monde via le Fabric RoCE.
Pas de câble direct entre DB Node et Cell.

Important : Le "Client Network" (vos applis) arrive uniquement sur les Database Servers. Les Storage Cells sont invisibles depuis l'extérieur.

Database Servers (Les Cerveaux)

OS : Oracle Linux (UEK)

Ce sont des serveurs x86 haut de gamme, mais "standards". C'est ici que vos licences Oracle Database sont consommées (CPU cores).

CPU Intel Xeon (Typiquement 2 sockets)
RAM Massive (512GB à 3TB par nœud)
Disques Locaux 2x NVMe (RAID 1) pour l'OS (boot) et /u01

Le paradoxe du stockage :
Ces serveurs ne stockent AUCUNE donnée utilisateur localement. Vos tablespaces USERS, SYSTEM, UNDOTBS sont tous sur les cellules de stockage, accédés via ASM.

Vue arrière : Ports Dual-port 100Gb RoCE + Ports Client Ethernet (Copper/Fiber)

Configuration RAC (Real Application Clusters)

Par défaut, tous les nœuds compute forment un cluster RAC. Si un nœud crashe, les sessions basculent (Failover) sur les autres nœuds. ASM assure que tous les nœuds voient les mêmes disques (via le réseau).

Storage Servers (Là où réside la magie)

C'est ici que l'Exadata se distingue d'un serveur Dell/HP classique connecté à une baie SAN.

Composant	Détail Technique	Utilité
CPU & RAM	Xeon + ~256GB RAM	Pour exécuter le logiciel CellSRV (Smart Scan). Le stockage a son propre "cerveau".
Flash Cache (NVMe)	~25 TB par cell (HC)	Cache de lecture/écriture intelligent. Transforme les disques lents en disques rapides.
Disques Durs (HC)	12x 18TB HDD (7200 rpm)	Stockage de masse "froid". Pas cher, énorme capacité.
PMEM (Optionnel X8M/X9M)	Persistent Memory (Intel Optane)	Cache ultra-rapide (< 19µs) pour les Commit (Log Write).

Offloading

Sur un SAN, le stockage envoie des blocs.
Sur une Cell, le CPU local analyse les blocs, applique les filtres WHERE et ne renvoie que les lignes utiles.

RDMA over Converged Ethernet (RoCE v2)

Si les Cells sont les muscles, RoCE est le système nerveux instantané.

Analogie Ludique : La Pizzeria

TCP/IP (Réseau classique) : Vous appelez le standard, qui note la commande, la passe au chef, qui la prépare, la donne au livreur... (Latence CPU OS, Kernel context switch).
RDMA (Exadata) : Vous vous téléportez dans la cuisine et prenez la pizza directement sur le plan de travail. (Accès direct à la mémoire RAM du serveur distant sans réveiller son CPU).

Pourquoi RoCE est révolutionnaire ?

Zéro-Copy Networking : Les données vont de la mémoire de la Cell à la mémoire de la DB sans copie intermédiaire dans les buffers de l'OS.
Kernel Bypass : Le CPU de la base de données ne perd pas de cycles à gérer les paquets réseaux.
Latence : ~17 microsecondes (I/O Read). C'est presque aussi rapide que la RAM locale.

sequenceDiagram participant DB as DB Server (RAM) participant NIC as Carte Réseau (RoCE) participant Cell as Cell (RAM) Note over DB, Cell: Lecture RDMA (Zero CPU Cell) DB->>NIC: "Je veux l'adresse mémoire 0x5F sur la Cell 3" NIC->>Cell: Accès Direct (DMA) Cell-->>NIC: Renvoie les données NIC-->>DB: Données placées en RAM Note right of Cell: Le CPU de la Cell
ne s'est même pas réveillé !

Evolution du réseau Exadata

V1 à X8	InfiniBand (40Gbps) : Très rapide, mais câble propriétaire.
X8M à X10M	RoCE v2 (100Gbps) : Utilise des câbles Ethernet standards mais avec le protocole RDMA. Plus rapide, plus standard.

5) Briques Exadata (Perf) – Vérifier l’“effet Exadata”

Smart Scan (Offload SQL vers les Cells)

But : filtrer/projeter/agréger au niveau stockage (moins d’I/O, moins de data remontée).
Audit : SQL éligibles ? offload réel ? anti-patterns (fonctions, accès row-by-row, etc.).

Signal rouge : “Exadata ne change rien, c’est juste plus rapide”.
                    => Souvent : Smart Scan non exploité / requêtes non éligibles.

Storage Index

But : éviter les lectures inutiles (skip scan) via min/max par région.
Audit : tables concernées, bénéfice réel, confusion avec B-Tree.

Hybrid Columnar Compression (HCC)

But : compression massive (surtout données historiques / entrepôt).
Audit : modes utilisés (Query/Archive), impact CPU vs I/O, tables éligibles.

Smart Flash Cache

But : accélérer les lectures chaudes.
Audit : “chaud/froid”, priorisation, interactions avec IORM.

IORM (I/O Resource Manager)

But : QoS des workloads (OLTP prioritaire vs batch).
Audit : stratégie définie, starvation, règles cohérentes avec SLA.

6) Oracle DB / RAC / ASM – Le socle “compute”

Ce qu’on vérifie

Versions RDBMS / GI, cohérence patch level.
ASM : diskgroups, répartition, problèmes d’équilibrage.
RAC : services, répartition sessions, interconnect (Cache Fusion).
Faux “SQL problems” : souvent réseau interconnect / skew.

Symptômes fréquents

- Un nœud RAC “chaud”, un nœud “froid”
                        - Latence interconnect → waits Cache Fusion
                        - Plan SQL ok mais réponse lente → réseau/IO/QoS
                        - “On a Exadata” mais comportements = serveur standard

7) Exploitation & Outils DBA

Outils à auditer (utilisation réelle)

Outil	Rôle	Attendu
CellCLI	Admin & inspection storage cells	Commandes runbook + checks périodiques
DBMCLI	Gestion DB Machine (global)	Vision d’ensemble + actions contrôlées
DCLI	Exécution parallèle multi-nœuds	Automatisation safe + inventaire
ExaCLI	Client distant d’admin	Accès maîtrisé, traçabilité
OEM	Monitoring / alerting	Alertes utiles, dashboards, rétention

Observabilité minimale

KPIs : latence I/O, offload, saturation réseau, erreurs RDMA
KPIs DB : DB Time, top waits, top SQL, événements RAC
Runbook : incidents types + actions “safe”

8) Backup / Restore / HA

Backup

RMAN : stratégie, fenêtres, rétention, stockage cible.
ZDLRA (si présent) : intégration, health, capacité.
Object Storage : coûts, débit, sécurité.

HA / DR

RAC (HA locale)
Data Guard (DR) : sync/async, bascule, runbook
Tests : restore & switchover/failover (obligatoire)

Signal rouge #1 : “On a des backups” ≠ “On sait restaurer”.
                Signal rouge #2 : RPO/RTO non contractualisés (ou non testés).

9) ExaChk & Patching (Conformité)

Ce qu’on patche (vraiment)

Grid Infrastructure (GI)
RDBMS
Cell software / storage server software
Composants réseau / firmware (selon politique)

Rolling patch

Objectif : réduire l’interruption (mais pas “zéro risque”).
Pré-requis : runbook, fenêtres, backups, validation post-patch.

ExaChk

Fréquence : mensuelle / trimestrielle (selon criticité)
Analyse des écarts : “drift” silencieux = danger
Historique : prouver l’amélioration (ou la dérive)

Règle d’or : ExaChk n’est pas un “rapport”, c’est une discipline.
                    Ignorer ExaChk = préparer l’incident.

10) Risques & Recommandations (Roadmap)

Anti-patterns

Exadata utilisé comme baie SAN (sans offload)
Smart Scan non exploité (SQL non éligible / mauvaises pratiques)
Flash mal priorisée, IORM absent → OLTP pénalisé
Patching en retard + ExaChk ignoré
Restore jamais testé

Quick wins

Mesurer offload Smart Scan + corriger SQL “bloquants”
Configurer IORM/QoS (OLTP vs batch)
Nettoyer / prioriser Smart Flash Cache
Rééquilibrer services RAC / sessions
ExaChk + remédiations critiques

Chantiers 1–6 mois

Stratégie HCC (tables éligibles + modes)
Révision architecture workload (séparation, fenêtres batch)
Automatisation runbooks (DCLI, checks, reporting)

Long terme

Cloud@Customer / OCI : stratégie d’évolution
Consolidation + gouvernance capacity
Roadmap hardware (X9M → X10M, options flash)

3️⃣ Le "Secret Sauce" : Smart Scan & Offloading

Offloading : Changer les règles du jeu

Sur une base traditionnelle, la base de données demande des blocs au disque ("Donne-moi le bloc 500"). Sur Exadata, la base envoie la requête SQL au disque ("Donne-moi les employés du département 10"). C'est le Function Shipping.

L'objectif : Réduire le trafic sur l'interconnect (RoCE) de 90% à 99% en filtrant les données à la source (sur les Storage Cells).

Opération	Oracle Classique (Non-Exadata)	Oracle Exadata (Smart Scan)
Protocole	iSCSI / Fibre Channel (Block I/O)	iDB (Intelligent Database Protocol)
Filtrage (WHERE)	Fait par le CPU du DB Server (SGA)	Fait par le CPU de la Cell (Storage)
Projection (SELECT col)	La ligne entière remonte en RAM	Seules les colonnes demandées remontent
Jointures	Toutes les tables remontent au DB Server	Bloom Filters poussés vers le stockage
Déchiffrement (TDE)	Coûteux en CPU DB	Offloadé sur le hardware de la Cell

Flux de Données

graph TD A[SQL: SELECT nom FROM t WHERE id>100] B{Direct Path Read?} C[Envoi iDB vers Cell] D[Cell: Scan Bloc] E[Cell: Filtre id>100] F[Cell: Extrait colonne 'nom'] G[Retourne Result Set] A --> B B -- OUI --> C C --> D --> E --> F --> G B -- NON (Buffer Cache) --> H[Lecture Bloc Classique] style E fill:#f9f,stroke:#333 style F fill:#f9f,stroke:#333

Le CPU de la Cell fait le travail sale. Le DB Node ne reçoit que le "diamant poli".

Condition Sine Qua Non : Le Direct Path Read

Le Smart Scan ne fonctionne JAMAIS si les blocs passent par le Buffer Cache (SGA). Il ne s'active que lors d'un Direct Path Read (lecture directe disque -> PGA).
Cela arrive généralement lors de : Full Table Scans ou Fast Full Index Scans sur des gros segments.

1. Storage Indexes (SI)

Les Storage Cells maintiennent en mémoire une carte "Min/Max" pour chaque 1MB de données sur le disque.

Principe : Si je cherche WHERE ID = 5 et que le Storage Index me dit que dans la région A, le Min est 10 et le Max est 100, la Cellule ne lit même pas le disque (I/O Avoidance).
Transparence : C'est automatique. Pas de CREATE INDEX à faire.
Limitations : Ne fonctionne pas si les données sont trop fragmentées (pas de corrélation physique).

2. Bloom Filters Offload

Optimisation massive des jointures (Hash Joins).

"Au lieu de remonter toute la table B pour la joindre à A, la DB crée un hachage (signature) des clés de A, l'envoie aux Cells, et les Cells utilisent cette signature pour filtrer B avant l'envoi."

3. Autres Offloads Supportés

JSON & XML	Le parsing et le filtrage des documents JSON/XML se fait dans la Cell. Seul le fragment JSON demandé remonte.
LOBs	SecureFiles LOBs bénéficient aussi du Smart Scan (compression + déduplication).
Fonctions SQL	La plupart des fonctions (SUBSTR, TO_DATE, REGEXP) sont exécutées par la Cell.
Data Mining	Scoring de modèles machine learning offloadé.
Backup (RMAN)	La compression des backups RMAN est faite par les CPU des Cells, libérant le serveur DB.

Visualisation Bloom Filter

Table A (Petite) -> Hash -> Cell -> Filtrage Table B (Grosse) -> Résultat

Hybrid Columnar Compression (HCC)

Exclusif à Exadata (et ZFS). Contrairement à la compression classique (par bloc), HCC organise les données par Compression Unit (CU).

Pourquoi "Hybride" ?

Logique : Les données sont stockées colonne par colonne à l'intérieur d'un gros bloc (CU). Cela permet une compression folle (données répétitives).
Physique : Ça reste compatible avec les blocs Oracle classiques pour les lectures.

Mode HCC	Taux Compression	Usage Typique
`QUERY LOW`	2x - 4x	DWH Actif, bonnes perfs de scan.
`QUERY HIGH`	6x - 10x	Le standard Exadata DWH. Excellent compromis.
`ARCHIVE HIGH`	15x - 50x+	Données froides/historiques. Accès rare. CPU intensif à la décompression.

Le piège du DML (Locking) : Attention ! Une mise à jour (UPDATE) sur une ligne compressée HCC verrouille toute la "Compression Unit" (qui peut contenir des milliers de lignes).
Règle d'or : HCC est pour les données en lecture seule ou chargement en masse (Bulk Load). Pour l'OLTP, restez en COMPRESS FOR OLTP (Advanced Compression).

Prouver que ça marche (ou pourquoi ça ne marche pas)

1. Les Wait Events à surveiller

cell smart table scan
Le Graal. Indique que le Smart Scan est actif.
cell single block physical read
Lecture classique indexée. Normal pour OLTP, mauvais pour DWH.
cell multiblock physical read
Le Smart Scan a échoué ! Oracle a fait du Full Scan mais a rapatrié les blocs (Pas d'offload).

2. La colonne magique

Dans SQL Monitor ou v$sql, cherchez IO_CELL_OFFLOAD_ELIGIBLE_BYTES vs IO_INTERCONNECT_BYTES.

Efficiency = (Eligible - Interconnect) / Eligible * 100

3. Pourquoi mon Smart Scan ne part pas ?

Cause	Solution
Scan via Buffer Cache	Forcer Direct Path (`_serial_direct_read=true` ou Parallel Query).
Lignes chaînées (Chained Rows)	Reconstruire la table (Les cellules ne gèrent pas le chaînage).
Table trop petite	Oracle estime qu'il est plus rapide de la mettre en cache.
Type de données non supporté	Ex: Colonnes LONG (obsolète), certaines types ADT complexes.

Exemple de gain réel :

IO Interconnect (100MB)

Filtered by Cell (900MB)

Focus : IORM / QoS

Pourquoi c’est critique en prod

Sans QoS, un batch DW peut “manger” les I/O et tuer l’OLTP.
IORM permet d’exprimer une priorité alignée sur le business.

Objectif audit : prouver qu’un pic batch n’écrase pas la latence OLTP
                => QoS, règles, et monitoring corrélé.

🟥 Oracle Exadata – Audit Framework & Production Checklist

Introduction à Exadata

Cadre & Périmètre

Contexte & Workloads

Architecture Exadata

Audit Hardware

Briques Exadata (Perf)

Oracle DB / RAC / ASM

Exploitation & Outils DBA

Backup / Restore / HA

Patching & ExaChk

Risques & Recos