Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?

Arjuna

Aircraft Ident.: F-MBSD

Salut,

Semaine dernière : un module de l'ERP qui tourne chez un de nos client part en sucette. Ayant 40 utilisateurs en train de boire des cafés à côté de la salle serveur tout en déplorant l'incompétence notable du service informatique (:sweat j'ai pas trop cherché à creuser sur le coup, puisque c'était la première fois que ça plantait. J'ai donc arrêté proprement ce qui tournait encore, rebooté le serveur, et tout est reparti normalement.

Lundi matin : badaboum. Même scénario. Sauf que là moi j'étais pas là, du coup c'est la cliente qui a rebooté le serveur, et j'ai pas vraiment eu l'occasion de creuser cette fois là non plus.

Ce matin : A ma demande, un technicien réseau/système vient auditer le réseau pour voir si on n'a pas des problème (l'erreur concernait la création d'un "serveur rpc", j'en avais déduit à la va vite une instabilité réseau). Coup de pot (enfin, façon ce parler) bananage à nouveau, mais cette fois un bon gros bananage de chez bananage. CPU bloqué à 100% pendant plus de 30 minutes, Oracle explosé à coup de process // dans tous les sens, et interface de contrôle de l'ERP plantée et impossible à redémarrer. On a attendu que ça se calme, et on a rebooté le serveur.
Depuis ça marche, mais on s'attends à ce que ça repète d'ici peu.

Après un appel à un collègue expert de l'ERP en question, il m'indique que les erreurs qu'on a obtenu sont généralement liées à des problèmes de manque de ressources. Si le nombre d'utilisateurs n'a pas changé, on a effectivement un changement notable dans la charge de la base Oracle, puisque j'ai écrit un intranet qui consulte la base Oracle en // de l'ERP.

Ayant écrit la chose en .NET, avec des évènements (databound sur des datagrid), je pense que le site génère joyeusement des requêtes en // à chaque page. Et notamment sur une page, je dois éxécuter environ 100 requêtes... Alors à la queue leue leue, pas de souci, ce sont des requêtes simples et rapides. Mais en // ça peut aisément être une source possible de problèmes dans Oracle.

Le collègue en question m'a indiqué que sur la version Unix de l'ERP (là on est sous Windows), il avait à plusieurs reprises résolu ce problème en augmentant le nombre de sémaphores du kernel Unix, et en augmentant le nombre de processes Oracles.

Seulement, là on est sous Windows, et si je ne m'abuse, y'a pas de sémaphores. Doit y avoir un autre truc par contre. Genre me semble-t-il une clé dans la base de registres qui permet de changer le nombre de process // et de threads.
Et pour la config d'Oracle, il n'a pas su me dire dans quel fichier c'était, ni encore moins quelle valeur mettre. Et vu que je suis pas plus DBA que lui, je sais pas non plus.

Donc la question est :
Où trouve-je les paramètres en question ? (Windows 2000 / Oracle 8.1.7)
Voyez-vous d'autres explications ?

Publicité

couak

as-tu des traces pertinentes dans le répertoire des traces ? (généralement <ORACLE_HOME>\database\SID\trace de mémoire)
Quelle est l'appli qui est à la base de ton intranet ? Si c'est PHP, ca fait appel à OCI, qui je crois utilise des cursors pour gérer sa partie privée

Regarde ton paramètre OPEN_CURSORS

Code :

SQL> show parameters open_cursors

Regarde la taille de ta share pool

Mais ca se trouve on cherche pas là où il faudrait, vaut mieux analyser les logs plutôt que d'augmenter à tout hasard des paramètres qui pourrait écrouler la machine

Arjuna

Aircraft Ident.: F-MBSD

Salut,

Merci pour ta réponse !

Tout d'abors, je viens de passer 3 heures à revoir le code de l'appli intranet, afin de vérifier que je ferme correctement toutes les connections.

En effet, au départ la destruction des objets merdait, et j'avais déjà tout remodifié.
J'avais donc rechangé, histoire de bien tout fermer comme il faut.

Mais là, en ajoutant des logs sur mon objet de connection, je me suis apperçu que les objets mettaient trois plombes à se détruire... Et du coup une connection ouverte restait ouverte 300 secondes, même si elle n'était plus du tout utilisée.

