Silverlake - Le blog de ADIMCOR

Optimal Flexible Architecture. Il s'agit d'un ensemble de recommandations Oracle sur l'arborescence des répertoires. Le principe général est de séparer les binaires Oracle des fichiers de bases de données. OFA repose sur 5 répertoires et 4 variables d'environnement.

• Inventory → Produits Oracle installés.
• Base → $ORACLE_BASE
• Home → $ORACLE_HOME
• Network → $TNS_ADMIN
• Diagnostic → $ADR_HOME

Le schéma ci-dessous présente l’arborescence type pour une version 12c selon la norme OFA ( Source Darl Kuhn : Pro Oracle Database 12c Administration ).

Attention : Tout ce qui suit concerne la norme OFA pour un serveur Oracle Stand-Alone. Dans le cas d'un cluster RAC la norme diffère.

OFA permet d'obtenir une vision claire des produits installés sur un même serveur. Il est ainsi simple d'utiliser différentes versions ( 11g, 12c,… ). OFA permet aussi la gestion d'installations multiples des mêmes binaires.

Le tableau suivant présente les recommandations OFA

En partant de ces variables le nom des répertoires est construit ainsi pour l'installation des binaires :

• /pm/s/u : ORACLE_BASE
• /pm/s/u/v/type_n : ORACLE_HOME

Pour l'installation des fichiers de données ( hors ASM )

• /pm/s/u/q/d

Le répertoire oraInventory doit être exclu de l'arborescence ORACLE_BASE. Valeur conseillée :

• /pm/s/oraInventory

La norme OFA est très utilisée notamment par les outils d'installation Oracle.

Voici un exemple d'utilisation de la norme OFA sur un serveur Oracle Stand-Alone avec gestion ASM, version 12c ( 12.1.0.2 ). Les variables d'environnement seront les suivantes :

• ORACLE_BASE : /ora01/app/oracle
• ORACLE_HOME : Deux cas possibles
• Database ( rdbms ) : /ora01/app/oracle/product/12.1.0.2/DB/formation
• Grid Infrastructure : /ora01/app/oracle/product/12.1.0.2/GI/formation
• TNS_ADMIN : /ora01/app/oracle/product/12.1.0.2/GI/formation/network/admin
• ADR_HOME : Sous $ORACLE_BASE/diag.

Dans certaines installations il existe une variable nommée GRID_HOME. Cette variable se rencontre en cas de séparation de la gestion grid Infrastructure, user oragrid, et du moteur de base de données, user oracle.

Pour ORACLE_HOME on pourrait utiliser uniquement /ora01/app/oracle/product/12.1.0.2. Un sous répertoire est utile pour éventuellement installer plusieurs binaires de la même version. Par exemple :

• Développement : /ora01/app/oracle/product/12.1.0.2/DB/dev
• Production : /ora01/app/oracle/product/12.1.0.2/DB/prod
• Recette : /ora01/app/oracle/product/12.1.0.2/DB/rct
• Formation : /ora01/app/oracle/product/12.1.0.2/DB/formation

Ce type de mise en place est utilisé notamment pour le passage des patches Oracle pouvant être différent selon l'environnement.

Il est important d'avoir un sous répertoire par produit surtout en cas d'implantation ASM qui implique le GRID Infrastructure.

• /ora01/app/oracle/product/12.1.0.2/DB/formation
• /ora01/app/oracle/product/12.1.0.2/GI/formation

Le répertoire Inventory sera sous /ora01/app/oraInventory.

Le fichier /etc/oratab

Il est parfois intéressant que la base soit démarrée automatiquement, ou pas, au boot du serveur. Afin de prendre en charge cette fonctionnalité il faut enregistrer la base dans le fichier /etc/oratab et créer un script de lancement.

Voir un script de lancement via systemd ( RedHat 7 )

Le fichier /etc/oratab est aussi utile afin de sélectionner la base de données sur laquelle on souhaite intervenir.

Remarque : oratab est sous /etc en cas d'utilisation de l'OS Linux, pour Solaris il est sous /var/opt/oracle.

La syntaxe de oratab est simple. Il contient une ligne par base de données :

+ASM:/ora01/app/oracle/product/12.1.0.2/GI/formation:N
YODA:/ora01/app/oracle/product/12.1.0.2/DB/formation:N
LUKE:/ora01/app/oracle/product/12.1.0.2/DB/formation:N

