Silverlake - Le blog de ADIMCOR

Etendre la swap en LVM sur Red Hat/CentOS

Silverlake — Sun, 20 Nov 2022 11:13:00 +0100

Désactiver la swap actuelle

swapoff -v /dev/VolGroup00/LogVol01

Retailler le LV par exemple à 8Go

lvresize /dev/VolGroup00/LogVol01 -L 8G

Recréer l'espace swap

mkswap /dev/VolGroup00/LogVol01

Activer la swap

swapon -v /dev/VolGroup00/LogVol01

Playbook ansible pour installation Oracle 19c

Silverlake — Sat, 13 Feb 2021 18:01:00 +0100

Introduction

Le précédent billet présentait l'installation d'un serveur Oracle 19c en mode stand-alone. Il peut être intéressant d'utiliser ansible pour des déploiement massifs. C'est ce que détaille cet article. Le système d'exploitation est Red Hat / CentOS 7.

Pré-requis

Il faut dans un premier temps disposer du fichier des binaires oracle 19c -> LINUX.X64_193000_db_home.zip ( voir site oracle ou billet précédent )

Il est également nécessaire de prévoir certains fichiers qui seront utilisés soit par le module copy, soit par le module template.

Le playbook fait référence à des machines regroupées dans l'inventaire sous le nom oracle.

Fichier db19c.rsp ( installation silencieuse oracle )

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0
oracle.install.option=INSTALL_DB_SWONLY
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/ora01/app/oraInventory
ORACLE_HOME=/ora01/app/oracle/product/19/DB
ORACLE_BASE=/ora01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.OSDBA_GROUP=dba
oracle.install.db.OSOPER_GROUP=oper
oracle.install.db.OSBACKUPDBA_GROUP=backupdba
oracle.install.db.OSDGDBA_GROUP=dgdba
oracle.install.db.OSKMDBA_GROUP=kmdba
oracle.install.db.OSRACDBA_GROUP=racdba
oracle.install.db.rootconfig.executeRootScript=false

Fichier listener.j2 ( module template )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION = 
     (ADDRESS=(PROTOCOL = TCP)(HOST = {{ansible_fqdn}} )(PORT = 1521))
    )
  )

On utilise ici la variable ansible_fqdn qui donne le nom complet du serveur.

Fichier login.sql ( Paramétrage sqlplus )

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

Fichier oracle.service ( Demarrage via systemctl )

[Unit]
Description=oracle
After=syslog.target
After=network.target

[Service]
Type=forking
Environment=ORACLE_HOME=/ora01/app/oracle/product/19/DB 
User=oracle 
Group=oinstall 
ExecStart=/ora01/app/oracle/product/19/DB/bin/dbstart ${ORACLE_HOME} 
ExecStop=/ora01/app/oracle/product/19/DB/bin/dbshut ${ORACLE_HOME}

[Install]
WantedBy=multi-user.target

Le playbook

---
- name: "Configuration Oracle 19c stand-alone"
  hosts: oracle
  tasks:
    - name: Packages oracle19c pour CentOS 7 ( obligatoires )
      yum:
        name: ['compat-libcap1','gcc','gcc-c++','ksh','libaio-devel','nfs-utils','sysstat','unzip','bind-utils','smartmontools','libXtst']
        state: present
    - name: Packages oracle19c pour CentOS 7 ( optionnels )
      yum:
        name: ['vim-enhanced','psmisc','net-tools','perl-TermReadKey']
        state: present
    - name : Parametrage noyau oracle19c
      sysctl:
        name: "{{ item.name }}"
        value: "{{ item.value }}"
      loop:
        - { name: 'kernel.shmall',value: '2097152' }
        - { name: 'kernel.shmmax',value: '8589934592' }
        - { name: 'kernel.shmmni',value: '4096' }
        - { name: 'kernel.sem',value: '250 32000 100 128' }
        - { name: 'kernel.panic_on_oops',value: '1' }
        - { name: 'fs.file-max',value: '6815744' }
        - { name: 'fs.aio-max-nr',value: '1048576' }
        - { name: 'net.ipv4.ip_local_port_range',value: '9000 65500' }
        - { name: 'net.core.rmem_default',value: '262144' }
        - { name: 'net.core.rmem_max',value: '4194304' }
        - { name: 'net.core.wmem_default',value: '262144' }
        - { name: 'net.core.wmem_max',value: '1048576' }
        - { name: 'net.ipv6.conf.all.disable_ipv6',value: '1' }
        - { name: 'net.ipv6.conf.default.disable_ipv6',value: '1' }
        - { name: 'vm.swappiness',value: '1' }
        - { name: 'vm.dirty_background_ratio',value: '3' }
        - { name: 'vm.dirty_ratio',value: '80' }
        - { name: 'vm.dirty_expire_centisecs',value: '500' }
        - { name: 'vm.dirty_writeback_centisecs',value: '100' }
    - name: Parametrage limites pour oracle 19c
      pam_limits:
        domain: "{{item.domain}}"
        limit_type: "{{item.limit_type}}"
        limit_item: "{{item.it}}"
        value: "{{item.value}}"
      loop:
        - { domain: 'oracle', limit_type: 'soft', it: 'nproc', value: '16384' }
        - { domain: 'oracle', limit_type: 'hard', it: 'nproc', value: '16384' }
        - { domain: 'oracle', limit_type: 'soft', it: 'nofile', value: '1024' }
        - { domain: 'oracle', limit_type: 'hard', it: 'nofile', value: '65536' }
        - { domain: 'oracle', limit_type: 'soft', it: 'stack', value: '10240' }
        - { domain: 'oracle', limit_type: 'hard', it: 'stack', value: '32768' }
    - name : Creation des groupes
      group:
        name: "{{ item.name }}"
        gid: "{{ item.gid }}"
      loop:
        - { name: 'oinstall', gid: '1001' }
        - { name: 'dba', gid: '1002' }
        - { name: 'oper', gid: '1003' }
        - { name: 'backupdba', gid: '1004' }
        - { name: 'dgdba', gid: '1005' }
        - { name: 'kmdba', gid: '1006' }
        - { name: 'racdba', gid: '1007' }
        - { name: 'asmadmin', gid: '1008' }
        - { name: 'asmdba', gid: '1009' }
        - { name: 'asmoper', gid: '1010' }
    - name: Creation user oracle
      user:
        name: oracle
        uid: 1001
        group: oinstall
        groups: dba,oper,backupdba,dgdba,kmdba,racdba,asmdba
        password: orPMdIdQOZmn.
        # Le mot de passe oracle est oracle01
    - name: Suppression fichier profile
      file:
        path: /etc/profile.d/oracle.sh
        state: absent
    - name: Profile oracle
      blockinfile:
        path: /etc/profile.d/oracle.sh
        create: yes
        block: |
          if [ $USER = "oracle" ]; then
            if [ $SHELL = "/bin/ksh" ]; then
              ulimit -p 16384
              ulimit -n 65536
            else
              ulimit -u 16384 -n 65536
            fi
          fi
    - name: Suppresion repertoire
      file:
        path: /ora01
        state: absent
    - name: Suppression de /etc/oraInst.loc
      file:
        path: /etc/oraInst.loc
        state: absent
    - name: Création répertoire
      file:
        path: /ora01/app/oracle/product/19/DB
        state: directory
        owner: oracle
        group: oinstall
    - name: Repertoire INSTALL
      file:
        path: /INSTALL
        state: directory
        mode: 1777
    - name: Copie fichier zip
      copy:
        src: LINUX.X64_193000_db_home.zip
        dest: /INSTALL
    - name: Extraction du binaire 
      unarchive:
        src: /INSTALL/LINUX.X64_193000_db_home.zip
        dest: /ora01/app/oracle/product/19/DB
        owner: oracle
        group: oinstall
        remote_src: yes
    - name: Fichier réponse
      copy:
        src: db19c.rsp
        dest: /home/oracle
        owner: oracle
        group: oinstall
    - name: Configuration pare-feu
      firewalld:
        port: 1521/tcp
        permanent: yes
        state: enabled
        immediate: yes
    - name: Installation
      command: /ora01/app/oracle/product/19/DB/runInstaller -silent -responsefile /home/oracle/db19c.rsp -waitforcompletion
      become: yes
      become_user: oracle
    - name: Changement des droits
      command: /ora01/app/oraInventory/orainstRoot.sh
    - name: Suppression bash_profile de oracle
      file:
        path: /home/oracle/.bash_profile
        state: absent
    - name: Configuration bash_profile oracle
      blockinfile:
        path: /home/oracle/.bash_profile
        block: |
          if [ -f ~/.bashrc ]; then
            . ~/.bashrc
          fi
          export ORACLE_BASE=/ora01/app/oracle
          export ORACLE_HOME=$ORACLE_BASE/product/19/DB
          export LD_LIBRARY_PATH=$ORACLE_HOME/lib
          export ORACLE_OWNER=oracle
          export PATH=$PATH:$ORACLE_HOME/bin
          export NLS_LANG=FRENCH_FRANCE.UTF8 
          export NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS'
          export SQLPATH=$HOME/sql
          export ORACLE_PATH=$SQLPATH
          export TNS_ADMIN=$ORACLE_HOME/network/admin
        create: yes
        owner: oracle
        group: oinstall
    - name: Configuration listener
      template:
        src: /home/listener.j2
        dest: /ora01/app/oracle/product/19/DB/network/admin/listener.ora
        owner: oracle
        group: oinstall
    - name: Script demmarage oracle
      copy:
        src: oracle.service
        dest: /usr/lib/systemd/system
    - name: Activation script oracle
      service:
        name: oracle
        enabled: yes
    - name: Fichier /etc/oratab
      file:
        path: /etc/oratab
        owner: oracle
        group: oinstall
        mode: 0664
        state: touch
    - name: Repertoire SQL
      file:
        path=/home/oracle/sql
        state=directory
        owner=oracle
        group=oinstall
    - name: Copie login.sql
      copy:
        src=login.sql
        dest=/home/oracle/sql
        owner=oracle
        group=oinstall

Conclusion

Ce playbook utilise le compte root pour déployer sur les serveurs distants. Il est facilement modifiable pour y ajouter toute autre configuration ...

Installation Oracle 19c

Silverlake — Thu, 10 Dec 2020 10:51:00 +0100

Introduction

L'objectif de ce billet est de présenter la mise en place d'un serveur Oracle en stand-alone version 19c. La version 19c est en fait la version 12.2.0.3, depuis 2018 Oracle a modifié la numérotation des versions en se basant sur l'année de sortie.

L'accent est mis avant tout sur le coté pratique par la mise en place d'une maquette mais en simulant un environnement de production. l'objectif est d'aborder la mise en oeuvre et l'administration dans des conditions optimales du SGBD Oracle 19c en mode stand alone. Ce billet comporte aussi une approche de la sauvegarde et la restauration avec RMAN.

Rappel important

Les produits de la société Oracle sont soumis à licence. Oracle accorde un droit d'utilisation libre à des fins de développement ou d'évaluation. Il est interdit d'utiliser les produits Oracle en production sans acquisition de licence. Les différents produits peuvent être téléchargés en respectant les termes d'utilisation via ce lien : https://www.oracle.com/fr/DOWNLOADS/

Ce billet est conçu pour Linux CentOS 7, version libre de RedHat 7. L'adaptation à une version antérieure est possible ainsi que d'utiliser Windows. En fait quelque soit la plate-forme OS les principes d'administration Oracle sont identiques. La version oracle étudiée est la 19.3.0.0 elle n'existe qu'en 64bits, comme CentOS 7 d'ailleurs. Sortie en janvier 2019 elle sera supportée jusqu'en 2025. Le schéma ci-dessous présente le cycle de vie des différentes versions de Oracle Database ( Document source Oracle Corp ).

L'essentiel des manipulations se fait en ligne de commande via une connexion ssh.

Plate-forme technique

L'environnement de départ est une machine virtuelle sous VirtualBox nommée ORA01 avec les caractéristiques suivantes :

OS : CentOS 7.7 64 bits
RAM : 8Go
2 VCPUS
Disque système : 100Go. 2 partitions :
swap : 8Go
/ : le reste ( environ 92Go )
IP : 192.168.56.11/24
Compte root mot de passe root01

Le choix de VirtualBox n'est pas obligatoire, ce produit est simple et disponible gratuitement sur tout OS. Il est toutefois utile de préciser que les performances resteront modestes.

La version 19c de Oracle est un peu plus “gourmande” en mémoire que les précédentes. 8Go est un minimum. Les tests peuvent être fait avec seulement 4Go, il y a aura toutefois des warnings non bloquants lors de l'installation.

Afin de bien simuler un cas de production il ne sera fait appel à aucune interface graphique. Toute la configuration se faisant en ligne de commande via SSH ( Y compris la gestion des VM ).

La machine virtuelle de base, fichier ora01.ova, est disponible via l'URL suivante : http://files.silverlake.space

Il suffit de télécharger le fichier ora01.ova et de l'importer via la commande vboxmanage.

wget http://files.silverlake.space/ora01.ova
vboxmanage import ora01.ova

Quelques scripts un peu longs sont disponibles en téléchargement sur la même URL. L'utilisation de ces scripts sera vue plus tard.

Installation d'un serveur Oracle

L'installation des binaires Oracle est sans doute la première action d'un DBA. Il est nécessaire d'y apporter un soin particulier. De nombreux dysfonctionnements viennent d'une installation mal réalisée ou mal maîtrisée.

Une interface graphique est normalement requise. Comme il fut précisé au début de ce document, l'objectif est de simuler un cas de production. Sur de nombreux environnements l'unique moyen de connexion au serveur est SSH rendant ainsi quasiment impossible l'utilisation de l'interface graphique. Il faut alors se tourner vers l'installation silencieuse via un fichier texte. C'est ici la méthode retenue.

La machine virtuelle de base ne comporte que les composants essentiels d'un serveur Linux ( Meta Package Core ). Pour installer un serveur Oracle il est nécessaire de procéder à certains ajustements notamment l'installation de packages complémentaires. Pour se faire il faut configurer un dépôt RPM.

Dépôt RPM

Dans cette procédure la VM ne dispose pas d'accès Internet. Le plus simple est de monter le DVD de la distribution sur la VM et de configurer yum pour utiliser le DVD comme dépôt. Le paragraphe suivant montre cette méthode.

Dans un premier temps sur l'hôte de virtualisation récupérer l'image ISO du DVD CentOS 7. Il existe sur le web un grand nombre de miroirs permettant ceci. L'exemple suivant utilise un miroir sur infoline.de.

wget http://mirror.infonline.de/centos/7.7.1908/isos/x86_64/CentOS-7-x86_64-DVD-1908.iso

Attacher l'ISO à la VM

vboxmanage storageattach ORA01 --storagectl IDE --port 0 --device 0 --type dvddrive --medium CentOS-7-x86_64-DVD-1908.iso

Désactiver le boot sur ce DVD en ne conservant que le boot sur le disque dur.

vboxmanage modifyvm ORA01 --boot1 disk
vboxmanage modifyvm ORA01 --boot2 none
vboxmanage modifyvm ORA01 --boot3 none
vboxmanage modifyvm ORA01 --boot4 none

Lancer la VM et vérifier la présence du DVD.

vboxmanage startvm ORA01 --type headless

Le démarrage en "type headless'' permet de ne pas lancer la console. Une fois lancer se connecter root sur cette VM -> ssh root@192.168.56.11. La commande //lsblk// permet de vérifier la présence du DVD.

