🧠 Storage Systems — Chapitre 37 : Tuning base de données et stockage

Chapitre dense consacré au tuning stockage des bases de données : PostgreSQL, MySQL/MariaDB, Oracle, SQL Server, séparation des volumes data/logs/temp/backup, tests fio/iostat/blktrace/pgbench/sysbench, WAL/redo, checkpoints, datafiles, tempdb/TEMP, buffer cache, fsync, direct I/O, filesystems, RAID/stripe, NVMe/SSD, SAN/NAS/cloud disks, replication, backup/restore, observabilité, benchmarks réalistes, VM/Kubernetes, méthode de tuning et checklist production.

PostgreSQLMySQL / MariaDBOracleSQL ServerData / logs / temppgbench / sysbench

37.1

PostgreSQL

WAL, tablespaces, checkpoint, fsync, random_page_cost, effective_io_concurrency, shared_buffers et autovacuum.

PostgreSQLWALCheckpoint

37.2

MySQL / MariaDB

InnoDB buffer pool, redo logs, doublewrite, flush method, binlogs, temporary tables et I/O capacity.

MySQLMariaDBInnoDB

37.3

Oracle

ASM, redo logs, datafiles, FRA, DBWR/LGWR, direct I/O, RMAN, Data Guard et AWR/ASH.

OracleASMRedo

37.4

SQL Server

Data files, log files, tempdb, instant file initialization, MAXDOP, wait stats, storage latency et backup throughput.

SQL ServertempdbWaits

37.5

Séparation des volumes

Data, logs, temp, backup : isoler les profils I/O pour réduire contention, latence p99 et blast radius.

DataLogsTempBackup

37.6

Tests

fio, iostat, blktrace, pgbench, sysbench, HammerDB, SLOB, AWR, PerfMon et scénarios reproductibles.

fiopgbenchsysbench

37.7

WAL / redo / transaction logs

Journaux transactionnels : fsync, group commit, flush latency, sync replication, archive logs et PITR.

WALRedofsync

37.8

Checkpoints et dirty pages

Checkpoint storm, writeback, dirty ratio, DB checkpoint tuning, page flushing et impact sur latence.

CheckpointDirty pagesFlush

37.9

Datafiles et tablespaces

Placement des données : tablespaces, filegroups, ASM disk groups, partitioning, hot data/cold data et tiering.

TablespacesFilegroupsASM

37.10

Temp / scratch space

tempdb, pg_temp, MySQL temp, Oracle TEMP : tri, hash, index build, spills et contention metadata.

tempdbTEMPSpills

37.11

Buffer pool et cache

Cache DB vs page cache OS : shared_buffers, buffer pool, SGA, buffer cache hit, warm-up et double caching.

Buffer poolSGACache

37.12

fsync et durabilité

Durabilité ACID : fsync, synchronous_commit, innodb_flush_log_at_trx_commit, delayed durability et risques.

fsyncACIDDurability

37.13

Direct I/O et page cache

O_DIRECT, innodb_flush_method, filesystem cache, buffered I/O, direct path reads et double buffering.

Direct I/OO_DIRECTCache

37.14

Filesystem pour bases

XFS, ext4, ASM raw-like, ZFS, mount options, barriers, noatime, reflink, logbufs et discard.

XFSext4ASMZFS

37.15

RAID, stripe et alignment

Stripe size, chunk, ASM allocation unit, LVM alignment, RAID penalty, write amplification et rebuild reserve.

RAIDStripeAlignment

37.16

NVMe / SSD pour bases

Latency p99, queue depth, endurance, DWPD, PLP, thermal throttling, TRIM, firmware et overprovisioning.

NVMeSSDDWPD

37.17

SAN, NAS et cloud disks

FC/iSCSI/NFS/SMB/EBS/Azure Disk/GCP PD : choisir selon latence, snapshots, HA, IOPS et throughput caps.

SANNASCloud

37.18

Réplication et stockage

Streaming replication, Data Guard, Always On, binlog replication, sync/async, lag, write latency et quorum.

ReplicationSyncLag

37.19

Backup / restore performance

RMAN, pgBackRest, mysqldump/xtrabackup, SQL backup, parallelism, compression, object storage et restore drills.

BackupRestoreParallelism

37.20

Observabilité DB + storage

Wait events, iostat, AWR, pg_stat_io, performance_schema, DMVs, eBPF et corrélation applicative.

AWRpg_stat_ioDMV

37.21

Benchmarks réalistes

pgbench, sysbench, HammerDB, SLOB, YCSB : profils OLTP, read-only, write-heavy et durée suffisante.

BenchmarkOLTPHammerDB

37.22

Bases en VM / Kubernetes

Datastore, vDisk, PVC, CSI, snapshots, anti-affinity, CPU steal, noisy neighbors et storageclass.

VMK8sPVC

37.23

Méthode de tuning DB storage

