Discussion :

[msomso]

Bonjour

1. J'ai activé l'option "trunc log on chkpt" dans ma base.
2. J'effectue des maj en boucle et en volume important en mode non chainé

Code :

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

1
2
3
ceci est fait par une procédure appélée en boucle tant que @@rowcount <> 0
  set rowcount 10000
  update <ma_table> ....where colonne="xxx"

Dans ce contexte, il m'arrive d'avoir le message :
Msg 1105 ... Can't allocate space ...'logsegment' is full ...

Pouvez-vous m'aider à le comprendre:
D'après la doc officielle de Sybase: avec l'option "trunc log on chkpt", le log devait être vidé à chaque checkpoint déclenché par le serveur au bout de 50 transactions inscrites dans le log.

Pour quelle raison, les checkpoints ne sont pas déclenchés ?

Une autre fois: je lance en boucle (70 fois environ) les suppressions (aussi par 10000 lignes) en mode non chaîné => commités immédiatement => chaque transaction inscrite dans le log.

Cette fois, je n'ai pas d'erreur.
Mais pourquoi alors, un checkpoint manuel à la fin (par précaution) prends 6 minutes ?

Au moment des maj intesives, j'ai lancé:

Code :

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

sp_sysmon "00:05:00" recovery

et cela a donné seulement 5 checkpoints "normaux". Cela me paraît un peu juste, non ?

Auriez-vous des explications ? Comment augmenter la fréquence de mes checkpoints ? Ceci étant, je ne voudrais pas changer de paramétrage du serveur, car d'autres bases (de prod) y sont hebergées.

Merci d'avance
mso

[arona]

Pour avoir moins de problème match avec l'option "select into/bulkcopy/pllsort," et/ou positionne des "pat commit" toutes la 10 000 lignes. (je dis 10 000 mais je te fais cela au nez cela peut être moins et celon la dificulté pour scripter cela ...

[mpeppler]

L'erreur 1105 peut intervenir même si on a "trunc. log on checkpoint" si la taille du transaction log est trop petit par rapport à la taille des transactions effectuées.

Dans ton cas tu un update sur 10000 ligne par transaction. Si cet update est fait dans une boucle "sérrée" il est possible que le data server n'ait pas le temps de faire un truncate entre chaque transaction committée (cela dépend de la vitesse du système IO, de la vitesse du CPU, de la charge de la machine, etc).

Pour y voir un peu plus clair il faudrait savoir quelle est la taille de la transaction log sur cette base, et quelle est la taille d'une ligne que tu modifie ?

Michael

[msomso]

Bonsoir
La taille maxi de mon journal de transactions est 1 Go.
Pour la taille de la ligne, je regarde demain (sp_help <nom_table> suffit ?)

Mon update consiste à

• mettre un zero à la place de 3 float ,
• un null à la place d'un varchar et
• un zero à la place d'un entier.

Ceci pour dire que le serveur doit pouvoir faire son update sans delete et insert, je me trompe ?

J'ai lancé le même trt (boucle) après un checkpoint explicite (6 minutes) et cela s'est bien passé. Cependant j'ai restauré aussi la base (load) alors que l'autre fois le trt. a été lancé après plusieurs interruptions brutales suite aux erreurs. Aurait-il accumulé les écritures + transactions non terminées proprement ... ?

Arona,
je ne te comprends pas: l'option avec le bulk est bien positionnée sur ma base. Mais le "pat commit" ( voulais-tu dire "pas") ?
J'utilise le mode non chaîné, donc chaque delete engendre un commit implicite, je crois .... Je n'utilise pas d'instruction commit dans mon code.

Mon traitement consiste à:

1. Code :

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

   set rowcount 10000

2. Pour chaque mois présent dans ma table:
   

   Code :

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

   select @mon_sql = 'UPDATE  ... WHERE <nom_colonne> ='+@mon_mois

3. Ensuite je passe en paramètre @mon_sql à une procédure qui exécute cet ordre, en boucle, tant que @@rowcount < 10000 . Je fais cela pour fractionner mes maj et éviter des transactions trop longues.

Le traitement d'un mois dure environ 20-30 secondes (70 mois). Mais l'erreur du dépassement de log s'est produite au bout de quelques mois seulement. Par contre avant il y avait des delete en masse et les arrêts/relances sans rechargement de base.

Merci
mso
P.S.
Que-est-ce qui est écrit exactement dans le journal log pour un ordre de type "delete from ..." avec la suppression de 1000 lignes en une seule transaction. Cela donne une ou 1000 écritures dans le journal ?
Je crois qu'une seule, non ?

[mpeppler]

La taille d'une ligne peut être déduite via sp_help, ou alors via sp_estspace:

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
 
[197] DBA_SQL.monitordb.1> sp_estspace counterDefs, 10000;
 name           type      idx_level Pages        Kbytes
 -------------- --------- --------- ------------ ------------
 counterDefs    data              0         4692         9384
 counterDefs_pk clustered         0          103          206
 counterDefs_pk clustered         1            3            6
 counterDefs_pk clustered         2            1            2
 
(1 row affected)
 Total_Mbytes
 -----------------
              9.37
 
 name           type      total_pages  time_mins
 -------------- --------- ------------ ------------
 counterDefs_pk clustered         4800           18
 
(return status = 0)

ce qui te donne une estimation de la taille nécessaire pour 10000 lignes.

Un update va se faire "in place" en général, mais dans certaines circonstances un "deferred update" est nécessaire. Dans ton cas ce n'est à priori pas le cas, puisque la ligne ne va pas grandir (modification de colonnes de tailles fixes, et mise à NULL d'un varchar).

Comme rowcount est mis à 10000, chaque update s'applique à 10000 lignes (au maximum), et donc chaque transaction touche 10000 lignes. Ce qui fait 10000 entrées dans le journal (d'un seul tennant, mais c'est 10000 entrées quand même).

Normallement je suis d'accord, un journal de 1GB devrait suffire.

Est-ce qu'il y a d'autres process qui tournent en même temps que ton delete ?

Michael

[msomso]

Bonjour
sp_estspace affiche 2.4 Mo.

J'ai l'impression que le contexte du test (arrêts/relances) a favorisé la survenue de cette erreur. Je pense que nous allons attendre l'eventuelle réapparition du problème pour aller plus loin dans nos investigations.

Pour ta question Michael:
Oui sur le même serveur il y plsrs bases en production.
Merci
mso