Ce fichier comporte 3 champs :

• Le nom de la base de données
• La valeur de ORACLE_HOME, sur quels binaires la base doit démarrer.
• Y|N : La base doit ou non être démarrée au boot.

Remarque : Il faut être prudent avec le 3ieme champ dans le cas d'une gestion ASM. Dans ce cas les bases ne sont pas démarrées par un script mais par la couche ClusterWare. Le champ doit donc être bien mis à 'N'.

Le fichier /etc/oratab est utilisé notamment par les exécutables dbstart et dbshut ( sous $ORACLE_HOME/bin ) qui permettent de démarrer et de stopper les bases Oracle via un script.

Le fichier oraenv

Ce fichier est aussi utilisé par le script oraenv afin de permettre l'affectation correcte des variables d'environnement que sont $ORACLE_HOME et $PATH. Son utilisation est simple :

[oracle@ora01 ~]$ . oraenv
ORACLE_SID = [oracle] ? YODA
The Oracle base remains unchanged with value /u01/app/oracle
[oracle@ora01 ~]$ 

A noter que oraenv doit être “sourcé” et non exécuté. Il est donc possible de taper la commande ainsi :

source oraenv

Le script demande alors interactivement le nom de l'instance et consulte le fichier /etc/oratab afin de déterminer ORACLE_HOME.

Le fichier oraenv est très pratique quand sur le même serveur résident plusieurs bases Oracle avec des versions binaires différentes.

Le script oraset

Ce script utilise aussi le fichier /etc/oratab, mais présente un menu permettant de choisir la base de données souhaitée en l'absence de paramètre passé. Ce script est inspiré du livre suivant : Darl Kuhn : Pro Oracle Database 12c Administration

#!/bin/bash
# Positionnement des variables d'environnement Oracle
# Setup: 1. A mettre sous /usr/local/bin
#        2. S'assurer d ela présence de /usr/local/bin dans $PATH
# Utilisation : Mode batch : . oraset <SID>
#               Mode menu  : . oraset
#====================================================

# Le fichier oratab n'est pas sous la même arborescence si OS Linux ou Solaris. 
if [ -f /etc/oratab ]; then # Linux
  OTAB=/etc/oratab
elif [ -f /var/opt/oracle/oratab ]; then # Solaris
  OTAB=/var/opt/oracle/oratab
else
     echo 'oratab fichier non trouvé.'
     exit
fi
#
if [ -z $1 ]; then
  SIDLIST=$(egrep -v '^#|\*' ${OTAB} | cut -f1 -d:)
  # PS3 : Prompt lors de l'utilisation de la commande select dans les shell BASH.
  PS3='SID? '
  select sid in ${SIDLIST}; do
    if [ -n $sid ]; then
      HOLD_SID=$sid
      break
    fi
  done
else
  if egrep -v '^#|\*' ${OTAB} | grep -w "${1}:">/dev/null; then
    HOLD_SID=$1
  else
    echo "SID: $1 n'existe pas dans $OTAB"
  fi
  shift
fi
#
export ORACLE_SID=$HOLD_SID
export ORACLE_HOME=$(egrep -v '^#|\*' $OTAB|grep -w $ORACLE_SID:|cut -f2 -d:)
export ORACLE_BASE=${ORACLE_HOME%%/product*}
export ADR_BASE=$ORACLE_BASE/diag
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib

Fichier .bash_profile du user oracle En utilisant les scripts présentés ci-dessus voici les variables d'environnement à définir pour le user oracle dans son fichier .bash_profile.

Editer le fichier $HOME/.bash_profile du user oracle et y ajouter les lignes suivantes :

export ORACLE_OWNER=oracle
export NLS_LANG=FRENCH_FRANCE.UTF8 
export NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS'
export SQLPATH=$HOME/sql
# Utilisation de oraenv
source oraenv
# Utilisation de oraset
# source /usr/local/bin/oraset

La variable NLS_DATE_FORMAT permet d'avoir dans certains états, notamment RMAN, une datation précise ( par défaut le format est DD/MM/YY ).

Attention : Ce fichier ne prend pas compte de la variable TNS_ADMIN. Voir un peu plus loin dans ce document.

Sourcer ensuite ce fichier

. $HOME/.bash_profile

