Discussion :

[Sardonnen]

bonjour
j'ai une base oracle sur laquelle je n'ai pas la main pour l'arreter et la redemarrer.
Je constate que la sql area est consequente et que par consequence les temps de réponse utilisateurs sont long

Existe t'il un autre moyen pour vider et réinitialiser la sql area???

merci pour votre aide

[Pomalaix]

Je constate que la sql area est consequente et que par consequence les temps de réponse utilisateurs sont long

Existe t'il un autre moyen pour vider et réinitialiser la sql area???

Bonjour

Vous faites une mauvaise supposition en établissant un lien de causalité entre "la sql area conséquente" et de mauvais temps de réponse.

ALTER SYSTEM FLUSH SHARED POOL permet de vider le cache SQL (library cache en bon franglais), mais c'est manifestement sans intérêt dans votre cas.

[Sardonnen]

oui tu as raison ça n'a pas eu d'incidence, je crois que l'action à mener doit se situer coté buffer cache alors????
car je pensais que le sql area avait une incidence justement sur les temps de réponse coté utilisateur, il existe le même type de syntaxe pour vider le buffer_cache???

[aline]

Qu'est ce qui vous fait penser que de lauvais temps de réponses sont dus à un mauvais paramertrage de la base?

Dans 90% desc cas, la cause est du mauvais code!

[orafrance]

tu me sembles diagnostiquer les problèmes un peu au petit bonheur. Quels symptomes (wait, event, etc...) te méne à ces conclusions ?

[Sardonnen]

ce qui me fait supposer cela c'est que lorsqu'on arrete la base et on la redemarre le temps de restitution des infos sur mes pages web est rapide

par contre il est vrai que mes pages pourraient être en cause également, mais j'explore déjà cette piste

[orafrance]

et pourquoi pas un problème de DB_CACHE_SIZE trop petit ?

[aline]

ou bien un problème de requetes non bindées!
voici un petit exemple que j'ai pris à Tom Kytes pour monitorer ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
column sql_text_wo_constants format a64
 
create table nobind as select sql_text from v$sqlarea;
 
alter table nobind add sql_text_wo_constants varchar2(1000);
create or replace function
remove_constants( p_query in varchar2 ) return varchar2
as
    l_query long;
    l_char  varchar2(1);
    l_in_quotes boolean default FALSE;
