🟥 Oracle Database – Architecture, SQL/PLSQL & Administration

Le bastion du "Mission Critical"

On n'utilise pas Oracle pour un blog WordPress. On l'utilise quand l'arrêt du service coûte des millions par minute.

• Banque & Finance : Core Banking Systems. Gestion transactionnelle ultra-intensive (Millions de TPS).
• Telco : Facturation en temps réel (Call Detail Records).
• Industrie & Logistique : Supply Chain mondiale, ERPs (SAP tourne souvent sur Oracle).
• État / Défense : Gestion de l'identité, impôts, données classifiées.

                            Pourquoi migrer D'Oracle est difficile ?

                            1. Dépendance PL/SQL : Des millions de lignes de code métier sont souvent DANS la base (Logique stockée).
                            2. Complexité RAC : Remplacer un cluster RAC actif-actif par du Postgres nécessite de repenser toute la HA (Haute Dispo).
                            3. Risque : "Nobody gets fired for buying Oracle". Migrer comporte un risque opérationnel énorme.

Structure Physique

• Control Files (.ctl) : Le cerveau. Contient le nom de la DB, le timestamp, l'emplacement des fichiers, le SCN actuel. Sans lui, impossible de démarrer (MOUNT).
• Data Files (.dbf) : Les données réelles. Ils appartiennent à un Tablespace logique.
• Online Redo Logs (.log) : Le journal de bord. Écritures séquentielles circulaires. En cas de crash, on rejoue ces fichiers.
• SPFILE (Server Parameter File) : Fichier binaire de configuration (mémoire, paramètres).

Structure Logique

                            DATABASE
                            └── TABLESPACE (ex: USERS, SYSTEM, UNDO)
                            └── SEGMENT (ex: Table EMP, Index EMP_IDX)
                            └── EXTENT (Groupe contigu de blocs)
                            └── BLOCK (Unité I/O, ex: 8KB)

Tablespace SYSTEM : Dictionnaire de données (appartenant à SYS).
Tablespace UNDO : Stocke les images "avant modification" pour le Rollback et la lecture cohérente (MVCC).

Schéma (simplifié, mais fidèle au concept)

 +---------------------------+              +---------------------------+
                            |         Console UI         |              |    Notifications/ITSM      |
                            |  Dashboards / Reports      | ----       |  Email / Webhook / Ticket  |
                            +---------------------------+      |       +---------------------------+
                            ^                  Alerts
                            |                   |
                            |                   v
                            +---------------------------+   +---------------------------+
                            |      OMS (Management      |   |  Policies / Baselines     |
                            |       Service)            |---|  Rules / Incidents        |
                            +---------------------------+   +---------------------------+
                            |
                            | writes/reads
                            v
                            +---------------------------+
                            |  OEM Repository (DB)      |
                            |  Metrics / history / conf |
                            +---------------------------+
                            ^
                            | agent upload
                            +--------------+--------------+------------------------------+
                            |        Agents OEM sur les hôtes / cibles                   |
                            |  - DB targets (instance/CDB/PDB), listeners, ASM, host     |
                            +--------------+--------------+------------------------------+
                            |                              |
                            v                              v
                            +------------------+             +------------------+
                            | Oracle DB target |             | Host/OS target   |
                            +------------------+             +------------------+

Checklist déploiement (vue DBA)

Erreurs classiques (à éviter)

• Trop d’alertes → personne ne lit. Résultat : incident non détecté.
• Seuils statiques “au pif” → faux positifs / faux négatifs.
• Pas de runbook → OEM sonne… mais personne ne sait quoi faire.
• Repo OEM sous-dimensionné → console lente, historique inutilisable.

Dashboard “SRE/Prod” (signaux rapides)

Dashboard “DBA” (investigation)

Diagramme : “DB Time se décompose en…”

DB TIME = DB CPU + Wait Time
                            Wait Time ≈ IO waits + Concurrency waits + Commit/Redo waits + Others

                            Si DB CPU >> waits  → CPU bound (SQL/parse)
                            Si waits dominent   → chercher l’événement principal (IO/locks/log sync…)

Stratégie de seuils (baseline-first)

• Définir une période saine (baseline) : jours ouvrés / batch / pics.
• Seuils = écart à la baseline + seuils absolus (ex: FRA 90%).
• Différencier warning vs critical + délai (persistant X minutes).
• Chaque alerte doit avoir : owner, runbook, action.

