Silverlake - Le blog de ADIMCOR

Une base de données, LUKE pour ne pas la nommer, ne comporte qu'un seul fichier de contrôle. Les fichiers de la base sont gérés en ASM et OMF. Ce billet montre comment en créer une seconde copie.

Se connecter à la base afin de connaitre le nom du fichier de contrôle actuel.

export ORACLE_SID=LUKE
sqlplus "/ as sysdba"
SQL> show parameter control_files;

La requête renverra un nom du style : +DATA/luke/controlfile/current.260.811769741

Toujours sous SQL*plus arrêter la base, la démarrer en mode nomount, tenter l'insertion d'un second fichier de contrôle avec le même nom que le premier puis stopper la base

SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter system set control_files='+DATA/luke/controlfile/current.260.811769741','+DATA' scope=spfile;
SQL> shutdown immediate;
SQL> exit;

Demander ensuite une restauration des fichiers de contrôle par RMAN

rman target /
RMAN> startup nomount;
RMAN> restore controlfile from '+DATA/luke/controlfile/current.260.811769741';
Démarrage de restore dans 03/04/13
utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=24 type d'unité=DISK

canal ORA_DISK_1 : copie du fichier de contrôle copiée
nom de fichier de sortie=+DATA/luke/controlfile/current.260.811769741
nom de fichier de sortie=+DATA/luke/controlfile/current.268.811779383
Fin de restore dans 03/04/13

RMAN> exit

Se reconnecter SQL*Plus ouvrir la base de données et vérifier la présence des deux fichiers de contrôle.

sqlplus "/ as sysdba"
SQL> show parameter control_files

NAME				     TYPE	 VALUE
------------------------------------         ----------- ------------------------------
control_files			     string	 +DATA/luke/controlfile/current.260.811769741, +DATA/luke/controlfile/current.268.811779383
SQL> alter database mount;

Base de données modifiée.

SQL> alter database open;

Base de données modifiée.

SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
+DATA/luke/controlfile/current.260.811769741
+DATA/luke/controlfile/current.268.811779383

SQL> 

Toujours dans la logique de démystifier RMAN, je vous propose ici un cas simple et banal.

Votre base et serveur Oracle est détruit. Il ne vous reste que la sauvegarde RMAN. Bien entendu ce scénario implique une perte de données, celles n'étant pas sur la sauvegarde ! Si c'est inacceptable, il faut mettre autre chose en place.

On utilise ici une version 11g mais est adaptable en 10g sans problème. Les hypothèses de départ sont les suivantes :

• La base de données se nomme RED
• Les fichiers sous sous /u01, /u02 et /u03
• La norme OFA est respectée
• On utilise une Flash Recovery Area.

Dans un premier temps ré-installer le serveur Oracle ( OS + Binaires sans créer de base de données ) voir l'article sur le wiki pour plus de détails.

Créer la structure des répertoires :

mkdir -p /u01/app/oracle/admin/RED/pfile
mkdir -p /u01/app/oracle/oradata/RED
mkdir -p /u02/app/oracle/oradata/RED
mkdir -p /u03/app/oracle/oradata/RED
mkdir -p /u01/app/oracle/flash_recovery_area/RED

Recopier toute la sauvegarde RMAN sous /u01/app/oracle/flash_recovery_area/RED

Créer un initRED.ora provisoire sous /u01/app/oracle/admin/RED/pfile

Contenu de initRED.ora

db_name=RED
db_block_size=8192
db_recovery_file_dest_size=2G
db_recovery_file_dest=/u01/app/oracle/flash_recovery_area

Au niveau du shell

export ORACLE_SID=RED
sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount pfile='/u01/app/oracle/admin/RED/pfile/initRED.ora';
SQL> exit

Se connecter à RMAN

rman target /
RMAN> restore spfile from autobackup;
RMAN> shutdown immediate;
RMAN> startup nomount;
RMAN> restore controlfile from autobackup;
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open resetlogs;
RMAN> exit;

Se connecter normalement à RED.

Le CERTA a diffusé en juin 2012 une note sur l'obsoléscence de certains logiciels, en particulier les OS Linux et Oracle Voir le lien suivant

Oracle annonce la fin de maintenance pour les versions de bases de données inférieures à 11.1.

La version 10G largement diffusée, ne sera plus maintenue à partir de juillet 2013. Le lien suivant permet de connaitre la position de Oracle sur ses produits

