L’administrateur de bases de données (DBA) est responsable du cycle de vie des bases : installation, configuration, sauvegarde, restauration, optimisation, sécurité et mise à jour. Il existe plusieurs spécialités : DBA de production (disponibilité), DBA de développement (modélisation, optimisation), DBA cloud (bases managées AWS RDS, Azure SQL). Les compétences clés incluent la maîtrise du SQL, la connaissance des moteurs (PostgreSQL, MySQL, Oracle, SQL Server), la gestion des index, et l’automatisation avec des scripts (bash, Python). ISOSET propose des cursus complets pour devenir DBA, de la théorie à la mise en production.

• DBA Production – surveille les performances, gère les sauvegardes, intervient en incident.
• DBA Développement – conseille les développeurs, normalise les schémas, valide les migrations.
• DBA Cloud – optimise les coûts, gère les réplicas, exploite les services managés.

L’installation d’un SGBD (PostgreSQL, MySQL, etc.) ne se limite pas à `apt install`. Le DBA doit choisir les bons paramètres : répertoires de données (disques distincts pour logs, données, sauvegardes), mémoire (shared_buffers, effective_cache_size, innodb_buffer_pool_size), connexions (max_connections), et méthodes d’authentification (scram‑sha‑256, certificats). Il est recommandé d’isoler les bases sur des volumes séparés, d’activer le chiffrement au repos (TDE) et de respecter le principe du moindre privilège pour les comptes d’application. ISOSET aide les entreprises à définir leur politique d’installation et de configuration.

# my.cnf (MySQL) – extraits clés
[mysqld]
innodb_buffer_pool_size = 8G
max_connections = 500
slow_query_log = 1
long_query_time = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 7

Une stratégie de sauvegarde robuste combine sauvegardes complètes (hebdomadaires), différentielles (quotidiennes) et journalières (logs de transactions, WAL). On utilise des outils comme `pg_dumpall` / `pg_basebackup` (PostgreSQL), `mysqldump` / `mysqlbinlog` (MySQL), ou des solutions externes (Percona XtraBackup, pgBackRest). Les sauvegardes doivent être stockées hors site (autre région cloud, site distant) et leur restauration testée régulièrement (au moins une fois par trimestre).

# Backup incrémental avec pgBackRest
pgbackrest backup --stanza=ma_base --type=incr
# Restauration complète
pgbackrest restore --stanza=ma_base --delta

Le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective) doivent être définis avec les métiers. ISOSET forme à la mise en œuvre de plans de reprise d’activité.

Le DBA surveille en continu les métriques critiques : taux d’utilisation CPU, mémoire, IOPS disque, taille des bases, nombre de connexions, temps de verrouillage, taux de hits cache, et requêtes lentes. Des solutions open source comme Prometheus + Grafana, ou commerciales (Datadog, New Relic), permettent de collecter ces indicateurs et de définir des alertes (ex: disque > 80%, connexions > 150, deadlocks). Les logs du SGBD (error log, slow query log) sont aussi analysés.

# Requête pour surveiller les connexions actives (PostgreSQL)
SELECT count(*) FROM pg_stat_activity WHERE state = 'active';
# Alerte Prometheus (exemple rule)
- alert: HighConnections
  expr: pg_stat_database_numbackends > 200
  for: 5m

ISOSET propose des ateliers pratiques de supervision de bases avec la stack Prometheus/Grafana.

L’optimisation des performances est un travail quotidien. On agit sur trois leviers :

• Index – créer les bons index (B‑tree, bitmap, partial) sur les colonnes filtrées dans WHERE, JOIN, ORDER BY. Éviter la sur‑indexation (impact sur écritures).
• Requêtes – analyser les plans d’exécution (EXPLAIN ANALYZE), réécrire les sous‑requêtes corrélées en jointures, éviter SELECT *, fractionner les requêtes complexes.
• Configuration SGBD – ajuster les buffers, le parallélisme, les paramètres d’écriture (checkpoint, WAL).

