Multiples requêtes techniques

Version imprimable

Bonjour,
chez un de mes clients, je constate l'exécution de beaucoup de requêtes du type
Code:

1 2 3 4 5 6 7 select * from (select null TABLE_CATALOG, ac.owner TABLE_SCHEMA, ac.table_name TABLE_NAME, acc.column_name COLUMN_NAME, null COLUMN_GUID, null COLUMN_PROPID, acc.position ORDINAL from all_constraints ac, all_cons_columns acc where ac.owner = acc.owner and ac.table_name = acc.table_name and ac.constraint_type = 'P' and ac.constraint_name = acc.constraint_name) DBSCHEMA_PRIMARY_KEYS WHERE TABLE_SCHEMA ...
Elles sont exécutées par dizaines ou centaines et ce sont celles qui consomment le plus de temps CPU et surtout réseau (beaucoup de SQL*Net message from client).

Toutes les requêtes applicatives s'exécutent très vite mais celles-ci (que ej qualifie de requêtes techniques) apparaissent en top dans awr.
Elles proviennent de l'exécutable situé sur le poste client.

La configuration est :
client : 11.1.0.6 + OLEDB
serveur : 11.2.0.2/Solaris 10

D’où proviennent ces requêtes ?
Comment limiter leur nombre d'exécution ?

14/12/2012, 09h24
mnitu

Je ne comprends pas bien votre question.

Citation:

D’où proviennent ces requêtes ?

Vous le dites par vous même

Citation:

Elles proviennent de l'exécutable situé sur le poste client

Comment limiter leur nombre d'exécution ?

Ca c'est simple: ne pas les exécuter.

Salut,

Alors on formate le code en premier pour qu'il soit bien lisible :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 SELECT * FROM ( SELECT NULL TABLE_CATALOG, ac.owner TABLE_SCHEMA, ac.table_name TABLE_NAME, acc.column_name COLUMN_NAME, NULL COLUMN_GUID, NULL COLUMN_PROPID, acc.position ORDINAL FROM all_constraints ac, all_cons_columns acc WHERE ac.owner = acc.owner AND ac.table_name = acc.table_name AND ac.constraint_type = 'P' AND ac.constraint_name = acc.constraint_name ) DBSCHEMA_PRIMARY_KEYS WHERE TABLE_SCHEMA = ...
De ce que je vois, cette requete renvoit pour chaque schéma et toutes les tables du schéma la liste des colonnes qui constituent la clé primaire (de chaque table).

Le filtre TABLE_SCHEMA = ... permet d'avoir le détail pour un schéma (un compte) donné.

Cette requête exécutée plusieurs fois /seconde/minute/heure/jour provoque des soucis de perf, c'est sûre.

Le client qui balance cette requête est une appli java ? .net ? ...

16/12/2012, 23h26
jkofr

Hello,

Parfois des application utilisent ce genre de requête pour vérifier qu'un index existe afin d'optimiser la requête dynamique qui sera exécutée.

Par exemple l'application T24 de témenos fait cela constamment...
Pas une bonne chose mais pas le choix!

Il est possible de contourner un peu en créant 2 tables privées à votre schéma en dupliquant les 2 vues systèmes puis en créant un synonyme local.
Optimiser si besoin l'accès via un index.

Ne pas oublier de rafraichir le contenu des table si modification de l'application.
Et bien documenter le work-arround!
jko
17/12/2012, 09h35
13thFloor

Citation:

Envoyé par alexisongagna

Le client qui balance cette requête est une appli java ? .net ? ...

Je ne sais pas comment est conçue l'appli, elle requiert Provider Oracle pour OLE DB.
On dirait que l'appli recherche pour chaque table accédée les composants des clés primaires.

@jkofr : je vais essayer ton workaround

Hello,

Voici un exemple, a toi de positionner les index utiles.
Le bloc PL/SQL est requis car colonne de type LOB...

Code:

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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
 
 
 
Create table APPOWNER.APP_ALL_CONS_COLUMNS as select * from ALL_CONS_COLUMNS;
create synonym APPOWNER.ALL_CONS_COLUMNS for APPOWNER.APP_ALL_CONS_COLUMNS;
 
 
Create table APPOWNER.APP_ALL_CONSTRAINTS
(
OWNER                      VARCHAR2(30),
CONSTRAINT_NAME            VARCHAR2(30) NOT NULL,
CONSTRAINT_TYPE            VARCHAR2(1),
TABLE_NAME        	       VARCHAR2(30) NOT NULL,
SEARCH_CONDITION           LONG,
R_OWNER                    VARCHAR2(30),
R_CONSTRAINT_NAME          VARCHAR2(30),
DELETE_RULE                VARCHAR2(9),
STATUS                     VARCHAR2(8),
DEFERRABLE                 VARCHAR2(14),
DEFERRED                   VARCHAR2(9),
VALIDATED                  VARCHAR2(13),
GENERATED                  VARCHAR2(14),
BAD                        VARCHAR2(3),
RELY                       VARCHAR2(4),
LAST_CHANGE                DATE,
INDEX_OWNER                VARCHAR2(30),
INDEX_NAME                 VARCHAR2(30),
INVALID                    VARCHAR2(7),
VIEW_RELATED               VARCHAR2(14)
);
 
 
declare
Cursor GetData is Select * from all_constraints;
lRec all_constraints%rowtype;
 
Begin
OPEN   GetData;
LOOP
     FETCH GetData INTO lRec;
     EXIT WHEN GetData%NOTFOUND;
 
     Insert into APPOWNER.APP_ALL_CONSTRAINTS
        values
       (lRec.OWNER            ,
				lRec.CONSTRAINT_NAME  ,
				lRec.CONSTRAINT_TYPE  ,
				lRec.TABLE_NAME       ,
				lRec.SEARCH_CONDITION ,
				lRec.R_OWNER          ,
				lRec.R_CONSTRAINT_NAME,
				lRec.DELETE_RULE      ,
				lRec.STATUS           ,
				lRec.DEFERRABLE       ,
				lRec.DEFERRED         ,
				lRec.VALIDATED        ,
				lRec.GENERATED        ,
				lRec.BAD              ,
				lRec.RELY             ,
				lRec.LAST_CHANGE      ,
				lRec.INDEX_OWNER      ,
				lRec.INDEX_NAME      , 
				lRec.INVALID          ,
				lRec.VIEW_RELATED);
End Loop;
Close GetData;
commit;
End;
/
 
create synonym APPOWNER.all_constraints for APPOWNER.APP_ALL_CONSTRAINTS;

Jko

17/12/2012, 20h07
pachot

Bonjour,

Citation:

Envoyé par 13thFloor

ce sont celles qui consomment le plus de temps CPU et surtout réseau (beaucoup de SQL*Net message from client).

'SQL*Net message from client' n'est pas une consommation de ressource réseau. C'est le processus serveur qui attend d'avoir quelque chose à faire (attente 'un appel du client) -> aucune consommation de ressource.

Ca n'empêche pas d'essayer de comprendre, mais l'impact n'est peut être pas si important...

Cordialement,
Franck
19/12/2012, 08h50
13thFloor

La solution de Jko est intéressante et me permet de réduire considérablement le temps cpu.
Je vais continuer à investiguer.

Ce qui est casse pied c'est que pour 5' de temps, la base ne travaille que 30" et l'application client poireaute 2 à 3', avec un beau sablier et un écran blanc en attendant que les données ne s'affichent.