Oracle DBA Tips

mardi 20 août 2013

ORA-13236: internal error in R-tree processing: [Snapshot too old or Recursive fetch error]

Après avoir migré de la version 10.2.0.3 vers la version 11.2.0.3, il arrive que des requêtes incluant des tables partitionnées contenant des données spatial donnent l'erreur:

ERREUR Ó la ligne 1 :
ORA-13236: erreur interne dans le traitement R-tree : [Snapshot too old or Recursive fetch error]
ORA-13234: Úchec de l'accÞs Ó la table d'index R-tree [MDRT Table]
ORA-29400: erreur de cartouche de donnÚes
ORA-01031: privilÞges insuffisants
ORA-06512: Ó "MDSYS.SDO_PQRY", ligne 122
ORA-06512: Ó ligne 1

Voir le document suivant de My Oracle Support:
ORA-13236 [Snapshot too old or Recursive fetch error] on cross-schema Spatial Query [ID 1303804.1]

Le problème est dû au fait qu'avec les nouvelles versions d'oracle (depuis la version 10.2.0.4) il faut faire un GRANT explicite sur les tables MDRT générées par les indexes spatial.

Voici un petit script pour faire ce GRANT sur toutes les tables MDRT concernées:

set pagesize 1000
spool c:\temp\grant_mdrt.sql
select 'grant select on '|| c.table_owner || '.' || c.sdo_index_table || ' to ' || d.grantee || ';' from DBA_PART_TABLES a, dba_tab_columns b, all_sdo_index_info c , dba_tab_privs d
where a.owner not in ('SYS','SYSTEM')
and a.owner = b.owner
and a.table_name = b.table_name
and b.data_type like '%SDO_GEOMETRY'
and b.owner = c.table_owner
and b.table_name = c.table_name
and a.owner = d.owner
and a.table_name = d.table_name
and d.privilege = 'SELECT' ;
spool off;

Exécuter par la suite le fichier sql obtenu:
@c:\temp\grant_mdrt.sql

Hope it helps...

OPatch found the word "warning" in the stderr of the make command

En appliquant des patches oracle il se peut que vous rencontriez l'avertissement suivant (ou un message similaire):

OPatch found the word "warning" in the stderr of the make command.
Please look at this stderr. You can re-run this make command.
Stderr output:
ins_precomp.mk:19: warning: overriding commands for target `pcscfg.cfg'
/ora01/logi/oracle/product/bd11203p/precomp/lib/env_precomp.mk:2160: warning: ignoring old commands for target `pcscfg.cfg'
/ora01/logi/oracle/product/bd11203p/precomp/lib/ins_precomp.mk:19: warning: overriding commands for target `pcscfg.cfg'
/ora01/logi/oracle/product/bd11203p/precomp/lib/env_precomp.mk:2160: warning: ignoring old commands for target `pcscfg.cfg'

Composite patch 14727310 successfully applied.
OPatch Session completed with warnings.
Log file location: /ora01/logi/oracle/product/bd11203p/cfgtoollogs/opatch/opatch2013-02-15_15-26-36PM_1.log

OPatch completed with warnings.

Voir le document de My Oracle Support:
Opatch warning: overriding commands for target xxxx [ID 1448337.1]

Selon ce document, il s'agit tout simplement d'un avertissement qui peut être ignoré.

Hope it helps...

UDE-00008: operation generated ORACLE error 31626

En faisant un export avec datapump (expdp) avec la version 10.2.0.3 j'ai rencontré l'erreur suivante:

UDE-00008: operation generated ORACLE error 31626
ORA-31626: job does not exist
ORA-39086: cannot retrieve job information
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2745
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3712
ORA-06512: at line 1

Pour ce problème voir le document suivant de My Oracle Support :
Data Pump Client Gets UDE-8 ORA-31626 ORA-39086 (Doc ID 549781.1)

Selon ce document, si le fichier log de l'export indique que l'export s'est terminé correctement le messsage d'erreur peut être ignoré.

Dans mon cas le fichier log de l'export indique bien que l'export s'est terminé correctement:

Master table "EXPORTS"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for EXPORTS.SYS_EXPORT_SCHEMA_01 is:
/ora501/bd11gr2/expdp_epel_he_sst1_20130819_161102_01.dmp
Job "EXPORTS"."SYS_EXPORT_SCHEMA_01" successfully completed at 20:30:07

Alors message d'erreur ignoré...

Hope it helps...

