Firefox 3 a une implementation SSL differente qui rencontre un bug des librairies SSL utilisées avec Apache. Le symptome est le suivant : “SSL a reçu un enregistrement « Change Cipher Spec » inattendu.”
La solution consiste à ajouter le parametre suivant à la configuration d’apache :
SSLProtocol all -TLSv1 -SSLv2

Avant tomcat 5.5, les pages d’erreurs (404,503…) pouvaient connaitre l’URL choisie par l’utilisateur au travers d’un classique request.getRequestURL() ; depuis la 5.5, il faut travailler autrement, en effet, l’instruction précédente renverra le nom de la page d’erreur.
Il est donc maintenant nécessaire de passer par un attribut qui conserve cette information en utilisant la commande suivante : (String) request.getAttribute(“javax.servlet.error.request_uri”);

En ce moment, je bricole pas mal avec Oracle pour chercher pourquoi certaines de nos applications rament … D’où l’envie de mettre quelques informations sur les principaux point à regarder. Cet article n’a pas de vocation exhaustive mais ce sont plutôt quelques notes sur un coin de table…

Oracle est une base possédant un énorme moteur d’optimisation de requêtes, sans doute très fort pour le traitement massif de données, cependant, le moindre grain de sable transforme immédiatement votre Ferrarie en une 2CV. Au premier rang des grains de sable se trouvent les statistiques. Il s’agit d’une donnée Oracle indiquant le nombre de lignes que la table doit contenir. Fonction de ce nombre, l’optimiseur choisira une methode de recherche des données dans une table plutôt qu’une autre. Il pourra utiliser des INDEX ou des CLEFS ou choisir de faire un FULL SCAN (essayer les lignes une à une). S’il se trompe… c’est la cata. Le premier point est donc de vérifier ces stats en consultant le nombre de ligne qu’ORACLE pense avoir dans “all_tables” et le comparer aux nombre de lignes reellement dans la table count(*).
Ceci étant dit, je n’ai pas dit grand chose car il est avant nécessaire d’identifier quelles sont les tables concernées, ceci peut se faire de 2 façons, la première, lorsque le temps de réponse est catastrophique, consiste à regarder les session actives et visualiser le sql en cours de traitement. Ceci se fait facilement avec des outils comme TOAD ou DbVisualizer.
La requête peut aussi être identifiée à l’aide du stat_pack oracle. Cet outil permet de mémoriser l’état de la SGA avant et après un traitement puis de faire une comparaison de entre les deux images. Cet outil permet alors de savoir quelles sont les requêtes qui ont consommées le plus de temps, quelle est l’utilisation de la SGA ou de la PGA … Bref … une fois la requête identifiée, il est possible de demander à Oracle un Explain plan qui indiquera quels est la complexité de la requête et par quelles méthode les données sont recherchées (full scan, index…)
Il est alors possible d’identifier les problèmes. Il faut identifier s’il existe un index qui pourrait être utilisé et qui ne l’est pas par exemple ou s’il faudrait créer un nouvel index. Dans le premier cas, il est possible que les stats ne soient pas bonnes car si oracle préfère un fullscan à un index, c’est sans doute qu’il croit que la table ne contient que très peu de lignes.
Si tout semble normal de ce point de vue, il arrive que les index aient besoin d’être rebuildés : il se peu que les arbre binaires associés soient déséquilibrés, que le nombre de niveau devienne trop grand et que son utilisation ne soit pas efficace. Un rebuild peut résoudre cela. Il est aussi possible, à l’aide de Hints de forcer Oracle à utiliser un index donné. Mais ceci n’est valable que lorsque vous avez accès aux sources de l’application.
On peut enfin penser à faire un reset de la High Water Mark sur une table donnée si vraiment on constate des soucis sur cette table alors que tout le reste est ok.

Avant de vraiment s’attaquer à tout cela, il peut être utile de jeter un oeil aux estimations que donne le stat pack sur la taille des SGA, PGA et Shared Pool car des espaces mémoire trop réduits vont fortement pénaliser Oracle qui devra faire trop d’accès aux disques. Dans le même esprit, il faut jeter un oeil aux taille des redo-log qui peuvent conduire à des fréquences d’I/O trop élevées dans les système de type batch.

Bon courage avec toutes ces notions et idées un peu en vrac … il y a ici surtout des mots clefs pour chercher ensuite sur google. A l’occasion, je mettrai des information plus opérationnelles, promis !

Deux petits scripts permettant le recalcul des index d’une base oracle lorsque ceux-ci ont l’air louche … Les scripts sont à passer l’un après l’autre sur la base

--- AnalyseIndex.sql
set pages 9999;
set heading off;
set feedback off;
set echo off;
set linesize 255;

spool step1.sql;
select 'drop table system.temp_stats_paul;' from dual;
select 'create table system.temp_stats_paul as select name, most_repeated_key, distinct_keys, del_lf_rows, height, blks_gets_per_access, lf_rows from index_stats;' from dual;

select 'analyze index '||owner||'.'||index_name||' validate structure;',
'insert into system.temp_stats_paul ( select name, most_repeated_key, distinct_keys, del_lf_rows, height, blks_gets_per_access, lf_rows from index_stats where height > 3 or ( 100 * del_lf_rows / (lf_rows+1) ) > 20 or BLKS_GETS_PER_ACCESS > 5 );'
from dba_indexes
where
owner not in ('SYS','SYSTEM');

spool off;
set heading on;
set feedback on;
set echo on;

@step1.sql
quit

--- RebuildIndex.sql
set pages 9999;
set heading off;
set feedback off;
set echo off;
set linesize 255;

spool step2.sql;

select 'alter index '||owner||'.'||name||' rebuild tablespace '||tablespace_name||';'
from system.temp_stats_paul, dba_indexes
where system.temp_stats_paul.name = dba_indexes.index_name;

spool off;

drop table system.temp_stats_paul;

set heading on;
set feedback on;
set echo on;

@step2.sql
quit