Recover set until, sans sauvegarde [Résolu]

[Isabella]

Bonjour à tous

Mon problème est le suivant,
suite à un incident imprévu (arrêt du serveur), l'instance de ma bd ne redémarre plus,
en fait elle arrive à l'état "MOUNT" et s'arrète là, la raison est bien expliquée dans un message
error "ORA-01172" qui me fait signe de l'impossibilité de récupérer le bloc 2500 du fichier 2, sachant que fichier 2 correponds mon UNDO tablespace
si j'ai bien compris , il y a un bloc corrompu suite à l'arret anormal ,et que oracle n'arrive pas à récupérer
n'ayant pas de sauvegarde récente, j'ai cherché un moyen de pouvoir revenir à l'état normal de la base qui a précédé l'incident , le plus récent possible en vue d'un minimum de perte de données,

j'ai trouvé ça sur le net

Code :

1
2
 
RECOVER SET UNTIL <date>

en quoi est comment ça peut m'être utile?
sinon y a t il un autre moyen ?

Merci

[LeoAnderson]

AVANT DE FAIRE QUOIQUE CE SOIT, FAITES UNE SAUVEGARDE BASE ARRETEE DE LA BASE COMPLETE !

Bien maintenant que la sauvegarde est faite :
- la base est-elle en archive log ?
- quelle est la version ?
- quel serait l'impact d'une perte de la base ?

[Isabella]

- j'ai déjà fait une sauvegarde, en dur, c'est à dire pure et simple copie de fichiers (datafile, redologfile, controle_files) avec base et services arrétés, je ne sais pas s'il y a un autre procédé
- la version Oracle 9i /windows 2000 server
- impact d'une perte de la base !!!!???? c'est la cata
Merci

[LeoAnderson]

Envoyé par LeoAnderson

- la base est-elle en archive log ?

Code :

1
2
3
 
sqlplus "/ as sysdba"
SQL> archive log list

[orafrance]

tu peux déjà commencer simplement :
- RECOVER DATABASE

tu verras alors si les redos courant suffisent à rattraper le coup

Tu peux aussi te rassurer, le UNDO c'est pas le plus grave même si ça peut générer quelques pertes de transaction

[Isabella]

justement quand j'ai vu " ORA-01172" pour bloc ...file 2,
j'ai été voir dans v$datafile et quand j'ai trouvé qu'il s'agissait d'un UNDO j'ai pensé que c'était pas grave et que la pire des choses qui
pouvait m'arriver est la perte de données concernant les transactions qui étaient en cours
mais quand LEO a commencé à parler de "perte de base"
j'ai eu le vertige ...., bon bref

LEO : je suis en mode NOarchivelog

ORAfrance :
"RECOVER DATABASE" ? même si je n'ai aucune
sauvegarde ?
en tous cas
UNDO je suis prête en m'en passer ainsi que les
éventuelles données qui étaient en transaction mais
comment je peut faire démarrer ma base maintenant ?
y a t il un moyen, par exemple, de mettre UNDO
offline, pour démarrer la base puis le régénérer par
la suite,

[LeoAnderson]

pas de backup, no archivelog, le open qui échoue avec un fichier corrompu, ça part mal...

le open faisant un recover implicite si besoin, le recover datafile 2 a peu de chances de marcher...

pouvez-vous nous coller l'alert.log, du dernier switch avant le crash jusqu'au dernier message de la commande startup ?

[orafrance]

avec pas mal de chance, un recover database (ou datafile) se suffira des REDO courant... j'comprends pas que ça n'a pas déjà été tenté

[LeoAnderson]

Envoyé par orafrance

avec pas mal de chance, un recover database (ou datafile) se suffira des REDO courant... j'comprends pas que ça n'a pas déjà été tenté

le open ne s'en charge-t-il pas automatiquement ?

[Isabella]

Bonjour

Code :

1
2
3
 
Pas de backup, no archivelog, le open qui échoue avec un fichier corrompu, ça part mal... 
le open faisant un recover implicite si besoin, le recover datafile 2 a peu de chances de marcher...

