Discussion :

[SERVIROC]

Bonjour,

ce matin je démarre le serveur et là incroyable, mes deux bases fonctionnent alors que je n'avait pas encore modifier le listener.ora
par contre j'ai un nouveau problème, j'ai régulièrement une bases sur les deux (voir les deux certaines fois) qui ne veut pas démarrer, apparement elles sont bloqués en NOMOUNT et ne veulent pas éxécuter le ALTER DATABASE MOUNT automatiquement, je suis donc obliger de les démarrer en manuel.

[Jaouad]

Bonjour ,
Qu dit le fichier trace de la base ?

[SERVIROC]

voila un morceau du fichier alert.log concernant le démarrage de ce matin :

Mon Aug 29 09:02:48 2005
ORACLE V10.1.0.2.0 - Production vsnsta=0
vsnsql=13 vsnxtr=3
Windows 2000 Version V5.0 Service Pack 4
CPU : 2 - type 586
Process Affinity: 0x00000000
Memory (A/P) : PH:1003M/1279M, PG:2473M/2630M, VA:1953M/2047M
Mon Aug 29 09:02:48 2005
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
KCCDEBUG_LEVEL = 0
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
Dynamic strands is set to TRUE
Running with 2 shared and 18 private strand(s). Zero-copy redo is FALSE
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 10.1.0.2.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 88080384
__large_pool_size = 4194304
__java_pool_size = 8388608
sga_target = 184549376
control_files = F:\ORACLE\PRODUCT\10.1.0\ORADATA\METALTOP\CONTROL01.CTL, F:\ORACLE\PRODUCT\10.1.0\ORADATA\METALTOP\CONTROL02.CTL, F:\ORACLE\PRODUCT\10.1.0\ORADATA\METALTOP\CONTROL03.CTL
db_block_size = 8192
__db_cache_size = 79691776
compatible = 10.1.0.2.0
db_file_multiblock_read_count= 16
db_recovery_file_dest = F:\oracle\product\10.1.0\flash_recovery_area
db_recovery_file_dest_size= 2147483648
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=METALTOPXDB)
job_queue_processes = 10
background_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\METALTOP\BDUMP
user_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\METALTOP\UDUMP
core_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\METALTOP\CDUMP
sort_area_size = 65536
db_name = METALTOP
open_cursors = 300
pga_aggregate_target = 78643200
DBW0 started with pid=4, OS id=1656
MMAN started with pid=3, OS id=1644
PMON started with pid=2, OS id=1596
CKPT started with pid=6, OS id=1668
SMON started with pid=7, OS id=1676
RECO started with pid=8, OS id=1684
Mon Aug 29 09:02:53 2005
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Mon Aug 29 09:02:53 2005
starting up 1 shared server(s) ...
LGWR started with pid=5, OS id=1660
CJQ0 started with pid=9, OS id=1688
Mon Aug 29 09:34:21 2005
alter database mount
Mon Aug 29 09:34:21 2005
Controlfile identified with block size 16384
Mon Aug 29 09:34:25 2005
Setting recovery target incarnation to 2
Mon Aug 29 09:34:25 2005
Successful mount of redo thread 1, with mount id 4285227933
Mon Aug 29 09:34:25 2005
Database mounted in Exclusive Mode.
Completed: alter database mount
Mon Aug 29 09:34:41 2005
alter database open
Mon Aug 29 09:34:41 2005
Beginning crash recovery of 1 threads
attempting to start a parallel recovery with 2 processes
parallel recovery started with 2 processes
Mon Aug 29 09:34:41 2005
Started first pass scan
Mon Aug 29 09:34:41 2005
Completed first pass scan
2 redo blocks read, 3 data blocks need recovery
Mon Aug 29 09:34:41 2005
Started redo application at
Thread 1: logseq 329, block 9545, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 1 Seq 329 Reading mem 0
Mem# 0 errs 0: F:\ORACLE\PRODUCT\10.1.0\ORADATA\METALTOP\REDO01.LOG

Il faut savoir que j'ai lancé le ALTER DATABASE MOUNT a 9h34 alors que le serveur à démarré a 9h00

[Jaouad]

