Sommaire

Installation

Nous avons détaillé tout les prérequis, l'installation va se faire sans soucis !

  • Copie les fichiers linuxamd64_12c_database*.zip
  • Décompression des zip
  • Exécution du runInstaller (toujours avec notre DISPLAY déporté sur une autre machine avec un serverX)
  • Nous allons créer & configurer une instance RAC. Vous pouvez si vous le souhaitez installer les fichiers RDBMS seulement puis créer une instance RAC ensuite si vous préférez
  • On prend une version "Server Class" et on choisi une installation RAC
  • Depuis Oracle 11g, vous pouvez installer le RAC sur un "Server Pool" et non plus un serveur spécifique. Je ne choisi pas cette option (utile pour les très grosses infrastructures)
  • Pour la sélection des nodes, l'assistant interroge le grid infrastructure et retrouve notre liste de serveurs.
  • On part sur l'install avancée (histoire de voir ce qui se cache) et édition Entreprise (pourquoi se priver pour un POC)
  • Pour les emplacements des fichiers, je garde la même logique : /base/oracle pour le ORACLE_BASE et /soft/oracle/product/etc... pour le ORACLE_HOME. J'ai quelques soucis de permissions ; corrigés après 3 tentatives
  • Pluggable database est la nouvelle option d'Oracle 12c. Je l'active et je demande a l'assistant une première "Pluggable Database" dans ma "Container Database"
  • Après avoir réglé la mémoire, le CHARSET, le fait de ne pas créer les schémas de démo Oracle, on attaque le stockage. Ce sera ASM.
  • Je n'ai pas d'infrastructure "Enterprise Manager" et j'active la FRA (Flash Recovery Area) en ASM.
  • L'image passe très vite, mais je choisi d'utiliser le diskgroup ASM NORMAL_DATA. N'hésitez pas a mettre la vidéo en pause à 4:00.
  • On renseigne les mot de passes des différents comptes
  • Au niveau des prérequis, j'ai encore une erreur avec la synchronisation des horloges. J'ignore les prérequis ; ce n'est pas une solution acceptable... J'aurai du lancer la synchronisation des horloges via NTP pour plus de sécurité.
  • J'obtiens une erreur de diskgroup non compatible ! Il me faut aller sur les 2 instances +ASM pour modifier le paramètre "compatible.asm" du diskgroup utilisé.
  • Je relance l'assistant ; cette fois, tout se passe correctement

On peut voir en fin de vidéo que j'ai bien les process des instances ASM qui tournent sur les 2 VM + les process des instances RAC : DB11 et DB12.

Vidéo

Test des connexions et exécution d'un petit load test

Maintenant que nous avons notre petite instance RAC, on va valider que tout fonctionne comme prévu. Je vous présente ci-après comment se connecter à l'instance RAC en utilisant le LISTENER ! Ce listener va faire un load-balancing entre les 2 instances de DB1 que nous avons. Nous le voyons clairement puisque qu'avec 3 connections identiques en SQLPlus, je me retrouve sur les 2 instances (host_name différents). Faites bien attention de passer par la couche Listener (@DB1) puisque c'est par ce biais là que la répartition de charge est réalisée.

SwingBench

Nous allons faire un petit test de charge sur notre instance RAC. Je vous conseille le programme Java : SwingBench - cet outil doit en premier lieu créer ses tables de travail (oewizard) puis la charge peut être contrôlée via swingbench.

  • Au premier lancement, la Pluggable Database pdborcl n'est pas démarrée sur aucune des 2 instances ; j'ai donc des erreurs. Après l'avoir démarrée des 2 côtés, SwingBench se connecte correctement.
  • Lors de l'exécution de la charge, on peut voir que les 2 instances passent de 2 sessions à 52. Nos 100 utilisateurs qui génèrent la charge sont donc parfaitement dispatchés sur les 2 instances.

Continuons un peu le test : alors que mon test de charge est en cours, je décide de stopper le service de la PluggableDatabase sur l'instance DB11.

  • Étonnamment, j'ai toujours mes 54 sessions connectées sur l'instance ! Tout à fait normal puisque le test de charge est configuré pour garder les connexions entre chaque transaction.
  • Je stoppe le test et le relance. Cette fois, toutes les connexions du test de charge vont sur l'instance DB12 (3 sessions sur DB11 et 102 sur DB12).

Conclusion

Nous voici avec une instance RAC 2 nœuds pleinement fonctionnelle. La charge est correctement répartie par les listeners. Nous avons une infrastructure VM déjà bien complète ; je l'utiliserai pour mes prochains articles.

Pour information, j'ai exécuté le test de charge de façon plus complète (durée plus longue) et la répartition RAC sur 2 instances ne permet PAS d’améliorer les performances dans mon cas. Il faut analyser pourquoi mais à première vue, mes disques virtuels iSCSI sont totalement saturés par le test de charge (que ce soit via 1 ou 2 instances).