Les GTT en 10g

[tropiko]

Bonjour ,

1/ J'ai une GTT (Global Temporary Table) qui utilise le tablespace TOOLS.
mais ce tablespace n'est ni le tablespace par défaut du user ni précisé dans l'ordre de création de la GTT !

D'où vient ce lien entre la GTT et ce tablespace ?

2/ Oracle préconise d'utiliser les GTT quand c'est possible .

En dehors du fait que les GTT ne génère pas d'écritures UNDO et REDO quels sont les autres avantages ?

3/ Pourquoi s'embêter à créer des GTT alors qu'on peut créer des tables classiques en mode NOLOGGING qu'on peut TRUNCATER au besoin ?

et en plus on peut vérifier le contenu (nombre de lignes par exemple) depuis n'importe qu'elle autre session(chose impossible avec les GTT).

A+

[pacmann]

Salut,

La GTT est créée dans le default temporary tablespace.

L'étanchéité inter session de la GTT peut être considéré comme un avantage, il permet de pas se mélanger les pinceaux (et donc être utilisée de manière concurrente par plusieurs jobs / users).

Donc gestion du vidage automatique, étanchéité et no redo / undo sont des avantagtes.

Sinon côté NOLOGGING, ça ne marche pas quand ta base est en force logging, ce qui arrive avec notamment avec Data Guard.

[mnitu]

Envoyé par tropiko

...

En dehors du fait que les GTT ne génère pas d'écritures UNDO et REDO quels sont les autres avantages ?
...

Faux!
Les tables temporaires génèrent toujours de l'undo et moins de redo ! En fait elles ne génèrent pas directement du redo mais comme elles génèrent de l’undo et l’undo doit être protégé par le redo il y en auras toujours un peu.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
SQL> create global temporary table gtt
(
  OWNER          VARCHAR2(30) not null,
  OBJECT_NAME    VARCHAR2(30) not null,
  SUBOBJECT_NAME VARCHAR2(30),
  OBJECT_ID      NUMBER not null,
  DATA_OBJECT_ID NUMBER,
  OBJECT_TYPE    VARCHAR2(19),
  CREATED        DATE not null,
  LAST_DDL_TIME     DATE not null,
  TIMESTAMP      VARCHAR2(19),
  STATUS         VARCHAR2(7),
  TEMPORARY      VARCHAR2(1),
  GENERATED      VARCHAR2(1),
  SECONDARY      VARCHAR2(1)
)
on commit delete rows
/
Table créée.

SQL> set autotrace traceonly statistics
SQL> insert into gtt select * from all_objects;

25870 ligne(s) créée(s).


Statistiques
----------------------------------------------------------
        276  recursive calls
       1816  db block gets
     135410  consistent gets
          1  physical reads
     136084  redo size
        833  bytes sent via SQL*Net to client
        734  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
        634  sorts (memory)
          0  sorts (disk)
      25870  rows processed

[pachot]

Bonjour,

Les GTT permettent:
- d'isoler les données de chaque session, alors que les tables 'normales' servent au contraire à les partager.
- de gérer des données non persitantes: les données disparaissent si la session se termine

C'est donc plus performant: moins de contention, moins de redo nécessaire.

Par contre, le UNDO est généré normalement car on doit pouvoir faire un rollback.
Et du REDO est quand nême généré (pour cet undo... même si c'est inutile)

Les tables classiques en NOLOGGING évitent de générer du REDO uniquement en direct-path (insert append). Elles génèrent quand même du redo en inserts conventionnels.

Et les GTT évitent surtout de créer des tables à la volée (DDL) ce qui est toujours couteux.

Gordialement,
Franck.