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