Introduction
Une légende tenace dans le monde Oracle dit qu'une fois les données d'une table supprimées, l'espace occupé par ces lignes est définitivement perdu! Oui, ça a l'air idiot mais on trouve encore cette histoire sur pas mal de forums.

La réalité est plus complexe : une fois que des blocs de données ont été alloués à une table, ces blocs restent alloués à la table, même si l'intégralité des données est supprimée par un DELETE! Néanmoins ces blocs seront réutilisables lors des INSERT suivants.

Si on souhaite libérer ces anciens blocs, il existe plusieurs méthodes :
          - TRUNCATE TABLE
          - DROP TABLE
          - ALTER TABLE ... SHRINK
          -
ALTER TABLE ... MOVE



Points d'attention
Si vous ne reconstruisez pas régulièrement vos tables, vous risquez de perdre beaucoup d'espace disque, voir de remplir votre tablespace de données avec des tables vides... Autre point : cet article traite des tables mais les index eux aussi doivent être régulièrement reconstruits suite à des DELETE.On termine avec le fait que si un MOVE ou un SHRINK a été effectué sur une table, il faut régénérer les index car ils sont invalidés; en effet, les rowid des index ne sont plus pertinents puisque les données dans les tables se sont déplacées :-)



Base de tests
N'importe quelle base Oracle.

 



Exemples
============================================================================================
Créer une table avec 290 000 enregistrements.

============================================================================================
Etat de la base avant la création de la table de test.
Mon tablespace de données, appelé USERS, fait seulement 1.94 Mo.
          SQL> SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_SEGMENTS GROUP BY TABLESPACE_NAME

          UNION
          SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME
          ORDER BY 1;

          TABLESPACE_NAME          TAILLE Mo
          ----------------------------------------------------------
          SYSAUX                            583,25
          SYSTEM                           687,875
          TEMP                                 29
          UNDOTBS1                           9,625
          USERS                                 1,9375

Création de la table de test.
On crée une table de test en choisissant de dupliquer la table DBA_OBJECTS et d'y copier quatre fois les mêmes données.
          SQL> CREATE TABLE T_OBJECTS02 AS SELECT * FROM DBA_OBJECTS;
          Table créée.

          SQL> select count(*) from T_OBJECTS02;
          COUNT(*)
          ----------
          72007

          SQL> INSERT INTO T_OBJECTS02 SELECT * FROM T_OBJECTS02;
          72007 ligne(s) créée(s).

          SQL> /
          144014 ligne(s) créée(s).

          SQL> select count(*) from T_OBJECTS02;
          COUNT(*)
          ----------
          288028

Espace disque occupé par la nouvelle table.
          SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME        TAILLE EN MO
          ----------------------------------------------------------
          T_OBJECTS02                     33

Nombre de blocs dans la table.
          SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME         SUM(BLOCKS)
          -------------------------------------------------------------
          T_OBJECTS02                   4224

Le DB_BLOCK_SIZE faisant 8K (8192 bytes en réalité), nous avons bien pour 4224 blocs, une taille total de 34,6 Mo mais arrondi à 33 Mo dans le calcul plus haut.


============================================================================================
DELETE de 90% de la table : espace non récupéré

============================================================================================

Nous allons maintenant effectuer un DELETE de 90% des données de la table.
          SQL> DELETE FROM T_OBJECTS02 WHERE ROWNUM < 260001;
          260000 LIGNE(S) SUPPRIMEE(S).

Il ne reste plus que 28000 enregistrements sur 288028 soit 10%.
          SQL> SELECT COUNT(*) FROM T_OBJECTS02;
          COUNT(*)
          ----------
          28028

Espace disque occupé par la table après le DELETE.

          SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME         TAILLE EN MO
          ----------------------------------------------------------
          T_OBJECTS02                 33

Nombre de blocs dans la table après le DELETE.
          SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
         SEGMENT_NAME        SUM(BLOCKS)
         ------------------------------------------------------------
         T_OBJECTS02                 4224

On voit bien que le DELETE de 90% de la table n'a rien changé à l'espace disque occupé par la table ni au nombre de blocs qui lui est affecté. Pour quelle raison? Tout simplement parce qu'Oracle a associé ces blocs au segment de la table T_OBJECTS02, qu'ils soient remplis ou vides, et qu'il ne les libérera que dans certaines circonstances qu'on verra plus bas.

