Oracle 10g commence à dater un peu et il peut être "délicat" de l'installer sur une distribution récente. Ce n'est pas le cas de la distribution OpenSuSE 11.4 sur laquelle Oracle 10 s'installe avec : 
- les ajouts habituels aux paramètres systèmes : 
/etc/sysctl.conf 
kernel.shmall = 134217728 
kernel.shmmax = 2147483648 
kernel.semopn = 100 
# semaphores: semmsl, semmns, semopm, semmni 
kernel.sem = 250 32000 100 128 
fs.file-max = 65536 
net.ipv4.ip_local_port_range = 1024 65000 
# 
net.core.rmem_default = 262144 
net.core.rmem_max = 262144 
net.core.wmem_default = 262144 
net.core.wmem_max = 262144 
net.ipv4.tcp_rmem = 4096 87380 8388608 
net.ipv4.tcp_wmem = 4096 65536 8388608 
net.ipv4.tcp_mem = 4096 4096 4096 

- une modification au fichier /etc/SuSE-release pour qu'il ressemble fortement à ceci : 
openSUSE 9 (i586) 
VERSION = 9 
CODENAME = Celadon 

L'installation doit ensuite se dérouler, comme pour moi, c'est à dire sans aucune difficulté.

L'installation (en mode texte) est à peu près identique à celle de la version 5.4 présentée ici. 
Attention, l'espace réservé au SWAP doit être eu moins égal à RAM * 1.5, dans mon cas RAM = 1024Mo, Swap = 2048Mo --> pré-requis largement rempli. 
Une fois le système Linux installé on configure les variables système  : 
Ajouter dans /etc/sysctl.conf : 
# add for Oracle  
fs.file-max = 6815744 
fs.aio-max-nr = 1048576 
kernel.shmmni = 4096 
kernel.shmall = 2097152 
kernel.shmmax = 536870912 
kernel.sem = 250 32000 100 128 
net.ipv4.ip_local_port_range = 1024 65500 
net.core.rmem_default = 262144 
net.core.rmem_max = 4194304 
net.core.wmem_default = 262144 
net.core.wmem_max = 1048576 

et dans /etc/security/limits.conf : 
# for oracle 
@dba            soft    nproc   2047 
@dba            hard    nproc   16384 
@dba            soft    nofile  65536 
@dba            hard    nofile  131072 

Mettre à jour les catalogues "yum" : 
cd /etc/yum.repo.d 
wget http://public-yum.oracle.com/public-yum-el4.repo 

Dans le fichier "public-yum-el4.repo" mettre à jour la ligne "enabled=1" dans le paragraphe [el4_u8_base]. 
Lancer ensuite le rafraichissement du catalogue "yum update", attention il faut être patient, surtout si votre connexion n'est pas très rapide et plus le temps passe, plus il y a de mises à jour, aujourd'hui (Février 2011) il y a plus de mises à jour que lors du premier jet de cet article. Eh oui, je me sers de mes propres articles pour faire de nouvelles installations et j'y rajoute éventuellement un petit commentaire. 
Puis charger les utilitaires indispensables tels que "vim-x11" qui fournit l'indispensable "gvim" par "yum install vim-X11". 
Il faut aussi installer une version spécifique du paquet "libaio" puisqu'Oracle demande la version 0.3.96 exclusivement, celle chargée par "yum update" (version 0.3.105) n'est pas reconnue comme valide. (http://rpmfind.net). Le RPM trouvé crée un fichier "libaio.so.1" il m'a fallu créer un lien vers "libaio.so.0" ( ? ) pour que l'installeur accepte la librairie. 
 Le user "oracle" et le groupe "dba" sont créés. 
Dans le disque monté sur "/DATA" créer un répertoire "u01" et "chown oracle:dba /DATA/u01", le fichier fstab sera agrémenté du montage de ce disque. 
Le paquet "Oracle 10g" sera installé dans un coin tranquille ou rendu accessible par un montage Samba ou NFS. 
On sera alors prêts pour la suite : l'installation de Oracle 10g 
Ci dessous le fichier de paramétrage XEN de la machine virtuelle : 
# Définition machine Linux Oracle 4.8 pour Oracle 10g 
ostype='other' 
name='com-ora10g' 
memory=2048 
vcpus=1 
uuid='9b58d38c-1767-76f7-e865-3fa96ba392d2' 
on_crash='destroy' 
on_poweroff='destroy' 
on_reboot='restart' 
localtime=0 

builder='hvm' 
extid=0 
device_model="/usr/lib/xen/bin/qemu-dm" 
kernel='/usr/lib/xen/boot/hvmloader' 
boot='c' 
disk=[  'phy:/dev/mapper/HUGE_1-COM_ORA10G_SYS,hdb,w', 
        'phy:/dev/mapper/DUO-COM_ORA10G_DATA,hdc,w', 
#       'tap:aio:/MV/ORALINUX/Enterprise-R4-U8-x86_64-dvd.iso,hdd:cdrom,r' 
     ] 
vif=[   'mac=00:16:3e:30:08:01,bridge=br0,model=rtl8139,type=ioemu', 
    ] 
vnc=1 
vncunused=1 
apic=0 
acpi=1 
pae=1 
usb=1 
usbdevice='tablet' 
serial='pty' 
 

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 :

 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.

Le mini test a été réalisé selon la procédure décrite ici. 
Remarque : 
Cette machine est munie de disques "strippés" à priori deux fois plus rapides que les disques non strippés (voir article sur le stripping). 
Calcul de la différence de dates : 
select to_char( to_date(min(datec),'YYYYMMDD') - 180,'YYYYMMDD'), 
    min(datec), max(datec), 
    to_date(max(datec),'YYYYMMDD') - to_date(min(datec),'YYYYMMDD'), 
    count(*) 
from xen_stat_v2 ; 
Génération de la table temporaire : 
set timing on 
insert into toto 
select to_char( to_date(datec,'YYYYMMDD') - DIFFERENTIEL_CALCULE  ,'YYYYMMDD') as DATEC, 
       heurec,serveur,domnom,deltacpu,deltarx,deltatx,cpupct, 
       nbsecr,nbsecw 
from xen_stat_v2; 

Insertion des rangs calculés : 
insert into xen_statv2 select * from toto 
go 
Après quelques itérations on arrive au volume voulu :  

La table permanente a été mise en "nologging" pendant la durée des insertions et Le volume occupé par la table et ses deux index est d'environ 2200Mo. 

Résultats du mini test.

• Test 1 création de deux index :

Index created. 
Elapsed: 00:02:12.69 
Index created. 
Elapsed: 00:01:49.37 

Soit un total de #242 secondes ou 5'02 ".

• Test 2 recalcul des statistiques :

set timing on 
begin 
dbms_stats.gather_table_stats(ownname => 'test',tabname => 'xen_stat_v2', estimate_percent => 100, 
    degree => 2); 
end; 
/ 
PL/SQL procedure successfully completed. 
Elapsed: 00:06:14.64 

Le calcul dure 6'14".

• Test 3 quelques "select" :

a) select DOMNOM,count(*) from xen_stat_v2 group by DOMNOM order by DOMNOM 
go 
- passe 1 : Elapsed: 00:00:12.46 
- passe 2 : Elapsed: 00:00:08.97 
Soit  #11 secondes 

b) select DOMNOM,count(*) from xen_stat_v2 group by DOMNOM order by DOMNOM 
go 
- passe 1 : Elapsed: 00:00:10.21 
- passe 2 : Elapsed: 00:00:09.76 
Soit #10 secondes