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.