Table d’alertes recommandées (production)

Diagramme : pipeline d’alerte “OEM → action”

Metric breach
                            |
                            v
                            Incident (OEM)  ---> auto-ticket (option)
                            |
                            +--> Notification (mail/webhook) --> on-call
                            |
                            +--> Runbook (lien) : "quoi regarder / quoi faire"
                            |
                            v
                            Investigation : AWR/ASH/SQL Monitor + logs
                            |
                            v
                            Fix (SQL / config / storage / app) + validation baseline

Anti-patterns (les pires)

Workflow “incident perf” (OEM-guided)

1) Symptôme : DB Time↑ / latence app↑ / sessions bloquées
                            2) OEM : ouvrir la cible DB → Performance home
                            3) Identifier :
                            - Top wait events (dominant)
                            - Top SQL (elapsed / CPU / IO)
                            - AAS & sessions actives
                            4) Basculer :
                            - ASH (qui attend quoi, SQL_ID, blocker)
                            - SQL Monitor (requête lourde)
                            - AWR report (période incident vs baseline)
                            5) Action :
                            - SQL tuning (plan/stats/index/rewrite)
                            - Concurrency (locks/app)
                            - Storage/IO (hot objects / path)
                            6) Validation : retour baseline + fermeture incident + postmortem

Table “symptôme → outil”

Diagramme : “Top wait” → hypothèses

Top Wait Event                    Hypothèses typiques
                            --------------------------------------------------------------
                            db file sequential read           index reads / IO latency
                            db file scattered read            full scans / stats/plan
                            log file sync                     commits fréquents / redo IO
                            enq: TX - row lock contention     locks applicatifs / transactions
                            library cache lock/pin            parsing / invalidations / shared pool
                            gc* (RAC)                         interconnect / hot blocks / skew

Check “SQL régression” (ultra utile)

Ce que tu automatises classiquement

Diagramme : OEM jobs → preuves (audit)

[Job OEM] --> [Exécution] --> [Résultat] --> [Evidence/Report]
                            |             |             |               |
                            |             |             +--> OK/FAIL     +--> PDF/HTML export / historique
                            |             +--> logs
                            +--> schedule + notifications

Conseil très prod

Capacity planning : ce que tu veux anticiper

Rapports utiles (et lisibles)

• Weekly health report : incidents, top alerts, top SQL, capacity delta.
• Monthly capacity : croissance, FRA, storage, tendances CPU/IO.
• Post-incident : timeline, métriques, root cause, action, prévention.

Diagramme : “reporting = preuve”

Mesure (avant) ---> Changement ---> Mesure (après) ---> Conclusion (ROI/risque)

Principes

• Comptes OEM : RBAC strict (DBA, viewer, auditor, ops).
• Agents : accès réseau minimal, segmentation.
• Audit : actions OEM tracées (qui a fait quoi, quand).
• Principe du moindre privilège sur les cibles DB (collecte vs action).

Modèle RBAC (exemple)

Diagramme : zones de confiance

[Admin Users] ---RBAC---> [OEM UI/OMS] ---agents---> [DB targets]
                            |                         |
                            |                         +--> Repository (metrics/history)
                            |
                            +--> Audit trail (who/when/what)

Mini runbook (template) — à coller dans tes tickets

1) Symptôme / impact / start time
                            2) OEM target : DB + instance + host
                            3) Graphs : DB Time, AAS, CPU, top waits
                            4) Top SQL : SQL_ID, module, user, plan changes
                            5) Hypothèse : (CPU/IO/locks/redo)
                            6) Action : (SQL fix / config / storage / app)
                            7) Validation : retour baseline + métrique OK
                            8) Postmortem : cause + prévention + seuils ajustés

Diagramme “MTTR” (ce qui fait gagner du temps)

MTTR ↓ = Alert (bon signal) + Runbook + Outil (AWR/ASH/SQL Mon) + Owner clair
                            MTTR ↑ = Bruit + Seuils au hasard + Pas de baseline + Pas d'ownership

Tablespace UNDO (Le Time Machine)

Stocke les "anciennes valeurs" avant modification. C'est vital pour :

