Crapule421/tiger-team

Référence DBA

Règles d'utilisation : les commandes ci-dessous sont les formes stables et bien connues. Le comportement diffère selon les versions et les éditions (licences !) – lorsqu'une ligne dit "vérifiez selon votre version", consultez la documentation du fournisseur pour la version exacte avant de vous y fier. N'exécutez jamais d'instructions de diagnostic qui modifient les données en production sans un enregistrement de changement.

1. Comparaison rapide des moteurs

Sujet	Oracle	PostgreSQL	SQL Server	Db2 LUW	MySQL / MariaDB (InnoDB)
Modèle de concurrence	MVCC (undo) ; les lecteurs ne bloquent jamais les rédacteurs	MVCC (versions de lignes dans la table ; VACUUM)	Verrouillage par défaut ; MVCC si RCSI/instantané activé	Verrouillage ; lectures "currently committed" (CUR_COMMIT)	MVCC (undo) + verrous next-key/gap dans REPEATABLE READ (défaut)
DDL transactionnel	Non (commit implicite avant/après)	Oui (sauf e.g. CREATE INDEX CONCURRENTLY, CREATE DATABASE, VACUUM)	Oui pour la plupart des DDL	Oui pour la plupart des DDL (vérifiez par instruction)	Non (commit implicite ; le DDL MySQL 8 est atomique par instruction seulement)
Escalade de verrou	Jamais	Jamais	Oui (ligne/page -> table, ~5000 verrous par objet par instruction)	Oui (LOCKLIST/MAXLOCKS)	Non (mais verrous gap)
Statistiques de requêtes	AWR/ASH (Diagnostics Pack), Statspack	pg_stat_statements	Query Store, DMVs	Fonctions table MON_GET_*	performance_schema, sys schema, slow log
Délai d'attente verrou session	ALTER SESSION SET DDL_LOCK_TIMEOUT = 30; (DDL, secondes)	SET lock_timeout = '5s';	SET LOCK_TIMEOUT 5000; (ms)	SET CURRENT LOCK TIMEOUT 30; (s)	SET SESSION lock_wait_timeout = 30; (verrous metadata) + innodb_lock_wait_timeout (verrous de ligne)

2. Diagnostic de performance