[root@ora01 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  100G  0 disk 
├─sda1   8:1    0   96G  0 part /
└─sda2   8:2    0    4G  0 part [SWAP]
sr0     11:0    1  4,4G  0 rom  
sr1     11:1    1 1024M  0 rom  
[root@ora01 ~]#

Le DVD est bien présent sur le device /dev/sr0. Créer un point de montage et monter l'ISO

mkdir /centos
mount -o ro /dev/sr0 /centos

Vérification

[root@ora01 ~]# df -hT
Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
devtmpfs         devtmpfs   2,0G       0  2,0G   0% /dev
tmpfs            tmpfs      2,0G       0  2,0G   0% /dev/shm
tmpfs            tmpfs      2,0G    8,5M  2,0G   1% /run
tmpfs            tmpfs      2,0G       0  2,0G   0% /sys/fs/cgroup
/dev/sda1        ext4        95G    1,3G   89G   2% /
tmpfs            tmpfs      396M       0  396M   0% /run/user/0
/dev/sr0         iso9660    4,4G    4,4G     0 100% /centos
[root@ora01 ~]#

Rendre ce montage permanent

cat /etc/mtab | grep centos >> /etc/fstab

Configurer ensuite le dépôt sur ce point de montage. Se positionner sous /etc/yum.repos.d et supprimer tous les fichiers.

cd /etc/yum.repos.d
rm -f *

Sous ce même répertoire créer le fichier dvd.repo avec les lignes suivantes :

[DVD]
name=DVD
baseurl=file:///centos
enabled=1
gpgcheck=0

La commande yum utilisera dorénavant le DVD.

Configuration système pour Oracle 19c

Le serveur est installé avec l'OS CentOS 7 minimal ( Meta package Core ). Seul le compte root est en place. Il est nécessaire de procéder à des ajustements sur la configuration OS :

Utilisateur et Groupes
Paramétrage noyau
Limites
Parefeu
SELinux
Packages complémentaires

Utilisateur et groupes

Par convention, les binaires RDBMS sont possédés et exécutés par un utilisateur dédié -> oracle. Il faut être attentif à une affectation correcte des UID et GID. Dans un cluster RAC, ils doivent être identiques entre tous les noeuds. Même si ceci est d'une importance moindre dans une serveur stand-alone il est de bonne pratique de respecter cette convention

L'utilisateur oracle fait partie de plusieurs groupes :

oinstall : groupe possédant les binaires. C'est le groupe principe du user oracle.
dba : Ce groupe permet **la connexion as sysdba**.
oper : groupe facultatif permettant **la connexion as sysoper**

La version 19c de Oracle a introduit 4 nouveaux groupes

backupdba : groupe dédié au sauvegarde/restauration notamment RMAN
dgdba : groupe pour la gestion dataguard
kmdba : groupe pour la gestion du cryptage
racdba : gestion du grid infrastructure

Il existe aussi 3 autres groupes pour la gestion ASM.

asmdba : groupe possédant l'accès aux disques ASM.
asmadmin : privilège as sysasm, notamment pour la gestion des diskgroups.
asmoper : groupe facultatif connexion idem oper pour database.

En utilisation basique ou dans les structures peu importantes, différentier les groupes ne présente pas de vraie valeur ajoutée. Il est possible de tout faire en utilisant juste le groupe dba. Il est alors nécessaire lors de l’installation de bien spécifier correctement chaque groupe même si c'est le même pour tous. Il faut toutefois faire attention car lors de l'installation des warnings sont générés.

Dans l'exemple afin de rester "classique" avec les différentes documentions existantes et en accord avec OFA tous les groupes seront mis en place.

Création des groupes par la commande groupadd

groupadd -g 1001 oinstall
groupadd -g 1002 dba
groupadd -g 1003 oper
groupadd -g 1004 backupdba
groupadd -g 1005 dgdba
groupadd -g 1006 kmdba
groupadd -g 1007 racdba
groupadd -g 1008 asmdba
groupadd -g 1009 asmadmin
groupadd -g 1010 asmoper

Création du user oracle ( commande useradd ). Le groupe principal est oinstall, les secondaires sont tous les autres créés ci-dessus pour oracle.

useradd -u 501 -g oinstall -G dba,oper,backupdba,kmdba,dgdba,racdba,asmdba,asmadmin,asmoper -d /home/oracle -s /bin/bash oracle

Donner un mot de passe au user oracle, dans le cadre de ce cours : //oracle01//. En production donner une mot de passe plus robuste.

passwd oracle

La commande id permet de vérifier l'affectation correcte aux groupes.

id oracle
uid=501(oracle) gid=1001(oinstall) groupes=1001(oinstall),1002(dba),1003(oper),1004(backupdba),1005(dgdba),1006(kmdba),1007(racdba),1008(asmdba),1009(asmadmin),1010(asmoper)

Il est important de vérifier que la commande umask du user oracle renvoie bien la valeur 0022.

Paramétrage noyau

Oracle demande quelques ajustements du noyau Linux en particulier sur la gestion mémoire et les processus via les sémaphores. Pour rendre ces paramètres permanents il faut les inscrire dans le fichier /etc/sysctl.conf. Ci dessous le fichier /etc/sysctl.conf utilisé.

# Memoire partagee
# kernel.shmall limite la taille de la shared memory ( penser à la PGA et à l'OS... )
# Si 8Go de RAM : 6 * 1024 * 1024 * 1024 / 4096 = 1572864
# Valeur minimale de shmall : 1021796
kernel.shmall = 1572864
kernel.shmmax = 4185278464
kernel.shmmni = 4096

# Semaphores
kernel.sem = 250 32000 100 128

kernel.panic_on_oops = 1

# Nbre fichiers
fs.file-max = 6815744
fs.aio-max-nr = 1048576

# Reseau
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

# Desactive totalement IPV6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

# Optimisation mémoire
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100

Les valeurs type shm concernent la Shared Memory, donc la SGA de Oracle.
Les valeurs type sem concernent les sémaphores donc liées au paramètre PROCESSES de Oracle.
Les valeurs type net sont relatives au réseau.
Les valeurs type vm sont relatives à la mémoire et notamment sur la gestion des dirty block dans le database buffer cache.

Ne pas oublier que ces valeurs partent du principe que seul Oracle tourne sur le serveur. D'autres logiciels utilisent aussi la Shared Memory et les sémaphores.

Sur certaines configuration le calcul suivant peut être fait ici l'exemple avec 16Go de RAM :

kernel.shmall : 40% RAM en pages mémoire ( 4096 ) : 16 * 0.4 * 1024 * 1024 * 1024 / 4096 = 1677722.
kernel.shmmax : 50% RAM en bytes : 16 * 0.5 * 1024 * 1024 * 1024 = 8589934592

Activer la configuration par la commande suivante :

sysctl -p

Dans cette configuration la gestion de la mémoire n'utilise pas les HugePages. L'utilisation des HugesPages demande des précautions et fera l'objet d'un paragraphe séparé plus loin dans ce document.

Paramétrage des limites

Les limites sont relatives aux ressources utilisées par un user particulier, en l'occurrence ici oracle. Sont concernées le nombre de processus et de fichiers ouverts.

Ajouter au fichier /etc/security/limits.conf les lignes suivantes :

oracle soft nproc 16384
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
oracle hard stack 32768

Ces limites n'influencent pas sur les performances. Par contre elles peuvent gêner leur bon fonctionnement.

La limite soft d'un utilisateur peut être modifiée par l'utilisateur lui-même, mais sans toutefois dépasser la limite hard.

Cette configuration permet de définir les limites soft et hard d'un user. La commande ulimit permet à un utilisateur de modifier ses limites pour le shell courant.

Modifier le fichier /etc/pam.d/login et ajouter la ligne suivante :

session required pam_limits.so

Dans le répertoire /etc/profile.d créer le fichier oracle.sh avec les lignes suivantes :

if [ $USER = "oracle" ]; then
  if [ $SHELL = "/bin/ksh" ]; then
    ulimit -p 16384
    ulimit -n 65536
  else
    ulimit -u 16384 -n 65536
  fi
fi

SELinux

Oracle 19c est compatible avec SELinux, il est donc conseillé de laisser la valeur par défaut, soit Enforcing, en place. Il reste possible de désactiver totalement SELinux en éditant le fichier /etc/selinux/config et en paramétrant la clause SELINUX à la valeur disabled.

La commande getenforce permet de connaitre la valeur de SELinux.

Pare-feu

La gestion du pare-feu sous CentOS 7 utilise firewalld. Dans un soucis de simplification il est possible de désactiver le pare-feu. Les deux commandes suivantes permettent ceci.

systemctl stop firewalld
systemctl disable firewalld

Packages complémentaires

Il s'agit ici des packages requis par Oracle pour l'installation de ses binaires. Les documentations font état d'une liste assez longue de packages. Par le jeu des dépendances la liste suivante est suffisante.

yum -y install compat-libcap1 gcc gcc-c++ ksh libaio-devel nfs-utils sysstat unzip bind-utils smartmontools

Même si la gestion graphique n'est pas requise il faut installer le package suivant relatif aux librairies X et ce afin d'éviter un warning lors de l'installation.

yum -y install libXtst

Les packages suivants ne sont pas indispensables,mais ils apportent un confort d'utilisation.

yum -y install vim-enhanced psmisc net-tools

PERL

Depuis la version 12c Oracle utilise massivement des scripts PERL, notamment si la gestion multitenant est en place et que l'on souhaite utiliser des pluggable database. Pour passer certains scripts SQL, notamment catalog, catproc,... Oracle conseille de ne pas utiliser SQL*Plus mais catcon.pl. En cas d'installation minimale de CentOS 7 il faut installer un module PERL supplémentaire ( perl-TermReadKey ) sinon catcon échoue ( voir exemple ci-dessous )

perl catcon.pl
Can't locate Term/ReadKey.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . ./) at catcon.pm line 189.
BEGIN failed--compilation aborted at catcon.pm line 189.
Compilation failed in require at catcon.pl line 94.
BEGIN failed--compilation aborted at catcon.pl line 94.

L'installation du module requis est simple

yum -y install perl-TermReadKey

vim-enhanced est un éditeur évolué base sur vi.
psmisc contient la commande pstree et fuser ( indispensable pour PSU )
net-tools contient la commande ifconfig( obsolète normalement au profit de la commande ip ).

Installation des binaires Oracle

Les fichiers sources proviennent du https://www.oracle.com/database/technologies/oracle19c-linux-downloads.html :

LINUX.X64_193000_db_home.zip : RDBMS
LINUX.X64_193000_grid_home.zip : Grid Infrastructure ( pour la gestion ASM )

Sur la VM les binaires zippés seront placées dans le répertoire /INSTALL/. Dans un premier temps seul le fichier LINUX.X64_193000_db_home.zip ( RDBMS ) sera utilisé, le fichier LINUX.X64_193000_grid_home.zip relatif au Grid Infrastructure sera vu dans un autre billet.

En connexion root, créer le répertoire /INSTALL sur la VM et affecter les bons droits

mkdir /INSTALL
chmod 1777 /INSTALL

Transférer ensuite les fichiers zip chargés depuis le site Oracle dans ce répertoire.

Depuis la version 12.2.0.1 l'installation des binaires est simplifiée. Il faut décompresser le fichier zip dans le répertoire pointé par ORACLE_HOME et lancer l'installation.

Sous l'identité root créer le répertoire /ora01 et affecter les bons droits.

mkdir /ora01
chown -R oracle:oinstall /ora01

Sous l'identité oracle créer le répertoire ORACLE_HOME

mkdir -p /ora01/app/oracle/product/19/DB

Se positionner sous ce répertoire et decompresser le zip. Attention de bien dezipper en tant que user oracle et non root.

cd /ora01/app/oracle/product/19/DB
unzip /INSTALL/LINUX.X64_193000_db_home.zip

Installation silencieuse

En production les installations se font rarement en graphique mais en mode silencieux. Il faut disposer d'un fichier réponse, un exemple peut être trouvé dans le fichier suivant : /ora01/app/oracle/product/19/DB/install/response/db_install.rsp.

Sous /home/oracle créer un fichier db19c.rsp avec les lignes suivantes:

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0
oracle.install.option=INSTALL_DB_SWONLY
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/ora01/app/oraInventory
ORACLE_HOME=/ora01/app/oracle/product/19/DB
ORACLE_BASE=/ora01/app/oracle
oracle.install.db.InstallEdition=EE
oracle.install.db.OSDBA_GROUP=dba
oracle.install.db.OSOPER_GROUP=oper
oracle.install.db.OSBACKUPDBA_GROUP=backupdba
oracle.install.db.OSDGDBA_GROUP=dgdba
oracle.install.db.OSKMDBA_GROUP=kmdba
oracle.install.db.OSRACDBA_GROUP=racdba
oracle.install.db.rootconfig.executeRootScript=true
oracle.install.db.rootconfig.configMethod=ROOT

Une fois décompacté, il suffit de lancer le programme runInstaller

[oracle@ora01 ~]$ /ora01/app/oracle/product/19/DB/runInstaller -silent -waitforcompletion -responsefile /home/oracle/db19c.rsp

Lancement de l'assistant Configuration d'Oracle Database...

 Entrez le mot de passe de l'utilisateur 'root' : 
Le fichier de réponses pour cette session est accessible sur :
 /ora01/app/oracle/product/19/DB/install/response/db_2020-04-13_03-21-25PM.rsp

Le journal de cette session d'installation se trouve dans :
 /tmp/InstallActions2020-04-13_03-21-25PM/installActions2020-04-13_03-21-25PM.log
Successfully Setup Software.
Les journaux de session d'installation ont été déplacés vers :
 /ora01/app/oraInventory/logs/InstallActions2020-04-13_03-21-25PM
[oracle@ora01 ~]$

Finalisation de l'installation

Rajouter les lignes suivantes dans le fichier $HOME/.bash_profile du user oracle.

export ORACLE_BASE=/ora01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19/DB
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_OWNER=oracle
export PATH=$PATH:$ORACLE_HOME/bin
export NLS_LANG=FRENCH_FRANCE.UTF8 
export NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS'
export SQLPATH=$HOME/sql
export ORACLE_PATH=$SQLPATH
export TNS_ADMIN=$ORACLE_HOME/network/admin

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 ).

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
cd $HOME/sql

Dans ce même répertoire créer un fichier login.sql avec les lignes suivantes. Ce fichier est lu à chaque lancement de SQL*Plus, et permet un paramétrage de l'environnement SQL*Plus.

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 ou $ORACLE_SID 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 n'est pas configuré dans les dépôts pour CentOS 7.

L’installation de rlwrap est un peu complexe, il faut dans un premier temps récupérer un certain nombre de packages RPM depuis l'internet, les transférer sur la VM et les installer via yum.

wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python3-3.6.8-10.el7.x86_64.rpm
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python3-setuptools-39.2.0-10.el7.noarch.rpm
wget http://mirror.centos.org/centos/7/updates/x86_64/Packages/python3-pip-9.0.3-7.el7_7.noarch.rpm
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python3-libs-3.6.8-10.el7.x86_64.rpm
wget https://download-ib01.fedoraproject.org/pub/epel/7/x86_64/Packages/r/rlwrap-0.43-2.el7.x86_64.rpm

Unre 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'

Puis sourcer le fichier

. $HOME/.bashrc

Une fois ces actions faites, la connexion SQL*Plus doit être opérationnelle.

[oracle@ora01 ~]$ sqlplus /nolog

SQL*Plus: Release 19.0.0.0.0 - Production on Lun. Avr. 13 15:33:07 2020
Version 19.3.0.0.0

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

@ >exit

Conclusion de l'installation

Au niveau de ce chapitre ont été vus différents points pour faciliter l'administration Oracle surtout en mode ligne de commande qui est le plus souvent l'unique moyen de se connecter à la base de données.

Le chapitre suivant aborde la configuration du réseau. Une base Oracle est en effet le plus souvent accessible via des connexions distantes.

La couche Oracle*Net

Oracle*Net, anciennement SQL*Net, est la couche réseau de Oracle. Il s'agit d'une configuration de type client/serveur. Le principe est de rendre transparent pour les applications la localisation des bases de données.