Cela vous choque? C'est pourtant ce qui se passe quand, sous Windows, on supprime un fichier de plusieurs gigas et qu'on constate que l'espace disque n'est pas récupéré. Windows a mis le fichier dans la corbeille et on est obligé de vider celle-ci pour réellement récupérer l'espace du fichier supprimé. Oracle est a peu près dans la même philosophie : pour récupérer l'espace disque, vous devez faire une action spécifique et ce n'est pas un DELETE suivi d'un COMMIT mais plutôt un TRUNCATE, MOVE, SHRINK, DROP.


============================================================================================
INSERT de 260000 enregistrements : les anciens blocs sont réutilisés

============================================================================================

Nous allons maintenant prouver que suite à un DELETE, les blocs de données vidés précédemment (en totalité ou partiellement) sont réutilisés lors d'un INSERT.

Nous supprimons d'abord tous les enregistrements de la table pour ensuite alimenter la table comme dans le premier test.
          SQL> delete from t_objects02;
          28028 ligne(s) supprimée(s).

          SQL> commit;
          Validation effectuée.

          SQL> select * from t_objects02;
          aucune ligne sélectionnée

Même vide, la table continue d'occuper les 4224 blocs du départ.
          SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY                      SEGMENT_NAME;
          SEGMENT_NAME          SUM(BLOCKS)
          -----------------------------------------------------------
          T_OBJECTS02                   4224

On réinsère 300 000 enregistrements dans la table de tests.
          SQL> INSERT INTO T_OBJECTS02 SELECT * FROM dba_objects;
          72007 ligne(s) créée(s).

          SQL> INSERT INTO T_OBJECTS02 SELECT * FROM T_OBJECTS02;
          72007 ligne(s) créée(s).

          SQL> /
          144014 ligne(s) créée(s).

          SQL> COMMIT;
          Validation effectuée.

          SQL> SELECT COUNT(*) FROM T_OBJECTS02;
          COUNT(*)
          ----------
          288028

On voit que la table occupe le même nombre de mégas et, surtout, le même nombre de blocs! Ce qui prouve bien que les blocs alloués à la table lors des premiers INSERT le sont restés après le DELETE et qu'ils ont été réutilisés lors des derniers INSERT.
          SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME          TAILLE EN MO
          -----------------------------------------------------------
          T_OBJECTS02                     33

          SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME          SUM(BLOCKS)
          -------------------------------------------------------------
          T_OBJECTS02                    4224

Regardons la taille des tablespaces. Elle nous confirme ce qu'on vient de voir, soit que même si on a généré 66 Mo lors des deux INSERT, seuls 33 Mo ont été ajoutés au TBS USERS. Au départ celui-ci faisait 1,9375 Mo et maintenant il fait 34.9375 Mo.
         SQL> SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_SEGMENTS GROUP BY TABLESPACE_NAME
         UNION
         SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME
         ORDER BY 1;

        TABLESPACE_NAME         TAILLE MO
        ----------------------------------------------------------
        SYSAUX                              584,4375
        SYSTEM                             687,875
        TEMP                                   29
        UNDOTBS1                           20,3125
        USERS                                 34,9375


============================================================================================
TRUNCATE de la table : l'espace est libéré.

============================================================================================

Nous allons maintenant faire un TRUNCATE pour voir si l'espace disque est complètement rendu à Oracle ou s'il reste lié à la table.

Le résultat du test est clair : l'espace est quasiment rendu à Oracle, même s'il reste 8 blocks occupant 0.625 Mo.

        SQL> TRUNCATE TABLE T_OBJECTS02;
        Table tronquée.

        SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
        SEGMENT_NAME          TAILLE EN MO
        -----------------------------------------------------------
        T_OBJECTS02                     ,0625

        SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
        SEGMENT_NAME          SUM(BLOCKS)
        ------------------------------------------------------------
        T_OBJECTS02                       8

        SQL> SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_SEGMENTS GROUP BY TABLESPACE_NAME
        UNION
        SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME
        ORDER BY 1;
        TABLESPACE_NAME          TAILLE MO
        ------------------------------------------------------------
        SYSAUX                              584,4375
        SYSTEM                             687,875
        TEMP                                   29
        UNDOTBS1                           20,3125
        USERS                                  2


