Mémoire insuffisante occasionnée par un bug de l'analyseur (parser) XML

Lors du traitement de contenu XML, une erreur de mémoire insuffisante a été rencontrée. Le message d’erreur exacte est le suivant :

ORA-27163: mémoire insuffisante

ORA-06512: à "SYS.XMLTYPE", ligne 272

ORA-06512: à ligne 1

ORA-06512: à ligne 15

Après avoir diagnostiquer le problème, nous avons trouver une solution de contournement sur MOS (My Oracle Support). Il suffit d'exécuter cette commande pour désactiver la nouvelle version du parser XML et d'utiliser plutôt l'ancienne :

Alter session set events='31156 trace name context forever, level 0x400';

Ce problème a été rencontré sous Oracle Database 11.2.0.3.6 sur un plateforme Red Hat Enterprise Linux 64bits.

OOW 2010 - Jour 2

Aujourd'hui ce fut encore une fois une journée bien remplie. J'ai eu droit à plusieurs conférences sur des nouveautés et quelques unes à propos de l'optimisation.

Depuis que je suis ici, il y a un mot qui revient sans cesse. Que se soit Oracle, les partenaires, les exposants, etc... ils l'utilisent à profusion. C'est sans contredit, la tendance. Le mot en question est " cloud ". Donc, je ne pense pas me tromper en prédisant que la prochaine version de la base de données, qui sera la version 12, sera suivi de la lettre " c " au lieu de la lettre " g ". Alors, préparez-vous à voir " Oracle 12C " très bientôt ! :)

Avis à ceux qui font une collection de t-shirts, OOW est LA place. Tous les exposants font des pieds et des mains pour nous offrir des t-shirts gratuitement. Il vous suffit de remplir un mini sondage et voilà !

Il y a un conférencier qui à dit ce qui suit et je suis particulièrement d'accord avec lui :
" Trop souvent les gens (DBA, développeurs, etc...) n'exploitent pas les fonctionnalités offertes par les nouvelles versions. Les gens sont souvent trop conservateurs. Il faut laisser place aux nouveautés puis prendre le temps de les découvrir ".


Edition Based Redefinition (EBR)

Cette nouvelle fonctionnalité permet de mettre en place sur une même base de données différentes versions d'objets d'un schéma appartenant à une application tels que les procédures, fonctions, packages, triggers, vues et synonymes. Elle permet de mettre à jour une application sans interruption. En d'autres mots, c'est une solution de haute disponibilité pour le PL/SQL. Voici d'autres points d'intérêt :

• C'est gratuit (je suis sérieux!) et inclut avec toutes les éditions d'Oracle
• Les éditions sont complètement indépendantes l'une de l'autre et ils coexistent, donc le retour arrière est simple et rapide.
• L'édition par défaut s'appelle : ORA$BASE
• Nouveau privilège : ENABLE EDITION
• Trois nouveaux objets : Edition, Editioning view et Crossedition trigger
• Plusieurs nouvelles vues du dictionnaire ont été créées pour répondre au mode Edition. Par exemple, il faut consulter les vues avec le suffixe " _AE ", qui signifie " All Edition " pour voir tous les objets de toutes les éditions.
• Pour simplifier la gestion des éditions pour une application, il suffit de créer une vue par table ayant le même nom. Préalablement, les tables doivent toutes être renommées. Donc, vous comprendrez que l'application accèdera maintenant aux vues au lieu des tables.
• Lors de la création d'une édition (CREATE EDITION), tous les objets de l'application sont créés automatiquement dans la nouvelle édition.
• Les triggers de type " crossedition " sont optionnels et peuvent être utilisés pour de la conversion de données.
• Les services de bases de données peuvent être reliés à une édition particulière.
• La fonction SYS_CONTEXT permet d'afficher l'édition en cours
• La commande ALTER SESSION permet de passer d'une édition à une autre.

