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;
/
mercredi 24 mars 2010
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.
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.
mardi 23 mars 2010
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.
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.
jeudi 25 février 2010
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;
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;
jeudi 28 janvier 2010
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';
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';
jeudi 14 janvier 2010
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
Single Client Access Name (SCAN)
Grid Plug and Play (GPnP)
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.
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.
S'abonner à :
Messages (Atom)