Baseline, hypothèse, changement unique, mesure p99, test transactionnel, rollback et documentation.

MethodBaselineRollback

37.24

Checklist tuning DB storage

GO/NO-GO : logs séparés, restore testé, p99, fsync compris, checkpoints maîtrisés, volumes isolés, monitoring.

ChecklistGO/NO-GOp99

37.1 PostgreSQL

Définition opérationnelle

WAL, tablespaces, checkpoint, fsync, random_page_cost, effective_io_concurrency, shared_buffers et autovacuum.

Point clé : une base de données ne fait pas seulement des I/O : elle garantit l’ACID. Le tuning stockage doit respecter les logs transactionnels, checkpoints, fsync, backups, PITR et cohérence applicative.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.2 MySQL / MariaDB

Définition opérationnelle

InnoDB buffer pool, redo logs, doublewrite, flush method, binlogs, temporary tables et I/O capacity.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.3 Oracle

Définition opérationnelle

ASM, redo logs, datafiles, FRA, DBWR/LGWR, direct I/O, RMAN, Data Guard et AWR/ASH.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.4 SQL Server

Définition opérationnelle

Data files, log files, tempdb, instant file initialization, MAXDOP, wait stats, storage latency et backup throughput.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.5 Séparation des volumes

Définition opérationnelle

Data, logs, temp, backup : isoler les profils I/O pour réduire contention, latence p99 et blast radius.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.6 Tests

Définition opérationnelle

fio, iostat, blktrace, pgbench, sysbench, HammerDB, SLOB, AWR, PerfMon et scénarios reproductibles.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.7 WAL / redo / transaction logs

Définition opérationnelle

Journaux transactionnels : fsync, group commit, flush latency, sync replication, archive logs et PITR.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.8 Checkpoints et dirty pages

Définition opérationnelle

Checkpoint storm, writeback, dirty ratio, DB checkpoint tuning, page flushing et impact sur latence.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.9 Datafiles et tablespaces

Définition opérationnelle

Placement des données : tablespaces, filegroups, ASM disk groups, partitioning, hot data/cold data et tiering.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.10 Temp / scratch space

Définition opérationnelle

tempdb, pg_temp, MySQL temp, Oracle TEMP : tri, hash, index build, spills et contention metadata.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.11 Buffer pool et cache

Définition opérationnelle

Cache DB vs page cache OS : shared_buffers, buffer pool, SGA, buffer cache hit, warm-up et double caching.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.12 fsync et durabilité

Définition opérationnelle

Durabilité ACID : fsync, synchronous_commit, innodb_flush_log_at_trx_commit, delayed durability et risques.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.13 Direct I/O et page cache

Définition opérationnelle

O_DIRECT, innodb_flush_method, filesystem cache, buffered I/O, direct path reads et double buffering.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.14 Filesystem pour bases

Définition opérationnelle

XFS, ext4, ASM raw-like, ZFS, mount options, barriers, noatime, reflink, logbufs et discard.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.15 RAID, stripe et alignment

Définition opérationnelle

Stripe size, chunk, ASM allocation unit, LVM alignment, RAID penalty, write amplification et rebuild reserve.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.16 NVMe / SSD pour bases

Définition opérationnelle

Latency p99, queue depth, endurance, DWPD, PLP, thermal throttling, TRIM, firmware et overprovisioning.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.17 SAN, NAS et cloud disks

Définition opérationnelle

FC/iSCSI/NFS/SMB/EBS/Azure Disk/GCP PD : choisir selon latence, snapshots, HA, IOPS et throughput caps.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.18 Réplication et stockage

Définition opérationnelle

Streaming replication, Data Guard, Always On, binlog replication, sync/async, lag, write latency et quorum.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.19 Backup / restore performance

Définition opérationnelle

RMAN, pgBackRest, mysqldump/xtrabackup, SQL backup, parallelism, compression, object storage et restore drills.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.20 Observabilité DB + storage

Définition opérationnelle

Wait events, iostat, AWR, pg_stat_io, performance_schema, DMVs, eBPF et corrélation applicative.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.21 Benchmarks réalistes

Définition opérationnelle

pgbench, sysbench, HammerDB, SLOB, YCSB : profils OLTP, read-only, write-heavy et durée suffisante.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.22 Bases en VM / Kubernetes

Définition opérationnelle

Datastore, vDisk, PVC, CSI, snapshots, anti-affinity, CPU steal, noisy neighbors et storageclass.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.23 Méthode de tuning DB storage

Définition opérationnelle

Baseline, hypothèse, changement unique, mesure p99, test transactionnel, rollback et documentation.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.

37.24 Checklist tuning DB storage

Définition opérationnelle

GO/NO-GO : logs séparés, restore testé, p99, fsync compris, checkpoints maîtrisés, volumes isolés, monitoring.

Chaîne I/O database

SQL transaction→Buffer cache→WAL / redo fsync→Datafile write→Checkpoint→Replication / backup

Règle clé : log latency conditionne souvent le commit ; datafile throughput conditionne scans/checkpoints ; temp conditionne tris/hash/spills.

Composants à analyser

Composant	Rôle / explication
Transaction path	Client, SQL executor, buffer cache, WAL/redo, fsync, datafile, checkpoint, replication, ACK.
Critical files	Datafiles, WAL/redo logs, temp, undo, archive logs, control files, backups, snapshots.
Storage profile	Random read, random write, sequential log write, temp spills, checkpoint bursts, backup streaming.
Durability knobs	fsync, sync commit, flush method, doublewrite, synchronous replication, delayed durability.
Observation	Wait events DB, iostat, fio, pgbench/sysbench, AWR/ASH, DMVs, performance_schema, logs.
Safety	Backup, PITR, restore test, rollback config, staged rollout, change window and business validation.

Cas d’usage

Réduire latence transactionnelle p99
Séparer data/logs/temp/backups pour éviter contention
Dimensionner SAN/NVMe/cloud disks pour une base critique
Diagnostiquer checkpoint storms ou redo/WAL latency
Valider migration database vers VM, Kubernetes ou cloud
Tester restore et PITR avec un profil réaliste

DB wait events→Storage metrics→Hypothesis→One change→Benchmark→Restore test

Apports du tuning

Relie métriques DB et métriques stockage
Évite de tuner uniquement le système Linux sans comprendre l’ACID
Permet distinguer data reads, log writes, temp spills et backups
Améliore performance sans sacrifier la durabilité
Fournit une preuve POC exploitable par DBA, infra et métier

Risques / limites

Désactiver fsync/durabilité pour gagner artificiellement
Mettre logs et data sur même volume saturé
Benchmark cache-only sans working set réaliste
Ignorer tempdb/temp et checkpoints
Changer plusieurs paramètres à la fois sans rollback

Matrice de décision DB storage tuning

Question	Décision à prendre
Quel moteur ?	PostgreSQL, MySQL/MariaDB, Oracle, SQL Server : chacun a ses logs, caches, checkpoints et outils de mesure.
Quel fichier est chaud ?	Data, WAL/redo/log, temp, undo, archive, backup. Les isoler si profils et SLA divergent fortement.
Quelle contrainte ACID ?	Ne pas sacrifier fsync, doublewrite, redo ou synchronous commit sans acceptation métier documentée.
Quelle mesure fiable ?	Wait events DB + iostat/fio + logs application + p95/p99 + throughput backup/restore.
Quel test représentatif ?	Working set > cache, durée suffisante, mix read/write réel, checkpoints, backups et replication lag inclus.
Quelle restauration ?	Backup, PITR, restore DB, validation cohérence, checksum, replay logs et test applicatif.

Règle pratique : logs transactionnels sur stockage faible latence et prévisible ; datafiles sur capacité/throughput ; temp sur espace rapide et isolé.

Runbook tuning database storage

Capturer baseline DB : wait events, slow queries, checkpoint logs, replication lag, backup duration.
Capturer baseline OS/storage : iostat, vmstat, sar, fio, multipath, filesystem, queue depth, p99.
Identifier le type d’I/O : WAL/redo fsync, random data reads, checkpoint writes, temp spills, backup sequential.
Appliquer un changement unique : volume separation, flush method, tablespace, temp placement, checkpoint setting, queue/scheduler.
Tester avec workload réaliste : pgbench, sysbench, HammerDB, replay, batch, restore, failover.
Valider ACID/PITR : crash test contrôlé, backup restore, logs replay, consistency check.
Documenter résultat, rollback, seuils monitoring et décision GO/NO-GO.

# Generic Linux + DB storage checks
iostat -x 1
vmstat 1
sar -d 1
pidstat -d 1
lsblk -o NAME,TYPE,SIZE,ROTA,SCHED,MOUNTPOINT
findmnt -no OPTIONS /var/lib/postgresql
fio --name=db-log --rw=write --bs=8k --iodepth=1 --numjobs=1 --size=4G --direct=1 --fsync=1 --runtime=120 --time_based --group_reporting
fio --name=db-data --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --size=20G --direct=1 --runtime=300 --time_based --group_reporting

# PostgreSQL examples
pgbench -i -s 100 benchdb
pgbench -c 32 -j 8 -T 300 benchdb
psql -c "select * from pg_stat_bgwriter;"
psql -c "select * from pg_stat_database where datname=current_database();"

# MySQL / MariaDB examples
sysbench oltp_read_write --mysql-db=test --tables=16 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-db=test --threads=32 --time=300 run
mysql -e "show engine innodb status\G"

# SQL Server / Oracle: correlate wait stats or AWR/ASH with OS/storage metrics.

NO-GO : désactivation fsync/durabilité non validée, absence de restore/PITR, benchmark sans checkpoints, ou décision basée uniquement sur fio sans métriques DB.