En version 10GR2 RAC et 11GR1 RAC, lorsqu’on était dans une configuration ‘cluster étendu’ avec deux baies de stockage, possibilité était donnée de stocker un des voting disks du cluster sur un partage NFS situé sur un autre serveur n’utilisant pas l’une des baies.

L’objectif de cette configuration était de fournir un quorum permettant à une des parties du cluster de continuer à fonctionner même en cas de perte complète d’une baie (ou d’une salle d’hébergement) ou en cas de perte du réseau privé entre les noeuds.

Si vous êtes encore en version 10GR2 ou 11GR1 vous trouverez des infos sur ce paramétrage ici

En version 11GR2 (11.2.0.2 en l’occurrence) où les voting disks peuvent être stockés dans ASM les choses se compliquent un peu pour mettre en place ce troisième voting disk :

On dispose d’un cluster RAC à deux nœuds utilisant deux baies de stockage, un diskgroup ‘OCRCONFIG1’ composé de quatre disques (deux sur chaque baie) est utilisé pour le stockage des OCR et voting disks.

Un partage nfs /votedisk est monté sur chacun des serveurs du cluster :

nfs-server:/votedisk /votedisk nfs rw,bg,hard,intr,rsize=32768,wsize=32768,tcp,noac,vers=3,timeo=600 0 0

La configuration des voting disks est pour l’instant la suivante :

[root@rac1 bin]# ./crsctl query css votedisk

##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   77d5d112ed054f97bf7049422ae169ff (ORCL:OCRCONFIG1) [OCRCONFIG1]
 2. ONLINE   4a72763dc7c94f5fbf4acbe0d51b4f69 (ORCL:OCRCONFIG2) [OCRCONFIG1]
 3. ONLINE   45936edfe3174f9fbff3e99794dab38a (ORCL:OCRCONFIG3) [OCRCONFIG1]
Located 3 voting disk(s).

On a trois voting disks, chacun sur un disque, deux dans une salle  (OCRCONFIG1 et OCRCONFIG3) et 1 dans l’autre (OCRCONFIG2)

Création du futur voting disk sur le partage nfs :

dd if=/dev/zero of=/votedisk/vote3 bs=1M count=500

Démarrer ensuite l’assistant asmca

Dans l’onglet ‘Groupe de disques’ sélectionner le groupe de disques  OCRCONFIG1 et sélectionner l’option ‘Ajouter des disques

Cliquer ensuite sur le bouton ‘Modifier le chemin de repérage des disques’

Ajouter au(x) chemin(s) existant(s) l’emplacement du voting disk sur le partage NFS

Notre disque candidat apparait ensuite :

Le sélectionner et cocher la case ‘Quorum’ (dernière colonne) pour indiquer qu’il s’agit d’un disque jouant le rôle de quorum.

C’est fait !

Nous voici maintenant avec les disques suivants :

[root@rac1 bin]# ./crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   77d5d112ed054f97bf7049422ae169ff (ORCL:OCRCONFIG1) [OCRCONFIG1]
 2. ONLINE   4a72763dc7c94f5fbf4acbe0d51b4f69 (ORCL:OCRCONFIG2) [OCRCONFIG1]
 3. ONLINE   1912723de8bf4f9abf7c79052b008606 (/votedisk/vote3) [OCRCONFIG1]

Le disque OCRCONFIG1 est en salle 1, le disque OCRCONFIG2 en salle 2, le troisième /votedisk/vote3 joue donc le rôle de quorum.

Remarque : évidemment, le serveur hébergeant ce disque n’est situé ni dans l’une ni dans l’autre des salles, et utilise également un stockage indépendant, sinon ça ne sert pas à grand-chose …

Attention : il y a quelques effets de bord à cette configuration, en particulier lorsque le device NFS n’est pas accessible, cf la partie ‘Known issue’ du white paper Oracle. ]]> http://blogorak.estsurinternet.com/oracle-asm/oracle-11gr2-rac-3%c2%b0-voting-disk-et-nfs/feed/ http://blogorak.estsurinternet.com/oracle-asm/restauration-dun-ocr-dans-asm-11gr2/ http://blogorak.estsurinternet.com/oracle-asm/restauration-dun-ocr-dans-asm-11gr2/#comments Mon, 23 May 2011 10:10:51 +0000 alban http://blogorak.estsurinternet.com/?p=459

