Comment utiliser l'IA quand on est Administrateur de Bases de Données Oracle ?
Prompts et workflows 2026

Tu es un Administrateur de Bases de Données Oracle senior. Un développeur signale que l'application de facturation est devenue lente depuis ce matin. Ta mission:

1. Génère un rapport AWR (Automatic Workload Repository) pour la plage horaire 08h00-10h00 avec les 10 premiers SQL par temps d'exécution total
2. Exécute une analyse ADDM sur le snapshot le plus récent
3. Identifie les 3 problèmes majeurs remontés par ADDM
4. Pour chaque problème, fournis:
   - La requête SQL associée (si applicable)
   - La commande SQL de tuning recommandée (EXPLAIN PLAN, индекс reconstruction, mise à jour des statistiques...)
   - Le gain estimé en pourcentage

Format de sortie attendu:
- Section AWR: Top SQL avec plan d'exécution estimé
- Section ADDM: Findings classées par impact
- Plan d'action priorisé avec délais de mise en œuvre

En tant que DBA Oracle sur un système de production critique (OLTP, 2TB de données, RPO=15min, RTO=1h), rédige:

1. **Politique RMAN complète**:
   - Script backup incrémental level 0 (quotidien à 2h00)
   - Script backup incrémental level 1 (toutes les 6h)
   - Script backup archive logs (toutes les 15min)
   - Configuration RMAN avec compression, encryption et backup optimization
   - Stratégie de rétention (recovery window 7 jours)

2. **Plan de recovery documenté**:
   - Scénario 1: Perte d'un datafile (recovery online)
   - Scénario 2: Perte du controlfile
   - Scénario 3: Crash total (loss of all disks)
   - Scénario 4: Corruption de bloc sur SYSTEM tablespace

3. **Procédure de TEST DE RECOVERY**:
   - Script de validation hebdomadaire des backups
   - Commande RMAN: RESTORE DATABASE VALIDATE
   - Vérification de la recoverabilité à un point dans le temps
   - Checklist de validation post-restore

4. **Script de monitoring**:
   - Alerte si backup > 4h ou échoue
   - Contrôle de l'espace disk utilisé par RMAN
   - Vérification de la chaîne de recoverabilité

Une alerte critique arrive: 'TS_FACTURATION reached 98% capacity'. Tu as 30 minutes avant un blocage total. Agis méthodiquement:

**Phase 1 - Diagnostic immédiat** (5 min):
- Requêtes pour identifier l'utilisation exacte des tablespaces
- Identification des segments qui consomment le plus d'espace
- Vérification de l'espace disque disponible sur le serveur
- Historique de croissance pour projections

**Phase 2 - Actions de secours urgentes** (10 min):
-resize du tablespace si espace disponible
- Déplacement/historisation de données anciennes
- Compression de tables avec SHRINK SPACE
- Commands: ALTER TABLESPACE ADD DATAFILE, RESIZE

**Phase 3 - Solution durable** (15 min):
- Implementation de tablespaces bigfile si compatible
- Configuration d'alertes proactives (seuil 80%)
- Script de monitoring quotidien de la croissance
- Recommandation pour partitioning strategy

**Deliverables**:
- Commandes SQL prêtes à copier-coller
- Timeline d'exécution
- Validation post-action
- Procédure de prévention pour le futur

Mission: Migrer la base PROD_FINANCE (800GB, Oracle 12.1.0.2 vers 19c, même OS Linux RHEL 7.9) avec méthode Transportable Tablespaces (TTS) pour minimiser le downtime.

**Plan de migration détaillé:**

1. **Phase préparation (Week-end J-7)**:
   - Pré-check automatisé de compatibilité
   - Validation des prérequis 19c
   - Script de gather stats complet sur source
   - Export des metadata avec Data Pump
   - Commandes: DBMS_TTS, expdp/impdp avec TRANSPORT_TABLESPACES

2. **Phase Pre-Migration (Jour J, 6h-14h)**:
   - Convertir les datafiles au format 19c (CONVERT)
   - Transfert réseau ou NFS des datafiles
   - Import des metadata sur target
   - Script de vérification d'intégrité

3. **Phase Cutover (Jour J, 14h-18h)**:
   - Quiesce de l'application
   - Export final des transactions
   - Switch vers nouvelle base
   - Commandes: IMPDP, DBMS_DBCORA, ALTER DATABASE

4. **Validation post-migration**:
   - Script de validation schema integrity
   - Comparaison counts tables source vs target
   - Tests de connectivité applicatifs
   - Validation des jobs scheduler
   - Vérification AWR baseline

**Rollback plan:**
- Procédure de retour arrière en < 30 minutes
- Points de no-return clairement identifiés

**Checklist Go/NoGo:**
- Critères de validation pour chaque phase
- Signatures requises (DBA Lead, App Owner)