Discussion :

[PpPool]

Bonjour à tous,

Oracle 9i Release 9.2.0.1.0
OS : windows 2000 server

Sur un serveur web dont nous avons installé un noyau Oracle 9i il y a plusieurs mois, je viens de constater des problèmes très importants ce matin. j'aimerai bcq avoir votre avis sur ce problème :

Extrait du fichier Alert

Sun Feb 19 22:22:30 2006
found dead shared server 'S002', pid = (13, 5)
Sun Feb 19 22:24:37 2006
found dead shared server 'S002', pid = (13, 6)
Sun Feb 19 22:25:10 2006
found dead shared server 'S002', pid = (13, 7)
Sun Feb 19 22:40:22 2006
found dead shared server 'S004', pid = (14, 4)
Sun Feb 19 23:27:49 2006
Errors in file d:\oracle\admin\web\udump\web_s005_2716.trc:
ORA-00600: internal error code, arguments: [kghsscwrbuf_closed], [], [], [], [], [], [], []

dans les évents applications de windows, je constate que plusieurs fois le service OracleServiceWeb de mon instance s'est arreté.

Ce matin, je tente de le redémarrer :
1ère fois : crash : temps alloué trop long
2nde fois çà passe !! mais c'est très long !

J'arrive à me connecter avec SQL*Plus.

j'ai cherché sur Metalink des infos sur kghsscwrbuf_closed, mais nada, rien trouvé.

Ce serveur est un serveur de dév pour le moment, mais j'aimerai tout de même résoudre le pb.

Merci de vos conseils.

@

[bouyao]

Le mieu est de faire une mise à jours en 9.2.0.7
Sinon essaye de configurer ta base en serveur dedié au lieu en MTS.Si tu veut vraiement utiliser MTS il faut augmenter le paramètre : LARGE_POOL_SIZE

[PpPool]

Le mieu est de faire une mise à jours en 9.2.0.7
Sinon essaye de configurer ta base en serveur dedié au lieu en MTS.Si tu veut vraiement utiliser MTS il faut augmenter le paramètre : LARGE_POOL_SIZE

bonjour bouyao et merci de ton aide,

pourtant je suis bien en serveur dédié :

Fichier Tnsnames.ora

WEB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = aglae)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = WEB)
)
)