============================================================================================
DROP de la table : l'espace n'est pas libéré!

============================================================================================

Nous allons maintenant tester le DROP TABLE. Solution extrême mais quand une table ne sert plus à rien, autant la supprimer.

Nous remplissons à nouveau notre table, nous la supprimons et là, surprise!!!!! le tablespace USERS n'a pas relaché la taille occupée par la table supprimée! Pourtant il ne reste plus aucun bloc associé à la table...

       SQL> INSERT INTO T_OBJECTS02 SELECT * FROM dba_objects;
       72007 ligne(s) créée(s).

       SQL> INSERT INTO T_OBJECTS02 SELECT * FROM T_OBJECTS02;
       72007 ligne(s) créée(s).

       SQL> /
       144014 ligne(s) créée(s).

       SQL> commit;
       Validation effectuée.

       SQL> select count(*) from t_objects02;
       COUNT(*)
       ----------
       288028

       SQL>  SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
       SEGMENT_NAME          SUM(BLOCKS)
       --------------------------------------------------------------
       T_OBJECTS02                 4224

       SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
       SEGMENT_NAME              TAILLE EN MO
       -------------------------------------------------------------------
       T_OBJECTS02                           33

Nous supprimons maintenant la table.
       SQL> DROP TABLE T_OBJECTS02;
       Table supprimée.

       SQL> SELECT SEGMENT_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE EN MO" FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
       aucune ligne sélectionnée

       SQL>  SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
       aucune ligne sélectionnée

       SQL> SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_SEGMENTS GROUP BY TABLESPACE_NAME
                 UNION
                 SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME
                 ORDER BY 1;
       TABLESPACE_NAME                 TAILLE MO
       --------------------------------------------------------------------
       SYSAUX                                         588,75
       SYSTEM                                         687,875
       TEMP                                               29
       UNDOTBS1                                       20,25
       USERS                                             34,9375

L'espace n'est pas récupéré mais l'explication est toute bête : la table droppée est copiée dans la corbeille Oracle appelée RECYCLEBIN et donc elle existe toujours sur le disque dur, au cas où on voudrait la récupérer. Nous allons donc vider cette corbeille et voir si l'espace de la table est bien rendu à Oracle. Bien sur, si vous avez configuré votre base pour ne pas avoir de RECYCLEBIN, l'espace est libéré de suite avec le DROP TABLE. L'autre solution consiste à faire un DROP TABLE ma_table PURGE pour supprimer vraiment la table.
       SQL> select * from cat;
       TABLE_NAME                                           TABLE_TYPE
       -----------------------------------------------------------------------------------
       BIN$MdxPtbEdRcaYummc7uUxOg==$0        TABLE   -- les objets mis dans le RECYCLEBIN ont un nom très bizarre
       COUNTRIES                                                TABLE
       DEPARTMENTS                                          TABLE
       DEPARTMENTS_SEQ                                  SEQUENCE
       EMP                                                           TABLE
       EMPLOYEES                                              TABLE
       EMPLOYEES_SEQ                                     SEQUENCE
       EMP_DETAILS_VIEW                                  VIEW
       JOBS                                                          TABLE
       JOB_HISTORY                                            TABLE
       LOCATIONS                                                TABLE
       LOCATIONS_SEQ                                        SEQUENCE
       REGIONS                                                    TABLE
       13 ligne(s) sélectionnée(s).

       SQL> purge recyclebin ;
       Corbeille purgée.

       SQL> SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_SEGMENTS GROUP BY TABLESPACE_NAME
       UNION
       SELECT TABLESPACE_NAME, SUM(BYTES)/(1024*1024) AS "TAILLE MO" FROM DBA_TEMP_FILES GROUP BY TABLESPACE_NAME
       ORDER BY 1;
       TABLESPACE_NAME        TAILLE MO
       ---------------------------------------------------------
       SYSAUX                             589,0625
       SYSTEM                            687,875
       TEMP                                  29
       UNDOTBS1                          20,25
       USERS                                 1,9375