Bien que n'étant pas vraiment programmeur, il m'arrive de donner des formations sur PL/SQL. Afin de faire souffrir mes stagiaires, je leur demande d'écrire une fonction calculant le jour de Pâques.

Pâques est une fête mobile qui permet de calculer d'autres jours fériés

• Lundi de Pâques, le lendemain.
• L'ascension, 40 jours après Pâques,
• La Pentecôte, 50 jours après Paques
• Le lundi de Pentecôte, lendemain du précédent.

La fonction suivante est exacte pour les années 1955 à 2048.

Pour rédiger ce billet, j'ai pris un des algorythmes sur la page suivante Calcul de Pâques - Wikipédia

create or replace function calc_paques( annee in number ) return date is
a number;b number;c number;d number;e number;de number;
paques date;
begin
a := mod( annee,19 );b := mod( annee,4 );c := mod( annee,7 );
d := mod(( (19 * a) + 24 ),30 );
e := mod(( (2 * b) + (4 * c) + (6 * d) + 5 ), 7);
de := d + e;
if de > 9 then
select to_date( to_char( de - 9 ) ||'/04/' || to_char( annee ), 'DD/MM/YYYY') into paques from dual;
else
select to_date( to_char( 22 + de ) ||'/03/' || to_char( annee ), 'DD/MM/YYYY') into paques from dual;
end if;
if paques > to_date( '25/04/' || to_char( annee ), 'DD/MM/YYYY') then
paques := paques - 7;
end if;
return paques;
end;
/

Son utilisation sous SQL*Plus reste basique

select calc_paques( to_number(to_char(sysdate,'YYYY'))) from dual;

Fonction à intégrer dans un package de gestion des dates bien pratique aux DRH et autres logiciels de logistique...

Lors de la création d'une base Oracle, certaines permissions violent des règles de sécurité. Dans le Database Control ceci se manifeste par un certain nombre ( 8 par défaut ) d'alerte en page d'accueil.

Eliminer ces alertes est assez simple, 6 d'entre elles concernent l'affectation de droit d'execution à PUBLIC. Se connecter sous sqlplus et exécuter les ordres suivants :

revoke execute on utl_tcp from public;
revoke execute on utl_http from public;
revoke execute on utl_smtp from public;
revoke execute on utl_file from public;
revoke execute on dbms_lob from public;
revoke execute on dbms_job from public;

Le dernier ordre ( dbms_job ) prend un peu de temps.

Il reste deux règles, la première concerne les droits sur le répertoire audit et à déjà fait l'objet d'un billet ( voir ici ). Il suffit de passer la commande suivante en tant que user oracle.

chmod o-rx $ORACLE_HOME/rdbms/audit

La dernière concerne la mise en place d'une fonction de vérification des mots de passe pour le profil DEFAULT. Oracle fournit un script pour celà qu'il est possible de personnaliser.

start $ORACLE_HOME/rdbms/admin/utlpwdmg.sql

Ce script passe les ordres suivants :

ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION verify_function_11G;

La fonction de vérification contient les règles suivantes :

• Le mot de passe est différent du user
• La longueur est au moins de 8 caractères
• Le mot de passe est testé sur un mini dictionnaire afin d'eviter certains mots.
• Le mot de passe contient au moins une lettre et un chiffre.
• Le nouveau mot de passe doit être different par 3 lettres du précédent.

Et s'il vous plait, ne pas mettre system/manager. Si vous saviez le nombre de bases, y compris dans des sociétés prestigieuses, où je me suis connecté ainsi...

Il suffit de rédemarrer le database control ou de patienter 24 heures, les alertes auront disparues.

Introduction

J'aime la ligne de commande, les scripts et autre installation silencieuse en particulier avec Oracle. La raison est simple, lors de mes interventions je n'ai le plus souvent à ma disposition qu'un accès ssh au serveur. Dans ces conditions connaitre les outils type TOAD ou même Database Control ne me sert pas à grand chose.

J'anime d'ailleurs un cours pour le compte de ORSYS ( pub gratuite ) sur l'administration de Oracle uniquement en ligne de commande.Vous en trouverez le détail via ce lien

Un des sujets de ce cours est la mise en place d'un script de création automatique d'une base de données. Je l'ai voulu simple avant tout, il y manque tous les tests de bonne exécution par exemple. La version complète est disponible ici

Le script contient deux variables

• INST : le nom de l'instance
• PASSWORD : le mot de passe pour les user sys et system

