Ce chapitre présente l'installation sous XEN d'une machine destinée à une installation de oracle11G.

La machine virtuelle XEN est dotée de :

• 1 CPU
• 3072 Mo de RAM
• 1 disque système de 16G
• 1 disque données de 40G
• 1 interface réseau

Le chapitre est divisé en plusieurs parties :

• Installation du Linux Oracle
• Installation des pré-requis
• Installation de Oracle

J'ai décidé d'installer une base ORACLE 11g pour ma formation personnelle et au passage de tester l'installation de la version "Oraclisée" de Linux en 64 bits. 
Après téléchargement de la version 5.4 (# 4Go) et préparation d'une machine virtuelle :

• 2 processeurs
• Ram 3 Go
• Disque : un disque "système" de 16Go, un autre disque sera créé par la suite pour les données Oracle. 
  Ce disque est partitionné comme suit :

hda1 /boot 512Mo 
hda2 LVM de 16,5Go divisé comme suit : 
VOL00 / 12 Go 
VOL01 swap 4 Go

Le fichier de description de cette machine virtuelle est attaché.

Au lancement de la machine le premier écran de boot s'affiche : 
 

Dans lequel je préfère prendre l'option "linux text" pour ne pas avoir de bugs d'affichage. 
Après le lancement la procédure d'installation s'enchaine :

• Premier écran (ECRAN_001.png) choisir l'installation en mlode texte pour ne pas avoir de surprises.
•  "CD Found"  (vérification du CD) ressemble comme deux gouttes d'eau à  celui de RedHat : on teste le CD pour vérifier son bon chargement, cela prends un peu de temps, mais cela rassure. 
  La vérification est bonne --> OK.
• Ecran "Media check" : on n'a pas d'autre source d'installation --> Continue
• Ecran "Language Selection" --> French
• Ecran "Selection de clavier" --> fr-latin1
• Ecran "Type de partitionnement" --> Supprimer les partitions ... sur le seul disque connu "/dev/hda". 
  
  
• Ecran "Avertissement", Oui on écrase le disque et on Continue
• Ecran "Examiner la structure de partitionnement" --> Oui
• Ecran "Partitionnement" l'écran propose Swap à  5Go et Data à 11 Go en LVM, je prefère un swap à  4Go seulement. Je modifie la taille du swap et automatiquement la taille des DATA passe à  12Go. 
  Je valide le tout --> OK
• Ecran  "Configuration du chargeur de démarrage" --> on utilise GRUB --> OK
• Ecran  "Configuration du chargeur de démarrage" --> pas de forçage de LBA32 --> OK
• Ecran "Configuration du chargeur de démarrage" --> pas de mot de passe GRUB --> OK
• Ecran "Configuration du chargeur de démarrage" --> on utilise le seul volume dsponible --> OK
• Ecran "Configuration du chargeur de démarrage" --> laisser l'éiquette standard --> OK
• - "Configuration du chargeur de démarrage" --> on installe sur "/dev/hda" (MBR) --> OK
• Ecran "Configurer l'interface réseau" --> OUI
• Ecran "configuration réseau de eth0" --> Activer au démarrage, IPV4 seul --> OK
• Ecran "Configuration IPV4 pour eth0" --> Configuration adresse manuelle, fournir l'adresse/masque --> OK

• Ecran  "Divers paramètres de réseau" --> Passerelle, DNS primaire et secondaire --> OK
• Ecran  "Configuration du nom d'hôte" : "Manuellement" + nom machine --> OK
• Ecran "Sélection du fuseau horaire" --> Europe/Paris --> OK
• Ecran "Mot de passe root" --> mot de passe + confirmation --> OK

L'installation se lance et propose un premier niveau de personnalisation de la machine 
 
 --> on sélectionne "Développement Logiciel" pour disposer des compilateurs et "Personalisation de la sélection des logiciels".

• Ecran "Package group Selection" : Sélectionner 

1. "Bibliothèques de développement",
2. "Environnement de bureau Gnome",
3. "Internet Graphique",
4. "Outils d'administration",
5. "Outils de configuration de serveur",
6. "Outils de développement",
7. "Outils système",
8. "Système X Window",
9. "Editeurs" 
   --> OK

L'installation débute alors réellement ...  un écran de rappel vous signale que le log de l'installation sera disponible dans /root/install.log --> OK. 
Et c'est enfin parti pour formater le disque et installer les paquetages : 
 

Après une quinzaine de minutes l'instant tant attendu : 
  

On redémarre le système (c'est un noyau 2.6.18), au bout d'une dizaine de secondes un écran de post installation apparait, il faut se dépêcher de configurer les services .... 
 
Par défaut au bout de 10 secondes le login apparaît à son tour. 
Un premier test : le réseau est OK, la machine est accessible par ssh. 
Mince, aucun écran graphique n'est disponible, le serveur X n'est pas configuré ou pas lancé. 
On redémarre pour voir le premier écran de config : 
Il permet de sélectionner les services à activer/désactiver, mais toujours pas d'interface graphique ! 
Le script de lancement de "gdm" n' pas été installé (??), j'en fabrique donc un petit et le lancement de mon script est concluant, l'accès XWindow fonctionne. 
Mais seulement en 600x480, c'est un peu petit, après un petit tour dans le fichier /etc/X11/xorg.conf et un "stop/start" de mon petit script l'accès en 1024x768 est OK. C'est beaucoup plus confortable. 
Après la mise en place des gadgets indispensables dans les panels Gnome je stoppe la machine pour en sauvegarder l'état.

Cet article a pour but de présenter une installation plus "perfectionnée" utilisant les dernières nouveautés (en fait ASM pour Automatic Storage Management date de la 10g) mais l'installation et la gestion en sont plus simples et mieux intégrées dans cette nouvelle version.

Pour plus de détails sur ASM voir les documentations Oracle où on peut trouver beaucoup de choses.

Le système de base sera un système Linux Oracle (image disque copiée de l'image "de base" d'installation) cf article : "installation d'un linux Oracle".

La configuration disques prévue est la suivante :

• Disque système de 16Go
• Disque "DATA" de 10Go
• Disque "RECO" de 10Go

En effet Oracle propose de définir par défaut deux groupes de disques séparés :

• Un pour les données
• L'autre pour les éléments liés à la sécurité (double des "redo logs", fichiers "archivelog", sauvegardes de la base par RMAN.

Nous n'utiliserons pas, dans un premier temps, la possibilité offerte par ASM de gérer lui même la redondance des données, ce qui explique la présence de seulement deux disques de données. Dans une phase ultérieure on reconfigurera cette machine avec 4 disques de données pour pouvoir jouer avec la redondance et les "disk failure groups".

En ne mettant pas tous ses oeufs dans le même panier on garantit mieux la pérénité de sa base, par défaut un exemplaire du "controlfile" est créé dans chacun des groupes.

En regardant d'un peu plus près ASM donne à l'administrateur de la base de données (le "DBA") beaucoup plus de pouvoirs sur le fonctionnement gobal de la base de données en lui permettant de contrôler l'ensemble de la chaine de gestion depuis le stockage des données sur les disques jusqu'à leur délivrance aux utilisateurs.

Mais qui dit plus de pouvoirs dit aussi plus de responsabilité car il devra aussi assurer :

• La sécurité de ces données par divers moyens dont la redondance,
• La rapidité des traitements par le stripping des fichiers de données.
• La résistance aux pannes par une distribution réfléchie des disques sur les contrôleurs
• La "scalabilité" par les bases de données multi-instances (RAC chez Oracle)
• ...

Il va falloir que le DBA assimile de nouvelles techniques, de nouvelles contraintes pour garantir l'accès aux données.

Cette installation sera divisée en cinq parties :

• Mise en place des pré-requis.
• Mise e place de la partie ASM (partie de "grid").
• Chargement du logiciel base de données
• Création de la base de données.elle même
• Finalisation de l'installation

Pour créer la base de données l'utilisation de l'assistant "dbca" est conseillée. 
La base n'étant pas encore créée le "ORACLE_HOME" n'existe pas encore il nous faut donc "forcer" l'utilisation du "bon" (/opt/oracle/product/11.2.0/dbhome_1) lors de l'appel à "oraenv" :

. oraenv ORACLE_SID = [oracle] ? 
ORACLE_HOME = [/home/oracle] ? /opt/oracle/product/11.2.0/dbhome_1 
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/dbhome_1 is /opt/oracle

On vérifie par :

echo $PATH 
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin:/opt/oracle/product/11.2.0/dbhome_1/bin

C'est OK, on peut lancer la commande "dbca", l'écran initial de OUI est à passer pour arriver au premier écran de l'installation :

• Premier écran "Sélectionner le type d'opération", on coche évidemment  "Créer une base de données".

• Deuxième écran on coche "Bd généraliste...".
• Troisième écran "Nom de la base de données", le "nom global" sera "orcl.toto.fr", le SID sera automatiquement mis à "orcl".

• Quatrième écran : "Options de gestion", on coche "Configurer Entreprise Manager", "Configurer Database Control pour la gestion locale". Sur l'onglet "Taches de maintenance automatique " bien cocher "Activer les tâches de maintenance automatiques".
• Cinquième écran "Information d'identification" pour simplifier utiliser le même mot de passe pour tous les comptes

• Sixième écran "Emplacement des fichiers", c'est là qu'il faut sélectionner le choix "Automatic Storage Management" pour le type de stockage et cocher "utiliser Oracle Managed Files (OMF) ,

cliquer ensuite "Parcourir" pour sélectionner la "zone de base de données". Comme nous avons choisi "ASM" la boite de sélection des groupes de disques s'ouvre et nous sélectionnons notre groupe "DATA" 
 
Nous pouvons ensuite passer à la suite.

• Septième écran : on nous demande le mot de passe de ASMSNMP (ne pas l'oublier !) qu'il faut fournir avant de continuer sur la "configuration de la récupération" (Flash-recovery ou Fast-recovery). Il faut cocher "Indiquer la zone de récupération rapide" et saisir "+RECO" pour le nom de la zone (ou cliquer "Parcourir" pour ré-ouvrir la boite de choix des groupes de disques) et laisser la taille proposée. Vous pouvez dès maintenant activer l'archivage (comme sur une "vraie" base).
• Huitième écran : cocher "exemples de schémas" pour bénéficier et SCOTT/TIGER et autres HR/HR, laisser tranquille l'onglet "Scrips personnalisés".
• Neuvième écran "Parametres d'initialisation", Onglet "Mémoire" : 
  mettre la Taille de la SGA vers 500 Mo, 
  cochez "Utilisez la gestion automatique de la mémoire". 
  Onglet "Dimensionnement" : la taille de bloc est figée à 8192 octest (conséquence de notre choix du modèle), réduire le nombre de processus à 100. 
  Onglet "Jeu de caractères" : c'est très important en production, ici on coche "Utiliser Unicode (AL32UTF8) et on laisse tel quel le "Jeu de caractère National", on positionne la langue par défaut à "Français" et le territoie par défaut à "France" (je suis un peu chauvin !). 
  Onglet "Mode de connection" : on coche mode serveur dédié car on ne compte pas avoir 3000 utilisateurs connectés.
• Dixième écran : "Stockage de la base de données" : on vérifie que tout est OK sur nos disques ASM, en principe rien à toucher pour nos tests.
• Sur l'écran suivant (le dernier) on coche "Générer les scripts de création de la base de données" pour pouvoir s'instruire plus tard et on clique "Terminer".

Le récapitulatif de notre paramétrage s'affiche 
 
Il est de bon ton de le vérifier, et même de 'enregistrer au format HTML pour historique, avant de confirmer. 
La création de la base démarre ensuite et est assez longue car il y a

1. du boulot
2. pas mal d'IO).

Selon l'heure un café ou une tisane peuvent être bienvenus. 
Pour finir un petit "Recap" des actions s'affiche, il rappelle notament l'adresse et le port à utiliser pour l'accès à la console d'admin (en https maintenant). 

on peut depuis cet écran aller "activer" certains utilisateurs (SCOTT/TIGER par exemple en confirmant ce mot de passe qui ne répond pas aux normes !), mais on pourra le faire plus tard par l'intérmédiaire de la consle d'administration.

Remarques : - pour la gestion des autorisations il faudrait, sur une base réelle, être beaucoup plus "fins" et créer différents groupes au niveau du système afin de pouvoir déléguer un certain nombre de tâches "administratives" (stop/start des instances par exemple, à des personnes n'ayant pas à disposer d'autres droits d'administrateur. 
Ceci est particulièrement vrai pour les privilèges "oper" destinés aux opérateurs qui doivent au moins pouvoir arrêter et démarrer la base.

. - La version 11gR2 intègre "Oracle restart" qui permet de démarrer et de stopper les éléments en respectant l'ordre des dépendances :  
- Asm doit avoir un "listener" pour fonctionner, 
- la base a besoin d'Asm pour démarrer ...

Oracle restart se commande en ligne de commande par "srvctrl (start|stop|status) (database|asm...) ..... 
Pour finir vérifions que tout est OK :

. oraenv 
ORACLE_SID = [orcl] ? orcl  
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/dbhome_1 is /opt/oracle

et on lance le test final

sqlplus scott/tiger 
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 17 02:36:07 2010 
Copyright (c) 1982, 2009, Oracle. All rights reserved. 
Connecte a : Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options 
SQL> select table_name from user_tables; 
TABLE_NAME ------------------------------ 
SALGRADE 
BONUS 
EMP 
DEPT

SQL> exit

Deconnecte de Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options

Tout baigne ... on va pouvoir lancer la console https:127.0.0.1:1158/em et après un "echec de la connexion sécurisée" et l'ajout d'une exception dans Firefox pour accepter le certificat voici la merveilleuse console d'administration : 

Pour finaliser l'installation de Oracle 11G il faut effectuer quelques ajustements :

• Modifier le fichier "/etc/oratab"
• Mettre en place les bonnes variables lors du login.
• Corriger deux scripts (dbstart et dbshut)

Le fichier /etc/oratab doit être légèrement modifié, il s'agit juste de déclarer notre base de données fonctionnelle en remplaçant un "N" par un "Y" :

# Multiple entries with the same $ORACLE_SID are not allowed. 
# 
# 
ORA11G64:/home/oracle/app/oracle/product/11.2.0/dbhome_1:Y

Mettre en place les "bonnes" variables lors du login :

Pour réaliser cette opération nous allons créer un petit fichier "/etc/default/oracle" contenant les déclarations de variables, celui-ci pourra être déclenché lors du login des utilisateurs ayant besoin d'un accès à Oracle par un appel dans le fichier ".bashrc". Ce petit fichier contiendra pour nous :

ORACLE_BASE=/home/oracle/app/oracle 
ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_1 
export ORACLE_BASE ORACLE_HOME 

PATH=$PATH':'$ORACLE_HOME'/bin' 
ORACLE_SID=ORA11G64 
export ORACLE_SID 

ORACLE_TERM=xterm 
LD_LIBRARY_PATH=$ORACLE_HOME/lib':/lib:/usr/lib' 
CLASSPATH=$ORACLE_HOME'/JRE:'$ORACLE_HOME'/jlib:'$ORACLE_HOME'/rdbms/jlib' 
ORATAB=/etc/oratab 
export ORACLE_TERM LD_LIBRARY_PATH ORATAB CLASSPATH

Le fichier ".bashrc" de "oracle" sera modifié comme suit :

# .bashrc 
# Source global definitions 
if [ -f /etc/bashrc ]; then 
. /etc/bashrc 
fi 
. /etc/default/oracle 

# User specific aliases and functions

La ligne en rouge est à ajouter. Il faut ensuite se déconnecter, se reconnecter et vérifier que les variables "ORACLE_..." sont bien en place, ici : 

env | grep ORACLE 
ORACLE_SID=ORA11G64 
ORACLE_BASE=/home/oracle/app/oracle 
ORACLE_TERM=xterm 
ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_1 
Aller modifier les scripts "dbshut" et "dbstart" situés dans $ORACLE_HOME/bin pour y ajouter une ligne qui permettra au "listener" de démarrer tranquillement sans besoin 'avoir recours à "lsnrctl start" systématiquement ou à " dbstart|dbshut $ORACLE_HOME ".

• dbstart. 
  79 # First argument is used to bring up Oracle Net Listener 
  80 ORACLE_HOME_LISTNER=$1 
  81 ORACLE_HOME_LISTNER=$ORACLE_HOME 
  Ajouter la ligne en rouge et supprimer la précédente si vous voulez ...
• dbshut 
  49 # The this to bring down Oracle Net Listener 
  50 ORACLE_HOME_LISTNER=$1 
  51 ORACLE_HOME_LISTNER=$ORACLE_HOME 
  Ajouter la ligne en rouge et supprimer la précédente si vous voulez ...

Les numéros de lignes sont valables pour ma version seulement .... 
On peut alors utiliser la commande qui lance la base de données :

dbstart 
Processing Database instance "ORA11G64": log file /home/oracle/app/oracle/product/11.2.0/dbhome_1/startup.log 
Et c'est parti, la base de données est activée, la preuve :

sqlplus system 

SQL*Plus: Release 11.2.0.1.0 Production on Fri Feb 12 16:15:14 2010 

Copyright (c) 1982, 2009, Oracle. All rights reserved. 

Enter password: 

Connected to: 
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options 

SQL>exit

Si vous voulez, en plus, l'accès par le web à la console Oracle il faudra lancer la commande :

emctl start dbconsole

Qui devrait vous renvoyer quelque chose comme : 
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0 
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved. 
https://k2000-ora64.jpp.fr:1158/em/console/aboutApplication 
Starting Oracle Enterprise Manager 11g Database Control .......... started. 
------------------------------------------------------------------ 
Logs are generated in directory /home/oracle/app/oracle/product/11.2.0/dbhome_1/k2000-ora64.jpp.fr_ORA11G64/sysman/log

Et vous permettre d'accéder au nirvana des DBA, grâce à un "https://serveur:1158/em" : 

That's all folk.

L'installation de la machine Linux étant terminée (et une image sauvegardée) on va pouvoir s'attaquer au plus gros : l'installation de Oracle avec ASM. 
Il y a d'abord un certain nombre de pré-requis pour que l'installation se passe sans anicroches (les pré-requis et l'image Linux de base ont été "pompés" d'un autre article !). 
Rappel : ceci n'est pas une installation destinée à la production mais une installation de test dont la sécurité n'est pas assurée correctement ! 

Ajouter les lignes suivantes dans le fichier "/etc/sysctl.conf" : 
------------------------------------------ 
# add for Oracle GRID 
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 = 9000 65500 
net.core.rmem_default = 262144 
net.core.rmem_max = 4194304 
net.core.wmem_default = 262144 
net.core.wmem_max = 1048576 
------------------------------------------ 
Ne pas oublier ensuite un "systcl -p" pour valider les modifiations. 

A modifier le fichier "/etc/security/limit.conf" et y ajouter : 
----------------------------------------- 
# for oracle 
@dba            soft    nproc   2047 
@dba            hard    nproc   16384 
@dba            soft    nofile  65536 
@dba            hard    nofile  131072 
-----------------------------------------

Nous sommes en test et nous n'allons pas séparer les privilèges entre "oracle" et "grid", nous installerons le tout par l'utilisateur "oracle" afin de simplifier l'installation.

Créer quelques groupes :

1. dba ( réservé à l'utilisation)
2. oinstall  (réservé à l'installation, sera "owner" du logiciel).

Créer l'utilisateur "oracle" membre des groupes : "oracle" en groupe primaire + "oinstall" et "dba". 
Mettre à jour la version Linux et initialiser "yum" : 
cd /etc/yum.repo.d 
wget http://public-yum.oracle.com/public-yum-el5.repo 

Lancer l'éditeur sur le fichier repo et passer à "enabled = 1" les repositories à utiliser (el5_ga_bas, el5_u4-base) 
Lancer un "yum repolist" qui déclenche le chargement des données de catalogue. 
Vous pouvez ensuite utiliser les commandes "yum" pour installer les paquets manquants :

1. libaio-devel
2. sysstat
3. unixODBC
4. unixODBC-devel

Un grand coup de "yum install ...." et c'est torché (presque aussi bien que aptitude). 
Installer les "bons" drivers pour ASMLIB, ceux ci dépendent du système, comme nous avons un Linux made by Oracle un petit coup de : 
yum search asm 
vous donnera la liste des candidats, ici je choisit (en fonction du noyau installé (uname -a)) : 
oracleasm-support.x86_64 : The Oracle Automatic Storage Management support programs. 
puis donc : 
yum install oracleasm-2.6.18-164.el5.x86_64 oracleasm-support.x86_64 
Comme il y a un driver au niveau du noyau un redémarrage est prudent pour véfifier. 
Après un reboot il reste encore des "choses" à faire pour ne pas tomber en rade lors de l'installation. 
Lancer la commande suivante pour vérifier l'espace partagé : 
df -h /dev/shm/ 
Chez moi elle donne : 
df -h /dev/shm/ 
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur 
tmpfs                 1,5G     0  1,5G   0% /dev/shm 
Ce qui devrait nous permettre d'utiliser un "MEMORY_TARGET" <= 1,5Go 
Beaucoup d'autres pré-requis sur l'espace nécessaire dans les différents filesystems, le swap, il faut aussi disposer d'un écran X de 1024x768 mini. Mais comme la partition unique destinée au système et au logiciel est dimensionnée généreusement cela ne devrait pas poser de problèmes. L'installation de Oracle Linux est normalement compatible si vous avez installé le système de développement car Oracle a besoin de compilateurs. 

Mise en place des chemins "qui vont bien" et des variables d'environnement communes à toute l'installation. J'ai créé un répertoire ORACLE dans /etc/default pour contenir ces infos communes. Ce fichier est exécuté (. /etc/default/ORACLE ) dans le fichier profile des utilisateurs concernés.

• ORACLE_BASE pointe ici vers notre répertoire "/opt/oracle"
• export ORACLE_BASE

Le tout placé dans le fichier "/home/oracle/.bashrc". 
Créer ensuite un fichier "99-oracle-rules" de règles dans "/etc/udev/rules.d" qui contiendra pour nous : 
# Regles pour ASM 
KERNEL=="hdb[1-9]", OWNER="oracle", GROUP="dba", MODE="0660" 
KERNEL=="hdc[1-9]", OWNER="oracle", GROUP="dba", MODE="0660"

Nous allons ensuite affecter 2 "disques" à la machine virtuelle en /dev/hdb et /dev/hdc. Ici il s'agira de deux partitions LVM sur deux disques physiques différents pour avoir de meilleures performances. Ces "disques" seront créés avec chacun une seule partition. 
Ces deux disques seront utilisés pour "imiter" une base de produtcion où, en dehors de toute option de performance, il ne faut pas oublier de séparer la base des fichiers permettant de la reconstituer (archives, double des "redologs", sauvegarde RMAN, zone de "flash-back"), ne serait-ce que pour assurer un minimum de sécurité :si on perd les données on aura les sauvegardes (RMAN), le double des redologs et la zone Flash. 
Ceci réalisé il sera possible de passer à l'opération suivante : Installation des éléments du "grid" où se trouve ASM et préparation des zones ASM destinées à recevoir notre BDD.

Comme d'habitude se rendre dans le répertoire où le logiciel a été décompressé, ici sur un montage Samba et lancer la commande "./runInstaller.sh" qui démarre l'installeur "OUI". Après quelques contrôles et un certain temps la fenêtre de "OUI" s'ouvre. 
Ouvrir un terminal "root" en ssh sur la machine, cela va servir ! 
  
Ecran 1 "Option d'installation", cocher "Installer ... pour un cluster, comme cela on pourra plus tard tenter le RAC puisque un "cluster" d'une seule machine ne mérite guère son nom ! 

Ecran 2 "Type d'installation", cocher "Installation Standard" 

Ecran 3 : "Configuration du cluster", garder les noms proposés (toute la partie réseau a été préparée pour cela). 
 
a) Il faut identifier les interfaces réseau, "eth0" en "public" et "eth1" en "privé". 
 
b) paramétrer la connexion ssh en la configurant puis en testant 
 

Ecran 4 : "Emplacement d'installation", Il faut (terminal "root" que vous avez déjà ouvert) créer le répertoire "11.2.0" dans /opt et faire un "chown oracle:dba 11.2.0", le rouge de la zone disparait alors par miracle. 
Il faut sélectionner "Automatic Storage Management" pour le "type de stockage...". Il faut aussi donner le mot de passe de "SYSASM" (c'est "dieu le père", l'équivalent du user "SYS" pour la base de données), ne pas perdre ce mot de passe ! Je sélectionne "dba" pour le groupe "OSASM". 

Mon mot de passe n'entre pas dans les règles il me faut donc confirmer, on voit d'ailleurs la zone en jaune sur l'écran. 
Ecran 5 : "Groupes de disque ASM", on ne crée ici que le groupe initial, on l'appelera "DATA" pour rester dans le standard. Cocher la redondance "externe" car un seul disque est réservé (je m'en fous c'est un RAID0 !à. Après avoir "modifié l chemin de repérage" 
 
on voit apparaître notre premier disque, rappelez vous celui réservé sur /dev/hdb1 en dehors de notre future "batterie" de disques. On sélectionne le disque "candidat". 
 

Ecran 6 : "Créer un inventaire", créer (terminal "root") le répertoire "/opt/oraInventory" et executer "chown oracle:dba oraInventory" et faire immédiatement "Suivant". 

Ecran 7 : "Vérification des pré-requis", si rien ne cloche il ne devrait pas y avoir de problèmes et l'écran "Récapitulatif" s'affiche : 

Et on clique "Fin" pour que cette N...! de machine se mette sérieusement à bosser et que je puisse aller déguster mon café : 
 

Enfin arrive le moment des scripts "root" (dans le beau terminal que vous avez ouvert) :

• /opt/oraInventory/orainstRoot.sh
• /opt/11.2.0/grid/root.sh

Le premier est une simple formalité, le deuxième est beaucoup plus importat (et long) car il configure réellement le "cluster".

./orainstRoot.sh 
Modification des droits d'accès de /opt/oraInventory. 
Ajout de droits d'accès en lecture/écriture pour le groupe. 
Suppression des droits d'accès en lecture/écriture/exécution pour le monde. 
Modification du nom de groupe de /opt/oraInventory en oracle. 
L'exécution du script est terminée. Pas bavard et court ! Il n'en pas de même pour le suivant : 
/root.sh 2>&1 | tee ROOT.LOG 
Running Oracle 11g root.sh script... 
The following environment variables are set as: 
    ORACLE_OWNER= oracle 
    ORACLE_HOME=  /opt/11.2.0/grid 
Enter the full pathname of the local bin directory: [/usr/local/bin]:

Après l'appui sur "Entrée" il se passe des choses (prévoir un deuxième café ou une petite promenade) ... la suite du listing en fichier attaché pour information. 
Après appui sur OK c'est reparti : 

pour le final (une minute!).Et c'est l'instant tant attendu : 

Après fermeture de la session X "oracle" il y a 41 processes qui tournent sous le user "oracle" !

L'étape suivante est : une bonne sauvegarde avant d'aller plus loin suivi d'un redémarrage pour vérifier que tout est toujours en place.

Au redémarrage, les disques sont toujjours là (et attribués à "oracle"), et nous pouvons remarquer que la machine est dotée de deux pseudo interfaces réseau supplémentaires et qu'elle répond bien aux noms supplémentaires préparés :

• k2000-ora65-vip 
  ping -c1 k2000-ora65-vip 
  PING k2000-ora65-vip.jpp.fr (192.168.1.150) 56(84) bytes of data. 
  64 bytes from k2000-ora65-vip.jpp.fr (192.168.1.150): icmp_seq=1 ttl=64 time=0.038 ms 
  
  --- k2000-ora65-vip.jpp.fr ping statistics --- 
  1 packets transmitted, 1 received, 0% packet loss, time 0ms 
  rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms
• k2000-o-cluster 
  ping -c1 k2000-o-cluster 
  PING k2000-o-cluster.jpp.fr (192.168.1.151) 56(84) bytes of data. 
  64 bytes from k2000-o-cluster.jpp.fr (192.168.1.151): icmp_seq=1 ttl=64 time=0.041 ms 
  --- k2000-o-cluster.jpp.fr ping statistics --- 
  1 packets transmitted, 1 received, 0% packet loss, time 0ms 
  rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms

Si l'on regarde les interfaces deux pseudo interfaces ont ét créés :

# ifconfig eth0:1 
eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:30:07:01   
          inet adr:192.168.1.151  Bcast:192.168.1.255  Masque:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          Interruption:177 Adresse de base:0x2000 
# ifconfig eth0:2 
eth0:2    Link encap:Ethernet  HWaddr 00:16:3E:30:07:01   
          inet adr:192.168.1.150  Bcast:192.168.1.255  Masque:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          Interruption:177 Adresse de base:0x2000 
..

Tout semble OK pour passer à l'étape suivante : configurer notre jeu de disques ASM pour accueillir en toute sécurité nos bases de données.

Après quelques vacances il va enfin être possible de se lancer dans l'installation de la base de données sur notre machine. Toutefois un incident de dernière minute (crash disque) retarde un peu la publication de cette partie. 
Bonne nouvelle (29/03/2010) le disque est changé, un système "propre" réinstallé. Il me reste juste à compiler et installer la dernière version (3.4.3-rc...) de XEN. 
Mais il me faut restaurer la machine virtuelle "RAC" car elle avait souffert lors du crash du serveur (elle était en pleine installation) et il me faut ré-installer la partie grid (excellent test du petit tutorial précédent) avant de pouvoir installer le logiciel et la base de données.Quelques soucis dans la nouvelle installation avec le SSD (il faut le "trimmer" pour améliorer les performances, et ce n'est pas évident, probablement un sujet à traiter), décidemment celà n'avance pas ! 
Le nouveau noyau linux/xen que je teste ne supporte que très mal Xwindows, il me faut donc me résoudre à installer "libvirt" et "virt-manager" sur une autre machine, à configurer le tout pour pouvoir me passer de X sur le serveur principal. Enfin, tout est prêt, la partie "grid" s'est installée sans problèmes (je pourrais maintenant l'installer quasiment les yeux fermés !), après une petite sauvegarde l'installation de la partie Base de Données peut commencer.

En ce qui concerne l'installation du logiciel et de la base de données il vaut mieux séparer les deux opérations car il me semble que l'assistant de création de base (dbca) ne présente pas toutes les options lorsqu'il est lancé depuis l'installeur.

Cette partie est assez simple, l'article sera court et avec peu de copies d'écran. 
Lancer l'installeur dans le répertoire d'installation : ./runInstaller.sh 
- Premier écran "Configurer les mises à jour" :

Tout décocher (il faudra confirmer après le clic sur suivant). 

- Deuxième écran "Options d'installation" : 
 
Cocher "Installer le logiciel de base de données uniquement". Copie écran avec la petite boîte explicative pour exemple. 

- Troisième écran "Options de grille" : 
 
Vérifier la connexion SSH. 

- Quatrième écran "Langues du produit" : ajouter les langues désirées, pour moi anglais + français cela me suffit ! 

- Cinquième écran "Edition de base de données" : 
Cocher "Entreprise Edition", on est là pour tout voir ! 
Le bouton "Sélectionner des options" peut permettre d'installer ou non certaines options, on n'y touche pas par principe. 

- Sixième écran "Emplacement d'installation" : 
Laisser les valeurs présentes ... pas de surprises, sauf un "dbhome_2" pour moi car j'ai du annuler (en cours) une installation précédente, et je n'ai pas détruit ce répertoire résiduel. 

- Septième écran "Groupes de système d'exploitation" : et hop "dba" pour tout le monde. L'enchainement sur la vérification ne devrait pas nous poser de problèmes ... et c'est bien le cas. 
 
Il est bon de passer tout cela en revue avant de cliquer "Fin". 
Et c'est parti ... 
 
le voyant du disque (physique) clignote frénétiquement pendant la copie des fichiers. Ce n'est pas super rapide et en plus le répertoire d'installation est sur un partage Samba. 
Le link des fichiers binaires est nettement plus rapide et arrive enfin le moment de passer le script "root.sh", je ne résiste pas à la prise d'une petite image ! 

./root.sh 
Running Oracle 11g root.sh script... 

The following environment variables are set as: 
    ORACLE_OWNER= oracle 
    ORACLE_HOME=  /opt/oracle/product/11.2.0/dbhome_2 
Enter the full pathname of the local bin directory: [/usr/local/bin]:  
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n)  
[n]: n 
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)  
[n]: n 
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)  
[n]: n 
Entries will be added to the /etc/oratab file as needed by 
Database Configuration Assistant when a database is created 
Finished running generic part of root.sh script. 
Now product-specific root actions will be performed. 
Finished product-specific root actions. 

Ensuite après le "OK" final un magnifique écran nous indiquant que l'installation a réussi, on n'en doutais pas ! 
 

Une fois la machine démarrée créer les partitions sur les disques "hdb" et "hdc" avec fdisk, une partiton par disque. Ne pas monter les nouvelles partitions et  lancer la commande "partprobe" pour valider ces nouvelles partitions auprès du noyau : 
partprobe /dev/hdb 
partprobe /dev/hdc 
Un reboot peut permettre de s'assurer que les disques sont bien "chownés" par le système au démarrage : 
ls -al /dev/hdb* 
brw-r----- 1 root   disk 3, 64 fév 21  2010 /dev/hdb 
brw-rw---- 1 oracle dba  3, 65 fév 21 14:01 /dev/hdb1 
Les partitions seront alors reconnues par le kernel. On peut ensuite quitter le user "root" et lancer l'interface graphique et se connecter avec le user "oracle". 
Vérifier que le répertoire d'installation (pour nous "/opt/oracle" est bien pointé par la variable "ORACLE_BASE" et que le répertoire est bien "chowné" "dba". 
Dans le répertoire d'installation, oui, celui où l'archive "zip"' a été décompressée, on trouve un sous-répertoire "grid" qui contient l'habituel "runInstaller.sh" qui permet le lancement de l'installer ("OUI" de son petit nom). 
drwxr-xr-x  9 1000 root    0 aoû 16  2009 doc 
drwxr-xr-x  4 1000 root    0 aoû 15  2009 install 
drwxrwxr-x  2 1000 root    0 aoû 15  2009 response 
drwxrwxr-x  2 1000 root    0 aoû 15  2009 rpm 
-rwxrwxr-x  1 1000 root 3795 jan  8 01:03 runcluvfy.sh 
-rwxr-xr-x  1 1000 root 3227 jan  8 01:03 runInstaller 
drwxrwxr-x  2 1000 root    0 aoû 15  2009 sshsetup 
drwxr-xr-x 14 1000 root    0 aoû 15  2009 stage 
-rw-r--r--  1 1000 root 4228 jan  8 01:04 welcome.html 
Un "./runInstaller.sh" lance le tout et on se retrouve après quelques vérifications devant l'écran :

Premier écran "Option d'installation" : On remarque sur cet écran (partie gauche) une échelle de suivi des différentes phases. Ici on choisira une installation pour un "...serveur autonome". Pas de RAC pour cette fois.

Deuxième écran : "Langues du produit" : ajouter la ou les langues désirées.

 
Troisième écran "Créer un groupe de disques", on ne créera ici qu'un groupe de disque sur les deux que nous avons définis. Nous ne sommes pas en production et je n'ai pas "plein" de disques. Je fais le chois de redondance externe pour le groupe par défaut "DATA" dans lequel nous allons intégrer notre partition "hdb1". Le disque n'étant pas reconnu par défaut par ASM il nous faut lui "forcer" un peu la main en passant par l'option "Modifier le chemin de repérage" où nous indiquerons "/dev/hdb1". Cocher ensuite ce disque "candidat".

 
Quatrième écran "Mot de passe ASM", je sélectionne un seul mot de passe pour les deux users "ASM" : SYS et ASMSNMP (ne pas confondre avec le user SYS de la base de données !). Si le mot de passe est "trop simple", il faudra confirmer notre "volonté" d'utiliser un mot de passe si simple ! 

Cinquième écran "Groupes de système d'exploitation" : on choisit "dba" pour les trois groupes. Encore une fois, en production il serait "sage" d'utiliser un groupe par catégorie d'activité. C'est déconseillé par Oracle --> il faut confirmer cette volonté délibéreé de faire simple (et pas très sécurisé). 

Sixième écran "Emplacement d'installation" : je laisse les emplacements par défaut dérivés de "ORACLE_BASE".

Septième écran " : corriger l'emplacement de l'inventaire par défaut en "/home/oracle/oraInventory".

Huitième écran "Vérification de prérequis" : normalement pas de problème ici l'installer passe ensuite à l'écran suivant.

 
Neuvième écran "Récapitulatif" (ORAGRI_004.png) on peut ici enregistrer les réponses pour les "rejouer" plus tard sur un autre serveur. 
L'installation est ensuite lancée ... 
Et le miracle s'accomplit ... 

C'est bon, on ferme avec soulagement. 

Pour le deuxième groupe de disques on commence par vérifier que nos disques seront bien accessibles par : 
ls -al /dev/hdc1 
brw-rw---- 1 oracle dba 22, 1 fév 16 03:12 /dev/hdc1

C'est OK, on commute dans le "bon" environnement par : 
. oraenv 
ORACLE_SID = [oracle] ?+ASM 
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/grid is /opt/oracle 
Suivi de (pour montrer le travail de "oraenv" : 
echo $PATH 
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin:/opt/oracle/product/11.2.0/grid/bin 
Suivi de la commande : 
asmca 
Qui lance l'écran principal de l'assistant asm 
 
On va ensuite créer notre deuxième groupe de disques par le bouton intelligement appelé "Créer" 

on modifie le chemin de repérage en "/dev/hd*"  et on coche notre disque "/dev/hdc1" et on clique "OK". Le groupe de disque "RECO" est alors créé 
.

Ne croyant que ce que je vois je tente le reboot. Après le reboot, voyons si notre "disque" ASM est bien là en utilisant un autre type de commande (asmcmd fait partie du paquet, c'est une sorte de shell permettant d'explorer les disques ASM) : 
. oraenv 
ORACLE_SID = [oracle] ? +ASM 
... 
asmcmd 
ASMCMD> ls -al 
State    Type    Rebal  Name 
MOUNTED  EXTERN  N      DATA/ 
MOUNTED  EXTERN  N      RECO/ 
ASMCMD> exit 
Nos deux disques sont bien là ... tout à l'air OK on va pouvoir prendre une image de notre machine et lancer l'opération suivante.

Dans ce chapitre nous allons créer notre première base de données grâce à l'assistant de création de bases de données, j'ai nommé "dbca". Plus besoin de recourir aux CD d'installation, tout fonctionne maintenant "en local", nous avons pris notre indépendance. 

 Le but de cet article est de présenter l'installation d'une base de données à la fois performante et sécurisée. 
L'installation sera faite sur deux groupes de disques, un pour les données, un pour la zone de sécurité (Fast Recovery Area). Cette zone de sécurité doit permettre de redémarrer une base saine même en cas de perte (ou de corruption) des disques principaux. 
Un petit schéma valant mieux qu'un long discours ... 
 
Cette configuration ne se prête pas au "vrai" RAC car les disques internes ne seront pas partageables entre deux instances. On verra cela un peu plus tard. 

Après cette petite mise en bouche connectons nous un terminal sous X et dans le bon environnement : 
. oraenv 
ORACLE_SID = [oracle] ? 
ORACLE_HOME = [/home/oracle] ? /opt/oracle/product/11.2.0/dbhome_2 
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/dbhome_2 is /opt/oracle

Lançons l'assistant de création "dbca" qui nous accueille après avoir murement réfléchi i 
"Etape 0 ?" : Premier écran "Bienvenue" 
 
Cocher "Base de données RAC".

• "Etape 1" : cocher "Créer une base de données".
• "Etape 2" : cocher "BD généraliste... Sur cet écran on peut déjà avoir un avant-goût de ce que sera notre base ("Afficher les détails"), au détail près de ASM qui n'est pas pris en compte dans le modèle.
• "Etape 3" : je coche "Configuration gérée par un administrateur",

je coche "Configuration gérée par un administrateur". 
je choisis le nom "rac001" 
Un seul cluster étant présent pas d'angoisse de choix. 

"Etape 4 " : 
Premier onglet : 

• Cocher "Configurer Entreprise Manager"
• Cocher "Configurer Database control", "Activer les notifications d'alerte"
• Fournir l'adresse d'un serveur mail valide (c'est vérifié !) et une adresse non moins valide.
• Cocher "Activer la sauvegarde....", on pourra la gérer "à la main ensuite"

Donner le user et le password d'un utilisateur autorisé à effectuer les sauvegardes. Pour nous un utilisateur avec les droits "dba". 
Deuxième onglet : vérifier que les "taches de maintenance automatique" sont bien cochées. 

"Etape 5" : par simplification je coche "Utiliser le même mot de passe pour tous les comptes" et donne un mot de passe (trop simple qu'il faudra confirmer par la suite). 

"Etape 6" : 
 
. Pour "Type de stockage" choisir ASM 
. cocher "Utiliser OMF" 
. "Zone base de données", choisir "DONNEES" qui affichera +DONNEES dans la boite. 

Cliquer "Multplexer les fichiers ..." : 
 
Indiquer ici le groupe principal +DONNEES et le groupe de sécurité +SAUVE 
Rappel le "+" pour ASM correspond au "/" pour un filesystem Unix. 

Inutile de cliquer "Variables d'emplacement de fichier" : 
Lors du clic sur "Suivant" une boite demandant le mot de passe ASM s'ouvre. 

"Etape 7" : 
Ici les choses importantes, on sépare les données de sécurité des données de la base, il faut donc cocher "Indiquer la zone de récupération rapide" et la faire pointer sur "+SAUVE", augmentons un peu la taille à 5120M. Cette zone est fonction de la taille de la base hébergée. Au passage quelqu'un aurait-il une base de 4 à 6 G à prêter ? ... 
Cocher "Activer l'archivage", c'est indispensable (et je ne parle même pas d'une base de production OLTP). 
Inutile de cliquer "Variables d'emplacement de fichier". 

"Etape 8" : 
. Premier onglet, je coche "Exemples de schémas" car je suis un addict de scott/tiger et du schéma HR. 
. Deuxième onglet, je n'ai pas de scrpts personnalisés. 

Etape 9 : 
. Premier onglet "Mémoire" : 
 
pour des tests je limite la taille mémoire à 640M et je coche "Utiliser gestion auto" 
Deuxième onglet "Dimensionnement" : la taille de bocs n'est pas modifiable ... et 150 processus est un bon chiffre ... on ne touche rien. 
Troisième onglet "Jeu de caractères" : 
 
Je sélectionne "Utiliser Unicode" et laisse les autres valeurs par défaut. 
. Quatrième onglet : je coche "Mode serveur dédié" 
Je ne touche pas à "Tous les paramètres d'initialisation", mais je vais y jeter un oeil. 

"Etape 10 " : 
On peut ici vérifier (et éventuellement modifier les éléments de stockage). 

"Etape 11" : cocher "Créer une base de données" et "Générer les scripts", stocker les scripts où vous voulez ! 
Et on arrive au moment fatidique de cliquer sur le bouton "Terminer" ce qu'il est fortement conseillé de faire. 
Un écran récapitulatif s'affiche et permet de vérifier toute la configuration qui peut même être enregistrée en fichier HTML pour historique. 
On clique "OK" et c'est parti .... d'abord la création du script ... "OK" ... 
 
et je n'ai pas besoin cette fois de cliquer "Arrêter". 
Le voyant disques clignote frénétiquememt .. tout semble se dérouler correctement, largement le temps de prendre un café. 
Enfin la base est créée ... 
 
je ne touche pas à la gestion des mots de passe ... et clique sur "Quitter". 
Le fichier "/etc/oratab" comporte bien une nouvelle ligne "rac001......" et un "ps -ef | grep rac001" montre une belle liste de process. 
Une connexion https montre (après avoir accepté le certificat SSL) une belle image : 
 
Enfin on va pouvoir s'amuser ... mais auparavant il nous faudra initialiser quelques variables permettant de discuter avec cette instance (rac0011) de la base de données (rac001).

Comme indiqué en fin du chapitre précédent il reste un certain nombre de manipulations à effectuer avant de pouvoir accéder "normalement" à la base. En effet ce n'est pas une base "normale" mais l'instance numéro un d'une base RAC.

Pour simplifier les choses j'ai préparé un script ( à lancer en début de connexion par ". mon_script" ) :

# My Oracle Settings 
export ORACLE_SID=rac001 
export ORAENV_ASK=NO 
. oraenv 
export TMP=/tmp 
export TMPDIR=$TMP 
export ORACLE_HOSTNAME=k2000-ora65 
export ORACLE_UNQNAME=rac001 
export ORACLE_BASE=/opt/oracle 
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_2 
export ORACLE_TERM=xterm 
export PATH=/usr/sbin:$PATH 
# export PATH=$ORACLE_HOME/bin:$PATH  
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib 
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib 
ORAENV_ASK=''

Une fois le script de lancement exécuté notre environnement est "propre" et nous pouvons utiliser les commandes classiques. 
D'abord démarrer l'instance : 
srvctl start instance -d rac001 -i rac0011 
on peut ensuite se connecter avec sqlplus : 

sqlplus sys@rac001 as sysdba 
SQL*Plus: Release 11.2.0.1.0 Production on Sat Apr 10 11:23:14 2010 
Copyright (c) 1982, 2009, Oracle.  All rights reserved. 
Enter password:  
Connecte a : 
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production 
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, 
Data Mining and Real Application Testing options 
SQL> 

Et c'est parti ... tout est OK. 
Toutes ces opérations sont faites "en manuel" il faudra automatiser tout cela dès que possible.

Premier essai : connectons nous avec sqlplus et créons un premier tablespace : 
CREATE TABLESPACE "TEST_SPACE" DATAFILE 
  SIZE 512M 
  AUTOEXTEND ON NEXT 32M MAXSIZE 1024M; 
Avec "OMF" et "ASM" pas la peine de nommer le datafile, le pied pour les paresseux.

Ensuite n'oubliez pas de lancer la console Web par :

emctl start dbconsole

Après un temps certain vous pourrez découvrir (en https maintenant) la console Web qui n'a pas fini de vous occuper car on peut tout faire depuis cet outil :

• Gérer la base de données :
  • instance par instance (database instance)
  •  globalement (cluster database)
• Gérer le "cluster"
• Gérer ASM, pour y aller passer par l'onglet "cluster" (en haut à droite) puis dans le nouvel écran l'onglet "target" qui donne accès à une liste des objets gérables, y compris notre console ASM.
• Gérer les listener

Il y a beaucoup à découvrir, y compris du coté des backups ou RMAN est particulièrement bien "empaqueté" et si facilement utilisable : backups compressés, backups incrémentaux, backups "online" ... 
Allez aussi voir du coté des "advisors" en passant pas "Advisor central" (lien disponible entre autres endroits en bas à droite de la page "Home"). 
La surveillance des performances n'est pas en reste et permet de surveiller la performance :

• au niveau du cluster
• au niveau d'une instance
• au niveau de ASM.

En bref cette console est un monde à part entière a découvrir et offre réellement un très grand nombre de possibilités. 
Si vous cherchez les fichiers de trace (donr le célèbre alert...log) rendez vous dans : 
$ORACLE_BASE/diag 
où une arborescence fournie vous attends, allez voir dans "rdbms/nom_base/nom_instance" pour voir.

Le nouveau système se lance bien, on a le choix entre deux versions de kernel 5.15 et 4.18, je laisse démarrer sur le 5.15 par défaut et comme j'ai choisi un mode "graphique" une session X s'ouvre. 
Après avoir indiqué user/mot de passe il faut terminer le configuration de l'utilisateur courant et accepter ou refuser quelques "contraintes" telles que la géolocalisation et la transmission de données de fonctionnement (rapports de plantage). 
L'aspect visuel est "classique" et tout fonctionne normalement. 
Il faut maintenant monter et formater les deux disques (Data et Index) prévus pour cette machine. Pour ce faire une connection en "root" sera utilisée. 
Sur les deux disques (125 GO chacun) j'implante sur chacun des deux disques (vdb et vdc) : 
- Une table de partitions GPT 
- Une partition unique de 125Go 
Les deux partitions sont formatées en xfs : 
mkfs -t xfs /dev/vdb1 
meta-data=/dev/vdb1        isize=512    agcount=4, agsize=8191935 blks 
         =                 sectsz=512   attr=2, projid32bit=1 
         =                 crc=1        finobt=1, sparse=1, rmapbt=0 
         =                 reflink=1    bigtime=0 inobtcount=0 
data     =                 bsize=4096   blocks=32767739, imaxpct=25 
         =                 sunit=0      swidth=0 blks 
naming   =                 version 2    bsize=4096   ascii-ci=0, ftype=1 
log      =                 internal log bsize=4096   blocks=25600, version=2 
         =                 sectsz=512   sunit=0 blks, lazy-count=1 
realtime =                 none         extsz=4096   blocks=0, rtextents=0 
Discarding blocks...Done. 
Et "baptise" mes deux nouveaux FS : DATA et INDEX. 
Il faut pour cela utiliser la commande "xfs_admin" avec les "bonnes" options, ici : 
xfs_admin -L DATA  /dev/vdb1 
writing all SBs 
new label = "DATA" 
xfs_admin -L INDEX /dev/vdc1 
writing all SBs 
new label = "INDEX"

On teste que le montage de nos disques est OK : 
mount LABEL=DATA /u/DATA 
mount LABEL=INDEX /u/INDEX 
Vérification : 
df /u/* 
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur 
/dev/vdb1          130968556  946168  130022388   1% /u/DATA 
/dev/vdc1          130968556  946168  130022388   1% /u/INDEX

Le montage est OK, on va pouvoir mettre à jour /etc/fstab pour le montage automatique de ces deux File Systems avec utilisation du "nom" des disques. 
Avec la syntaxe "xfs" il suffit d'ajouter en fin du fichier fstab : 
LABEL=DATA    /u/DATA     xfs  nodiratime,relatime 1 2 
# 
LABEL=INDEX    /u/INDEX     xfs  nodiratime,relatime 1 2 
Au reboot tout se passe bien et mes deux partitions DATA et INDEX sont bien présentes. 
J'installe immédiatement mon éditeur indispensable et préféré : 
dnf install vim-X11.x86_64 
Maintenant que le "support" est OK, on va pouvoir passer à la suite, installer Oracle 23c.  
Note : 
Deux Kernels sont proposée : 5.15 et 4.18, pas encore de 6.0, mais le 5.15 devrait nous suffire.

Après le redémarrage de la machine on a accès au "login", ici en mode graphique car j'aime bien utiliser Gvim pour la maintenance des fichiers de paramétrage.

Tout a l'air OK on peut lancer les opérations d'installation : 
1) Télécharger les deux RPM d'installation dans un répertoire tranquille : 
- pre-install 
wget https://yum.oracle.com/repo/OracleLinux/OL8/developer/x86_64/getPackage/oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm 
- oracle-database-free-23c 
wget https://download.oracle.com/otn-pub/otn_software/db-free/oracle-database-free-2…;
2) Installer le RPM "preinstall" 
yum -y localinstall oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm 
3) Installer Oracle 23c 
yum -y localinstall oracle-database-free-23c-1.0-1.el8.x86_64.rpm 
Au vu du volume (1,67Go) cela promet d'être assez long, mais cela se termine quand même. 
Note : 
Le paquet "preinstall" crée un fichier "/etc/sysctl.d99-oracle-database-preinstall-23c-sysctl.conf" qui contient tous les paramètres conseillés par Oracle, donc pas besoin de bricoler de ce coté. 
La prochaine étape : configurer la base et cela se réalise (en tant que "root") avec : 
/etc/init.d/oracle-free-23c configure

Ici pas de mode graphique, tout est enchaîné depuis le script de configuration. 
 

On a un beau système, performant, efficace, je vous laisse imaginer différentes manières de s'en servir mais on peut, par exemple :

• Spécialiser un serveur dans l'écriture, L'autre dans la lecture, par exemple pour la création de ces gros rapports dont raffolent certaines personnes et qui "écroulent" le serveur principal.
• Spécialiser une des machines en écriture, l'autre en lecture. On peu faire ce type d'utilisation à l'aide d'adresses IP virtuelles (1 pour l'écriture, l'autre pour la lecture), un système de fail-over permet en cas d'incident sur l'un des serveurs bascule les 2 VIP sur le serveur valide..

​Une Sauvegarde quasi "ON LINE". 

Sauvegarde non testée --> DANGER, n'oubliez de tester une restauration ...

Passons maintenant à la pratique du passage en "maître / maître" !

Le principe du maître / maître est très simple, chaque machine est à la fois le maître et l'esclave de l'autre. 
Cela impose quelques contraintes déjà connues telles que d'utiliser différentes valeurs de "server-id" et, comme précisé dans le précédent article, d'utiliser des valeurs correctes de "auto-increment-increment" et "auto-increment-offset" afin de limiter les risques de doublons. 
Il est par ailleurs déconseillé d'utiliser les deux machines en écriture simultanément car un risque de corruption existe. Il est par contre intéressant au niveau de la performance globale d'utiliser une machine en écriture et de diriger vers l'autre les applications en lecture seule, particulièrement des applications grosses consommatrices de lecture : états et statistiques diverses. Le retard entre les deux machines est en général à peu près négligeable. 
Ce type de redondance permet par contre un basculement extrêmement rapide en car d'incident sur le serveur "écriture". Les adresses IP virtuelles permettent de réaliser la basculement sans délai ni manipulation complexe et cela peut être automatisé à l'aide de divers outils.

Pour simplifier nous nommerons S1 et S2 les deux machines. Les deux opérations à réaliser sont extrêmement simples :

• Rendre S2 "esclave" de S1, et lorsque cela est réalisé passer à la phase suivante
• Rendre S1 "esclave" de S2.

1) Rendre S2 esclave de S1. 
Les commandes suivantes permettent : 
d'autoriser S2 à se connecter comme esclave :​

Lorsque cette opération est réalisée, on teste un peu en redémarrant chacun des deux serveurs et en vérifiant la synchro à l'aide des commandes : 
SHOW MASTER STATUS; 
et 
SHOW SLAVE STATUS\G 
(le \G permet un affichage plus agréable .... pour les quelques malheureux qui l'ignorent encore).

Il est alors possible d'effectuer les tests habituels de création de table et d'insertion de rangs en vérifiant bien que les séries des identifiants attribués diffèrent bien entre les deux machines. Cela marche aussi avec trois machines en utilisant les "bons" paramètres d'incrément pour créer les séries 1,4,7,10; 2,5,8,11 et 3.6.9.12 ... 

Le maître/maître ... mais c'est très simple !

A partir de là, tout ce qui se passe dans un des deux serveurs est reproduit sur l'autre. 

Si vous recopiez vos données par export (d'un autre système) + import dans le groupe maître/maître (vidé de préférence) cela fonctionne bien. Il faut, là encore, bien synchroniser vos deux serveurs avant le début de l'import des données. 
L'import dans l'un des serveurs sera reproduit fidèlement dans le second. 
A ce propos, si vous utilisez des "events" ils seront en état "ENABLED" dans le serveur dans lequel a été réalisé l'import et en l'état "SLAVE_DISABLED" dans l'autre. Ainsi pas de risque de déclenchement de deux traitements en parallèle. 
 

Vous trouverez vite quelques inconvénients à cette réplication car certains ordres SQL ne fonctionnent pas (ou plus). 
Par exemple "create table as select * from ... where AA = '3' ", bien commode pourtant, vous jettera à la figure un message : 
ERROR 1786 (HY000): CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1. 
En effet cette construction est un concentré de deux ordres SQL : CREATE TABLE + INSERT et comme il s'agit d'une seule transaction elle n'aura qu'un "Transaction ID" et le slave recevra deux ordres différents le CREATE et l'INSERT avec un même TID, or un bon esclave n'exécute pas deux fois le même ID de transaction, il ferait le CREATE mais pas l'INSERT ! 
C'est un peu stupide, mais on arrive à s'y faire. 
D'autres inconvénients existent lors d'un mélange de tables MyISAM et InnoDB car InnoDB supporte les transactions mais pas MyISAM d'où d'autres messages parfois sybillins, mais je pense que vous n'avez plus de tables MyIsam ! C'est si facile de les convertir ... 
C'est peut-être un bon motif pour abandonner le MyISAM au profit de InnoDB pour vivre dans un monde transactionnel et maître/esclave sans erreurs superflues et sans "CREATE TABLE ... AS SELECT" (sniff). 
Ah, aussi, on ne peut pas créer de tables temporaires dans une transaction, il faut les créer en dehors de tout contexte transactionnel pour que cela se passe bien. 
Il semble d'ailleurs que le problème du "CREATE AS SELECT" soit résolu dans les dernières versions en choisissant bien le bon mode pour le binlog_mode.

Préambule.

Les configurations suivantes sont adoptées, elles sont "légères" mais largement suffisantes pour nos tests :     
  - GALE_1 : future machine "Maxscale"     
    Disque 40GB     
    Mémoire 2048M     
    2 VCPU     
 - GALE-2, GALE-3 et GALE-4 nos trois machines bases de données :     
    Disque 40GB     
    Mémoire 4096M     
    2 VCPU     
Le partitionnement adopté, volontairement simple, est suffisant pour des tests :     
   /boot 656Mo     
   / 36Go     
   Swap 3,5Go

Les deux premières machines ont été installées "normalement" à partir d'une image ISO, les machines 3 et 4 ont été "clonées" depuis la machine 2 après l'installation de la base de données et les premiers tests de validation. "dd" est un bon ami.

Installation.     
Il faut commencer par installer la définition du repository spécifique à MariaDB qui installe tout ce qu'il faut pour MariaDB, Maxscale et quelques outils complémentaires.     
- Commencer par installer les outils curl, net-tools, vim ou gvim-gtk3 ...     
Pour pouvoir ensuite installer, valider, suivre et mettre à jour confortablement tout ce qu'il faut pour un système "normal".     
- Installer le repository MariaDB :     
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash     
Ce script gère tout, y compris un "apt update" pour mettre à jour les listes de paquets.      
Comme les machines sont installées en Debian Bullseye on est limité aux versions 10.5 de MariaDB, 22.08 de Maxscale et Galera 3 ou 4 (on utilisera bien sûr la version 4).     
- On installe ici (GALE-2) MariaDB et Galera :     
apt install mariadb-client-10.5 mariadb-server-10.5 galera-4     
Cela récupère un paquet de dépendances : #28Mo d'archives et promet d'occuper 213MO sur disque.     
Après le fatidique "sysctl start mariadb" tout se passe bien !    
Lancée sous "root" la commande "mysql" nous lance gentiment le client connecté à notre nouvelle base.      
On peut alors mettre un mot de passe à l'utilisateur "root", limité à localhost et créer un compte spécifique d'administration avec une visibilité plus importante (/24 par exemple). Bien le faire avant le clonage de GALE-2 sur les deux machines suivantes.

Le système "modèle" est prêt et on peut le cloner dans les deux autres machines, il suffira de changer :     
- hostname      /etc/hostname     
- IP                  /etc/network.interfaces IP statiques    
et pour la base MariaDB.     
- server_id      /etc/mysql/mariadb.conf.d/50-server.cnf      
y mettre 2,3 et 4, les numéros de nostrois  braves machines.     
Maintenant que nos trois machines bases de données sont prêtes on va pouvoir passer à la mise en service de Galera ce qui promet d'être plus amusant.

Avant de se lancer dans Galera proprement dit il vaut mieux "arranger un peu" la configuration de MariaDB. 
Par exemple mettre les fichiers "binlog" ailleurs que dans /var/log/mariadb ! 
J'ai donc ici créé un répertoire /var/lib/binlogs : 
mkdir /var/lib/binlogs 
chown mysql: /var/lib/binlogs 
et modifié en conséquence le fichier /etc/mysql/mariadb.conf.d/50-server.cnf. 
 

Pour Galera le fichier de paramétrage est /etc/mysql/mariadb.conf.d/60-galera.cnf, voir ci-dessous mon paramétrage :

#
# * Galera-related settings
#
[galera]
# Mandatory settings
wsrep_on                 = ON
wsrep_provider           = "/usr/lib/libgalera_smm.so"
wsrep_cluster_name       = "clustertest"
#
wsrep_node_name          = gale-2
wsrep-node-address	 = 192.168.2.153
#
wsrep_cluster_address    = "gcomm://192.168.2.153,192.168.2.154,192.168.2.155"
binlog_format            = row
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2
# Allow server to accept connections on all interfaces.
bind-address = 0.0.0.0
# Optional settings
wsrep_slave_threads = 1
innodb_flush_log_at_trx_commit = 0
# pour restart si cluster planté
wsrep_provider_options="gcache.recover=yes"

Pour le premier lancement il faut impérativement utiliser la commande suivante : 
mysqld --wsrep-new-cluster 
sur chacun des trois membres du cluster.  
Malheureusement cette commande ne "rends pas la main" j'ai donc du passer par la suite de commandes suivantes : 
mysqladmin shutdown 
systemctl start mariadb 
pour "rendre la main" et démarrer normalement, j'ai fait cela sur chacun des nœuds en laissant un petit temps intermédiaire pour laisser les machines se re-synchroniser.

Pour contrôle je crée une base : 
CREATE DATABASE montest; 
Et je vérifie qu'elle est bien créée sur les trois nœuds, youpi cette base existe bien partout ... c'est le pied. 
De même la création d'une table de test est parfaitement répliquée sur les trois nœuds : 
Create Table: CREATE TABLE `TT` ( 
 `ID` bigint(20) NOT NULL AUTO_INCREMENT, 
 `ZONE` varchar(32) DEFAULT NULL, 
 PRIMARY KEY (`ID`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

Vérifions maintenant l'insertion : 
Sur le nœud gale-2 (nœud 1) : 
insert into TT (ZONE) values ('UN'); 
Sur les deux autres nœuds on voit :

select * from TT;
+----+------+
| ID | ZONE |
+----+------+
|  3 | UN   |
+----+------+

Tiens, l'autoincrement débute à 3 ? 
Voyons voir un insert sur le nœud gale-3 (nœud 2) : 
insert into TT (ZONE) values ('DEUX'); 
L'ID généré est égal à 5. 
Un insert sur le nœud gale-4 (nœud 3) : 
insert into TT (ZONE) values ('TROIS'); 
L'ID généré est égal à 7; 
Retour sur le nœud 1 qui génère un ID à 9; 
En bref cela à l'air de bien fonctionner ... 
On essaye un arrêt de toutes les machines machines, puis on les redémarre, et ... c'est la catastrophe, rien ne redémarre. 
Il faut chercher quel était le nœud "maître" en examinant les fichiers "grastate.dat" (dans /var/lib/mysql) et chercher celui qui possède la ligne "safe_to_bootstrap: 1". 
Ici c'est le nœud "gale-4" qui a été stoppé en dernier ... donc il doit pouvoir repartir car il est réputé le plus à jour. Si aucun fichier ne comporte cette mention (cas de crash simultané) il faudra en éditer un "à la main" et mettre la valeur à 0. Dans le cas précédent le noeud "gale-4" démarre normalement, les autres peuvent alors démarrer et se connecter au cluster.

Si la situation est réellement "sérieuse" (refus complet de démarrage) mettre à jour le fichier "/var/lib/mysql/grastate.dat" de la machine stoppée en dernier et y forcer la valeur 0 dans la ligne "safe_to_bootstrap:", les autres membres du cluster pourront alors être démarrés avec un simple "systemctl start mariadb".

Utilisation du paramètre "wsrep_provider_options="gcache.recover=yes" ne change rien ... par contre en utilisant la commande "galera_new_cluster" sur le nœud 4 celui-ci démarre normalement et le démarrage des deux autres est alors possible ... Ouf! Le cluster se comporte ensuite normalement et il est possible de démarrer les autres systèmes avec "systemctl start mariadb".  
La commande "galera_new_cluster" ne fonctionne directement que sur la dernière machine stoppée du cluster afin d'être sûr qu'aucune donnée ne sera perdue. 
Souvenez-vous de cette commande ... qui peut servir en cas d'incident grave ou pour des machines de test que l'on stoppe souvent. 
Sinon il faut aller s'intéresser au fichier "/var/lib/mysql/grastate.dat" et, éventuellement (si la dernière machine stoppée est hors-service) et y passer la valeur de "safe_to_bootstrap" de 0 à 1. Mais le risque sera de perdre les dernières données traitées avant l'arrêt de la dernière machine du cluster.

Le redémarrage d'un seul des membres de notre cluster se passe fort bien et chacun des autres nœuds note que ce membre a disparu : 
2022-11-01 18:01:03 0 [Note] WSREP:  cleaning up e713c304-9429 (tcp://192.168.2.155:4567) 
192.168.2.155 est l'adresse du membre qui s'est absenté, lorsqu'il redémarre il se signale et les deux autres membres constatent ce fait avec un message : 
2022-11-01 18:03:24 0 [Note] WSREP: Member 0.0 (gale-4) synced with group. 
Une fonction qui peut être utile pour signaler ce type d'événement est disponible dans le paramétrage de Galera :

wsrep_notify_cmd = 'une commande shell' 
Cette commande permet de signaler les événements importants. 
J'en ai installé une très simple sur le nœud GALE_2 : 
#!/bin/bash 
FLOG=/var/tmp/MSG.LOG 
DTT=$(date +%Y/%m/%d_%H:%M:%S) 
echo ${DTT}' | '$* >>${FLOG} 
Lors du démarrage des machines (dans l'ordre inverse de celui dans lequel elles ont été stoppées, (le dernier membre actif doit redémarrer le premier) on obtient l'affichage suivant :

23:52:04 | --status connected
23:52:04 | --status joiner
23:52:04 | --status initializing
23:52:05 | --status initialized
23:52:05 | --status joined
23:52:05 | --status joined --uuid 28736ddb-59f8-11ed-abde-fe2234c75fO
23:52:05 | --status synced
23:53:15 | --status synced --uuid 28736ddb-59f8-11ed-abde-fe2234c75fO
23:53:15 | --status donor
23:53:15 | --status joined
23:53:15 | --status synced
23:54:42 | --status synced --uuid 28736ddb-59f8-11ed-abde-fe2234c75fO
23:54:42 | --status donor
23:54:42 | --status joined
23:54:42 | --status synced

C'est très anormal que toutes les machines soient stoppées, mais cela peut arriver, tant qu'il reste une machine en fonction les autres peuvent venir s'abonner au cluster et tout se passe bien.

Le seul problème est que lors de la "panne" d'une machine son adresse IP ne réponds plus et les clients n'ont plus accès aux données et établir un système de haute disponibilité entre trois machines n'est pas une sinécure. 
C'est là l'avantage d'utiliser Maxscale qui va, entre autres choses gérer l'accès à notre cluster. Maxscale permet de gérer des clusters disposant de plus de 3 nœuds, nous verrons cela dans un prochain chapitre ... à suivre 
 

Cet article détaille, un peu, la mise en place de Maxscale.

Le paramétrage est relativement simple mais les dernières présentent un petit "piège" car l'adresse d'écoute par défaut est une adresse IPV6 et cela pourrait vous surprendre. Il est donc important de préciser "address=0.0.0.0" (ou une autre adresse IPV4) dans le paramétrage de Maxscale. 
D'abord la définition des serveurs du cluster Galera :

# Server definitions
#
[gale-2]
type=server
address=192.168.2.153
port=3306
protocol=MariaDBBackend
#
[gale-3]
type=server
address=192.168.2.154
port=3306
protocol=MariaDBBackend
#
[gale-4]
type=server
address=192.168.2.155
port=3306
protocol=MariaDBBackend

J'ai ensuite décidé de créer deux "voies d'accès" :

1. Une en lecture seule
2. Une en lecture/écriture

[lect-seule]
type=service
router=readconnroute
servers=gale-4
user=util_services
password=xxxxxxxx
router_options=running
# ReadWriteSplit documentation:
# https://mariadb.com/kb/en/mariadb-maxscale-6-readwritesplit/
[ecri-lect]
type=service
router=readwritesplit
servers=gale-2,gale-3
user=util_services
password=xxxxxxxx

Une fois ces deux services créés il faut leur affecter un "listener" qui permettra l'accès à nos services, nous aurons donc deux "listeners".

[Read-Only-Listener]
type=listener
service=lect-seule
protocol=MariaDBClient
port=3007
address=0.0.0.0
[Read-Write-Listener]
type=listener
service=ecri-lect
protocol=MariaDBClient
port=3006
address=0.0.0.0

C'est ici qu'il faut préciser l'adresse au format IPV4 pour éviter le piège de l'IPV6 par défaut.

Enfin le dernier paragraphe pour fixer les paramètres du monitoring de nos 3 serveurs :

# This will keep MaxScale aware of the state of the servers.
# MariaDB Monitor documentation:
# https://mariadb.com/kb/en/maxscale-6-monitors/
#
[MariaDB-Monitor]
type=monitor
module=mariadbmon
servers=gale-2,gale-3,gale-4
user=xxxxxxx
password=yyyyyyyy
monitor_interval=2s

Ne pas oublier de "protéger" ce fichier par :

chown maxscale: /etc/maxscale.cnf 
chmod 600  /etc/maxscale.cnf 

Le GUI de gestion de Maxscale.

Il est accessible sur le port 8989 de la machine selon les paramètres du fichier de configuration :

# MAXGUI 
admin_host=192.168.2.152
# GUI without SSL
admin_secure_gui=false

Ici j'ai inhibé le SSL ce qu'il ne faudrait pas faire en production ... 
Le premier écran qui s'affiche est l'écran de surveillance (Dashboard) de notre cluster Galera première option a gauche dans le menu horizontal.

Cet écran présente l'état de notre cluster, on y voit l'état de notre cluster "Running" en vert dans la colonne "STATE" et la liste de tous les membres du cluster avec le nombre de connexions, leur état (autre colonne "STATE"). 
Le master a droit à la couleur verte et au statut "Master, Running", les deux autres à une mension rouge et Running, donc tout va bien. La dernière colonne indique à quel "service" chaque machine est attachée. 
Un graphique, en haut de l'écran, montre la charge de chaque machine (nombre de sessions, connctions et le load). 
Un menu horizontal permet d'afficher : 
Les sessions courantes. Il est possible ici de "tuer" une session gênante. 
Les services avec les machines concernées et les les sessions en cours. 
Les listeners le nom du listener avec le port qu'ils utilisent, leur état (Running normalement !) et le nom du service. 
Les filtres actifs. Les filtres permettent de réaliser des actions en fonction de l'utilisateur, par exemple de "cacher" certaines données confidentielles .... 
En haut à droite de l'écran le bouton "Create New" permet de créer de nouveaux services, de nouveaux serveurs et des filtres. 
Pour les filtres voir la documentation de Maxscale qui présente toutes les possibilités.  
Depuis le menu principal les options suivantes :

• Visualisation : permet d'afficher notre cluster en mode graphique.

• Query-editor : permet d'exécuter des ordres SQL après s'être identifié auprès d'un service.
• Users : permet de gérer les utilisateurs de Maxscale (pas ceux du cluster).
• Logs archives : permet d'afficher le log de Maxscale.
• Settings : permet de modifier les paramètres de Maxgui, et il y en a un bon paquet ! N'y toucher que si l'on sait ce que l'on fait. 
   

That's all folks.

Cette page de 2009 reste d'actualité (au moins pour les tables MyISAM) et les remarques et conseils peuvent s'appliquer à la variable "innodb_buffer_size" qui remplit à peu près la même fonction pour InnoDB.

Sur quelle information optimiser la valeur de ce paramètre ? 
Ce paramètre est réservé aux tables "MyIsam", de plus en plus rares au profit des tables InnoDB.

KEY_BUFFER = taille réservée au buffer des index. Sa taille doit être assez importante, l'idéal est que tous les index résident en mémoire limitant ainsi les IO. 
Vous pouvez calculer cette taille en évaluant la taille des index de votre base de données. L'utilisation de MySQL-Admin vous permet de suivre "en direct" l'évolution de l'utilisation de ce cache. Voir dans la section "Health", onglet "Memory Health" de MySQL-Admin. La partie "Key efficiency" vous permet de voir la partie du buffer effectivement utilisée ainsi que le "hitrate". 
Le "hitrate" est le pourcentage de clés effectivement lues depuis le buffer. 
Attention : Ne pas tenir compte des valeurs présentes peu après un redémarrage, il faut attendre plusieurs heures que le fonctionnement de la base se stabilise et que l'utilisation corresponde à l'utilisation moyenne normale des applications liées à cette base.

INNODB_BUFFER_POOL_SIZE = taille réservée au buffer Innodb (data + index) 
Plus la valeur est élevée, meilleur est le fonctionnement de la base ... La mémoire étant bien moins rare qu'il y a quelques années on peut mettre ce qu'il faut. 
Si on a assez de mémoire pour contenir la taille de la base ne pas hésiter, mais calculer au moins le volume des tables les plus accédées plus 20 ou 30%.

INNODB_BUFFER_POOL_INSTANCES = Nombre de "sous pools" 
Une valeur de 1 par Gigaoctet de POOL_SIZE est à considérer comme correcte, mais mettre une valeur proche de celle du nombre de coeurs de processeur est une option à ne pas négliger.

• Des buffers trop petits --> hitrate bas et :
  •     temps de réponse allongé
  •     IO plus élevées
• Des buffers trop grands --> mémoire gachée.

Il n'est pas la peine de mobiliser 8 Gigaoctets de mémoire si seulement 50% sont utilisés, la mémoire économisée ici peut avec profit être utilisée ailleurs, c'est le cas de la plupart des paramètres de mémoire, trop petits cela ralentit, trop grands cela utilise inutilement de la mémoire. 
Si votre base est "petite" par rapport à la mémoire mettez ce qu'il faut, sur une machine spécialisée "base de données" 75/80% de la mémoire est parfait pour InnoDB. 
Toutefois si l'ensemble de vos tables ne "pèse" que 30 Go il est inutile de réserver 64 Go de mémoire !

TABLE_OPEN_CACHE = nombre de tables en cache. 
Une cette valeur égale au nombre de tables si cela est possible. Note : on trouve un tas de choses à ce sujet ... 
Une taille peu différente du nombre de tables de la base semble en général favorable.

Un autre point à surveiller est la mémoire affectée aux tris et autres zones temporaires (TMP_TABLE_SIZE et MAX_HEAP_TABLE_SIZE). Si certaines requêtes ramènent beaucoup de lignes à trier cela nécessite de la place et, là aussi, affecter un peu de mémoire n'est pas un luxe. En général 64 à 320Mo sont suffisants, surveiller le pourcentage de tables temporaires sur disque. La valeur de READ_IO_THREADS et WRITE_IO_THREADS peut être au minimum de 2, mais sur une machine multiprocesseurs aller presque jusqu'au nombre de coeurs est une bonne pratique ... 
La taille des READ, SORT et JOIN BUFFER_SIZE est à suivre et des valeurs de 2 à 16M sont en général adaptées.

Mais il faut aussi penser à l'activité de création/modification de la base et affecter un minimum de mémoire au INNO_DB_LOG_BUFFER_SIZE afin de fluidifier les écritures sur le log. 
A propos de accès disques, plus ils sont rapides, mieux c'est. L'utilisation de SSD permet d'atteindre des vitesses impressionnantes et la mise en RAID 1 permet d'augmenter encore ce type de performance avec toutefois un certain risque, le RAID 10 est parfait. Voir ici l'influence de la variable INNODB_IO_CAPACITY qui permet à la base d'optimiser son fonctionnement en fonction de la vitesse des I/O, en général de 100 à 1000 pour des disques standard et > 10000 pour des SSD. 
Sur des systèmes largement multi-processeurs on peut aussi jouer sur les paramètres INNODB_READ_IO_THREADS et INNODB_WRITE_IO_THREADS et les augmenter à 2,3 ... afin d'accélérer au maximum les IO, base en lecture --> forcer le nombre de READ_IO_THREADS, si beaucoup d'écritures forcer le nombre de WRITE_IO_THREADS. Toutefois si vous n'avez pas de SSD ou de multiples disque de données cela peut être très peu efficace. 
Pour l'ajustement de ces valeurs suivre l'évolution des compteurs et ratios fournis par un système de suivi de performance tel que Shinken + Graphite/InfluxDB ou d'autres produits non libres, Mysql Workbench fournit aussi l'accès à beaucoup d'informations utiles.

Erreur mise à jour MariaDB. 
Mise à jour de  10.1.23-9+deb9u1 vers 10.1.26-0+deb9u1 
Lors de cette mise à jour normale par apt-get upgrade l'installation s'est "plantée" avec la trace suivante : 
regarding mariadb-server-10.1_10.1.26-0+deb9u1_amd64.deb containing mariadb-server-10.1, pre-dependency problem: 
mariadb-server-10.1 pre-depends on mariadb-common (>= 10.1.26-0+deb9u1) 
mariadb-common latest configured version is 10.1.23-9+deb9u1. 
...... 
update-alternatives: error: alternative path /etc/mysql/mariadb.cnf doesn't exist 

Une solution : 
cd /etc/mysql 
ln -s ./mariadb.conf.d/50-server.cnf ./mariadb.cnf 

Quand on relance l'installation du paquet "fautif" on obtient : 
dpkg -i mariadb-common_10.1.26-0+deb9u1_all.deb 
(Reading database ... 192496 files and directories currently installed.) 
Preparing to unpack mariadb-common_10.1.26-0+deb9u1_all.deb ... 
Unpacking mariadb-common (10.1.26-0+deb9u1) over (10.1.26-0+deb9u1) ... 
Setting up mariadb-common (10.1.26-0+deb9u1) ... 
update-alternatives: warning: forcing reinstallation of alternative /etc/mysql/mariadb.cnf because link group my.cnf is broken

Le paquet s'est bien installé, voyons voir l'installation des paquets "client" : 
dpkg -i mariadb-client*deb 
(Reading database ... 192496 files and directories currently installed.) 
Preparing to unpack mariadb-client-10.1_10.1.26-0+deb9u1_amd64.deb ... 
Unpacking mariadb-client-10.1 (10.1.26-0+deb9u1) over (10.1.26-0+deb9u1) ... 
Preparing to unpack mariadb-client-core-10.1_10.1.26-0+deb9u1_amd64.deb ... 
Unpacking mariadb-client-core-10.1 (10.1.26-0+deb9u1) over (10.1.26-0+deb9u1) ... 
Setting up mariadb-client-core-10.1 (10.1.26-0+deb9u1) ... 
Setting up mariadb-client-10.1 (10.1.26-0+deb9u1) ... 
Processing triggers for man-db (2.7.6.1-2) ... 
Processing triggers for menu (2.1.47+b1) ... 

C'est OK et les paquets "serveur" de MariaDB s'installent eux aussi correctement et une connexion à la base s'effectue normalement.

Le plugin "Federatedx" responsable de la gestion des tables "federated" est livré en standard avec MariaDB mais n'est pas activé par défaut, le paramètre "federated", si présent dans les fichiers de configuration, provoque une erreur.

Pour quelques détails sur les tables "federated" voir ici. 

L'import sans précaution d'une base comprenant des tables "federated" ne donne pas les résultats escomptés, les tables sont bien créées, mais avec le type "InnoDB" ce qui n'est pas le but recherché. 
En effet l'objet "serveur" auquel sont rattachées les tables "federated" ne fait pas partie de l'export.

L'activation est très simple : 
Dans une console "mysql" administrateur : 
INSTALL SONAME 'ha_federatedx'; 
Ensuite jouter dans le fichier de config : 
federated 
On redémarre et c'est OK. 
Remarque ; 
Même en cas d'export/import la création du "serveur" doit être exécutée sur la nouvelle machine avant toute tentative de création d'une table "federated" sinon celle-ci sera créée en ="InnoDB".

Ce script de :  Nathaniel Hendler   permet d'analyser finement le fameux "mysql-slow.log". 
Rappel : 
L'enregistrement des requêtes lentes ou des requêtes sans index se paramètre dans le fichier "my.cnf" : 

# Here you can see queries with especially long duration 
log_slow_queries    = /var/log/mysql/mysql-slow.log 
long_query_time = 2 
log-queries-not-using-indexes 

Ici les lignes sont décommentées afin d'activer l'enregistrement. 
Attention, assez consommateur de ressources,peu conseillé sur des machines de production qui ont déjà des problèmes de temps de réponse ..... 

Una analyse visuelle de ce fichier peut être intéressante mais devient rapidement rébarbative, heureusement "mysql_slow_log_parser.pl" est arrivé. 

Ce petit script Perl effectue un regroupement des "queries" coûteux en fournissant pour chaque query identifié :

• le nombre d'occurences
• le temps total utilisé et le temps moyen
• le nombre de rangs analysés
• un "modèle" du query, dépourvu des variables
• un exemple de query avec les valeurs des variables

Ces résultats sont une mine d'or pour les développeurs car tous les ordres SQL critiques (criticables) apparaissent en clair avec même un exemple à soumettre à "EXPLAIN". 
L'utilisation de ce module aide à repérer :

• les index manquants ou non judicieux
• les requêtes mal faites ...

Le comptage de chaque type de requête permet de se pencher d'abord sur les plus critiques (les plus nombreuses/coûteuses). 

En bref un très bon outil que l'on peut trouver facilement sur Internet.

J'ai rencontré un problème bizarre lors d'une mise à jour de MariaDB.

La mise à jour se passe mal et l'installation du paquet "mariadb-server-10.1_10.1.26-0+deb9u1_amd64.deb" échoue avec le message : 
E: mariadb-server-10.1: subprocess installed post-installation script returned error exit status 2

En examinant les logs on trouve un message : 
[ERROR] /usr/sbin/mysqld: unknown option '--federated' 
[ERROR] Aborting 

Si on commente dans le fichier "50-server.cnf" la ligne "federated" le démarrage se passe bien. 
Il faut alors terminer la mise à jour "ratée" ... 
On peut alors dé-commenter la ligne "federated" et relancer MariaDB.

​Et cela fonctionne.

En effet le plugin "federated" a été déclaré obsolete et doit être remplacé par "ha_federatedx" ou il faut utiliser mariadb-connect ou FederatedX.

Le partitionnement c'est parfois très commode et cela permet de débarrasser une base opérationnelle de données "anciennes" qui sont mieux placées dans des archives. 
C'est ce qui a été fait chez un client où les données d'opération sont reportées dans des tables d'archives dès qu'elles sont jugées inutiles aux opérations courantes, elles restent ainsi disponibles pour des statistiques, des études commerciales et ... 
Toutefois au bout de quelques mois elles sont utilisées de plus en plus rarement et leur présence n'est plus justifiée dans la base opérationnelle.  
Le partitionnement par semaine/mois permet de se débarrasser facilement et rapidement de ces données par un simple "ALTER TABLE TRUNCATE PARTITION XXXXX" qui supprime l'intégralité du contenu en quelques instants au lieu d'heures à défiler des ordres "DELETE. 
Or lors de la création d'une de ces tables d'archives une petite erreur de frappe s'est glissée, le nom des partitions comporte une référence directe au numéro de mois. Les partitions sont donc nommées de P01 à P12, un processus automatique supprime les partitions du mois N avec un ordre de troncature de la partition "PN", la faute de frappe concernait la partition "P11" malheureusement orthographiée "P21" ce qui aurait provoqué le plantage du processus d'archivage/purge lorsqu'il aurait voulu traiter la partitions P11 associée au mois 11. 
Mais quel ordre SQL permet de faire cela ? Eh bien non il n'y a pas d'ordre dédié au renommage de partitions ... il faut utiliser la réorganisation de partitions avec l'ordre suivant :

Et le tour est joué en ... quelques temps, car ici la partition contient plus de 50 millions de rangs et occupe environ 8Go, mais cela s'est bien exécuté en un temps raisonnable :

Oui, c'est une belle base avec une activité certaine dont voici quelques chiffres tirés de la fin d'un "SHOW ENGINE INNODB STATUS" :

Vous avez perdu le mot de passe "root" de votre belle installation de MariaDB !

Note 2021 : Cela ne fonctionne plus avec les versions récentes de MariaDB car la table mysql.user n'est plus qu'une vue vers une structure plus complexe, il faut obligatoirement passer par un "init_file" pour re-créer un mot de passe "root". Ce fichier "init_file" peut être exécuté au démarrage de MariaDB, avant le démarrage complet, et permet d'exécuter des commandes en passant outre à la vérification des droits. A ne pas laisser entre toutes les mains ... et à bien supprimer du fichier de paramétrage après usage !

Pas de panique la procédure suivante vous sortira de l'embarras (à condition de stopper votre base quelques instants ce qui peut ne pas être évident pour une base de production ... mais pour celles la vous avez soigneusement sauvegardé les mots de passe dans un gestionnaire spécialisé).

• Stopper MariaDB
• En root lancer lé commande suivante :

mysqld_safe --skip-grant-tables --skip-networking & 
Ici aucun accès ne sera possible aux commandes "classiques" "SET PASSWORD..." ou "ALTER USER ..." il faut mettre à jour directement la table "mysql.user" :

mysql -u root 
UPDATE mysql.user SET authentication_string = PASSWORD('nouveau_mot_de_passe')  
where user = 'root' 
and host = 'localhost'; 
commit; 
\q

Il suffira alors de stopper (gentiment) notre "mysqld_safe" avec la commande : 
mysqladmin -u root shutdown

Puis de relancer MariaDB avec systemctl et se retrouver dans un état normal.

Ceci fonctionne parfaitement avec un MariaDB 10.3