Discussion :

[madmaxou]

Bonjour tout le monde,

Lors d'un processus de sauvegarde d'Oracle (que je ne maitrise déjà pas bien ) nous avons du faire face à un étrange problème.

En gros, pour effectuer notre backup à froid, on arrête notre instance avec un shutdown immediate (de ce que j'ai pu lire ^^), puis on effectue un snapshot (sur notre netapp), et pour finir on relance la base.

Le hic, c'est que j'ai ça comme Logs :
(udump)

Mon Apr 20 01:19:42 2009
Shutting down instance: further logons disabled
Shutting down instance (immediate) ==> Effet du script de backup, base en shutdown immediate, semble OK ??
License high water mark = 35
Mon Apr 20 01:19:45 2009
ALTER DATABASE CLOSE NORMAL
Mon Apr 20 01:19:46 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Mon Apr 20 01:19:46 2009
Shutting down archive processes
Archiving is disabled
Mon Apr 20 01:19:46 2009
ARCH shutting down
ARC1: Archival stopped
Mon Apr 20 01:19:46 2009
ARCH shutting down
Mon Apr 20 01:19:46 2009
ARC0: Archival stopped
Mon Apr 20 01:19:46 2009
Thread 1 closed at log sequence 10668
Successful close of redo thread 1.
Mon Apr 20 01:19:46 2009
Completed: ALTER DATABASE CLOSE NORMAL
Mon Apr 20 01:19:46 2009
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archiving is disabled
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active

Pourtant, voici les retours qu'on a dans nos traces de backup, en essayant de relancer l'instance après son "soit-disant" arrêt :

cannot start already-running ORACLE - shut it down first

Et effectivement, en se connectant en interactif, avec sqlplus pour tacher d'arrêter la base, on a pu constater que le shutdown était toujours en cours

Au final nous avons du prendre la décision de redémarrer le serveur, et oracle est reparti sans coup férir, mais je cherche un peu la cause.

Vous auriez des conseils/pistes à me donner sur le pourquoi de ça ? (je n'ai pas la prétention de remplacer un vrai administrateur oracle, juste tenter d'expliquer aux supérieurs, pourquoi ça a planté )

[fatsora]

Bonjour,

Quand vous arretez une base, il faut attendre qu'Oracle rende la main ...

Si vous faites

Code :

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

ps -e |grep pmon sous unix

ou dans Task Manager Si vous voyez "oracle" c'est que la "bete n'est pas morte" !!!!

C'est pour ca que vous voyez l'erreur .... au demarrage

[pifor]

Sous Windows, le service OracleService<SID> peut être démarré sans que l'instance en elle-même soit démarrée. Si le service est démarré, l'exécutable oracle.exe est là. Exemple avec XE sur Windows XP:

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
C:\>pslist | findstr oracle
 
pslist v1.28 - Sysinternals PsList
Copyright ® 2000-2004 Mark Russinovich
Sysinternals
 
oracle             3196   8   4   64   4860     0:00:00.218     0:00:40.186
 
C:>sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.1.0 - Production on Lun. Avr. 20 17:55:09 2009
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
Connecté à une instance inactive.
 
SQL>

[pifor]

Avec:

Completed: ALTER DATABASE CLOSE NORMAL
Mon Apr 20 01:19:46 2009
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT

J'ai du mal à croire que l'instance n'était pas arrêtée. Peut-être qu'elle était déjà démarrée par un autre script ? Quelle version d'Oracle (avec 4 chiffres) utilisez-vous ?

On peut aussi éviter d'arrêter l'instance pour sauvegarder la base si la base en mode ARCHIVELOG càd faire des sauvegardes à chaud. Ou faire un arrêt rapide et propre avec:

Code :

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

1
2
3
4
 
shutdown abort
startup
shutdown immediate

[pachot]

Bonjour,

Code :

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

1
2
3
4
 
shutdown abort
startup
shutdown immediate

Je rajouterai bien un 'alter system checkpoint' avant le 'shutdown abort' pour éviter un recovery trop long au startup
Et plutot un 'startup restrict' pour éviter de nouvelles connexions, ou des jobs qui démarrent.

Cordialement,
Franck.

[fatsora]

Bonjour,

Peux tu nous envoyer les commandes (scripts) que tu a lancées ?

Quel OS tu as et quelle version exacte d'Oracle ?

[madmaxou]

Bonjour,

Merci à tous de vos réponses, quelques détails sur l'environnement (que j'aurai pu penser à indiquer directement, c'est sur ) :

OS : Solaris 5.8
Oracle (SELECT * FROM v$version )
BANNER
----------------------------------------------------------------
Oracle9i Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

Pour les commandes, c'est un shutdown immediate qui est envoyé, théoriquement la base est ensuite censée être redémarrée avec une commande type startup mount.

Mais effectivement, les processus oracle tournaient toujours au moment où nous avons détecté le problème, cependant en entrant la commande shutdown immediate en interactif, nous obtenions un message indiquant que la base était déjà en train de se fermer, et inversement en essayant de la lancer avec un startup mount, un message renvoyait que la base était déjà démarrée

[fatsora]

Mais effectivement, les processus oracle tournaient toujours au moment où nous avons détecté le problème, cependant en entrant la commande shutdown immediate en interactif, nous obtenions un message indiquant que la base était déjà en train de se fermer, et inversement en essayant de la lancer avec un startup mount, un message renvoyait que la base était déjà démarrée

Effectivement ...

Un message d'erreur apparait si on essie d'eteindre alors qu'on autre processus de shut est deja en cours

Pareil si on essaie de demarrer alors que la base n'est pas entierement arretée.

Dans ce cas la effectivement pour résoudre rapidement , au lieu de relancer tout l'OS,
faire un shut abort peut resoudre ....

D'ailleurs,

Voici ce que dit la doc officiele d'oracle la dessus

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
 
Shutting Down with the ABORT Clause
 
You can shut down a database instantaneously by aborting the database instance. If possible, perform this type of shutdown only in the following situations:
 
The database or one of its applications is functioning irregularly and none of the other types of shutdown works.
 
    *
 
      You need to shut down the database instantaneously (for example, if you know a power shutdown is going to occur in one minute).
    *
 
      You experience problems when starting a database instance.
 
When you must do a database shutdown by aborting transactions and user connections, issue the SHUTDOWN command with the ABORT clause:
 
SHUTDOWN ABORT
 
 
An aborted database shutdown proceeds with the following conditions:
 
    *
 
      No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
    *
 
      Current client SQL statements being processed by Oracle Database are immediately terminated.
    *
 
      Uncommitted transactions are not rolled back.
    *
 
      Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.
 
The next startup of the database will require instance recovery procedures

Pour ta version 9.2.0.4

Voici des bug , parmi d'autres liés au SHUT ABORT

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Subject: 	Bug 4147870 - Dump possible (in kjccdel) during shutdown or process abort
  	Doc ID: 	4147870.8
 
 
  	Subject: 	Job Queue Won't Run Jobs Automatically After Aborting A Shutdown
  	Doc ID: 	342805.1
 
  	Oracle Server - Standard Edition - Version:
This problem can occur on any platform.

et
au SHUT IMMEDIATE



Database Shutdown Immediate Takes Forever, Can Only Do Shutdown Abort
Doc ID: 332177.1 Type: PROBLEM
Modified Date: 21-NOV-2005


Si ca persiste .... i.e le shut immediate est long ...tres long

envisager peut etre au moins de patcher oracle ou de passer a 10G -11G , mais c'est un autre débat .... car apperemment cette version 9.2.0.4 est assez buggée ....(pas seulement sur le shutdown !!)

[pachot]

Bonjour,

Est-ce qu'il y a dans l'alert.log quelque chose comme ça:

Active Call for Process ... user ... Program ...
shutdown: waiting for active calls to complete

C'est signe d'une connexion restée bloquée.

Cordialement,
Franck.

[madmaxou]

Bonjour Franck,

Non je n'ai pas remarqué une chaine ressemblant dans les logs de traces. Une autre piste que nous suivons a peut-être été l'impossibilité pour le serveur de forker l'un des processus Oracle.

Effectivement, nous savons que la 9.2.0.4 est assez buggée mais pour l'instant aucun plan de migration n'a été étudié/lancé/validé/planifié, il faudra donc que l'on compose avec

Ce problème n'est heureusement pas tellement récurent, mais je pense effectivement que s'il venait à se reproduire trop régulièrement, la solution du shutdown abort me semble la plus opportune.

La cause racine me semble assez difficile à trouver en fin de compte

[orafrance]

envisager peut etre au moins de patcher oracle ou de passer a 10G -11G , mais c'est un autre débat .... car apperemment cette version 9.2.0.4 est assez buggée ....(pas seulement sur le shutdown !!)

Là tu parles de migration... il peut déjà envisager de passer le dernier patchset

[fatsora]

Là tu parles de migration... il peut déjà envisager de passer le dernier patchset

a madmaxou,

tu peux deja patcher .... en attendant le grand saut vers l'inconnu (11G)

[madmaxou]

Ce n'est pas une mauvaise idée, il faudrait insérer ce patching après nos procédures d'arrêt des bases, le problème étant que cela se déroule à 1h du matin et uniquement une fois par semaine pour minimiser les impacts, donc à moins d'être sur à 100% qu'une procédure automatique de patch se déploiera avec succès, il faudra quelqu'un pour driver et là... ça risque d'être compliqué ^^

Pour un patch à chaud, sachant que ce sont des données/bases de production je suis sur à 99,99% qu'une proposition de patching en fonctionnement ne passera pas, même si on assure que l'opération est transparente et n'empêche pas le bon fonctionnement des bases (est-ce seulement le cas ?)

Merci en tous cas de votre aide et de vos suggestions

[orafrance]

Tu peux prendre un presta pour faire la manip à 1h si vraiment tu ne veux pas t'y coller

[fatsora]

Ce n'est pas une mauvaise idée, il faudrait insérer ce patching après nos procédures d'arrêt des bases, le problème étant que cela se déroule à 1h du matin et uniquement une fois par semaine pour minimiser les impacts, donc à moins d'être sur à 100% qu'une procédure automatique de patch se déploiera avec succès, il faudra quelqu'un pour driver et là... ça risque d'être compliqué ^^

Pour un patch à chaud, sachant que ce sont des données/bases de production je suis sur à 99,99% qu'une proposition de patching en fonctionnement ne passera pas, même si on assure que l'opération est transparente et n'empêche pas le bon fonctionnement des bases (est-ce seulement le cas ?)

Merci en tous cas de votre aide et de vos suggestions

Ce n'est pas aussi simple appliquer un patch



Voici ce que dit la Doc de PATCh 11G (valable en 9I aussi !)


Oracle recommends that you create a backup of the Oracle Inventory,
Oracle 11g home and Oracle 11g Database before you install the patch set.
If you are planning to apply this patch to Oracle RAC, ensure that you create a backup of these components on all nodes before applying the patch


Si en plus tu as une base de test ... autant tester les commandes.

Apparemment tu as une proposition d'aide pour le patch