remise à jour des rollback segment par oracle

Bonjour,

J'ai un probleme. J'ai un traitement en batch qui crée des tables et qui insèrent dans ces tables à l'aide d'un "execute immédiate". Pour chacun des "execute immédiate" que je fais, j'utilise dbms_transaction.use_rollback_segment pour forcer un très gros rollback segment (rbig) défini exprès pour ce travail batch. A un moment dans mon script, je fais 2 gros insert coup sur coup (avec execute immédiate et dbms_transaction.use_rollback_segment et un commit entre chaque). Le premier passe bien, mais le 2e me donne l'erreur que mon rollback segment ne peut extentionner le rollback r01. Je viens de lui spécifier de prendre mon rbig!

Est-ce que entre mon 1er insert et mon 2e, oracle a besoin de temp pour mettre à jour mon gros rollback segment avant de pouvoir l'utiliser? Si c'est le cas, je dois faire une boucle de quelques minutes avant de pouvoir faire mon 2e insert? Y'a t'il une autre explication?

merci

Bonjour,

Votre problème provient de l'utilisation du LDD (Langage de Définition des Données).

En clair, une création de table (CREATE TABLE...) est une commande du LDD et qu'elle effectue automatiquement un COMMIT.

Imaginer que vous utilisez un Rollback Segment (par exemple votre RBIG) en l'ayant sélectionné, puis en ayant fait un INSERT. Vous avez donc une transaction en cours et cette transaction doit être commitée ou rollbacker.

Et bien, si jamais vous utilisez par la suite une instruction du LDD (type create table, mais aussi alter table, truncate...), cette instruction est exécutée et de plus automatiquement commitée !!! Votre transaction est finie.

A votre place, je ferais dans cet ordre :
1 ) création d'une table,
2 ) choix du rollback segment RBIG,
3 ) insertion des données dans la table,
4 ) commit.

Ensuite, je réitère le processus.

En tout cas, regarder bien votre code car à un moment, entre le fait de choisir votre Rollback Segment et le fait d'insérer, il y a une instruction (soit CREATE TABLE, soit COMMIT) qui vous fait changer de RBS.

Bonjour,

Je suis au courant que pour les instructions ddl un commit automatique est fait. Mais ce n'est pas mon cas. Je me suis peut-etre mal exprimé. Voici la séquence des instructions :

1) choix du rollback segment RBIG,
2) création d'une table1,
3) choix du rollback segment RBIG,
4) création d'une table1,
5 ) choix du rollback segment RBIG,
6 ) insertion des données dans la table1,
7 ) commit.
8 ) choix du rollback segment RBIG,
9 ) insertion des données dans la table2,
10 ) commit.

l'insertion en 6 passe bien (insertion de 25 millions de rangées) donc le rollback a été sollicité de facon importante. Lorsque j'arrive en 8, on dirait qu'il ne me donne pas mon RBIG parce qu'il est en train de le mettre à jour à cause du commit en 7. Donc je passerait au rollback segment suivant qui est vraiment trop petit et je plante. Est-ce que ma théorie est bonne? Est-ce que Oracle a besoin de temps pour mettre à jour un rollback segment qui vient d'être sollicité par une transaction qui vient d'être commiter?

seulement pour savoir si y'a quelqu'un qui a une idée là dessus encore

Alors j'ai bien relu ton poste.
Je me demandais si tu pouvais inserer du code apres ton commit de 7 pour enregistrer ou afficher quel est le rollback segment qui est actif et celui qui est en cours d'utilisation. en allant regarder dans les vues
V$ROLLNAME, V$ROLLSTAT, V$TRANSACTION, et V$SESSION.

avec

Code:

---

1 2 3 4

select s.sid, s.username, r.name "ROLLBACK SEG" from v$session s, v$transaction t, v$rollname r where s.taddr=t.addr and t.xidusn = r.usn;

---