Contrairement au versions précédentes, pour la 11GR2, on a la possibilité de stocker l’OCR et les Voting Disks dans un diskgroup ASM.

Après avoir installé un cluster utilisant cette nouvelle fonctionnalité, et faisant quelques tests de recette qui comprennent notamment la restauration de l’OCR, je me suis demandé comment pouvait on restaurer l’OCR quand le cluster est arrêté et donc ASM où il est stocké ?

Attention, ce qui suit est valable uniquement pour la version 11.2.0.1, en 11.2.0.2 les choses sont un petit peu différentes

1. Arrêter le  clusterware sur chaque noeud :

crsctl stop cluster -all

2. On vérifie que les deux clusterware sont bien arrêtés sur chaque noeud

3. Sur le noeud sur lequel est présent le backup de l’OCR démarrer manuellement les ressources css et asm

[root@rac1 bin]# ./crsctl start res ora.cssd -init
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'rac1'
CRS-2676: Start of 'ora.cssdmonitor' on 'rac1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'rac1'
CRS-2672: Attempting to start 'ora.diskmon' on 'rac1'
CRS-2676: Start of 'ora.diskmon' on 'rac1' succeeded
CRS-2676: Start of 'ora.cssd' on 'rac1' succeeded

[root@rac1 bin]# ./crsctl start res ora.asm -init
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'rac1'
CRS-2672: Attempting to start 'ora.ctssd' on 'rac1'
CRS-2676: Start of 'ora.ctssd' on 'rac1' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'rac1' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'rac1'
CRS-2676: Start of 'ora.asm' on 'rac1' succeeded

4. Restaurer l’OCR depuis le backup qui nous intéresse

[root@rac1 bin]# ./ocrconfig -showbackup

rac1     2010/12/22 12:53:13     /app/product/11.2.0/grid/cdata/rac-cluster/backup00.ocr

rac1     2010/12/22 08:53:11     /app/product/11.2.0/grid/cdata/rac-cluster/backup01.ocr

rac1     2010/12/22 04:53:11     /app/product/11.2.0/grid/cdata/rac-cluster/backup02.ocr

rac1     2010/12/21 20:53:10     /app/product/11.2.0/grid/cdata/rac-cluster/day.ocr

rac1     2010/12/21 20:53:10     /app/product/11.2.0/grid/cdata/rac-cluster/week.ocr

rac1     2011/03/03 14:54:21     /app/product/11.2.0/grid/cdata/rac-cluster/backup_20110303_145421.ocr

[root@rac1 bin]# ./ocrconfig -restore /app/product/11.2.0/grid/cdata/rac-cluster/backup_20110303_145421.ocr

5. Démarrer manuellement les ressources manquantes du cluster evmd et crsd.

 [root@rac1 bin]# ./crsctl start res ora.evmd –init
CRS-2672: Attempting to start 'ora.evmd' on 'rac1'
CRS-2676: Start of 'ora.evmd' on 'rac1' succeeded
[root@rac1 bin]# ./crsctl start res ora.crsd –init
CRS-2672: Attempting to start 'ora.crsd' on 'rac1'
CRS-2676: Start of 'ora.crsd' on 'rac1' succeeded

6. Démarrer le clusterware sur les autres noeuds : crsctl start cluster –all

[root@rac1 bin]# ./crsctl start cluster –all
CRS-2672: Tentative de drmarrage de 'ora.cssdmonitor' sur 'rac2'
CRS-2676: 'ora.cssdmonitor' a été démarré sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.cssd' sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.diskmon' sur 'rac2'
CRS-2676: 'ora.diskmon' a été démarré sur 'rac2'
CRS-2676: 'ora.cssd' a été démarré sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.ctssd' sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.cluster_interconnect.haip' sur 'rac2'
CRS-2676: 'ora.ctssd' a été démarré sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.evmd' sur 'rac2'
CRS-2676: 'ora.evmd' a été démarré sur 'rac2'
CRS-2676: 'ora.cluster_interconnect.haip' a été démarré sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.asm' sur 'rac2'
CRS-2676: 'ora.asm' a été démarré sur 'rac2'
CRS-2672: Tentative de démarrage de 'ora.crsd' sur 'rac2'
CRS-2676: 'ora.crsd' a été démarré sur 'rac2'
CRS-4690: Oracle Clusterware is already running on 'rac1'
CRS-4000: Command Start failed, or completed with errors

