(oui je sais c’est un peu long)
L’hypothese est toujours qu’on ait une suavegarde RMAN en place qui tienne la route ( voir mon article : Sauvegarde Oracle 11g avec RMAN en 5 clics , pour + d’infos)
Avec la console OEM :
Cliquer sur l’onglet ‘Availability’, puis le lien ‘perform recovery’, choisir ‘recovery scope = datafile’ , clic ‘recover’, clic ‘Next’, clic ‘Next’ et ‘Submit’.
C’est fini ;-(

En 2 commandes

On va voir ici comment récupérer un fichier perdu…sans savoir lequel ni connaitre RMAN !
En fait 2 commandes suffisent : ADVISE FAILURE et REPAIR FAILURE. C’est tout bonnement miraculeux ca s’appelle Data Recovery Advisor !

Supposons qu’on ait donc perdu un datafile.
Au bout d’un moment (si, si) Oracle va finir par s’en apercevoir et on aura une erreur ORA-1157.
Oracle ERROR at line 1:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/tmp/dd.dbf’ DATAFILE

Les étapes de restauration sont très simples grace à DATA RECOVERY ADVISOR disponible avec Oracle 11g.
Concrètement ce Data recovery advisor consiste en qq commandes que l’on pourra lancer sous RMAN.

3 commandes utiles :

RMAN> LIST FAILURE : liste les pbs en cours détectés (fichiers manquents, corrompus, etc…)

RMAN> ADVISE FAILURE : propose des solution de recovery et produit un script associé

RMAN> REPAIR FAILURE : execute le script de récupération

Voici un exemple concret :

Connexion a RMAN

$> rman target sys@portab2-a-dd:1521/DD1.dd.com
connected to target database: DD1 (DBID=1767735647, not open)
RMAN>

Recherche de problemes éventuels :

RMAN> list failure;
using target database control file instead of recovery catalog
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1242 HIGH OPEN 23-JUL-10 One or more non-system datafiles are missing

Ou si l’on souhaite avoir des infos plus détaillées sur le problème on utilise l’ID qui nous intéresse , ici 1242

RMAN> list failure 1242 detail;

List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1242 HIGH OPEN 23-JUL-10 One or more non-system datafiles are missing
Impact: See impact for individual child failures
List of child failures for parent failure ID 1242
Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
1245 HIGH OPEN 23-JUL-10 Datafile 6: ‘/tmp/dd.dbf’ is missing
Impact: Some objects in tablespace DD might be unavailable

En suite la partie Assistance / conseil proprement dite (ADvisor) :

RMAN> advise failure;

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=155 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /tmp/dd.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
—— ——————
1 Restore and recover datafile 6
Strategy: The repair includes complete media recovery with no data loss
Repair script: /oracle/diag/rdbms/dd1/DD1/hm/reco_1841908370.hm

On peut dès lors récupérer le fichier de données effacé en une étape :

RMAN> REPAIR FAILURE

Ou si l’on veut mieux maitriser ce que l’on fait, visualiser le script et lancer les étapes de restauration et recovery manuellement :

Vérification du script généré :

$> more /oracle/diag/rdbms/dd1/DD1/hm/reco_1841908370.hm
# restore and recover datafile
restore datafile 6;
recover datafile 6;

Restauration (récupération) du fichier perdu à partir des Backups Sets de la sauvegarde RMAN :

RMAN> restore datafile 6;

Starting restore at 23-JUL-10
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00006 to /tmp/dd.dbf
channel ORA_DISK_1: reading from backup piece /oracle/flash_recovery_area/DD1/DD1/backupset/2010_07_22/o1_mf_nnnd1_BACUP_INCR_DEL_BAC_0_64jlhkvc_.bkp
channel ORA_DISK_1: piece handle=/oracle/flash_recovery_area/DD1/DD1/backupset/2010_07_22/o1_mf_nnnd1_BACUP_INCR_DEL_BAC_0_64jlhkvc_.bkp tag=BACUP_INCR_DEL_BAC_072210033828
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 23-JUL-10

Récupération de données supplémentaires et synchronisation des fichiers si nécessaire :

RMAN> recover datafile 6;

Starting recover at 23-JUL-10

using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 23-JUL-10

SQL> SHOW PARAMETER DB_RECOVERY

Oracle (et le listener s’il n’est pas protégé par un mot de passe) peuvent être démarrés automatiquement comme un service.  L’implantation des fichiers et les ‘run level’ utilisés au boot dépendent des distributions.
Voici un exemple qui fonctionne sous Ubuntu :

1. se positionner dans le répertoire d’initialisation qui va bien, ici /etc/init.d
2. créer un fichier  /etc/oraclectl comme suit avec les bonnes valeur de ORACLE_HOME
   et de compte propriétaire oracle

   # les 2 commentaires ‘chkconfig’ et ‘description’ suivants sont OBLIGATOIRES
   # on fournit liste_run_level priorite_start priorite_stop, ici 2,3,5 et 80 , 20
   # chkconfig: 235 80 20
   # description: ajout de service auto pour start/stop oracle#!/bin/bash
   ORACLE_OWNER=”oracle”
   ORACLE_HOME=”/oracle/db11a”
   case “$1″ in
   start)
   echo -n $”Starting Oracle DB:”
   su - $ORACLE_OWNER -c “$ORACLE_HOME/bin/dbstart $ORACLE_HOME”
   echo “OK”
   ;;
   stop)
   echo -n $”Stopping Oracle DB:”
   su - $ORACLE_OWNER -c “$ORACLE_HOME/bin/dbshut $ORACLE_HOME”
   echo “OK”
   ;;
   *)
   echo $”Usage: $0 {start|stop}”
   esac

