À ne pas mettre avant la commande "BACKUP"

En voulant prendre une copie de la commande de création du "Controlfile" de la base de données dans un script RMAN, je me suis aperçu que la série de commandes n'était pas générée dans le fichier de trace.

Après quelques essais, je me suis rendu compte que si la commande "BACKUP..." suit directement la commande "ALTER DATABASE BACKUP CONTROLFILE...", le fichier de trace se créer sans contenir les commandes SQL.

Donc. j'ai tout simplement déplacé la commande SQL à la toute fin :

run
{
BACKUP DATABASE FILESPERSET 1 PLUS ARCHIVELOG;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";
}

Ceci a été observé en effectuant une sauvegarde d'une base de données Oracle 10G Express Edition (XE) sous Linux RHEL4 sans catalogue RMAN.

Outil de désinstallation d'Oracle 11gR2

Depuis la version 11gR2, Oracle rends disponible un outil de désinstallation. Ce dernier est situé dans "$ORACLE_HOME/deinstall" et il peut être téléchargé à partir du site d'Oracle au même endroit qu'on retrouve les fichiers pour la base de données.

L'outil de désinstallation effectue vraiment tout. Il supprime Oracle Clusterware, Oracle Automatic Storage Management (ASM), et Oracle Real Application Clusters (Oracle RAC) ou, une installation de base de données Standalone.

L'outil effectue toutes les actions nécessaires lors de la suppression du logiciel à partir d'un ORACLE_HOME. Il identifie toutes les instances associées à un ORACLE_HOME et il s'occupe d'arrêter tous les processus pour ensuite, supprimer toutes les composantes incluant les "listeners".

Pour l'exécuter, il suffit de mentionner au minimum l'ORACLE_HOME que vous désirez supprimé. Voici un exemple :

$ORACLE_HOME/deinstall/deinstall -home /u01/app/oracle/product/11.1.0/db_1

Vous pouvez utiliser le paramètre "checkonly". Ce dernier est fort utile car il fait le même traitement cependant, il ne supprime aucune composante :

$ORACLE_HOME/deinstall/deinstall -home /u01/app/oracle/product/11.1.0/db_1 -checkonly

Bon ménage à tous !

OOW 2010 – Database Track – Jour 4…le dernier!

C'est peut-être le dernier jour mais non le moindre en fait de contenu. Aujourd'hui, j'ai eu droit à des conférences sur l'optimisation avec les outils ASH et AWR et, une autre à propos d'Oracle Active Data Guard. Comme toutes les autres sessions, elles furent très intéressantes et remplies d'informations pertinentes.

La première conférence était présentée par nul autre que Thomas Kyte. Disons que ça commence bien la journée! Comme d'habitude, il a su me captiver dès la première seconde et ce, jusqu'à la toute dernière.

Ce que j'ai particulièrement aimé (et que j'aimerai probablement toujours), c'est les façons d'effectuer de l'optimisation à partir de simples lignes de commandes avec un outil tel que SQL*Plus. Les raisons sont bien simples car en mandat nous n'avons pas toujours recours à des outils graphiques et, aussi, j'aime voir les commandes exécutées et les résultats. Je ne suis pas trop fervent des boites noirs par lesquels une multitude de commandes sont exécutées sans que nous ne sachions ce qui est accomplis.

Alors, voici quelques faits à propos d'ASH ainsi qu'AWR :

ASH

• ASH = Active Session History
• ASH est toujours actifs, donc, lorsqu'un problème survient, on peut directement s'y référer puis comparer les valeurs actuelles avec celles précédant le problème.
• Simplifie l'investigation car autrement un problème peut être difficilement reproduit
• Ce mécanisme accède directement à la structure du noyau de la base de données
• Ne contient pas tous les énoncés SQL qui ont été exécutés. On y retrouve seulement ceux qui ont été actifs et qui sont plus " gourmands "
• Un échantillon d'énoncé SQL actif est collecté à chaque seconde en mémoire. Le processus " MMON Lite (MMNL) " s'occupe d'accomplir cette tâche.
• L'échantillon est conservé dans une cache (buffer) circulaire dans le SGA. Par défaut, il a la dimension de 2 MB par CPU (consulter la vue V$SGASTAT pour la taille totale utilisée)
• Les données d'ASH sont principalement consultées via la vue V$ACTIVE_SESSION_HISTORY
• Une partie de l'échantillon utilisé par ASH alimente l'AWR
• Permet d'effectuer une analyse basée sur le temps de traitement sur la base de données (DB Time)
• Les données proviennent principalement des vues V$SESSION et V$SESSION_WAIT
• Si nous effectuons la somme des secondes d'ASH, nous obtiendrons le " DB Time "
• La page " Top Activity " dans Oracle EM est basée sur les données d'ASH. Le pourcentage d'activité correspondant à un énoncé SQL correspond au pourcentage du " DB Time "
• Il ne faut pas utiliser des fonctions telles que MIN, MAX et AVG avec les données provenant d'ASH car les résultats seront biaisés. Les données proviennent d'échantillon et les longs traitements fausseront les résultats.
• Le contenu d'ASH peut être exporté puis chargé dans une table ou un chiffrier
• ASH n'est pas un résultat de trace mais plutôt de l'échantillonnage

AWR

• AWR = Automatic Workload Repository
• AWR est présent dans toutes les éditions de base de données
• Il est constitué de statistiques de base (ex. physical reads), de statistiques sur les énoncés SQL (disk read par SQL), mesures (physical reads/seconde) et d'information (échantillon) provenant d'ASH.
• Un cliché (snapshot) provient d'un processus qui extrait les données de la mémoire puis qui les écrient sur disque.
• Ne jamais comparer deux clichés dont un redémarrage de base de données a eu lieu durant la période couverte par les clichés
• Le package DBMS_WORKLOAD_REPOSITORY permet de gérer l'AWR
• La rétention par défaut est de 7 jours, Oracle supprime automatiquement les données plus anciennes. Il est recommandé (bonne pratique) de conserver un minimum d'un mois.