1. Rollback : Annuler une transaction (ROLLBACK).
2. Read Consistency : Garantir que si je lance un SELECT à 10h00 qui dure 15min, je ne vois PAS les updates faits à 10h05 par quelqu'un d'autre.
3. Flashback Query : SELECT * FROM table AS OF TIMESTAMP (hier).

Erreur ORA-01555 (Snapshot too old) : Vous essayez de lire une vieille donnée qui a été écrasée dans l'UNDO (car trop petite rétention).

Tablespace TEMP (Le Brouillon)

Utilisé pour les opérations qui ne tiennent pas en mémoire RAM (PGA).

• Gros tris (ORDER BY, GROUP BY).
• Création d'index.
• Hash Joins massifs.
• Global Temporary Tables (GTT).

Si le TEMP est plein, la requête plante (ORA-01652: unable to extend temp segment).

Mauvaise Pratique (Row-by-Row)

                            -- Lent : 1 million de switchs
                            FOR rec IN (SELECT id FROM employees) LOOP
                            UPDATE employees SET s = s*1.1 
                            WHERE id = rec.id;
                            END LOOP;

Bonne Pratique (Bulk)

                            -- Rapide : 1 switch
                            DECLARE
                            TYPE t_id_list IS TABLE OF NUMBER;
                            v_ids t_id_list;
                            BEGIN
                            -- 1. Lire tout d'un coup
                            SELECT id BULK COLLECT INTO v_ids 
                            FROM employees;

                            -- 2. Écrire tout d'un coup
                            FORALL i IN 1..v_ids.COUNT
                            UPDATE employees SET s = s*1.1 
                            WHERE id = v_ids(i);
                            END;

Triggers

Code déclenché automatiquement sur INSERT/UPDATE/DELETE.

                            CREATE OR REPLACE TRIGGER trg_audit_emp
                            AFTER UPDATE OF salary ON employees
                            FOR EACH ROW
                            BEGIN
                            IF :NEW.salary > :OLD.salary * 1.5 THEN
                            INSERT INTO audit_log VALUES (
                            USER, SYSDATE, :OLD.salary, :NEW.salary
                            );
                            END IF;
                            END;
                            /

Attention : Les triggers ralentissent les DML, sont invisibles pour le développeur, et peuvent causer des "Mutating Table Errors" si mal codés.

DBMS_SCHEDULER (Le Cron Oracle)

Pour les traitements asynchrones ou récurrents.

                            BEGIN
                            DBMS_SCHEDULER.CREATE_JOB (
                            job_name        => 'JOB_PURGE_LOGS',
                            job_type        => 'PLSQL_BLOCK',
                            job_action      => 'BEGIN pkg_maint.purge; END;',
                            start_date      => SYSTIMESTAMP,
                            repeat_interval => 'FREQ=DAILY; BYHOUR=2',
                            enabled         => TRUE
                            );
                            END;
                            /

Partitioning (Option payante $$)

Découper une table géante en morceaux plus petits (physiquement indépendants).

• Range : Par date (Janvier, Février...).
• List : Par région (Nord, Sud...).
• Hash : Distribution aléatoire (pour la performance I/O).
• Interval : Range automatique (crée la partition mensuelle tout seul).

Partition Pruning : Le CBO est assez malin pour ne lire QUE la partition concernée (ex: WHERE date > '2024-01-01' ne lit pas 2023).

Parallel Query (PQ)

Utiliser plusieurs processus CPU pour une seule requête.

SELECT /*+ PARALLEL(t, 4) */ * FROM grosse_table t;

• Avantage : Divise le temps de réponse par N (idéalement).
• Risque : Peut tuer le serveur en consommant tout le CPU et les I/O. À réserver aux batchs de nuit ou Datawarehouse.

UNDO : La Machine à Remonter le Temps

Avant de modifier une donnée (ex: changer SALARY de 1000 à 2000), Oracle copie l'ancienne valeur (1000) dans un Segment UNDO.

À quoi ça sert ?

1. Rollback : Si je change d'avis, je remets le 1000.
2. Read Consistency : Si un collègue lance un SELECT long avant mon commit, Oracle utilise l'UNDO pour lui montrer le 1000 (il ne voit pas mon 2000 non validé).
3. Flashback Query : SELECT * FROM table AS OF TIMESTAMP (il y a 1h).

L'Erreur ORA-01555 (Snapshot too old)