Apparement tu effectue un recovery
Tu arrête ta base comment ?

[SERVIROC]

ma base s'arrete seul en arretant le serveur le soir.
Par contre je ne fais pas de recovery (enfin je ne crois pas, du moins ce n'est pas une action volontaire de ma part)

[bouyao]

Est ce que tu a le script d'arrêt de la base ?
Est ce que tu utilise :

Code :

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

shutdown abort

dans ton script

[SERVIROC]

non je n'ai pas de script d'arret de la base
je pense plutôt qu'elle s'arrète seule avec l'arrêt des services windows correspondant

[Jaouad]

Est ce que tu a le script d'arrêt de la base ?
Est ce que tu utilise :

Code :

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

shutdown abort

dans ton script

+1
C'est a ca que je pensais
SERVIROC si tu arretes ta base ainsi , la phase de recoveru est auto et cela expliquerait pourquoi le startup prend du temps :

Recovery of Online Redo Log: Thread 1 Group 1 Seq 329 Reading mem 0
Mem# 0 errs 0: F:\ORACLE\PRODUCT\10.1.0\ORADATA\METALTOP\REDO01.LOG

[SERVIROC]

et donc que dois-je faire ?

[Jaouad]

Est ce que tu as bien un shutdown abort ??
Pourquoi cela a été mis en place ??
SI possible passer en shutdown immediate

[SERVIROC]

???
Je suis désolé mais je ne pense pas avoir bien compris ce qu'il fallait que je fasse.
Je ne suis malheureusement pas former sous oracle donc je peine un peu !
je n'ai pas de shutdown dans la mesure ou je ne demande jamais à mes bases de s'arreter, elles le font toutes seules lorsque j'éteint mon serveur en arreter les services Oracle !

[Jaouad]

Donc si j'ai bien compris tu arrête ta base en arrêtant les services Windows .
Deux solutions s'offrent à toi.
La premiére qui me parait le plus logique est de créer un script du type :

Code :

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

1
2
3
4
 
sqlplus /nolog
connect /as sysdba 
shutdown immediate

La seconde qui est plus alambiqué est de modifié la maniére dont Oracle s'arrête lors de l'arrêt des services :

Dans HKEY_LOCAL_MACHINE => SOFTAWARE => ORACLE => chercher la variable ORA_SID_SHUTDOWNTYPE mettre la valeur I pour immediate. Tu as surement A pour abort

[SERVIROC]

donc en fait il faudrait que j crée un script sql mais comment dois-je faire pour lui dire de s'éxécuter automatiquement avant l'arret du serveur ?

[Jaouad]

la personne arrêttant le serveur pourra le lancer ce script.
Sinon tu peux modifier la valeur de la base de registre et dans ceas là tu n'a pas d'actions a faire avant l'arrêt de ton serveur !!!

[SERVIROC]

Je viens de regarder dans la base de registre est la variable ORA_SID_SHUTDOWNTYPE à déjà immediate pour valeur.

[Jaouad]

Je viens de regarder dans la base de registre est la variable ORA_SID_SHUTDOWNTYPE à déjà immediate pour valeur.

Est ce que dans le fichier TRACE tu peux vérifier quel est le type de shutdown ?

[SERVIROC]

c'est bien un shutdown immediate par contre je viens de remarquer une erreur dans le alert.log pendant l'arret de la base :

Errors in file f:\oracle\product\10.1.0\admin\metaltop\udump\metaltop_ora_2108.trc:
ORA-01089: immediate shutdown in progress - no operations are permitted
ORA-06512: at "SYS.DBMS_AQ", line 577
ORA-06512: at "SYSMAN.EMD_NOTIFICATION", line 492
ORA-06512: at line 1

All dispatchers and shared servers shutdown
Dump file f:\oracle\product\10.1.0\admin\metaltop\bdump\alert_metaltop.log

Peut-être que cela à un rapport ?

[Jaouad]

Et bein voila d'ou vient le recovery
Sur Métalink Note:303470.1 pour une 10.1.0.4

Fix
Please could you do:
1. Stop the Database Control
2. From SQL*Plus as sys, connect to the database
3. Execute the following SQL statements:

grant execute on sys.utl_smtp to sysman;
grant execute on sys.utl_tcp to sysman;
alter package sysman.emd_notification compile;

4. REMOVE ORACLE_HOME\<hostname>_<sidname>\upload\*.xml
5. Start the Database Control
6. Access to the Database Control
7. Purge the Alert Log

[SERVIROC]

j'ai fait cette manipulation et apparement cela fonctionne, maintenant, il faudrait que j'essaye de redémarrer plusieurs fois pour être vraiment sûr !

[SERVIROC]

Ce matin j'ai encore une des mes deux bases qui n'a pas démarrer !!!
et voici ce que je trouve dans le alert.log concernant l'arret d'hier soir :

Tue Aug 30 17:26:41 2005
Starting background process EMN0
EMN0 started with pid=18, OS id=1892
Tue Aug 30 17:26:42 2005
Shutting down instance: further logons disabled
Tue Aug 30 17:26:42 2005
Stopping background process QMNC
Tue Aug 30 17:26:42 2005
Stopping background process CJQ0
Tue Aug 30 17:26:44 2005
Stopping background process MMNL
Tue Aug 30 17:26:45 2005
Stopping background process MMON
Tue Aug 30 17:26:46 2005
Shutting down instance (immediate)
License high water mark = 13
Tue Aug 30 17:26:46 2005
Stopping Job queue slave processes
Tue Aug 30 17:26:47 2005
Errors in file f:\oracle\product\10.1.0\admin\codeve\udump\codeve_ora_2236.trc:
ORA-01089: immediate shutdown in progress - no operations are permitted
ORA-06512: at "SYS.DBMS_AQ", line 577
ORA-06512: at "SYSMAN.EMD_NOTIFICATION", line 492
ORA-06512: at line 1

Tue Aug 30 17:26:49 2005
Waiting for Job queue slaves to complete
Tue Aug 30 17:26:49 2005
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Dump file f:\oracle\product\10.1.0\admin\codeve\bdump\alert_codeve.log

maintenant voici le contenu du fichier alert.log pour le démarrage de ce matin :

Wed Aug 31 09:19:29 2005
ORACLE V10.1.0.2.0 - Production vsnsta=0
vsnsql=13 vsnxtr=3
Windows 2000 Version V5.0 Service Pack 4
CPU : 2 - type 586
Process Affinity: 0x00000000
Memory (A/P) : PH:1004M/1279M, PG:2474M/2630M, VA:1953M/2047M
Wed Aug 31 09:19:29 2005
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
KCCDEBUG_LEVEL = 0
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
Dynamic strands is set to TRUE
Running with 2 shared and 18 private strand(s). Zero-copy redo is FALSE
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 10.1.0.2.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 79691776
__large_pool_size = 4194304
__java_pool_size = 8388608
sga_target = 260046848
control_files = F:\ORACLE\PRODUCT\10.1.0\ORADATA\CODEVE\CONTROL01.CTL, F:\ORACLE\PRODUCT\10.1.0\ORADATA\CODEVE\CONTROL02.CTL, F:\ORACLE\PRODUCT\10.1.0\ORADATA\CODEVE\CONTROL03.CTL
db_block_size = 8192
__db_cache_size = 163577856
compatible = 10.1.0.2.0
db_file_multiblock_read_count= 16
db_recovery_file_dest = F:\oracle\product\10.1.0\flash_recovery_area
db_recovery_file_dest_size= 2147483648
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=CODEVEXDB)
job_queue_processes = 10
background_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\CODEVE\BDUMP
user_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\CODEVE\UDUMP
core_dump_dest = F:\ORACLE\PRODUCT\10.1.0\ADMIN\CODEVE\CDUMP
sort_area_size = 65536
db_name = CODEVE
open_cursors = 300
pga_aggregate_target = 110100480
MMAN started with pid=3, OS id=1628
LGWR started with pid=5, OS id=1644
CKPT started with pid=6, OS id=1648
SMON started with pid=7, OS id=1656
RECO started with pid=8, OS id=1660
CJQ0 started with pid=9, OS id=1664
Wed Aug 31 09:19:33 2005
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
PMON started with pid=2, OS id=1620
DBW0 started with pid=4, OS id=1636