jeudi, décembre 10 2020

Installation Oracle 19c

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

version_oracle.jpg, janv. 2020

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 :

binaires19c.jpg, déc. 2020

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

oraclenet.jpg, déc. 2020

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.

arbo_adr_luke_oracle.jpg, déc. 2020

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.

principerman.png, déc. 2020

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

vendredi, octobre 2 2020

Installer VirtualBox sous CentOS 7

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  […]

Lire la suite

mercredi, mars 4 2020

Synchronisation horaire Cluster RAC Oracle

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  […]

Lire la suite

mardi, janvier 28 2020

Serveur physique ou virtuel

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  […]

Lire la suite

vendredi, janvier 24 2020

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

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  […]

Lire la suite

vendredi, septembre 13 2019

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

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.  […]

Lire la suite

mercredi, juin 5 2019

Exporter des données depuis une standby database

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 :  […]

Lire la suite

mercredi, mars 13 2019

Modification informations avec DataPump

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  […]

Lire la suite

jeudi, janvier 10 2019

Réplication de données Oracle avec Streams

replication_streams_red_black_blog.jpg

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  […]

Lire la suite

dimanche, novembre 25 2018

Sql*Loader et les dates

sqlloader.png

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  […]

Lire la suite

jeudi, novembre 8 2018

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

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  […]

Lire la suite

jeudi, juin 14 2018

Traces Oracle et ADRCI

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  […]

Lire la suite

samedi, juin 9 2018

Cluster RAC et Dataguard avec Oracle 12c

cluster test dataguard.jpg

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  […]

Lire la suite

mercredi, mars 7 2018

Monitoring RMAN

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  […]

Lire la suite

dimanche, janvier 14 2018

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

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  […]

Lire la suite

jeudi, novembre 16 2017

Informations sur les sauvegardes RMAN

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  […]

Lire la suite

vendredi, novembre 3 2017

Fonctionnalité In-Database Archiving Oracle 12c

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  […]

Lire la suite

dimanche, juillet 30 2017

Channel bonding et VirtualBox

Capture_du_2017-07-30_17-19-08.png

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  […]

Lire la suite

lundi, juillet 10 2017

Installer Oracle 12c sur CentOS/RedHat 7

download_12c.png

Introduction L'installation du SGBD Oracle sur un serveur Linux peut sembler simple. Il y a toutefois des précautions à prendre afin d'obtenir une plate-forme stable. Ce billet présente l'installation de la version 12.2.0.1 de Oracle sur CentOS 7 en utilisant le mode silencieux, c'est à dire sans  […]

Lire la suite

jeudi, juin 29 2017

Installation automatique de serveurs Linux

boot_PXE.jpg

Introduction Avec la prolifération des machines virtuelles, déployer rapidement des serveurs devient monnaie courante. Il est donc souhaitable de disposer d'une solution permettant au maximum d'automatiser le processus. Bien entendu il est possible d'utiliser cette solution avec de vrais serveurs.  […]

Lire la suite

- page 1 de 11