begin
    for i in 1 .. length( p_query )
    loop
        l_char := substr(p_query,i,1);
        if ( l_char = '''' and l_in_quotes )
        then
            l_in_quotes := FALSE;
        elsif ( l_char = '''' and NOT l_in_quotes )
        then
            l_in_quotes := TRUE;
            l_query := l_query || '''#';
        end if;
        if ( NOT l_in_quotes ) then
            l_query := l_query || l_char;
        end if;
    end loop;
    l_query := translate( l_query, '0123456789', '@@@@@@@@@@' );
    for i in 0 .. 8 loop
        l_query := replace( l_query, lpad('@',10-i,'@'), '@' );
        l_query := replace( l_query, lpad(' ',10-i,' '), ' ' );
    end loop;
    return upper(l_query);
end;
/
update nobind set sql_text_wo_constants = remove_constants(sql_text);
 
select sql_text_wo_constants, count(*)
  from nobind
 group by sql_text_wo_constants
having count(*) > 100
 order by 2
/

[remi4444]

ce qui me fait supposer cela c'est que lorsqu'on arrete la base et on la redemarre le temps de restitution des infos sur mes pages web est rapide

ça c'est étonnant parcqu'avec le système de cache, le principe est exactement l'inverse à savoir que ce ne sont que les 1ieres requêtes qui doivent être lentes et les suivantes plus rapides.

Est-ce que tu as simplement regardé le nombre de connexions à la base (par v$session). Il se peut que le problème vienne du serveur web qui ne libère pas ses sessions oracle ou bien qu'il lance des requêtes longues qui s'accumulent. Le fait de redémarrer la base aurait comme bénéfice colatéral de faire un reset de toute ces connexions...

[Sardonnen]

effectivement mes requetes ne sont pas bindés, je passe tous mes parametres en dur dans la requete. Il faut que je regarde comment faire ce que tu me dis en asp.net 1.1

sinon sur mes parametres j'ai augmenté le DB_BLOCK_BUFFERS à 15000

[aline]

effectivement mes requetes ne sont pas bindés, je passe tous mes parametres en dur dans la requete. Il faut que je regarde comment faire ce que tu me dis en asp.net 1.1

Dans ce cas, cela explique aisément le comportement que tu décris.
Juste pour info, peux-tu nous donner le résultat du petit script que je t'ai envoyé quand la base commence à être chargée?

[remi4444]

Il existe un paramètre pour forcer oracle à "pre-binder" les requêtes qui ne le sont pas: CURSOR_SHARING. Si tu es en 8i, tu peux le mettre à "FORCE", en 9i ou plus, tu peux le mettre à "SIMILAR" (solution intermédiaire entre "FORCE" et "EXACT" qui est un bon compromis). Cependant je ne pense pas que ton problème vienne de là, car si tel était le cas, le "FLUSH SHARED_POOL" aurait temporairerement accélérer les choses ce qui n'était pas le cas d'après ce que tu as dis.

[Sardonnen]

Dans ce cas, cela explique aisément le comportement que tu décris.
Juste pour info, peux-tu nous donner le résultat du petit script que je t'ai envoyé quand la base commence à être chargée?

il m'a chargé une table avec 800 enregistrements et en resultat j'ai ça

SQL_TEXT_WO_CONSTANTS COUNT(*)
---------------------------------------------------------------- ----------
SELECT W_REP.IDENT_REPONSE,W_REP.IDENT_ITEM,W_REP.IDENT_POR,W_RE 220
1 row selected

[Sardonnen]

Il existe un paramètre pour forcer oracle à "pre-binder" les requêtes qui ne le sont pas: CURSOR_SHARING. Si tu es en 8i, tu peux le mettre à "FORCE", en 9i ou plus, tu peux le mettre à "SIMILAR" (solution intermédiaire entre "FORCE" et "EXACT" qui est un bon compromis). Cependant je ne pense pas que ton problème vienne de là, car si tel était le cas, le "FLUSH SHARED_POOL" aurait temporairerement accélérer les choses ce qui n'était pas le cas d'après ce que tu as dis.

je pensais que cette opération se faisait coté requete sur page web en passant les criteres avec des variables du type @variable@, sinon oracle peux gérer ça??? c'est pas gourmand en ressource???

sinon je suis en 8.17

[nuke_y]

Question bête : si on binde les variables, est-ce que cela fige le plan d'exécution ?

[remi4444]

je pensais que cette opération se faisait coté requete sur page web en passant les criteres avec des variables du type @variable@

Effectivement c'est normalement coté client qu'on décide d'utiliser les bind, mais je ne sais pas ce que génère les pilotes php/oracle derrière cette syntaxe...

sinon oracle peux gérer ça??? c'est pas gourmand en ressource???

sinon je suis en 8.17

En plaçant le CURSOR_SHARING à FORCE, on force oracle à faire une petite analyse syntaxique afin de ré-écrire la requête à la volée, ça prend un peu de CPU, mais ça y gagne coté partage de requête (calcul du plan d'exécution, compilation...). Cependant ça ne deviens efficace qu'en présence d'un nombre conscéquant de requête non bindée qui se ressemblent toute, ce qui a l'air d'être ton cas. Normalement le résultat va se voir très vite en regardant la montée en mémoire de la sql-aréa. Cependant, je reste persuadé que le gros problème ne viens pas de là...

Question bête : si on binde les variables, est-ce que cela fige le plan d'exécution ?

Si les stats ne bougent pas, le plan reste le même et n'est meme pas re-calculé, j'ai juste un doute sur l'utilisation des histogrammes...

[aline]

Cependant, je reste persuadé que le problème ne viens pas de là.

+1

l m'a chargé une table avec 800 enregistrements et en resultat j'ai ça

SQL_TEXT_WO_CONSTANTS COUNT(*)
---------------------------------------------------------------- ----------
SELECT W_REP.IDENT_REPONSE,W_REP.IDENT_ITEM,W_REP.IDENT_POR,W_RE 220
1 row selected

En effet, si quand ca rame, tu n'as que 220 requêtes en mémoires non bindées, le problème ne vient pas de là.
Donc il faut continuer à chercher.
Maintenant, il vaut mieux binder quand même.Cela t'évitera bien des désagréments par la suite!

[nuke_y]

Si les stats ne bougent pas, le plan reste le même et n'est meme pas re-calculé, j'ai juste un doute sur l'utilisation des histogrammes...

Bah j'ai eu le cas où la même requête avec 2 valeurs différentes a 2 plans d'exécution, et surtout où un des 2 plans est complétement foireux. Mais les variables n'étaient pas bindées, d'où ma question.

[orafrance]

ça peut aussi venir des histogrammes, dans ce cas le plan change en fonction de l'échantillon de données sélectionné

[nuke_y]

Justement des histogrammes il n'y en a pas à ce que je sais, et on avait conclu qu'il faudrait essayer d'en utiliser pour voir. Enfin bon c'est pas le sujet.