[Oracle 10g]Trou dans les séquences des redo logs

Version imprimable

06/11/2008, 14h03
Christophe P.

[Oracle 10g]Trou dans les séquences des redo logs

Un script pl/sql ne fournit pas toujours les mêmes données sur la même base, certaines données manquent (mais pas toujours les mêmes). En lançant le script sur une petite partie des données rien ne manque. Aucune erreur n'est remontée.

Voici un extrait du fichier alert.log :

Citation:

Wed Nov 5 11:53:41 2008
Thread 1 advanced to log sequence 521
Current log# 1 seq# 521 mem# 0: /base/redo01.log
Wed Nov 5 11:56:40 2008
Thread 1 advanced to Wed Nov 5 14:39:19 2008
Thread 1 advanced to log sequence 580
Current log# 3 seq# 580 mem# 0: /base/redo03.log

Avant et après cet extrait, les séquences se suivent mais à cet endroit il y a un trou (passage de 521 à 580). Savez-vous ce que cela signifie ? Cela peut-il être lié à mon problème ?
06/11/2008, 14h37
salim11

Salut,

Peux-tu poster ton script ?
06/11/2008, 14h40
Christophe P.

Citation:

Envoyé par salim11

Salut,

Peux-tu poster ton script ?

Non, je ne suis pas sûr d'en avoir le droit et 3000 lignes c'est peut-être beaucoup.
06/11/2008, 14h49
salim11

Citation:

Envoyé par Christophe P.

Non, je ne suis pas sûr d'en avoir le droit et 3000 lignes c'est peut-être beaucoup.

Les données sont confidentielles oui je comprends mais le code ?????
06/11/2008, 14h51
plaineR

Il n'y a rien d'étonnant à ce qu'il y ait des trous dans la numérotation des séquences.

Un post là dessus :
http://www.developpez.net/forums/d23...quence-oracle/
06/11/2008, 14h56
Pomalaix

Citation:

Envoyé par plaineR

Il n'y a rien d'étonnant à ce qu'il y ait des trous dans la numérotation des séquences.

Un post là dessus :
http://www.developpez.net/forums/d23...quence-oracle/

Euh, rien à voir, notre ami parle de trous dans la séquence des redo logs !!!
06/11/2008, 15h01
plaineR

:oops: J'ai lu trop vite... A ma décharge, le titre porte à confusion :aie:
06/11/2008, 15h40
Christophe P.

Citation:

Envoyé par plaineR

:oops: J'ai lu trop vite... A ma décharge, le titre porte à confusion :aie:

Je corrige le titre.
06/11/2008, 15h48
Christophe P.

Citation:

Envoyé par salim11

Les données sont confidentielles oui je comprends mais le code ?????

Je vais me renseigner mais je ne vois pas l'intérêt de poster 4145 lignes de codes (j'ai vu petit dans le poste précédent) sans compter les appels aux fonctions d'autres packages. Je ne suis pas sûr que beaucoup de monde le regarde. Et un code peut tout à fait être confidentiel.
07/11/2008, 10h33
Christophe P.

Celui qui m'a passé les infos vient de me signaler que le trou ne s'est pas passé en même temps que le problème de données... mais si vous avez des explications sur ce trou des séquences des redo.log je suis preneur.
07/11/2008, 13h43
13thFloor

Peux-tu au moins indiquer la vue utilisée pour vérifier les séquences des redo ?
Ou mieux, la commande sql (il ne doit pas y en avoir des tonnes parmi les 4000 lignes).
07/11/2008, 20h13
bouyao

Citation:

Wed Nov 5 11:53:41 2008
Thread 1 advanced to log sequence 521
Current log# 1 seq# 521 mem# 0: /base/redo01.log
Wed Nov 5 11:56:40 2008
Thread 1 advanced to Wed Nov 5 14:39:19 2008
Thread 1 advanced to log sequence 580
Current log# 3 seq# 580 mem# 0: /base/redo03.log

Il y a une anomalie dans ta requête.
Il y a 2h30 entre la sequence 521 et 580.
On ne voit pas le log#2

Et en plus la requête qui fait 3000 lignes pour afficher ca, c'est un peu exagéré. Un seul ligne ca suffit pour ca.

D'après le resultat de ta requête , ce sont que des lignes du fichier alert<SID>.log.

sous unix il suffit de faire un cat alert<SID>.log et sous windows un type alert<SID>.log