En conclusion, Oracle Open World fut une expérience formidable. J'ai grandement apprécié les conférences. Je fus très impressionné par l'ampleur de l'événement. Bravo à Oracle et je leur dit : " Two Thumbs Up "

OOW 2010 - Jour 3

Trop souvent les entreprises négligent complètement la prise de copie de sécurité et, ceux qui en prennent, négligent les essais de recouvrement. Pourquoi les gens aiment tant jouer avec le risque ? Personnellement, ça me renverse! Jamais je ne pourrais avoir la conscience tranquille tant et aussi longtemps que je n'aurais pas effectué des copies de sécurité et réaliser des scénarios de recouvrement. Ceci devrait être la ou l'une des premières règles qu'un DBA devrait suivre. D'autant plus, pouvez-vous bien me dire pourquoi qu'il y a tant d'entreprises qui n'utilisent pas RMAN ? Cet utilitaire a fait ses preuves depuis plusieurs années et aucun autre utilitaire ne peut être aussi fiable que lui.

Je vous parle de sauvegarde et de recouvrement car aujourd'hui, j'ai eu l'opportunité d'assister à des conférences au sujet de " Recovery Manager ". Le premier conférencier nous à présenter une multitude de scénarios de recouvrement. Certains dont je classifierais de classique et d'autres plutôt tordus qui ne sont pas supporté par Oracle. Ces derniers sont plutôt pratiques quand nous n'avons vraiment pas le choix et qu'il faut ressusciter une base de données. Voici ce qui peut être utile pour effectuer un recouvrement incomplet et forcer l'ouverture de la base de données :

• _ALLOW_RESETLOGS_CORRUPTION=TRUE
• _CORRUPTED_ROLLBACK_SEGMENTS=(RBS1,RBS2,..)
• UNDO_MANAGEMENT=MANUAL
• EVENT = "10015 TRACE NAME ADJUST_SCN LEVEL 1"

Quand il n'y a vraiment plus de possibilité alors vous pouvez vous en remettre au support d'Oracle puis utiliser " Data Unloader (DUL) ". Cet utilitaire permet de lire les données directement dans les fichiers de données sans passer par le noyau d'Oracle.

Autres points d'intérêt abordés lors des conférences :

• Il est possible de recréer un fichier de paramètre (pfile) à partir de la mémoire. Il suffit d'exécuter la commande " CREATE PFILE " et spécifier à la toute fin " FROM MEMORY ".
• DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER() retourne le SCN en cours de la base de données.
• Il est possible de restaurer un fichier de données lors de la perte de celui-ci et que vous n'avez pas de sauvegarde de ce fichier. Si le fichier de données est inscrit dans le fichier de contrôle, la commande RESTORE créée le fichier de données dans l'emplacement d'origine et la commande RECOVER applique les journaux nécessaires pour le fichier de données.
• Si vous soupçonnez une corruption de blocs de données, DBVERIFY est un utilitaire qui effectue une vérification de l'intégrité de la structure des données physiques sur une base de données.
• La commande BLOCKRECOVER peut restaurer et récupérer des blocs individuels au sein d'un fichier de données. Cette procédure est utile quand seulement un petit nombre de blocs sont corrompus.
• Le package DBMS_BACKUP_RESTORE est utilisé comme une interface PL/SQL en ligne de commande pour le remplacement des commandes natives RMAN.

Oracle ORION
Oracle ORION est un outil pour vérifier les performances de type I/O pour les systèmes de stockage qui sont destinés à être utilisés pour les bases de données Oracle. Les résultats obtenus sont utiles pour comprendre les capacités de performance d'un système de stockage, soit pour découvrir les causes qui pourraient influer sur le rendement d'une base de données Oracle. ORION est un outil autonome, on n'a pas à créer et d'exécuter une base de données Oracle pour l'utiliser.


Pour le plaisirs, je vous invite à regarder les vidéos suivants sur youtube.com :