Créer ensuite le répertoire $HOME/sql. Ce répertoire contiendra les scripts sql pouvant être lancés depuis SQL*Plus sans spécifier l'emplacement ( variable d'environnement SQLPATH ).

mkdir -p $HOME/sql

Dans ce répertoire est également situé le fichier login.sql, qui est lu à chaque lancement de SQL*Plus, et qui permet un paramétrage de l'environnement SQL*Plus. Créer ce fichier et y ajouter les lignes suivantes :

define _editor=vi
set sqlprompt '&_user.@&_connect_identifier. >'
set linesize 250
set pagesize 50

Ainsi sous SQL*Plus lors de l'appel de l'éditeur vi sera lancé en lieu et place de ed. Le prompt est redéfini afin d'afficher le user et l'alias Oracle*Net en cours lors de la session SQL*Plus.

Autre élément de confort, la possibilité de rappeler sous SQL*Plus les lignes précédentes. Il faut pour cela installer le package rlwrap qui est configuré dans les dépôts pour RedHat 7 ( pour les version antérieures il faut rechercher sur le Net ). L'installation est classique via YUM.

yum -y install rlwrap

Une fois cette installation faite, ajouter les alias suivants dans $HOME/.bashrc ( user oracle ).

alias sqlplus='rlwrap sqlplus'
alias rman='rlwrap rman'
alias adrci='rlwrap adrci'
alias dgmgrl='rlwrap dgmgrl'
alias asmcmd='rlwrap asmcmd'

Puis sourcer le fichier

. $HOME/.bashrc

La variable TNS_ADMIN

Cette variable est importante, elle précise l'emplacement des fichiers de configuration de la couche Oracle*Net soit les fichiers suivants :

• listener.ora
• sqlnet.ora
• tnsnames.ora

Dans le cas d'un serveur Stand-Alone sans ASM, Si TNS_ADMIN n'est pas défini la valeur par défaut est $ORACLE_HOME/network/admin. Ce qui peut poser des soucis en cas de ORACLE_HOME multiples.

Afin de faciliter la gestion des ces fichiers de configuration il est possible de les mettre sous /etc/oraclenet et de positionner TNS_ADMIN vers ce répertoire.

mkdir -p /etc/oraclenet
chown -R oracle:g_db_sysdba  /etc/oraclenet

Mettre ensuite sous ce répertoires les fichiers de configuration Oracle*Net et positionner la variable TNS_ADMIN

export TNS_ADMIN=/etc/oraclenet

Par contre en cas de gestion ASM il est impératif de faire pointer cette variable vers les binaires du Grid Infrastructure.

Par exemple si l'installation du Grid Infrastructure est faite sous /ora01/app/oracle/product/12.1.0.2/GI/formation, alors TNS_ADMIN doit être défini ainsi :

export TNS_ADMIN=/ora01/app/oracle/product/12.1.0.2/GI/formation/network/admin

Le positionnement correct de TNS_ADMIN est vital dans l''utilisation de ASM car les bases sont démarrées par la couche cluster.

OFA et Cluster RAC

Tout ce qui précède concerne les serveurs Stand-Alone. Dans le cas de RAC il faut modifier certains points de la norme principalement sur l'installation du Grid Infrastructure.

Important : Oracle aimant faire compliqué quand on peut faire simple nomme Grid Infrastructure ce qui s'appelait avant ClusterWare.

Oracle conseille de définir un user dédié à la gestion du Grid Infrastructure. Cet utilisateur se nomme souvent oragrid par rapport au user classique oracle qui lui est dédié a moteur de base de données soit RDBMS.

Dans le cas d'un cluster RAC les binaires Grid Infrastructure doivent être installés hors de l'arborescence ORACLE_BASE. Cette séparation est importante en raison des droits Unix, car certains processus du grid ne peuvent être lancés que par root.

En conservant les recommandations OFA voici un exemple d'installation d'un cluster RAC 12c

• /ora01/app/oragrid/product/12.1.0.2/GI → GRID_HOME ou ORACLE_HOME pour grid
• /ora01/app/oracle → ORACLE_BASE
• /ora01/app/oracle/diag → ADR_HOME
• /ora01/app/oracle/product/12.1.0.2/DB → ORACLE_HOME
• /ora01/app/oragrid/product/12.1.0.2/GI/network/admin → TNS_ADMIN
• /ora01/app/oraInventory