# Détecter les index inutilisés (PostgreSQL)
SELECT schemaname, tablename, indexname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0;
# Créer un index partiel
CREATE INDEX idx_commandes_active ON commandes(date) WHERE status = 'active';

ISOSET initie les jeunes à l’impact des index sur des jeux de données massifs.

La sécurité des bases repose sur des comptes dédiés avec des droits strictement nécessaires. On crée des rôles (lecture seule, lecture/écriture, administrateur) et on les attribue aux utilisateurs. L’authentification doit être forte (LDAP, Kerberos, IAM pour le cloud). Les mots de passe sont hachés (SCRAM‑SHA‑256, bcrypt) et régulièrement changés. Les accès sont révoqués lors des départs. La journalisation des connexions (log_connections) et des tentatives échouées est activée.

# Créer un utilisateur avec des droits restreints (MySQL)
CREATE USER 'app_read'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT ON ma_base.* TO 'app_read'@'%';
# PostgreSQL : rôle en lecture seule
CREATE ROLE app_ro LOGIN PASSWORD 'xxx';
GRANT CONNECT ON DATABASE ma_base TO app_ro;
GRANT USAGE ON SCHEMA public TO app_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;

ISOSET forme les DBA à l’audit des privilèges et à la mise en place de la sécurité au niveau des lignes (RLS).

Pour garantir une disponibilité élevée (99,9% à 99,99%), on met en place des réplicas (standby) avec réplication synchrone ou asynchrone. Les solutions : PostgreSQL (Streaming Replication + Patroni ou repmgr), MySQL (Group Replication, InnoDB Cluster), SQL Server (Always On). Un cluster de basculement automatique (failover) associé à un load balancer (HAProxy, ProxySQL) permet de rediriger le trafic en cas de panne du primaire. La réplication multi‑régions assure la continuité en cas de sinistre majeur.

# Configuration d’un réplica PostgreSQL (recovery.conf)
primary_conninfo = 'host=primary_ip port=5432 user=replicator password=...'
restore_command = 'cp /archive/%f %p'
recovery_target_timeline = 'latest'

ISOSET propose des exercices pratiques de montée en charge avec réplication.

La maintenance préventive évite la dégradation des performances.

• VACUUM (PostgreSQL) – nettoie les tuples morts, évite le bloat. L’autovacuum doit être activé et paramétré (seuils).
• OPTIMIZE TABLE (MySQL) – défragmente les tables InnoDB.
• ANALYZE / VACUUM ANALYZE – met à jour les statistiques pour l’optimiseur.
• Purge des logs – supprimer les journaux de transactions au‑delà de la rétention définie.

# Script de maintenance automatique (cron)
0 2 * * * /usr/bin/vacuumdb --all --analyze --verbose >> /var/log/dba/vacuum.log

• pgAdmin / phpMyAdmin / Azure Data Studio – interfaces graphiques.
• DBeaver – client universel multi‑SGBD.
• Prometheus + Grafana – monitoring open source.
• pt‑query‑digest (Percona Toolkit) – analyse des logs de requêtes lentes.
• pgBackRest / Percona XtraBackup – sauvegardes physiques incrémentales.
• Ansible / Terraform – infrastructure as code pour les bases.

# Étapes pour migrer PostgreSQL avec réplication logique (peu d’indisponibilité)
1. Créer un abonnement sur le serveur source vers le serveur cible (publication)
2. Synchroniser le schéma (pg_dump --schema-only)
3. Copier les données initiales avec pg_dump --data-only
4. Activer la réplication logique
5. Basculer les applications après rattrapage

Ce type de migration permet un temps d’arrêt inférieur à 5 minutes pour des bases volumineuses.

Les témoignages d’anciens élèves d’ISOSET : *« La formation DBA m’a appris à configurer un cluster PostgreSQL haute disponibilité avec Patroni, à analyser les plans de requêtes et à automatiser les sauvegardes. Aujourd’hui, je gère des bases critiques pour une banque. »*