Méthode : (1) définir le symptôme (une requête, une fenêtre temporelle, l'instance entière) ; (2) regarder les temps d'attente/modèle temporel avant de tuner la SQL ; (3) obtenir le plan réel (pas seulement estimé) ; (4) comparer les lignes estimées vs réelles – les mauvaises estimations de cardinalité sont la cause racine habituelle (statistiques obsolètes, asymétrie, prédicats corrélés, paramètre sniffing/bind peeking) ; (5) changer une chose, mesurer.

Oracle

• Plan estimé : EXPLAIN PLAN FOR <stmt>; puis SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
• Plan réel : exécuter avec /*+ GATHER_PLAN_STATISTICS */ puis SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>', NULL, 'ALLSTATS LAST'));
• AWR/ASH/ADDM (@?/rdbms/admin/awrrpt.sql, ashrpt.sql, addmrpt.sql, V$ACTIVE_SESSION_HISTORY, DBA_HIST_*) nécessitent le Diagnostics Pack (Enterprise Edition) ; SQL Monitor et SQL Tuning Advisor nécessitent le Tuning Pack. Vérifiez CONTROL_MANAGEMENT_PACK_ACCESS. Sans licence : Statspack.
• Attentes en direct : V$SESSION (event, wait_class, sql_id, blocking_session), V$SYSTEM_EVENT, V$SQL / V$SQLSTATS.
• Attentes courantes : db file sequential read (monobloc, accès index), db file scattered read / direct path read (analyses complètes), log file sync (fréquence des commits / E/S de redo), enq: TX - row lock contention (verrouillage applicatif), enq: TM - contention (souvent clés étrangères non indexées), latch: cache buffers chains (blocs chauds), gc * (interconnect RAC).
• Stabilité du plan : SQL Plan Management (baselines) ; les profils SQL nécessitent le Tuning Pack.

PostgreSQL

• EXPLAIN (ANALYZE, BUFFERS) <stmt>; – ANALYZE exécute l'instruction : encapsulez le DML dans BEGIN; ... ROLLBACK;.
• pg_stat_statements (nécessite shared_preload_libraries) : top SQL par total_exec_time (les noms de colonnes ont changé dans PG13 : total_exec_time, mean_exec_time). SELECT queryid, calls, round(total_exec_time) total_ms, round(mean_exec_time::numeric,1) mean_ms, rows, left(query,80) FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20;
• En direct : pg_stat_activity (state, wait_event_type, wait_event, xact_start, query) ; les sessions idle in transaction maintiennent des verrous et bloquent VACUUM.
• Module auto_explain pour les plans lents dans les logs ; track_io_timing = on pour les temporisations d'E/S.
• Santé : pg_stat_user_tables (seq_scan, n_dead_tup, last_autovacuum, last_autoanalyze) ; bloat ; contournement d'ID de transaction : SELECT datname, age(datfrozenxid) FROM pg_database;.
• Tueur : pg_cancel_backend(pid) (requête) puis pg_terminate_backend(pid) (session).

SQL Server

• Plan réel : SSMS "Inclure le plan d'exécution réel" ou SET STATISTICS XML ON; ; SET STATISTICS IO, TIME ON; pour les lectures/CPU.
• Query Store (2016+ ; ACTIVÉ par défaut pour les nouvelles bases de données en 2022) : sys.query_store_query, sys.query_store_query_text, sys.query_store_plan, sys.query_store_runtime_stats, sys.query_store_wait_stats (2017+) ; régressions -> forçage de plan EXEC sp_query_store_force_plan @query_id = <q>, @plan_id = <p>;.
• DMVs : sys.dm_exec_requests (wait_type, blocking_session_id), sys.dm_os_wait_stats, sys.dm_exec_query_stats + CROSS APPLY sys.dm_exec_sql_text(sql_handle) + sys.dm_exec_query_plan(plan_handle).
• Attentes courantes : PAGEIOLATCH_* (lectures de données), LCK_M_* (blocage), WRITELOG (E/S de log / taux de commit), CXPACKET/CXCONSUMER (parallélisme – vérifiez MAXDOP/seuil de coût), SOS_SCHEDULER_YIELD (CPU), ASYNC_NETWORK_IO (client ne consomme pas les résultats), RESOURCE_SEMAPHORE (allocations mémoire).
• Parameter sniffing : comparez les plans par paramètre ; options OPTION (RECOMPILE), OPTIMIZE FOR, Query Store hints (2022) – choisissez selon le cas.
• Extended Events ; la session system_health conserve les graphes d'interblocage récents.

Db2 LUW

• Explain : créez les tables explain (SYSPROC.SYSINSTALLOBJECTS ou EXPLAIN.DDL), EXPLAIN PLAN FOR <stmt>, formatez avec db2exfmt -d <DB> -1 -o plan.txt ; vue rapide db2expln.
• Fonctions table de surveillance : MON_GET_PKG_CACHE_STMT (top SQL : STMT_EXEC_TIME, NUM_EXECUTIONS, ROWS_READ), MON_GET_CONNECTION, MON_GET_ACTIVITY, MON_GET_TABLE, MON_GET_BUFFERPOOL.
• Verrous : SYSIBMADM.MON_LOCKWAITS, db2pd -db <DB> -wlocks, db2pd -db <DB> -locks.
• Statistiques : RUNSTATS ON TABLE <SCHEMA>.<TABLE> WITH DISTRIBUTION AND DETAILED INDEXES ALL; – REORGCHK pour évaluer les besoins de réorganisation ; db2advis pour des conseils d'index.

MySQL / MariaDB

• EXPLAIN <stmt> ; réel : MySQL 8.0.18+ EXPLAIN ANALYZE <stmt> ; MariaDB ANALYZE <stmt> (les deux exécutent l'instruction).
• Top SQL : sys.statement_analysis, performance_schema.events_statements_summary_by_digest ; slow query log (slow_query_log, long_query_time) + pt-query-digest.
• InnoDB : SHOW ENGINE INNODB STATUS\G (dernier deadlock, longueur de la liste d'historique), information_schema.INNODB_TRX, sys.innodb_lock_waits ; MySQL 8 : performance_schema.data_locks / data_lock_waits ; MariaDB : information_schema.INNODB_LOCKS / INNODB_LOCK_WAITS et l'extension METADATA_LOCK_INFO ; verrous de metadata MySQL : performance_schema.metadata_locks.

3. Verrouillage et concurrence - pièges

Moteur	Piège	Atténuation
Tous	Transaction longue + DDL : le DDL attend, et chaque requête ultérieure fait la queue derrière	Délai d'attente court sur le DDL, boucle de tentative, exécuter quand il n'y a pas de transactions longues ; vérifier avant (sessions actives)
Oracle	Clés étrangères non indexées -> verrous TM sur l'enfant lorsque des lignes parent sont supprimées/la PK est mise à jour	Indexer les colonnes FK
Oracle	Le DDL échoue avec ORA-00054 sur un objet occupé	DDL_LOCK_TIMEOUT ; variantes en ligne (CREATE INDEX ... ONLINE, ALTER TABLE ... MOVE ONLINE 12.2+, DBMS_REDEFINITION) – toutes Enterprise Edition seulement (pas dans SE2)
Oracle	Commit dans une boucle sur un curseur ouvert -> ORA-01555 snapshot too old	Segmentation par plages de clés/rowid (DBMS_PARALLEL_EXECUTE), dimensionner la rétention d'undo
PostgreSQL	La plupart des ALTER TABLE prennent ACCESS EXCLUSIVE ; l'attente bloque tous les lecteurs	SET lock_timeout ; CREATE INDEX CONCURRENTLY ; FK/CHECK NOT VALID puis VALIDATE CONSTRAINT
PostgreSQL	Le changement de type de colonne réécrit la table (sauf cas sûrs comme l'augmentation de la longueur varchar)	Expand/contract avec une nouvelle colonne + backfill
PostgreSQL	Sessions idle in transaction	idle_in_transaction_session_timeout, corriger l'application
SQL Server	Les lecteurs bloquent les rédacteurs sous READ COMMITTED par défaut	Évaluer READ_COMMITTED_SNAPSHOT ON (impact sur le magasin de versions tempdb ; tester)
SQL Server	Escalade de verrou vers la table sur un grand DML	Lots en dessous de ~5000 lignes ; ALTER TABLE ... SET (LOCK_ESCALATION = ...) avec précaution
SQL Server	NOLOCK utilisé comme "correctif"	Lectures sales, lignes manquantes/dupliquées – rejeter dans les revues
Db2	LOCKTIMEOUT = -1 (attendre indéfiniment) par défaut	Définir CURRENT LOCK TIMEOUT dans les sessions de release
Db2	ALTER TABLE ... DROP COLUMN, la plupart des ALTER COLUMN SET DATA TYPE, SET NOT NULL/DROP NOT NULL mettent une table organisée en lignes en état reorg-pending (SQLSTATE 57007) : jusqu'à REORG TABLE seules les analyses, DROP/RENAME/TRUNCATE et la plupart des autres ALTER sont autorisés ; au plus 31 unités de travail de ces opérations avant que REORG ne devienne obligatoire	Planifier REORG TABLE dans la fenêtre ; vérifier REORG_PENDING / NUM_REORG_REC_ALTERS dans SYSIBMADM.ADMINTABINFO
MySQL	Attentes de verrou metadata (MDL) : DDL bloqué par une transaction ouverte puis bloque tout le monde	lock_wait_timeout bas dans la session de release ; tuer les transactions longues inactives
MySQL	Le DDL en ligne retombe silencieusement sur une copie de table	Toujours spécifier ALGORITHM=INSTANT (ou INPLACE) avec LOCK=NONE pour qu'il génère une erreur sinon ; ou gh-ost / pt-online-schema-change
MySQL	Verrous gap/next-key sur les mises à jour de plage sous REPEATABLE READ	Indexer le prédicat ; envisager READ COMMITTED là où c'est acceptable

Interblocages : toujours un problème de conception (ordre d'accès incohérent, index manquants). Capture : fichier trace Oracle / alert log (ORA-00060), log PostgreSQL (log_lock_waits = on pour les attentes > deadlock_timeout), SQL Server system_health XE, moniteur d'événements Db2 pour le verrouillage, MySQL innodb_print_all_deadlocks.

4. HA / DR

Moteur	HA locale	DR / réplicas	Opérations clés & vérifications
Oracle	RAC (stockage partagé, actif-actif, licence supplémentaire)	Data Guard physical standby (redo apply) ; Active Data Guard = ouvert en lecture seule avec apply (licence supplémentaire)	Modes de protection : Maximum Performance (ASYNC, défaut), Maximum Availability (SYNC, repli), Maximum Protection (SYNC, le primaire s'arrête si aucun standby). Broker dgmgrl : SHOW CONFIGURATION;, VALIDATE DATABASE <stby>;, SWITCHOVER TO <stby>;, FAILOVER TO <stby>;. Lag : V$DATAGUARD_STATS. Primaire en FORCE LOGGING. Fast-Start Failover nécessite un observer (idéalement sur un troisième site).
PostgreSQL	Patroni (DCS : etcd/Consul/ZooKeeper) + HAProxy/VIP	Réplication streaming (physique, WAL) ; réplication logique (publications/subscriptions, PG10+)	pg_stat_replication (sent_lsn, write_lsn, flush_lsn, play_lsn), pg_is_in_recovery(), pg_promote() (PG12+). Sync : synchronous_standby_names + synchronous_commit. Les slots de réplication retiennent le WAL si un réplica est down -> disque plein : surveiller, plafonner avec max_slot_wal_keep_size (PG13+). Patroni : patronictl -c <cfg> list / switchover / failover ; points de terminaison REST health (/primary, /replica) pour le répartiteur de charge. La réplication logique ne réplique ni le DDL ni les valeurs de séquence (à partir de PG 18) : appliquez les changements de schéma additifs sur le subscriber en premier et réinitialisez les séquences avant de basculer sur un subscriber.
SQL Server	Instance de cluster de basculement (stockage partagé, WSFC)	Groupes de disponibilité Always On (WSFC, ou Pacemaker sur Linux) ; log shipping	Basculement automatique uniquement entre réplicas synchrones. Listener pour les clients (MultiSubnetFailover=True). Les logins, jobs Agent, serveurs liés, credentials ne sont PAS répliqués (AG contenu, SQL Server 2022 Enterprise, aide). Les AG complètes nécessitent Enterprise ; Basic AG sur Standard Edition (1 DB, 2 réplicas). Vérifier sys.dm_hadr_database_replica_states. Basculement planifié : ALTER AVAILABILITY GROUP [<AG>] FAILOVER; sur le réplica secondaire synchrone cible. Les secondaires lisibles ont un impact sur les licences.
Db2 LUW	pureScale (actif-actif) ou HADR + automatisation Pacemaker/TSA	HADR (jusqu'à 3 standbys, HADR_TARGET_LIST)	HADR_SYNCMODE : SYNC, NEARSYNC, ASYNC, SUPERASYNC. Surveiller db2pd -db <DB> -hadr ou MON_GET_HADR. Basculement de rôle sur le standby : TAKEOVER HADR ON DATABASE <DB> (BY FORCE pour le failover). Lectures sur standby via DB2_HADR_ROS (limitations).
MySQL / MariaDB	InnoDB Cluster (Group Replication + MySQL Router) ; Galera (MariaDB)	Réplication Async/semi-sync, basée sur GTID	SHOW REPLICA STATUS (MySQL 8.0.22+ ; MariaDB 10.5.1+ accepte REPLICA comme synonyme de SLAVE ; versions plus anciennes : SHOW SLAVE STATUS). Surveillez le lag de réplication et les GTID errants ; Galera nécessite un quorum de composant primaire (3 nœuds ou un arbitre).

Règles de conception : définir RPO/RTO par application avant de choisir synchrone/asynchrone ; test DR au moins une fois par an avec résultats documentés (DORA exige des tests de continuité ICT pour les entités financières) ; les clients doivent se reconnecter de manière transparente (chaînes de connexion avec plusieurs hôtes/écouteur/SCAN, logique de nouvelle tentative) ; surveiller le lag et alerter ; protection anti-split-brain (quorum, fencing, observer/witness sur un troisième site).

5. Sauvegarde, restauration, PITR

Moteur	Complète / incrémentielle	PITR	Valider
Oracle (RMAN)	BACKUP DATABASE PLUS ARCHIVELOG; incrémentielle niveau 0/1 ; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;	Mode ARCHIVELOG requis. RUN { SET UNTIL TIME "TO_DATE('2026-10-01 12:00','YYYY-MM-DD HH24:MI')"; RESTORE DATABASE; RECOVER DATABASE; } puis ALTER DATABASE OPEN RESETLOGS;	RESTORE DATABASE VALIDATE;, CROSSCHECK BACKUP;, LIST BACKUP SUMMARY;, REPORT NEED BACKUP;, DELETE OBSOLETE;
PostgreSQL	pg_basebackup -D <dir> -Ft -z -X stream -P ; pgBackRest --type=full / diff / incr backup ; Barman. pg_dump est logique seulement (pas de PITR)	Archivage WAL (archive_mode, archive_command) ; restaurer base + restore_command + recovery_target_time + recovery.signal (PG12+). pgBackRest : pgbackrest --stanza=<s> --type=time "--target=2026-10-01 12:00:00+02" restore	pgbackrest --stanza=<s> check, pgbackrest --stanza=<s> info ; test de restauration réelle périodique
SQL Server	Modèle de récupération FULL ; BACKUP DATABASE [<db>] TO DISK = N'<path>' WITH CHECKSUM, COMPRESSION; différentiel ; BACKUP LOG	Restaurer complet WITH NORECOVERY, restaurer les différentiels WITH NORECOVERY dans l'ordre, puis les logs de transaction jusqu'à STOPAT = '<timestamp>' ; terminer par RESTORE DATABASE [<db>] WITH RECOVERY;. Vérifier msdb.dbo.backupset et RESTORE VERIFYONLY.	RESTORE VERIFYONLY FROM DISK = N'<path>';, DBCC CHECKDB et DBCC CHECKCATALOG après restauration
Db2 LUW	BACKUP DATABASE <DB> TO <dir> COMPRESS EXCLUDE LOGS WITHOUT PROMPTING; ; sauvegardes incrémentielles activées via UPDATE DB CFG FOR <DB> USING TRACKMOD YES;	Base restaurée en mode rollforward avec ROLLFORWARD DATABASE <DB> TO <timestamp> AND STOP;. SET LOGARCHMETH1 pour l'archivage des logs.	RESTORE DATABASE <DB> FROM <dir> WITHOUT PROMPTING; ; valider avec DB2 GET SNAPSHOT FOR DATABASE ON <DB>; et db2ckbkp
MySQL / MariaDB	mysqldump avec --single-transaction et --routines --triggers --events --hex-blob (logique) ; mysqlpump parallèle (logique) ; xtrabackup --backup --target-dir=<dir> par Percona (physique, binaire, ou incrémentiel). Sauvegardes logiques plus lentes sur les gros ensembles de données.	Nécessite binlog (log_bin, server-id). mysqlbinlog pour lire les binlogs dans le SQL. xtrabackup --prepare --target-dir=<dir> puis restauration. Restauration mysqldump : mysql -u <u> -p <db> < dump.sql	mysqlcheck -u <u> -p --all-databases ; pour xtrabackup : xtrabackup --prepare --target-dir=<dir>

PITR - règles générales

• Testez la restauration à partir de zéro au moins annuellement (idéalement semestriellement) ; documentez-la dans une runbook.
• Définissez un emplacement de sauvegarde distinct du stockage de données (site différent, nuage, compartiment d'objet).
• Surveillez l'espace de log de transaction (archivage, rétention) – une sauvegarde n'est pas une sauvegarde si les logs sont perdus.
• Pour les migrations (Oracle -> PostgreSQL, etc.), après atterrissage des données, validez les totaux de contrôle, le nombre de lignes, et exécutez les scripts de tests fonctionnels avant d'ouvrir l'accès utilisateur ; PITR n'est pas une solution de migration en soi (Oracle : outils GoldenGate / ORA2PG / Ora2Pg).

6. Sécurité, RBAC, audit, RGPD

Oracle

• Rôles par défaut : DBA, CONNECT, RESOURCE (obsolète) ; AUDIT_ADMIN et AUDIT_VIEWER (12c+) ; PDB_DBA dans les bases de données enfichables.
• Audit unifié (Oracle 12c+) : AUDIT POLICY <pol> BY <user> WHENEVER SUCCESSFUL; ; SELECT * FROM UNIFIED_AUDIT_TRAIL;.
• V$SESSION/V$SQL pour les actions en cours ; DBA_SOURCE ne peut être le seul contrôle d'accès – utilisez VPD ou les listes d'accès aux objets.
• Chiffrement au repos : Transparent Data Encryption (TDE) – nécessite Oracle Advanced Security (licencié en supplément).
• Validation RGPD : vérifiez les données personnelles (numéros de sécurité sociale, etc.) dans les tables, les schémas, les synonymes, et les vues ; pour les tests, anonymisez ou masquez (Data Masking Pack - supplémentaire).

PostgreSQL

• pg_hba.conf contrôle l'authentification (md5/scram-sha-256/cert/ldap) ; ne pas omettre une règle de refus à la fin.
• Privilèges : GRANT, REVOKE ; créer des rôles pour les applications, pas de connexion directe postgres.
• SSL : ssl = on et certificats ; sslmode=verify-full du côté client.
• Audit : pgaudit (extension), log_statement = 'all' (à des fins d'audit, testez l'impact).
• Chiffrement au repos : pgcrypto (chiffrement au niveau colonne, lent, revoir le schéma) ; TDE natif non disponible (pg_tde ou chiffrement au niveau fichier).

SQL Server

• Authentification : Windows (Kerberos/NTLM) ou mode mixte ; Active Directory (Azure AD) pour les instances managées et Azure SQL.
• Rôles : sysadmin, serveradmin, securityadmin ; rôles de base de données (db_owner, db_datareader, etc.) ; rôles de base de données personnalisés.
• Audit : SERVER AUDIT, DATABASE AUDIT SPECIFICATION ; SQL Server Audit ou Extended Events.
• Always Encrypted : chiffrement au niveau colonne, les clés ne sont pas exposées au serveur (nécessite SQL Server 2016+ ou Azure SQL).
• Dynamic Data Masking (masquage au niveau colonne pour les utilisateurs non privilégiés ; ne remplace pas les autorisations) ; Row-Level Security.

Db2 LUW

• Authentification : système d'exploitation (PAM, LDAP) ; SRVCON pour les connexions locales ; AUTHENTICATION = SERVER dans dbm cfg.
• Autorités : SYSADM, DBADM, SECADM ; privilèges (CONTROL sur table, EXECUTE sur routine, etc.). GRANT SECADM ON DATABASE TO USER <u>; ; rôles (Db2 9.7+).
• Audit : db2audit (surveiller VALIDATE, OBJMAINT, CHECK, etc.) ; AUDIT ARCHIVE PATH.
• LBAC (Label-Based Access Control) : contrôle d'accès au niveau ligne/colonne basé sur des étiquettes ; nécessite SECADM pour la configuration.
• Chiffrement : TDE pour tablespaces (via ENCRYPT dans CREATE TABLESPACE) ; chiffrement au niveau fichier/native storage encryption ; ENC_LIB pour la gestion des clés.

Règles générales (tous les moteurs) :

• Ne connectez jamais votre application en tant que propriétaire de schéma (DBA, postgres, sa, db2inst1, root) – créez un rôle avec les privilèges minimaux nécessaires (lecture/écriture sur des tables/vues spécifiques, exécution de procédures stockées).
• Validez les politiques de mots de passe : longueur minimale, complexité, rotation, réutilisation ; utilisez vault / secret store pour la gestion des credentials.
• Activez l'audit pour les accès aux données sensibles (lecture de colonnes avec PII, exportations, tentatives échouées).
• Testez les procédures de révocation : un utilisateur désactivé ne doit pas pouvoir se reconnecter.
• RGPD : documentez où les données personnelles résident (tables, colonnes, fichiers), établissez un registre des traitements, mettez en œuvre un droit à l'effacement (DELETE/UPDATE, mais aussi des contraintes d'intégrité référentielle / logs d'audit).

7. Pièges de migration Oracle vers PostgreSQL

Problèmes courants

• Séquences : Oracle les attache aux tables (DEFAULT <tab>_seq.NEXTVAL), PostgreSQL les utilise indépendamment (SERIAL/IDENTITY) ; après migration, les séquences doivent être réinitialisées au MAX(id) + 1 (SELECT setval('<tab>_id_seq', max(id)) FROM <tab>; ou en utilisant pg_restore avec -1 / --single-transaction).
• Synonymes : Oracle en a (privés et publiques), PostgreSQL n'en a pas – objet public vs schéma public, ou utiliser les vues ou les search_path.
• PL/SQL -> plpgsql : manque IN OUT (les paramètres OUT sont retournés comme résultats de fonction, pas comme paramètres modifiables ; utiliser des procédures à la place), SYS_REFCURSOR -> REFCURSOR/CURSOR, les tables imbriquées, les varrays et les tables d'indexation sont remplacés par des tableaux ; les packages Oracle n'ont pas d'équivalent en PostgreSQL (le schéma est l'espace de noms ; les fonctions/procédures sont des objets de premier niveau).
• Types de données : VARCHAR2 -> VARCHAR/TEXT ; NUMBER -> NUMERIC/INTEGER/BIGINT/REAL ; DATE (Oracle = date+heure) -> TIMESTAMP (PostgreSQL a DATE sans heure). CLOB/BLOB -> TEXT/BYTEA (ou BLOB via l'extension lo). SDO_GEOMETRY -> PostGIS.
• Index : Oracle peut ignorer un index sur une fonction sans utiliser la syntaxe d'index fonctionnel ; PostgreSQL nécessite CREATE INDEX ON tab (UPPER(col)) pour les recherches insensibles à la casse. Index bitmap seulement dans pg_bitmap.
• Verrous : Oracle utilise des verrous de ligne (pas d'escalade), PostgreSQL utilise une table de verrous en mémoire – le max_locks_per_transaction par défaut (64) peut être insuffisant lors de migrations en masse (relancez le serveur).
• NULLs et index : Oracle (B-tree inclut les NULLs sans les indexer dans UNIQUE), PostgreSQL les indexe – UNIQUE n'empêche pas les NULLs en double.
• Conformité ACID : Oracle lit sans attendre ; PostgreSQL peut avoir des verrous de sérialisation ; SERIALIZABLE dans PostgreSQL nécessite REPEATABLE READ comme niveau inférieur.
• Mots-clés réservés : plus stricts dans PostgreSQL – échappez les noms de colonnes.
• Fonctions système : SYSDATE -> CURRENT_TIMESTAMP/NOW(), ROWNUM -> ROW_NUMBER() OVER () ou LIMIT/OFFSET, NVL -> COALESCE, DECODE -> CASE/COALESCE, CONNECT BY -> WITH RECURSIVE.

Stratégie

• Utilisez ora2pg (audit, schéma, données), Ora2Pg ou pgLoader pour l'extraction ; testez sur un sous-ensemble.
• Après migration, vérifiez : les vues (\(d+v <view>), les fonctions (\ <fn>), les contraintes, les triggers, les index.
• Comparez les totaux de contrôle (lorsque cela est possible avec les types de données) et exécutez les tests fonctionnels.
• Testez PITR après la migration.

8. Révision de script de release – checklist de bonnes pratiques

Sécurité et conformité

• Aucun mot de passe en clair, secret dur ou informations d'identification dans le script ? Sinon, utiliser SECRETS / variables d'environnement / vault / credential store.
• Privilèges minimaux : le script s'exécute-t-il avec le rôle DB le plus bas qui a les autorisations nécessaires ? Pas de GRANT ALL.
• Aucune injection SQL possible ? Utiliser des instructions préparées / paramètres liés.
• Vérifier les audits / logs si un masquage de données ou des contrôles d'accès sont modifiés.
• Si RGPD ou données personnelles : WHERE inclut-il une clause de filtrage pour les colonnes personnelles ? Aucune fuite d'ID via des logs ou des erreurs ?

Performance et verrouillage

• Chaque DDL a-t-il un délai d'attente ? (lock_timeout/DDL_LOCK_TIMEOUT/LOCK_TIMEOUT/lock_wait_timeout).
• Les grands DML sont-ils divisés en lots (par exemple, lots de 1000-10000 avec LIMIT + OFFSET ou pagination par clé) ? Sinon, risque d'escalade de verrou / saturation du log de transactions / longs verrous.
• Le script s'exécute-t-il pendant les heures creuses planifiées ou la fenêtre de maintenance ?
• Aucune modification d'index ou de table qui provoque une dégradation des performances pour les requêtes en cours ? (Envisager CREATE INDEX CONCURRENTLY/ONLINE, ALTER TABLE ... ONLINE, pg_repack / pt-online-schema-change).
• Si nouveau index : vérifier EXPLAIN sur les requêtes existantes – pas de plan d'exécution plus lent.
• Si DROP COLUMN/ALTER COLUMN : vérifier les vues, fonctions et applications en aval qui s'y réfèrent.
• Aucune instruction DDL qui ne soit pas entourée de transactions (si le moteur le supporte) ? Sinon, encapsuler le script entier dans une transaction avec rollback en cas d'erreur.

Exactitude et intégrité

• Toutes les contraintes (PK, FK, UNIQUE, CHECK, NOT NULL) sont-elles appliquées après la mise à jour des données ? Si vous insérez d'abord, validez que les contraintes ne sont pas violées.
• Les clés étrangères ont-elles un index ? Si non, les créations/détections de verrous parents provoqueront des verrous TM dans Oracle, une analyse complète dans d'autres moteurs.
• Les scripts de migration de données incluent-ils un commit après chaque lot ? (Mais pas à l'intérieur d'une boucle de curseur – voir la section Oracle).
• Les transactions longues déclenchent-elles le vidage des logs de transactions ? Vérifier la taille des logs et le temps de commit.
• Si MERGE/REPLACE/ON CONFLICT : tester avec les deux cas (insertion et mise à jour) sur les données réelles.
• Valider que les vues sélectionnent les colonnes dans le bon ordre, en faisant correspondre les applications en aval.

Surveillance et alerte

• Le script crée-t-il une entrée dans une table de changement/suivi des versions de la base de données ? (Chaque changement doit être journalisé).
• Existe-t-il une attente + une alerte en cas d'échec (Verify a changé, sans réponse de la base lors de l'échec) ?
• Les métriques de performance (temps d'exécution, taille des logs, espace DB utilisé) sont-elles capturées avant et après la release ?

Rollback et validation

• Existe-t-il un script de rollback pour le changement (c'est-à-dire inverser les instructions SQL dans l'ordre inverse) ?
• Les données sont-elles sauvegardées avant le changement ? (Si DDL/DDL-suppression, sauvegarde de la table entière).
• Existe-t-il un test de validation après le script (vérification de l'intégrité des données, comptage des lignes, vérification de la construction de l'index) ?
• Planifier deux jeux de tests : pré-production (mêmes données) et une révision manuelle par un DBA senior.

Spécifique à PostgreSQL

• CREATE INDEX CONCURRENTLY n'est pas transactionnel – ne pas encapsuler dans une transaction.
• Les ALTER TABLE ... ADD COLUMN ... DEFAULT <volatile> réécrivent-ils la table ? (PostgreSQL 11+ : DEFAULT non volatyle est gratuit ; les valeurs volatiles (e.g. random()) le sont).
• REINDEX n'est pas transactionnel – ne pas encapsuler dans une transaction.
• VACUUM n'est pas transactionnel – ne pas encapsuler dans une transaction.
• Les migrations de séquence : ALTER SEQUENCE ... RESTART WITH <n>; / setval('<seq>', <n>);.

Spécifique à SQL Server

• SET XACT_ABORT ON activé pour interrompre les transactions sur erreur ?
• SET NOCOUNT ON pour réduire le trafic réseau.
• SET ARITHABORT ON (nécessaire pour les index vus avec des colonnes calculées).
• ALTER TABLE ... WITH (ONLINE = ON) si l'édition et la version le supportent (Enterprise Edition pour la plupart) ?
• Vérifier que les GO batch separators sont à la bonne place (uniquement dans SSMS/sqlcmd, pas dans les drivers).

9. API REST – Design et gestion des bases de données

Cette section s'applique aux API qui lisent/écrivent dans la base de données et est destinée à être révisée parallèlement aux scripts de release.

• Paging : les API qui renvoient des listes doivent utiliser une pagination basée sur un curseur (pas OFFSET pour les grands ensembles) – WHERE id > ? LIMIT 100.
• Transactions : une requête API ne doit pas contenir plus d'une transaction sauf si elle est explicitement conçue (par exemple, orchestration saga).
• Timeouts : configurer les timeouts de connexion DB et de requête au niveau de l'API (pool de connexions).
• Pool de connexions : dimensionné correctement (max connections DB / application / instance) ; éviter l'épuisement des connexions.
• Cache : implémenter un cache pour les données rarement modifiées (lookups, données de référence) ; définir un TTL.
• Validation : valider les entrées du côté API avant de les envoyer à la DB (format, longueur, valeurs autorisées) ; jamais de SQL dynamique.
• Gestion des erreurs : renvoyer des messages d'erreur cohérents (400 Bad Request, 409 Conflict, 500 Internal Server Error), sans exposer les détails de la DB.
• Rate limiting : prévenir les abus avec un throttling par IP / token API.
• Chiffrement : HTTPS pour toutes les communications ; les données sensibles (PII, jetons) doivent être chiffrées au repos.
• Scaling : l'API doit être sans état pour permettre un scale horizontal ; les sessions DB doivent être éphémères (pas de sessions persistantes).
• Monitoring : enregistrer les métriques API (temps de réponse, taux d'erreur, débit) et corréler avec les métriques DB (nombre de connexions, temps de requête).
• Idempotence : les opérations de mutation (POST, PUT, DELETE) doivent être idempotentes ou fournir une clé d'idempotence pour éviter les écritures en double.
• Versioning : versionner l'API (via URL ou en-tête) pour permettre l'évolution du schéma sans casser les clients.

10. Files d'attente et streaming de messages

Cette section couvre les systèmes de files d'attente et de streaming de messages utilisés dans les architectures de bases de données (déclencheurs, CDC, ingestion de flux, notifications asynchrones).

Moteur de file d'attente	Type	Cas d'utilisation	Notes
Notification de base de données	Oracle AQ / PostgreSQL LISTEN/NOTIFY / SQL Server Service Broker	Déclencher une application après un changement (msg in-DB)	LISTEN/NOTIFY est léger mais non persistant ; AQ et Service Broker sont persistants ; mais la latence est de l'ordre de la milliseconde.
Kafka Debezium (CDC)	Capture des changements de données en streaming	Alimenter les entrepôts de données, les caches, les autres bases, les lacs de données	Déverrouille les lectures transactionnelles ; nécessite de surveiller le lag de réplication et les fichiers de log.
Redis	File d'attente en mémoire, pub/sub	Cache, mise en cache des sessions, rate limiting	Pas de persistance (sauf AOF/RDB) ; pas de transactions multi-enregistrements ni de requêtes.
RabbitMQ / Pulsar / SQS / NATS	File d'attente / streaming	Découplage des microservices, ordonnancement des tâches, ingestion d'événements	Choisir selon la persistance, le partitionnement, qos, dead letter, etc.

11. Sauvegardes et bases de données : informations croisées

• Sauvegarde et restauration : appliquer la configuration de sauvegarde à tous les nœuds (primaire et réplicas) ; tester la restauration au moins une fois par an.
• Surveillance : surveiller les marqueurs de sauvegarde (dernière sauvegarde réussie, taille, durée) ; configurer une alerte si une sauvegarde échoue.
• Log shipping : si vous utilisez le log shipping (base de données de veille), assurez-vous que le log shipping ne peut pas devenir une sauvegarde unique (test de restauration).
• Cloud : si vous stockez des sauvegardes dans le cloud, protégez les credentials de stockage ; activez le versioning / cycle de vie des objets.
• PITR : documentez le RPO (perte de données maximale) et le RTO (temps de récupération cible) pour chaque système ; assurez-vous que l'archivage des logs est dimensionné pour prendre en charge la fenêtre PITR.

12. Observabilité et métriques

Catégorie	Métriques clés	Alertes typiques
Temps de réponse	Temps d'exécution des requêtes, temps d'attente, temps d'analyse	Latence > seuil (ex: >1s pour une requête simple)
Débit	Appels/s, transactions/s, connexions/s, taille du pool de connexions	Pool de connexions maximisé, débit en baisse
Erreurs	Taux d'erreur d'exécution des requêtes, timeouts de connexion, deadlocks	Taux d'erreur > seuil, deadlocks > 0
Ressources	CPU, mémoire, E/S disque, réseau, espace de stockage	Espace disque < 10%, CPU > 80%, mémoire insuffisante
HA/DR	Lag de réplication, état du basculement, état du quorum, état de la sauvegarde	Lag de réplication > seuil, pas de sauvegarde dans les dernières 24h
Sécurité	Tentatives de connexion échouées, connexions depuis des IP non autorisées	Taux de connexions échouées > seuil

Remarque : les seuils dépendent du profil de charge de l'application ; définissez les alertes en fonction de l'analyse des données historiques.

13. Reporting et tableaux de bord

• Tableaux de bord de performance : surveiller le temps d'exécution des requêtes, les attentes, les IOPS, le CPU, l'utilisation mémoire.
• Tableaux de bord de capacité : prévoir la croissance (stockage, CPU, mémoire, connexions).
• Tableaux de bord de sécurité : audit des connexions, modèles d'accès aux données, violations de politique.
• Tableaux de bord de conformité : audits RGPD/PCI-DSS, rapports de masquage des données, échecs de validation.
• Tableaux de bord de release : changements de schéma, scripts exécutés, leurs durées, résultats (succès/échec).

Outils : Grafana (Prometheus/InfluxDB), Datadog, New Relic, outils natifs Cloud (CloudWatch, Azure Monitor, GCP Operations Suite), outils spécifiques fournisseur (Enterprise Manager, pgAdmin, SSMS, Control Center, MySQL Workbench).

14. Règles générales

• Sauvegarde et restauration : testez-la. Périodiquement. À partir de zéro. Documentez-la dans un runbook.
• Migration : utilisez des outils validés (ora2pg, pgLoader, SSMA, AWS DMS, etc.) ; testez sur un sous-ensemble en pré-prod.
• CLI : pour tous les moteurs, l'interface en ligne de commande doit être utilisée avec des paramètres, pas d'invite ; en production, utilisez la force brute (-f, -q, --no-interactive).
• Logging : activez la journalisation de manière cohérente sur tous les serveurs (niveau INFO, rotation, rétention).
• Documentation : maintenez un wiki / base de connaissances partagée ; toute commande doit être commentée dans le runbook.
• Architecture : les mises à jour sont validées via un processus de révision ; les modifications sont faites via des scripts versionnés (Git) et déployées avec un outil CI/CD (Jenkins, GitLab CI, Azure DevOps).
• Revue : chaque changement doit être examiné par un pair DBA ; la checklist de cette section doit être remplie pour chaque release.
• Continuité : documentez les procédures de basculement, de restauration et de reprise après sinistre dans des runbooks ; testez-les au moins une fois par an.