3. changer le groupe (dba en général) et les permissions du fichier

   $> sudo chgrp dba oraclectl
   $> sudo chmod 750 oraclectl

4. tester le script a la main

$>  ./oraclectl  start

1. ajouter le service oraclectl
   Le moyen le plus simple pour ce faire plutôt que de bidouiller les rc0.d , rc1.d, rc2.d …et autres liens symboliques est d’utiliser la commande chkconfig qui va bien (cf parametres mlis en commentaires en début du script précédent

$> sudo chkconfig –add oraclectl
# ou sans utiliser les commentaires du script (on precise explicitement les levels :
$> chkconfig –level 235 oraclectl on
$> #verifier :$> chkconfig -l oraclectl
oraclectl 0:off 1:off 2:on 3:on 4:off 5:on 6:off
$> # verifier si necessaire le runlevel courant
$> runlevel
N 2

Apres un reboot de la machine  le service oracle devrait démarrer automatiquement…

Il permet d’éviter que des utilisateurs malveillants accèdent aux données OFFLINe, c’est à dire aux données stockées physiquement dans les fichiers en court-circuitant SQL.

Une simple commande Unix
$> strings mon_fichier.dbf
suffit à voir les données ASCII en clair. ce qui pour les CHAR et VARCHAR est très pratique.

Nous allons  détailler ici les étapes necessaires à la mise en place du chiffrement de données sur les colonnes d’une table. Bonne lecture.

1) création d’un Wallet.

Lancer OWM : Wallet /new donner un pwd, ne pas creer de certificat de securite additionnel
ignorer les warning
sauvegarder le wallet dans une directory accessible

On peut vérifier au niveau de l’OS la création d’un fichier wallet :
$> ls -l /data/pprqu/wallet
-rw——-  1 oracle dba 7917 2010-07-02 11:07 ewallet.p12

2) configurer la  base pour utiliser le wallet
rajouter dans sqlnet.ora ($ORACLE_HOME/network/admin/sqlnet.ora)
l’emplacement du Wallet.

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /data/pprqu/wallet)
)
)

tester la validité des paramaetres avec un eventuel
$> lsnrctl reload

3) ouvrir le Wallet

SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY  “mmxlv3ipu”;
– Attention aux guillemets !!!!!!!!!!!
– sensible à la casse en plus !!! (11g style !)

rem : on peut eviter cette ouverture manuelle à chaque redémarrage de la base, avec un AUTOLOGIN WALLET

4) créer le mot de passe de la clé de chiffrement principale

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “mmxlv3ipu”

!!!!!!!!!!!! doit etre le meme mot de passe sinon :
ORA-28353: failed to open wallet

L’Algorithme de chiffrement par défaut est AES192. On peut en choisir d’autres plus ou moins complexes …voir la doc.

rem : cette commande est valide tant que la base n’est pas redémarrée…

5) chiffrer la colonne confidentielle

SQL> alter table emp_cryptee modify( ename encrypt)
Table altered.

Pour intégrer le passage à l’euro.

Le charset W8ISOMSWIN1252  est un subset de WE8ISO8859P1, il n’y a donc aucun risque mais que des avantages à passer en WE8ISOMSWIN1252 plutôt qu’en WE8ISO8859P15 qui possède mui aussi le caractère ‘€’ (y compris sur linux cf Note Metalink 264294.1).

Sur le nœud 1

Sur le nœud 2

Sur le nœud 1

Dans /app/oracle/product/10.2.0/db_1/dbs on commente les  deux lignes  suivantes cluster_database_instances et cluster_database dans initSID1.ora.

On dé commente les paramètres dans initSID1.ora.

Avant d’arrêter le noeud 1 penser à recréer le spfile dans ASM.

On re démarre les deux instances

Nœud 1

Nœud 2