Les fichiers de configuration Oracle*Net peuvent être pointés par la variable d'environnement $TNS_ADMIN dont la valeur par défaut est $ORACLE_HOME/network/admin. Sous ce répertoire doivent se trouver certains fichiers dont le plus important sur un serveur se nomme listener.ora.

Le schéma suivant présente la fonction Oracle*Net.

Configuration serveur

Un processus d'écoute, le listener, écoute le réseau sur le port 1521 d'un réseau TCP/IP. Il est possible de configurer plusieurs processus d'écoute sur le même serveur; ils doivent :

Porter un nom différent
Ecouter sur des ports distincts

Par convention le processus d'écoute se nomme LISTENER. Le port d'écoute 1521 est aussi une convention. Il est possible d'utiliser un autre nom et/ou un autre port d'écoute.

Il est conseillé de renseigner le port d'écoute dans le fichier /etc/services.

La configuration du listener se fait dans un fichier, listener.ora, situé sous $ORACLE_HOME/network/admin. C'est le seul fichier à configurer, sauf si le serveur est aussi client d'un autre serveur.

Le listener se lance par la commande lsnrctl start, s'arrête avec lsnrctl stop

La commande lsnrctl status permet de visualiser l'état du listener.

La commande lsnrctl reload permet de recharger la configuration sans arrêt du listener.

Si le serveur comporte plusieurs versions de Oracle ( 10g, 11g, 12c,... ) il faut toujours utiliser la version la plus récente du listener.

La configuration du listener peut se faire de plusieurs manières. Configuration via deux programmes :

Assistant netca
Programme netmgr

Ces deux programmes sont graphiques. En production il est souvent plus simple d'éditer le fichier listener.ora avec vi.

cd $ORACLE_HOME/network/admin
vi listener.ora

Ci dessous un exemple de configuration

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION = 
     (ADDRESS=(PROTOCOL = TCP)(HOST = ora01 )(PORT = 1521))
    )
  )

La clause HOST peut utiliser un nom ou une IP. Dans le cas de l’utilisation d'un nom il faut au minimum renseigner celui-ci dans le fichier /etc/hosts -> 192.168.56.11 ora01

Lancer le listener ainsi

lsnrctl start

Le fichier sqlnet.ora

Ce fichier, présent également sur le serveur au même endroit que listener.ora permet une configuration poussée du mode de connexion des clients. Dans un premier temps sa mise en place sera simple. Le fichier contiendra les différentes méthodes autorisées pour se connecter.

Sous $ORACLE_HOME/network/admin éditer un fichier sqlnet.ora et ajouter juste la ligne suivante :

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

Ici on autorise la connexion type TNS ( Transparent Network Substrate ), un fichier tnsnames.ora, devra être présent sur le client. On autorise aussi la connexion Easy Connect.

Configuration client

Elle demande la présence d'une base de données, or à ce stade aucune n'est encore en place. Toutefois afin de préparer la suite créer sous $ORACLE_HOME/network/admin un fichier nommé tnsnames.ora avec les lignes suivantes :

LUKE =
  (DESCRIPTION =
    (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = ora01 )(PORT = 1521))
    )
    (CONNECT_DATA =
       (SERVICE_NAME = LUKE)
    ) 
)

Comme pour la configuration listener, la clause HOST peut contenir un nom ou une IP. le fichier tnsnames.ora étant souvent sur un client oracle il importe de bien valider ce point. Le plus simple étant la gestion via un DNS.

Création d'une base de données

Il existe plusieurs méthodes :

Manuellement
Graphiquement avec DBCA
DBCA en mode silencieux
Génération de scripts via DBCA
Clonage

Dans ce document il sera mis en place un script shell utilisant la gestion OMF pour les fichiers.

Répertoires pour OMF

En connexion root créer les deux répertoires suivants et affecter les bons droits

mkdir /data /fra
chown oracle:dba /data /fra

Le répertoire /data supportera les fichiers de la base. Le répertoire /fra sera dédié à la Fast Recovery Area.

Le script de création

Ce shell comporte un certain nombre de variables qu'il suffit de personnaliser en fonction de l'environnement. Ici il sera mis en place une base nommée LUKE en utilisant la gestion OMF. Ce script est téléchargeable via l'URL suivante : http://files.silverlake.space/createLUKE.sh

######################################################
# Shell de creation d'une base LUKE Stand-Alone
# SILVERLAKE : 10/12/2020
# Note : Deux fichiers ( initLUKE.ora et createLUKE.sql ) sont ecrits sous $HOME/sql
# Appel : createLUKE.sh
######################################################
#!/bin/bash

if [ -z ${ORACLE_BASE} ]
then
  export ORACLE_BASE=/ora01/app/oracle
fi

if [ -z ${ORACLE_HOME} ]
then
  export ORACLE_HOME=${ORACLE_BASE}/product/19/DB
  export PATH=$ORACLE_HOME/bin:$PATH
fi

export DEBUT=$(date +%s)
echo $(date)

# Variables a spécifier
export DB=LUKE
export DBUNIQ=${DB}
export ORACLE_SID=${DBUNIQ}
export DATA=/data
export FRA=/fra
export SGA=1280M
export PGA=360M
export REDOSIZE=50M
export CHARACTERSET=AL32UTF8
#export CHARACTERSET=WE8ISO8859P15
export MDP=Manager19#
export SERVEUR1=ora01

echo "Suppression ancienne BASE"
rm -rf ${DATA}/${DBUNIQ}
rm -rf ${FRA}/${DBUNIQ}

mkdir -p ${DATA}
mkdir -p ${FRA}