Après re-modifications, je force bien la fermeture de chaque connection "à la main".
Seulement, la plupart du temps j'ai des erreurs "NullReferenceException", ce qui indique que mon ancien code marchait... parfois ! Un coup de try de goret, et maintenant ça doit être bon. J'espère juste que ça ferme pour de bon... Pas moyen de monitorer ADO malheureusement (ou alors je ne connais pas le moyen de le faire, et je suis preneur d'une suggestion ! )

Sinon, le langage utilisé pour l'intranet, c'est C#/.NET
J'avais déjà posté ma détresse sur le sujet des connexions la semaine dernière.

Pour ce qui est des paramètres :

SQL*Plus: Release 8.1.7.0.0 - Production on Wed Jan 25 22:27:28 2006

(c) Copyright 2000 Oracle Corporation. All rights reserved.

Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
With the Partitioning option
JServer Release 8.1.7.4.1 - Production

SQL> select 1 from dual;

1
----------
1

SQL> show parameters open_cursors
ORA-00942: table or view does not exist

SQL> show parameters open_cursors;
ORA-00942: table or view does not exist

SQL>

Hmmm... Faut être SYSTEM pour les voir ? Si c'est le cas, on est mal barrés, j'ai pas ce login, et la société qui a installé la base étant coulée depuis, je vois pas trop comment récupérer le mot de passes :sweat:

Arf !

SQL> connect system/manager
Connected.
SQL> show parameters open_cursors

NAME TYPE VALUE
------------------------------------ ------- ------------------------------
open_cursors integer 300
SQL>

300 ça me semble pas trop mal déjà... A moins que les curseurs restent ouverts pendant qu'on se balade dans le jeu de résultat ?

Sinon, pour les logs, y'a rien dans le répertoire que tu indiques... Enfin... Il n'existe pas

Le "initSID.ora :

#
##################################################################
#(2) -------Installation/Database Size------ #
# SMALL MEDIUM LARGE #
# Block 2K 4500K 6800K 17000K #
# Size 4K 5500K 8800K 21000K #
# #
# Oracle 8i #
##################################################################
#
#
db_name = "SID"
instance_name = SID
service_names = SID
db_files = 1024
control_files = (d:\oracle\ora81\DATABASE\ctl1SID.ora)
control_files = (d:\generix\serveur\data\ctl2SID.ora)
#
open_cursors = 300
max_enabled_roles = 30
db_file_multiblock_read_count = 8
db_block_buffers = 8110
shared_pool_size = 52428800
large_pool_size = 15728640
#java_pool_size = 0
# sk 15/12/2003 avant =
optimizer_mode=RULE
#
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
#
processes = 200 # sk 15/12/2003 avant =150
parallel_max_servers = 5
log_buffer = 32768
#
max_dump_file_size = 10240
#
global_names = true
oracle_trace_collection_name =""
user_dump_dest=%DIR_RDBMS%\trace
db_block_size = 8192
#
background_dump_dest=%DIR_RDBMS%\trace
remote_login_passwordfile = exclusive # shared
os_authent_prefix =""
distributed_transactions = 10
sort_area_size = 65536
sort_area_retained_size = 65536
#
rollback_segments = (roll_1)
rollback_segments = (roll_2)
compatible = 8.1.5.0.0
UTL_FILE_DIR=* \

A noter que "RULES" est déprecated, mais l'ERP a été écrit à l'origine pour obtenir de meilleurs perfs avec ce mode. Dans la doc technique, il est stipulé que sur les 9i et 10g ils préconisent maintenant STATISTICS, mais mettent en garde contre l'importance du tunning afin de ne pas avoir des perfs catastrophiques, et préconisent donc toujours RULES pour les sociétés qui n'ont pas un DBA sous la main (c'est le cas chez ce client)

Voici le "SQLNet.log" :

***********************************************************************
Fatal NI connect error 12640, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oraclegnx)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=gnx)(CID=(PROGRAM=d:\oracle\ora81\bin\ORACLE.EXE)(HOST=SRVBCI)(USER=SYSTEM))))

VERSION INFORMATION:
TNS for 32-bit Windows: Version 8.1.7.4.0 - Production
Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.7.4.0 - Production
Time: 25-JAN-2006 12:25:12
Tracing not turned on.
Tns error struct:
nr err code: 0
ns main err code: 12640
TNS-12640: Authentication adapter initialization failed
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0

***********************************************************************
Fatal NI connect error 12640, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oraclegnx)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=gnx)(CID=(PROGRAM=d:\oracle\ora81\bin\ORACLE.EXE)(HOST=SRVBCI)(USER=SYSTEM))))

VERSION INFORMATION:
TNS for 32-bit Windows: Version 8.1.7.4.0 - Production
Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.7.4.0 - Production
Time: 25-JAN-2006 12:25:12
Tracing not turned on.
Tns error struct:
nr err code: 0
ns main err code: 12640
TNS-12640: Authentication adapter initialization failed
ns secondary err code: 0
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0