1. Arrêter le  clusterware sur chaque noeud : crsctl stop cluster -all
2. Sur le noeud ou est présent le backup de l’OCR démarrer manuellementles ressources css and asm.

crsctl start res ora.cssd -init
crsctl start res ora.asm -init

3.Restorer l’ocr:

ocrconfig -showbackup
ocrconfig -restore <ocrbackup file>

4.Démarrer manuellement les ressources manquantes du cluster evmd and crsd.
crsctl start res ora.evmd -init
crsctl start res ora.crsd -init

5. Démarrer le clusterware sur les autres noeuds : crsctl start cluster -all

Un peu plus compliqué que dans les versions précédentes, mais ASM oblige.

Albanlepunk

$> emctl start dbconsole…failed

L’environnement minimal

…il en faut un !
Le <ORACLE_HOME> doit être correct, le < ORACLE_SID > doit être positionné sur la base cible et le <HOSTNAME>  (nom logique local de la machine) avoir une valeur correcte.
Si tel n’est pas le cas, Oracle ne trouve pas la configuration et on a un message d’erreur du genre

OC4J Configuration issue /oracle/db11g/oc4j/j2ee/OC4J_DBConsole_monpc_TEST not found.

La raison en est qu’il existe des répertoires suffixés avec la valeur de <HOSTNAME> et < ORACLE_SID> notamment :

<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<HOSTNAME>_<ORACLE_SID>
exemple : /oracle/db11g/oc4j/j2ee/OC4J_DBConsole_monpc_TEST
<ORACLE_HOME><HOSTNAME>_<ORACLE_SID>
exemple : /oracle/db11g/monpc_TEST

Accessoirement la base et le listener doivent être démarrés pour que la console soit complètement fonctionnelle.

rem : on peut cependant lancer la console sans rien et s’en servir pour démarrer la base et le listener…mais je ne vous le conseille pas

Solution brute

1) recréer le référentiel de la console dans la base ( ou repository) qui correspond au schema SYSMAN :

$> emca -repos recreate

2) reconfigurer la console :

$> emca -config dbcontrol db

exemple :

$> emctl start dbconsole

$> ulimit: 25: bad number

Le pb vient de ce que cette commande s’execute en Shell ( sh ) et non pas bash.

Solution : modifier $ORACLE_HOME/bin/emctl et remplacer le

#!/bin/sh -f

par

#!/bin/bash -f

Its not possible to change CONTROL FILES location with Oracle ENterprise Manager Console ( OEM ) . But you can do it with some SQL commands and…a SPFILE. Here is the script :

$> sqlplus /nolog
SQL> connect sys as sysdba

SQL> show parameter CONTROL_FILES
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      E:\ORADATA\ORCL\CONTROL01.CTL,
E:\ORADATA\ORCL\CONTROL02.CTL
,  E:\ORADATA\ORCL\CONTROL03.CTL

SQL> CREATE PFILE=’c:\temp\pfile.ora’ FROM SPFILE;

edit  c:\temp\pfile.ora and change one of the PATH value for CONTROL_FILES
here :
E:\ORADATA\ORCL\CONTROL03.CTL becomes  C:\TEMP\CONTROL03.CTL

copy the  control file
ici CONTROL03.CTL de E:\ORADATA\ORCL\ vers c:\TEMP

– shutdown and restart with the new parameter
SQL> shutdown abort
SQL> startup

SQL> show parameter control_files
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      E:\ORADATA\ORCL\CONTROL01.CTL,
E:\ORADATA\ORCL\CONTROL02.CTL
, C:\TEMP\CONTROL03.CTL

You’re done !

Il n’est pas possible de changer dynamiquement l’emplacement d’un  CONTROL FILE  pour le multiplexer par exemple, avec  Oracle ENterprise Manager Console ( OEM ) . Quelques commandes SQL et l’appui du SPFILE suffisent… :

$> sqlplus /nolog
SQL> connect sys as sysdba

SQL> show parameter CONTROL_FILES
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      E:\ORADATA\ORCL\CONTROL01.CTL,
E:\ORADATA\ORCL\CONTROL02.CTL
,  E:\ORADATA\ORCL\CONTROL03.CTL

SQL> CREATE PFILE=’c:\temp\pfile.ora’ FROM SPFILE;

editer  c:\temp\pfile.ora and change one of the PATH value for CONTROL_FILES
ici :
E:\ORADATA\ORCL\CONTROL03.CTL becomes  C:\TEMP\CONTROL03.CTL

copier le control file
ici CONTROL03.CTL de E:\ORADATA\ORCL\ vers c:\TEMP

SQL> shutdown abort
SQL> startup

SQL> show parameter control_files
NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      E:\ORADATA\ORCL\CONTROL01.CTL,
E:\ORADATA\ORCL\CONTROL02.CTL
, C:\TEMP\CONTROL03.CTL

C’est fait!