Oracle 23ai : ce qui change vraiment pour le DBA

Oracle 23ai est présenté comme la version de l'IA. C'est vrai, mais ce n'est pas le sujet qui intéresse le DBA terrain. Voici ce qui change concrètement dans le quotidien d'un administrateur de bases Oracle.

True Cache : une vraie nouveauté pour les lectures

True Cache est une cache locale en lecture seule synchronisée automatiquement avec la base principale. Contrairement à un Data Guard standby, pas besoin de redo apply : la synchronisation est faite au niveau du cache buffer.

-- Créer un True Cache (côté primaire)
ALTER SYSTEM SET TRUE_CACHE_SIZE=4G SCOPE=SPFILE;

-- Configurer un service de cache
BEGIN
  DBMS_TRUE_CACHE.CONFIGURE(
    service_name => 'CACHE_SALES',
    cache_mode   => 'AUTOMATIC'
  );
END;

Impact DBA : plus besoin de scaler verticalement la base principale pour supporter un surplus de lectures. Le True Cache absorbe nativelement les requêtes SELECT sans modification applicative. C'est utile pour les rapports décisionnels et les requêtes batch qui impactent la production.

Priority de transactions : fin de la politique de l'autruche

-- Définir une transaction prioritaire
BEGIN
  DBMS_TRANSACTION.SET_PRIORITY('HIGH');
  -- Transaction critique ici
  UPDATE compte SET solde = solde - 10000 WHERE id = 42;
  COMMIT;
END;

Les transactions prioritaires passent devant les autres dans les conflits de lock. Applicatif prioritaire (paiement, réservation) vs batch non prioritaire (calcul de stats, purge). Le DBA n'a plus à tuer des sessions manuellement.

Ce que ça change : plus de "kill session" à 3h du matin parce qu'un batch bloque une transaction critique. C'est géré par le SGBD.

Propriétés de schéma : des paramètres par défaut applicatifs

CREATE SCHEMA app_compta
  DEFAULT TABLESPACE tbs_compta
  DEFAULT COLLATION fr_FR.UTF8
  CONTAINER = CURRENT;

Chaque schéma peut maintenant avoir ses propres valeurs par défaut. Fini les ALTER SESSION SET en début de chaque connexion applicative. Les paramètres sont automatiques à la connexion.

Vues asynchrones matérialisées (refresh permanent)

CREATE MATERIALIZED VIEW mv_ventes_jour
AS SELECT date_vente, SUM(montant) total
FROM ventes
GROUP BY date_vente
REFRESH EVERY 5 MINUTES;

Le refresh se fait en continu sans intervention DBA. Plus de jobs de refresh à configurer, plus de fenêtre de maintenance pour rafraîchir les vues. C'est un gain de temps significatif pour les DBA qui gèrent des environnements décisionnels.

Améliorations de l'optimiseur qui changent la vie

Quelques nouveautés subtiles mais puissantes :

-- Optimisation des requêtes avec beaucoup de valeurs IN
SELECT * FROM commandes
WHERE client_id IN (SELECT client_id FROM clients_vip);
-- Oracle 23ai optimise automatiquement avec un bloom filter intégré

-- Statistiques sur les expressions
SELECT * FROM employes
WHERE UPPER(nom) = 'DUPONT';
-- 23ai crée automatiquement des histogrammes sur les expressions

Résultat : moins de plans d'exécution déviants à corriger, moins de SQL profiles à créer manuellement. L'optimiseur est meilleur.

Pour le DBA quotidien : les petites choses qui comptent

-- ALTER TABLE sans rebuild d'index
ALTER TABLE gros_table MODIFY (col VARCHAR2(200));
-- Plus besoin de rebuild des indexes (gain en maintenance)

-- Force ALL_ROWS par session
ALTER SESSION SET OPTIMIZER_MODE = ALL_ROWS;
-- Enfin possible sans toucher au paramètre global

-- Arrêt du DataGuard en douceur
ALTER DATABASE STOP APPLY LOG;
ALTER DATABASE RESUME APPLY LOG;
-- (oui, ça existait avant mais amélioré en 23ai)

Ce qu'il faut retenir (vraiment)

Fonctionnalité	Impact DBA	Priorité
True Cache	Réduction charge lecture	Haute
Priorité transactions	Moins d'incidents nocturnes	Haute
Vues asynchrones	Moins de jobs manuels	Moyenne
Optimiseur amélioré	Moins de régressions	Haute
Propriétés de schéma	Configuration simplifiée	Moyenne

À retenir : Oracle 23ai n'est pas une version "IA gadget". True Cache et la priorisation des transactions sont des fonctionnalités solides qui changent le quotidien. La migration de 19c vers 23ai n'est pas urgente (19c est LTS jusqu'en 2028), mais les projets de migration devraient commencer à se préparer dès 2026.