Discussion :

[frp31]

Bonjour,

en suivant une procedure visant à copier une base dans une autre en la reconstruisant co,pletement :

J'ai (enfin je suppose que c'est ça, j'en suis pas sur), virer les fichier de la base avant la fin du shutdown de la base.

du coup ma procedure de copie échoué et bien sur je me suis dit je peut la reconstruire c'est pas grave....

mais lors de la procédure de construction je dois pour pouvoir créer mes datafiles etc....
me connecter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
svrmgrl 
connect system/XXXXX
 
ORA-01089 : immediate shutdown on progess - no operations are permitted
quit

et du coup je peux pas le reconstruire...
comment je peux m'en sortir ? SVP.

merci

[noumian]

Attends un moment et tu pourras te connecter a ta base, mais si tes datafiles ne sont pas presents, tu ne pourras pas demarrer ta bases.
pour cela il te faudra soit remettre les datafiles a leur places, soir les restaurer a partir d'une sauvegarde.
j'espere que j'ai repondu a ta question,si non precise la))

[frp31]

les fichiers ne sont pas présents effectivement, puisque je les ai supprimé trop tot

mais le shutdown ne fini pas (puisqu'il est detecté par le svrmgr)
mais il n'y a plus de process svrmgr actuellement
donc il ne finira "jamais"
j'ai testé de restaurer pour voir si il allait finir un jour ou non.
mais pour l'instant pas résultats...

en fait le shutdown est bien planté lui aussi



ça c'est de la bourde number one je crois que la seule façon de m'en sortir est faire croire à oracle que le shutdown à bien fonctionné ( et qu'il n'y en a pas en cours donc), ET que la base n'est pas démarrée, mais comment faire ?

[scheu]

Au pire fait un shutdown abort pour arrêter la base, puis un startup, et là tu verras selon le message si une restauration des datafiles est nécessaire

[frp31]

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
> shutdown abort
base arretee
[....] restauration et demarrage automatique
# je fait un shudown pour faire une copie à froid des fichier 
> shutdown immediate
base arretee
>quit
Serveur manager termine
[...] le log de restauration du backup me dit : ok....
$svrmgrl
> connect internal
connecte
> startup 
Instance Oracle demarre
#blabla SGA 
$
$sleep 1200 && svrmgrl
> connect
connecte
> connect system/manager
shutown in progress no operations are permitted
> quit
$

là ce sera plus clair comme le montre ce bout de log
le shutdown n'est jamais terminé
quoi qu'il arrive
(même après avoir effacé les dbf ! suite à une restauration complete de la base puis au demarrage et à l'arret de celle ci)
C'est donc un ancien shutdown qui est persistant. et pas le shutdown que je lance depuis une heure > à 12h30 mais celui d'une session svrmgrl précédente


PS: pour info actuellement
restauer puis demarrer ne demarre pas vraiment
il s'arrete juste avant le niveau alter database nomount pour toute la periode du diagnostic.

[Milo59000]

Pourquoi ne pas tuer la session au niveau de l'OS qui effectue l'opération non désirée ?

[frp31]

la session svrmgrl est déjà tuée en fait j'ai oublié de le préciser.

il n'y a pas d'autres sessions svrmgrl que la mienne sur la machine

[frp31]

final de l'histoire,

on a trouve ce qui s'est passe,
c'est simple et pas de bol a la fois.


j'ai lance le shutdown (le premier) sans faire gaffe a l'horraire et pas de bol un backup fichier est passe au meme moment et a plante de son cote en cassant les fichiers ouverts dans le repertoire du processus svrmgrl et surtout $ORACLE_HOME/dbs/initBASEA.ora qui apres faisait une taille de zero

ce qui a pour effet lorsque je copie une autre base vers BASEA il n'arrive pas a executer la
procedure "create controle file " puisque le init est vide et donc sans references de construction




en clair c'est pas une erreur oracle ni de methode de copie du tout.

en reecrivant un init.ora pour BASEA puis copier les .dbf puis monter la base et etc... a suffit a enfin copier la base de prod dans une base de test pour faire joujou