Lance cette requete à différent instant dans le code pour voir l'évolution de l'utilisation des RBS

De plus ton probleme ressemble tres fortement à un probleme de SNAPSHOT.

Pour regarder cela il faudrai que tu poste le code que tu utilises ( ou tout du moins la partie en question)

De plus pourrais tu me donner les erreurs que tu as lorsque tu plantes (regarde aussi si y en a pas dans ton alert log)

De plus Oracle recommande de toujours faire un Commit avant le dbms_transaction

Je crois avoir réglé mon probleme avec différentes action... j'ai utilisé un create table as select.... avec nologging et un commit juste avant le set transaction...

mais ma question reste entière puisque j'ai seulement contourné le problème en changeant mon approche, est-ce que Oracle a besoin de temps pour vider ou réinitialisé un rollback segment apres une grosse transaction "commiter".

l'erreur que j'avais était

Code:

---

1 2 3

ERROR -1562 ORA-01562: failed to extend rollback segment number 1 ORA-01628: max # extents (200) reached for rollback segment R01

---

le rollback segment R01 n'est pas celui que j'ai setter au départ... C'est bien RBIG. Est-il en train de se réinitialisé?

Nan en fait l'erreur était pas du à Oracle mais à toi qui générait des snapshot to old

Tu devais faire je suppose de grosses transactions sans COMMIT.

Le problème de cette technique est que tu remplis indéfiniment ton rollback segment. Et vu qu'il a pu de place il change automatiquement

Pour ne plus avoir se probleme je te conseille de faire des commits toutes les 200 lignes environ (bon sur 25 millions disons toute les 2000)

Mais il n'est pas bon de faire durer trop longtemps une transaction. Car à la fin tu donnes trop de travaille à DBWR et LOGWR donc il vaut mieux commité de temps à autres.

Ce qui te permettra de supprimer l'option nologging .

Par contre tu laisses bien le commit avant le dbms_transaction

Le probleme est que j'utilise un create table as select .... Je ne peux donc pas faire des commit régulier.

D'après la vitesse à laquelle il "plante", je ne crois pas qu'il ait commencé par remplir mon gros rollback segment, je crois plutot qu'il a été setter toute de suite à R01 (le petit rbs). C'est pourquoi je posais cette question.

Je sais que Oracle ne libère pas toujours l'espace tout de suite d'un tablespace lors d'un drop de table, il attend d'être moins occupé pour le faire...(ca m'est déjà arrivé). Peut-etre que c'est la meme chose avec un rollback segment? Peut-être que mon gros rbs qui a déjà été sollicité beaucoup en 6 lorsqu'il arrive avec le commit de 7 devrait libérer l'espace dans le rbs mais n'a pas le temps, donc quand il arrive en 8 pour resetter RBIG encore, il est encore plein donc change de rollback tout de suite... c'est ma théorie, est-ce qu'elle se tient?

Oui ca peut se tenir mais je pense plutot qu'il change non pas avant mais apres. Vu qu'il a beaucoup de ligne à valider il le vide depuis le début ce qui prend du temps et le laisse indisponible.

Par contre comme solution est ce que tu ne pourras pas séparer ton create table as select en un create table puis tes inserts ce qui te permettrait de faire des commits plus régulier.

Foncierement voila ce qui'il se passe. Le rollback segment est directement utilisé lorsque tu fais ton create table as select car il construit alors une image de la table que tu veux copier. Etant donné que les rollbacks segments fonctionne de manière cyclique quand tu vas donc commencé à copier tes lignes générant ainsi des informations de rollback, un fois celui -ci rempli il ne peut pas écraser le premier segment vu que celui-ci sert à l'image de la table que tu copies donc il swappe.

Donc soit tu augmentes la taille de tes rollbacks, soit tu utilises la fonction no logging

soit tu sépares ton create de tes inserts et tu commites toute les 2000 lignes ce qui videra les rollbacks

bon bien merci... je crois que ca répond à ma question.