Aucun message portant le libellé DBA_REGISTRY. Afficher tous les messages
Aucun message portant le libellé DBA_REGISTRY. Afficher tous les messages

jeudi 20 décembre 2012

Quels sont les correctifs (patches) installés sur la base de données ?


Si vous désirez connaître les correctifs (patches) d'Oracle qui ont été installés/appliqués sur la base de données, vous pouvez exécuter la commande suivante :

opatch lsinventory

et consulter le contenu des objets ci-dessous du dictionnaire :

select * from DBA_REGISTRY_HISTORY
select * from registry$history;
select * from dba_registry;


jeudi 27 août 2009

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

mercredi 6 mai 2009

Composante "Oracle Database Packages and Types" invalide dans DBA_REGISTRY

Après l'exécution du script « catupgrd.sql », on doit vérifier le statut des composantes avec la requête suivante :

Select comp_name,version,status
from sys.dba_registry;

Lors de la vérification des celles-ci sur une instance fraichement migrée, il s'est avéré que la composante « Oracle Database Packages and Types » était invalide.

Après vérification du statut des objets de la base de données, le package DBMS_SQLPA était invalide.

cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba

-- Detruire la table si elle a été mise à jour
drop table plan_table$;
-- Detruire la PLAN_TABLE du schema si elle existe
drop table plan_table;
-- Recréer la PLAN_TABLE
@catplan.sql
-- Recharger les packages impactés
@dbmsxpln.sql
@prvtxpln.plb
@prvtspao.plb
-- Recompiler les objets invalides en tenant compte des dépendances
@utlrp

Référence : Oracle Metalink, Note 605317.1

samedi 28 février 2009

Migrer une base de données vers un autre ORACLE_HOME

J'ai eu à migrer une bases de données 10.2.0.3 à 10.2.0.4.

La façon préconisée a été d'installer un nouveau "ORACLE_HOME" et tant qu'à faire, j'en ai profité pour déployer le CPU d'Oracle (Critical Patch Update Jan2009).

Installation
1. Installer le logiciel "Oracle Database 10.2.0.1"
2. Installer le patchset "Oracle Database 10.2.0.4"
3. Installer le "CPU January 2009"

Migration
1. Arrêt de la base de données

$ sqlplus / as sysdba
SQL> shutdown immediate

2. Création d'un fichier de paramètres PFILE à partir du SPFILE

$ sqlplus / as sysdba
SQL> create pfile='ORACLE_HOME/dbs/initORCL.ora' from spfile;
$ cd ORACLE_HOME/dbs
$ cp initORCL.ora NOUV_ORACLE_HOME/dbs/initORCL.ora

3. Editer le PFILE et modifier les paramètres dont ceux qui pointent dans l'ancien ORACLE_HOME ( compatible, optimizer_features_enable, etc...)

$ cd NOUV_ORACLE_HOME/dbs
$ vi initORCL.ora

4. Modifier le fichier ORATAB

Changer l'ORACLE_HOME correspondant à la base de données

$vi oratab
ORCL:NOUV_ORACLE_HOME:Y

5. Modifier le fichier de configuration du listener

(SID_DESC =
(GLOBAL_DBNAME = ORCL.world)
(ORACLE_HOME = NOUV_ORACLE_HOME)
(ENVS = 'LD_LIBRARY_PATH=NOUV_ORACLE_HOME/lib')
(SID_NAME = ORCL)

6. Redémarrer le listener

$ lsnrctl reload lsnr1020

7. Création des liens pour des fichiers (optionel)

Si vous n'utilisez pas les emplacements par défaut de certains fichiers (c'est mon cas!) alors vous devez créer des liens symboliques sous Unix.

Il suffit de se positionner dans le répertoire par défaut puis d'exécuter la commande:

- Pour l' ALERTSID.LOG
cd NOUV_ORACLE_HOME/rdbms/log
ln -s REPERTOIRE_DE_DESTN/alert_ORCL.log alert_ORCL.log

- Pour les fichiers de configuration (PFILE, SPFILE)
cd NOUV_ORACLE_HOME/dbs
ln –s REPERTOIRE_DE_DESTN/initORCL.ora initORCL.ora
ln –s REPERTOIRE_DE_DESTN/spfileORCL.ora spfileORCL.ora

8. Créer le fichier de mot de passe

$ orapwd file=NOUV_ORACLE_HOME/dbs/orapwORCL password= entries=20

9. Démarrer la base de données sous le nouveau ORACLE_HOME

$ sqlplus / as sysdba
SQL> create spfile from pfile='NOUV_ORACLE_HOME/dbs/initORCL.ora';

10. Démarrer la migration de la base de données

SQL> startup upgrade
SQL> SPOOL upgrade_info.log
SQL> @?/rdbms/admin/utlu102i.sql
SQL> SPOOL OFF

-- Vérifier le log précédent pour tout problème

SQL> SPOOL patch.log
SQL> @?/rdbms/admin/catupgrd.sql
SQL> SPOOL OFF
-- Vérifier le log précédent pour tout problème

11. Redémarrer la base de données en mode normal

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

12. Recompiler les objets invalides

SQL> @?/rdbms/admin/utlrp.sql

13. Vérifier le statut des composantes de la base de données

SQL> SELECT COMP_NAME, VERSION, STATUS FROM SYS.DBA_REGISTRY;


Cette façon permet de réinstaller proprement le logiciel de la base de données. Aussi, l'avantage de celle-ci est que si votre ORACLE_HOME actuel est partagé par plusieurs bases de données, vous pourrez migrer une base de données sans impacter les autres. Cette méthode peut aussi être utilisé pour déplacer une base de données vers un autre ORACLE_HOME.