Après le premier reboot, on tente le "dbstart" et on récupère l'infâme message :
Failed to auto-start Oracle Net Listener using /ade/vikrkuma_new/oracle/bin/tnslsnr
Il faut aller corriger le script $ORACLE_HOME/bin/dbstart et y ajouter (après la ligne 78) :
# ORACLE_HOME_LISTNER=/ade/vikrkuma_new/oracle
ORACLE_HOME_LISTNER=/home/oracle/oracle/product/10.2.0/db_1
Au prochain "dbstart" le listener démarrera correctement, sacré vikrkuma ! En plus il a signé son méfait.
Après un "bon" lancement la commande "lsnrctl service" nous renvoie la liste tant espérée :
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0
LOCAL SERVER
Service "orcl10g" has 1 instance(s).
Instance "orcl10g", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
Service "orcl10gXDB" has 1 instance(s).
Instance "orcl10g", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:0 refused:0 current:0 max:1022 state:ready
DISPATCHER <machine: com-ora10g.jpp.fr, pid: 16057>
(ADDRESS=(PROTOCOL=tcp)(HOST=com-ora10g.jpp.fr)(PORT=32815))
Service "orcl10g_XPT" has 1 instance(s).
Instance "orcl10g", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
The command completed successfully
Le système est donc bien "prêt". Voyons voir ce que l'installeur nous a mis comme paramètres mémoire (sur la dbconsole) "Administration --> Memory parameters"
512MO de SGA répartis comme suit :
| SGA Component | Current Allocation (MB) |
| Shared Pool | 160 |
| Buffer Cache | 340 |
| Large Pool | 4 |
| Java Pool | 4 |
| Others | 4 |
et 192MO de PGA, cela sera très large pour nos essais.
Un petit tour dans "Administration --> All initialization parameters" pour voir un peu toute cette configuration "standard", 258 paramètres quand même.
"db_file_multiblock_read_count" est à 16, cela va très bien avec un bloc de 8K.
"db_keep_cache_size" et "db_recycle_cache_size" sont à blanc ce qui nous satiafait.
On cherche le "filesystemio_options" (à blanc par défaut) et lui met "DIRECTIO" juste pour voir.
Pour ce test pas d'archivelog, de flashback et autres complexités.
Au niveau du système je stoppe des services inutiles et modifie le fichier "/etc/inittab" pour démarrer en niveau 3, un serveur de BDD n'a pas besoin d'interface X ! Et cela économise de la mémoire.
Pour finir on reboote pour avoir "tout propre", peu après le démarrage le système occupe quand même #85Mo de mémoire.
Après le lancement de la base et de la dbconsole on est déjà à plus de 700Mo, se connecter à la console fait dépasser les 760Mo après le lancement de quelques opérations : création d'une table historique de #13 Millions de lignes par insertions multiples en modifiant les dates, la mémoire utilisée monte à 1,2G.
La dernière phase : générer 6,5 Millions de lignes en modifiant la date des 6,5 Millions de la table originale est effectuée en 63 secondes. Le tout occupe environ 640Mo sur le disque. L'insertion des mêmes 6,5 millions de rangs fraîchement générés dure #34 secondes, ça marche.
Un index composite (3 champs) est créé en 3' 45", un deuxième en 2' 55"...
Un petit tour dans "Administration --> All initialization parameters" pour voir un peu toute cette configuration "standard", 258 paramètres quand même.
"db_file_multiblock_read_count" est à 16, cela va très bien avec un bloc de 8K.
"db_keep_cache_size" et "db_recycle_cache_size" sont à blanc ce qui nous satiafait.
On cherche le "filesystemio_options" (à blanc par défaut) et lui met "DIRECTIO" juste pour voir.
Pour ce test pas d'archivelog, de flashback et autres complexités.
Au niveau du système je stoppe des services inutiles et modifie le fichier "/etc/inittab" pour démarrer en niveau 3, un serveur de BDD n'a pas besoin d'interface X ! Et cela économise de la mémoire.
Pour finir on reboote pour avoir "tout propre", peu après le démarrage le système occupe quand même #85Mo de mémoire.
Après le lancement de la base et de la dbconsole on est déjà à plus de 700Mo, se connecter à la console fait dépasser les 760Mo après le lancement de quelques opérations : création d'une table historique de #13 Millions de lignes par insertions multiples en modifiant les dates, la mémoire utilisée monte à 1,2G.
La dernière phase : générer 6,5 Millions de lignes en modifiant la date des 6,5 Millions de la table originale est effectuée en 63 secondes. Le tout occupe environ 640Mo sur le disque. L'insertion des mêmes 6,5 millions de rangs fraîchement générés dure #34 secondes, ça marche.
Un index composite (3 champs) est créé en 3' 45", un deuxième en 2' 55"..
Le calcul des statistiques sur cette table :
begin
dbms_stats.gather_schema_stats(ownname => 'test',estimate_percent => 90,
degree => 2);
end
dure #11 minutes.