Destination alternative pour les fichiers d'archive (archivelog files)

Pour les bases de données Oracle, on peut ajouter une destination alternative pour les fichiers d'archive (archivelog files) au cas où la destination primaire se remplisse ou devienne indisponible.

Par exemple, en supposant que la destination primaire est le groupe de disque "FRA1" sous Oracle Automatic Storage Management (ASM), il est possible d'ajouter comme destination alternative le groupe de disques (diskgroup), nommons-le "FRA2". Si jamais "FRA1" est plein, Oracle va automatiquement commencer à inscrire ses fichiers d'archive dans "FRA2". Lorsque "FRA1" redeviendra en état de recevoir des fichiers d'archive, Oracle va automatiquement recommencer à inscrire les fichiers dans "FRA1".

Ceci est un comportement normal pour les bases de données de la version 12c. Pour les bases de données de la version 11g, la destination alternative est aussi possible cependant si jamais la base de données bascule l’inscription des fichiers d'archive vers "FRA2", vous devrez manuellement réactiver la destination primaire.

Statut de la capture « INITIALIZING » ou « DICTIONNARY INITIALIZING »

En effectuant la commande suivante pour vérifier le processus de capture :

select * from v$streams_capture;

Si le statut (STATE) indique "INITIALIZING" ou "DICTIONARY INITIALIZATION", assurez-vous que tout les fichiers d'archive nécessaire au fonctionnement de Stream sont présent. Pour ce faire, exécuter le script "Health Check" (Streams Configuration Report and Health Check Script [ID 273674.1]) .

Suite à l'exécution du script, chercher la section intitulé "++ Minimum Archive Log Necessary to Restart Capture ++". Cette section vous indiquera quel fichier d'archive vous devez avoir sur disque pour que la capture puisse reprendre.

Voici un extrait du résultat du script "Health Check" :

==========================================================================

++ Minimum Archive Log Necessary to Restart Capture ++
Note: This query is valid for databases where the capture processes exist for the same source database.

Capture will restart from SCN 17548223670 in the following file:
/uhm004_u04/home/dba/oracle/admin/R002/arch/R002_723971581073678.arc (04:53:41 02/15/10)
PL/SQL procedure successfully completed.

==========================================================================

Si vous remarquez qu'il vous manque des fichiers d'archive, vous devrez procéder à une restauration des fichiers d'archive via Recovery Manager.

Voici comment procéder :

rman target sys/xxxx@BD_CIBLE catalog rman/xxxx@BD_CATALOG

RMAN> run {
allocate channel ch01 type 'SBT_TAPE';
restore archivelog sequence between 72390 and 72414;
}

Dans le cas présent, la restauration s'est effectué en précisant des numéros de séquences mais plusieurs autres types de restauration sont possibles tels que par date, par # scn, etc...
Suite à la restauration des fichiers d'archive, le processus de capture reprendra graduellement. Vérifier à quelques reprises le statut du processus de capture, il changera de valeurs, puis il restera dans l'état "CAPTURING CHANGES".

select * from v$streams_capture;

Assurez-vous qu'il n'y a pas d'erreur sur l'ensemble des processus impliqué dans la réplication Oracle Streams :

SELECT CAPTURE_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_CAPTURE;

SELECT PROPAGATION_NAME, STATUS, ERROR_MESSAGE, ERROR_DATE
FROM DBA_PROPAGATION;

SELECT APPLY_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_APPLY;

SELECT APPLY_NAME, SOURCE_DATABASE, LOCAL_TRANSACTION_ID,
ERROR_NUMBER, ERROR_MESSAGE, MESSAGE_COUNT
FROM DBA_APPLY_ERROR;

Voyage dans le... passé

La mise à niveau d'une base de données Oracle nous force à se questionner sur la possibilité d'un retour arrière. En effet, malgré que nous prenions toutes les précautions possibles et que
nous testions les applications, un problème important peut surgir et nous forcer à réaliser un retour arrière vers les versions de bases de données originales.

Le retour arrière n'est jamais l'idéal sauf qu'il vaut mieux prévoir une méthode afin de minimiser les impacts et les problèmes. C'est à ce moment que la fonctionnalité "FLASHBACK DATABASE" attire mon attention.

Flashback Database permet de ramener la base de données entière à un état dans le passé. Elle utilise des journaux (Flashback log) et, quand elle est activée, ces journaux sont créés à l'emplacement nommé « flash recovery area ». Oracle s'occupe de créer, détruire et redimensionner les journaux automatiquement. À l'occasion, il faut vérifier l'espace qui est disponible pour le flashback area.

Pour utiliser le « flashback database », le « flash recovery area » doit être mis en place.

Voici quelques prés requis :

ACTIVATION DES FONCTIONNALITÉS
Pour utiliser la fonctionnalité « FLASHBACK DATABASE », Le mode d'archive et la fonctionnalité « flashback database » doit être activé sur la base de données.

Voici comment vérifier l'état des fonctionnalités :

SELECT flashback_on, log_mode
FROM v$database;

Vérifier la valeur des paramètres lies à la fonctionnalité « flashback
database » :

col name format A30 wrap
col value format A20 wrap
SELECT inst.instance_name, parm.name, parm.value
FROM gv$parameter parm, gv$instance inst
WHERE parm.inst_id = inst.inst_id
and (name LIKE '%flashback%'or name LIKE '%recovery%')
order by 1,2;

Initialiser les paramètres pour le « Flashback » :

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+FRAGRP01' SCOPE= BOTH;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G SCOPE=BOTH;

Fermer l'instance :

Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer
toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount »

startup mount exclusive;

Activer le mode ARCHIVE (si nécessaire)

Alter database archivelog;

Activer la fonctionnalité « FLASHBACK DATABASE »

Alter database flashback on;

