[ASE]Remplissage du journal de log ? [Résolu]

[arona]

Bonjours a vous j'ai un journal de log sur une base avec 8 Go pour une base de 50 Go, mais elle a tendance depuis peu a être de plus en plus consomatrice d'espace, je voudrais savoir comment savoir qui consomme cela et pourquoi ?? Le sp_who ne me montre pas d'activité d'update ou autre pouvant justifier cela ??? Auriez-vous des pistes a investiguer pour avoir la solation a ce problème d'autant qu'avec la commande

Code :

dump tran toto WITH skip_transaction

cela me vide pratiquement intégralement mes logs ?
Merci à vous car mes opérationnel ne peuvent me répondre sur leurs applis

[mpeppler]

Euh... c'est quoi l'option "skip_transaction" ???

A part cela - il faut regarder dans master..syslogshold et dans master..systransactions pour voir qui tient une transaction ouverte. Il suffit qu'une transaction ancienne soit ouverte pour que la log grandisse et ne puisse pas être tronquée.

Michael

[arona]

pardon Mickael petit mélange entre ma prod et mon sujet

Code :

dump tran toto WITH truncate_only

...
en tout cas merci pour les infos je regarde.
A+
;-)

[arona]

ben j'ai vérifié sur tes deux tables system et aucune lignes sont présente ??? Mais mon espace de logs augmente...
Merci de ton aide

[kagemaru]

bizarre, tu dois au moins avoir un verrour posé qq part non ?

si tu fais un sp_lock tu dois au moins avoir une ligne avec un spid qui a un verrou sur une table / page / ligne de ta base ?

[arona]

Je suis toujours sur ce problème de remplissage de logs j'utilise les tables MDA et je ne trouve rien ni pourquoi ces logs se remplissent ....
Help en un mot

[kagemaru]

si tu fais un sp_lock tu dois au moins avoir une ligne avec un spid qui a un verrou sur une table / page / ligne de ta base ?

[arona]

bien oui j'ai un lock pour un select éffectivement, en "matchant" avec sysprocesses cela donne cela :

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
 
1> SELECT * FROM master..sysprocesses WHERE spid = 88
2> go
 spid   kpid        enginenum   STATUS       suid        hostname   program_name     hostprocess cmd
         cpu         physical_io memusage    blocked dbid   uid         gid
         tran_name                                                        time_blocked network_pktsz fid
         execlass                       priority   affinity                       id          stmtnum     linenum
         origsuid    block_xloid clientname                     clienthostname
         clientapplname                 sys_id ses_id      loggedindatetime           ipaddr
 ------ ----------- ----------- ------------ ----------- ---------- ---------------- ----------- ----------------
         ----------- ----------- ----------- ------- ------ ----------- -----------
         ---------------------------------------------------------------- ------------ ------------- ------
         ------------------------------ ---------- ------------------------------ ----------- ----------- -----------
         ----------- ----------- ------------------------------ ------------------------------
         ------------------------------ ------ ----------- -------------------------- ---------------
     88   622264498           1 running                1 srv-parsyb isql             7786        SELECT
                   8           0          11       0      4           1           0
         NULL                                                                     NULL           512      0
         EC2                            MEDIUM     ANYENGINE                                0           1           1
                NULL           0
                                             0           0        Jul  2 2007 12:15PM 10.210.1.129
 
(1 row affected)
1> sp_lock
2> go
The class COLUMN will display the cursor name FOR locks associated WITH a cursor FOR the current user AND the cursor id
FOR other users.
 fid    spid   loid        locktype                     table_id    page        row    dbname
         class                          context
 ------ ------ ----------- ---------------------------- ----------- ----------- ------ ---------------
         ------------------------------ ----------------------------
      0     88         176 Sh_intent                       12524047           0      0 master
         Non Cursor LOCK
 
(1 row affected)

mais un select peut remplire le journal de logs ? en plus le lock est sur master pas sur ma base de prod....

[fadace]

Un select qui ne demande pas de création de table temporaire (soit donc sans aggrégat, sans group by, ...), non.

Sinon, c'est souvent la tempdb qui est utilisée... ce qui fait qu'une tempdb pleine plante souvent la majeure partie des appels aux SP.

[mpeppler]

Euh... ce lock, ce ne serait pas ta propre session ?

(un select sur sysprocesses, ou une exécution de sp_lock va en principe poser un verrou "shared" sur l'une ou l'autre des tables système...)

Michael

[arona]

bon mon journal ne rempli plus j'ai mis en cron un dump tran toto truncate_only... Mais cela ne solutionne pas mon problème en plus j'ai regardé la tempdb et elle n'est pas solicitez ...

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1> sp_helpdb tempdb
2> go
 name                     db_size       owner                    dbid   created
         STATUS
 ------------------------ ------------- ------------------------ ------ ------------------
         ------------------------------------------------------------------------------------------------------
 tempdb                       1503.0 MB sa                            2 Jun 27, 2007
         SELECT INTO/bulkcopy/pllsort, trunc log ON chkpt, mixed log AND DATA
 
(1 row affected)
 device_fragments               size          usage                created                   free kbytes
 ------------------------------ ------------- -------------------- ------------------------- ----------------
 master                                3.0 MB DATA AND log         Nov 23 2006 11:43AM                   1786
 tempdb_data01                      1400.0 MB DATA AND log         Nov 23 2006  3:28PM                1427954
 tempdb_log01                        100.0 MB log only             Nov 23 2006  3:28PM       NOT applicable
 
 --------------------------------------------------------------
 log only free kbytes = 1531754
(RETURN STATUS = 0)

Yo no se ... ce qui se passe et comme nos développeurs communiques peu j'ai aucunes idées peut être installer historical et monitor server !!

[kagemaru]

elle est est "no options set" ta base toto ? C'est peut-être normal qu'il se remplisse ton log s'il n'y pas l'option 'trunc log on ckpt' ou si tu ne sauves pas régulièrement ton log dans un fichier ...

[mpeppler]

Ou si tu ne mets pas en place une sp_thresholdaction pour tronquer (ou sauver) la log quand elle passe un certain seuil.

Michael

[arona]

Ben sur ma base toto j'ai en option select into/bulkcopy/pllsort et pas le trunc log on chekpoint, mais comme le disait Mickael j'ai mis en place le threshold action donc mon problème n'est pas que cela block ma base mais plus tôt le "pourquoi" du remplissage incontroler des logs. En fait je veux trouver d'ou cela vient pour mettre "sans doute" en cause les derniers dev des équipes de "dev" justement....

[mpeppler]

Si tu n'as pas le "trunc. log on checkpoint" alors tes logs vont forcéments se remplir - jusqu'à ce que le seuil du sp_thresholdaction est atteint.

Donc pour moi le comportement de ta base est tout à fait normal.

Michael

[arona]

Oui je suis ok avec toi mais j'ai des scripts de dump automatique database ou log qui sont fait 2 X par jours donc que cela se rempli bcp plus qu'avant x 3 en terme d'espace et cela c'est pas normal... d'oû mon intérrogation Mickael

[mpeppler]

Dans ce cas j'ai vraiment mal compris ta question initiale...

Et tu as probablement simplement de l'activité de mise à jour plus importante qu'avant. Les tables MDA (monOpenObjectActivity) pourraient te renseigner sur quelles tables sont particulièrement touchées par ces mises à jour.

Michael

[arona]

Oui je dois avouer que j'ai mal posé ma question du début.... Je vais regarder la table MDA dont tu me parlais.
Thx