7. Vérification

 [root@rac1 bin]# ./crs_stat –t
Name           Type           Target    State     Host
ora.DGDATA.dg  ora....up.type ONLINE    ONLINE    rac1
ora.DGFRA.dg   ora....up.type ONLINE    ONLINE    rac1
ora....ER.lsnr ora....er.type ONLINE    ONLINE    rac1
ora....N1.lsnr ora....er.type ONLINE    ONLINE    rac1
ora....TING.dg ora....up.type ONLINE    ONLINE    rac1
ora.asm        ora.asm.type   ONLINE    ONLINE    rac1
ora.cvu        ora.cvu.type   ONLINE    ONLINE    rac1
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE
ora....network ora....rk.type ONLINE    ONLINE    rac1
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    rac1
ora.ons        ora.ons.type   ONLINE    ONLINE    rac1
ora....SM1.asm application    ONLINE    ONLINE    rac1
ora....C1.lsnr application    ONLINE    ONLINE    rac1
ora.rac1.gsd   application    OFFLINE   OFFLINE
ora.rac1.ons   application    ONLINE    ONLINE    rac1
ora.rac1.vip   ora....t1.type ONLINE    ONLINE    rac1
ora....SM2.asm application    ONLINE    ONLINE    rac2
ora....C2.lsnr application    ONLINE    ONLINE    rac2
ora.rac2.gsd   application    OFFLINE   OFFLINE
ora.rac2.ons   application    ONLINE    ONLINE    rac2
ora.rac2.vip   ora....t1.type ONLINE    ONLINE    rac2
ora....ry.acfs ora....fs.type ONLINE    ONLINE    rac1
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    rac1
ora.setra.db   ora....se.type ONLINE    ONLINE    rac1

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

Migration crs 10G vers 11GR2

Les clusters RAC installés ces dernières années en 10g vont devoir être migrés un jour ou l’autre fatalement.

Les éditeurs mettant souvent du temps à valider leurs soft avec la version 11GR2,
on peut prendre de l’avance en ne migrant que les couche CRS et ASM en 11GR2 et en laissant les bases en 10G.

Si vous êtes sur OEL4, vérifier ou upgrader votre OS au minimum en 4.7

Appliquer les pré-requis pour la version 11GR2 sur votre système (note Metalink 880942.1 pour OEL4 et 880989.1 pour OEL5).

Un petit coup de cluster verify permet d’en avoir le coeur net.

runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose

Une fois les binaires du grid 11GR2 copiés, on va utiliser la fonctionnalité “Mettre à niveau Oracle Grid Infrastructure” de l’installer.
Il n’est pas nécéssaire d’arrêter le crs, bien que ça marche quand même si c’est le cas.
On peut sinon passer le script clusterware/upgrade/preupdate.sh qui arrête le crs.

On peut donc théoriquement faire l’upgrade d’un noeud après l’autre, sans coupure de production.

Si vous utilisez ASM, alors arrêtez vos bases et vos instances ASM, l’installeur vous le demandera de toute façon.

Si les pré-requis ont été respecté et l’adresse scan convenablement renseignée, l’installation se déroule comme une installation 11GR2 standard.

Au lieu de lancer le fameux root.sh, on va lancer le rootupgrade.sh qui va arrêter le crs (s’il est démarré), effectuer les mises à jour nécéssaires et relancer la couche cluster.

[root@rac1 tmp]# /app/11.2.0/grid/rootupgrade.sh
Running Oracle 11g root.sh script...
The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /app/11.2.0/grid
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The file "dbhome" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]: y
   Copying dbhome to /usr/local/bin ...
The file "oraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]: y
   Copying oraenv to /usr/local/bin ...
The file "coraenv" already exists in /usr/local/bin.  Overwrite it? (y/n)
[n]: y
   Copying coraenv to /usr/local/bin ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
