Discussion :

[Maraudeur]

Bonjour à tous
J'ai un serveur Oracle 9.2.05 sur un windows 2000 server et depuis quelques temps, un "plantage bizarre" survient. En fait, au jour J tout marche bien, les utilisateurs se connectent, travaillent sur la base sans problème. A J+1, quand les utilisateurs veuilent se connecter, impossible, même en étant physiquement sur le serveur, impossible de se connecter à la base, que ce soit avec l'appli ou avec Enterprise Manager console. Le seul "remède" que j'ai trouvé pour le moment est le reboot du serveur, mais en ce moment, j'en ai un peu marre de rebooter le serveur tous les matins.
Quelqu'un aurait une idée?
D'avance merci

[Milo59000]

Bonjour,

Peux-tu nous spécifier l'erreur que tu reçois lorsque tu essaies de te connecter ?

[Maraudeur]

Effet Bonaldi oblige, il a suffit que je poste un message pour demander de l'aide que le problème ne se présente plus. Avant, j'avais une coupure de connexion tous les deux jours et voila bientôt une semaine que tout fonctionne bien. M'enfin, je posterai le message d'erreur dès que je le verrai.

[Maraudeur]

Salut,
Après un bon moment sans problèmes, voici enfin un plantage.
L'application a planté chez un user et la base c'est arrêtée. Je me suis loggé en tant que system / SYSDBA (en tant que system tout court, il m'a jeté) et quand j'ai voulu redémarrer la base il m'a sortit le message : ORA-01031 : insufficient privileges.
J'ai dû rebooter pour permettre aux users de continuer à travailler.

Des idées?

[philcero]

Je ne comprends pas bien ton terme de "plantage". Peux-tu être plus précis en spécifiant l'état exact de la machine et de la base au moment de ce phénomène.

Y a t'il encore des processus Oracle en mémoire ?
Ton listener est-il là ?
Quelle est ton architecture applicative (2 ou 3 tiers) ?
Quelles sont les dernières entrées des fichiers ALERT_XXX.LOG et LISTENER.LOG ?

[Maraudeur]

quand je dis plantage pour l'application user, tout ce que je sais, c'est que l'application c'est fermée.
quand j'ai voulu me connecter sur la base via l'Enterprise Manager Console en tant que user SYSTEM, j'ai eu comme réponse que la base était arrêtée et que je devais me connecter en tant que SYSDBA, chose que j'ai faite. Une fois connecté, j'ai été sur l'instance (il n'y en a qu'une sur ce serveur) et j'ai voulula démarrer et c'est là que j'ai eu le message d'erreur comme quoi je n'avais pas assez de privilèges.
Tous les proccess Oracle étaient encore présent et running,
Listenner??? Je ne savais pas qu'il y en avais un ni où le trouver.

Concernant la question sur l'architecture 2 ou 3 tiers, aucune idée. Je ne comprends pas ta question. Pour ce que je sais, le serveur Oracle fait tourner une instance, que l'on appelle à partir des Pc des users via une application et un client oracle installé en local.
Au passage, la base est hostée sur un SAN.

Voici les entrées du alert_orafer.log au moment du crash :
Wed Apr 30 08:02:33 2008
Thread 1 advanced to log sequence 5339
Current log# 1 seq# 5339 mem# 0: D:\ORACLE\ORADATA\ORAFER\REDO01.LOG
Wed Apr 30 08:45:13 2008
Errors in file d:\oracle\admin\orafer\bdump\orafer_lgwr_1620.trc:
ORA-00345: redo log write error block 110333 count 38
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\ORAFER\REDO01.LOG'
ORA-27072: skgfdisp: I/O error
OSD-04008: WriteFile() failure, unable to write to file
O/S-Error: (OS 112) There is not enough space on the disk.

Wed Apr 30 08:45:14 2008
Errors in file d:\oracle\admin\orafer\bdump\orafer_lgwr_1620.trc:
ORA-00340: IO error processing online log 1 of thread 1
ORA-00345: redo log write error block 110333 count 38
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\ORAFER\REDO01.LOG'
ORA-27072: skgfdisp: I/O error
OSD-04008: WriteFile() failure, unable to write to file
O/S-Error: (OS 112) There is not enough space on the disk.

LGWR: terminating instance due to error 340
Instance terminated by LGWR, pid = 1620
Dump file d:\oracle\admin\orafer\bdump\alert_orafer.log
Wed Apr 30 08:58:03 2008
ORACLE V9.2.0.5.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Wed Apr 30 08:58:03 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.5.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 159383552
sga_max_size = 403775716
large_pool_size = 33554432
java_pool_size = 83886080
control_files = D:\oracle\oradata\ORAFER\CONTROL01.CTL, D:\oracle\oradata\ORAFER\CONTROL02.CTL, D:\oracle\oradata\ORAFER\CONTROL03.CTL
db_block_size = 8192
db_cache_size = 109051904
compatible = 9.2.0.0.0
db_file_multiblock_read_count= 32
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = ORAFER
dispatchers = (PROTOCOL=TCP) (SERVICE=ORAFERXDB)
utl_file_dir = *
job_queue_processes = 10
hash_join_enabled = TRUE
hash_area_size = 1048576
background_dump_dest = D:\oracle\admin\ORAFER\bdump
user_dump_dest = D:\oracle\admin\ORAFER\udump
core_dump_dest = D:\oracle\admin\ORAFER\cdump
sort_area_size = 1048576
db_name = ORAFER
open_cursors = 300
star_transformation_enabled= TRUE
query_rewrite_enabled = TRUE
pga_aggregate_target = 104857600
aq_tm_processes = 1
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
CJQ0 started with pid=8
QMN0 started with pid=9
Wed Apr 30 08:58:05 2008
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Wed Apr 30 08:58:06 2008
alter database mount exclusive
Wed Apr 30 08:58:10 2008
Successful mount of redo thread 1, with mount id 2449148190
Wed Apr 30 08:58:10 2008
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Wed Apr 30 08:58:10 2008
alter database open
Wed Apr 30 08:58:19 2008
Beginning crash recovery of 1 threads
Wed Apr 30 08:58:19 2008
Started redo scan
Wed Apr 30 08:58:22 2008
Completed redo scan
89309 redo blocks read, 251 data blocks need recovery
Wed Apr 30 08:58:24 2008
Started recovery at
Thread 1: logseq 5339, block 21024, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 1 Seq 5339 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORAFER\REDO01.LOG
Wed Apr 30 08:58:26 2008
Completed redo application
Wed Apr 30 08:58:27 2008
Ended recovery at
Thread 1: logseq 5339, block 110333, scn 0.486882819
251 data blocks read, 251 data blocks written, 89309 redo blocks read
Crash recovery completed successfully
Wed Apr 30 08:58:27 2008
Thread 1 advanced to log sequence 5340
Thread 1 opened at log sequence 5340
Current log# 2 seq# 5340 mem# 0: D:\ORACLE\ORADATA\ORAFER\REDO02.LOG
Successful open of redo thread 1
Wed Apr 30 08:58:27 2008
SMON: enabling cache recovery
Wed Apr 30 08:58:28 2008
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Wed Apr 30 08:58:28 2008
SMON: enabling tx recovery
Wed Apr 30 08:58:31 2008
Database Characterset is WE8MSWIN1252
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open

Des erreurs d'espace disque sont notées, pourtant il reste presque 8 Go de libre.

Voici les entrées du listener.log au moment du crash :

30-APR-2008 08:54:56 * (CONNECT_DATA=(SID=orafer)(SERVER=DEDICATED)(CID=(PROGRAM=C:\Program Files\Oracle\jre\1.1.8\bin\jrew.exe)(HOST=PXxxx)(USER=xxxx))) * (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xx.xx.xx)(PORT=4756)) * establish * orafer * 0