OK, l'explication était la bonne! Nous avons récupéré l'intégralité des blocs alloués à la table puisque nous avons le même espace disque pour le TBS USERS qu'avant la création de la table.


============================================================================================
MOVE ET SHRINK de la table : l'espace est libéré!

============================================================================================

Nous avons vu que TRUNCATE TABLE et DROP TABLE ma_table PURGE permettaient de rendre à Oracle les blocs occupés par la table mais il s'agit là de commandes à utiliser en dernier recours. Pour juste récupérer les blocs perdus lors d'un DELETE, nous allons réorganiser notre table via un MOVE ou un SHRINK; il s'agit là des commandes Oracle prévues à cet effet.

Attention, une fois un MOVE ou un SHRINK effectués sur une table, il faut régénérer ses index. Ceux-ci ont été invalidés car les rowid des index ne sont plus pertinents par rapport à l'emplacement des données puisqu'elles ont été déplacées (elles ont donc un nouveau ROWID).

Nous testons d'abord le MOVE.
          SQL> CREATE TABLE T_OBJECTS02 AS SELECT * FROM DBA_OBJECTS;
          Table créée.

          SQL> select count(*) from T_OBJECTS02;
          COUNT(*)
          ----------
          72007

          SQL> INSERT INTO T_OBJECTS02 SELECT * FROM T_OBJECTS02;
          72007 ligne(s) créée(s).

          SQL> /
          144014 ligne(s) créée(s).

          SQL> select count(*) from T_OBJECTS02;
          COUNT(*)
          ----------
          288028

          SQL> DELETE FROM T_OBJECTS02 WHERE ROWNUM < 260001;
          260000 LIGNE(S) SUPPRIMEE(S).

          SQL>  SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME          SUM(BLOCKS)
          --------------------------------------------------------------
          T_OBJECTS02                 4224

          SQL> ALTER TABLE T_OBJECTS02 MOVE;
          Table modifiée.

          SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
          SEGMENT_NAME                 SUM(BLOCKS)
          ---------------------------------------------------------------------------
          T_OBJECTS02                             512

Bingo!  Nous sommes passés de 4224 blocs à seulement 512! La table a bien été réorganisée. On notera quand même que 260 000 lignes sur 288 000 représente 90% de la table supprimée. Pourtant, nous avons 512 blocs au lieu de 422 (10% de 4224) après le MOVE. A quoi servent ces 90 blocs en plus? Nous dirons que le MOVE est bien mais qu'il ne peut pas réorganiser en totalité la table, il a donc ses imperfections que le SHRINK vient corriger.


Nous allons maintenant tester le SHRINK pour voir s'il est plus performant que le MOVE.
Nous droppons la table, la recréons et la remplissons comme dans les tests précédents.
         SQL> drop table T_OBJECTS02 purge;
         Table supprimée.

         SQL> CREATE TABLE T_OBJECTS02 AS SELECT * FROM DBA_OBJECTS;
         Table créée.

         SQL> INSERT INTO T_OBJECTS02 SELECT * FROM T_OBJECTS02;
         72007 ligne(s) créée(s).

         SQL> /
         144014 ligne(s) créée(s).

         SQL> commit;
         Validation effectuée.

         SQL> DELETE FROM T_OBJECTS02 WHERE ROWNUM < 260001;
         260000 LIGNE(S) SUPPRIMEE(S).

         SQL> commit;
         Validation effectuée.

Pour pouvoir utiliser la fonction SHRINK, il faut que pour la table l'option ROW MOVEMENT soit activée.
        SQL> alter table T_OBJECTS02 ENABLE ROW MOVEMENT;
        Table modifiée.

        SQL> ALTER TABLE T_OBJECTS02 Shrink SPACE;
        Table modifiée.

        SQL> SELECT SEGMENT_NAME, SUM(BLOCKS) FROM DBA_SEGMENTS WHERE SEGMENT_NAME = 'T_OBJECTS02' GROUP BY SEGMENT_NAME;
        SEGMENT_NAME          SUM(BLOCKS)
        ----------------------------------------------------------------
        T_OBJECTS02                       424

Et voilà, il reste 424 blocs après la réorganisation contre 512 pour le MOVE, soit quasiment tout l'espace récupéré!