INST1_HTTP =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = aglae)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = SHARED)
(SERVICE_NAME = MODOSE)
(PRESENTATION = http://HRService)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)

je vais essayer de patcher : dois-je passer directement de la v9.2.0.1 à la 9.2.0.7, où passer par une version intermédiaire ?

Merci de ton aide

[bouyao]

Je pense que tu peut passer directement de la 9.2.0.1 vers la 9.2.0.7

[PpPool]

Je pense que tu peut passer directement de la 9.2.0.1 vers la 9.2.0.7

Sur le site Metalink, faut-il se référer à la partie Patches ou Updates.

car sur la partie Updates pas de version 9.2.0.7 !

[bouyao]

Tu prend le patch : 4163445 (228Mo)

[PpPool]

Tu prend le patch : 4163445 (228Mo)

merci encore de ton aide !

comment as tu trouvé ce n° de patch ?

[bouyao]

c'est sous metalink

[PpPool]

c'est sous metalink

tu vas surement me trouver nunuch

je suis bien sous Metalink, je suis en train de dowloader le patch

ce que je voudrai comprendre c'est comment obtenir le n° d'un patch pour une version donnée d'Oracle.
En fait, j'aimerai savoir comment tu as fait !

car soit, je suis pas encore remis de mon we , soit je suis complétement mirro, car au niveau de l'interface Metalink, j'ai pas trouvé !

encore désolé de poser des questions aussi idiotes

[bouyao]

Sous metalink, tu va dans l'option Patches & Updates
Dans Serach by tu selectionne Product or Family
et entre RDBMS
après tu choisi dans Release : Oracle 9.2.0.7
Dans Patch Type : Patchset/Minipack
Dans Platform or Language : Microsoft Windows (32-bit)

Après tu appuye sur Go
Et tu aura le patch : 4163445

[PpPool]

Sous metalink, tu va dans l'option Patches & Updates
Dans Serach by tu selectionne Product or Family
et entre RDBMS
après tu choisi dans Release : Oracle 9.2.0.7
Dans Patch Type : Patchset/Minipack
Dans Platform or Language : Microsoft Windows (32-bit)

Après tu appuye sur Go
Et tu aura le patch : 4163445

c'est le RDBMS que j'avais loupé !

J'abuse peut-etre, mais comme c'est la première fois, que je procéde à ce genre de manip :
-je vais arreter la database + les services oracle associés
-je vais lancer le RunInstaller
-je démarre la database + les services oracle associés

rien d'autres ?

Merci encore pour le coup de main

[bouyao]

Il faut surtout lire le fichier readme

[aline]

Bonjour,

Es-tu sur d'être en serveur dédié?

quand on voit ton erreur, on en doute beaucoup

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
Sun Feb 19 22:22:30 2006
found dead shared server 'S002', pid = (13, 5)
Sun Feb 19 22:24:37 2006
found dead shared server 'S002', pid = (13, 6)
Sun Feb 19 22:25:10 2006
found dead shared server 'S002', pid = (13, 7)
Sun Feb 19 22:40:22 2006
found dead shared server 'S004', pid = (14, 4)
Sun Feb 19 23:27:49 2006

peux tu nous donner les paramêtres de ton init.ora?

[PpPool]

Bonjour,

Es-tu sur d'être en serveur dédié?

quand on voit ton erreur, on en doute beaucoup

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
Sun Feb 19 22:22:30 2006
found dead shared server 'S002', pid = (13, 5)
Sun Feb 19 22:24:37 2006
found dead shared server 'S002', pid = (13, 6)
Sun Feb 19 22:25:10 2006
found dead shared server 'S002', pid = (13, 7)
Sun Feb 19 22:40:22 2006
found dead shared server 'S004', pid = (14, 4)
Sun Feb 19 23:27:49 2006

peux tu nous donner les paramêtres de ton init.ora?

Bonjour Aline,

processes = 150
timed_statistics = TRUE
shared_pool_size = 50331648
large_pool_size = 8388608
java_pool_size = 0
control_files = D:\oracle\oradata\WEB\CONTROL01.CTL, D:\oracle\oradata\WEB\CONTROL02.CTL, D:\oracle\oradata\WEB\CONTROL03.CTL
db_block_size = 4096
db_cache_size = 33554432
compatible = 9.2.0.0.0
db_file_multiblock_read_count= 8
fast_start_mttr_target = 0
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 900
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = WEB
dispatchers = (PROTOCOL=TCP) (SERVICE=WEBXDB)
job_queue_processes = 10
hash_join_enabled = FALSE
background_dump_dest = D:\oracle\admin\WEB\bdump
user_dump_dest = D:\oracle\admin\WEB\udump
core_dump_dest = D:\oracle\admin\WEB\cdump
sort_area_size = 524288
db_name = WEB
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 16777216
aq_tm_processes = 1

N'est-ce pas au niveau du fichier Tnsnames.ora que cela est indiqué ?

Merci de ton aide

[aline]

Non, c'est dans le init.ora



ce paramêtre décrit un shared server.

dispatchers="(PROTOCOL=TCP) (SERVICE=DEVXDB)"



Je te conseille de l'enlever si tu veux tourner en mode dédié.
Par ailleurs, si tu à une application web, il vaut peux être mieux ne pas tourner en dédié

[Pomalaix]

Bonsoir

J'ai connu un problème similaire il y a quelques jours, sur une 9.2.0.7.
Pas sûr donc que la mise à jour que vous envisagez suffise à résoudre le problème.

S'il s'agit d'un serveur de développement, avec peu de sessions simultanées, il n'y a aucune raison d'utiliser le mode serveur partagé (sauf si l'application de production fonctionnera, elle, dans ce mode. Dans ce cas, il faut au contraire tester en serveur partagé, pour se rapprocher des conditions du réel)

