Comment utiliser DML sur une table temporaire Oracle sans générer beaucoup d'annulations

Question

L'utilisation d'une table temporaire Oracle ne génère pas beaucoup de journalisation en tant que table normale. Cependant, le journal d'annulation est toujours généré. Ainsi, comment puis-je écrire une instruction insert, update ou delete sur une table temporaire mais Oracle ne générera pas undo log ou générera le moins possible?

De plus, en utilisant/+ annexe/dans l'instruction d'insertion générera peu de journal d'annulation. Ai-je raison? Si non, quelqu'un pourrait-il m'expliquer comment utiliser l'indice/+ ajouter /?

INSERT /*+APPEND*/ INTO table1(...) VALUES(...); 

Answer 1

Oracle a besoin d'informations UNDO pour restaurer le fichier DML dans la transaction. Comme Gary met dans son commentaire:

« Undo est nécessaire pour rollback Il est également nécessaire effets d'une seule déclaration si elle échoue partiellement par de prévoir une ROLLBACK TO SAVEPOINT ou. ROLLBACK (bien que pour GLOBAL TEMPORARY TABLES le dernier ne serait pertinent que pour la session durée GTT). "

Cette information UNDO génère elle-même des données REDO. Il n'y a rien que vous pouvez faire à propos de cette situation: les tables temporaires ont besoin d'UNDO et c'est la fin.

Pour minimiser la quantité de UNDO est assez simple: il suffit d'insérer des enregistrements et sélectionner des enregistrements. INSERT génère la plus petite quantité de UNDO, car l'annulation d'un INSERT nécessite simplement l'attribut rowid. Inversement, les instructions DELETE génèrent le plus d'UNDO, car la base de données doit stocker l'intégralité de l'enregistrement. Fondamentalement, pour annuler un problème INSERT un DELETE, pour annuler un problème DELETE un INSERT. Un UPDATE génère une quantité variable de UNDO, car nous avons besoin des anciennes versions des colonnes modifiées; plus les colonnes sont modifiées et plus elles sont grandes, plus la quantité d'UNDO générée est importante.

Démonstration

En séance un utilisateur insère un grand nombre d'enregistrements dans une table temporaire, puis de les supprimer. Dans la deuxième session, un administrateur de base de données surveillera l'utilisation de l'opération UNDO de la transaction.

SSN1> insert into gtt23 
    2  select * from big_table 
    3/

553928 rows created. 

SSN1> 

utilisation Annuler:

SSN2> select space, noundo, used_ublk, used_urec from v$transaction 
    2/

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO   257  10816 

SSN2> 

Maintenant, la suppression:

SSN1> delete from gtt23 
    2/

553928 rows deleted. 

SSN1> 

utilisation Undo (plusieurs échantillons au cours d'une longue déclaration de fonctionnement) ::

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO  11123  435605 

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO  13413  525452 

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO  14552  570567 

SSN2> 

Commit (la table temporaire a une transaction portée à-dire EFFACER rows)

SSN1> commit 
    2/

Commit complete. 

SSN1> 

d'utilisation Annuler:

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

no rows selected 

SSN2> 

L'utilisation d'annulation est accumulative:

SSN1> insert into gtt23 
    2  select * from big_table 
    3/

553928 rows created. 

SSN1> delete from gtt23 
    2/

553928 rows deleted. 

SSN1> insert into gtt23 
    2  select * from big_table 
    3/

553928 rows created. 

SSN1> 

Undo utilisation

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO   258  10816 

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO  14766  579495 

SSN2> r 
    1* select space, noundo, used_ublk, used_urec from v$transaction 

SPA NOU USED_UBLK USED_UREC 
--- --- ---------- ---------- 
NO NO  14819  581685 

SSN2> 

Donc, pour minimiser l'impact de UNDO qu'une table temporaire génère, assurez-vous d'insérer les bonnes données, une fois. Évitez d'y appliquer des mises à jour et surtout évitez de supprimer un grand nombre d'enregistrements. Si vous utilisez une table temporaire avec une étendue de transaction, il ne devrait pas être nécessaire de supprimer des enregistrements. Si votre table temporaire a une durée de session et que vous devez l'effacer, il serait préférable d'utiliser TRUNCATE, si possible, plutôt que DELETE.

Answer 2

Je crois que vous pouvez également obtenir un certain avantage du mot-clé NOLOGGING. L'indicateur append suggère qu'Oracle doit utiliser les opérations DIRECT-PATH, ce qui peut entraîner des insertions plus rapides. Si je me souviens bien, vous devriez avoir un accès exclusif à la table. Il est important de valider après l'insertion, afin que vous puissiez sélectionner des informations à partir de celle-ci.

Answer 3

trouvé sur AskTom:

inserts de chemin classique génèrent UNDO . ils doivent, vous devez être capable de revenir en arrière, vous devez être en mesure de pour soutenir multi-versioning.

UNDO est toujours protégé par le rétablissement.

Si vous définissez le chemin de la table temporaire globale (insérez/* + APPEND * /), vous pouvez ignorer l'annulation de la table, mais pas celle des index. D'où vous pouvez réduire (marginalement typiquement car est habituellement des index qui génèrent le le plus d'annulation) le montant de refaire, mais vous ne pouvez pas l'éliminer.