Discussion :

[farenheiit]

Bonjour,

j'aurais souhaité savoir à quoi sert le paramètre UNDO_RETENTION?
Je travaille sur base en 9.2.0.8 et j'ai un problème de taille de RollBackSegment.

On m'a conseillé d'augmenter la valeur de ce paramètre à la place d'augmenter la taille du tablespace UNDO. Est-ce judicieux?si oui Pourquoi.
merci pour vos réponses

[LeoAnderson]

en 9, si vous avez l'erreur snapshot too old, ça ne changera rien
faut juste aggrandir ou réduire les transactions

en 10, tout dépend de la garantie
http://download-uk.oracle.com/docs/c...o.htm#ADMIN013

[orafrance]

c'est quoi le problème exactement ?

[farenheiit]

en fait j'ai une procédure qui permet de faire redescendre la HWM de mes tables.
donc je créer une table temporaire en faisant un select * de la table que je veux truncater. ensuite je truncate ma table et je réinsère les données à partir de ma table temporaire.
voici un extrait de mon code:

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
-- Boucle sur toutes les tables LDR
  	FOR CUR_REC in (select * from USER_TABLES where table_name like 'LDR_%')
  	LOOP
	  	BEGIN
 
			vA_nom_table_tmp := 'A_' || CUR_REC.table_name;
 
			-- création de la table temporaire contenant les même données que la table LDR
	  		vA_sql := 'create table ' || vA_nom_table_tmp || ' as select * from ' || CUR_REC.table_name;	
	  		EXECUTE IMMEDIATE vA_sql;
 
	  		-- truncate de la table LDR
	  		vA_sql := 'truncate table ' || CUR_REC.table_name;	
	  		EXECUTE IMMEDIATE vA_sql;
 
	  		-- insertion des données dans la table LDR avec la table tmp
	  		vA_sql := 'insert into ' || CUR_REC.table_name || ' select * from ' || vA_nom_table_tmp;	
	  		EXECUTE IMMEDIATE vA_sql;
 
	  		COMMIT;
 
	  		-- ANALYZE de la table LDR
	  		vA_sql := 'analyze table ' || CUR_REC.table_name || ' compute statistics';	
	  		EXECUTE IMMEDIATE vA_sql;
 
	  		-- DROP de la table temporaire
	  		vA_sql := 'drop table ' || vA_nom_table_tmp;	
	  		EXECUTE IMMEDIATE vA_sql;
 
 
	  	EXCEPTION
		  WHEN OTHERS THEN
		  	   vA_msg := SQLERRM;
 			   Pck_Log.PWrite_Error('Pck_util.PUTL_INIT_HWM','SQLCODE='||TO_CHAR(SQLCODE));
			   Pck_Log.PWrite_Error('Pck_util.PUTL_INIT_HWM',SQLERRM);
			   Pck_Log.PWrite_info;
	  	END;
  	END LOOP;

Pour les grosses tables j'ai un problème de rollbacksegment too small

[farenheiit]

finalement j'ai modifié le paramètre UNDO_RETENTION en le faisant passer de 5min à 30 minutes et je n'ai plus de problème. Mais je ne comprends toujours pas l'impact de ce paramètre

[orafrance]

tu sais que tu peux faire un MOVE pour faire redescendre la HWM ? Sinon, le UNDO_RETENTION (à part en 10g avec la garantie) ne peut être la souce du problème... c'est la taille du UNDO qui est insuffisante ou plutôt sa sollicitation qui est trop intensive.

Autre question : pourquoi vouloir absolument redescendre la HWM si les tables sont grosses ?

[farenheiit]

c'est quoi un move?
ba en fait ma base sert de DataWarehouse: je charge mes tables de dimensions et ma table de fait à partir de la base transactionnelle. A chaque chargement de mon DW c'est comme si je chargeais tout le contenu de ma base transactionnelle. Chaque chargement correpond à un identifiant de traitement dans mes tables. De temps en temps je suis amené à supprimer des chargements donc des milliers de lignes dans chaque table de dimensions. Pour certaines requêtes effectuées sur ces tables l'optimiseur oracle préfère faire un Full Scan. Il me paraissait donc utile de faire redescendre la HWM sinon le full scan irait jusqu'à la HWM. Non? est ce que je suis dans le faux? As-tu une meilleure solution?
merci de ton aide

[orafrance]

En effet... mais si tu ne fais pas de l'insertion en mode DIRECT (INSERT /*+ APPEND*/ par exemple) les vides seront comblés... est-ce que ce ne serait pas plus intéressant de stabiliser le plan d'exécution ? Le FTS est-il réellement plus intéressant ?

[farenheiit]

par FTS t'entends Full Scan?
Je ne sais pas si c'est plus intéressant, c'est l'optimiseur qui choisit. j'essaye pour chaque requête de travailler avec le plan d'execution et donc de mettre des Index là où il faut mais malgré ces indexes oracle prefere le Full Scan.

[orafrance]

J'ai oublié de répondre MOVE sert à déplacer la table, tu peux faire un MOVE dans le même tablespace.

FTS = Full Table Scan. Créé des indexes systématiquement c'est pas forcément une super idée. Vérifie que les stats sont bien calculées, ça peut être la cause d'un mauvais plan d'exécution... sachant qu'un FTS n'est pas forcément synonyme de mauvais plan

[farenheiit]

oui je sais: je met l'index je calcul les stats et je regarde dans le plan d'execution si l'index est utilisé sinon je le supprime. c'est ce que je fais.

Concernant le move ça marche en 9i? c koi la commande exact?

[orafrance]

http://www.developpez.net/forums/sho...E9organisation

Oui, depuis la 8i il me semble

[farenheiit]

ok merci mais j'aimerais quand même bien savoir à quoi sert le paramètre UNDO_RETENTION

[orafrance]

il définit la durée durant laquelle les données doivent être conservée dans le UNDO après la fin de la transaction qui les a mise. En revanche cette durée n'est pas garantie ce qui signifie que si Oracle a besoin de place il écrasement quand même les données retenues.

[13thFloor]

j'essaye pour chaque requête de travailler avec le plan d'execution et donc de mettre des Index là où il faut mais malgré ces indexes oracle prefere le Full Scan.

Les index non utilisés sont sans doute peu sélectifs, d'ou un coût par index plus coûteux que si Oracle effectue un FTS.
Ta base étant orientée DSS, elle manipule de plus gros volumes de data (en principe), donc les FTS sont plus fréquent qu'en transactionnel.
Maintenant, si tu veux absolument qu'oracle utilise tes index, et ainsi vérifier si l'optimiseur à tort ou raison (à toi de comparer les plans d'exécution et les temps d'exec), tu peux soit placer des hints dans quelques requêtes, soit réduire drastiquement le paramètre optimizer_index_cost_adj (à 10 par exemple).