C'est le cauchemar des développeurs sur les longues requêtes.

Scénario :
1. Vous lancez un gros rapport à 09h00 (durée 2h).
2. À 09h30, quelqu'un update massivement la table et commit.
3. Oracle stocke l'ancienne image dans l'Undo.
4. À 10h00, l'Undo est plein, Oracle écrase les vieilles images (Logique circulaire).
5. À 10h30, votre rapport arrive sur les lignes modifiées. Il cherche l'image de 09h00... elle n'existe plus !
=> CRASH : ORA-01555.

Solution : Augmenter UNDO_RETENTION ou la taille du Tablespace UNDO.

Réseau (sqlnet.ora)

Restreindre qui peut contacter le Listener.

                            # $ORACLE_HOME/network/admin/sqlnet.ora

                            # Whitelist IP
                            TCP.VALIDNODE_CHECKING = YES
                            TCP.INVITED_NODES = (127.0.0.1, 192.168.1.50) # App Server uniquement

                            # Chiffrement réseau natif (In-Transit)
                            SQLNET.ENCRYPTION_SERVER = REQUIRED
                            SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)

Comptes par défaut

• Changer les mots de passe de SYS et SYSTEM immédiatement.
• Verrouiller les comptes d'exemples : ALTER USER SCOTT ACCOUNT LOCK;
• Limiter l'accès OS au groupe dba (Linux).

Solutions

• HikariCP : Le standard Java actuel. Ultra-rapide.
• UCP (Oracle Universal Connection Pool) : Optimisé pour RAC (gère le "Fast Connection Failover" et le "Runtime Load Balancing"). Recommandé pour les gros clusters.

Statement Caching

Le driver garde les curseurs ouverts côté client. Évite le "Soft Parse" côté serveur.

                            # Config HikariCP
                            dataSource.prepStmtCacheSize=250
                            dataSource.prepStmtCacheSqlLimit=2048

SmartDB (The Old/Solid Way)

Philosophie : "La donnée est plus importante que l'appli".

• Logique métier dans des Packages PL/SQL.
• L'appli (Java/.NET) n'appelle que des procédures stockées.
• Sécurité maximale (l'appli n'a pas accès aux tables, juste aux APIs PL/SQL).
• Inconvénient : Difficile à tester/versionner pour les devs modernes.

Microservices (The New Way)

Philosophie : "Database per Service".

• On utilise les PDBs (Pluggable Databases) pour isoler chaque microservice.
• Utilisation de JSON natif dans Oracle (SODA API) pour le stockage de documents.
• Communication asynchrone via AQ (Advanced Queuing) ou Kafka.

1. Active-Active (RAC)

Postgres n'a pas d'équivalent natif à RAC (écrire sur 2 nœuds en même temps). En Postgres, on écrit sur un Maître, on lit sur des Réplicas.

2. Optimizer (CBO)

Sur des requêtes complexes (DW, 50 jointures), le CBO Oracle reste le roi. Il gère mieux les plans adaptatifs et les transformations de requêtes.

3. Parallel Query

Oracle parallélise tout (DML, DDL, Query). Postgres s'améliore mais reste limité sur le Parallel DML.

4. Flashback

Revenir en arrière dans le temps sans restaurer de backup. Postgres n'a pas ça nativement.

Standard Edition 2 (SE2)

• Limite Hardware : Max 2 Sockets physiques par serveur.
• Limite Thread : Oracle n'utilisera pas plus de 16 threads CPU (même si vous en avez 64).
• Fonctionnalités : RAC inclus (Max 2 nœuds), mais AUCUNE option payante possible (Pas de Partitioning, pas de Tuning Pack, pas de Data Guard).

Enterprise Edition (EE)

• Limites : Aucune (Scalabilité infinie).
• Options : Tout est disponible... mais tout est en option payante (à la carte).
• Parallelism : Inclus.
• Data Guard : Inclus.

La Règle (Galaxy Licensing)

Si vous avez un cluster VMware de 10 serveurs ESXi, et que vous lancez UNE SEULE VM Oracle avec 1 vCPU...

Oracle considère que la VM pourrait bouger (vMotion) sur n'importe quel serveur du cluster.

=> Vous devez payer des licences pour TOUS les coeurs physiques de TOUS les serveurs du cluster VMware.

Solutions