A noter que ces erreurs sont quelques instants après le reboot, à priori des requêtes en spool qui se sont faites gicler du moteur qui s'arrêtait (3 minutes avant le reboot du serveur, sâchant qu'il était planté depuis au moins 30 minutes)

-- Edit : En fait, en regardant bien, cette erreur se produit quelques instants après chaque reboot. Ca doit correspondre au message d'erreur qu'on a au moment du chargement de l'ERP : il essaie de démarrer la base, qui est déjà démarrée...
M'enfin c'est pas bien grave, puisque la base est déjà démarrée

A noter que dans l'EventLog de Windows, à part des tas d'alerts "PerfLog" indiquant des délais exprirés dans les prises de mesures des perfs système, y'a aucun truc étrange avant le reboot. Ces messages sont explicables par la charge CPU de 100% pendant 30 minutes.

Le "SIDALRT.log" est normal :

Thread 1 advanced to log sequence 25867
Current log# 3 seq# 25867 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 11:27:19 2006
Thread 1 advanced to log sequence 25868
Current log# 4 seq# 25868 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 11:36:33 2006
Thread 1 advanced to log sequence 25869
Current log# 1 seq# 25869 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 11:57:38 2006
Thread 1 advanced to log sequence 25870
Current log# 2 seq# 25870 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Dump file d:\oracle\ora81\RDBMS\trace\gnxALRT.LOG
Wed Jan 25 12:28:58 2006
ORACLE V8.1.7.4.1 - Production vsnsta=0
vsnsql=f vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.7.4.1.
System parameters with non-default values:
processes = 200
shared_pool_size = 52428800
large_pool_size = 15728640
control_files = d:\oracle\ora81\DATABASE\ctl1gnx.ora, d:\generix\serveur\data\ctl2gnx.ora
db_block_buffers = 8110
db_block_size = 8192
compatible = 8.1.5.0.0
log_buffer = 32768
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
db_files = 1024
db_file_multiblock_read_count= 8
rollback_segments = roll_1, roll_2
max_enabled_roles = 30
remote_login_passwordfile= EXCLUSIVE
global_names = TRUE
distributed_transactions = 10
instance_name = gnx
service_names = gnx
sort_area_size = 65536
sort_area_retained_size = 65536
db_name = gnx
open_cursors = 300
os_authent_prefix =
optimizer_mode = RULE
utl_file_dir = *
parallel_max_servers = 5
background_dump_dest = %DIR_RDBMS%\trace
user_dump_dest = %DIR_RDBMS%\trace
max_dump_file_size = 10240
oracle_trace_collection_name=
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
Wed Jan 25 12:29:02 2006
alter database mount exclusive
Wed Jan 25 12:29:09 2006
Successful mount of redo thread 1, with mount id 1200376725.
Wed Jan 25 12:29:09 2006
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Wed Jan 25 12:29:09 2006
alter database open
Beginning crash recovery of 1 threads
Wed Jan 25 12:29:11 2006
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25869 Reading mem 0
Mem# 0 errs 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Recovery of Online Redo Log: Thread 1 Group 2 Seq 25870 Reading mem 0
Mem# 0 errs 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 12:29:13 2006
Thread recovery: finish rolling forward thread 1
Thread recovery: 278 data blocks read, 89 data blocks written, 3594 redo blocks read
Crash recovery completed successfully
Wed Jan 25 12:29:14 2006
Thread 1 advanced to log sequence 25871
Thread 1 opened at log sequence 25871
Current log# 3 seq# 25871 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Successful open of redo thread 1.
Wed Jan 25 12:29:14 2006
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Jan 25 12:29:16 2006
Completed: alter database open
Wed Jan 25 14:01:04 2006
Thread 1 advanced to log sequence 25872
Current log# 4 seq# 25872 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 14:28:25 2006
Thread 1 advanced to log sequence 25873
Current log# 1 seq# 25873 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 14:42:58 2006
Thread 1 advanced to log sequence 25874
Current log# 2 seq# 25874 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 15:10:12 2006
Thread 1 advanced to log sequence 25875
Current log# 3 seq# 25875 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 15:30:41 2006
Thread 1 advanced to log sequence 25876
Current log# 4 seq# 25876 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 15:49:45 2006
Thread 1 advanced to log sequence 25877
Current log# 1 seq# 25877 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 16:46:58 2006
Thread 1 advanced to log sequence 25878
Current log# 2 seq# 25878 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 17:10:21 2006
Thread 1 advanced to log sequence 25879
Current log# 3 seq# 25879 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 21:04:25 2006
Thread 1 advanced to log sequence 25880
Current log# 4 seq# 25880 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 22:09:40 2006
Thread 1 advanced to log sequence 25881
Current log# 1 seq# 25881 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF

=> Les rotations de logs ne sont pas plus rapides avant qu'après reboot.

Et rien de particulier dans le listner.log

25-JAN-2006 12:07:17 * service_update * gnx * 0
25-JAN-2006 12:07:19 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4354)) * establish * gnx * 0
25-JAN-2006 12:08:04 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=C:\Program Files\Quest Software\TOAD\TOAD.exe)(HOST=METAFRAME01)(USER=MARYSE))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.198)(PORT=4861)) * establish * gnx * 0
25-JAN-2006 12:13:37 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4356)) * establish * gnx * 0
25-JAN-2006 12:16:47 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4358)) * establish * gnx * 0
25-JAN-2006 12:17:18 * service_update * gnx * 0
25-JAN-2006 12:23:07 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4360)) * establish * gnx * 0
25-JAN-2006 12:25:13 * service_died * gnx * 12547
TNS-12547: TNS:lost contact

TNSLSNR for 32-bit Windows: Version 8.1.7.4.0 - Production on 25-JAN-2006 12:28:54

(c) Copyright 1998 Oracle Corporation. All rights reserved.

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

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=srvbci.BCI.local)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC0ipc)))
TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT [* SID] * RETURN CODE
25-JAN-2006 12:29:02 * service_register * gnx * 0
25-JAN-2006 12:29:11 * service_update * gnx * 0
25-JAN-2006 12:29:24 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4363)) * establish * gnx * 0
25-JAN-2006 12:32:34 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4365)) * establish * gnx * 0
25-JAN-2006 12:33:53 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4367)) * establish * gnx * 0
25-JAN-2006 12:35:44 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4369)) * establish * gnx * 0
25-JAN-2006 12:39:11 * service_update * gnx * 0

Message édité par Arjuna le 25-01-2006 à 22:56:50

couak

au vu de ton init, les traces sont dans ton ORACLE_HOME\trace

ton share pool n'est pas énorme, mais ptet que l'ERP n'a pas besoin de plus

pour ce qui est du plan d'exécution, effectivement le mieux est de mettre un mode CHOOSE plutôt que RULES, et récolter les stats de manière périodique (package dbms_stats je crois)
pas besoin d'un DBA, juste besoin d'un mec qui le met en place via l'ordonnaceneur de la boîte ou via le plannificateur de tâche windows, ou via l'ordonnanceur interne d'oracle (package dbms_jobs je crois)
Mais bon si l'éditeur de l'ERP dit qu'il ne faut pas, mieux ne vaut pas s'amuser à changer des trucs en prod. sans en mesurer les réelles impacts, car en activant les stats il peut arriver que l'on perd en perf.
Mais cela ne résoudra pas ton problème

au vu du listener.log il n'y pas tant de connexions parallèles que ca, mais j'avoue que voir un Oracle planter sans raisons apparentes, c'est assez rare, même en ayant des connexions mal déconnectées, normalement Oracle les déconnecte proprement

j'aime pas trop l'option "compatible = 8.1.5.0.0" mais bon on n'y peut rien

tu n'as plus qu'à espérer un vrai DBA expérimenté traîne ici =)
As-tu regarder les alertes systèmes du serveur ? Parfois des choses intéressantes peuvent apparaîtres dans l'event viewer de windows

bon courage

Arjuna

Aircraft Ident.: F-MBSD

Justement, y'a rien dans l'eventlog de Windows. Juste des alertes "perflib".

Ceci dit, on n'est pas sûrs que c'est Oracle qui part en live... En effet, l'ERP et Oracle sont sur le même serveur, et quand la charge était de 100%, aucun process ne dépassait 5% d'utilisation CPU, du coup c'est un service ou un process "caché" qui est parti en couille, et impossible de savoir lequel :sweat:

FORUM HardWare.fr

Programmation

SQL/NoSQL

Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?

Sujets relatifs
Exporter les enregistrements d'une base au oracle au format XML	[FTP] Serveur FTP pour site Web
RMI -> obligé d'avoir la même version de JVM sur clients et serveur ?	aide sur SQL serveur
Lancer un exe sur le serveur	[Resolu] [PHP-MySQL] Serveur MySQL derrière un proxy
[Résolu][Oracle] Mutating table sur un update	[Oracle] Désactiver un trigger pendant un UPDATE
tomcat jsp et connection oracle	Oracle : erreur ORA-00947 en insertion
Plus de sujets relatifs à : Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?

Page générée en 0.070 secondes