shutdown immediate sans reponse?

Version imprimable

12/04/2007, 14h41
Mehdilis

shutdown immediate sans reponse?

J’ai une base de test(oracle 8I sous windows), j’ai fait un shutdown immediate , la base ne répond pas.
Voici le fichier d’alerte généré :

Thu Apr 12 12:20:14 2007
alter database backup controlfile to 'C:\Documents and Settings\SCHOPPE\control1.ctl' reuse

Thu Apr 12 13:16:01 2007
Starting ORACLE instance (normal)
Thu Apr 12 13:17:25 2007
alter database backup controlfile to trace

Completed: alter database backup controlfile to trace
Thu Apr 12 13:20:01 2007
Restarting dead background process EMN0
EMN0 started with pid=15

Thu Apr 12 13:20:12 2007
Shutting down instance (immediate)
License high water mark = 5Restarting dead background process EMN0
EMN0 started with pid=15
Thu Apr 12 13:20:12 2007
Shutting down instance (immediate)
License high water mark = 5

Pourriez vous svp me dire qoui faire ? pour la redemarrer et retablir la situation.

Merci d’avance de votre aide
12/04/2007, 14h47
bouyao
Soit tu attend 1 heure ou plus. Sinon tu fait
Code:

1 2 shutdown abort
et ca peut corrompre les fichiers redo en ligne.
12/04/2007, 15h16
LeoAnderson

Ne rien faire si ce n'est attendre !

Un shutdown immediate est un shutdown propre qui synchronise tous les fichiers, et effectue les rollbacks pour les transactions en cours.

Si il y en avait beaucoup et des très volumineuses, ça peut prendre du temps...

mais si vous faites un shutdown abort, certes la base sera arrêtée plus vite mais :
1. ça risque de corrompre la base (redo ou control)
2. Le temps évité au shutdown sera consommé au restart...
13/04/2007, 11h41
Mehdilis

Bonjour,
Merci pour vos conseils, le shutdown immdiate a mis du temps je pense a cause de la premiere sauvegarde de la base, mais le probléme est résolu exactement à ce que vous maviez dit.

Merci!!!!!!!!
13/04/2007, 11h51
orafrance

Citation:

Envoyé par LeoAnderson

1. ça risque de corrompre la base (redo ou control)
2. Le temps évité au shutdown sera consommé au restart...

1. je crois que c'est une idée reçue, en effet, le shutdown abort est garantie par Oracle, il n'y a aucun risque tant que les archives et/ou redo sont présent
2. sauf que le rollback n'empêche pas l'ouverture de la base, ça permet ainsi une moindre indispo ;)
13/04/2007, 13h37
LeoAnderson

1. C'est pas une légende, c'est du vécu !
Il avait commencé un checkpoint => certains fichiers étaient plus récents que les control => ils ne voulait pas démarrer en me disant que j'avais un controlfile trop vieux.
Depuis, je suis vacciné contre les shutdown aborts !

2. Sauf si tu dois restaurer (cf 1)
et le rollback se fait avant d'avoir ta base open (t'as jamais remarqué que parfois le open prenait bcp de temps ? ;) )
13/04/2007, 15h15
orafrance

1. ça se recréer les fichiers de contrôle ;)

2. C'est le media recovery qui bloque l'ouverture. Le rollback se fait en background, il plombe bien entendu les perfs mais n'empêche pas d'ouvrir la base. Nous arrêtons toutes les instances de cette manière pour éviter l'indispo justement ;)
13/04/2007, 19h20
LeoAnderson

ça vous sert à quoi d'arrêter les instances de façon crade ??? 8O
tu peux même pas t'en servir pour un backup....

c'est juste pour prendre en compte des paramètres non modifiables à chaud et vous faites simplement un "STARTUP FORCE" ?
13/04/2007, 19h38
orafrance

c'est pas crade, c'est ce que j'essaye de t'expliquer... c'est une préco d'Oracle pour Oracle Application par exemple et comme je l'ai dit, ça permet de faire une sauvegarde base arrêtée sans attendre l'arrêt pendant TRES longtemps parfois... et la base est parfaitement consistente, il faut juste bien sauvegarder les UNDO et REDO ;)
13/04/2007, 19h49
LeoAnderson

"sauvegarde consistente" ???
ça, sors moi la note metalink le disant !
je suis comme saint-thomas,sauf que j'ai vu que justement, ce n'était pas consistent...
13/04/2007, 19h58
pifor

Ce n'est pas une note Metalink, mais Tom Kyte lui-même dit que shutdown abort + sauvegarde à froid sont OK si on sauvegarde les redo logs.

Je n'ai pas trouvé de note Metalink ni de document officiel Oracle qui justifie cette pratique. Mais je n'ai pas trouvé non plus de référence de bug ou de contre-indication comme quoi shutdown abort peut casser les control files ou les redo logs.
13/04/2007, 20h20
orafrance

Citation:

Envoyé par LeoAnderson

"sauvegarde consistente" ???
ça, sors moi la note metalink le disant !
je suis comme saint-thomas,sauf que j'ai vu que justement, ce n'était pas consistent...

