XEN : Oracle 10, ajustements

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.