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

Oracle Discussion :

Perte de tous les controlfile : comportement bizarre [Débat]


Sujet :

Oracle

  1. #1
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut Perte de tous les controlfile : comportement bizarre
    Bonjour,

    Je viens de faire une constatation assez déconcertante : en 9i et 10g (sous Sun), après avoir physiquement supprimé tous les fichiers de contrôle (base ouverte), je peux sans problèmes continuer à faire des
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    alter system switch logfile;
    ou
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    alter system checkpoint;
    ou encore créer des tablespaces

    alors qu'en 8i, dès je tente ce genre de manip, ça plante (heureusement).

    Tandis qu'en 9i/10g, il n'y a que lorsque je tente de faire un shutdown qu'il me retourne (enfin !!) l'erreur
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    ORA-00210: cannot open the specified controlfile
    ORA-00202: controlfile: '/oradata/toto/control01.ctl'
    ORA-27041: unable to open file
    SVR4 Error: 2: No such file or directory
    Est-ce que quelqu'un pourrait m'expliquer ce qui se passe quand je switche sans controlfile ?

    Leo.

  2. #2
    Membre habitué
    Inscrit en
    Septembre 2006
    Messages
    142
    Détails du profil
    Informations forums :
    Inscription : Septembre 2006
    Messages : 142
    Points : 170
    Points
    170
    Par défaut
    jamais testé le problème mais peut-être que sous la 9/10 tand qu'il y a au moins un controle file présent il continu à travailler et ne signale le problème qu'au redémarrage.

    Peut-être que sous l'instance 8i le controle file n'est pas multiplexé?
    DBA ORACLE

  3. #3
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Non, dans les 3 scénarios de tests, les controls étaient multiplexés et dans les 3 cas, j'ai supprimé tous les controle file !

    ce qui n'est pas normal, a priori, c'est le comportement constaté en 9i/10g car lors de points de synchro, il est justement censé écrire dans le controlfile...

    et il signale le problème lors de l'arrêt (obligeant à faire un abort)

  4. #4
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Est ce que la base est en mode archivelog ?

    Est ce que tu a testé après avoir supprimer les fichier de contrôle de faire un SELECT sur l’une des vues suivantes : (Normalement ca se plante automatique.)
    V$DATABASE,
    V$ARCHIVED_LOG,
    V$BACKUP,
    V$BACKUP_DATAFILE,
    V$BACKUP_PIECE,
    V$BACKUP_REDOLOG,
    V$BACKUP_SET,
    V$DATAFILE,
    V$DATAFILE_COPY,
    V$DATAFILE_HEADER,
    V$LOG,
    V$LOGFILE,
    V$THREAD
    Le checkpoint se réalise directement par la commande ALTER SYSTEM SWITCH LOGFILE ou ALTER SYSTEM CHECKPOINT , par contre, le checkpoint doit être rompus dans deux cas spécifiques :

    Le DBWR écrit les tampons modifiés de la cache dans les fichiers de données.
    Le LGWR met à jours l'entête des fichiers de données et le fichier de contrôle.

    Dans 10g, après un checkpoint, le processus CKPT est censé d’ecrire dans le fichier de contrôle.

    Le fichier de contrôle est utilisé comme l’unique point de synchronisation des composants dans oracle. Il est mis à jours à chaque modification dans la structure de la base, comme l’ajout d’une tablespace ou d’un fichier de données, execution des opérations de restauration comme le checkpoint et le log switch, execution des opérations de maintenance comme le demarrage et l’arrêt de la base. Certains opérations comme l’ajout d’un fichier de données ou d’une tablespace necessitent l’enqueue CF en mode exclusive. Pendant la même periode, un autre processus qui a besoin d’un enqueue à un niveau égale ou plus elevé, devrait attendre 15mn et ressaye l’operation. La pause peut être définie par le paramètre _CONTROLFILE_ENQUEUE_TIMEOUT, par defaut il est à 900 secondes.

  5. #5
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    je viens donc de refaire le test.

    Verdict : je peux interroger sans problèmes les vues que tu cites (je ne les ais pas toutes faites, mais au moins v$database, v$datafile, v$datafile_header, v$thread) sans aucun problème.
    j'ai même attendu plus de 15 minutes, ça change rien.

    et un show parameter du paramètre que tu mentionnes ne retourne rien...

  6. #6
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Citation Envoyé par LeoAnderson
    je viens donc de refaire le test.

    Verdict : je peux interroger sans problèmes les vues que tu cites (je ne les ais pas toutes faites, mais au moins v$database, v$datafile, v$datafile_header, v$thread) sans aucun problème.
    j'ai même attendu plus de 15 minutes, ça change rien.
    Donc , ce n'est pas possible puisque la vue V$DATABASE lit dans le fichier de contrôle.


    Citation Envoyé par LeoAnderson
    et un show parameter du paramètre que tu mentionnes ne retourne rien...
    _CONTROLFILE_ENQUEUE_TIMEOUT C'est un parametre caché on ne peut pas le voir avec un SHOW PARAMETER. Pour cela il faut lancer :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    select a.ksppinm , b.ksppstvl , c.ksppstvl from x$ksppi a, x$ksppcv b, 
    x$ksppsv c where a.indx = b.indx and a.indx = c.indx
    and a.ksppinm = '_controlfile_enqueue_timeout';

  7. #7
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Donc , ce n'est pas possible puisque la vue V$DATABASE lit dans le fichier de contrôle.
    Je sais bien.... mais pourtant je peux t'assurer que je le reproduit !
    Et c'est bien parce que ce comportement bouscule toutes mes certitudes sur Oracle que je cherche des explications !

    Et le paramètre (qui était bien caché, je le reconnais) vaut bien 900. (sans surprises puisque ne sachant pas le trouver, je ne l'avais certainement pas modifié !)


    [edit]
    je veux bien envisager la possibilité d'un cache au niveau des accès disques, mais pas sur une période de plus de 15 minutes.
    Ceci étant, 1 heure après, voici le comportement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    SQL> select * from v$database;
    select * from v$database
                  *
    ERROR at line 1:
    ORA-00210: cannot open the specified controlfile
    ORA-00202: controlfile: '/oradata/toto/control01.ctl'
    ORA-27041: unable to open file
    SVR4 Error: 2: No such file or directory
    Additional information: 3
     
     
    SQL> alter system switch logfile;
     
    System altered.

  8. #8
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Je n'ai pas dit dans 15mn que la base tombe, j'ai dit simplement qu'elle va essayer d'acceder au fichier de contrôle.

    Pour moi , ca peut venir que du cache système.

    demain je testerai sur d'autres OS.

  9. #9
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Oui, mais voici la chronologie :
    • t0 : suppression de tous les controlfiles
    • t0 + 1 minute : interrogation de v$database et switches => OK
    • t0 + 20 minutes : interrogation de v$database et switches => Ok
    • t0 + 1 heure : interrogation de v$database KO mais switches OK


    Donc, à minima, ça voudrait dire que j'ai 15 minutes dans les buffers OS... j'y crois pas !
    et de toute façon, une heure après, je ne devrais plus switcher !!!

  10. #10
    Membre éprouvé
    Inscrit en
    Avril 2006
    Messages
    1 024
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 1 024
    Points : 1 294
    Points
    1 294
    Par défaut
    Si il est possible sous certains système que la supression d'un fichier ouvert par ailleurs ne le supprime que du catalogue mais a toujours sa place réservée sur le disque. Ca se voit quand tu supprimes certains gros fichiers ouvert par un programme et que tu fait un "df" derrière, tu constates que la place n'est pas libérée... je ne sais pas exactement comment est programmé oracle mais si le buffer-fichier est maintenu ouvert, le programme doit avoir l'illusion que le fichier est encore présent lors du switch, par contre pour une autre commande qui doit ouvrir ce meme fichier une nouvelle fois (select from v$database) là il se rend compte qu'il a disparu du catalogue unix.

  11. #11
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Je suis d'accord, quand tu supprimes un fichier maintenu ouvert par un autre programme, la place n'est libéré sur disque qu'à la libération du fichier.
    exemple :
    shell 1 qui fait un tail -f sur l'alert.log
    shell 2 qui fait un rm de alert.log
    la place libérée par le rm n'est pas libérée tant que le tail -f tourne (différence de résultats entre df et du)

    mais là, il ne s'agit pas de ça !
    le fichier est supprimé, ça c'est indiscutable. Et je réalise des opérations qui impliquent forcément d'écrire dans le fichier (du moins, c'était la théorie) et ces opérations d'écriture dans un fichier absent ne semblent poser aucun problème à Oracle.

    le cache OS, j'y crois pas, sinon, le strings devrait réussir lui-aussi :
    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
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    SQL> select * from v$controlfile;
     
    STATUS
    -------
    NAME
    --------------------------------------------------------------------------------
     
    /oradata/toto/control01.ctl
     
     
    /oradata/toto/control02.ctl
     
     
    SQL> !rm /oradata/toto/control01.ctl /oradata/toto/control02.ctl
     
    SQL> !strings /oradata/toto/control02.ctl
    /oradata/toto/control02.ctl: No such file or directory
     
    SQL> alter system switch logfile;
     
    System altered.
     
    SQL> alter system checkpoint;
     
    System altered.
     
    SQL> select name from v$database;
     
    NAME
    ---------
    TEST
     
    SQL> select count(*) from v$datafile;
     
      COUNT(*)
    ----------
             5
     
    SQL> select * from v$controlfile;
     
    STATUS
    -------
    NAME
    --------------------------------------------------------------------------------
     
    /oradata/toto/control01.ctl
     
     
    /oradata/toto/control02.ctl

  12. #12
    Membre éprouvé
    Inscrit en
    Avril 2006
    Messages
    1 024
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 1 024
    Points : 1 294
    Points
    1 294
    Par défaut
    ce n'est pas vraiment un contre-exemple de ce que je disais puisque lorsque tu fais le "string", c'est un nouveau programme qui initie un nouveau file-descriptor et qui va donc regarder dans le catalogue unix.

    Pour en avoir le coeur net c'est un petit programme en C qu'il faudrait faire (ou autre langage maitrisant bien les pointeurs de fichier)

    ça donnerais quelque chose du style:

    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
     
    ...
    FILE *fic;
     
    printf("etape 0\n");
    fic = fopen("/tmp/toto","w+t");
    printf("etape 1\n");
    fprintf(fic,"1iere ecriture\n");
    printf("etape 2\n");
    system("rm /tmp/toto");
    printf("etape 3\n");
    fprintf(fic,"2ieme ecriture\n");
    fflush(fic);
    fprintf("etape 4\n");
    fprintf(fic,"3ieme ecriture\n");
    printf("etape 5\n");
    Questions anexes:
    - n'y a-t-il pas quand meme quelques insultes dans le fichier alert quand tu fait les commandes oracle apres avoir supprimé les control-file?
    - As-tu essayé de faire un "ALTER SYSTEM FLUSH SHARED_POOL" ?

  13. #13
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Que le fichier soit maintenu ouvert ou pas ne change rien à sa suppression qui elle intervient, c'est sûr. Et le strings est significatif car si les données du control étaient dans le cache OS, le strings pourrait les exploiter, ce qui n'est pas le cas.

    Sinon, les infos de control ne sont pas dans les buffer cache ni dans la shared pool... et même si des infos y étaient (types buffer), un checkpoint / switch impose justement d'écrire dans les fichiers.
    je ne suis pas dans le cas où j'ai perdu un tablespace et où les blocks sont encore en buffer. Là, ce sont tous les control qui sont HS.

    Et non, rien dans l'alert.

    Vraiment, il s'en moque on dirait de ne pas trouver les control.

  14. #14
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Voici une simulation d'un fichier de contrôle corrompu : Fichier de Contrôle corrompu

    et vous pouvez testez vos connaissances sur les fichiers de contrôles : Quiz : Fichier de Contrôle

  15. #15
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    Citation Envoyé par bouyao
    Voici une simulation d'un fichier de contrôle corrompu : Fichier de Contrôle corrompu

    et vous pouvez testez vos connaissances sur les fichiers de contrôles : Quizz : Fichier de Contrôle
    sans vouloir te faire de la peine, en quoi ça explique le phénomène que je constate ?

  16. #16
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Comme ce thread concerne les fichiers de contrôle, j'ai ajouté quleques remarques.

    Avec un editeur Hexadecimal (ULTRAEDIT) j'ai modifier le fichier de contrôle CONTROL03.CTL ce qui simule une corruption.(base ouverte)
    Le fait de consulter le fichier de contrôle par la vue V$DATABASE ne cause aucun problème puisque, puisqu'Oracle consulte uniquement le premier fichier cité dans le paramètre CONTROL_FILES.
    Par contre le fait de faire un LOGSWITCH, oracle écrit dans tous les fichiers de contrôles, ce qui cause une erreur.
    A l fin j'ai montré comment remedier ce problème en copiant juste le fichier de contrôle 1 dans le fichier corrompu.

    et pour le fan un Quiz pour les fichiers de contrôle

  17. #17
    Membre éprouvé
    Inscrit en
    Avril 2006
    Messages
    1 024
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 1 024
    Points : 1 294
    Points
    1 294
    Par défaut
    Mais l'OS est radicalement différent... C'est vrai que le comportement signalé par LeoAnderson ressemble furieusement à un bug qui doit dépendre de l'interaction entre la gestion de fichier oracle et la gestiond de fichier de l'OS, s'il y a du temps à perdre il faudrait reproduire les meme manips sous windows pour voir si le comportement d'oracle est le même...

  18. #18
    Membre expert
    Avatar de LeoAnderson
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 2 938
    Points : 3 199
    Points
    3 199
    Par défaut
    oui, et .... ?

    ça n'explique simplement pourquoi le select sur v$database peut marcher si tu as le 1er ctl. Dans mon cas, je n'en ai plus aucun !

    Et de toute façon, je switche tranquillou-pépère sans controlfile, et ça, c'est une abberration à laquelle je n'ai pas vu le début d'une explication...

  19. #19
    Expert éminent sénior
    Avatar de SheikYerbouti
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    6 760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 6 760
    Points : 11 862
    Points
    11 862
    Par défaut
    Pourquoi ne pas simplement ouvrir un Service Request ?
    Rédacteur Oracle (Oracle ACE)
    Guide Oracle ,Guide PL/SQL, Guide Forms 9i/10g, Index de recherche
    Je ne réponds pas aux questions techniques par MP
    Blogs: Forms-PL/SQL-J2EE - Forms Java Beans

  20. #20
    Membre expert
    Avatar de bouyao
    Inscrit en
    Janvier 2005
    Messages
    1 778
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 1 778
    Points : 3 135
    Points
    3 135
    Par défaut
    Citation Envoyé par remi4444
    il faudrait reproduire les meme manips sous windows pour voir si le comportement d'oracle est le même...
    Ce n'est pas possible, puisque sous windows les fichiers de contrôles sont verrouilés par le système et on ne peut pas les supprimés.

    Ce qui m'intrigue moi aussi pourquoi sous 8i sa se plante et non pas sur la 9i/10g
    ce qui elimine la cache de l'OS.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 3 123 DernièreDernière

Discussions similaires

  1. Réponses: 4
    Dernier message: 26/09/2013, 14h56
  2. probleme avec les socket (comportement bizarre)
    Par yous18 dans le forum Réseau
    Réponses: 14
    Dernier message: 23/05/2011, 19h30
  3. perte de tous les outils d'administration
    Par gorgonite dans le forum Administration
    Réponses: 3
    Dernier message: 07/01/2008, 12h09
  4. Perte de tous les menus
    Par maudemma dans le forum Access
    Réponses: 3
    Dernier message: 15/02/2007, 10h47
  5. [TRANSAQ SQL] INSERT comportement bizarre avec les REAL
    Par argyronet dans le forum Langage SQL
    Réponses: 2
    Dernier message: 02/12/2005, 12h47

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