• Cluster Dédié : Créer un petit cluster VMware de 2 serveurs physiquement isolés uniquement pour Oracle.
• Hard Partitioning : Utiliser IBM LPAR (AIX) ou Solaris Zones (capped), qui sont reconnus par Oracle pour limiter le licensing aux coeurs alloués.
• Oracle VM (OVM) / KVM : La solution de virtualisation maison d'Oracle (Hard Partitioning reconnu).

Oracle Database@Azure

Oracle installe physiquement des racks Exadata DANS les datacenters de Microsoft Azure.

• Latence : < 2ms (Comme si c'était local).
• Achat : Via la Marketplace Azure (consomme votre engagement MACC).
• Gestion : Interface Azure, moteur Oracle géré par Oracle.

Interconnect (L'ancienne méthode)

Un câble direct entre un DC OCI et un DC Azure (ex: Paris OCI <-> Paris Azure).

Latence ~2ms, mais complexité réseau (VNET/VCN peering). Remplacé petit à petit par les offres natives "@Azure" et "@AWS".

L'Ancienne École : OEM

Oracle Enterprise Manager (Cloud Control).

• Avantages : Tout-en-un. Gère le Hardware (Exadata), l'OS et la DB. Permet de lancer des jobs, patcher, tuner (SQL Advisor).
• Inconvénients : Lourd (Java), complexe à installer, licence coûteuse (Packs).

La Nouvelle École : Observabilité

Intégration dans la stack DevOps moderne.

• Prometheus + Grafana : Via oracledb_exporter. Tableaux de bord légers et rapides.
• Datadog / Dynatrace : Agents natifs. Corrélation avec les logs applicatifs (Full Stack Tracing).
• Splunk / ELK : Pour l'analyse des logs d'audit et alert.log.

1. Archiver Stuck (Disk Full)

• Symptôme : L'application est figée. Personne ne peut écrire. Le log dit : ORA-00257: Archiver error.
• Cause : La zone de stockage des logs archivés est pleine.
• Fix Rapide : Sauvegarder et supprimer les vieux logs via RMAN (DELETE ARCHIVELOG ALL COMPLETED BEFORE...) ou agrandir la FRA.

2. Blocking Locks (Verrous)

• Symptôme : "L'appli tourne dans le vide". Le CPU est bas.
• Cause : Une session (ex: un dev avec un SELECT FOR UPDATE non committé) bloque tout le monde.
• Fix : Identifier le "Root Blocker" et tuer la session (ALTER SYSTEM KILL SESSION).

L'outil : OPatch

                            # 1. Vérifier l'inventaire
                            $ORACLE_HOME/OPatch/opatch lsinventory

                            # 2. Appliquer le patch (Arrêt requis pour Single Instance)
                            opatch apply

                            # 3. Post-Install (Mettre à jour le dictionnaire SQL)
                            cd $ORACLE_HOME/OPatch
                            ./datapatch -verbose

Best Practice : Out-of-Place Patching

Au lieu de patcher le binaire existant (risqué), on installe un nouveau ORACLE_HOME avec la nouvelle version.

Jour J : On arrête la base sur le Home V1, on change les variables d'env, on démarre sur le Home V2. Si ça plante, retour arrière en 5 minutes.

L'Environnement

Souvent des ERP monolithiques (SAP, Oracle E-Business Suite, JD Edwards). Des milliers de tables, des modèles de données ultra-complexes.

Pourquoi Oracle ?

• L'Optimizer (CBO) : Seul Oracle arrive à trouver un plan d'exécution efficace pour une jointure de 50 tables générée par un ERP.
• Online Redefinition : Permet de modifier la structure d'une table (ajout de colonne, partitionnement) pendant que l'usine continue de produire (DBMS_REDEFINITION).

Pourquoi ça paie ?

• Rareté : Moins de juniors se forment sur Oracle. Les seniors deviennent des ressources rares.
• Risque : Toucher à la base de données de la facturation d'un opérateur Telco demande des nerfs d'acier. On paie la responsabilité.
• Enjeux : Les clients Oracle sont des grands comptes (CAC40) avec des budgets conséquents.

Fourchettes (Est. Paris 2024)

• Junior (0-2 ans) : 40k - 48k € (Souvent reconversion ou alternance).
• Confirmé (3-7 ans) : 55k - 70k €.
• Senior / Expert : 75k - 100k+ €.
• Architecte : 90k - 120k €.

Le Piège (Legacy Trap)

Ne restez pas le "DBA Vieux Jeu" qui refuse le Cloud et ne connaît que la ligne de commande SQL*Plus. Vous finirez par éteindre la lumière dans 10 ans.

La Stratégie Gagnante (Hybride)

Soyez un "Database Reliability Engineer" (DBRE) qui :

• Connaît Oracle en profondeur (Internals).
• Sait automatiser avec Terraform/Ansible.
• Connaît au moins une autre base "Moderne" (PostgreSQL ou MongoDB).

Auto-Indexing

L'IA observe les requêtes. Elle crée des index "candidats", les teste en background, et si la performance s'améliore, elle les publie. Si non, elle les supprime.

Conséquence : Le métier de DBA "Tuning SQL" va évoluer vers de la supervision d'IA.

Auto-Scaling (K8s)

La base détecte la charge CPU et alloue des cœurs supplémentaires instantanément (sans redémarrage), puis réduit la voilure pour économiser les coûts.

Microservices vs Monolith

Oracle est taillé pour le Monolithe Modulaire. Découper une base Oracle en 50 petites bases microservices perd tout l'intérêt (ACID, Joins, Performance).

Compromis : Utiliser les Schemas ou PDBs pour isoler les domaines, mais rester sur une infrastructure consolidée.

Traitement par Lots (Batchs)

Ne faites jamais de gros traitements de données en Java/Python (Extract -> Process -> Insert).

Faites-le en PL/SQL (Inside-DB) :

• Pas de latence réseau (Data Gravity).
• Utilisation de INSERT INTO ... SELECT (Direct Path Load).
• Parallélisme natif Oracle.

Oracle (UNDO)

• Quand on update une ligne, l'ancienne valeur part dans le Tablespace UNDO.
• La table de données reste compacte.
• Avantage : Performance constante en UPDATE intensif.
• Risque : ORA-01555 Snapshot Too Old (si l'Undo est trop petit).

PostgreSQL (VACUUM)

• Quand on update une ligne, on crée une nouvelle version dans la même page (bloc). L'ancienne devient "morte".
• Problème : La table grossit ("Bloat").
• Solution : Le processus AutoVacuum doit passer derrière pour marquer l'espace comme libre.
• Risque : Si l'AutoVacuum ne suit pas la cadence, la performance s'effondre.

Culture Oracle (Le "Sachant")

• Outils graphiques (OEM, Toad).
• Tuning via "Wait Events" (Méthodique).
• On s'appuie sur le Support Oracle en cas de crash.
• L'infra est "Statique" et "Robuste".

Culture Postgres (Le "Do-er")

• Ligne de commande (psql, bash) et scripts.
• On doit construire sa propre HA (Patroni, Ansible).
• En cas de crash, on lit les logs et le code source (ou StackOverflow).
• L'infra est "Jetable" (Pets vs Cattle).

Oracle Database@Azure / @AWS

La solution ultime : Oracle installe physiquement des racks Exadata DANS les datacenters de Microsoft et Amazon.

• Latence : < 2ms (Réseau local).
• Expérience : Vous provisionnez la base depuis la console Azure/AWS.
• Facturation : Intégrée à votre facture Azure/AWS (consomme vos crédits MACC/EDP).

Interconnect (L'alternative)

Un lien direct dédié entre OCI et Azure (dispo dans certaines régions). Latence ~2ms. Moins intégré mais fonctionnel.

Blocking Sessions (Arbre de blocage)

                            SELECT 
                            lpad(' ', (level-1)*2) || s.sid || ' ' || s.username AS user_tree,
                            s.event,
                            s.blocking_session
                            FROM v$session s
                            CONNECT BY PRIOR s.sid = s.blocking_session
                            START WITH s.blocking_session IS NULL 
                            AND s.sid IN (SELECT blocking_session FROM v$session);

Espace Critique (TEMP / UNDO)

Qui mange tout le TEMP ?

                            SELECT s.sid, s.username, u.tablespace, 
                            u.contents, u.blocks * 8192 / 1024 / 1024 as MB
                            FROM v$session s, v$sort_usage u
                            WHERE s.saddr = u.session_addr
                            ORDER BY u.blocks DESC;