• Iron Man: Man. Machine. Hero. Oracle. Software. Hardware. Complete. (http://www.youtube.com/watch?v=L5cO2R-b39M)
• Exadata Iron Man display at Oracle Open World 2010 (http://www.youtube.com/watch?v=nzZs2SlJuGA)
  
• As we waited to enter Hall D for the Welcome Keynotes we were entertained by a display of the Iron Man / Oracle teaser trailers plus the actual suits from the movie. (http://www.youtube.com/watch?v=pBW5napyM80)
  
• Highlights from Oracle CEO Larry Ellison's welcome keynote at Oracle OpenWorld 2010 on Sunday September 19 (http://www.youtube.com/watch?v=tWB0fR-buJ4)
• OpenWorld's 2010 Welcome Keynote ended with Larry's announcement. Leaving Hall D (http://www.youtube.com/watch?v=mYEmjp3Bpdc)

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

En direct d'OOW 2010

Vu ma présence à Oracle Open World à San Francisco, j'ai décidé de vous faire profiter des informations que j'ai reçues. Je n'irai certainement pas dans les détails car ça serait très fastidieux et, de plus, je n'ai assurément pas toutes les informations. Par contre, j'espère que cela vous informera suffisamment pour que vous soyez en mesure de rechercher plus de détails sur les sujets que j'aborde.


Weblogic Suite

• La suite Weblogic ne cesse de s'améliorer de version en version. Et, c'est bien réel car le produit est de plus en plus complet et stable.
• Weblogic Server pour développeurs sera supporté sous MAC OS X
• JRockit Virtual Edition (VE) est utilisé au lieu d'un " guest OS ". En plus d'être beaucoup plus simple et sécuritaire, il est 30% plus performant.
• Oracle Virtual Assembly builder tool est un nouvel outil permettant de cataloguer toutes les VM utilisées. Cet outil permettra de concevoir des graphiques, comme de la modélisation, pour répertorier les VM utilisées dans votre infrastructure tout en précisant diverses propriétés générales ainsi que des informations concernant le déploiement.
• Glassfish, vous connaissez? C'est un logiciel " open source " très populaire. Ce dernier est très léger et c'est la référence en termes d'implantation Java EE 6 ainsi que Java EE 7. La version 3.1 reviendra avec le clustering qui avait été délaissé avec la version précédente.

Performance

Fermé les curseurs!!! Souvent, les développeurs conçoivent des unités de traitements sans tenir compte que ceux-ci restent ouverts et qu'ils ne sont plus utilisés. Savez-vous que le nombre de curseurs pouvant être ouvert est configurable via un paramètre sur une base de données et que ceux-ci consomment de la mémoire. Et, bien, maintenant, vous le savez ;)

Il ne faut pas négliger l'utilisation du partitionnement, de la compression, du parallélisme, des différents types de jointure, des types de tri, etc… Ces sont des fonctionnalités qui doivent être exploitées afin d'optimiser tous les traitements des applications que vous utilisez. Par exemple le partitionnement permet de regrouper les données selon une clé particulière telle que le temps ou une région. Lors de l'accès de ceux-ci, vous en bénéficierez car il y aura moins de temps d'attente et surement moins de lecture sur disques. De plus, on n'est pas obligé d'appliquer le partitionnement sur une méga grosse table.

Autres points à propos des types de jointures, pour ceux qui ne sont plus sous Oracle 9i, sachez que le " hash join " est bien souvent plus performant que le " sur utilisé " Nested Loop ". Ceci s'applique principalement lorsque plusieurs données de deux tables doivent être mise en jointure.

Lors de l'optimisation de requête, on devrait vérifier le nombre de données qui devra être obtenu indirectement pour que la requête soit complétée au lieu du nombre de rangées que la ou les tables contiennent dans l'énoncé SQL que nous tentons d'optimiser.


Exalogic Elastic Cloud

Voici le nouveau terme que vous entendrez parler dans les prochains jours à venir. Larry Ellison en a fait son sujet lors de l'ouverture d'Oracle Open World. Selon l'annonce qu'il a fait, ce sera le " Data Center " du 21ème siècle. C'est une solution complète impliquant les logiciels (software) et le matériel (hardware) qui ont été conçu pour travailler ensemble. Si vous fouillé le Web, je suis persuadé que bien des infos doivent courir entre autres sur Tweeter.


SQL Performance Analyser (SPA)

Cette fonctionnalité fait partie de " Real Application Testing ". Il n'est pas gratuit mais il procure une réelle assurance lorsque vient le temps d'appliquer des changements sur un environnement de production. SQL Performance Analyser peut être utilisé avec Oracle Dataguard. Cela vient de donner une valeur ajoutée à Dataguard.

SPA devrait être utilisé peu importe la nature du changement comme lors d'un changement de plateforme, de serveur, de type de stockage (ASM), nouvelle collecte de statistiques, migration vers une nouvelle version, et bien d'autres.

Nous avons eu droit à des cas vécus de " DirectTV " et " Bank of America ". Leurs expériences ont démontrés que l'utilisation de SPA fut très bénéfique. Celui-ci a permit d'identifier les impacts de la migration sur leurs applications et d'appliquer les changements qui s'imposaient. Les points qui ont ressortis sont :

• Limitation sur les " bind variables "
• Analyse des requêtes rapides et efficaces
• Un minime changement peut avoir un impact majeur
• Extraction des requêtes les plus fréquentes
• Comparaison par la statistique " buffers get " et le nombre d'exécution
• Conversion de trace SQL en SQL Tuning Sets (STS)

Recouvrement suite à une copie en mode "begin backup"

Pour répliquer rapidement un environnement complet, nous utilisons le logiciel "ShadowImage". Cette opération permet de créer une image complet d'un serveur pour ensuite diagnostiquer des problèmes majeurs survenu sur cet environnement.

L'environnement répliqué consiste à un serveur Sun Solaris 10 sur lequel réside une base de données 10gR2 Enterprise Edition.

Pour que la cpoie répliquée de la base de données soit fonctionnelle, nous mettons celle-ci en mode "begin backup" avant de démarrer le processus de copie. Malgré cela, une fois que le processus est terminé, nous rencontrons des problèmes avec la base de données copiée. Voici les problèmes rencontrées avec leurs solutions :

Recouvrement du tablespace SYSTEM
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/uprodz2-obd001_u02/oradata/P059/system01.dbf'

Mettre la base de données en mode "mount" :

sqlplus / as sysdba
shutdown immediate
startup mount

2 scénarios possibles :

1. Recouvrement à partir d'un copie de sécurité des controlfiles

1.1 Récupérer des anciens CONTROLFILE qui furent générés par la commande :

alter database backup controlfile
to '/u01/home/dba/oracle/admin/ORCL/udump/control.2010-09-16-09:00.bkp';

prendre un copie du controlfile puis copier le backup controlfile aux 2 endroits

1.2 Recouvrer la base de données à l'aide des controlfiles récupérés

Recover database until time '2010-10-15 09:00:00' using backup controlfile;
OU
Recover database using backup controlfile until cancel;

Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement

1.3 Ouvrir la base de données

alter database open resetlogs;

il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".

2. Recouvrement à partir des controlfiles courants (actuels)

2.1 Recouvrer la base de données avec la commande suivante à partir des controlfiles actuels

Recover database until time '2010-10-15 09:00:00' using backup controlfile;

Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement

2.2 Ouvrir la base de données

alter database open resetlogs;

il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".


Corruption du tablespace UNDO

Lors du démarrage de la base de données, si celle-ci tarde beaucoup à démarrer ou que le démarrage renvoi une erreur ORA-600 avec l'argument [4194], c'est probablement occasionné par une corruption dans les segments du tablespace " undo ".

Avant de procéder tel qu'indiqué, assurez-vous que le fichier " alert_ORCL.log " contient bel et bien des lignes affichant le code d'erreur mentionné précédemment.

Compte tenu que le contenu du tablespace " undo " sert à conserver les transactions non sauvegardées (non commit), on peut détruire ces données sans danger. Voici les étapes pour recréer le tablespace " undo " :

sqlplus / as sysdba

Alter database open;

create undo tablespace undo2
datafile '/u05/oradata/ORCL/undo02.dbf' size 50 m
autoextend on;

alter system set undo_tablespace = undo2 ;

drop tablespace undo including contents and datafiles ;

create undo tablespace undo
datafile '/u05/oradata/ORCL/undo01.dbf' size 1000 m
autoextend on ;

alter system set undo_tablespace = undo ;

drop tablespace undo2 including contents and datafiles ;

Pour réaliser les commandes précédentes, il se peut que vous soyez dans l'obligation de désactiver la gestion automatique des segments " undo " :

sqlplus / as sysdba
startup mount
create pfile from spfile;

Modifier le paramètre suivant dans le fichier " initORCL.ora " :
undo_management = MANUAL

shutdown immediate
startup pfile=initORCL.ora

Une fois l'intervention terminée, n'oubliez pas de revenir en mode "spfile".


Il y a un autre cas, que l'un de mes collègues a rencontré. Il a eu à recréer les controlfiles pour ressusciter la base de données.

Machine Virtuelle pré-installée avec la suite SOA et BPM 11g

Tout dont vous avez besoin est d'installer Oracle VirtualBox sur votre ordinateur et importer l'application SOA/BPM et vous êtes prêts à essayer SOA 11g incluant BPM 11g récemment sortie. Aucune installation et configuration particulière. Simple n'est-ce pas !

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

Add-on intéressant pour Microsoft Excel

J'ai mis la main sur un "add-on" qui s'installe en tant que macro complémentaire dans Microsoft Excel.

Cet "add-on" s'appelle "Query Editor". Il permet de configurer d'une façon simple un accès à une source de données externes telle qu'une base de données Oracle.

Tout est plus intuitif. Par un simple clic-droit de la souris, nous accédons à l'éditeur de requêtes. Cette fenêtre contient toutes les paramètres et les champs nécessaires pour réaliser une requête.


Pour ceux qui utilise Excel pour réaliser des rapports, je vous le recommande. Vous l'aimerez !

Concepteur : Rob van Gelder (rob@vangelder.co.nz)
Site Web : http://vangelder.orconhosting.net.nz/excel/queryeditor.html

Recompilation de packages PL/SQL sous Oracle RAC 11gR2

Suite à la mise en place d'une nouvelle version d'un package PL/SQL, certaines applications obtenaient l'erreur suivante :

ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04065: not executed, altered or dropped stored procedure "ABC.PKG_CALC_PAMNT"
ORA-06508: PL/SQL: could not find program unit being called: "ABC.PKG_CALC_PAMNT"
ORA-06512: at "ABC.PKG_FACTRN", line 4

Habituellement, cette erreur disparait dès le prochain accès au package. C'est le cas pour la session active sauf que, lorsqu'il y avait une nouvelle connexion avec le même compte Oracle, l'erreur réapparaissait.

Étrangement, cette erreur ne se produisait pas pour certaines applications... pourquoi? Et bien, c'est surement parce que nous utilisons les services Oracle pour la répartition de la charge sur les différents noeuds hébergeant les instances du Cluster RAC 11gR2. Compte tenu que cette erreur était, disons-le, absurde, j'ai commencé à douter de la "fraîcheur" des caches en mémoire. Après quelques essais, je me suis rendu compte que le problème survenait sur une instance et non sur les autres. J'ai alors décidé de forcer une réinitialisation du "shared pool" pour que la nouvelle définition de l'objet y soit stockée. Pour ce faire, j'ai exécuté la commande : "Alter system flush shared_pool;" et, effectivement, l'erreur n'a par réapparu.

Actualisation d'une vue matérialisée avec l'option "parallel"

En tentant de mettre en place une tâche via Oracle Scheduler qui effectue le rafraichissement d'un groupe de vues matérialisées, j'obtenais une erreur qui sentait le "service request" à plein nez !

ORA-07445: exception encountered: core dump [_memcpy()+264] [SIGSEGV] [ADDR:0x0] [PC:0xFFFFFFFF7C500908] [Address not mapped to object] []

Ce genre d'erreur n'augure jamais bien. Après avoir fouillé et effectué un ensemble de tests, j'ai réussi à identifier la vue matérialisée qui causait l'erreur. Elle comportait des colonnes dont le type de données est SDO_GEOMETRY (Oracle Spatial) et la source de celle-ci se trouve sur une base de données distante. Voilà, des particularités intéressantes...

Après avoir googolisé le Net de bout en bout, je me suis souvenu que la manipulation des données spatiales sont souvent capricieuses. J'ai alors réalisé qu'en enlevant les colonnes de la vue, je pouvais actualiser (refresh) la vue matérialisée avec succès.

Avec un peu de recul, je me suis dit : "Utilisons une commande simple qui n'utilisera pas des fonctionnalités qui pourrait augmenter les chances de provoquer des erreurs". La commande CREATE MATERIALIZED VIEW utilisait le parallélisme.... Hmmm... Spatial et parallélisme... Une autre belle particularité ! Essayons NOPARALLEL, juste pour voir. Eh bien, devinez quoi? L'actualisation de la vue matérialisée a fonctionné.

Dans mon cas, le parallélisme n'est vraiment pas obligatoire donc, je peut m'en passer sans problème. Par contre, comme je le disait plus tôt, il y a sûrement place à créer un SR chez Oracle pour identifier la cause.

La boîte virtuelle d'Oracle

Suite à l'acquisition de la compagnie Sun, Oracle a mis la main sur l'outil permettant de créer et gérer des machines virtuelles (VM). Cet outil s'appelle Virtualbox et sa plus belle qualité est qu'il est gratuit.

J'ai eu la chance de m'amuser avec l'outil et jusqu'à présent, je dois vous dire que je l'apprécie énormément. J'ai pu créer quelques machines virtuelles fonctionnant sous Linux (Oracle Enterprise Linux 5) et actuellement, je tente d'installer un cluster Oracle 11gR2 composé de deux noeuds et un troisième noeud simulant une unité de stockage (SAN). Ce dernier me permettra de configurer des "raw devices" sous Oracle ASM.

Les machines virtuelles sont une belles façon d'expérimenter les produits ainsi que les nouveautés. En quelque sorte, ça devient de réels bacs à sables ou si vous préférez, des terrains de jeux.

Sur Internet, vous trouverez plusieurs informations à propos de Virtualbox tels que des articles (blog), des tutoriels pour procéder à divers installations de systèmes d'exploitation et de logiciels Oracle. Je vous suggère de visiter les adresses suivantes :

• Guide d'installation d'Oracle Virtualbox
  
• Wiki-Oracle - Installation Oracle RAC 11gr2 sur MAC
  
• Oracle Technology Network Developer Day - Hands-on Database Application Development
  

Le lien concernant Oracle Technology Network vous permet de télécharger une VM complète qui contient les éléments suivants :

• Oracle Enterprise Linux 5
• Oracle Database 11g Release 2 Enterprise Edition
• Oracle TimesTen In-Memory Database Cache
• Oracle XML DB
• Oracle SQL Developer
• Oracle SQL Developer Data Modeler
• Oracle Application Express 4.0
• Oracle JDeveloper
• Hands-On-Labs (accessed via the Toolbar Menu in Firefox)
  

Alors, vous n'avez plus de raisons pour ne pas vous amuser ! ;)

Impact des contraintes étrangères sur la performance

Il y a quelques temps, Tom Kyte a effectué un essai pour vérifier l'impact d'une clé étrangère lors de l'insertion de plus de 37 000 rangées.

L'essai consiste à effectuer deux insertions dans deux tables dont l'une d'elle a une clé étrangère :

SQL> alter session set sql_trace=true;
Session altered.
SQL> declare
2 type array is table of varchar2(30) index by binary_integer;
3 l_data array;
4 begin
5 select * BULK COLLECT into l_data from cities;
6 for i in 1 .. 1000
7 loop
8 for j in 1 .. l_data.count
9 loop
10 insert into with_ri 11 values ('x', l_data(j) );
11 insert into without_ri values ('x', l_data(j) );
12 end loop;
13 end loop;
14 end;
15 /
PL/SQL procedure successfully completed.

Le rapport basé sur le fichier de trace généré par l'utilitaire " TKPROF " est le suivant :

INSERT into with_ri values ('x',:b1 )

call count cpu elpsed disk query current rows
------- ------ ---- ------ ---- ----- ------- -----
Parse 1 0.00 0.02 0 2 0 0
Execute 37000 9.49 13.51 0 566 78873 37000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ ---- ------ ---- ----- ------- -----
total 37001 9.50 13.53 0 568 78873 37000

*****************************************************
INSERT into without_ri values ('x', :b1 )

call count cpu elpsed disk query current rows
------- ------ ---- ------ ---- ----- ------- -----
Parse 1 0.00 0.03 0 0 0 0
Execute 37000 8.07 12.25 0 567 41882 37000
Fetch 0 0.00 0.00 0 0 0 0
------- ------ ---- ------ ---- ----- ------- -----
total 37001 8.07 12.29 0 567 41882 37000

L'essai a démontré que lors de l'insertion de 37 000 enregistrements dans la table avec la contrainte référentielle, 0.000256 secondes CPU par enregistrements fut utilisé (9.50/37000). Tandis que la table n'ayant pas de contrainte référentielle, 0.000218 secondes CPU par enregistrement fut utilisé.

Donc, la différence est de 0.00004 secondes CPU. Rien de bien dérangeant. À ce coût, il est préférable de préserver l'intégrité des données.

Je vous invite à visiter le blog de Tom Kytes (http://tkyte.blogspot.com)

Identifier les causes des verrous par l'historique

Depuis quelques temps grâce à Oracle Enterprise Manager, nous avons remarqué des verrous empêchaient ou plutôt retardaient certains traitements de se compléter dans un temps normal.

Pour identifier les sessions et/ou les requêtes en cause, j'ai utilisé la requête ci-dessous. Enterprise Manager me fournissait déjà les "session id" donc, assez simple d'extraire les infos et de plus, je savais à quel moment les verrous se sont produits :

col sql_text format a60 wrap
col event format a30 wrap
select count(*), s.sql_text, h.event
from GV$active_session_history h, gv$sql s
where h.sql_id = s.sql_id
and h.blocking_session in (1474,1260,200,592,1165,1351,584,18,780,1164,595)
and h.sample_time between to_date('2010-08-03 03:00:00','YYYY-MM-DD HH24:MI:SS')
and to_date('2010-08-03 12:00:00','YYYY-MM-DD HH24:MI:SS')
group by s.sql_text, h.event
order by 1 DESC;

Dans mon cas, j'ai remarqué beaucoup d'attente lié à une requête qui impliquait l'événement "enq: TX - row lock contention".

Ps. J'ai utilisé la vue GV$... parce que mon cas s'était produit sur un environnement Oracle RAC 11gR2.

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.

ORA-01078 au démarrage d'une instance Oracle 11g sous ASM

J'ai rencontré cette erreur lors d'un redémarrage de la base de données suite à des modifications de paramètres de bases de données qui sont stockés dans un SPFILE.

La base de données est de la version Oracle 11gR2 et elle est liée à un Grid Infrastructure qui utilise Oracle ASM et Oracle Restart.

Voici les étapes que j'ai suivi pour résoudre le problème :

--
oracle@romeo:/tmp> srvctl stop database -d F100
oracle@romeo:/tmp> srvctl start database -d F100
PRCR-1079 : Failed to start resource ora.f100.db
ORA-01078: failure in processing system parameters
CRS-2674: Start of 'ora.f100.db' on 'romeo' failed

--
-- Tentative de démarrage avec SQL*Plus
--
oracle@romeo:/tmp> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mer. Mai 5 12:07:49 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup nomount;
ORA-01078: failure in processing system parameters
ORA-00844: Parameter not taking MEMORY_TARGET into account
ORA-00851: SGA_MAX_SIZE 1577058304 cannot be set to more than MEMORY_TARGET 1358954496.

--
-- Tentative de correction de la valeur du paramètre en erreur
--
SQL> alter system set SGA_MAX_SIZE=100 scope=spfile;
alter system set SGA_MAX_SIZE=100 scope=spfile
*
ERROR at line 1:
ORA-01034: ORACLE not available
ID de processus : 0
ID de session : 0, Numéro de série : 0

--
-- Essai de création du pfile à l'image du spfile
--
SQL> create pfile='/tmp/pfileEC.ora' from spfile;
create pfile='/tmp/pfileEC.ora' from spfile
*
ERROR at line 1:
ORA-01565: error in identifying file '?/dbs/spfile@.ora'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

--
-- Afficher l'emplacement exact du SPFILE
--
SQL> ! cat $ORACLE_HOME/dbs/initF100.ora
SPFILE='+SYSDG01/F100/spfileF100.ora'

--
-- Création du pfile à l'image du spfile
--
SQL> create pfile='/tmp/pfileEC.ora' from spfile='+SYSDG01/F100/spfileF100.ora';

File created.

SQL> exit

--
-- Éditer le pfile pour enlever la ligne SGA_MAX_SIZE
--
oracle@romeo:/tmp> vi pfileEC.ora

--
-- Redémarrer la base de données avec le PFILE pour s'assurer
-- aucune autre erreur
--
oracle@romeo:/tmp> sqlplus / as sysdba


SQL*Plus: Release 11.2.0.1.0 Production on Mer. Mai 5 12:12:40 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.


Connected to an idle instance.

SQL> startup pfile='/tmp/pfileEC.ora'

ORACLE instance started.

Total System Global Area 1871208448 bytes
Fixed Size 2149152 bytes
Variable Size 1325405408 bytes
Database Buffers 536870912 bytes
Redo Buffers 6782976 bytes
Database mounted.
Database opened.

--
-- Création du spfile à l'image du pfile
--
SQL> Create spfile='+SYSDG01/F100/spfileF100.ora' from pfile='/tmp/pfileEC.ora';

File created.

--
-- Arrêt de la base de données
--
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit

--
-- Redémarrer la base de données à partir du Grid Infrastructure
--
oracle@romeo:/tmp> srvctl start database -d F100

Calculer le MEMORY_TARGET sous 11g

À partir des valeurs actuelles du SGA et du PGA, vous pouvez facilement déterminer les valeurs des nouveaux paramètres relatifs à la gestion automatique de la mémoire. Pour simplifier le calcul, je me suis bâtit une requête qui me propose les valeurs de base. La voici :

Select '-- Memory Target = '
||round(to_char((qry_sga_target.value+
greatest(qry_pga_target.value,
qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||
'Alter system set memory_target='
||to_char((qry_sga_target.value+
greatest(qry_pga_target.value,
qry_pga_alloc.value)))||' scope=spfile;'||chr(10)||
'-- Memory Max Target = '
||round(to_char((qry_sga_max.value+
greatest(qry_pga_target.value,
qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||
'Alter system set memory_max_target='
||to_char((qry_sga_max.value+
greatest(qry_pga_target.value,
qry_pga_alloc.value)))||' scope=spfile;'||chr(10)||
'Alter system reset sga_target scope=spfile;'||chr(10)||
'Alter system reset pga_aggregate_target scope=spfile;'||chr(10)||
'-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET'||chr(10)||
'Alter system set sga_max_size='
||to_char((qry_sga_target.value+
greatest(qry_pga_target.value,
qry_pga_alloc.value)))||' scope=spfile;' CMD_SQL
from (select value from v$parameter
where name='sga_target') qry_sga_target,
(select value from v$parameter
where name='pga_aggregate_target') qry_pga_target,
(select value from v$pgastat
where name='maximum PGA allocated') qry_pga_alloc,
(select value from v$parameter
where name='sga_max_size') qry_sga_max;


Il ne vous reste qu'à estimer le MEMORY_MAX_TARGET.

Utile ce SQL_ID !

Actuellement, nous travaillons à concevoir un outil de vérification de la performance des requêtes SQL entre une base de données Oracle 10g et 11g. Ceci nous permettra d'évaluer les impacts et d'être proactif dans l'identification, la configuration et, s'il y a lieu, dans les changements à apporter.

Pour débuter, nous collectons les requêtes et leurs statistiques qui sont exécutées par les utilisateurs via leurs applications sur la base de données 10g et nous stockons tout simplement ces informations dans des tables de travail. En faisant cela, nous sommes certains d'avoir des requêtes réelles, des statistiques claires et précises. Lorsque nous aurons migrés la base de données à Oracle 11g, la plupart des requêtes collectées précédemment seront sans aucun doute exécutées sur la nouvelle base de données. Lors de la conception de notre script, nous nous demandions comment nous pourrions retrouver et jumeler les requêtes identiques pour comparer les statistiques. À notre grande surprise, nous avons remarqué que le valeur contenue dans la colonne SQL_ID est identique entre les deux versions de bases de données. Vous comprendrez que ça vient de nous simplifier la vie et, pas juste un peu. Ce sera simple de regrouper les requêtes par SQL_ID et de les comparer puis faire ressortir celles ayant des valeurs de statistiques dont l'écart est prononcé.

Voici une démonstration :

SQL> conn system@A009
Enter password:
Connecté.
SQL> Select count(*) from sys.v_$parameter;

COUNT(*)
------------
263

SQL> select a.SQL_ID, a.executions, a.disk_reads, a.buffer_gets, a.sql_text
2 from v$sql a, all_users b
3 where a.parsing_user_id = b.user_id
4 and b.username = 'SYSTEM'
5 and a.sql_text = 'Select count(*) from sys.v_$parameter'
6 order by 1 desc;

SQL_ID EXECUTIONS DISK_READS BUFFER_GETS SQL_TEXT
------------- ------------ ------------ ------------ --------------------------------------
3yq5vhv923584 1 1 2 Select count(*) from sys.v_$parameter

SQL> conn system@mig11201
Enter password:
Connecté.
SQL> Select count(*) from sys.v_$parameter;

COUNT(*)
------------
343

SQL> select a.SQL_ID, a.executions, a.disk_reads, a.buffer_gets, a.sql_text
2 from v$sql a, all_users b
3 where a.parsing_user_id = b.user_id
4 and b.username = 'SYSTEM'
5 and a.sql_text = 'Select count(*) from sys.v_$parameter'
6 order by 1 desc;

SQL_ID EXECUTIONS DISK_READS BUFFER_GETS SQL_TEXT
------------- ------------ ------------ ------------ --------------------------------------
3yq5vhv923584 1 0 2 Select count(*) from sys.v_$parameter

Utilisation de la commande "tar"

La commande "tar" permet de regrouper plusieurs fichiers sous un même fichier. Cette commande fusionne les fichiers sans les compresser.

Concevoir un archive

tar -vcf nom_fichier_archive.tar nom_fichier

• tar: la commande
• vcf: les options
• v : fournit des informations lors de la conception de l’archive (optionnelle)
• c: Indique de créer un archive
• f: permet de spécifier le nom du fichier d’archive
• nom_fichier_archive.tar: nom donné au fichier d’archive
• nom_fichier : nom du dossier (ou fichiers) à archiver

Extraire le contenu d’un archive

La commande tar est aussi utilise pour extraire les fichiers contenu dans l’archive.
Extraire tout le contenu d’un archive

tar -vxf nom_fichier_archive.tar

• tar: la commande
• vxf: les options
• v: Afficher des informations lors de l’extraction (optionnelle)
• x: Indique d’extraire les fichiers
• f: Indique que l’archive contient des fichiers
• nom_fichier_archive.tar: Nom du fichier d’archive à traiter

Extraire certains fichiers d’un archive

tar -xvf nom_fichier_archive.tar "*.dbf"

Afficher le contenu d’un fichier d’archive

tar -tf nom_fichier_archive.tar

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 :)

Objets sans statistiques ou désuètes

Voici un script qui permet d'afficher les objets dont les statistiques sont absentes ou désuètes (stale) :

SET SERVEROUTPUT ON

DECLARE
vListeObjt dbms_stats.ObjectTab;
BEGIN
-- Stats désuetes
dbms_output.put_line('-- **********************');
dbms_output.put_line('-- Statistiques désuètes');
dbms_output.put_line('-- **********************');
dbms_stats.gather_database_stats(objlist=>vListeObjt, options=>'LIST STALE');
FOR i in vListeObjt.FIRST..vListeObjt.LAST
LOOP
dbms_output.put_line(vListeObjt(i).ownname || '.' || vListeObjt(i).ObjName || ' (' || vListeObjt(i).ObjType || ' ' || vListeObjt(i).partname||' )');
END LOOP;
-- Sans Stats
dbms_output.put_line('-- **********************');
dbms_output.put_line('-- Sans statistique');
dbms_output.put_line('-- **********************');
dbms_stats.gather_database_stats(objlist=>vListeObjt, options=>'LIST EMPTY');
FOR i in vListeObjt.FIRST..vListeObjt.LAST
LOOP
dbms_output.put_line(vListeObjt(i).ownname || '.' || vListeObjt(i).ObjName || ' (' || vListeObjt(i).ObjType || ' ' || vListeObjt(i).partname||' )');
END LOOP;
END;
/

Comportement des statistiques systèmes en mode RAC

Lors de la collecte des statistiques systèmes d'un environnement RAC, on peut déclencher la collecte à partir de n'importe quelle instance. Tout s'effectue correctement... À vrai dire, pas exactement car les autres instances attachées au cluster ne prennent pas en compte les nouvelles valeurs.

Je me suis aperçu de ce problème quand une requête est devenue gourmande. Le plan d'exécution de la requête était complètement différent sur 2 instances. En me connectant sur l'une des instances du cluster, j'ai vérifié les valeurs des statistiques (select * from sys.aux_stats$). C'est à ce moment que j'ai remarqué qu'elles avaient été régénérées récemment et l'un de mes collègues me l'a confirmé. J'ai aussi eu la confirmation que la lenteur avait été observée depuis la date de la régénération des statistiques. Donc, je pouvais déduire que la collecte de statistiques systèmes était l'élément déclencheur.

Que se soit sur l'une ou l'autre des instances du cluster, les mêmes statistiques sont supposées être utilisées dont je suspecte que le problème soit au niveau de la mémoire ou d'une certaine cache. J'ai tenté une simple purge du "shared pool" et celle des données mais sans succès. Comme à l'habitude, j'ai fait une petite recherche sur Metalink et effectivement, il y a un problème de répertorier sur la base de données 10.2.0.3. (ID 7645777.8) concernant un plan d'exécution différent sur des instances RAC. La solution : Recycle the instances... Qu'est-ce que cela veut dire exactement ?!? J'imagine que c'est l'équivalent d'un redémarrage d'instance et, si c'est le cas, et bien, je ne peux pas me le permettre. Vu que ce bug concerne les statistiques systèmes alors, j'ai décidé de pousser la vérification en influençant l'optimisateur pour qu'il n'utilise pas les statistiques liées au CPU. Pour ce faire, j'ai utilisé le hint "NO_CPU_COSTING". Les résultats furent concluants, j'ai obtenu le même plan d'exécution que sur l'instance où la requête est optimale.

Tant qu'à pousser, j'ai décidé d'effectuer une trace de l'optimisateur sur l'exécution de la requête sur chacune des instances avec la commande :

ALTER SESSION SET EVENTS '10053 trace name context forever, level 1'

Les 2 fichiers de trace ont démontrés que les statistiques systèmes sont différentes donc ça confirme que l'optimisateur n'utilise pas les mêmes valeurs d'une instance à l'autre... Inquiétant ?

Après réflexion, je me suis dit, pourquoi ne pas répéter ou presque les mêmes étapes de collecte de statistiques systèmes mais cette fois-ci, en étant connecté sur l'instance n'ayant pas le même comportement ou si vous préférez, le même plan d'exécution. Alors, j'ai effectué ceci :

-- Établir une connexion sur l'instance qui n'utilise pas les nouvelles valeurs
connect sys@inst1 as sysdba

-- Prendre une copie des statistiques actuelles
Drop table stats_bkp;
EXECUTE DBMS_STATS.CREATE_STAT_TABLE ('SYS','stats_bkp','SYSAUX');
EXECUTE DBMS_STATS.EXPORT_SYSTEM_STATS (stattab => 'stats_bkp', statid => 'stats_bkp', statown => 'SYS');
select * from sys.stats_bkp;

-- Charger les valeurs
execute DBMS_STATS.DELETE_SYSTEM_STATS;
EXECUTE DBMS_STATS.IMPORT_SYSTEM_STATS (stattab => 'stats_bkp', statid => 'stats_bkp', statown => 'SYS');
select * from sys.aux_stats$;

-- Initialiser les espaces mémoires
Alter system flush shared_pool;
Alter system flush buffer_cache;

Et bien oui, ça fonctionne! La requête a maintenant le même plan d'exécution que sur l'autre instance. Stop! Le problème s'est déplacé sur l'autre instance... oups! Ok, alors, je vais refaire la même chose, mais cette fois-ci sur l'instance où le problème s'est déplacé. Suite à l'exécution des commandes précédentes, le plan d'exécution est redevenu celui d'auparavant et, sans impacter le plan d'exécution sur l'autre instance.

Je crois qu'un redémarrage de l'instance aurait pu régler le problème sauf que lorsque nous sommes sur un environnement de production, cela n'est pas toujours une solution et ce, même si c'est un environnement RAC à moins que vous preniez le temps de déplacer tous les services vers une autre instance puis que vous patientez jusqu'à ce que toutes les sessions se soient reconnectés vers la nouvelle instance.

Les caprices d'Oracle EM

S'il vous arrive de rencontrer l'erreur "numeric or value error" lorsque vous naviguez à travers l'outil d'Oracle Enterprise Manger (Grid Control)... et possiblement la version Stand Alone (database Control), pensez à tout simplement modifier la langue utilisée par votre fureteur.

J'ai rencontré à maintes reprises ce problème et le simple fait de mettre la langue à "Anglais" vous permet de continuer ou plutôt contourner ce problème.

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;

Modification de la valeur du paramètre "service_names"

Lorsque vous créer vos services puis que vous appliquez le changement avec la commande « ALTER SYSTEM », il faut que chacun des services soit entre apostrophes.

Si vous traitez la ligne comme une seule chaîne, vous obtiendrez une erreur vous disant que vous avez atteint la taille maximum autorisée pour un paramètre qui est de 255 caractères.

Mauvaise façon
Alter system set service_names = 'RH_FRMT, SALES_FRMT' scope=both;

Bonne façon
Alter system set service_names = 'RH_FRMT', 'SALES_FRMT' scope=both;

Pour générer la commande (extraction) à partir des valeurs déjà assignées, j’utilise cette commande :

Select 'Alter system set service_names = '''
||replace(value,', ',''', ''')
||''' scope=both;'
from v$parameter where name = 'service_names';

Oracle Clusterware 11gR2

Oracle Clusterware est la composante majeure d’Oracle Grid Infrastructure et constitue la base d’Oracle Real Application Cluster (RAC). Oracle Clusterware permet de former un groupe de serveurs et de les faire fonctionner comme un seul système. Il permet de gérer l’ensemble des ressources, des processus et des applications du cluster tout en gérant et assurant la stabilité des nœuds.

Oracle Clusterware est composé principalement de deux éléments : le « voting disk » et l'OCR (Oracle Cluster Registry). Le « voting disk » est tout simplement un fichier qui contient et gère les informations de tous les nœuds liés au cluster et, l'OCR est un fichier qui gère le cluster et configuration RAC.

Depuis la version 11g Release 2, les fichiers de l’OCR et des voting disks peuvent maintenant être stockés dans ASM. D’ailleurs, cette façon de faire est conseillée par Oracle.
Dans les versions antérieures, la sauvegarde des « voting disks » en utilisant la commande « dd » était une tâche nécessaire suite à l’installation. Avec Oracle Clusterware 11gR2, la sauvegarde et la restauration d'un « voting disk » en utilisant la commande « dd » n'est plus supportée ni requise car ils sont sauvegardés automatiquement dans l’Oracle Cluster Registry (OCR) dès qu’un changement de configuration se produit. De plus, les données d’un « voting disks » sont automatiquement restaurées et appliquées sur un disque nouvellement ajouté.

Nouveautés intéressantes avec Clusterware 11gR2

Server Pool

• Division logique du cluster en pools de serveurs.
• Regroupement de serveurs ayant une charge similaire
• Gérer avec les outils crsctl (applications) et srvctl (Oracle)
• Définit par 3 principaux attributs (min, max, importance) ou une liste prédéfinie des nœuds
• Utilisation de règles (policies) pour contrôler l’utilisation du pool

Single Client Access Name (SCAN)

• Utilisé par les clients pour établir une connexion à n’importe quelle base de données du cluster
• Aucun changement nécessaire à la configuration de connexion d’un client advenant un changement au cluster
• Balancement de la charge parmi les instances desservit par un service
• Transparence lors d’un déplacement d’instance (failover)
• Permet aux clients d’utiliser une connexion de type « EZConnect » ou JDBC simple

Grid Plug and Play (GPnP)

• Simplifie l’ajout, le remplacement, et la suppression d’un noeud du cluster
• Permettre au cluster de gérer ses propres adresses IP virtuelles (Grid Naming Service)

Oracle Grid Infrastructure 11gR2

À partir d’Oracle 11g Release 2, Oracle Clusterware combiné à Oracle Automatic Storage Management (ASM) est devenu Oracle Grid Infrastructure.

Oracle Grid Infrastructure peut être déployé autant pour un environnement à multiples instances que simple instance (stand alone).

Pour les bases de données à simple instance, Oracle Grid Infrastructure permet de mettre en place une infrastructure légère de haute disponibilité. Cette option inclut deux composantes : Oracle Restart et Oracle ASM.

Pour les bases de données à multiple instance (RAC), Oracle Grid Infrastructure permet de mettre en place une réelle infrastructure de haute disponibilité regroupant plusieurs serveurs. Cette option inclut deux composantes : Oracle Clusterware et Oracle ASM.