rm -f ${ORACLE_HOME}/dbs/*${DBUNIQ}*

echo "Création base Stand-Alone ${DBUNIQ} sur ${SERVEUR1}"

# Fichier init.ora
# A adapter selon le besoin
cat <<EOF > ${HOME}/sql/init${DBUNIQ}.ora
db_name=${DB}
db_unique_name=${DBUNIQ}
db_block_size=8192
db_create_file_dest=${DATA}
db_recovery_file_dest=${FRA}
db_recovery_file_dest_size=5000M
log_archive_format=${DB}_%t_%s_%r.arch
sga_target=${SGA}
pga_aggregate_target=${PGA}
EOF

# Script de creation
# A adapter, notamment dimension des tablespaces standards ( SYSTEM,SYSAUX,TEMP,UNDO,USERS )
# Le tablespace USERS est volontairement cree et bloque a 100K
cat <<EOF > ${HOME}/sql/create${DBUNIQ}.sql
create database ${DB}
character set ${CHARACTERSET}
national character set AL16UTF16
datafile size 500M autoextend on next 500M maxsize 2G extent management local
sysaux datafile size 500M autoextend on next 500M maxsize 2G
undo tablespace UNDOTBS1 datafile size 500M
default temporary tablespace TEMP tempfile size 500M
default tablespace USERS datafile size 100K
logfile group 1 size ${REDOSIZE},
        group 2 size ${REDOSIZE},
        group 3 size ${REDOSIZE}
user sys identified by "${MDP}"
user system identified by "${MDP}";
EOF

ln -sfn ${HOME}/sql/init${DBUNIQ}.ora ${ORACLE_HOME}/dbs/init${DBUNIQ}.ora
orapwd file=${ORACLE_HOME}/dbs/orapw${DBUNIQ} password=${MDP}

# Creation de la base
echo "Création de l'instance et des fichiers principaux"
resultat=`sqlplus -s "/ as sysdba" <<EOF
create spfile from pfile;
startup force nomount;
start ${HOME}/sql/create${DBUNIQ}.sql;
exit;
EOF`

echo "Base de données ${DBUNIQ} créee. Les fichiers de contrôle sont en place."

echo "Création des vues du dictionnaire. Phase assez longue"
resultat=`sqlplus -s "/ as sysdba" <<EOF
@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql

BEGIN
 FOR item IN ( SELECT USERNAME FROM DBA_USERS WHERE ACCOUNT_STATUS IN ('OPEN', 'LOCKED', 'EXPIRED') AND USERNAME NOT IN (
'SYS','SYSTEM') )
 LOOP
  dbms_output.put_line('Locking and Expiring: ' || item.USERNAME);
  execute immediate 'alter user ' ||
         sys.dbms_assert.enquote_name(
         sys.dbms_assert.schema_name(
         item.USERNAME),false) || ' password expire account lock' ;
 END LOOP;
END;
/

connect system/${MDP}
@?/sqlplus/admin/pupbld.sql
@?/sqlplus/admin/help/hlpbld.sql helpus.sql
exit;
EOF

# la base est mise en archivelog.
# Commenter ces instructions en cas de non archivelog.
`resultat=`sqlplus -s "/ as sysdba" <<EOF
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
alter system archive log current;
exit;
EOF`

echo ${DBUNIQ}':'${ORACLE_HOME}':Y' >> /etc/oratab

export FIN=$(date +%s)
echo $(date)
export DUREE=$(( ${FIN} - ${DEBUT} ))
echo "Fin de création. Durée -> ${DUREE}"
exit 0

Le lancement est simple

[oracle@ora01 ~]$ sh createLUKE.sh 
jeu.décembre 10 18:09:14 CEST 2020
Suppression ancienne BASE
Création base Stand-Alone LUKE sur ora01
Création de l'instance et des fichiers principaux
Base de données LUKE créee. Les fichiers de contrôle sont en place.
Création des vues du dictionnaire. Phase assez longue
jeu.décembre 10 18:34:21 CEST 2020
Fin de création. Durée -> 1507
[oracle@ora01 ~]$

Ce script est largement personnalisable, commenté et explicite. Il créé une base de données avec le minimum requis pour une production :

2 fichiers de contrôle.
3 groupes de redolog composé chacun de 2 membres de 50Mo
1 tablespace par défaut différent ( USERS ) de SYSTEM
1 tablespace temporaire
1 tablespace UNDO
La base est mise en archivelog.
La gestion OMF permet une simplification des noms de fichiers
La SGA est de 1,2Go
La PGA de 360Mo

Le jeu de caractères est important et paramétrable:

AL32UTF8 : Caractères codés sur 4 octets
WE8ISO8859P15 : Caractères codés sur 1 octet

Sur la VM de test, la création a duré environ 35/40 minutes.

Enregistrement statique dans listener

Si le listener est démarré avant la base de données, celle-ci s'enregistre automatiquement au moment de son démarrage auprès du listener.

Si le listener est démarré après la base de données, le listener ne connait pas forcement la base à écouter.

Il est parfois judicieux de spécifier statiquement dans la configuration du listener quelles bases il écoute. Cet enregistrement statique est obligatoire pour démarrer une base à distance.

Editer le fichier $ORACLE_HOME/network/admin/listener.ora et ajouter les lignes suivantes :

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = LUKE)
      (ORACLE_HOME = /ora01/app/oracle/product/19/DB)
      (SID_NAME = LUKE)
    )
  )

Cette procédure est obligatoire pour démarrer une base de données depuis un poste distant. Il faut également faire ceci dans une configuration DataGuard ou la mise en place de clonage.

Bien que facultatif en première approche, il est de bonne pratique de renseigner statiquement les bases dans le listener. Recharger la configuration listener ainsi.

lsnrctl reload

Démarrage automatique de la base LUKE

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.

Le fichier /etc/oratab

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

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

LUKE:/ora01/app/oracle/product/19/DB:Y

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.

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 le Grid Infrastructure. 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 script oraenv

Le fichier /etc/oratab est aussi utilisé par le script oraenv ( situé sous /usr/local/bin ) 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] ? LUKE
The Oracle base remains unchanged with value /ora01/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 script oraenv peut s'appeler aussi sans intéraction, il suffit de mettre en place les variables suivantes :

export ORAENV_ASK=NO
export ORACLE_SID=LUKE

Cette manière de faire est intéressante si le serveur ne contient qu'une seule base de données.

Le script oraset

Ce script est tiré du livre de Darl Kuhn sur l'administation Oracle 12c.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é.

Se connecter en root et se positionner dans /usr/local/bin ( c'est dans ce répertoire que se trouve oraenv également ) pour créer le fichier oraset.

#!/bin/bash
# Positionnement des variables d'environnement Oracle
# Setup: 1. A mettre sous /usr/local/bin
#        2. S'assurer de la 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

Rendre ce script exécutable

chmod 0755 oraset

Ci dessous un exemple d'utilisation de oraset en interactif ou batch

[oracle@ora01 ~]$  . oraset
1) LUKE
SID? 1

[oracle@ora01 ~]$  . oraset LUKE

Script de démarrage

Il faut ensuite créer un script de démarrage au boot compatible systemD. Se connecter dans une session root.

Se positionner dans le répertoire /usr/lib/systemd/system et créer un fichier nommé oracle.service avec les lignes suivantes :

[Unit]
Description=oracle
After=syslog.target
After=network.target

[Service]
Type=forking
Environment=ORACLE_HOME=/ora01/app/oracle/product/19/DB 
User=oracle 
Group=oinstall 
ExecStart=/ora01/app/oracle/product/19/DB/bin/dbstart ${ORACLE_HOME} 
ExecStop=/ora01/app/oracle/product/19/DB/bin/dbshut ${ORACLE_HOME}

[Install]
WantedBy=multi-user.target

Ce script utilise les shell dbstart et dbshut fournis par Oracle. L'activation est classique en systemd

systemctl enable oracle

Attention dans le cas de l'utilisation de ASM, ce fichier ne doit pas exister. Le démarrage de la base est effectué par le Grid Infrastructure.

Diagnostics

La version 11g a introduit une nouvelle infrastructure pour le diagnostic des problèmes, Automatic Diagnostic Repository. Ces fonctions se retrouvent en 19c. ADR se présente sous la forme d'une arborescence de répertoires qui stocke de manière centralisée les données de diagnostic. Il existe 2 concepts :

Les problèmes. Erreur Internes ORA-00600, OS ORA-07445...Chaque problème inclut un code ORA...et éventuellement des paramètres supplémentaires.
Les incidents. Il s'agit d'une occurrence d'un problème, chaque incident porte un numéro

L'exploitation de ADR se fait en ligne de commande par l'utilitaire adrci.

ADR stocke tous les fichiers de traces et journaux pour l'ensemble des produits s'exécutant sur le serveur. BD, listener... Défini par le paramètre DIAGNOSTIC_DEST, sa valeur par défaut est $ORACLE_BASE si cette variable est définie, sinon $ORACLE_HOME/log. Le schéma suivant présente une partie de cette arborescence.

La racine de ce répertoire se nomme diag et contient un sous répertoire par produit Oracle

rdbms → BD, ce répertoire contient un sous répertoire par instance de base de données.
tnslsnr→ listener...

Suite à la création de la base LUKE, sous $ORACLE_BASE/diag/rdbms/luke/LUKE, se trouve un certain nombre de répertoires dédiés au traces.

luke ( en minuscules ) correspond au nom unique de la base de données ( DB_UNIQ_NAME )
LUKE ( en majuscules ) au nom de l'instance ( $ORACLE_SID )

Les principaux répertoires sont :

Alert : Fichier d'alerte format XML
Incident : Fichiers relatifs aux incidents
Trace : Fichier de trace des processus et format texte du fichier d'alerte ( alertLUKE.log ).

Oracle maintient un fichier d’alerte dans lequel il écrit des messages d’information ou d’erreurs sur la vie de la base de données :

Création de la base de données,
Démarrages et arrêts,
Modifications de la structure (tablespaces, fichiers de données),
Erreurs internes (ORA-00600, ORA-07445),
Erreurs de bloc corrompu (ORA-01578),
Problèmes relatifs à l’écriture ou à l’archivage des fichiers de journalisation.

En complément, lorsqu’un processus rencontre un problème, il écrit des informations dans un fichier de trace. Le fichier d'alerte est disponible sous deux formats : texte et XML. Le nom du fichier d’alerte xml est de la forme : log.xml ( sous répertoire alert ). Le nom du fichier d’alerte texte est de la forme : alert_<SID>.log ( sous répertoire trace ).

Les traces ne sont pas obligatoirement des erreurs. ADR fait le distinctif entre les traces ordinaires ( switch log,... ) et les traces relatives aux incidents.

Il importe de comprendre le nommage des fichiers de trace. Pour Processus d'arrière plan le nom des fichiers de trace des processus d’arrière-plan est de la forme : <sid>_<nom_processus>_<id_processus>.trc.

Le nom des fichiers de trace des processus serveur est de la forme : <sid>_ora_<id_processus>.trc.

Les anciens paramètres BACKGROUND_DUMP_DEST et USER_DUMP_DEST sont dépréciés.

ADRCI

Automatic Diagnostic Repository Command Interpreter. Outil ligne de commande et interactif pour gérer les erreurs Oracle. ADRCI offre diverses fonctionnalités

Visualiser le fichier alert.log
Gestion des problèmes et des incidents
Création de packages zippés pour envoi au support Oracle.
Purge des fichiers de traces...

La version 12c introduit une nouvelle fonctionnalité permettant de tracer toute action DDL. Cette fonctionnalité n'est pas activé par défaut.

Script utile pour ADRCI

Le shell suivant propose des fonctions utiles, adrci_fct à positionner sous /usr/local/bin

# Fonctions ADRCI utiles
# Se positione dans le répertoire des traces.
function trace {
  cd $HOME
  TRACE=$(adrci exec="show homes" | grep $ORACLE_SID)
  cd ${ORACLE_BASE}/${TRACE}/trace
}

# L'option -d permet de visualiser en dynamique le fichier alert.log
function alerte {
  cd $HOME
  TRACE=$(adrci exec="show homes" | grep $ORACLE_SID)
  if [ "$1" = "-d" ]; then
    adrci exec="set home ${TRACE};show alert -tail -f"
  else
    adrci exec="set home ${TRACE};show alert"
  fi
}

# l'option -a permet de visualiser les problèmes sur l'ensemble
function probleme {
  cd $HOME
  if [ "$1" = "-a" ]; then
    for i in $( adrci exec="show homes" | grep -v "ADR Homes:" )
    do
      adrci exec="set home ${i};show problem"
    done
  else
    TRACE=$(adrci exec="show homes" | grep $ORACLE_SID)
    adrci exec="set home ${TRACE};show problem"
  fi
}

function adrci_show_control {
  cd $HOME
  for i in $( adrci exec="show homes" | grep $ORACLE_SID )
  do
    echo "SHOW CONTROL ${i}:"
    adrci exec="set home ${i}; show control;"
  done
}

function adrci_set_control {
  cd $HOME
  export SHORT=168 # 1 semaine ( 7 jours )
  export LONG=720 # 1 mois ( 30 jours )
  for i in $( adrci exec="show homes" | grep $ORACLE_SID )
  do
    echo "set control ${i}:"
    adrci exec="set home ${i}; set control \(SHORTP_POLICY=${SHORT}, LONGP_POLICY=${LONG}\);"
  done
}

function adrci_purge_trace {
  cd $HOME
  export TEMPS=240 # 4 heures
  for i in $( adrci exec="show homes" | grep $ORACLE_SID )
  do
    adrci exec="set home ${i}; purge -age ${TEMPS}"
  done
}

En cas de soucis adrci -> erreur : No ADR base is set. Ceci est du à une corruption ou une absence du fichier /ora01/app/oracle/product/19/DB/log/diag/adrci_dir. Ce fichier contient le chemin vers ORACLE_BASE. Sous root créer le répertoire suivant :

mkdir -p /ora01/app/oracle/product/19/DB/log/diag
chown -R oracle:oinstall /ora01/app/oracle/product/19/DB/log

Puis sous oracle générer ce fichier.

printf "%s" "/ora01/app/oracle" > /ora01/app/oracle/product/19/DB/log/diag/adrci_dir.mif

Afin de pouvoir utiliser adrci_fct et oraset, il suffit de rajouter les lignes suivantes dans le fichier .bash_profile du user oracle et ce sur chaque noeud.

source /usr/local/bin/adrci_fct
source /usr/local/bin/oraset

Sauvegarde et restauration

Sauvegarder à rien ne sert, si restaurer ne peut se faire.

Le DBA doit sauvegarder une base de données. En cas de panne, le DBA est obligé de restaurer une base de données.

La sauvegarde est une opération standard, presque banale, le plus souvent automatisée. La restauration est la plupart du temps non désirée, imprévisible, malvenue…

Tout ce qui est susceptible de mal tourner, tournera nécessairement mal. Edward Aloysius Murphy Jr.

La sauvegarde sert essentiellement de protection contre les pannes. Il existe différentes sortes de pannes. Dans certaines situations Oracle peut remettre automatiquement la base en état. Les situations critiques sont celles où l'intervention manuelle est requise.

Ici il ne sera présenté que l'outil spécialement dédié à la sauvegarde/restauration : Recovery MANager, soit RMAN.

Recovery MANager

RMAN est l'outil fournit avec Oracle pour la sauvegarde et la restauration des bases de données. Livré en standard depuis la version 8i, RMAN permet :

sauvegarde complète ou incrémentale
sauvegarde partielle
restauration globale ou partielle
clonage de base
corriger les blocs corrompus...

Note sur import/export. Très utilisé comme mode de sauvegarde car simple, cet outil n'a jamais été conçu comme solution de sauvegarde et encore moins de restauration.

RMAN permet de sauvegarder :

A froid → Base stoppée. On parle de sauvegarde cohérente.
A chaud → base ouverte. On parle alors de sauvegarde incohérente.

La sauvegarde à chaud implique un fonctionnement en mode archivelog. Sans cela RMAN génère une erreur et refuse d'effectuer la sauvegarde.

Architecture RMAN

La base à sauvegarder est appelée cible → target. La connexion à une base cible utilise la couche Oracle*Net.

L'ensemble d'une sauvegarde est nommé backupset. Un backupset contient des backuppieces. Il est possible d'avoir des backuppieces d'une taille données → option maxpiecesize.

Les informations sur la sauvegarde peuvent être stockées sous deux formes :

dans le fichier de contrôle de la base,
dans un catalogue.

L'utilisation d'un catalogue permet de centraliser la sauvegarde de bases multiples.

RMAN permet également de sauvegarder les fichiers tels que → backup as copy. Le schéma suivant présente le principe de RMAN.

Le média de stockage peut être du disque ou une bande. Il est possible de paralléliser la communication en allouant plusieurs canaux → allocate channel.

Pour utiliser RMAN simplement, il est conseillé de définir une zone de récupération rapide → Fast Recovery Area ( FRA ). Mais cela n'est pas obligatoire. La FRA permet de simplifier les sauvegardes/restaurations. La base LUKE crée précédemment dispose d'une FRA, elle est également en archivelog permettant ainsi une sauvegarde à chaud.

Sauvegarde à chaud

Dans cet exemple la base sera sauvegardée sans arrêt de celle-ci.

rman target sys/Manager19#@LUKE
RMAN> backup database plus archivelog delete all input;
RMAN> exit;

Cette simple ligne sauvegarde l'ensemble de la base, les archivelog et les efface après sauvegarde.

Conclusion

Ce billet plus long que les autres pourrait encore et encore faire l'objet de nombreux ajouts. Peut-être plus tard...

Installer VirtualBox sous CentOS 7

Silverlake — Fri, 02 Oct 2020 15:07:00 +0200

Introduction

Virtualbox est une solution très simple et gratuite de gestion des machines virtuelles. Bien que disposant d'une interface graphique, il est possible de gérer VirtualBox via la commande vboxmanage. Ce billet présente l'installation et une configuration simple de l'environnement VirtualBox sous CentOS 7.

Installation packages

Classique via yum

yum install -y kernel-devel kernel-headers gcc make perl wget

Charger la clé du dépots Oracle VirtualBox

wget https://www.virtualbox.org/download/oracle_vbox.asc
rpm --import oracle_vbox.asc

Charger le dépots des RPM VirtualBox ( il sera nécessaire de confirmer la clé )

wget http://download.virtualbox.org/virtualbox/rpm/el/virtualbox.repo -O /etc/yum.repos.d/virtualbox.repo

Installer VirtualBox

yum -y install VirtualBox-6.1

Configuration

Dossier des VM, File Systeme dédié monté sous /VM. La commande VBoxManage peut être aussi écrite : vboxmanage

VBoxManage setproperty machinefolder /VM

Vérification

vboxmanage list systemproperties | grep folder
Default machine folder:          /VM

Configurer l'interface réseau interne

vboxmanage hostonlyif create
vboxmanage hostonlyif ipconfig vboxnet0 --ip 192.168.56.1

Vérification

vboxmanage list hostonlyifs
Name:            vboxnet0
GUID:            786f6276-656e-4074-8000-0a0027000000
DHCP:            Disabled
IPAddress:       192.168.56.1
NetworkMask:     255.255.255.0
IPV6Address:     
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Wireless:        No
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-vboxnet0

Désactiver le DHCP sur vboxnet0

vboxmanage dhcpserver remove --ifname vboxnet0
vboxmanage list dhcpservers

Importer une VM, fichier .ova

vboxmanage import DOK01.ova

Démarrer la VM sans la console

VboxManage startvm DOK01 --type headless

La liste des options VboxManage via ce lien : https://www.virtualbox.org/manual/ch08.html

Synchronisation horaire Cluster RAC Oracle

Silverlake — Wed, 04 Mar 2020 09:18:00 +0100

Introduction

La synchronisation horaire est vitale dans un cluster RAC. L'éviction de noeud peut être générée en cas de différence. Par défaut Oracle utilise NTP pour assurer la synchronisation horaire. Toutefois il est possible de laisser le cluster gérer ceci via CTSS. Ce billet présente l'activation de CTSS sur des serveurs Red Hat

CTSS

Cluster Time Synchronization Services. Par défaut il est en mode Observer. lancer la commande suivante en tant que user grid.

crsctl check ctss 
CRS-4700: The Cluster Time Synchronization Service is in Observer mode.

Afin de le faire passer en mode Active, il faut désactiver totalement NTP. Red Hat 7 utilise chrony pour la synchronisation horaire, dans certains cas l'ancien démon ntp est toujours utilisé. Sur chaque noeud deconfigurer ntp et chrony ( en tant que root )

mv /etc/chrony.conf /etc/chrony.conf.old
mv /etc/ntp.conf /etc/ntp.conf.old
systemctl stop chronyd
systemctl disable chronyd
systemctl stop ntpd
systemctl disable ntpd

En tant que user grid valider l'activiation de CTSS

crsctl check ctss
CRS-4701: The Cluster Time Synchronization Service is in Active mode.
CRS-4702: Offset (in msec): 0

Validation de la synchronisation de tous les noeuds

cluvfy comp clocksync -n all -verbose

Verifying Clock Synchronization across the cluster nodes

Checking if Clusterware is installed on all nodes...
Oracle Clusterware is installed on all nodes.

Checking if CTSS Resource is running on all nodes...
Check: CTSS Resource running on all nodes
  Node Name                             Status
  ------------------------------------  ------------------------
  rac01                                      passed
  rac02                                      passed
CTSS resource check passed

Querying CTSS for time offset on all nodes...
Query of CTSS for time offset passed

Check CTSS state started...
Check: CTSS state
  Node Name                             State
  ------------------------------------  ------------------------
  rac01                                             Active
  rac02                                             Active
CTSS is in Active state. Proceeding with check of clock time offsets on all nodes...
Reference Time Offset Limit: 1000.0 msecs
Check: Reference Time Offset
  Node Name     Time Offset               Status
  ------------  ------------------------  ------------------------
  rac01           0.0                       passed
  rac02           0.0                       passed

Time offset is within the specified limits on the following set of nodes:
"[rac01, rac02]"
Result: Check of clock time offsets passed

Oracle Cluster Time Synchronization Services check passed
Verification of Clock Synchronization across the cluster nodes was successful.

Serveur physique ou virtuel

Silverlake — Tue, 28 Jan 2020 14:40:00 +0100

Comment savoir si la machine sur laquelle on travaille est un vrai serveur ou une machine virtuelle. Il existe plusieurs méthodes. Il faut disposer d'un accès root ou via sudo.

Installer les packages dmidecode et facter

yum -y install dmidecode facter

Par la commande dmidecode

dmidecode -s system-manufacturer
HP

Il s'agit certainement d'un serveur physique

dmidecode -s system-manufacturer
VMware, Inc.

Machine virtuelle VmWare

Par la commande facter

facter virtual
physical

Physique

facter virtual
vmware

Machine virtuelle

Red Hat/CentOS 7 , perte du mot de passe root

Silverlake — Fri, 24 Jan 2020 08:35:00 +0100

Depuis la version 7 de Red Hat/CentOS la procédure de changement en cas de perte du mot de passe root a changé. Pour ce faire, il faut disposer d' un accès console.

Redémarrer la machine et interrompre le chargeur GRUB par la touche « e ».

Se déplacer sur la ligne contenant /boot/vmlinuz… Remplacer la chaine « ro » par la chaine suivante :

rw init=/sysroot/bin/sh

Attention clavier qwerty !!! ( le "/" est le "!", le "w" est le "z" et le "a" est le "q" )

Appuyer sur « ctrl » + « x » pour démarrer

Une invite s’affiche alors sans besoin de mot de passe. Normalement le clavier est devenu azerty. Isoler la partition /sysroot

chroot /sysroot

Changer le mot de passe de root

passwd root

Mettre à jour selinux

touch /.autorelabel

Quitter chroot

exit

Relancer le système

reboot

Récupérer les enregistrements type A d'une zone DNS

Silverlake — Fri, 13 Sep 2019 14:48:00 +0200

Utilisation de la commande dig

dig -tAXFR formation.maison

; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> -tAXFR formation.maison
;; global options: +cmd
formation.maison.	38400	IN	SOA	ns.formation.maison. root.formation.maison. 2019071901 3600 3600 604800 86400
formation.maison.	38400	IN	NS	ns.formation.maison.
ans01.formation.maison.	38400	IN	CNAME	ns.formation.maison.
lux01.formation.maison.	38400	IN	A	192.168.56.41
lux02.formation.maison.	38400	IN	A	192.168.56.42
lux03.formation.maison.	38400	IN	A	192.168.56.43
ns.formation.maison.	38400	IN	A	192.168.56.31
web01.formation.maison.	38400	IN	A	192.168.56.51
web02.formation.maison.	38400	IN	A	192.168.56.52
formation.maison.	38400	IN	SOA	ns.formation.maison. root.formation.maison. 2019071901 3600 3600 604800 86400
;; Query time: 2 msec
;; SERVER: 192.168.56.31#53(192.168.56.31)
;; WHEN: ven. sept. 13 14:47:46 CEST 2019
;; XFR size: 10 records (messages 1, bytes 274)

Utilisation des commande Linux pour récupérer les enregistrements A.

dig -tAXFR formation.maison | egrep -v '^;' | sed 's/\s/\|/g' | grep 'IN|A' | cut -d'|' -f1

lux01.formation.maison.
lux02.formation.maison.
lux03.formation.maison.
ns.formation.maison.
web01.formation.maison.
web02.formation.maison.

Exporter des données depuis une standby database

Silverlake — Wed, 05 Jun 2019 08:58:00 +0200

Introduction

Dans une configuration dataguard il est intéressant d'utiliser la base standby pour procéder à un export. Ceci permet d'éviter une surcharge de la base primaire. Il faut toutefois différentier deux cas selon l'outil utilisé.

EXP : Déprécié certes mais encore très utilisé.
EXPDP : Datapump, la solution depuis la version 10g de Oracle

Une standby database est soit en mode recouvrement ( mount ) ou en read only ( Active Dataguard ). EXP peut fonctionner sur une base en read only, ce qui n'est pas le cas de EXPDP qui doit écrire dans une table de la base. Dans tous les cas il est nécessaire de stopper le processus MRP ( Apply ). Le billet suivant se base sur une version 12c de Oracle.

Arrêt du processus MRP

Se connecter sur la standby database et lancer la commande suivante :

alter database recover managed standby database cancel;

En cas de configuration broker, utiliser DGMGRL et la commande suivante :

edit database STDBY set state='APPLY-OFF';

Utilisation de EXP

Se connecter sur la standby database et lancer la commande suivante :

alter database open read only;

Procéder ensuite à l'export classique. Une fois l'export terminé réactiver le recouvrement.

shutdown immediate;
startup mount;

Réactiver MRP. Si le broker n'est pas utilisé, via SQL*Plus :

alter database recover managed standby database using current logfile disconnect;

Si le broker est en place via DGMGRL

edit database STDBY set state='APPLY-ON';

Utilisation de EXPDP ( Datapump )

La base standby doit être ouverte en mode read write. Il faut donc dans un premier temps la transformer en snapshot database. Il faut également activer le mode flashback ( Fast Recovery Area obligatoire ) et passer la gestion des fichiers en manuel. Se connecter à la standby et passer les commandes suivantes :

alter system set standby_file_management=manual;
alter database flashback on;
alter database convert to snapshot database;
alter database open;

A ce stade la base est en mode read write. Procéder à l'export via expdp. En fin d'exécution réactiver la standby database.

shutdown immediate;
startup mount;
alter system set standby_file_management=auto;
alter database flashback off;
alter database convert to physical standby;

La dernière étape est de réactiver le recouvrement. Si le broker n'est pas utilisé, via SQL*Plus :

alter database recover managed standby database using current logfile disconnect;

Si le broker est en place via DGMGRL

edit database STDBY set state='APPLY-ON';

Conclusion

Il existe une autre solution qui consiste à créer un database link depuis la base primaire vers la standby et de procéder à un export datapump via ce database link. Il y a toutefois un problème avec cette solution si la base utilise des champs LONG qui ne peuvent être exportés via un database link.

Modification informations avec DataPump

Silverlake — Wed, 13 Mar 2019 16:27:00 +0100

Introduction

Il est parfois souhaitable lors d'un export par DataPump de modifier certaines données dites confidentielles. Un bon exemple est un numéro de carte bancaire ou de sécurité sociale. Ce billet présente l'option remap_data de la commande expdp qui permet cette transformation.

La syntaxe pour utiliser remap_data est la suivante :

remap_data=schema.table.colonne:schema.package.fonction

Mise en place

Dans un premier temps créer deux utilisateurs sur la base Oracle avec les droits ad hoc.

-- On utilise la gestion OMF
create tablespace data_test;
-- Objet directory pour datapump
create directory dpump as '/home/oracle/dpump';
-- Utilisateurs
create user alice identified by ecila default tablespace data_test quota unlimited on data_test;
grant connect, resource to alice;
grant read, write on directory dpump to alice;
create user bob identified by robert default tablespace data_test quota unlimited on data_test;
grant connect resource to bob;
grant read, write on directory dpump to bob;

Se connecter alice sur la base

-- Connexion alice
connect alice/ecila
create table t1 ( code number, cb number );
insert into t1 values (1,123456);
insert into t1 values (2,789012);
insert into t1 values (3,345678);
commit;
-- Creation de la fonction de transformation
create or replace package transform as
  function trans_cb ( cb in number) return number;
end;
/
create or replace package body transform as
  function trans_cb ( cb in number) return number as changed_value number;
begin
  changed_value := round(dbms_random.value(100000,999999));
  return changed_value;
end;
/

Il est possible de tester la transformation ainsi :

select transform.trans_cb(123456) from dual;
658794

Lancement de l'export datapump

expdp alice/ecila directory=dpump dumpfile=t1.dpump logfile=t1.dpimp.log tables=alice.t1 remap_data=alice.t1.cb:alice.transform.trans_cb

Puis procéder à l'import datapump dans le schéma de Bob.

 impdp bob/robert directory=dpump dumpfile=test.dpump logfile=test.dpimp.log remap_schema=alice:bob table_exists_action=replace

Se connecter à la base pour vérifier

select * from alice.t1;

      CODE         CB
---------- ----------
         1     123456
         2     789012
         3     345678

select * from bob.t1;

      CODE         CB
---------- ----------
         1     461025
         2     638644
         3     462037

Les données ont bien été modifiées.

Conclusion

La fonction de transformation présentée est simple et facilement adaptable.

Réplication de données Oracle avec Streams

Silverlake — Thu, 10 Jan 2019 15:01:00 +0100

Introduction

Streams n'a pas une très bonne réputation auprès des DBA Oracle, toutefois si l'on souhaite mettre de manière simple et peu onéreuse une réplication de données entre deux serveurs, cette solution n'est pas dénuée d'intérêt.

Oracle déconseille Streams au profit de GoldenGate ( coût supplémentaire ). Streams ne demande pas de licence ce qui est intéressant pour les petits budgets. L'objectif ici est de présenter la mise en place d'une réplication STREAMS entre deux bases Oracle 12c. L'exemple porte sur la réplication bi-directionnelle d'un schéma nommé ALICE entre deux bases de données RED et BLACK.

La base RED est sur le serveur srv1 et la base BLACK sur srv2. La version de Oracle est la 12.1.0.2. L'exemple est toutefois applicable dans les versions antérieures.

La gestion de streams est un livre à elle seule, cet exemple ne montre pas toutes les possibilités, notamment la gestion des conflits.

Principe de STREAMS

Le principe est simple :

Capture des ordres sur la base source
Propagation vers la base cible
Application des ordres sur la base cible.

Les composants STREAMS à mettre en place sont :

File ou queue d'envoi et de réception
Processus de capture, de propagation et d'application
Database links
User dédié à la supervision STREAMS -> strmadmin

Pré-requis

Les bases doivent être en archivelog, le supplemental logging minimum en place et activer le mode force logging. Les requêtes suivantes doivent être passées sur les deux bases RED et BLACK.

select log_mode from v$database;

LOG_MODE
------------------------------------
ARCHIVELOG

select supplemental_log_data_min Min, supplemental_log_data_pk PK, 
supplemental_log_data_ui UI, supplemental_log_data_fk FK from v$database; 

MIN            PK        UI        FK
-------------- --------- --------- ---------
NO             NO        NO        NO

alter database add supplemental log data;

select supplemental_log_data_min Min, supplemental_log_data_pk PK, 
supplemental_log_data_ui UI, supplemental_log_data_fk FK from v$database;

MIN            PK        UI        FK
-------------- --------- --------- ---------
YES            NO        NO        NO

select force_logging from v$database;

FORCE_LOGGING
---------------
NO

alter database force logging;

select force_logging from v$database;

FORCE_LOGGING
---------------
YES

User dédié STREAMS

Il est conseillé de créer un compte avec les droits DBA chargé de la supervision STREAMS. Ces actions sont à effectuer sur les deux bases.

create tablespace data_streams;
create temporary tablespace temp_streams;
create user strmadmin identified by strmadmin default tablespace data_streams temporary tablespace temp_streams 
quota unlimited on data_streams;
grant dba, select_catalog_role to strmadmin;
execute dbms_streams_auth.grant_admin_privilege('STRMADMIN',TRUE);

Configuration Oracle*Net

C'est un élément important dans la réplication STREAMS. Outre la résolution correcte via tnsnames il faut qu'au niveau de chaque base le paramètre global_names soit à TRUE.

show parameter global_names;

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
global_names                         boolean                           FALSE

alter system set global_names=true scope=both;

show parameter global_names;

NAME                                 TYPE                              VALUE
------------------------------------ --------------------------------- ------------------------------
global_names                         boolean                           TRUE

Création des DBLINKS

La création des database links doit être rigoureuse. Il est impératif que le nom des DBLINKS soit identique au nom de la base de données en raison de global_names = true.

Base BLACK, connexion en strmadmin

create database link red connect to strmadmin identified by strmadmin using 'RED';

select * from global_name@red;

GLOBAL_NAME
--------------
RED

Base RED, connexion en strmadmin

create database link black connect to strmadmin identified by strmadmin using 'BLACK';

select * from global_name@black;

GLOBAL_NAME
--------------
BLACK

Ci dessous la configuration tnsnames.ora

RED=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = srv1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = RED)
    )
  )

BLACK=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = srv2)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = BLACK)
    )
  )

Création du user ALICE

A faire sur les deux bases RED et BLACK.

create tablespace data_alice;
create temporary tablespace temp_alice;
create user alice identified by ecila default tablespace data_alice temporary tablespace temp_alice quota unlimited on data_alice;
grant connect,resource to alice;

Uniquement sur la base RED créer des données pour le user ALICE

connect alice/ecila
create table compositeur ( nocomp number(2), prenom varchar2(15 char), nom varchar2(15 char ), naissance date, deces date, constraint pk_compositeur primary key (nocomp) );
insert into compositeur values( 1,'Frédéric','Chopin', to_date('01/03/1810','DD/MM/YYYY'),to_date('17/10/1849','DD/MM/YYYY'));
insert into compositeur values( 2,'Hector','Berlioz', to_date('11/12/1803','DD/MM/YYYY'),to_date('08/03/1869','DD/MM/YYYY'));
insert into compositeur values( 3,'Franz','Liszt', to_date('22/10/1811','DD/MM/YYYY'),to_date('31/07/1886','DD/MM/YYYY'));
insert into compositeur values( 4,'Michel','Legrand', to_date('24/02/1932','DD/MM/YYYY'),null);
insert into compositeur values( 5,'Marin','Marais', to_date('31/05/1656','DD/MM/YYYY'),to_date('15/08/1728','DD/MM/YYYY'));
insert into compositeur values( 6,'Pierre','Boulez', to_date('26/03/1925','DD/MM/YYYY'),to_date('05/01/2016','DD/MM/YYYY'));
insert into compositeur values( 7,'Jean-Michel','Jarre', to_date('24/08/1948','DD/MM/YYYY'),null);
commit;

A ce stade la configuration de base et les pré-requis sont en place. Les manipulations suivantes doivent se faire de manière symétrique, en modifiant certaines clauses, sur les deux bases. Pour toutes les actions utiliser le compte STRMADMIN et non SYSDBA.

Réplication STREAMS du schéma ALICE

Le diagramme suivant présente l'architecture générale de la réplication bi-directionnelle.

Du fait de la symétrie de la réplication, il faut être attentif lors des créations des éléments streams à bien spécifier les clauses qui diffèrent.

Création des queues

Se connecter strmadmin/strmadmin sur chaque base avant la création des queues. Les requêtes sont identiques sur les deux bases.

Création de la file d'envoi.

begin
  dbms_streams_adm.set_up_queue(
  queue_table => 'ENVOI_ALICE',
  queue_name => 'ENVOI_ALICE',
  queue_user => 'STRMADMIN');
end;
/

Création de la file de réception

begin
  dbms_streams_adm.set_up_queue(
  queue_table => 'RECEPTION_ALICE',
  queue_name => 'RECEPTION_ALICE',
  queue_user => 'STRMADMIN');
end;
/

Vérification

select name from dba_queues where owner='STRMADMIN'

NAME
------------------------------
RECEPTION_ALICE
AQ$_RECEPTION_ALICE_E
ENVOI_ALICE
AQ$_ENVOI_ALICE_E

Les queues type AQ$ sont automatiquement mises en place pour gérer les exceptions ( non utilisées dans ce test ).

Création des captures

Les captures sont à mettre en place sur les deux bases. Attention certaines clauses diffèrent selon la base concernée.

Base RED

La capture se fait sur le schéma ALICE.

begin
  dbms_streams_adm.add_schema_rules(
    schema_name => 'ALICE',
    streams_type => 'capture',
    streams_name => 'CAPTURE_ALICE',
    queue_name => 'ENVOI_ALICE',
    include_dml => true,
    include_ddl => true,
    inclusion_rule => true);
  end;
/

Base BLACK

La création est identique à la précédente, sauf la clause inclusion_rule.

begin
  dbms_streams_adm.add_schema_rules(
    schema_name => 'ALICE',
    streams_type => 'capture',
    streams_name => 'CAPTURE_ALICE',
    queue_name => 'ENVOI_ALICE',
    include_dml => true,
    include_ddl => true );
  end;
/

Création des propagations

Une fois les captures faites, il faut envoyer les informations STREAMS vers l'autre base. Cette action est gérée par les propagations. Suite à leur création les propagations sont automatiquement démarrées. Depuis la base RED on envoie vers la queue de réception ( RECEPTION_ALICE ) de la base BLACK et réciproquement.

Base RED

begin
  dbms_streams_adm.add_schema_propagation_rules(
    schema_name => 'ALICE',
    streams_name => 'prop_red_to_black',
    source_queue_name => 'ENVOI_ALICE',
    destination_queue_name => 'RECEPTION_ALICE@BLACK',
    include_dml => true,
    include_ddl => true,
    source_database => 'RED');
end;
/

Base BLACK

begin
  dbms_streams_adm.add_schema_propagation_rules(
    schema_name => 'ALICE',
    streams_name => 'prop_black_to_red',
    source_queue_name => 'ENVOI_ALICE',
    destination_queue_name => 'RECEPTION_ALICE@RED',
    include_dml => true,
    include_ddl => true,
    source_database => 'BLACK');
end;
/

Création des applications

Une fois les données reçues sur la base de destination il faut les appliquer.

Base RED

begin
  dbms_streams_adm.add_schema_rules(
    schema_name=>'ALICE',
    streams_type=>'apply',
    streams_name=>'APPLY_ALICE',
    queue_name=>'RECEPTION_ALICE',
    include_dml=>true,
    include_ddl=>true,
    source_database=>'BLACK'
  );
end;
/

Il peut être intéressant de ne pas stopper le processus d'application en cas d'erreur, ce qui est la configuration par défaut. Procéder ainsi :

begin
  dbms_apply_adm.set_parameter(
    apply_name  => 'APPLY_ALICE', 
    parameter   => 'disable_on_error', 
    value       => 'n');
end;
/

Base BLACK

begin
  dbms_streams_adm.add_schema_rules(
    schema_name=>'ALICE',
    streams_type=>'apply',
    streams_name=>'APPLY_ALICE',
    queue_name=>'RECEPTION_ALICE',
    include_dml=>true,
    include_ddl=>true,
    source_database=>'RED'
  );
end;
/

Il peut être intéressant de ne pas stopper le processus d'application en cas d'erreur, ce qui est la configuration par défaut. Procéder ainsi :

begin
  dbms_apply_adm.set_parameter(
    apply_name  => 'APPLY_ALICE', 
    parameter   => 'disable_on_error', 
    value       => 'n');
end;
/

Instanciation de RED

La dernière étape consiste à l'instanciation de RED sur BLACK. Cette requête doit être lancée sur la base BLACK.

set serveroutput on size 1000000
declare
  current_scn number;
begin
  current_scn:=dbms_flashback.get_system_change_number();
  dbms_output.put_line( 'SCN Courant : ' || current_scn );
  dbms_apply_adm.set_schema_instantiation_scn@RED(
    source_schema_name => 'ALICE',
    source_database_name => 'BLACK',
    instantiation_scn => current_scn,
    recursive => true
  );
end;
/

Importation des données Alice de RED vers BLACK

Utilisation via datapump. Sur chaque serveur créer un répertoire /home/oracle/dpump. Sur chaque base créer un object directory dpump

create directory dpump as '/home/oracle/dpump';

L'import datapump dans BLACK se fera via un dblink -> RED. Dans un premier temps relever le numéro SCN de la base RED

select dbms_flashback.get_system_change_number() from dual;

74246358

Ce numéro doit être utilisé par l'import datapump.Sur la base BLACK lancer l'import datapump ainsi

impdp strmadmin/strmadmin@black directory=dpump network_link=red logfile=alice.dpimp.log table_exists_action=replace schemas=alice flashback_scn=74246358

Démarrage du STREAMS

Sur la base BLACK, démarrer l'apply et la capture

exec dbms_apply_adm.start_apply(apply_name=>'APPLY_ALICE');
exec dbms_capture_adm.start_capture(capture_name=>'CAPTURE_ALICE');

Sur la base RED démarrer l'apply et la capture.

exec dbms_apply_adm.start_apply(apply_name=>'APPLY_ALICE');
exec dbms_capture_adm.start_capture(capture_name=>'CAPTURE_ALICE');

Test

Se connecter à RED en alice et insérer la ligne suivante :

insert into compositeur values(8,'Maurice','Jarre',null,null);
commit;

Visualiser sur BLACK en connection alice la presence de l'insertion

Se connecter à BLACK en alice et faire un update

update compositeur set naissance=to_date('13/09/1924','DD/MM/YYYY') where nocomp=8;
commit;

Se reconnecter à RED pour voir la modification, puis faire un autre update

update compositeur set deces=to_date('28/03/2009','DD/MM/YYYY') where nocomp=8;
commit;

Les deux bases doivent être synchronisées.

Conclusion

La mise en place n'est pas très complexe, il faut juste être attentif à la symétrie. L'avantage c'est que les mises à jours peuvent se faire sur l'une ou l'autre des bases.

Sql*Loader et les dates

Silverlake — Sun, 25 Nov 2018 18:14:00 +0100

Introduction

SQL*Loader est un utilitaire fourni avec Oracle permettant de charger des données dans des tables Oracle depuis des fichiers plats. Le schéma ci-dessous présente le principe de SQL*Loader.

En entrée, SQL*Loader prend un fichier de contrôle ( rien à voir avec le fichier de contrôle de la base de données ) qui pilote le chargement, et un ou plusieurs fichiers de données ASCII.

En sortie, SQL*Loader alimente la base de données Oracle et génère un fichier journal (log), un fichier des rejets (bad - données erronées) et un fichier des refus (discard - données écartées).

Le fichier bad contient des enregistrements qui ont été rejetés par SQL*Loader (format de l’enregistrement non valide par rapport à la description du fichier de contrôle)

Le fichier discard contient les enregistrements rejetés par Oracle (violation d’une contrainte d’intégrité, type de données non valide, etc.).

Les enregistrements rejetés ou refusés sont écrits tels quels dans les fichiers bad et discard qui ont donc, la même structure que les fichiers de données utilisés en entrée ; après correction éventuelle des enregistrements, les fichiers bad et discard peuvent être utilisés comme fichiers d’entrée.

Ce billet présente une insertion via SQL*Loader avec des dates. Ce type de données peut parfois poser des soucis si le fichier de contrôle n'est pas correctement paramétré.

Fichier des données

Ci dessous le fichier à intégrer-> personnes.txt

code|prenom|nom|adr|datenais
10|Walker|Tyler|CP 192, 3418 Magna Ave|30/11/1948 02:49:10,101010
15|Lacota|Yates|391 Nisi. Ave|05/07/1969 21:35:55,555555
20|Patricia|Briggs|Appartement 758-7764 Cras Rd.|12/07/1957 08:28:46,464646
25|Aileen|Wiggins|4078 Libero Av.|06/07/1947 16:36:46,464646
30|Rhiannon|Bender|308 Commodo Chemin|25/07/1965 15:52:58,585858
35|Keith|Simpson|Appartement 839-742 Hendrerit. Ave|04/11/1963 04:52:13,131313
40|Jesse|Baker|343-1474 Vestibulum. Rue|25/07/1965 19:53:08,080808
45|Hilel|Fuentes|6993 Taciti Chemin|19/03/1967 17:09:41,414141
50|Bradley|Carroll|9347 Malesuada Chemin|23/11/1965 14:48:21,212121
55|Bianca|Rodriguez|Appartement 964-8829 Hymenaeos. Rue|22/11/1953 12:29:16,161616

La particularité est ici que le champ datenais est au format Oracle timestamp. La table personnes est donc créée ainsi :

create table personnes ( code number(2), prenom varchar2( 15 char ), nom varchar2( 15 char), adr varchar2( 40 char ), datenais timestamp );

Fichier de contrôle

Ci dessous le fichier de contrôle SQL*Loader

options (skip=1)
load data 
truncate
into table personnes
fields terminated by '|'
( code,
prenom,
nom,
adr,
datenais timestamp 'DD/MM/YYYY HH24:MI:SS,FF6' )

La clause options permet de ne pas tenir compte des entêtes de colonnes.

La ligne datenais permet de définir comment la date est structurée dans le fichier d'origine.

Chargement

Une fois correctement établi le fichier de contrôle le chargement est simple

sqlldr userid=alice/ecila data=personnes.txt control=personnes.ctl log=personnes.log bad=personnes.bad discard=personnes.discard

Il est bien entendu possible de passer via un fichier de paramètres et la clause parfile.

Fichier de paramètres -> personnes.load

userid=alice/ecila
control=personnes.ctl
log=personnes.log
bad=personnes.bad
discard=personnes.discard

Lancement

sqlldr parfile=personnes.load

Note relatif à la langue

Dans certains cas il peut être intéressant de modifier la langue dans laquelle est générée la trace. Ceci se fait en modifiant correctement la variable NLS_LANG.

Trace en anglais :

export NLS_LANG=AMERICAN_AMERICA.UTF8
 sqlldr alice/ecila data=personnes.txt control=personnes.ctl log=personnes.english.log bad=personnes.bad discard=personnes.discard

SQL*Loader: Release 12.1.0.2.0 - Production on Sun Nov 25 18:20:17 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Path used:      Conventional
Commit point reached - logical record count 10

Table PERSONNES:
  10 Rows successfully loaded.

Check the log file:
  personnes.english.log
for more information about the load.

Traces en français.

export NLS_LANG=FRENCH_FRANCE.UTF8
sqlldr alice/ecila data=personnes.txt control=personnes.ctl log=personnes.francais.log bad=personnes.bad discard=personnes.discard

SQL*Loader: Release 12.1.0.2.0 - Production on Dim. Nov. 25 18:20:39 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

Chemin utilisé:      Classique
Point de validation (COMMIT) atteint - nombre d'enregis. logiques 10

Table PERSONNES :
  10 Lignes - Chargement terminé.

Pour plus d'informations sur le chargement, consultez le fichier journal :
  personnes.francais.log

La définition correcte dans le fichier de contrôle du champ datenais est alors primordial, car les américains ne représentent pas les dates comme la France.

Déplacer la base MGMTDB vers un autre diskgroup sur un cluster Oracle 12c.

Silverlake — Thu, 08 Nov 2018 17:13:00 +0100

Introduction

Cette procédure explique comment déplacer la base _MGMTDB vers un autre diskgroup. Cette base gère les informations sur la "santé" du cluster RAC. Lors de la création du cluster cette base est créée sur le diskgroup de l'OCR soit +OCR_VOTING. Il s'agit ici de la déplacer sur +DG_MGMTDB. La version de Oracle utilisée est la 12.1.0.2. Dans cette version la base MGMTDB est de type Plugable Database.

Désactivation ressource

Sur chaque noeud en tant que root stopper et désactiver la ressource ora.crf

/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl stop res ora.crf -init
/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl modify res ora.crf -attr ENABLED=0 -init

Vérification

/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl stat res -t -init

Sortie :

...
ora.crf   1    OFFLINE OFFLINE                    STABLE
...

La ressource est bien OFFLINE

Déplacement de la base

Le principe est de détruire la base et de la recréer sur le nouveau diskgroup. Les actions sont faites en tant que user oragrid. Dans un premier temps relever sur quel noeud tourne la base MGMTDB.

srvctl status MGMTDB
Database is enabled
Instance -MGMTDB is running on node SRV1

Par DBCA supprimer la base MGMTDB depuis le noeud retrouvé précédement soit SRV1.

dbca -silent -deleteDatabase -sourceDB -MGMTDB

Puis la recréer sur le nouveau diskgroup ici +DG_MGMTDB

dbca -silent -createDatabase -sid -MGMTDB -createAsContainerDatabase true -templateName MGMTSeed_Database.dbc -gdbName _mgmtdb -storageType ASM -diskGroupName +DG_MGMTDB -datafileJarLocation /ora01/app/oragrid/product/12.1.0.2/GI/assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -skipUserTemplateCheck

En 12c la base MGMTDB est de type CDB, retrouver le nom du cluster avant de créer la PDB.

olsnodes -c
delta

Si le nom comporte des tirets il faut les remplacer dans la commande, clause pdbName, par des underscores ( exemple CRS-001 -> CRS_001 ). Dans l'exemple le cluster se nomme delta donc pdbName = DELTA.

dbca -silent -createPluggableDatabase -sourceDB -MGMTDB -pdbName DELTA -createPDBFrom RMANBACKUP -PDBBackUpfile /ora01/app/oragrid/product/12.1.0.2/GI/assistants/dbca/templates/mgmtseed_pdb.dfb -PDBMetadataFile /ora01/app/oragrid/product/12.1.0.2/GI/assistants/dbca/templates/mgmtseed_pdb.xml -createAsClone true

Une fois créée, demander la sécurisation par la commande mgmtca. Il ne doit pas y avoir d'erreur.

L'erreur la plus courante est de ne pas indiquer correctement le nom du cluster ce qui provoque l'erreur suivante :

MGTCA-1101 : failure in Oracle Grid Infrastructure Management Repository operation

Dans ce cas refaire les étapes de création. ( Voir MOS : Doc ID 2168379.1 )

Vérification

srvctl status MGMTDB
Database is enabled
Instance -MGMTDB is running on node SRV1

Réactivation ressource

Se connecter root sur chaque noeud et réactiver la ressource ora.crf.

/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl modify res ora.crf -attr ENABLED=1 -init
/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl start res ora.crf -init

Vérification

/ora01/app/oragrid/product/12.1.0.2/GI/bin/crsctl stat res -t -init

Sortie :

...
ora.crf    1        ONLINE  ONLINE     SRV1      STABLE

La ressource est bien ONLINE.

Conclusion

Sur l'ancien diskgroup, soit +OCR_VOTING, il peut rester une arborescence relative à MGMTDB. Celle-ci peut être supprimée manuellement sans danger car il ne s'agit que de répertoires et non de fichiers.

Traces Oracle et ADRCI

Silverlake — Thu, 14 Jun 2018 08:55:00 +0200

Introduction

Trois shell Linux très simples pour configurer de manière rapide et efficace la gestion des traces Oracle via ADRCI. Automatic Diagnostic Repository introduit en 11g permet une centralisation des traces Oracle en un point unique ( BD, Listener,... ). la politique de conservation de ces traces est gérée par 2 paramètres :

SHORTP : Traces ordinaires
LONGP : Traces incidents

En fonction de la durée de conservation, exprimée en heure, les traces sont automatiquement purgées. les shell suivants permettent de configurer rapidement la politique souhaitée.

Visualisation

adrci_show_control.sh

#!/bin/bash
# Visualise la short et la long policy pour la purge des traces oracle
for i in $( adrci exec="show homes" | grep -v "ADR Homes:" )
do
echo "SHOW CONTROL ${i}:"
adrci exec="set home ${i}; show control;"
done

Affectation

adrci_set_control.sh

#!/bin/bash
# Affecte la short et la long policy pour la conservation des traces oracle
# La duree est exprimee en heures.
export SHORT=168 # 1 semaine ( 7 jours )
export LONG=720 # 1 mois ( 30 jours )
for i in $( adrci exec="show homes" | grep -v "ADR Homes:" )
do
echo "set control ${i}:"
adrci exec="set home ${i}; set control \(SHORTP_POLICY=${SHORT}, LONGP_POLICY=${LONG}\);"
done

Lancement manuel

adrci_purge.sh

#!/bin/bash
# Lancement manuel de la purge des traces oracle
# La duree est exprimee en minutes
export TEMPS=240 # ( 4 heures )
for i in $( adrci exec="show homes" | grep -v "ADR Homes:" )
do
echo "purge ${i}:"
adrci exec="set home ${i}; show control; purge -age ${TEMPS}"
done

Cluster RAC et Dataguard avec Oracle 12c

Silverlake — Sat, 09 Jun 2018 10:29:00 +0200

Introduction

Ce billet, assez conséquent, détaille la mise en place d'un environnement Dataguard Oracle 12c en utilisant deux clusters RAC à deux noeuds sur des sites distants. La version de l'OS est CentOS 7.4. La version de Oracle est la 12.1.0.2 avec application du PSU de avril 2018.

Il est supposé une bonne connaissance du RAC et du Dataguard en général.

Au moment de la configuration seule la base YODASA est en place.

DB_NAME : YODA
DB_UNIQUE_NAME : YODASA ( primaire )
DB_UNIQUE_NAME : YODASB ( standby )

Les fichiers de la base sont sur des diskgroups ASM :

DG_YODA
FRA_YODA

La gestion OMF est en place.

La Fast Recovery Area est configurée sur le diskgroup FRA_YODA.

Le schéma ci-dessous présente succinctement la configuration.

Il n'est pas détaillé ici l'installation des binaires Oracle ( Grid et RDBMS ) ainsi que la création de la base primaire YODASA.

Les variables d'environnement Oracle sont :

ORACLE_BASE=/ora01/app/oracle
ORACLE_HOME=/ora01/app/oracle/product/12.1.0.2/DB ( RDBMS, user oracle )
ORACLE_HOME=/ora01/app/oragrid/product/12.1.0.2/GI ( GRID, user oragrid )

La couche Oracle*Net

Les serveurs sont tous gérés par un DNS sur une zone fictive nommée formation.maison. La configuration DNS n'est pas détaillée ici.

Un soin particulier doit être de mise pour cette configuration. Le dataguard utilise massivement le réseau. Les lignes suivantes doivent être présentes sur tous les noeuds de la configuration dans le fichier tnsnames.ora.

YODASA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac01-scan.formation.maison)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = YODASA)
    )
  )

YODASB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac02-scan.formation.maison)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = UMUTST1VE)
    )
  )

# Seulement pour RMAN duplicate ... from active database
YODASA_DUP =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora01sa.formation.maison)(PORT = 1521))
     )
    (CONNECT_DATA =
      (SERVICE_NAME = YODASA)
    )
  )

YODASB_DUP =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST =ora01sb.formation.maison )(PORT = 1521))
       )
    (CONNECT_DATA =
      (SERVICE_NAME = YODASB)
    )
  )

Pour les entrées type *_DUP il faut utiliser l'adresse VIP et un seul des noeuds. Via la commande tnsping, vérifier sur chaque noeud la réponse correcte de la configuration TNS. La boucle shell suivante exécute cette vérification.

for i in YODASA YODASB YODASA_DUP YODASB_DUP; do echo -n $i;  echo -n " --> "; tnsping $i | grep OK; done
YODASA --> OK (10 msec)
YODASB --> OK (20 msec)
YODASA_DUP --> OK (0 msec)
YODASB_DUP --> OK (20 msec)

Sur les noeuds du SITEB soit ora01sb et ora02sb ajouter les lignes suivantes dans le fichier listener.ora. Attention selon le noeud les lignes sont différentes. Sur le serveur ora01sb

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = YODASB)
      (ORACLE_HOME = /ora01/app/oracle/product/12.1.0.2/DB)
      (SID_NAME = YODASB1)
    )
  )

Sur le serveur ora02sb

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = YODASB)
      (ORACLE_HOME = /ora01/app/oracle/product/12.1.0.2/DB)
      (SID_NAME = YODASB2)
    )
  )

Entre les deux noeuds le nom de l'instance est différent. Il faut recharger la configuration listener sur chaque noeuds de SITEB par la commande ''lsnrctl reload"".

Préparation base primaire

Certaines actions sont nécessaires avant de lancer la création de la standby. La base primaire doit être en archivelog.

YODASA1.SYS > select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

YODASA1.SYS > archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     34
Next log sequence to archive   36
Current log sequence           36
YODASA1.SYS >

Il est de plus nécessaire d'activer le mode force logging.

alter database force logging;

La requête suivante permet de vérifier certains points. Pour cette procédure le mode flashback n'est pas actif.

YODASA1.SYS > select name,db_unique_name,database_role,log_mode,force_logging,flashback_on from v$database;

NAME      DB_UNIQUE_NAME                 DATABASE_ROLE    LOG_MODE     FORCE_LOGGING                           FLASHBACK_ON
---------       ------------------------------ ---------------- ------------ --------------------------------------- ------------------
YODA      YODASA                      PRIMARY          ARCHIVELOG   YES                                     NO

YODASA1.SYS >

Configuration du transport et l'apply

Plusieurs paramètre sont nécessaires pour le transport et l'application des ordres SQL.

alter system set log_archive_config='DG_CONFIG=(YODASA,YODASB)' scope=both sid='*';
alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=YODASA' scope=both sid='*';
alter system set log_archive_dest_2='SERVICE=YODASB VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=YODASB' scope=both sid='*';
alter system set log_archive_max_processes=8 scope=both sid='*';
alter system set fal_client='YODASA' scope=both sid='*';
alter system set fal_server='YODASB' scope=both sid='*';
alter system set standby_file_management=AUTO scope=both sid='*';

Standby redolog

Les standby redolog sont utilisés par la base standby, toutefois une base peut être primaire ou standby donc il est de bonne pratique de crééer de suite les standby redolog. Il faut 1 standby redolog de plus par thread et ils doivent avoir la même dimension que les online redolog.

YODASA1.SYS > select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME     CON_ID
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ --------- ----------
         1          1         34   52428800        512          2 YES INACTIVE                377639 06-JUN-18       420081 06-JUN-18          0
         2          1         35   52428800        512          2 YES INACTIVE                420081 06-JUN-18       463619 07-JUN-18          0
         3          1         36   52428800        512          2 NO  CURRENT                 463619 07-JUN-18   2.8147E+14                    0
         4          2          7   52428800        512          2 YES INACTIVE                427685 06-JUN-18       437418 06-JUN-18          0
         5          2          8   52428800        512          2 YES INACTIVE                437418 06-JUN-18       462576 07-JUN-18          0
         6          2          9   52428800        512          2 NO  CURRENT                 462576 07-JUN-18   2.8147E+14                    0

6 rows selected.

YODASA1.SYS >

La base primaire comporte 3 groupes de online redolog par thread ( taille des membres : 50Mo ), il faut donc 4 standby redolog par thread. Oracle recommande de ne pas multiplexer les standby redolog.

YODASA1.SYS > alter database add standby logfile thread 1 ('+DG_YODA') size 50M;

Database altered.

YODASA1.SYS > /

Database altered.

YODASA1.SYS > /

Database altered.

YODASA1.SYS > /

Database altered.

YODASA1.SYS > alter database add standby logfile thread 2 ('+DG_YODA') size 50M;

Database altered.

YODASA1.SYS > /

Database altered.

YODASA1.SYS > /

Database altered.

YODASA1.SYS > /

Database altered.
YODASA1.SYS > select group#,thread#,sequence#,bytes,status from v$standby_log;

    GROUP#    THREAD#  SEQUENCE#      BYTES STATUS
---------- ---------- ---------- ---------- ----------
         7          1          0   52428800 UNASSIGNED
         8          1          0   52428800 UNASSIGNED
         9          1          0   52428800 UNASSIGNED
        10          1          0   52428800 UNASSIGNED
        11          2          0   52428800 UNASSIGNED
        12          2          0   52428800 UNASSIGNED
        13          2          0   52428800 UNASSIGNED
        14          2          0   52428800 UNASSIGNED

8 rows selected.

YODASA1.SYS >

Fichier de paramètres

Pour la génération de la standby partir du pfile de la primaire et y apporter certaines modifications.

create pfile='/home/oracle/initYODASB1.ora' from spfile;

Editier ce fichier, retirer toutes les lignes contenant "__" ainsi que les lignes cluster_database et control_files.

Dans un dataguard le paramètre DB_NAME doit être identique sur les deux sites soit ici YODA. C'est le paramètre DB_UNIQUE_NAME qui fait la différence.

Modifier les occurences YODASA et YODASB ( YODASA devient YODASB et réciproquement ) voir exemple suivant :

*.db_block_size=8192
*.db_create_file_dest='+DG_YODA'
*.db_name='YODA'
*.db_recovery_file_dest='FRA_YODA'
*.db_recovery_file_dest_size=20G
*.db_unique_name='YODASB'
*.fal_client='YODASB'
*.fal_server='YODASA'
YODASB1.instance_number=1
YODASB2.instance_number=2
*.log_archive_config='DG_CONFIG=(YODASA,YODASB)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=YODASB'
*.log_archive_dest_2='SERVICE=YODASA VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=YODASA'
*.log_archive_format='YODA_%t_%s_%r.arch'
*.log_archive_max_processes=8
*.open_cursors=300
*.pga_aggregate_target=360M
*.processes=300
*.remote_login_passwordfile='exclusive'
*.sga_target=1280M
*.standby_file_management='AUTO'
YODASB1.thread=1
YODASB2.thread=2
YODASB1.undo_tablespace='UNDOTBS1'
YODASB2.undo_tablespace='UNDOTBS2'

Ce fichier est à copier sous le nom initYODASB1.ora sur le serveur ora01sb dans le répertoire $ORACLE_HOME/dbs. Le principe est dans un premier temps de créer la standby sans gestion de cluster et de l'activer par la suite.

Fichier de mot de passe

Toujours sur le serveur ora01sb et dans $ORACLE_HOME/dbs crééer un fichier de mot de passe temporaire. Celui-ci sera recopié par RMAN lors du duplicate depuis la base primaire.

orapwd file=orapwYODASB1
Enter password for SYS:

Création de la standby

La création utilisera RMAN via la commande duplicate from active database. Ici la création est lancée depuis le serveur ora01sb

rman target sys@YODASA_DUP auxiliary sys@YODASB_DUP

Recovery Manager: Release 12.1.0.2.0 - Production on Thu Jun 7 07:52:05 2018

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

target database Password:
connected to target database: YODASA1 (DBID=2193309380)
auxiliary database Password:
connected to auxiliary database (not started)

RMAN> startup clone nomount;

Oracle instance started

Total System Global Area    1342177280 bytes

Fixed Size                     2924160 bytes
Variable Size                402653568 bytes
Database Buffers             922746880 bytes
Redo Buffers                  13852672 bytes

RMAN> duplicate target database for standby from active database;

Starting Duplicate Db at 07/06/2018 09:00:33
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=2 device type=DISK
...
...
Finished Duplicate Db at 07/06/2018 09:02:22

RMAN>

A ce stade la standby est en place il reste à l'intégrer au cluster. Editer le fichier $ORACLE_HOME/dbs/initYODASB1.ora et ajouter les deux lignes suivantes :

*.cluster_database=true
*.control_files='+DG_YODA/YODASB/CONTROLFILE/current.281.978166873','+FRA_YODA/YODASB/CONTROLFILE/current.499.978166875'

Le noms des fichiers de contrôle générés est disponible dans la trace du duplicate RMAN.

Supprimer le spfile généré

rm $ORACLE_HOME/dbs/spfileYODASB1.ora

Stopper la base standby et la redémarrer en mode mount.

export ORACLE_SID=YODASB1
sqlplus / as sysdba

shutdown immediate;
startup mount

Créer le spfile sur le diskgroup ASM

create spfile='+DG_YODA/YODASB/spfileYODASB.ora' from pfile;
shutdown immediate;

Sur chaque noeud du cluster standby créer sous $ORACLE_HOME/dbs un fichier initYODASB1.ora ( ora01sb ) et initYODASB2.ora ( ora02sb ) avec la ligne suivante :

SPFILE='+DG_YODA/YODASB/spfileYODASB.ora'

Intégration au cluster

Les commandes suivantes intègre la base standby au cluster

srvctl add database -db YODASB -oraclehome $ORACLE_HOME -dbtype RAC -role PHYSICAL_STANDBY -startoption MOUNT -dbname YODA -diskgroup "DG_YODA,FRA_YODA"
srvctl add instance -db YODASB -instance YODASB1 -node ora02sa
srvctl add instance -db YODASB -instance YODASB2 -node ora02sb
srvctl modify database -db YODASB -spfile '+DG_YODA/YODASB/spfileYODASB.ora'
srvctl config database -db YODASB
Database unique name: YODASB
Database name: YODA
Oracle home: /ora01/app/oracle/product/12.1.0.2/DB
Oracle user: oracle
Spfile: +DG_YODA/YODASB/spfileYODASB.ora
Password file:
Domain:
Start options: mount
Stop options: immediate
Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Server pools:
Disk Groups: DG_YODA,FRA_YODA
Mount point paths:
Services:
Type: RAC
Start concurrency:
Stop concurrency:
OSDBA group: g_db_sysdba
OSOPER group: g_db_sysoper
Database instances: YODASB1,YODASB2
Configured nodes: ora01sb,ora02sb
Database is administrator managed

Activation dataguard

Démarrer la base standby

srvctl start database -db YODASB
srvctl status database -db YODASB
Instance YODASB1 is running on node ora01sb
Instance YODASB2 is running on node ora02sb

Se connecter à la standby et activer le recouvrement

alter database recover managed standby database using current logfile disconnect from session;

Les commandes suivantes permettent de voir le fonctionnement correct du dataguard.

Sur la base primaire YODASA

select thread#,max(sequence#) from v$archived_log group by thread#;

   THREAD# MAX(SEQUENCE#)
         1             41
         2             14

Sur la base standby YODASB

select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;

   THREAD# MAX(SEQUENCE#)
         1             41
         2             14

La consultation de la vue V$DATAGUARD_STATUS est aussi intéressante.

Fichier de mot de passe

Il faut transférer le fichier de mot de passe sur le diskgroup ASM. Sur le serveur ora01sb se connecter oragrid et charger l'environnement asm.

asmcmd -p
ASMCMD [+] > pwcopy --dbuniquename YODASB '/ora01/app/oracle/product/12.1.0.2/DB/dbs/orapwYODASB1' '+DG_YODA/YODASB/orapwYODASB'
copying /ora01/app/oracle/product/12.1.0.2/DB/dbs/orapwUMUTST1VE1 -> +DG_UMU/UMUTST1VE/orapwUMUTST1VE
ASMCMD-9453: failed to register password file as a CRS resource
ASMCMD [+] > exit

Le message ASMCMD-9453 est normal car l'enregistrement doit être fait par le user oracle. Se reconnecter oracle et modifier la configuration cluster

srvctl modify database -db YODASB -pwfile '+DG_YODA/YODASB/orapwYODASB'

Supprimer le fichier de mot de passe local.

rm /ora01/app/oracle/product/12.1.0.2/DB/dbs/orapwYODASB1

Configuration broker

La broker permet de simplifier les commandes d'administration du dataguard. Depuis la version 12c il n'est plus nécessaire de configurer les services _DGMGRL dans le listener.

Positionner les fichiers de configuration du broker sur l'ASM et démarrer le broker

Sur base primaire : YODASA

alter system set log_archive_dest_2='' scope=both sid='*';
alter system set dg_broker_config_file1='+DG_YODA/YODASA/dr1YODASA.dat' scope=both sid='*';
alter system set dg_broker_config_file2='+FRA_YODA/YODASA/dr2YODASA.dat' scope=both sid='*';
alter system set dg_broker_start=TRUE scope=both sid='*';

Sur la base standby : YODASB

alter system set log_archive_dest_2='' scope=both sid='*';
alter system set dg_broker_config_file1='+DG_YODA/YODASB/dr1YODASB.dat' scope=both sid='*';
alter system set dg_broker_config_file2='+FRA_YODA/YODASB/dr2YODASB.dat' scope=both sid='*';
alter system set dg_broker_start=TRUE scope=both sid='*';

Depuis le serveur ora01sa ( base primaire ) se connecter au broker

dgmgrl /
DGMGRL> create configuration DG_YODA as primary database is YODASA connect identifier is "YODASA";
Configuration "dg_yoda" created with primary database "yodasa"
DGMGRL> add database YODASB as connect identifier is "YODASB" maintained as physical;
Database "yodasb" added
DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration verbose;

Configuration - dg_yoda

  Protection Mode: MaxPerformance
  Members:
  yodasa - Primary database
    yodasb - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL>

Les commandes show/validate database verbose YODASA et show/validate database verbose YODASB donnent un grand nombre d'informations.

Switchover par broker

Lancer le broker et se connecter à la future primaire.

dgmgrl
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys@YODASB
Password:
Connected as SYSDBA.
DGMGRL> switchover to YODASB;
Performing switchover NOW, please wait...
New primary database "yodasb" is opening...
Oracle Clusterware is restarting database "yodasa" ...
Switchover succeeded, new primary is "yodasb"
DGMGRL> show configuration verbose;
Configuration - dg_yoda

  Protection Mode: MaxPerformance
  Members:
  yodasb - Primary database
    yodasa - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL>

Modifier paramètres via le broker

Certains paramètres de la base peuvent être modifiés via le broker. Ici par exemple configuration de archive_lag_target à 900 secondes.

DGMGRL> edit database YODASB set property ArchiveLagTarget=900;
DGMGRL> edit database YODASA set property ArchiveLagTarget=900;
DGMGRL> show database verbose YODASB;
Database - yodasb

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    YODASB1
    YODASB2

  Properties:
    DGConnectIdentifier             = 'YODASB'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    RedoRoutes                      = ''
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '30'
    ApplyParallel                   = 'AUTO'
    StandbyFileManagement           = 'AUTO'
    ArchiveLagTarget                = '900'
    LogArchiveMaxProcesses          = '8'
    LogArchiveMinSucceedDest        = '1'
    DbFileNameConvert               = ''
    LogFileNameConvert              = ''
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    StaticConnectIdentifier(*)
    StandbyArchiveLocation(*)
    AlternateLocation(*)
    LogArchiveTrace(*)
    LogArchiveFormat(*)
    TopWaitEvents(*)
    (*) - Please check specific instance for the property value

Database Status:
SUCCESS

Le fichier alert.log de la base montre cette modification

...
2018-06-07 11:05:54.328000 +02:00
ALTER SYSTEM SET archive_lag_target=900 SCOPE=BOTH SID='*';
...

Configuration de services

Le principe général est de démarrer les services uniquement quand la base est primaire. Sur chaque envrionnement il faut donc créer les services en indiquant la clause -role PRIMARY. Ici on met en place 3services

YODA_APS : Load Balancing
YODA_BAS1 : sur noeud 1 et failover sur noeud 2
YODA_BAS2 : sur noeud 2 et failover sur noeud 1

Sur base primaire YODASB

srvctl add service -db YODASB -service YODA_APS -preferred YODASB1,YODASB2 -role PRIMARY
srvctl add service -db YODASB -service YODA_BAS1 -preferred YODASB1 -available YODASB2 -role PRIMARY
srvctl add service -db YODASB -service YODA_BAS2 -preferred YODASB2 -available YODASB1 -role PRIMARY

Sur base standby YODASA

srvctl add service -db YODASA -service YODA_APS -preferred YODASA1,YODASA2 -role PRIMARY
srvctl add service -db YODASA -service YODA_BAS1 -preferred YODASA1 -available YODASA2 -role PRIMARY
srvctl add service -db YODASA -service YODA_BAS2 -preferred YODASA2 -available YODASA1 -role PRIMARY

Monitoring RMAN

Silverlake — Wed, 07 Mar 2018 09:12:00 +0100

Les sauvegardes et restaurations RMAN sont parfois longues et le Recovery MANager n'est pas toujours très bavard. les requêtes suivantes sont utiles afin de suivre l'avancement du processus.

Cette requête permet de suivre l'avancement et surtout de déterminer une date de fin approximative.

alter session set nls_date_format='dd/mm/yy hh24:mi:ss';

set linesize 250
col dbsize_mbytes      for 99,999,990.00 justify right head "TailleDB_MB"
col input_mbytes       for 99,999,990.00 justify right head "Lecture_MB"
col output_mbytes      for 99,999,990.00 justify right head "Ecriture_MB"
col output_device_type for a10           justify left head "DEVICE"
col complete           for 990.00        justify right head "COMPLETE %"
col compression        for 990.00        justify right head "COMPRESS|% ORIG"
col est_complete       for a20           head "Fin estimée"
col recid              for 9999999       head "ID"

select recid, output_device_type, dbsize_mbytes, input_bytes/1024/1024 input_mbytes, output_bytes/1024/1024 output_mbytes, 
(output_bytes/input_bytes*100) compression, 
(mbytes_processed/dbsize_mbytes*100) complete, 
to_char(start_time + (sysdate-start_time)/(mbytes_processed/dbsize_mbytes),'DD-MON-YYYY HH24:MI:SS') est_complete
from v$rman_status rs, (select sum(bytes)/1024/1024 dbsize_mbytes from v$datafile)
where status='RUNNING'  and output_device_type is not null;

Ci dessous un exemple

                                                                 COMPRESS
      ID DEVICE        TailleDB_MB     Lecture_MB    Ecriture_MB   % ORIG COMPLETE % Fin estimée
-------- ---------- -------------- -------------- -------------- -------- ---------- --------------------
    9791 DISK         1,173,192.67     212,822.94      59,460.00    27.94      18.14 07-MAR-2018 17:28:28

Les requêtes suivantes permettent également de suivre le processus phase par phase. La seconde donne les événements d'attente.

select SID, START_TIME,TOTALWORK, sofar, (sofar/totalwork) * 100 done,
sysdate + TIME_REMAINING/3600/24 "Fin à"
from v$session_longops
where totalwork > sofar
AND opname NOT LIKE '%aggregate%'
AND opname like 'RMAN%';

column sid format 9999
column spid format 99999
column client_info format a25
column event format a30
column secs format 9999
SELECT SID, SPID, CLIENT_INFO, event, seconds_in_wait secs, p1, p2, p3
  FROM V$PROCESS p, V$SESSION s
  WHERE p.ADDR = s.PADDR
  and CLIENT_INFO like 'rman channel=%';

En complément voici comment connaitre la volumétrie prise par les sauvegardes

select ctime "Date", 
decode(backup_type, 'L', 'Archive Log', 'D', 'Full', 'Incremental') "Type Sauvegarde", 
bsize "Taille MB"
from (select trunc(bp.completion_time) ctime, backup_type, round(sum(bp.bytes/1024/1024),2) bsize
       from v$backup_set bs, v$backup_piece bp
       where bs.set_stamp = bp.set_stamp
       and bs.set_count  = bp.set_count
       and bp.status = 'A'
       group by trunc(bp.completion_time), backup_type)
order by 1, 2;

Creation d'un base de données Stand-Alone

Silverlake — Sun, 14 Jan 2018 11:10:00 +0100

Introduction

Dans un précédent billet il fut présenté un script de création d'une base Oracle 12c sur un cluster RAC à 2 noeuds. Ici il s'agit d'un script basé sur le même modèle mais pour la création d'une base en mode stand-alone de type non-CDB ( pas de pluggable database ).

La version de Oracle en place est 12.2.0.1 l'adaptation à une autre version est simple, il suffit de modifier la variable ORACLE_HOME. Le script fonctionne en 11gR2 et 12c sans difficulté.

Présentation du script.

Celui-comporte en début un certain nombre de variables qu'il suffit de personnaliser, notamment le nom de la base et l'emplacement des fichiers et aussi des tailles SGA et PGA.

Les variables ORACLE_BASE et ORACLE_HOME respectent la norme OFA.

La gestion des fichiers est assurée en mode OMF.

Il est nécessaire de créer un répertoire $HOME/sql avant lancement.

######################################################
# Shell de creation d'une base Stand-Alone
# SILVERLAKE : 12/01/2018
# Note : Deux fichiers ( init<SID>.ora et create<SID>.sql ) sont ecrits sous $HOME/sql
# Appel : createBASE.sh
######################################################
#!/bin/bash

if [ -z ${ORACLE_BASE} ]
then
  export ORACLE_BASE=/ora01/app/oracle
fi

if [ -z ${ORACLE_HOME} ]
then
  export ORACLE_HOME=${ORACLE_BASE}/product/12.2.0.1/DB
  export PATH=$ORACLE_HOME/bin:$PATH
fi

export DEBUT=$(date +%s)
echo $(date)

# Variables a spécifier
export DB=YODA
export DBUNIQ=${DB}
export ORACLE_SID=${DBUNIQ}
export DATA=${ORACLE_BASE}/oradata
export FRA=${ORACLE_BASE}/fast_recovery_area
export SGA=1280M
export PGA=360M
export MDP=Manager12#
export SERVEUR1=ona01.formation.maison

echo "Suppression ancienne BASE"
rm -rf ${DATA}/${DBUNIQ}
rm -rf ${FRA}/${DBUNIQ}

mkdir -p ${DATA}
mkdir -p ${FRA}

echo "Création base Stand-Alone ${DBUNIQ} sur ${SERVEUR1}"

# Fichier init.ora
# A adapter selon le besoin
cat <<EOF > ${HOME}/sql/init${DB}.ora
db_name=${DB}
db_block_size=8192
db_create_file_dest=${DATA}
db_recovery_file_dest=${FRA}
db_recovery_file_dest_size=5000M
log_archive_format=${DB}_%t_%s_%r.arch
sga_target=${SGA}
pga_aggregate_target=${PGA}
EOF

# Script de creation
# A adapter, notamment dimension des tablespaces standards ( SYSTEM,SYSAUX,TEMP,UNDO,USERS )
# Le tablespace USERS est volontairement cree et bloque a 100K
cat <<EOF > ${HOME}/sql/create${DB}.sql
create database ${DB}
character set AL32UTF8
national character set AL16UTF16
datafile size 500M autoextend on next 500M maxsize 2G extent management local
sysaux datafile size 500M autoextend on next 500M maxsize 2G
undo tablespace UNDOTBS1 datafile size 500M
default temporary tablespace TEMP tempfile size 500M
default tablespace USERS datafile size 100K
logfile group 1 size 50M,
        group 2 size 50M,
        group 3 size 50M
user sys identified by "${MDP}"
user system identified by "${MDP}";
EOF

ln -sfn ${HOME}/sql/init${DB}.ora ${ORACLE_HOME}/dbs/init${DB}.ora

# Creation de la base
echo "Création de l'instance et des fichiers principaux"
resultat=`sqlplus -s "/ as sysdba" <<EOF
create spfile from pfile;
startup force nomount;
start ${HOME}/sql/create${DB}.sql;
exit;
EOF`

echo "Base de données ${DBUNIQ} créee. Les fichiers de contrôle sont en place."

echo "Création des vues du dictionnaire. Phase assez longue"
resultat=`sqlplus -s "/ as sysdba" <<EOF
@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql

BEGIN
 FOR item IN ( SELECT USERNAME FROM DBA_USERS WHERE ACCOUNT_STATUS IN ('OPEN', 'LOCKED', 'EXPIRED') AND USERNAME NOT IN (
'SYS','SYSTEM') )
 LOOP
  dbms_output.put_line('Locking and Expiring: ' || item.USERNAME);
  execute immediate 'alter user ' ||
         sys.dbms_assert.enquote_name(
         sys.dbms_assert.schema_name(
         item.USERNAME),false) || ' password expire account lock' ;
 END LOOP;
END;
/

connect system/${MDP}
@?/sqlplus/admin/pupbld.sql
@?/sqlplus/admin/help/hlpbld.sql helpus.sql
exit;
EOF

# la base est mise en archivelog.
# Commenter ces instructions en cas de non archivelog.
`resultat=`sqlplus -s "/ as sysdba" <<EOF
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
alter system archive log current;
exit;
EOF`

echo ${DBUNIQ}':'${ORACLE_HOME}':Y' >> /etc/oratab

export FIN=$(date +%s)
echo $(date)
export DUREE=$(( ${FIN} - ${DEBUT} ))
echo "Fin de création. Durée -> ${DUREE}"
exit 0

Le script est suffisamment auto-commenté pour être adapté ou amélioré. Par exemple il peut être intéressant de passer en paramètre le nom de la base.

Dans un prochain billet le même script sera adapté pour utiliser le mode CDB soit Pluggable Database.

Informations sur les sauvegardes RMAN

Silverlake — Thu, 16 Nov 2017 09:04:00 +0100

Il est intéressant de connaitre la durée et le volume des sauvegardes RMAN. La vue v$rman_backup_job_details permet de retrouver facilement un bon nombre d'informations. la requête présentée ici donne le type de sauvegarde : archivelog ou base ainsi que la durée en heures et le volume.

select input_type,status,
to_char(start_time,'DD/MM/YYYY HH24:MI' ) Debut,
to_char(end_time,'DD/MM/YYYY HH24:MI' ) Fin,
round( elapsed_seconds/3600,2) "Durée en Hrs",
round(input_bytes/1024/1024/1024,2) "Volume Données (Go)",
round(output_bytes/1024/1024/1024,2) "Taille Sauvegarde (Go)",
output_device_type "Média"
from v$rman_backup_job_details
order by session_key;

Fonctionnalité In-Database Archiving Oracle 12c

Silverlake — Fri, 03 Nov 2017 09:49:00 +0100

La version 12c de oracle Database a introduit une fonctionnalité intéressante vis à vis des données dites d'archives. Il est en effet courant de stocker des milliers, voir des millions de lignes dans des tables et qui ne sont jamais ou très peu utilisées. Ceci peut être particulièrement gênant dans le cas d'une recherche où seules les informations récentes sont souhaitées.

Pour palier à ceci il est fréquent de positionner dans la table un flag disant que l'on prend en compte la ligne ou pas. La fonction In-Database Archiving ou IDA gère ceci de manière plus souple.

Soit la table suivante :

create table personne ( code char(2), prenom char(15), constraint personne_pk primay key ( code));
insert into personne values ('01','Alice');
insert into personne values ('02','Bob');
insert into personne values ('03','Carmen');
commit;

Ici la ligne 03 - Carmen va être jugée non pertinente pour les recherches. Dans le concept IDA les données sont déclarées soit actives, soit archivées. Une donnée marquée archivée devient invisible pour l'application et est stockée sous forme compressée. L'activation est simple soit à la création de la table:

create table personne ( code char(2), prenom char(15), constraint client_pk primary key (code)) row archival;

Soit à postériori

alter table personne row archival;

La commande suivante désactive ce mode

alter table personne no row archival;

L'activation ajoute une colonne de plus à la table (ORA_ARCHIVE_STATE ) . Cette colonne n'est toutefois pas visible par la commande DESC, il faut interroger la table USER_TAB_COLS.

SELECT column_id, column_name, data_type, data_length, hidden_column
FROM   user_tab_cols
WHERE  table_name = 'PERSONNE'
ORDER BY column_id

 COLUMN_ID COLUMN_NAME		DATA_TYPE	     DATA_LENGTH HIDDEN_CO
---------- -------------------- -------------------- ----------- ---------
	 1 CODE 		CHAR			       2 NO
	 2 PRENOM		CHAR			      15 NO
	   SYS_NC00003$ 	RAW			     126 YES
	   ORA_ARCHIVE_STATE	VARCHAR2		    4000 YES

Par défaut la valeur de ORA_ARCHIVE_STATE est à "0"

select ora_archive_state, count(*) from personne group by ora_archive_state;

ORA   COUNT(*)
--- ----------
0	     3

L'exemple suivant présente la fonctionnalité.

select * from personne;

CODE   PRENOM
------ ---------------------------------------------
01     Alice
02     Bob
03     Carmen

Il peut au premier abord évident d'utiliser ceci pour archiver la ligne code = '03' par exemple : update personne set ora_archive_state='1' where code='03'; Il est conseillé toutefois de ne pas utiliser un update simple comme ici mais de passer par le package. dbms_ilm et la fonction archivestatename.

update personne set ora_archive_state=dbms_ilm.archivestatename(1) where code='03';
commit;
select * from personne;

CODE   PRENOM
------ ---------------------------------------------
01     Alice
02     Bob

select ora_archive_state, count(*) from personne group by ora_archive_state;

ORA_ARCHIVE_STATE  COUNT(*)
-----------------  --------
1	                 1
0	                 2

Pour voir les lignes archivées il faut demander la visibilité de toutes les lignes

alter session set row archival visibility=all;
select * from personne;

CODE   PRENOM
------ ---------------------------------------------
01     Alice
02     Bob
03     Carmen

Si on souhaite modifier l'état pour la ligne code '03' il faut au préalable activer la visibilité. La commande suivante réactive l'invisibilité des lignes archivées.

alter session set row archival visibility=active;
select * from personne;

CODE   PRENOM
------ ---------------------------------------------
01     Alice
02     Bob

Attention cette fonctionnalité ne fonctionne que sur le bases non-CDB en 12.1, par contre elle est étendue au CDB en version 12.2.

Channel bonding et VirtualBox

Silverlake — Sun, 30 Jul 2017 11:13:00 +0200

Le channel bonding ou agrégation de lien permet de configurer deux cartes réseau vue comme une seule. Chaque carte est reliée à un port du switch selon le schéma ci-dessous. L'objectif ici n'est pas de détailler la configuration channel bonding qui est largement référencée sur le Net, mais d'apporter une précision en cas d'utilisation de VM VirtualBox.

La mise en place du channel bonding sous RedHat 7 n'est pas complexe il suffit de créer 3 fichiers sous /etc/sysconfig/network-scripts. Il faut toutefois prendre une précaution avec VirtualBox : La clause fail_over_mac=1 est impérative en mode active-backup afin d'assurer le basculement correct de la MAC address. Sans cette option en cas de défaillance de la carte principale il faut redemarrer le service réseau manuellement.

ifcfg-bond0

DEVICE=bond0
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
BROADCAST=192.168.56.255
NETWORK=192.168.56.0
BONDING_OPTS="miimon=100 mode=active-backup fail_over_mac=1"
IPADDR=192.168.56.41
PREFIX=24
GATEWAY=192.168.56.1
DNS1=192.168.56.11
DOMAIN=formation.maison

ifcfg-enp0s3

DEVICE=enp0s3
ONBOOT=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

ifcfg-enp0s8

DEVICE=enp0s8
ONBOOT=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

Test channel bonding, fonctionnement normal enp0s3 est la carte active ( MAC address de bond0 : 08:00:27:05:44:79 ) .

ip addr

...
2: enp0s3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:05:44:79 brd ff:ff:ff:ff:ff:ff
...
5: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:d6:29:b5 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 08:00:27:05:44:79 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.41/24 brd 192.168.56.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe05:4479/64 scope link 
       valid_lft forever preferred_lft forever

Déconnexion de enp0s3, la carte active devient enp0s8 ( MAC address de bond0 : 08:00:27:d6:29:b5 )

ip addr

...
2: enp0s3: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 state DOWN qlen 1000
    link/ether 08:00:27:05:44:79 brd ff:ff:ff:ff:ff:ff
...
5: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
    link/ether 08:00:27:d6:29:b5 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 08:00:27:d6:29:b5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.41/24 brd 192.168.56.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe05:4479/64 scope link 
       valid_lft forever preferred_lft forever