Pour connaître le paramétrage en cours, il ne suffit pas de consulter l'NIT.ORA. En effet, on n'y trouve que les paramètres pour lesquels on a expressément spécifié une valeur.
Pour tous les autres paramètres, c'est la valeur par défaut qui s'applique.
Il faut donc consulter la vue V$PARAMETER pour avoir la liste complète des paramètres en vigueur.

Les 2 paramètres essentiels pour le mode serveur partagé sont DISPATCHERS et MAX_SHARED_SERVERS (ce dernier a une valeur par défaut non nulle en 9i; en 10g, ce n'est plus le cas).

Ces deux paramètres suffisent pour activer le mode serveur partagé. Ce sera même le mode de fonctionnement par défaut de toute connexion entrante, à moins qu'on précise SERVER=DEDICATED dans le TNSNAMES.ORA du poste client.

Pour désactiver avec certitude le mode serveur partagé, il faut supprimer le paramètre DISPATCHERS. Cela veut dire qu'il faut le retirer de l'INIT.ORA, ou au minimum le mettre en commentaire.

La syntaxe

Code :

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

DISPATCHERS=''

que l'on peut trouver dans la doc ne semble pas fonctionner. Si on est en SPFILE, il faudra donc passer par un PFILE intermédiaire.

Avec ça, vous devriez avoir la peau de vos serveurs partagés !

[PpPool]

Bonjour et merci à tous pour votre coup de main

je suis toujours en train d'essayer d'installer mon update : bah oui à distance avec les pbs réseaux+autres, j'ai enfin fini de dowloader hier soir à 21h30

ce matin : je lance le runInstaller version 10.1.0.4
je choisi au niveau de destination mon orahome que je veux mettre à jour :
path : D:/oracle/ora92/
name : ora92

je clic sur suivant
ban à 85%, il s'arrete sur :

There was an error while loading library generalQueries

Cette intervient au moment du chargement de la librairie 'Processing ISQL*Plus"

J'ai préféré stoppé l'installation, mais sachant que je n'utilise pas ISQL*Plus, ni le serveur HTTP d'oracle, je pense que je peux outrepasser cette erreur et poursuivre l'installation.

qu'en pensez vous ?

Merci de votre aide

[PpPool]

Bonsoir
J'ai connu un problème similaire il y a quelques jours, sur une 9.2.0.7.

Bonjour Pomalaix,

Comment as tu finalement résolu le problème à ton niveau ?

Pour ma part, pour aujoud'hui, je suis resté sur ta proposition de commenter le paramètre DISPATCHERS, et de passer par un PFILE intermédiaire.
De plus, j'ai laissé tombé de coté l'update pour le moment, car celui-ci de manière inésorablement se plante à 85%.

par contre, il est certain que j'ai devoir passé ce serveur en mode dédié, car c'est une appli web qu'il y aura derrière.

ce que j'ai vu avec des admins systèmes (car le serveur est géographiquent éloigné), c'est que les problèmes ont coincidés avec un plantage sévére d'un onduleur.

relation de causes à effets, je ne sais pas ! mais j'ai vu des posts sur metalink comme quoi le camarade SMON pouvait générait des logs dans le fichier Alert du genre de ceux que je rencontre, et qui n'en sont pas vraiment.

de plus, aux moments des plantages, il n'y avait vraiment aucune activité sur la base : le we personne n'y a accéder.

Enfin, cela n'explique pas que le service de l'instance se soit redémarré plusieurs fois, et soit finalement complément crashé.

je vois monitorer çà ces jours ci

merci encore

@