Avec un peu de recul, je me dis que cette merveilleuse fonctionnalité va être un cauchemar pour les DBA car nous risquons d'assister à une explosion d'objets. Je crois qu'un contrôle rigoureux devra être effectué puis des règles d'épuration seront nécessaires suite à la création de nouvelles éditions.

Je vous invite à consulter le site suivant pour plus de détails : www.morganslibrary.org. Sur ce site, vous y trouverez des scripts très utiles pour la création d'une édition.

Et pour terminer, voici les principales étapes à une approche à la résolution de problème :

• Ne pas chercher seulement sur la base de données, mais sur l'ensemble des composantes qui sont impliqués
• Effectuer un changement (correction) à la fois
• Utiliser les bons outils pour diagnostiquer et corriger
• Documenter les changements et les impacts
• 2 étapes de résolution :
  
• Correction rapide : La résolution du problème n'élimine pas nécessairement toujours le problème. On pourrait appeller cela une solution de contournement
• Correction définitive : Chercher à régler le problème une fois pour toute
• Prendre le temps de comprendre pourquoi le problème est survenu
• Accepter que la cause du problème ne soit pas toujours trouvée

Enlever un énoncé SQL de la cache (SHARED POOL)

Voici un script que j'utilise pour supprimer une requête (énoncé SQL) de la cache partagée nommé "shared pool". Ce script est fort utile lorsque vous effectuez du "tuning" de requête.

REM *******************************************************************
REM * Script: FlushSQL.sql
REM * Titre : Chercher et générer la commande pour enlever un énoncé
REM * SQL du SHARED POOL
REM * Auteur: Eric Cloutier
REM * Date modif. : 15-06-2010
REM * Parametres :
REM * Aucun
REM *******************************************************************
set pagesize 9999 feed off linesize 200 trimspoo on verify off
--
-- Sous 10g (10.2.0.4) :
-- Alter session set events '5614566 trace name context forever';
--
spool FlushSQL.log

Accept sql_text prompt 'Inscrire une partie de la requête (LIKE est utilisé alors inscrire %): '

col cmd_sql format a80
col username format a20
col executions format 999999
col sql_text format a30 wrap

select 'exec sys.dbms_shared_pool.purge('''||address||','||hash_value||''',''C'',1);' cmd_sql,
sql_id, child_number, executions, u.username, sql_text
from v$sql s, dba_users u
where upper(sql_text) like upper(nvl('&sql_text',sql_text))
and sql_text not like '%from v$sql where sql_text like nvl(%'
and u.user_id = s.parsing_user_id
/

spool off
set feed on linesize 5000
Prompt
Prompt -- Résultat dans le fichier : FlushSQL.log
Prompt

Cette fonctionnalité peut être utilisé en 10g (10.2.0.4) cependant, vous devez initialiser un "event" soit à la session ou au niveau de la base de données que qu'elle fonctionne.

Un merci particulier à Kerry Osborne pour son blog.

Manipuler avec soins car contient des paramètres standards, cachés et Hints

L'une des premières vérifications que je vous suggère fortement de faire lorsque vous effectuez de l'optimisation de requêtes est de vérifier la valeur des paramètres de bases de données qui ont été personnalisées (modifiées).

Dans plusieurs cas que j'ai rencontrés, surtout dans le cadre de projet de migration, certains paramètres avaient été modifiés pour contourner des problèmes (bugs) et, suite à la migration, ceux-ci sont la plupart du temps plus nécessaires.

Utiliser la commande "ALTER SESSION" pour ceux qui sont modifiable dynamiquement. Vous pourrez vérifier le comportement de vos requêtes avant d'appliquer le changement de façon permanente (ALTER SYSTEM) sur la base de données.

Autres conseils, évitez de modifier les paramètres de base de données, surtout ceux cachés. Vous aurez des problèmes lors des futures migrations. Si vous n'avez pas le choix, je vous conseille de bien documenter leur utilisation.

C'est la même situation pour les HINTS de requêtes, ce n'est que des diachylons et… souvenez-vous qu'un diachylon fini toujours par se décoller :)