============================================================================================
Détecter les tables avec trop de blocs vides

============================================================================================

Nous allons maintenant voir un ordre SQL qui va calculer l'espace disque réel et sur disque dur de nos tables, afin de voir celles qui ont besoin d'une réorganisation. Une fois cela fait, il vous suffit de vérifier les valeurs de la colonne "Taille MO" pour les deux lignes "TAILLE_REELLE_TABLE" et "TAILLE_SUR_DISQUE_TABLE".

Nous générons la requête uniquement pour la table de tests mais on peut le faire aussi pour un schéma entier.
Requête sur une table.
          SQL> SELECT owner, table_name,
                           'TAILLE_REELLE_TABLE' AS "TYPE_DE_TAILLE",
                           round((num_rows * avg_row_len)/(1024*1024),2) AS "TAILLE MO"
                  FROM dba_tab_statistics
                  WHERE table_name = 'T_OBJECTS02'
                  UNION
                  SELECT owner, segment_name,
                           'TAILLE_SUR_DISQUE_TABLE',
                           (blocks*(select value from v$parameter where UPPER(name) = 'DB_BLOCK_SIZE'))/(1024*1024)
                  FROM dba_segments
                  WHERE segment_name = 'T_OBJECTS02'
                  ORDER BY 1, 2;
       TYPE_DE_TAILLE                      TAILLE MO
       --------------------------------------------------------------------
       TAILLE_REELLE_TABLE                  2,65
       TAILLE_SUR_DISQUE_TABLE       33

Requête sur les tables d'un schéma.
         SQL> SELECT owner, table_name,
                  'TAILLE_REELLE_TABLE' AS "TYPE_DE_TAILLE",
                  round((num_rows * avg_row_len)/(1024*1024),2) AS "TAILLE MO"
         FROM dba_tab_statistics                       
         WHERE OWNER = 'HR'
         UNION
         SELECT owner, segment_name,
                  'TAILLE_SUR_DISQUE_TABLE',
                  (blocks*(select value from v$parameter where UPPER(name) = 'DB_BLOCK_SIZE'))/(1024*1024)
         FROM dba_segments
         WHERE OWNER = 'HR'
         ORDER BY 1, 2;
         OWNER                          TABLE_NAME                                                         TYPE_DE_TAILLE                          TAILLE MO
         ------------------------------ -------------------------------------------------------------------------------------------------------- -----
         HR                             DEPARTMENTS                                                     TAILLE_REELLE_TABLE                       0
         HR                             DEPARTMENTS                                                     TAILLE_SUR_DISQUE_TABLE               ,0625
         HR                             EMP                                                                       TAILLE_REELLE_TABLE                        0
         HR                             EMP                                                                       TAILLE_SUR_DISQUE_TABLE              ,0625
         HR                             EMPLOYEES                                                         TAILLE_REELLE_TABLE                         ,01
         HR                             EMPLOYEES                                                         TAILLE_SUR_DISQUE_TABLE                 ,0625
         HR                             JOB_HISTORY                                                      TAILLE_REELLE_TABLE                          0
         HR                             JOB_HISTORY                                                      TAILLE_SUR_DISQUE_TABLE                 ,0625
         HR                             JOBS                                                                     TAILLE_SUR_DISQUE_TABLE                 ,0625
         HR                             JOBS                                                                     TAILLE_REELLE_TABLE                          0
         HR                             LOCATIONS                                                           TAILLE_REELLE_TABLE                         0
         HR                             LOCATIONS                                                           TAILLE_SUR_DISQUE_TABLE                ,0625
         HR                             REGIONS                                                               TAILLE_REELLE_TABLE                         0
         HR                             REGIONS                                                               TAILLE_SUR_DISQUE_TABLE                ,0625
         HR                             T_OBJECTS02                                                       TAILLE_REELLE_TABLE                           2,65
         HR                             T_OBJECTS02                                                       TAILLE_SUR_DISQUE_TABLE                  33
         HR                             T_OBJECTS03                                                       TAILLE_SUR_DISQUE_TABLE                  33
         HR                             T_OBJECTS03                                                       TAILLE_REELLE_TABLE                           26,66
         19 ligne(s) sélectionnée(s).