TNSLSNR for 32-bit Windows: Version 9.2.0.5.0 - Production on 30-APR-2008 08:57:51

Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved.

System parameter file is D:\oracle\ora92\network\admin\listener.ora
Log messages written to D:\oracle\ora92\network\log\listener.log
Trace information written to D:\oracle\ora92\network\trace\listener.trc
Trace level is currently 0

Started with pid=892
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC0ipc)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xxxx)(PORT=1521)))

TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT [* SID] * RETURN CODE
30-APR-2008 08:58:05 * service_register * ORAFER * 0
30-APR-2008 08:58:12 * service_update * ORAFER * 0
30-APR-2008 08:58:36 * service_update * ORAFER * 0
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=2100))(Presentation=FTP)(Session=RAW))
30-APR-2008 08:58:39 * service_update * ORAFER * 0
30-APR-2008 08:59:06 * service_update * ORAFER * 0
30-APR-2008 08:59:39 * service_update * ORAFER * 0
30-APR-2008 09:09:07 * (CONNECT_DATA=(SID=orafer)(SERVER=DEDICATED)(CID=(PROGRAM=C:\Program Files\Oracle\jre\1.1.8\bin\jrew.exe)(HOST=PXxxx)(USER=xxxx))) * (ADDRESS=(PROTOCOL=tcp)(HOST=xx.xx.xx.xx)(PORT=4833)) * establish * orafer * 0
30-APR-2008 09:09:39 * service_update * ORAFER * 0

