[12.5.3] procedure stockée + log suspend [Résolu]

[dngaya]

Bonjour,
J'ai une base donnée instalée sur ASE 12.5.3. une procedure stockée appelée
ps_transfert_ngaya.sql a été mise en place par les études. lorsqu'il l'execute, le process se met en log suspend bien que le journal de transaction a été augmenté de 500 M et les données de la base de donnée en question fait 2000M.
Pour eviter d'augmenter indefinement le journal de transaction, je suppose peut-être que le problème provient de la procedure qui est a debuggué.
j'ai reussi a recuperé le plan d'execution avant que la procedure se plante en log suspend. n'ayant pas beaucoup de connaissance sur le tuning, pouvez-vous me dire ce qui ne va pas sur la procedure qui est en pièce jointe et le resultat du plan d'execution se trouve aussi en fichier attaché.
Merci.

Cordialement.

[dngaya]

Voir fichiers attachés ci-dessous

[mpeppler]

Quelle est la taille des tables dieudonne et ngaya ?
Combien de ligne de ngaya doivent être mise à jour dans la transaction?

C'est cette information qui va déterminer si l'opération peut tenir dans 500MB de log...

Michael

[dngaya]

Bonjour,
Voici les informations demandées:
Quelle est la taille des tables dieudonne et ngaya ?

reponse:
dieudonne:1493759 lignes
ngaya :o lignes
Combien de ligne de ngaya doivent être mise à jour dans la transaction?

près de 1,5 millions de mises à jour sur la table ngaya

Merci

[mpeppler]

Tu as des updates de type "deferred":

The type of query is UPDATE.
The update mode is deferred_varcol.
FROM TABLE

Cela implique un delete et un insert pour chaque ligne qui est mise à jour, et donc deux log records.

A mon avis il n'y a pas 36 solutions... Soit tu peux splitter les updates en plusieurs blocs, et ainsi limiter la taille de la log utilisée, soit il faut agrandir la log.

Michael

[dngaya]

Merci de vos reponses qui sont très pertinentes . par contre comment puis-je faire pour splitter les updates en plusieurs blocs ? avez-vous un exemple, cela me permettra de demander aux developpeurs de le faire.

[mpeppler]

Déjà il faut voir si cela est faisable d'un point de vue applicatif/utilisateurs:

Si on split l'opération alors on pourrait se retrouver dans une situation où une partie seulement de l'update/insert est passé (p.ex. si il y a une erreur sur un des blocs). Si ce genre de situation est acceptable (p.ex. elle peut être corrigée à la main si nécessaire), alors on peut splitter l'opération avec des clauses WHERE, éventuellement aussi en utilisant le SET ROWCOUNT.

Par exemple, pour effacer un gros blocs de lignes dans une table, on peut faire:

Code :

1
2
3
4
5
6
7
8
9
10
 
declare @rows int
SELECT @rows 1000
SET rowcount @rows
 
while @rows > 0
begin
    DELETE FROM ma_table WHERE <.......>
    SELECT @rows = @@rowcount
end

ce qui va effacer les lignes par blocs de 1000. Comme il n'y a pas de transaction autour de l'opération on pourra faire des dump tran (soit via l'option "trunc. log on checkpoint", soit avec des dump tran explicite ou avec des sp_thresholdaction) pour que la log ne se remplisse pas.

A voir si ce genre de téchnique est applicable dans le cas présent.

Michael