undo tablespace se remplit

**big1** · 04/10/2006, 14h00

Bonjour,
j'ai lancé un chargement par SQLLDR pour remplir une table vide. Le tablespace UNDO se remplit et cela ne s'arrête pas. Pour quoi ? y'a-t-il une façon de l'mpecher ?
merci de vos explications et de votre aide.

**orafrance** · 04/10/2006, 14h08

non, SQLLDR = INSERT = UNDO... c'est normal

**bouyao** · 04/10/2006, 14h42

Il faut utiliser l'option ROWS=n. Pour un chargement conventionel rows represente le nombres de lignes par commit.

**orafrance** · 04/10/2006, 15h08

non, rows=n = import de la structure uniquement

**Jaouad** · 04/10/2006, 15h16

fred tu ne confond pas avec l'import

On n'importe pas la structure avec le Loader

Une autre méthode consiste a utiliser l'option direct qui ne se sert pas des UNDO

**orafrance** · 04/10/2006, 15h16

ha oui désolé

**sygale** · 04/10/2006, 16h27

il existe une option dans sqlloader pour faire un commit apres x lignes, il suffit d'ajouter ROWS=[n]

exemple sur un fichier de 15 lignes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
sqlload USERID= /@mabase 
CONTROL=/pgm/control.ctl 
DATA=/pgm/data.dat 
LOG=log.log BAD=bad.bad 
DISCARD=dis.dis rows=1
 
SQL*Loader: Release 9.2.0.3.0 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 2
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 3
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 4
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 5
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 6
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 7
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 8
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 9
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 10
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 11
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 12
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 13
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 14
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 15

**LeoAnderson** · 04/10/2006, 16h38

C'est exactement ce que bouyao disait à 14h42 ! ;-)

**remi4444** · 05/10/2006, 19h13

Vous êtes sur que ça libère le UNDO de faire des commit ??

Sinon y'a le mode DIRECT=TRUE, brutal, dangeureux, mais efficace....

**rbaraer** · 06/10/2006, 14h09

Envoyé par remi4444

Vous êtes sur que ça libère le UNDO de faire des commit ??

Oui car l'espace "utile" de l'UNDO est ce qui n'est pas encore commité et qui doit pouvoir annuler la transaction courante via un rollback. Donc des commit plus fréquents = des transactions plus petites = UNDO utilisé par chaque transaction inférieur... donc l'UNDO utilisé à un instant t reste nettement inférieur à l'UNDO utilisé par une grosse transaction.

J'espère avoir été clair

.

Cordialement,

rbaraer

**remi4444** · 06/10/2006, 14h11

et le flashback il va les chercher ou ses données ?????

**Jaouad** · 06/10/2006, 14h31

Quelle type de flashback ?

**remi4444** · 06/10/2006, 14h48

En fait l'objet de ma remarque ne portait pas sur la méthode de flashback mais sur le fait qu'il me semblait bien que malgrés les commits, oracle conservait des données dans le tablespace UNDO précisément pour pouvoir éventuellement effectuer des flashbacks plus tard...

**LeoAnderson** · 06/10/2006, 14h48

Envoyé par rbaraer

Oui car l'espace "utile" de l'UNDO est ce qui n'est pas encore commité et qui doit pouvoir annuler la transaction courante via un rollback. Donc des commit plus fréquents = des transactions plus petites = UNDO utilisé par chaque transaction inférieur... donc l'UNDO utilisé à un instant t reste nettement inférieur à l'UNDO utilisé par une grosse transaction.

Non, les blocs undo libérés par un commit sont conservés jusqu'à ce que la durée undo_retention soit atteinte.

C'est jsutement le fait de garder les blocs undo qui permet de limiter les erreurs snapshots too old

**remi4444** · 06/10/2006, 14h50

ok c'est bien mon avis aussi, croisement de messages....

**Jaouad** · 06/10/2006, 15h50

Pour précision un Block undo est libére lorsque celui est commité. Jusque tout le monde est d'accord.
SI le paramétre UNDO_RETENTION et de facon plus large si le UAM est utilisé alors ce bloc sera conservé dans le UNDO durant cette période sauf si Oracle a besoin de cette place il recycle quand même.
Voila pourquoi il peut y avoir une Ora-1555 avec ce type de UNDO. Oracle ne vas pas bloquer les blocs UNDO et donc accessoirement le fonctionnement de l'instance Oracle pour assurer le UNDO RETENTION

**sygale** · 06/10/2006, 16h05

Donc si je comprends bien,
pour pouvoir faire des flashbacks à 10 min par exemple
il ne suffit pas de parametrer undo_retention + undo_management = auto
mais aussi de faire attention au volume des transactions même si la tablesapce UNDO est en AUTOEXTEND ?

Donc peut on dire que 10 min de flashback sur une alimentation infocentre sera bien plus consommatrice en volume que sur une base transactionnelle pour un même volume de données. Les transactions étant plus consomatrice de UNDO ?

J'ai peut être rien compris ?

**LeoAnderson** · 06/10/2006, 16h07

ça dépend si on garantie ou pas ! ;-)

Retention Guarantee

To guarantee the success of long-running queries or Oracle Flashback operations, you can enable retention guarantee. If retention guarantee is enabled, the specified minimum undo retention is guaranteed; the database never overwrites unexpired undo data even if it means that transactions fail due to lack of space in the undo tablespace. If retention guarantee is not enabled, the database can overwrite unexpired undo when space is low, thus lowering the undo retention for the system. This option is disabled by default.

WARNING:

Enabling retention guarantee can cause multiple DML operations to fail. Use with caution.

You enable retention guarantee by specifying the RETENTION GUARANTEE clause for the undo tablespace when you create it with either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Or, you can later specify this clause in an ALTER TABLESPACE statement. You disable retention guarantee with the RETENTION NOGUARANTEE clause.

You can use the DBA_TABLESPACES view to determine the retention guarantee setting for the undo tablespace. A column named RETENTION contains a value of GUARANTEE, NOGUARANTEE, or NOT APPLY (used for tablespaces other than the undo tablespace)

http://download-uk.oracle.com/docs/c...o.htm#ADMIN013