Cette requête permet de savoir qui utilise le temp à un instant donné :
select
sql_text,
sid,
c.username,
machine,
tablespace,
extents,
blocks
from
sys.v_$sort_usage a,
sys.v_$sqlarea b,
sys.v_$session c
where
a.sqladdr = b.address and
a.sqlhash = b.hash_value and
a.session_addr = c.saddr
order by
sid;
jeudi 8 octobre 2009
mardi 6 octobre 2009
Formation Oracle RAC
Et voilà, après une semaine sur cette formation j'ai comblé mes lacunes sur l'installation du RAC.
Parmis les points à retenir il y a :
Parmis les points à retenir il y a :
- le cache fusion qui aggrège le cache de chaque noeud en un seul
- les services RAC qui permettent d'affiner le load balancing
- les contraintes ( séquences, insertion concurrents sur les mêmes blocs d'index ... )
- le monitoring
mardi 29 septembre 2009
Formation Oracle RAC
Cette semaine, je suis en formation Oracle RAC 11GR1 . L'occasion de découvrir la nouvelle version d'Oracle mais aussi d'approfondir mes connaissances sur RAC.
Pour sur, à la fin de la semaine, je maîtriserai l'installation sous Linux :-)
Pour sur, à la fin de la semaine, je maîtriserai l'installation sous Linux :-)
mardi 21 juillet 2009
Article interessant sur le développements des applications
Cet article détaille une autre approche de développement où l'utilisation de procédures stockées pour alléger la couche tiers fait face à la tendance d'aujourd'hui ( frameworks et orm ).
Pourquoi parler de cela ... IFS Applications utilise ce principe de "base de données épaisses" car la logique métier est (presque) entièrement écrit en PL/SQL.
Ce principe permet de garantir les performances tout en exploitant les capacités de la base de données Oracle.
Après 10 ans de développement sur la plateforme Oracle et 4 ans de DBA, je pense que cette approche garantit les performances et l'extensibilité de votre système.
L'un de ses inconvénient majeur ( si il en est réellement ) est de limiter le portage de l'application vers une autre base de données mais elle est compensée par les performances.
Pourquoi parler de cela ... IFS Applications utilise ce principe de "base de données épaisses" car la logique métier est (presque) entièrement écrit en PL/SQL.
Ce principe permet de garantir les performances tout en exploitant les capacités de la base de données Oracle.
Après 10 ans de développement sur la plateforme Oracle et 4 ans de DBA, je pense que cette approche garantit les performances et l'extensibilité de votre système.
L'un de ses inconvénient majeur ( si il en est réellement ) est de limiter le portage de l'application vers une autre base de données mais elle est compensée par les performances.
dimanche 10 mai 2009
Problème de session avec Asp.net, IIS et IE8
Une petite note pour dire que j'ai eu un problème stupide avec les sessions avec un serveur IIS 6 et IE ( 7 et 8).
Je n'avais pas les sessions qui fonctionnaient ... alors que le problème n'existait pas sous Firefox.
Avec la page suivante Ani S Menon's Blog- My Little thoughts : Troubleshooting Session loss..., j'ai trouvé l'erreur : la machine avait un '_' ( underscore ) dans son nom.
En changeant le nom de la machine, l'application fonctionnait enfin.
Je n'avais pas les sessions qui fonctionnaient ... alors que le problème n'existait pas sous Firefox.
Avec la page suivante Ani S Menon's Blog- My Little thoughts : Troubleshooting Session loss..., j'ai trouvé l'erreur : la machine avait un '_' ( underscore ) dans son nom.
En changeant le nom de la machine, l'application fonctionnait enfin.
jeudi 16 avril 2009
Oracle RAC partie 3
Depuis 2 semaines, le cluster RAC est en production et héberge 3 bases sachant que deux autres sont encore attendues.
Au final, il a été réinstallé suite à un plantage complet de la couche cluster. Cette dernière a permit de supprimer tous les applications tierces qui pouvaient poser problème.
Le volume ocfs a aussi été supprimer.
Depuis, aucun problème n'est à déplorer.
Au final, il a été réinstallé suite à un plantage complet de la couche cluster. Cette dernière a permit de supprimer tous les applications tierces qui pouvaient poser problème.
Le volume ocfs a aussi été supprimer.
Depuis, aucun problème n'est à déplorer.
lundi 23 février 2009
ORA 12500 ...
Un de mes clients rencontrait depuis plusieurs mois ce problème sous Windows avec Oracle 9i.
On lui avait conseillé d'ajouter un second listener sans résultat.
Après 3h d'analyse j'en ai déduit que le nombre de sessions et le paramétrage mémoire ( SGA + cache ) faisait atteindre les 2Go de mémoire au process Oracle... limite de windows en 32 bits.
J'ai modifié le paramétrage de la base pour réduire la SGA et préconisé d'autres pistes : shared server, migration vers 10Gr2 en 64 bits ...
De son côté, le client a commencé à bloquer le nombre de sessions par utilisateurs afin de limiter les connexions intempestives.
En attendant, aucun nouveau blocage des connexions n'est intervenu.
On lui avait conseillé d'ajouter un second listener sans résultat.
Après 3h d'analyse j'en ai déduit que le nombre de sessions et le paramétrage mémoire ( SGA + cache ) faisait atteindre les 2Go de mémoire au process Oracle... limite de windows en 32 bits.
J'ai modifié le paramétrage de la base pour réduire la SGA et préconisé d'autres pistes : shared server, migration vers 10Gr2 en 64 bits ...
De son côté, le client a commencé à bloquer le nombre de sessions par utilisateurs afin de limiter les connexions intempestives.
En attendant, aucun nouveau blocage des connexions n'est intervenu.
Oracle RAC partie 2
Voilà 2 semaines, j'ai commencé à travailler sur la migration de bases sur un cluster Oracle 10GR2 sous Windows.
Au total, 6 bases seront hostées dont une pour un ERP et une deuxième pour un datawarehouse.
Certaines bases sont en 10Gr2 alors que d'autres sont en 9i. J'ai choisi l'export / import pour ces dernières afin de recréer les tablespaces correctement et bénéficier d'une "défragmentation".
Que dire du RAC ... on rencontre un certain nombre de problème avec 1 des 2 noeuds qui a planté plusieurs fois. Les raisons évoquées sont les suivantes :
On en saura plus demain.
Au total, 6 bases seront hostées dont une pour un ERP et une deuxième pour un datawarehouse.
Certaines bases sont en 10Gr2 alors que d'autres sont en 9i. J'ai choisi l'export / import pour ces dernières afin de recréer les tablespaces correctement et bénéficier d'une "défragmentation".
Que dire du RAC ... on rencontre un certain nombre de problème avec 1 des 2 noeuds qui a planté plusieurs fois. Les raisons évoquées sont les suivantes :
- matérielle
- logicielle ( problème avec le logiciel de sauvegarde ou bien l'antivirus )
- système : problème avec la partition OCFS
On en saura plus demain.
jeudi 5 février 2009
Mes débuts avec Oracle RAC
Depuis le début de la semaine, j'ai commencé à travaillé sur la migration de différentes bases 10G et 9i sur un RAC Oracle sous Windows.
Le RAC a été installé par un DBA qui maîtrise la chose ( il a un certain nombre d'installations sous Unix à son actif ). J'ai repis le flambeau pour tester la migration de la base de prod afin de le réaliser à la fin du mois.
Le RAC est composé de 2 noeuds sous Windows 2003 Server en 64 bits doté de 26 Go de RAM chacun et utilisant un SAN pour le stockage des bases.
La gestion du stockage est faite par ASM ce qui permet d'avoir de très bonnes performances mais cela nécessite d'utiliser RMAN pour la sauvegarde ... ce qui n'est plus un problème pour moi.
La migration de la base de production se fait à partir d'une sauvegarde RMAN réalisée sur autre serveur. Lors de la restauration, les fichiers sont créés directement en ASM.
La base fait 100Go environ et elle se restaure en environ 30 minutes.
Le reste de la procédure demande environ 2h de manipulations manuelles.
Suite à ces tests de restauration, la mise en sauvegarde via RMAN a été mise en place.
Le script de clonage de base de données est fait.
Il ne reste que la mise en place des tests du cluster à faire. Chose qui devrait se faire cet après midi.
Le RAC a été installé par un DBA qui maîtrise la chose ( il a un certain nombre d'installations sous Unix à son actif ). J'ai repis le flambeau pour tester la migration de la base de prod afin de le réaliser à la fin du mois.
Le RAC est composé de 2 noeuds sous Windows 2003 Server en 64 bits doté de 26 Go de RAM chacun et utilisant un SAN pour le stockage des bases.
La gestion du stockage est faite par ASM ce qui permet d'avoir de très bonnes performances mais cela nécessite d'utiliser RMAN pour la sauvegarde ... ce qui n'est plus un problème pour moi.
La migration de la base de production se fait à partir d'une sauvegarde RMAN réalisée sur autre serveur. Lors de la restauration, les fichiers sont créés directement en ASM.
La base fait 100Go environ et elle se restaure en environ 30 minutes.
Le reste de la procédure demande environ 2h de manipulations manuelles.
Suite à ces tests de restauration, la mise en sauvegarde via RMAN a été mise en place.
Le script de clonage de base de données est fait.
Il ne reste que la mise en place des tests du cluster à faire. Chose qui devrait se faire cet après midi.
Migrations oracle
J'ai quelques clients utilisant des versions plus supportées d'Oracle ( 8i et 9i ) qui m'ont demandé de migrer leurs bases.
Les tests que j'ai réalisé jusqu'à présent n'ont pas présenté de problèmes.
Une version 9i ( version 9.2.0.8 ) peut être migrée directement sur un serveur Windows 2003 Server 64 bits sur une 10Gr2 ( 10.2.0.4 ).
Malheureusement, les versions antérieures du moteur 9i ne se lancent pas sur cette version de Windows. Cela nécessite de patcher la base avant de la migrer.
Pour les bases 8i, je crois que je vais devoir passer par un export car le moteur 8i ne s'installe pas sur un Windows 2003 en 64 bits.
Les intérêts de ce genrer de migrations ne sont pas négligeables :
Les apports qu'apportent ce genre de migration n'est pas négligeable en niveau du SI.
Les tests que j'ai réalisé jusqu'à présent n'ont pas présenté de problèmes.
Une version 9i ( version 9.2.0.8 ) peut être migrée directement sur un serveur Windows 2003 Server 64 bits sur une 10Gr2 ( 10.2.0.4 ).
Malheureusement, les versions antérieures du moteur 9i ne se lancent pas sur cette version de Windows. Cela nécessite de patcher la base avant de la migrer.
Pour les bases 8i, je crois que je vais devoir passer par un export car le moteur 8i ne s'installe pas sur un Windows 2003 en 64 bits.
Les intérêts de ce genrer de migrations ne sont pas négligeables :
- utilisation d'une version supportée par Oracle
- de meilleurs performances car on est plus limité à 2 Go de Ram pour le process Oracle ce qui permet d'avoir plus de mémoire pour les caches mémoires
- une vitesse accrue car on parle de dual core ou de quad core
- de meilleurs accès disques ( utilisation de SAN ou de disques plus performants )
Les apports qu'apportent ce genre de migration n'est pas négligeable en niveau du SI.
jeudi 1 janvier 2009
Inscription à :
Articles (Atom)