2011-03-29 15:23:53: Parsing the host name
2011-03-29 15:23:53: Checking for super user privileges
2011-03-29 15:23:53: User has super user privileges
Using configuration parameter file: /app/11.2.0/grid/crs/install/crsconfig_params
Creating trace directory
Failure 1 contacting CSS daemon
Command return code of 6 (1536) from command: /app/oracle/product/10.2.0/crs/bin/crsctl check cssd
Cannot communicate with EVM
Cannot communicate with CRS
Command return code of 1 (256) from command: /app/oracle/product/10.2.0/crs/bin/crsctl check crsd
LOCAL ADD MODE
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
  root wallet
  root wallet cert
  root cert export
  peer wallet
  profile reader wallet
  pa wallet
  peer wallet keys
  pa wallet keys
  peer cert request
  pa cert request
  peer cert
  pa cert
  peer root cert TP
  profile reader root cert TP
  pa root cert TP
  peer pa cert TP
  pa peer cert TP
  profile reader pa cert TP
  profile reader peer cert TP
  peer user cert
  pa user cert
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting
ADVM/ACFS is not supported on Redhat 4
CRS-2672: Tentative de démarrage de 'ora.mdnsd' sur 'rac1'
CRS-2676: 'ora.mdnsd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.gipcd' sur 'rac1'
CRS-2676: 'ora.gipcd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.gpnpd' sur 'rac1'
CRS-2676: 'ora.gpnpd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.cssdmonitor' sur 'rac1'
CRS-2676: 'ora.cssdmonitor' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.cssd' sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.diskmon' sur 'rac1'
CRS-2676: 'ora.diskmon' a été démarré sur 'rac1'
CRS-2676: 'ora.cssd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.ctssd' sur 'rac1'
CRS-2676: 'ora.ctssd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.crsd' sur 'rac1'
CRS-2676: 'ora.crsd' a été démarré sur 'rac1'
CRS-2672: Tentative de démarrage de 'ora.evmd' sur 'rac1'
CRS-2676: 'ora.evmd' a été démarré sur 'rac1'
clscfg: EXISTING configuration version 3 detected.
clscfg: version 3 is 10G Release 2.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
rac1     2011/03/29 15:27:32     /app/11.2.0/grid/cdata/rac1/backup_20110329_152732.olr
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
Updating inventory properties for clusterware
Démarrage d'Oracle Universal Installer...
Vérification de l'espace de swap : il doit être supérieur à 500 Mo.   Réel 1567 Mo    Succès
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /app/oracle/oraInventory
'UpdateNodeList' a réussi.
Démarrage d'Oracle Universal Installer...
Vérification de l'espace de swap : il doit être supérieur à 500 Mo.   Réel 1567 Mo    Succès
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /app/oracle/oraInventory
'UpdateNodeList' a réussi.

Tout est redémarré sur ce noeud, il ne reste plus qu’à migrer ASM.

Pour cela on lance l’assistant asmca à partir du home grid.

L’assistant va vous proposer de mettre à niveau votre version d’ASM, et va arrêter successivement toutes les instances pour finir par les redémarrer dans la nouvelle version.

On verra apparaitre les ressources correspondantes aux diskgroups au fur et à mesure.

Vous avez maitenant un beau cluster en 11GR2 avec des bases en 10G.

Une bonne partie des actions à réaliser pouvant se faire en amont (pré requis, copie des binaires etc..) et sans arrêt de service, on peut donc s’en tirer avec des arrêts de production relativement courts.

PS : évidemment un retour arrière est à prévoir (et à tester :-))

IMP-00003: ORACLE error 2304 encountered
ORA-02304: invalid object identifier literal
IMP-00017: following statement failed with ORACLE error 2304:
“CREATE TYPE “SYS_PLSQL_1823160_17_2″ TIMESTAMP ‘2011-04-13:08: …

lors d’un import cela est du au fait  que les identifiants de type sont unique dans la base et que le type que vous creez lors de l’import existe deja dans un autre schema.

3 solutions :

