IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

remise à jour des rollback segment par oracle


Sujet :

Administration Oracle

  1. #1
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut 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

  2. #2
    Expert Oracle confirmé

    Homme Profil pro
    Consultant Big Data
    Inscrit en
    Mars 2003
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Consultant Big Data
    Secteur : Conseil

    Informations forums :
    Inscription : Mars 2003
    Messages : 448
    Points : 926
    Points
    926
    Par défaut
    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.

  3. #3
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut
    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?

  4. #4
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut
    seulement pour savoir si y'a quelqu'un qui a une idée là dessus encore

  5. #5
    Membre expérimenté

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mai 2003
    Messages : 412
    Points : 1 326
    Points
    1 326
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  6. #6
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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é?

  7. #7
    Membre expérimenté

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mai 2003
    Messages : 412
    Points : 1 326
    Points
    1 326
    Par défaut
    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

  8. #8
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut
    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?

  9. #9
    Membre expérimenté

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mai 2003
    Messages : 412
    Points : 1 326
    Points
    1 326
    Par défaut
    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

  10. #10
    Membre du Club
    Inscrit en
    Mars 2004
    Messages
    137
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 137
    Points : 48
    Points
    48
    Par défaut
    bon bien merci... je crois que ca répond à ma question.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 08/04/2010, 13h58
  2. Réponses: 11
    Dernier message: 10/01/2007, 20h38
  3. Oracle 8.1.7.4 : Vider les Rollback segments
    Par beyonder2005 dans le forum Oracle
    Réponses: 7
    Dernier message: 02/11/2005, 15h37
  4. Réponses: 15
    Dernier message: 30/06/2005, 17h35
  5. Taille des Rollback Segments
    Par slyv dans le forum Oracle
    Réponses: 9
    Dernier message: 17/03/2005, 13h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo