Multiples requêtes techniques

[13thFloor]

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 ?

[mnitu]

Je ne comprends pas bien votre question.

D’où proviennent ces requêtes ?

Vous le dites par vous même

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.

[alexisongagna]

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 ? ...

[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

[13thFloor]

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

[jkofr]

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

[pachot]

Bonjour,

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

[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.