- la mauvaise (eclle qu’on vous conseille partout comme si vous aviez le choix de creer des schemas ou d’en supprimer en production comme bon vous semble…) : créer tous les TYPEs dans un schema dédié par ex; : ‘MES_TYPES’  ainsi ils deviennent transverrses et il n’y a plus de probleme de doublons d’IDs.

- SI vous utilisez IMPORT :  mettre l’option TOID_NOVALIDATE de l’import. ATTENTION ! ce n’est pas ‘=Y ‘ la valeur mais ‘NOM_SCHEMA.NOM_TYPE’, ‘NOM_SCHEMA.NOM_TYPE’,
Si vous en avez 2000 …;-((

- Si vs utilisez DATAPUMP impdb : appliquez l’option  “ transform=OID:y “

Infos générales sur le compte

SQL> select * from dba_users
where username='TOTO';

USERNAME 	USER_ID 	PASSWORD 	ACCOUNT_STATUS 	LOCK_DATE 	EXPIRY_DA 	DEFAULT_TABLESPACE 	TEMPORARY_TABLESPACE 	CREATED 	PROFILE 	INITIAL_RSRC_CONSUMER_GROUP 	EXTERNAL_NAME
TOTO 		5394 		EBD64F4E40B74042 	LOCKED 	24-FEB-11 	USERS 		TEMP						21-FEB-11 	DEFAULT 	DEFAULT_CONSUMER_GROUP

On voit notamment :

profil : DEFAUT
lockable apres 20 essai et LE PASSWORD crypté !

Infos plus détaillées (si on se souvient du USERID Oracle (USER# ici) vu précédemment :

SQL> select * from sys.user$
where user#=5394

USER# 	NAME 	TYPE# 	PASSWORD 	DATATS# 	TEMPTS# 	CTIME 	PTIME 	EXPTIME 	LTIME 	RESOURCE$ 	AUDIT$ 	DEFROLE 	DEFGRP# 	DEFGRP_SEQ# 	ASTATUS 	LCOUNT 	DEFSCHCLASS 	EXT_USERNAME 	SPARE1 	SPARE2 	SPARE3 	SPARE4 	SPARE5 	SPARE6
5394 	TOTO 	1 	EBD64F4E40B74042 	4 	250 	21-FEB-11 	03-MAR-11 	  	24-FEB-11 	0 	  	1 	  	  	8 	20 	DEFAULT_CONSUMER_GROUP 	  	0

Avec :

CTIME : date de création
PTIME : date de modification
LTIME: date du lock
EXPTIME : date d’expiration
LCOUNT :
ASTATUS : statut du compte. En gros ouvert, verrouillé ou expiré.

Plus d’infos sur la colonne ASTATUS de USER$ :

SQL> SELECT * FROM SYS.USER_ASTATUS_MAP;

STATUS# STATUS
———- ——————————–
0 OPEN
1 EXPIRED
2 EXPIRED(GRACE)
4 LOCKED(TIMED)
8 LOCKED
5 EXPIRED & LOCKED(TIMED)
6 EXPIRED(GRACE) & LOCKED(TIMED)
9 EXPIRED & LOCKED
10 EXPIRED(GRACE) & LOCKED

details du profile  (qui n’apparaissent pas tous dans la console) :

failed_login_attempts - This is the number of failed login attempts before locking the Oracle user account. The default is three failed attempts.
password_grace_time - This is the grace period after the password_life_time limit is exceeded.
password_life_time - This is how long an existing password is valid. The default here forces a password change every 60 days.
password_lock_time – This specifies how long to lock the account after the failed login attempts is met. Most DBA’s set this value to UNLIMITED.
password_reuse_max – This is the number of times that you may re-user a passwords and is intended to prevent repeating password cycles (north, south, east, west).
password_reuse_time – This parameter specifies a time limit before a previous password can be re-entered. To allow unlimited use of previously used passwords, set password_reuse_time to UNLIMITED.
password_verify_function - This allows you to specify the name of a custom password verification function.

Se connecter sur l’instance du premier nœud et arrêter l’instance :

[oracle@rac1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon Dec 13 14:24:30 2010
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connecte a :
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> archive log list
mode Database log              mode No Archive
Archivage automatique             Desactive
Destination de l’archive             USE_DB_RECOVERY_FILE_DEST
Sequence de journal en ligne la plus ancienne     57
Sequence de journal courante            59
SQL>

On voit bien que la base n’est pas en mode archivelog et que la destination des archives est positionnée par défaut dans la Flash Recovery Area.

Normalement on arrête les instances sur tous les nœuds et on passe la base en archivelog.

Que se passe t il si on oublie d’arrêter la deuxième instance du cluster??

On va donc oublier d’arrêter l’instance sur le noeud 2 avant de modifier la base.

On fait la manip sur le noeud1.

SQL> shutdown immediate
Base de donnees fermee.
Base de donnees demontee.
Instance ORACLE arretee.
SQL> startup mount
Instance ORACLE lancee.
Total System Global Area  477073408 bytes
Fixed Size                  1337324 bytes
Variable Size             209717268 bytes
Database Buffers          260046848 bytes
Redo Buffers                5971968 bytes
Base de donnees montee.
SQL>
SQL> alter database archivelog;
Base de donnees modifiee.

SQL> alter database open;
Base de donnees modifiee.

On génère quelques archives :

SQL> alter system switch logfile;
Systeme modifie.

Le cluster gère le cas et arrête lui même l’instance “oubliée” sans mettre un seul message d’erreur!

On est donc forcée de la redémarrer à la main et elle prend obligatoirement la modification.

SQL> alter system archive log current;
Systeme modifie.

Si on vérifie :

SQL> select name, THREAD#, SEQUENCE#, ARCHIVED from v$archived_log;

+DGFRA/racdb/archivelog/2010_12_13/thread_1_seq_63.265.737650775
1         63 YES

NAME
——————————————————————————–
THREAD#  SEQUENCE# ARC
———- ———- —
+DGFRA/racdb/archivelog/2010_12_13/thread_2_seq_4.266.737650777
2          4 YES

La base archive bien les deux threads correspondants aux deux nœuds.

Albanlepunk

Par exemple un disque lâche sur le serveur et on perd le datafile présent dessus, pour restaurer convenablement ce datafile, il nous faut les archives générées entre le dernier backup et le crash mais il nous manque les archives en question. On ne peut donc plus ouvrir la base et manque de chance, ce datafile contient des tables super importantes.

On sait pertinemment que l’on va perdre des données mais on aimerait en perdre le moins possible quitte à utiliser des moyens “spéciaux” pour cela.

A cause de l’intégrité faussée de la base, on ne peut plus l’ouvrir normallement.

Le paramètre caché qui permet de démarrer la base soit en mode  désynchronisée c’est à dire avec au moins un de ses entêtes de datafiles incorrect soit parce qu’on a  endommagé un ou plusieurs redo logs ou encore parce qu’il nous manque une archive ou deux pour restaurer un datafile est _allow_resetlogs_corruption.

Dans le cas ou votre datafile contiendrait des données type index ou que l’on peut facilement recréer, le mieux serait toujours de dropper le tablespace, puis de le recréer / recharger mais dans le cas ou les données ne sont pas facilement reconstructibles quoi faire?

L’idée à suivre pourrait être la suivante :

Restaurer le datafile ou la base à partir du dernier backup.

Jouer les archives jusqu’au dernier numéro de séquence correct (pour cela regarder dans rman : list backup of archivelog all).

Arrêter et redémarrer l’instance avec le paramètre _allow_resetlogs_corruption = TRUE.

Exporter les données souhaitées.

Restaurer la base à partir du dernier backup.

Mettre le datafile offline.

Dropper et recréer le tablespace.

Réimporter les données “récupérées”. Vous risquez néanmoins d’avoir des décalages applicatifs selon les cas, vous n’êtes donc peut être pas exempt de correction des données.

Re backuper la base correctement.

Dans notre cas, la base refuse de s’ouvrir après une restauration RMAN.

la restauration until logseq s’est bien passée, le recover database aussi. Il n’y a qu’au moment d’ouvrir la base en open resetlogs que la base réclame “une récupération de données après défaillance matérielle”.

Ceci à cause d’un datafile dont la mise offline ne s’était pas déroulé correctement.

J’ai donc remis ce datafile online, redémarré avec le paramètre _allow_resetlogs_corruption à TRUE qui a permis de corriger l’entête du fichier.

Puis on arrête la base et on la redémarre normalement.

BEMOL & RESTRICTION : Oracle ne maintient les bases qui ont été démarrées avec ce paramètre, elles sont potentiellement corrompues. C’est donc en dernier ressort et dans le cas désespérés qu’il faut l’utiliser et tout de suite après exporter les données et les réimporter dans une belle base toute neuve.

Alban le punk

SYSMAN account includes 3 relevant objects related to Alerts :
MGMT_SECURITY , actually a View, based on the TABLE SYSMAN.MGMT_VIOLATIONS
MGMT_CURRENT_SECURITY , actually a View, based on the TABLE SYSMAN.MGMT_CURRENT_VIOLATIONS

Here is its description :

Column Name	ID	Data Type	Null?

TARGET_GUID	1	RAW (16)	N
METRIC_GUID	2	RAW (16)	N
KEY_VALUE	3	VARCHAR2 (256 Byte)	N
COLLECTION_TIMESTAMP	4	DATE	N
SEVERITY_CODE	5	NUMBER	N
SEVERITY_TYPE	6	NUMBER	N
SEVERITY_DURATION	7	NUMBER	Y
SEVERITY_GUID	8	RAW (16)	Y
ANNOTATED_FLAG	9	NUMBER	Y
NOTIFICATION_STATUS	10	NUMBER	Y
MESSAGE	11	VARCHAR2 (4000 Byte)	Y
MESSAGE_NLSID	12	VARCHAR2 (64 Byte)	Y
MESSAGE_PARAMS	13	VARCHAR2 (4000 Byte)	Y
ACTION_MESSAGE	14	VARCHAR2 (4000 Byte)	Y
ACTION_NLSID	15	VARCHAR2 (64 Byte)	Y
ACTION_MESSAGE_PARAMS	16	VARCHAR2 (4000 Byte)	Y
ADVISORY_ID	17	VARCHAR2 (64 Byte)	Y
LOAD_TIMESTAMP	18	DATE	Y
USER_NAME	19	VARCHAR2 (64 Byte)	Yand

DELETE_CURRENT_SEVERITY a procedure that  belongs to SYSMAN.EM_SEVERITY package.
Here is its description :

PROCEDURE delete_current_severity (
p_target_guid IN RAW,
p_metric_guid IN RAW,
p_key_value   IN VARCHAR2);

Note : A trigger deltes Rows from MGMT_CURRENT_SSEVERITY AFTER DELETE from MGMT_SEVERITY !!?

A full description of the parameters  can be obtained via the Dictionnary :

SQL> select column_name, comments
from  dba_col_comments
where table_name=’MGMT_SEVERITY’

COLUMN_NAME	COMMENTS

ADVISORY_ID	Advisory ID of the severity
LOAD_TIMESTAMP	Date and time when the severity was loaded
USER_NAME	Name of the user to load the severity
TARGET_GUID	 The target guid of the severity
METRIC_GUID	 The metric guid of the severity
KEY_VALUE	 The key value of the severity
COLLECTION_TIMESTAMP	 The timestamp at which the severity occurred
SEVERITY_CODE	The severity codes for error, warnin, critical etc.
    These codes are backwards compatible with EM 9i and EM 10gR1.
      15 - CLEAR
      18 - INFO
      20 - WARNING
      25 - CRITICAL
     115 - AGENT UNREACHABLE CLEART
     125 - AGENT UNREACHABLE START
     215 - BLACKOUT END
     225 - BLACKOUT START
     315 - METRIC ERROR END
     325 - METRIC ERROR START
    Codes 115 and above are applicable only for response/status metric
SEVERITY_TYPE	 The severity type allows an application that is selecting
      from this table to filter the rows returned by the type of
      severity.  Values in this column are:
           0 - METRIC THRESHOLD ALERT
           1 - AVAILABILITY
SEVERITY_DURATION	The delta time, in hours, from when the severity was logged
    until it was cleared.
SEVERITY_GUID	 The unique id of the severity. Defaults to SYS_GUID()
ANNOTATED_FLAG	A flag to indicate whether the severity is annotated or not.
NOTIFICATION_STATUS	The column used by the notification sub system to determine
    notification status of the severity.
MESSAGE	The message of the severity.  The messages usually contain
    details about what triggered this severity.
MESSAGE_NLSID	The NLS ID of the severity message.
MESSAGE_PARAMS	URL encoded parameters separated by "&" to be used to
    format the severity message.
ACTION_MESSAGE	Suggested action message in english for this severity
ACTION_NLSID	The NLS ID of the action message.
ACTION_MESSAGE_PARAMS	URL encoded parameters for translating action message

Pour avoir des infos sur les alertes :

SELECT distinct s.target_guid, s.metric_guid,t.target_name,t.target_type,
    m.metric_name,   s.collection_timestamp, s.key_value
       FROM mgmt_targets t ,mgmt_current_severity s, mgmt_metrics m
            where s.target_guid = t.target_guid
            and m.metric_guid = s.metric_guid
            and t.target_type='oracle_database' -- interested only in database resultes (not hosts, application server,...)
            and s.collection_timestamp < to_timestamp('01/07/2010','DD/MM/YYYY') -- my deadline
            and t.target_name like 'my_database%'

To clean up, use something like (be careful could delete more rows than you expoect (i have to check that later on…)):

delete from mgmt_severity
WHERE (target_guid,metric_guid) IN
(SELECT s.target_guid,s.metric_guid
FROM mgmt_targets t ,mgmt_severity s
where s.target_guid = t.target_guid
and t.target_type=’oracle_database’
and s.collection_timestamp < to_timestamp(’25/06/2010′,’DD/MM/YYYY’)
and t.target_name like ‘pprtr%’)

Il est possible avec Oracle de se connecter SYSDBA à distance…mais pas toujours :

SQL> connect sys/monpassword@base_distante as sysdba
ERROR:
ORA-01031: insufficient privileges
Warning: You are no longer connected to ORACLE.

Il faut 3 conditions pour pouvoir faire une authentification a distance (remote authentication) :

• un fichier de mot de passe (password file)
• l’autorisation de s’authentifier ( REMOTE_OS_ATHENT=TRUE)
• la déclaration du password file ( REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE …ou SHARED )

Attention : cette authentification à distance d’un user très privilégié, en fait le + privilégié  (équivallent à SYS) est fortement déconseillée pour des raisons de sécurité.

Le password file d’Oracle est créé avec un utilitaire : orapwd

A sa création le user SYS est par défaut ajouté dans le fichier, une fois que le fichier existe on peut y rajouter d’autres utilisateurs que SYS en utilisant la commande GRANT SYSDBA

– exemple minimal

$> orapwd password=mypassword
– par défaut le fichier créé est  <$ORACLE_HOME>/dbs/orapwd<$ORACLE_SID>
– et plus tard on rajoute un user
SQL> GRANT SYSDBA TO SCOTT;

Attention !!!!!!!!!!!!!!!!!! si on créé un fichier ailleurs (avec le parametre ‘file=’ la commande orapwd s’execute correctyement …et Oracle sera incapable de retrouver le fichier au démarrage !!!!!!!!!! ou si on ne redémarre pas on aura tjs l’erreur ORA-03113
Pas de FILE ici donc un nom par defaut si echoue on n’a aucune erreur !!!

On peut éventuellement s’en apercevoir si on fait un GRANT SYSDBA :
SQL> grant sysdba to sys;
grant sysdba to sys
*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled
Syntaxe complete de orapwd :

Usage: orapwd file=<fname> password=<password> entries=<users> force=<y/n> nosysdba=<y/n>

where
file - name of password file (mand),le nom et l’emplacement du fichier, c’est faux ce n’est pas obligatoire, au contraire  !
password - password for SYS (mand),
entries - maximum number of distinct DBA, nb max de DBA dans le fichier
force - whether to overwrite existing file (opt), écrase le fichier existant
nosysdba - whether to shut out the SYSDBA logon (opt for Database Vault only).,

Il est possible de vérifier les users enregistrés dans le password file grace a la vue v$pwfile_users :

SQL> select * from v$pwfile_users;
USERNAME                       SYSDB SYSOP
SYS                            TRUE  TRUE

(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