lundi 29 juillet 2013

Exemple d'utilisation de l'utilitaire ASM "kfod"

Un petit script qui permet de lister les diskgroups et les disks ASM associés.
Bien sûr l'on peut retrouver les mêmes informations à partir des vues dynamiques, mais l'objectif de cet article c'est de montrer l'utilisation que l'on peut faire de l'utilitaire asm "kfod".

L'utilitaire se trouve dans le répertoire $GRID_HOME/bin en environnement cluster comme en environnement standalone.

Le script a été écrit sur un serveur Linux, donc avec la présence d'asmlib. Il tient compte du fait que sur certains serveurs les disques s'appellent /dev/oracleasm/disks/* (les alias sont créés par asmlib, mais asmlib n'est pas utilisé au moment de monter les diskgroups, cela est le résultat d'un problème que nous avons rencontré à cause de la version des contrôleurs du SAN. Voir l'article http://www.herve-etche.com/2012/12/ora-15085-asm-disk-has-inconsistent.html pour plus de détails) et sur d'autres serveurs c'est ORCL:* (ici asmlib est utilisé).

# 10-avril-2013 - Creation initiale - Par Herve Etche

# Ce script permet d'afficher les diskgroups asm et leurs tailles. Il affiche aussi les disques de chaque diskgroup et leurs tailles

#!/usr/bin/ksh

GRID_HOME=$(cat /etc/oratab | awk -F: '/^\+ASM/{print $2}') #Recuperer le GRID_HOME a partir du fichier /etc/oratab

ASM_PID=`ps -ef|grep asm_pmon|grep -v grep|awk '{print $2}'` #Le PID du process pmon d'asm

if [ $ASM_PID ]; then # Le process pmon d'asm existe, l'instance est donc demarree

v_profile=`asmcmd dsget|cut -d ':' -f2|uniq`

DG=`$GRID_HOME/bin/kfod asm_diskstring='/dev/oracleasm/disks/*' dscvgroup=TRUE disks=all|grep DISK|awk '{print $5}'|grep -v \#|sort|uniq` #Liste des diskgroups

if test -n "$DG"; then

for x in $DG

echo

printf '\033[32m' #couleur verte

printf '\033[4m' #Souligner phrase

echo -e "Diskgroup: $x"'\033[0m';

printf '\033[0m' #Annuler couleur verte et le souligner

echo

echo " Diskgroup Total (GB) Util (GB) Libre (GB) %Util "

echo "======================================================================"

$GRID_HOME/bin/asmcmd lsdg $x | \

awk -v sq="'" 'BEGIN { getline } {

printf" %s \t %11"sq"d \t %9"sq"d \t %8"sq"d \t %3d%% \n",$13,$7/1024,($7-$8)/1024,$8/1024,100-100*($8/$7)

echo

if [[ $v_profile == /dev* ]]; then

echo " Disque(s) Taille (MB) Taille (GB) "

echo "======================================================================"

/usr/bin/diff <($GRID_HOME/bin/kfod asm_diskstring='/dev/oracleasm/disks/*' group=$x) <($GRID_HOME/bin/kfod asm_diskstring='/dev/oracleasm/disks/*' group=#) | \

awk -v sq="'" 'BEGIN { getline } {

printf" %s \t %10"sq"d \t %11"sq"d \n",$5,$3,$3/1024

}' | grep DISK

else

echo

echo " Disque(s) Taille (MB) Taille (GB) "

echo "======================================================"

echo

/usr/bin/diff <($GRID_HOME/bin/kfod asm_diskstring='ORCL*' group=$x) <(kfod asm_diskstring='ORCL*' group=#) | \

awk -v sq="'" 'BEGIN { getline } {

printf" %s \t %10"sq"d \t %11"sq"d \n",$5,$3,$3/1024

}' | grep DISK

echo

done

printf '\033[32m' #couleur verte

printf '\033[4m' #Souligner phrase

echo -e "Disque(s) n'appartenant a aucun diskgroup:"'\033[0m';

printf '\033[0m' #Annuler couleur verte

nb=`$GRID_HOME/bin/kfod asm_diskstring='/dev/oracleasm/disks/*' group=# | grep DISK |wc -l` #nombre de disques n'appartenent a aucun diskgroup

if [ "$nb" -ge 1 ]; then

echo

echo " Disque(s) Taille (MB) Taille (GB) "

echo "======================================================================"

$GRID_HOME/bin/kfod asm_diskstring='/dev/oracleasm/disks/*' group=# | \

awk -v sq="'" 'BEGIN { getline } {

printf" %s \t %10"sq"d \t %11"sq"d \n",$4,$2,$2/1024

}' | grep DISK

echo

else

echo

echo "Il n'existe aucun disque libre dans cet environnement"

echo

else # Il n'y a pas de process pmon pour asm, l'instance asm n'est donc pas demarree.

printf '\033[31m' #couleur rouge

echo "********************************************************************"

echo "***** Desole, l'instance ASM n'est pas demarree sur ce noeud ! *****"

echo "********************************************************************"

printf '\033[0m' #Annuler couleur rouge

Exemple de résultat obtenu:

[oracle@svr_host ]$ ./asm_kfod.ksh

Diskgroup: DATA

Diskgroup Total (GB) Util (GB) Libre (GB) %Util

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

DATA/ 400 86 313 21%

Disque(s) Taille (MB) Taille (GB)

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

/dev/oracleasm/disks/DISK_AL9 409,626 400

Diskgroup: DATA11G

Diskgroup Total (GB) Util (GB) Libre (GB) %Util

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

DATA11G/ 2,800 481 2,318 17%

Disque(s) Taille (MB) Taille (GB)

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

/dev/oracleasm/disks/DISK_AL1 409,626 400

/dev/oracleasm/disks/DISK_AL2 409,626 400

/dev/oracleasm/disks/DISK_AL3 409,626 400

/dev/oracleasm/disks/DISK_AL4 409,626 400

/dev/oracleasm/disks/DISK_AL5 409,626 400

/dev/oracleasm/disks/DISK_AL6 409,626 400

/dev/oracleasm/disks/DISK_AL7 409,626 400

Diskgroup: FRA

Diskgroup Total (GB) Util (GB) Libre (GB) %Util

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

FRA/ 400 41 358 10%

Disque(s) Taille (MB) Taille (GB)

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

/dev/oracleasm/disks/DISK_AL10 409,626 400

Diskgroup: FRA11G

Diskgroup Total (GB) Util (GB) Libre (GB) %Util

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

FRA11G/ 400 17 382 4%

Disque(s) Taille (MB) Taille (GB)

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

/dev/oracleasm/disks/DISK_AL8 409,626 400

Diskgroup: OCR_VOTE

Diskgroup Total (GB) Util (GB) Libre (GB) %Util

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

OCR_VOTE/ 20 0 19 1%

Disque(s) Taille (MB) Taille (GB)

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

/dev/oracleasm/disks/DISK_AL11 10,240 10

/dev/oracleasm/disks/DISK_AL12 10,240 10

Disque(s) n'appartenant a aucun diskgroup:

Il n'existe aucun disque libre dans cet environnement

Hope it helps...

jeudi 25 juillet 2013

OEM 12c - Archivage excessif après migration de la version 12cR1 vers 12cR2

J'ai rencontré récemment un problème avec la base de données du référentiel d'oem 12c.
Après avoir migré de la version OEM 12cR1 (12.1.0.1.0) vers OEM 12cR2 (12.1.0.2.0) la base de données du référentiel s'est mise à générer un nombre excessif d'archives.
Ce qui avait pour effet de remplir très rapidement l'espace alloué à cet effet et de faire planter la base de données. J'ai appliqué le PSU 14840279 pour obtenir la version 12.1.0.2.1, mais le problème n'a pas été réglé. Après quelques recherches je me suis rendu compte qu'il s'agissait d'un bug connu.

Pour corriger le problème il faut appliquer le Patch 14833587 au home de l'OMS.
Ce patch est aussi inclus dans le PSU 14840279, donc dans mon cas je n'avais pas besoin de l'appliquer.

D'ailleurs, appliquer le patch ne règle pas systématiquement le problème puisque le mal est déjà fait. En effet, dans mon cas la table em_job_metrics contenait déjà des millions d'enregistrements et c'est le travail de nettoyage qui générait les archives.
Après avoir appliqué le patch ou le PSU, il faut vider la table EM_JOB_METRICS.
Il est important de faire le "truncate" une seule fois.

SQL> truncate table em_job_metrics;

Pour plus de détails, voir le document:
12c Cloud Control: Redo Logging is Drastically Increased in the Repository Database After Upgrade to 12.1.0.2 (PS1) and EM_JOB_METRICS Table is Very Large in Size (Doc ID 1502370.1)

Hope it helps...