jeudi 21 juin 2012

Informations sur les ressources du clusterware, les dernières sauvegardes de l'OCR/OLR et les statuts des voting disks

Je vous partage un script que j'ai écrit chez un client, qui permet d'afficher les ressources du clusterware, les dernières sauvegardes de l'OCR et OLR et le statut des voting disks.

Lorsqu'aucune ressource n'est passée en paramètre, le script affiche les informations sus-mentionnées.
Par contre, si on passe une ressource en paramètre, le script affiche juste le statut de cette dernière.


# 29-03-2012 - Creation initiale - Par Herve Etche
# 15-06-2012 - Ajout de la section des voting disks - Herve Etche

# Ce script affiche le statut general des ressources du cluster et les derniers backups de l'OCR et de l'OLR si on ne lui passe aucun parametre
#Il affiche aussi les informations concernant les voting disks.
# S'il y a une ressource passee en parametre, alors il affiche les details concernant la ressource en question
# Exemple de parametre: resource_script ora.asm -t (affiche seulement le statut de la ressource ora.asm) -- En supposant que resource_script est le nom donne au script

#!/usr/bin/ksh
HOST_NAME=`hostname -s`
GRID_HOME=$(cat /etc/oratab | awk -F: '/^\+ASM/{print $2}') #Recuperer le GRID_HOME a partir du fichier /etc/oratab
CRSD_PID=`ps -ef|grep crsd.bin|grep -v grep|awk '{print $2}'` #Le PID du process crsd
if [ $CRSD_PID ]; then #si le pid du process crsd existe, cela signifie que le clusterware est demarre
   STATUS_CRS=`$GRID_HOME/bin/crsctl stat res ora.asm -t|head -1|cut -d ':' -f1`
   if [ $STATUS_CRS != "CRS-4535" ]; then #Sinon impossible de communiquer avec le Cluster Ready Services (crs en cours de demarrage)
      if [[ $# -eq 0 ]]; then #Aucune ressource n'est passee en parametre
         #Afficher le status general des ressources sous forme tabulaire
         $GRID_HOME/bin/crsctl stat res -t

         #Afficher le dernier backup de l'OCR (Oracle Cluster Registry)
         printf '\033[31m' #couleur rouge
         echo -e "\nLes backups de l'OCR sont effectues sur le MASTER du cluster."
         printf '\033[0m' #Annuler couleur rouge
         A_OCR_MAXDATE=`$GRID_HOME/bin/ocrconfig -showbackup auto|awk '{print($2,$3)}'|sort -r|head -1` #Date et heure du dernier backup auto
         M_OCR_MAXDATE=`$GRID_HOME/bin/ocrconfig -showbackup manual|awk '{print($2,$3)}'|sort -r|head -1` #Date et heure du dernier backup manuel
         A_MNODE=`$GRID_HOME/bin/ocrconfig -showbackup auto|grep -m 1 "$A_OCR_MAXDATE"|cut -d ' ' -f1` #Master lors du dernier backup auto
         A_ERROR=`echo $A_MNODE|cut -c1-4`
         M_MNODE=`$GRID_HOME/bin/ocrconfig -showbackup manual|grep -m 1 "$M_OCR_MAXDATE"|cut -d ' ' -f1` #Master lors du dernier backup manuel
         M_ERROR=`echo $M_MNODE|cut -c1-4`
         printf '\033[4m' #Souligner phrase
         echo "Backup Automatique (chaque 4h):"
         printf '\033[0m' #Annuler souligner phrase
         if [ $A_ERROR = "PROT" ]; then #S'il n'existe pas de backup auto
            printf '\033[0;32m' #Couleur verte
            echo "Il n'existe aucun backup automatique de l'OCR"
            printf '\033[0m' #Annuler couleur verte
         else
            echo "Le master au moment du dernier backup automatique etait: "$A_MNODE
            echo -e "Le dernier backup automatique de l'OCR, effectue sur \""$A_MNODE\" "est:"
            printf '\033[0;32m' #Couleur verte
            $GRID_HOME/bin/ocrconfig -showbackup auto|grep -m 1 "$A_OCR_MAXDATE" #Affichage du dernier backup auto
            printf '\033[0m' #Annuler couleur verte
         fi
         printf '\033[4m' #Souligner phrase
         echo "Backup Manuel:"
         printf '\033[0m' #Annuler souligner phrase
         if [ $M_ERROR = "PROT" ]; then #S'il n'existe pas de backup manuel
            printf '\033[0;32m' #Couleur verte
            echo "Il n'existe aucun backup manuel de l'OCR"
            printf '\033[0m' #Annuler couleur verte
         else
            echo "Le master au moment du dernier backup manuel etait: "$M_MNODE
            echo -e "Le dernier backup manuel de l'OCR, effectue sur \""$M_MNODE\" "est:"
            printf '\033[0;32m' #Couleur verte
            $GRID_HOME/bin/ocrconfig -showbackup manual|grep -m 1 "$M_OCR_MAXDATE" #Affichage du dernier backup manuel
            printf '\033[0m' #Annuler couleur verte
         fi
         echo -e "\n"
         #Afficher le dernier backup de l'OLR (Oracle Local Registry) du noeud a partir duquel le script est lance
         printf '\033[31m' #couleur rouge
         echo "Les backups de l'OLR sont effectues localement sur chaque noeud du cluster."
         printf '\033[0m' #Annuler couleur rouge
         OLR_MAXDATE=`$GRID_HOME/bin/ocrconfig -local -showbackup|awk '{print($2,$3)}'|sort -r|head -1` #Date et heure du dernier backup de l'olr
         LNODE=`$GRID_HOME/bin/ocrconfig -local -showbackup|awk '{print $1}'|sort -r|head -1` #Utiliser LNODE et non "hostname" pour s'assurer de l'existence ou pas d'un backup
         L_ERROR=`echo $LNODE|cut -c1-4`
         if [ $L_ERROR = "PROT" ]; then #S'il n'existe pas de backup de l'OLR
            printf '\033[0;32m' #Couleur verte
            echo -e "Il n'existe aucun backup de l'OLR sur le noeud local \"`hostname -s`\"\n" #Utiliser "hostname" car LNODE ici contient une erreur
            printf '\033[0m' #Annuler couleur verte
         else
            echo -e "Le dernier backup de l'OLR, effectue sur le noeud local \""$LNODE\" "est:"
            printf '\033[0;32m' #Couleur verte
            $GRID_HOME/bin/ocrconfig -local -showbackup|grep -m 1 "$OLR_MAXDATE" #Affichage du dernier backup de l'OLR
            printf '\033[0m' #Annuler couleur verte
            echo -e "\n"
         fi

         #Information sur les voting disks
         nb_voting=`$GRID_HOME/bin/crsctl query css votedisk|tail -1|awk '{print $2}'` #nombre de voting disks
         printf '\033[31m' #couleur rouge
         echo "Les donnees des voting disks sont automatiquement sauvegardees dans l'OCR a chaque changement de configuration."
         printf '\033[0m' #Annuler couleur rouge
         echo -e "Il existe \033[0;32m$nb_voting\033[0m voting disk(s)"
         nb=1
         while [ $nb -le $nb_voting ]
         do
            statut=`$GRID_HOME/bin/crsctl query css votedisk|sed 's/^ //g'|grep ^[0-9]|grep -m 1 $nb.|awk '{print $2}'`
            diskgrp=`$GRID_HOME/bin/crsctl query css votedisk|sed 's/^ //g'|grep ^[0-9]|grep -m 1 $nb.|cut -d '[' -f2|cut -d ']' -f1`
            disk=`$GRID_HOME/bin/crsctl query css votedisk|sed 's/^ //g'|grep ^[0-9]|grep -m 1 $nb.|cut -d '(' -f2|cut -d ':' -f2|cut -d ')' -f1`
            if [ $diskgrp ]; then
               echo -e "Le voting disk numero \033[0;32m$nb\033[0m, situe dans le diskgroup \033[0;32m$diskgrp\033[0m, disque \033[0;32m$disk\033[0m, a un statut \033[0;32m$statut\033[0m."
            else
               echo -e "Le voting disk numero \033[0;32m$nb\033[0m, situe dans le disque \033[0;32m$disk\033[0m, a un statut \033[0;32m$statut\033[0m."
            fi
            nb=$(( $nb + 1 ))
         done
         echo -e "\n"
      else #Une ressource est passee en parametre
         #Afficher seulement le status de cette derniere
         $GRID_HOME/bin/crsctl stat res "$@"
      fi
   else #Clusterware en cours de demarrage donc impossible de communiquer avec le crs malgre que le process crsd.bin existe
      echo -e "\n*******************************************************************"
      printf '\033[4m' #Souligner phrase
      echo "Statut des ressources du cluster:"
      printf '\033[0m' #Annuler souligner phrase
      echo "Le clusterware est en cours de demarrage sur le noeud local!"
      echo "Veuillez patienter ou lancer la commande a partir d'un autre noeud."
      echo -e "*******************************************************************\n"
   fi
else #Pas de process crsd, donc le clusterware n'est pas demarre
   echo -e "\n*************************************************"
   echo " Le clusterware n'est pas demarre sur ce noeud !"
   echo -e "*************************************************\n"
fi
find $GRID_HOME/log/$HOST_NAME/client/ocrconfig* -user $USER -type f -mtime +15 -exec rm {} \; #Efface les fichiers log generes par la commande ocrconfig datant de plus de 15 jours

Exemple de résultat attendu sans paramètre:

[oracle@srvhost1 ~]$ ./resource_script.sh
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       srvhost1
               ONLINE  ONLINE       srvhost2
ora.FRA.dg
               ONLINE  ONLINE       srvhost1
               ONLINE  ONLINE       srvhost2
Les backups de l'OCR sont effectues sur le MASTER du cluster.
Backup Automatique (chaque 4h):
Le master au moment du dernier backup automatique etait: srvhost1
Le dernier backup automatique de l'OCR, effectue sur "srvhost1" est:
srvhost1     2012/06/21 13:55:11     /ora01/app/grid/grid_11g/cdata/crs11gr2/backup00.ocr
Backup Manuel:
Le master au moment du dernier backup manuel etait: srvhost2
Le dernier backup manuel de l'OCR, effectue sur " srvhost2" est:
srvhost2     2012/05/10 15:12:30     /ora01/app/grid/grid_11g/cdata/crs11gr2/backup_20120510_151230.ocr

Les backups de l'OLR sont effectues localement sur chaque noeud du cluster.
Le dernier backup de l'OLR, effectue sur le noeud local "srvhost1" est:
srvhost1     2012/04/30 12:07:40     /ora01/app/grid/grid_11g/cdata/srvhost1/backup_20120430_120740.olr

Les donnees des voting disks sont automatiquement sauvegardees dans l'OCR a chaque changement de configuration.
Il existe 1 voting disk(s)
Le voting disk numero 1, situe dans le diskgroup OCRDG, disque DISK_D01, a un statut ONLINE.
[oracle@srvhost1 ~]$

Avec des paramètres:
--Exemple: Rechercher toutes les ressources contenant le mot "inst" c'est à dire les instances enregistrées dans le clusterware.

[oracle@ srvhost1 ~]$ ./resource_script -w "NAME co inst" -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.db1.db11.inst
      1        ONLINE  ONLINE       srvhost1
ora. db1. db12.inst
      1        ONLINE  ONLINE       srvhost2
ora.db2.db21.inst
      1        ONLINE  ONLINE       srvhost1
ora.db2.db22.inst
      1        ONLINE  ONLINE       srvhost2
ora.db3.db31.inst
      1        ONLINE  ONLINE       srvhost1
ora.db3.db32.inst
      1        ONLINE  ONLINE       srvhost2
 [oracle@ srvhost1 ~]$

Hope it helps...

mercredi 20 juin 2012

La colonne header_status a la valeur PROVISIONED dans la vue v$asm_disk pour un disque appartenant a un diskgroup

Salut à tous,

Désolé pour ce long silence.

Pour rentrer dans le vif du sujet, il arrive qu'un disque asm appartenant à un diskgroup ait un statut PROVISIONED (colonne header_status de la vue v$asm_disk), alors que le statut devrait être MEMBER. J'ai vécu ce cas dans un environnement 11.2.0.3.

Pour vérifier le « header_status », se connecter à l'instance ASM.

sqlplus / as sysasm

set linesize 3000
column name format a9
column failgroup format a10
column label format a10
column state format a8
column group_number format 999999 heading 'GR_NBR'
column header_status format a11 heading 'HEADER'

select a.group_number, a.name, a.state, a.type, b.disk_number, b.failgroup, b.label, b.header_status
from v$asm_diskgroup a, v$asm_disk b
where a.group_number <> 0
and a.group_number = b.group_number
order by b.failgroup;

GR_NBR NAME STATE TYPE DISK_NUMBER FAILGROUP LABEL HEADER
------- --------- -------- ------ ----------- ---------- ---------- -----------
2 DATA MOUNTED EXTERN 2 DISK_AD1 DISK_AD1 MEMBER
1 DATAFRA MOUNTED EXTERN 0 DISK_AD3 DISK_AD3 MEMBER
4 OCR_VOTE MOUNTED EXTERN 0 DISK_AD5 DISK_AD5 MEMBER
4 OCR_VOTE MOUNTED EXTERN 1 DISK_AD6 DISK_AD6 MEMBER
2 DATA MOUNTED EXTERN 0 DISK_DD1 DISK_DD1 MEMBER
2 DATA MOUNTED EXTERN 1 DISK_DD2 DISK_DD2 MEMBER
3 FRA MOUNTED EXTERN 0 DISK_FD1 DISK_FD1 PROVISIONED
7 rows selected.


Lorsqu’un disque a pour header_status « PROVISIONED », il est impossible de monter le diskgroup qui le contient (evidemment lorsque le diskgroup sera démonté et qu'on voudra le montrer à nouveau):

sqlplus / as sysasm

SQL> alter diskgroup fra mount;
alter diskgroup fra mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "0" is missing from group number "1"


Lorsqu’on fait un "kfed read" sur le disque en question, on voit bien qu’il est MEMBER:

Pour utiliser la commande "kfed" positionner les valeurs d'environnement de l'utilisateur qui a installé le grid infrastructure 11gR2, puis lancer la commande:

[oracle@srvhost bin]$ kfed read ORCL:DISK_FD1
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfbh.check: 3532758487 ; 0x00c: 0xd2919dd7
kfbh.fcn.base: 145337452 ; 0x010: 0x08a9ac6c
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISKDISK_FD1 ; 0x000: length=16
kfdhdb.driver.reserved[0]: 1263749444 ; 0x008: 0x4b534944
kfdhdb.driver.reserved[1]: 826558047 ; 0x00c: 0x3144465f
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DISK_FD1 ; 0x028: length=8
kfdhdb.grpname: FRA ; 0x048: length=3
kfdhdb.fgname: DISK_FD1 ; 0x068: length=8


Le fait que le "kfed read" du disque montre MEMBER démontre que c’est seulement au niveau de la vue V$ASM_DISK qu’on obtient la valeur PROVISIONED.

Puisque la version d’ASM utilisée est 11.2.0.3, on peut utiliser la commande « kfed repair » pour corriger le problème.

Pour utiliser la commande "kfed" positionner les valeurs d'environnement de l'utilisateur qui a installé le grid infrastructure 11gR2, puis lancer la commande pour réparer:

[oracle@srvhost bin]$ kfed repair ORCL:DISK_FD1
[oracle@srvhost bin]$

Vérifier que le problème est résolu:

sqlplus / as sysasm

set linesize 3000
column name format a9
column failgroup format a10
column label format a10
column state format a8
column group_number format 999999 heading 'GR_NBR'
column header_status format a11 heading 'HEADER'

select a.group_number, a.name, a.state, a.type, b.disk_number, b.failgroup, b.label, b.header_status
from v$asm_diskgroup a, v$asm_disk b
where a.group_number <> 0
and a.group_number = b.group_number
order by b.failgroup;


GR_NBR NAME STATE TYPE DISK_NUMBER FAILGROUP LABEL HEADER
------- --------- -------- ------ ----------- ---------- ---------- -----------
2 DATA MOUNTED EXTERN 2 DISK_AD1 DISK_AD1 MEMBER
1 DATAFRA MOUNTED EXTERN 0 DISK_AD3 DISK_AD3 MEMBER
4 OCR_VOTE MOUNTED EXTERN 0 DISK_AD5 DISK_AD5 MEMBER
4 OCR_VOTE MOUNTED EXTERN 1 DISK_AD6 DISK_AD6 MEMBER
2 DATA MOUNTED EXTERN 0 DISK_DD1 DISK_DD1 MEMBER
2 DATA MOUNTED EXTERN 1 DISK_DD2 DISK_DD2 MEMBER
3 FRA MOUNTED EXTERN 0 DISK_FD1 DISK_FD1 MEMBER
7 rows selected.


Hope it helps...

jeudi 21 avril 2011

MODPLSQL-00367: mod_plsql: /pls/apex/f HTTP-400 Illegal PLSQL identifer in input

Une application oracle application express (apex) utilise un «database access descriptor» (DAD) configuré au niveau d'un serveur OAS 10g.

Voici la section concernant ce DAD dans le fichier «dads.conf»:

<location /pls/apex>
SetHandler pls_handler
Order allow,deny
Allow from All
AllowOverride None
PlsqlDatabaseUsername apex_public_user
PlsqlDatabasePassword xxxxxxxxx
PlsqlDatabaseConnectString hostname:port:service ServiceNameFormat
PlsqlAuthenticationMode Basic
PlsqlSessionStateManagement StatelessWithFastResetPackageState
PlsqlDocumentTablename wwv_flow_file_objects$
PlsqlDocumentPath docs
PlsqlDocumentProcedure wwv_flow_file_mgr.process_download
PlsqlAlwaysDescribeProcedure Off
PlsqlDefaultPage f?p=102
</location>

Après avoir migré le serveur OAS à la version fusion middleware 11.1.1.3, en essayant l'url de l'application apex, l'on reçoit un message d'erreur HTTP-400.

Dans le fichier $INSTANCE11g_HOME/diagnostics/logs/OHS/ohs1/ohs1.log on peut lire le message d'erreur suivant:

MODPLSQL-00367: mod_plsql: /pls/apex/f HTTP-400 Illegal PLSQL identifer in input

Cette erreur est causée par la ligne suivante dans la configuration du DAD:

PlsqlDefaultPage f?p=102

Selon la documentation Oracle, ce paramètre peut être remplacé par un Rewrite rule:
http://download.oracle.com/docs/cd/E14571_01/web.1111/e10144/under_mods.htm#CIHBJFII

Donc supprimons cette ligne de notre fichier «dads.conf» (ou la mettre en commentaire).

Dans le fichier «httpd.conf», ajoutons le Rewrite rule (dans la section commune, pas dans un virtual host):

RewriteRule ^/pls/apex$ /pls/apex/f?p=102 [R]

Puis redémarrer OHS:

$INSTANCE11g_HOME/bin/opmnctl restartproc ias-component=ohs1

Hope it helps

mardi 19 avril 2011

«Failed to load user defined filter» after upgrade from portal 10.1.4.0 to portal 11.1.1.3

Après avoir migré de portal 10.1.4.0 à portal 11.1.1.3, les omniportlets ramènent le message d'erreur suivant:

Failed to load user defined filter
Dans le fichier WLS_PORTAL-diagnostic.log, l'on peut voir le message d'erreur:

oracle.xml.parser.v2.XMLParseException: Start of root element expected.
at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:323)
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:380)
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:321)
at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:319)
at oracle.xml.xslt.XSLProcessor.newXSLStylesheet(XSLProcessor.java:682)
at oracle.xml.xslt.XSLStylesheet.(XSLStylesheet.java:287)
at oracle.xml.parser.v2.XSLStylesheet.(XSLStylesheet.java:90)
at oracle.webdb.reformlet.data.xml.FilterHandler.loadFilter(Unknown Source)
at oracle.webdb.reformlet.data.xml.XMLDataDefinition.createContext(Unknown Source)
at oracle.webdb.reformlet.data.DataSourceDefinitionWrapper.createContext(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.setDataSourceInfoInContext(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.execute(Unknown Source)
at oracle.webdb.reformlet.definition.DataDefinition.execute(Unknown Source)
at oracle.webdb.reformlet.api.layout.LayoutContext.nextRow(Unknown Source)
at oracle.webdb.reformlet.api.el.ELRows.hasNext(Unknown Source)
...
...
Cela est dû au fait que les URLs dans les omniportlets sont sous la forme:

Pour le XML url:
http://localhost:7777/pls/pes/P_PESB_RECUP_FIL_RSS?P_IDENT=1&P_PERSP=Accueil

Pour le XSL filter url:
http://localhost:7777/portal/page/portal/14F1816FBFB751AEE04400144F0104BD

«localhost» a été utilisé dans la version 10g pour que les pages soient portables, c'est à dire qu'on peut exporter les pages d'un environnement à un autre et les omniportlets restent fonctionnels car localhost existe aussi sur l'hote cible.

Le problème vient du fait qu'avec la version 11g de portal, le server de bd qui abrite le metadata repository doit être capable de communiquer avec le serveur de midle tier par le virtual host utilisé. Puisque localhost est utilisé, il faut que le server de bd puisse communiquer avec le server de midle tier par localhost !!! ce qui est impossible, puisque sur chaque server, localhost pointe sur le serveur lui même.

Pour régler ce problème, il faut:

- Créer un virtual host commun dans tous les environnements (pour que les pages restent portables).
- Il faut definir ce virtual host dans le fichier /etc/hosts du serveur de bd de sorte qu'il pointe sur le serveur de middle tier ou le definir dans un DNS.
- Modifier tous les omniportlets pour qu'ils utilisent ce nouveau virtual host.

Hope it helps...

lundi 18 avril 2011

Object Not Found (WWC-50003) Error Accessing a page Using Durable URL after upgrade to Portal 11.1.1.3

Après avoir migré de la version 10.1.4.2 de portal vers la version 11.1.1.3, en voulant utiliser les liens (url) durables des pages, l'on reçoit le message d'erreur suivant:

Object Not Found (WWC-50003)

Cela est dû au fait que le processus de migration du metadara repository regenère les liens (url) durables. Mais c'est le comportement voulu par oracle, donc ce n'est pas une anomalie...

La question qui reste en suspens c'est pourquoi oracle décide de regénérer les liens durables tout en sachant très bien que cela rendra le site non fonctionnel après la migration...?

Pour régler le problème, deux options s'offrent à nous:

1- Parcourir le site et remplacer tous les appels par des liens durables par les nouveaux liens durables générés.

2- Si vous ne désirez pas faire ce travail manuel, et que vous souhaiteriez conserver vos anciens liens durables, suivre la procédure suivante:
- Restaurer le schéma PORTAL (en le renommant) d'un export de la BD pris avant de migrer le metadata repository. Cela suppose que vous devez avoir un export valid pris avant la migration. Si vous n'avez pas d'export, mais plutot un backup rman, restaurer le backup rman et faites votre export.
- Créer un DBLINK en utilisant le schéma précédemment restauré. - Demander le script «guidmasg.sql» à oracle support
- Se connecter à la BD du référentiel avec le schéma portal (le schéma migré) - Exécuter le scipt comme suit: SQL> @guidmasg.sql DBLINK

Hope it helps...