Dans l'exemple nous allons créer une base nommée YODA avec comme mot de passe sys et system : manager11

La version présentée est Oracle 11gR2, mais ce script fonctionne très bien aussi en 9i ou 10g.

Répertoires

La norme OFA sera respectée, les fichiers seront donc sous une structure type :

• /u01/app/oracle/product/11.2.0/dbhome_1 -> $ORACLE_HOME
• /u01/app/oracle/oradata/YODA
• /u02/app/oracle/oradata/YODA
• /u03/app/oracle/oradata/YODA

Variables

Il suffit de les adapter à la création voulue. Il est aussi très simple de les passer en ligne de commande...

#!/bin/bash
# Script de création de base Oracle
INST=YODA # Nom de l'instance
PASSWORD=manager11 # Mot de passe sys et system

Répertoires de la base

mkdir -p /u01/app/oracle/admin/${INST}/pfile
mkdir -p /u01/app/oracle/oradata/${INST}
mkdir -p /u02/app/oracle/oradata/${INST}
mkdir -p /u03/app/oracle/oradata/${INST}

Le fichier init.ora

La base sera créée avec 3 fichiers de contrôle sur des axes différents et une taille mémoire affecté à l'instance de 1,5Go.

# init.ora
cat <<EOF > /u01/app/oracle/admin/${INST}/pfile/init${INST}.ora
db_name = ${INST}
db_block_size = 8192
control_files = /u01/app/oracle/oradata/${INST}/control01.ctl, /u02/app/oracle/oradata/${INST}/control02.ctl, /u03/app/oracle/oradata/${INST}/control03.ctl
sga_target = 1280M
pga_aggregate_target = 320M
EOF

Création du lien symbolique vers $ORACLE_HOME/dbs et du fichier de mot de passe pour la connexion as sysdba.

# Fichier mot de passe et lien symbolique vers init.ora
cd $ORACLE_HOME/dbs
ln -sfn $ORACLE_BASE/admin/${INST}/pfile/init${INST}.ora init${INST}.ora
orapwd file=orapw${INST} password=${PASSWORD}

Création

Dans un premier temps nous allons générer un script SQL pour l'ordre create database.

# Fichier .sql de création
cat <<EOF > $HOME/create${INST}.sql
create database ${INST}
character set UTF8
national character set UTF8
logfile
group 1 ('/u01/app/oracle/oradata/${INST}/redo01a.log','/u02/app/oracle/oradata/${INST}/redo01b.log') size 50M,
group 2 ('/u01/app/oracle/oradata/${INST}/redo02a.log','/u02/app/oracle/oradata/${INST}/redo02b.log') size 50M,
group 3 ('/u01/app/oracle/oradata/${INST}/redo03a.log','/u02/app/oracle/oradata/${INST}/redo03b.log') size 50M
datafile '/u01/app/oracle/oradata/${INST}/system01.dbf' size 500M autoextend on next 100M maxsize 2G extent management local
sysaux datafile '/u01/app/oracle/oradata/${INST}/sysaux01.dbf' size 500M autoextend on next 100M maxsize 2G
undo tablespace UNDO_TBS datafile '/u01/app/oracle/oradata/${INST}/undo_tbs01.dbf' size 25M
default temporary tablespace TEMP tempfile '/u01/app/oracle/oradata/${INST}/temp01.dbf' size 50M;
EOF

La base est créée avec 3 groupes de redo-logs multipléxés en 2 membres. Un tablespace UNDO et un temporaire, du classique.

Le spfile est créé de suite.

# Lancement en mode nomount de l'instance pour création
# Création directe du spfile
export ORACLE_SID=${INST}
resultat=`sqlplus -s "/ as sysdba" <<EOF
startup nomount;
create spfile from pfile;
shutdown immediate;
startup nomount;
start $HOME/create${INST}.sql;
start $ORACLE_HOME/rdbms/admin/catalog.sql;
start $ORACLE_HOME/rdbms/admin/catproc.sql;
alter user sys identified by ${PASSWORD};
alter user system identified by ${PASSWORD};
exit;
EOF`

les scripts catalog et catproc servent à la création du dictionnaire des données.

Script pupbld.sql

Execution du script pupbld.sql. Afin d'éviter le warning suivant :

Error accessing PRODUCT_USER_PROFILE
Warning:  Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM

Le script créé la table PRODUCT_USER_PROFILE dans le schema SYSTEM. Le message n'est qu'un warning en fait, la connexion est acceptée en l'absence de cette table.

resultat=`sqlplus -s system/${PASSWORD} <<EOF
start $ORACLE_HOME/sqlplus/admin/pupbld.sql
EOF`

Conclusion

Il est très facile de rajouter d'autres ordres SQL à la suite de ce script. L'objectif ici était de présenter une méthode simple de création. La version complète du script est disponible ici. Selon la puissance de la machine il faut compter 10 à 15 minutes pour la création.

Bonus

Ci dessous quelques commandes utiles à rajouter

# Tablespace par défaut
resultat=`sqlplus -s system/${PASSWORD} <<EOF
create tablespace users datafile '/u02/app/oracle/oradata/RED/users_01.dbf' size 100K;
alter database default tablespace users;
exit;
EOF`

# Flash Recovery Area
mkdir -p /u03/app/oracle/flash_recovery_area
resultat=`sqlplus -s "/ as sysdba" <<EOF
alter system set db_recovery_file_dest_size=5G scope=both;
alter system set db_recovery_file_dest='/u03/app/oracle/flash_recovery_area' scope=both;
exit;
EOF`

# Activation du mode archivelog
resultat=`sqlplus -s "/ as sysdba" <<EOF
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
exit;
EOF`

Ce billet concerne la version 10g de Oracle.

Lors de la création manuelle d'une base Oracle, sans l'assistant dbca, le database control n'est pas configuré, il est bien évidement possible de le faire à postériori. La commande permettant ceci est emca qui peut s'appeler en mode intéractif, mais aussi avec un fichier de réponse.

Dans l'exemple suivant, nous allons utiliser une base de données nommée YODA, sur un serveur appelé adi100.concarnux.fr. Le mot de passe des utilisateurs sys, dbsnmp et sysman étant manager10.

La syntaxe du fichier est très claire pour l'adapter à la configuration souhaitée.

Remplir les clauses EMAIL_ADDRESS et MAIL_SERVER_NAME est facultatif, mais une demande sera faite intéractivement;

Créer un fichier, par exemple em.rsp avec les lignes suivantes :

HOST=adi100.concarnux.fr
SID=YODA
PORT=1521
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
EMAIL_ADDRESS=votre_mail
MAIL_SERVER_NAME=votre_serveur_smtp
DBSNMP_PWD=manager10
SYSMAN_PWD=manager10
SYS_PWD=manager10

Dans le cas d'utilisation de ASM il faut compléter ce fichier avec les lignes suivantes :

ASM_OH=/u01/app/oracle/product/10.2.0/db_1
ASM_SID=+ASM
ASM_PORT=1521
ASM_USER_ROLE=sysdba
ASM_USER_NAME=sys
ASM_USER_PWD=manager10

Lancer ensuite la commande de création

emca -config dbcontrol db -repos create -respFile em.rsp

Pour récréer un database control

emca -config dbcontrol db -repos recreate -respFile em.rsp

Le dataguard, on disait standby database avant, permet de disposer d'une base de secours sur laquelle il est possible de basculer en cas d'arrêt de la base de production.

La gestion du dataguard comporte de très nombreuses fonctionnalités, j'ai voulu décrire la mise en place d'une configuration simple avec deux serveurs. Si l'un s'arrête, on bascule sur l'autre.

Le temps d'indisponibilité est faible. Attention un dataguard n'est pas une configuration RAC, il protège de la perte de données mais n'est pas une solution de haute disponibilité.

L'article est assez conséquent et se trouve sur le wiki de Silverlake via ce lien

Pour simuler l'environnement, je suis parti sur un serveur avec CentOS 5.7 et deux VM sous XEN

L'image ci-dessous ( honteusement pompée sur le site Oracle ) montre le principe du dataguard.

J'ai apporté un soin particulier ( comme toujours ? ) à rendre ce billet le plus clair possible, tout retour est le bienvenu.

Deux fonctionnalités basiques mais au combien indispensables sous SQL*Plus

• Définir l'éditeur de texte, appelé par la commande ed
• Changer le prompt SQL > en mettant le nom de l'utilisateur connecté et la chaine Oracle*Net

Pour rendre définitif ces fonctionnalités, il faut éditer le fichier $ORACLE_HOME/sqlplus/admin/glogin.sql et y ajouter les deux lignes suivantes :

define _editor=vi
set sqlprompt "&_user:&_connect_identifier > "