ou je sais , c'est le chaos ...
mais bon, la seule chose qui me laisse une petite lueur d'espoir c'est que le fichier en question (datafile 2) est un UNDO , pas un fichier de donnée , je me dis peut être qu'il y a un moyen de le supprimer et d'en créer un nouveau (sachant toujours que mon instance ne dépasse pas l'état MOUNT) , c'est à dire le simple CREATE TABLESPACE ... ne marche pas

voilà une partie de mon Alert.log (concernant la jourée d'hier : Tue Jan 22)
voir vers la fin : RECOVERY OF THREAD 1 STUCK AT BLOCK 2599 OF FILE 2

Code :

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
 
Tue Jan 22 09:26:21 2008
ORACLE V9.2.0.1.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 3, CPU type 586
Tue Jan 22 09:26:21 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
USING log_archive_dest parameter DEFAULT value
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
Starting up ORACLE RDBMS Version: 9.2.0.1.0.
System parameters WITH non-DEFAULT VALUES:
  processes                = 150
  timed_statistics         = TRUE
  resource_limit           = TRUE
  shared_pool_size         = 50331648
  large_pool_size          = 67108864
  java_pool_size           = 0
  control_files            = D:\oracle\oradata\ORCL\control01.ctl, D:\oracle\oradata\ORCL\control02.ctl, D:\oracle\oradata\ORCL\control03.ctl
  db_block_size            = 8192
  db_cache_size            = 25165824
  compatible               = 9.2.0.0.0
  db_file_multiblock_read_count= 64
  fast_start_mttr_target   = 300
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_retention           = 10800
  remote_login_passwordfile= EXCLUSIVE
  db_domain                = 
  instance_name            = ORCL
  hash_join_enabled        = TRUE
  background_dump_dest     = D:\oracle\admin\ORCL\bdump
  user_dump_dest           = D:\oracle\admin\ORCL\udump
  core_dump_dest           = D:\oracle\admin\ORCL\cdump
  sort_area_size           = 2097152
  sort_area_retained_size  = 2097152
  db_name                  = ORCL
  open_cursors             = 300
  star_transformation_enabled= FALSE
  query_rewrite_enabled    = FALSE
  pga_aggregate_target     = 25165824
PMON started WITH pid=2
DBW0 started WITH pid=3
LGWR started WITH pid=4
CKPT started WITH pid=5
SMON started WITH pid=6
RECO started WITH pid=7
Tue Jan 22 09:26:40 2008
ALTER DATABASE mount exclusive 
Tue Jan 22 09:26:49 2008
Successful mount of redo thread 1, WITH mount id 1172399057.
Tue Jan 22 09:26:49 2008
DATABASE mounted IN Exclusive Mode.
Completed: ALTER DATABASE mount exclusive
Tue Jan 22 09:26:49 2008
ALTER DATABASE open
Tue Jan 22 09:26:52 2008
Beginning crash recovery of 1 threads
Tue Jan 22 09:26:53 2008
Started first pass scan
Tue Jan 22 09:26:54 2008
Completed first pass scan
 22765 redo blocks READ, 29 DATA blocks need recovery
Tue Jan 22 09:26:55 2008
Started recovery at
 Thread 1: logseq 1323, block 2, scn 0.63895025
Recovery of Online Redo Log: Thread 1 GROUP 3 Seq 1323 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG
RECOVERY OF THREAD 1 STUCK AT BLOCK 2599 OF FILE 2
ORA-1172 signalled during: ALTER DATABASE open...
Tue Jan 22 15:55:00 2008
Shutting down instance: further logons disabled
Shutting down instance (normal)
License high water mark = 2
Tue Jan 22 15:55:00 2008
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Tue Jan 22 15:55:00 2008
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archiving IS disabled
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active
ARCH: Archiving IS disabled
Shutting down archive processes
Archiving IS disabled
Archive process shutdown avoided: 0 active

Ora à dit :

Code :

1
2
 
avec pas mal de chance, un recover DATABASE (ou datafile) se suffira des REDO courant... j'comprends pas que ça n'a pas déjà été tenté

je n'ai pas encore tenté celà pour 2 raisons
1 - le message RECOVERY OF THREAD 1 STUCK AT BLOCK 2599 OF FILE 2, laisse croire que c'est déjà tenté par le système lui même
2- Jamais je n'ai utilisé RECOVERY, je ne sais pas comment ça fonctionne, est ce que je dois taper la commande : RECOVER DATABASE (ou DATAFILE) à partir de RAMAN , sqlplus, ... , base fermé, montée, ou non montée, ...
et si jamais ça ne marche , ça n'aggraverait pas la situation ?
j'ai peur de m'enfoncer davantage dans le pétrin !

Merci

[LeoAnderson]

oui, le système a déjà lancé la récupération automatique d'instance suite au crash, c'est ce que je craignais ..

Non, le fait que ce soit l'UNDO n'est pas rassurant. Les données des UNDO sont indispensables car elles n'ont pas forcément été écrites dans les fichier de données.

faites un coup de DBV sur le fichier d'undo...
et collez ici le résultat

[Pomalaix]

Bonjour

Avez-vous lu la discussion suivante, et en particulier ma réponse (N° 22 à la deuxième page) : http://www.developpez.net/forums/sho...d.php?t=271722

Ca vous permettra d'identifier si vous avez des segments UNDO réellement nécessaires.
Si par chance ils ne le sont pas, vous pourrez recréer un tablespace UNDO.

[orafrance]

Envoyé par LeoAnderson

le open ne s'en charge-t-il pas automatiquement ?

Pour se que je me rappelle des crashs de base, en cas de base inconsistante il ne fait pas un RECOVER explicite donc du coup il ne demande pas le chemin du REDO. Non ?

[LeoAnderson]

Envoyé par orafrance

Pour se que je me rappelle des crashs de base, en cas de base inconsistante il ne fait pas un RECOVER explicite donc du coup il ne demande pas le chemin du REDO. Non ?

ALTER DATABASE open
Tue Jan 22 09:26:52 2008
Beginning crash recovery of 1 threads
Tue Jan 22 09:26:53 2008
Started first pass scan

[orafrance]

oui mais il est pas capable de consolider tout seul avec les REDO plutôt que les archives logs si ?

[Isabella]

coup dbv ! c quoi ?

la perte du fichier UNDO entraine , au pire des cas, le modifs qui étaient en trancation , NON ?
si c'est le cas , pas de problème , je suis prête à assumer ce dégat minime connassaint la cadence et densité des applicatifs sur la base,
s'il y a un moyen de me débarasser de ce maudit fichier UNDO, faites vite de me le montrer SVP, je préfère ressaisir les données d'il y a 2 ou 3 jours plutot que de rester bloquée et livrée à l'incertain.

[Pomalaix]

Envoyé par Isabella

s'il y a un moyen de me débarasser de ce maudit fichier UNDO, faites vite de me le montrer SVP, je préfère ressaisir les données d'il y a 2 ou 3 jours plutot que de rester bloquée et livrée à l'incertain.

Comme disait l'autre :

Avez-vous lu la discussion suivante, et en particulier ma réponse (N° 22 à la deuxième page) : http://www.developpez.net/forums/sho...d.php?t=271722

Ca vous permettra d'identifier si vous avez des segments UNDO réellement nécessaires.
Si par chance ils ne le sont pas, vous pourrez recréer un tablespace UNDO.

[LeoAnderson]

si si, bien sûr

mais là, manifestement, c'est pas un problème de données présentes en redo qui n'ont pas été écrites dans les dbf mais de block corruption (d'où la question de faire un dbv)
mais savoir si les transactions sont encore nécessaires ou pas (excellente manip de Pomalaix à se noter dans un coin ! ) est utile pour la résolution.

[Isabella]

je reviens à ORA

Code :

1
2
 
avec pas mal de chance, un recover DATABASE (ou datafile) se suffira des REDO courant... j'comprends pas que ça n'a pas déjà été tenté

Après tout ce qui vient d'etre dit, je voudrais bien essayer RECOVER DATABASE
mais est ce que je ne perd toujours rien si je ne gagne rien ?

[LeoAnderson]

Envoyé par Pomalaix

Comme disait l'autre :
Avez-vous lu la discussion suivante, et en particulier ma réponse (N° 22 à la deuxième page) : http://www.developpez.net/forums/sho...d.php?t=271722

Ca vous permettra d'identifier si vous avez des segments UNDO réellement nécessaires.
Si par chance ils ne le sont pas, vous pourrez recréer un tablespace UNDO.