CRÉATION DU POINT DE RESTAURATION
Un point de restauration doit être marqué dans le temps pour être en mesure de le référer dans l'éventualité où nous en aurions besoin. Ce point de restauration doit être créé avant la migration de la base de données.

Voici comment procéder pour créer le point de restauration :

Fermer l'instance :

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Créer le point de restauration :

CREATE RESTORE POINT avant_upgrade GUARANTEE FLASHBACK DATABASE;

Vérifier l'existence de point de restauration créé précédemment :

SELECT NAME, SCN, TIME,
DATABASE_INCARNATION# DI,
GUARANTEE_FLASHBACK_DATABASE,
STORAGE_SIZE FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

Fermer l'instance :

shutdown immediate

À partir de ce point, la migration peut débuter.

PARTICULARITÉS
Il ne faut pas modifier la valeur du paramètre « COMPATIBLE ». Autrement, le mécanisme de retour arrière peut ne pas fonctionner adéquatement. Le changement de valeur va identifier tous les fichiers de la base de données comme étant des fichiers de la nouvelle version et, vous
observerez une erreur semblable lors du démarrage de l'instance :

ORA-00201: control file version 10.2.0.4.0 incompatible with ORACLE version
10.2.0.3.0
ORA-00202: control file: '+FRAGRP01/orcl/controlfile/current.263.660837815'

RESTAURATION
Si vous devez ramener votre base de données à l'état où elle était avant la migration, il vous suffit de suivre ces étapes :

Fermer l'instance:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount

Restaurer la base de données au point de restauration :

Flashback database to restore point avant_upgrade;

Fermer l'instance :

shutdown immediate

N'oubliez pas de réinitialiser toutes les variables d'environnement incluant ceux des autres noeuds si vous êtes sur un environnement RAC.

Après avoir réinitialisé les variables d'environnements, il faut :

Démarrer l'instance:

startup mount

Ouvrir la base de données en initialisant les journaux :

Alter database open resetlogs;

Vérifier l'état actuel des composantes de la base de données :

select comp_name, status, version from dba_registry;

N'oubliez pas de reprendre une copie de sauvegarde de la base de données.

DÉSACTIVATION DE LA FONCTIONNALITÉ
Pour désactiver la fonctionnalité « FLASHBACK DATABASE », voici les étapes à
suivre :

Voici comment le vérifier :

SELECT flashback_on FROM v$database;

Fermer l'instance :
Si c'est une instance faisant partie d'un cluster (RAC), veuillez fermer toutes les instances en suivant l'exemple ci-dessous :

srvctl stop database -d BD

Autrement, fermer l'instance comme suit:

shutdown immediate

Démarrer l'instance en mode « mount » :

startup mount exclusive;

Désactiver la fonctionnalité « FLASHBACK DATABASE » :

Alter database flashback off;

Cette solution de retour en arrière s'applique seulement dans le cas où la migration ne s'effectue pas correctement. Toutes les transactions suivant la migration, incluant celles provenant des applications maisons, seront perdues si un retour en arrière est effectué.

Archiver error... Quel est la cause ?

Durant le weekend, une base de données a rencontrée des problèmes. Elle générait plein d'écritures donc, plein de fichiers d'archive jusqu’à remplir le disque réservé aux archives.

J'avais remarqué que c'était une job (DBMS_JOB) qui exécutait un rafraichissement de vues matérialisées via un groupe de rafraichissement. Voici le code exécuté par la job :

dbms_refresh.refresh('"ABC"."ABC_GRP_REPLC"');

La job plantait et elle s'exécutait de nouveau pour effectuer une reprise automatique. Je l’ai donc interrompu, le temps de trouver la cause exacte.

Pour débuter, j’ai tenté de rafraichir les vues, à tour de rôle, pour finalement rencontrer cette erreur lors du rafraichissement manuelle d'une d'entre-elle :

ABC@ORCL> exec dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C');
ERROR:
ORA-03114: pas connecté à ORACLE

BEGIN dbms_mview.refresh('ABC.ABC_V_DIRCT_TERRT_GENRL','C'); END;

*
ERROR at line 1:
ORA-03113: fin de fichier sur canal de communication
Process ID: 0
Session ID: 412 Serial number: 3177


Suite à cette erreur rencontré dans l'outil SQL*Plus, j’ai consulté le fichier « alertSID.log » de la base de données et, j’ai trouvé cette erreur :

ORA-07445: exception encountered: core dump [qcdlgcd()+116] [SIGSEGV] [Address not mapped to object] [0x000000037] [] []

Après avoir faire quelques recherches, je suis tombé sur la note 459323.1 du site Oracle Metalink qui explique ce problème. La cause provient de l’énoncé SQL qui constitue la vue matérialisée. Cet énoncé est invalide. Elle fait référence à une colonne qui n’existe plus. Pour résoudre ce problème, on doit détruire et recréer la vue matérialisée.

Étape de résolution :

- Détruire la vue matérialisée
DROP MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL";

- Créer la vue matérialisée
CREATE MATERIALIZED VIEW "ABC"."ABC_V_DIRCT_TERRT_GENRL"
TABLESPACE "ABC_D01"
USING INDEX TABLESPACE "ABC_D01"
REFRESH FORCE AS
SELECT…

- Rétablir les droits sur la vue matérialisée
GRANT SELECT ON ABC.ABC_v_dirct_terrt_genrl TO abcpool;

- Ajouter la vue matérialisée au groupe de rafraichissement
BEGIN
DBMS_REFRESH.ADD(
name => '"ABC"."ABC_GRP_REPLC"',
list => '"ABC"."ABC_V_DIRCT_TERRT_GENRL"',
lax => TRUE);
END;
/

- Exécuter la job
exec DBMS_JOB.RUN(job => 372);