Discussion :

[arona]

J'ai mis les table MDA mais je ne trouve pas ou se trouve le code sql qui est éxécuté en ce moment, je pensais que c'était dans les tables monProcessSQLText ou monSysSQLText mais rien de spécial ou plustôt que des "1"...
une idée ???

[mpeppler]

monProcessSQLText contient le SQL des requêtes actives actuellement. Le contenu de cette table est très furtif, puisque les données disparaissent dès que la requête se termine.

monSysSQLText contient des données "historiques" (en faite c'est un tuyaux avec une longueur définie, et qui se vide quand on le lis).

Pour que le SQL soit monitoré il faut que les paramètres sp_configure suivants soient positionnés: "SQL batch capture", "sql text pipe active", "sql text pipe max messages" et "max SQL text monitored".

Michael

[Fabien Celaia]

sinon, essayez sp__showplan
ou utilisez le monitor server

[arona]

Merci de ces explication mais cela ne résoud pas mon problème... Quel est mon problème vas tu me demander !! et bien j'ai des utilisateur qui s'occupe d'un progiciel s'appuyant sur une BDD sybase, ils ont lancé une augmentation de niveau et vous vous en doutez cela fait des upgrades dans les bases, comme leur traitements est lancé depuis Dimanche matin je voulais trouver le code sql afin de trouver sur quel collones tapait cette upgrade afin que je puisse mettre des indexs ... Vila comme la table fait 40 millions de rows un ou deux indexes pourraient être pas mal ... Si vous avez une autre idée je suis preneur

[mpeppler]

Dans ce cas, la première chose à identifier est le ou les SPID qui sont actifs et qui font le traitement d'upgrade.

Ensuite, exécute sp_showplan sur ce (ou ces) SPID, pour voir le plan d'exécution et les tables qui sont affectées. Si c'est un upgrade il s'agit probablement d'une ou plusieurs procedures SQL qui s'exécutent en boucle, ce qui peut évidement rendre l'analyse plus complexe.

Une fois que tu as le showplan il faudra voir ce qui peut être lent dans l'opération, et peut être que qqch d'aussi simple comme un update statistics pourrait améliorer la situation.

Michael

[arona]

j'ai bien les options défini a ce que tu explique mais j'ai eu leur requète. Je vous la "colle" ici, mais une rapide lecture et moi je préconiserai la création d'un index non unique et passer le requète, car détruire l'index pour le reconstruire en unique je pense que c'est pas top. votre avis ??

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
create table TB_ALLOCATION_AUDIT_TRAIL
(
 TIMESTAMP              DT_TIMESTAMP            NOT NULL,
 AUDIT_ID               DT_ALLOCATION_AUDIT_ID  NOT NULL,   /* PRIMARY KEY */
 CL_USER_ID             integer                 NULL,
 CL_EVENT               char(5)                 NULL,
 CL_EVENT_TIME          datetime                NULL,
 CL_TRADE_ID            DT_TRADE_ID             NULL,
 CL_TRADE_VERSION       integer                 NULL,
 CL_ALLOCATION_ID       DT_ALLOCATION_ID        NULL,
 CL_ALLOCATION_VERSION  integer                 NULL,
 CL_DESCRIPTION         varchar(160)            NULL,
 CL_AUDIT_ID            integer                 NULL,       /* Obsolete */
 UPDATE_COUNT           int                     NULL,
 UPDATE_USER            DT_USER_NAME            NULL,
 UPDATE_DATE            datetime                NULL
)
go
 
if @@error = 0
begin
    print "TB_ALLOCATION_AUDIT_TRAIL: table created."
end
go
 
if not exists
(
    select 1 from sysindexes
    where name = "TB_ALLOCATION_AUDIT_TRAIL_1"
)
begin
    create unique index TB_ALLOCATION_AUDIT_TRAIL_1 on TB_ALLOCATION_AUDIT_TRAIL
    ( AUDIT_ID )
end
go
 
grant select on TB_ALLOCATION_AUDIT_TRAIL to FDA_GRP_REPORT
go

[mpeppler]

Euh... sans connaitre la requête, et sans connaitre le SHOWPLAN il est difficile de faire une recommendation!

:-)

Michael

[arona]

Oui oui je sais c'était juste pour commenter mon discour.... . Non je ne demande plus de conseil pour cette requète
Non par contre quel configuration serveur peu amélioré les perfs pour tout ce qui concersn les select ?? outre le paramétrage mémoir pour les % de prock stock???

[mpeppler]

Améliorer les perfs pour les selects... à priori la cache, et d'avoir un pool 16k "suffisant". Si une table est petite et très utilisée on peut créer une cache juste pour cette table pour s'assurer qu'elle est toujours en mémoire.

Michael

[arona]

mouais c'est grosso modo ce que j'ai fais. Merci pout tout.
slt

[Gauthde]

sinon, essayez sp__showplan
ou utilisez le monitor server

Bonjour,

Il Il y a aussi une commande trés pratique pour connaître le code sql en court d'exécution:

dbcc traceon(3604)
dbcc sqltext(spid)

A voire

[mpeppler]

Pour ceux qui sont à la pointe du progrès (cad en 15.0.2!) on peut maintenant créer des fichiers traces pour sa propre session, ou pour une autre session:

Code :

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

1
2
3
 
set trace <nom_fichier> for <spid>
go

Ensuite si on met set showplan, etc ces informations sont directements placées dans le fichier trace.

Evidemment c'est une fonctionallité qui n'est pas vraiment d'actuallité pour la pluspart d'entre nous (puisque on est encore assez peu nombreux à être en 15.x), mais c'est peut être un argument de plus pour aller dans cette direction.

Michael