nous faisons tous nos clones de cette manière avec 5-6 clones par semaine, si ça devait ne pas fonctionner, je serais au courant je pense ;) (vu le nombre de bugs et problèmes rencontrés ça aurait été étonnant de passer à coté :mouarf: )

par contre, sans UNDO tu es mort puisque le rollback doit être fait au démarrage :?

Edit: au fait, j'ai fait un abus de langage, la base n'est pas consistente à l'arrêt mais le devient au démarrage... voila pourquoi je parle de sauvegarde consistente ;)
13/04/2007, 20h27
orafrance

Citation:

Envoyé par pifor

si on sauvegarde les redo logs.

Et le UNDO ou alors si tu es en archivelog il faut aussi les archivelogs pour faire une restore until cancel ;)
13/04/2007, 20h36
orafrance

Note : 1020192.6 :arrow: aucun problème pour le startup signalé par Oracle ;)

En tout cas, je m'engage personnellement et affirme qu'il n'y a aucun risque pourvu que la sauvegarde soit compléte, le shutdown immediate diminue le risque en cas de corruption de fichier lors de la sauvegarde ;)
13/04/2007, 20h45
orafrance

et aussi : http://hernk.wordpress.com/2007/02/1...%80%99-is-bad/

Je concluerai en conseillant malgré tout le shutdown immediate qui permet de s'assurer que le démarrage ne nécessitera aucune intervention humaine, le shutdown doit être réservé aux cas très particulier notamment la haute dispo avec une fenêtre d'indispo très serrée ;)
14/04/2007, 04h16
bouyao

Je confirme que le shutdown abort peut corrompre la base 8.1.7 . (estimation : 1/1000).
Histoire vecu, après un hutdown abort, un des fichiers redolog est corrompu.
14/04/2007, 09h01
LeoAnderson

Citation:

Envoyé par orafrance

Note : 1020192.6 :arrow: aucun problème pour le startup signalé par Oracle ;)

Voilà ce que dit justement la note : "This option should only be used as a last resort."
Comme argument en faveur du shutdown abort comme pratique normale et régulière, on fait mieux ! :lol:

Citation:

Envoyé par orafrance

En tout cas, je m'engage personnellement et affirme qu'il n'y a aucun risque pourvu que la sauvegarde soit compléte, le shutdown immediate diminue le risque en cas de corruption de fichier lors de la sauvegarde ;)

Bien sûr, et pour chaque bases plantées parce que des lecteurs auront lu ton engagement, tu vas aller personnellement et immédiatement les dépatouiller ? :roll:

Citation:

Envoyé par orafrance

et aussi : http://hernk.wordpress.com/2007/02/1...%80%99-is-bad/

Ce doc. recommande de faire un checkpoint avant, ce qui est effectivement la moindre des choses.... et ça, tu as complètement oublié d'en parler ! ;)

Citation:

Envoyé par orafrance

Je concluerai en conseillant malgré tout le shutdown immediate qui permet de s'assurer que le démarrage ne nécessitera aucune intervention humaine, le shutdown doit être réservé aux cas très particulier notamment la haute dispo avec une fenêtre d'indispo très serrée

Effectivement, s'il y a des contraintes opérationnelles critiques et qu'on n'a que 3 minutes le dimanche à 23h50 pour effectuer l'arrêt/relance, et vu la faible probabilité de survenue d'un problème, on peut prendre le risque, si on a les ressources humaines suffisantes et que les backups sont online.
Dans tous les autres cas, soit on n'arrête pas, soit on fait un shutdown immediate
14/04/2007, 14h01
orafrance

Citation:

Envoyé par bouyao

Je confirme que le shutdown abort peut corrompre la base 8.1.7 . (estimation : 1/1000).
Histoire vecu, après un hutdown abort, un des fichiers redolog est corrompu.

j'ai bien précisé depuis la 9i ;)

Et en archivelog tu n'as pas besoin des redo courant... tu restaures "juste" un peu plus dans le passé ;)
14/04/2007, 14h05
orafrance

Citation:

Envoyé par LeoAnderson

Bien sûr, et pour chaque bases plantées parce que des lecteurs auront lu ton engagement, tu vas aller personnellement et immédiatement les dépatouiller ? :roll:

Faut voir :)

Citation:

Envoyé par LeoAnderson

Ce doc. recommande de faire un checkpoint avant, ce qui est effectivement la moindre des choses.... et ça, tu as complètement oublié d'en parler ! ;)

Ca évite juste de devoir rejouer les archives ;)

Citation:

Envoyé par LeoAnderson

Effectivement, s'il y a des contraintes opérationnelles critiques et qu'on n'a que 3 minutes le dimanche à 23h50 pour effectuer l'arrêt/relance, et vu la faible probabilité de survenue d'un problème, on peut prendre le risque, si on a les ressources humaines suffisantes et que les backups sont online.
Dans tous les autres cas, soit on n'arrête pas, soit on fait un shutdown immediate

pour notre part, on fait des flash copy, ce qui permet une indispo de moins de 3 minutes ce qui est impossible de faire en immediate :? Comme je le disais, la contrainte impose se mode et si toutes les sauvegardes sont "parfaites" alors il n'y a plus de raison de s'en priver. En 10g c'est encore plus simple grace au flashback recovery ;)