Désolé, j'ai dû le censurer, j'ai supprimer les adresses IP, l'hostname ainsi que les identifiants personnels des users connectés.

[philcero]

Oups, ça craint

Va falloir trouver vite car jouer au yoyo crash/relance c'est pas bon pour les affaires ça...

Ta base s'arrête en mode panique pour les raisons suivantes (Faut lire les blocs de messages d'erreurs à l'envers) :
08h45m : O/S-Error: (OS 112) There is not enough space on the disk. --> ORA-00345: redo log write error block 110333 count 38 --> Bye bye la babase...

Ce qui m'étonne c'est qu'il y ait un redémarrage juste derrière (08h58m), est-ce toi à la mano ou bien une relance à la fin d'un backup qui n'aurait pas su arrêter la base avant (Thèse la plus plausible selon moi) ?

La perte de fonctionnement applicative semble logique car si ton client est connecté et que la base passe par un crash/relance, les sessions IP courantes sont cassées et la base reste dans un état visuel non joignable pour les applications qui ne savent pas se re-connecter à la base de données en cas d'indisponibilité.

En tout cas ton problème est avant tout SYSTEME et non Oracle.
Regarde côté serveur et SAN ce qui se passe dans ces heures là, pour ma part cela ressemble plus à une indisponibilité des espaces disques à l'heure H qu'à une saturation. Comme si tu avais un backup de ceux-ci pendant la nuit et qu'à la fin de celui-ci (Un peu avant 08h45m) il y avait une ré-initialisation qui justifierait le fait que le système ne voie plus rien pendant quelques secondes/minutes.

[Maraudeur]

salut

Le redémarrage que l'on voit, c'est bien moi qui fait un redémarrage à la mano.
Pour ce qui est des backups, ils sont toujours effectués le soir et durent à peu près une heure. Je ne pense pas que ce soit de ce côté où ça pose problème. Par contre, j'ai peur que ce ne soit du côté de la fibre qui relie le serveur au SAN. Mais je n'ai aucun log qui me disent qu'il y a eu une coupure. Il fut dire que je n'ai jamais testé la présence du volume lors d'un crash. A chaque fois, je suis passé par l'Enterprise Manager console qui me disait qu'il n'arrivait pas à ce connecté puis je rebootait le serveur.
Par contre, j'ai remarqué des erreurs dans l'event viewer concernant la carte fibre. Je vais upgrader les drivers et on verra.
Pour la prochaine déconnexion, je regarderai si c'est au moment des backups. Ces derniers ne sont faits que deux fois par mois. Oui, je sais, ce serveur n'est pas très utilisé .


Merci de ton aide.
Je mets ce post en tant que résolu, mais si j'ai plus d'infos, je viendrai les ajouter