Réplication et log full : y a-t-il un lien ?

Le
thelastjedi
Bonjour,


J'ai un problème qui devient récurrent et surtout se reproduit sur un
ensemble de machines qui forment un schema type "alimentation de
datawarehouse".

Ces machines ont en commun :
- d'être virtualisées sous VMWare / ESX Server,
- d'être équipées de SQL Server 2005 (toutes SP1 sauf une en SP2) ,
- d'être installées en Windows Server 2003 R2 SP1,
- d'avoir chacune une publication en réplication snapshot d'une base
différente (compatibilité 2000) vers la 4ème machine commune (datawarehouse),
- que les bases répliquées soient en mode simple,
- que les bases répliquées puissent faire l'objet d'imports de données (de
taille variable) par le biais de bulk-copy en ligne de commande ou de lots
SSIS.
- que les bases répliquées aient des plans de maintenance et des
programmations presque identiques,
- que les bases répliquées soient en log de taille fixe et suffisante pour
la production.

Mon problème est que (seulement certains jours et - pour l'instant - jamais
deux machines en même temps) le journal de transactions se remplit à 100%,
n'est pas purgé et fait donc planter tous les traitements qui essayent
d'accéder aux bases répliquées.

Chronologiquement, les étapes nocturnes sont :
1 - maintenance quotidienne (cohérence, dump, defrag d'index, etc)
2 - snapshot
3 - réplication des données de l'instantané.

Quand -à mon arrivée, quand tout est bloqué - j'inspecte la valeur de la
colonne log_reuse_wait_desc de sys.databases, j'ai toujours (les jours de
plantage) la valeur "REPLICATION". Le checkpoint semble inefficace, le backup
log xxxxx with no_log au moins autant, le seul remède est d'augmenter un peu
la taille du log, forcer sa vidange et faire sauter la réplication, puis la
reconstruire.

Ce qui m'intrigue, c'est que le log peut être plein avant même que la
réplication (snapshot ou transfert de données) n'ai démarré, avant même
d'ailleurs la maintenance nocturne, alors pourquoi cette valeur "REPLICATION"
?!!

J'espère avoir été assez factuel. :)

Quelqu'un a-t-il une piste qui me sorte de ce cauchemar ?
Merci.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
bruno reiter
Le #17523761
S'il s'agit de réplication transactionnelle, certaines transactions sont
"marquées pour la réplication" et empêchent la purge du log tant que l'agent
"log reader" n'est pas passé pour les récupérer.

DBCC OPENTRAN le montre

HTH

BR

"thelastjedi" news:
Bonjour,


J'ai un problème qui devient récurrent et surtout se reproduit sur un
ensemble de machines qui forment un schema type "alimentation de
datawarehouse".

Ces machines ont en commun :
- d'être virtualisées sous VMWare / ESX Server,
- d'être équipées de SQL Server 2005 (toutes SP1 sauf une en SP2) ,
- d'être installées en Windows Server 2003 R2 SP1,
- d'avoir chacune une publication en réplication snapshot d'une base
différente (compatibilité 2000) vers la 4ème machine commune
(datawarehouse),
- que les bases répliquées soient en mode simple,
- que les bases répliquées puissent faire l'objet d'imports de données (de
taille variable) par le biais de bulk-copy en ligne de commande ou de lots
SSIS.
- que les bases répliquées aient des plans de maintenance et des
programmations presque identiques,
- que les bases répliquées soient en log de taille fixe et suffisante pour
la production.

Mon problème est que (seulement certains jours et - pour l'instant -
jamais
deux machines en même temps) le journal de transactions se remplit à 100%,
n'est pas purgé et fait donc planter tous les traitements qui essayent
d'accéder aux bases répliquées.

Chronologiquement, les étapes nocturnes sont :
1 - maintenance quotidienne (cohérence, dump, defrag d'index, etc...)
2 - snapshot
3 - réplication des données de l'instantané.

Quand -à mon arrivée, quand tout est bloqué - j'inspecte la valeur de la
colonne log_reuse_wait_desc de sys.databases, j'ai toujours (les jours de
plantage) la valeur "REPLICATION". Le checkpoint semble inefficace, le
backup
log xxxxx with no_log au moins autant, le seul remède est d'augmenter un
peu
la taille du log, forcer sa vidange et faire sauter la réplication, puis
la
reconstruire.

Ce qui m'intrigue, c'est que le log peut être plein avant même que la
réplication (snapshot ou transfert de données) n'ai démarré, avant même
d'ailleurs la maintenance nocturne, alors pourquoi cette valeur
"REPLICATION"
?!!...

J'espère avoir été assez factuel. :)

Quelqu'un a-t-il une piste qui me sorte de ce cauchemar ?
Merci.


thelastjedi
Le #17524451
Ainsi que je le disais dans l'énoncé, il s'agit de réplications snapshot, pas
transactionnelle.

Comme il s'agit de bases de 25 à 40 Go dont seule une petite partie des
données est modifiée, il est prévu de basculer vers une solution
transactionnelle, style "log shipping". J'ai préféré mettre en place une
solution stable d'abord, donc simple. ;)

Merci de la réponse.

"bruno reiter" wrote:

S'il s'agit de réplication transactionnelle, certaines transactions sont
"marquées pour la réplication" et empêchent la purge du log tant que l'agent
"log reader" n'est pas passé pour les récupérer.

DBCC OPENTRAN le montre

HTH

BR


bruno reiter
Le #17529441
que dit le DBCC OPENTRAN?

peut etre ceci peut aider? http://support.microsoft.com/kb/317375/en-us#7

éventuellement faire sp_repldone sur la base peut supprimer le pb
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time =
0, @reset = 1

BR

"thelastjedi" news:
Ainsi que je le disais dans l'énoncé, il s'agit de réplications snapshot,
pas
transactionnelle.

Comme il s'agit de bases de 25 à 40 Go dont seule une petite partie des
données est modifiée, il est prévu de basculer vers une solution
transactionnelle, style "log shipping". J'ai préféré mettre en place une
solution stable d'abord, donc simple. ;)

Merci de la réponse.

"bruno reiter" wrote:

S'il s'agit de réplication transactionnelle, certaines transactions sont
"marquées pour la réplication" et empêchent la purge du log tant que
l'agent
"log reader" n'est pas passé pour les récupérer.

DBCC OPENTRAN le montre

HTH

BR





thelastjedi
Le #17533631
Ce problème ne semble pas avoir d'écho auprès des collègues DBAs à ce que je
vois. J'en déduis qu'il doit être marginal et très contextuel... Merci
d'autant plus de te préoccuper de mon sort ! :)

Le souci, c'est que ce "bug" arrive BIEN-SUR uniquement quand je ne suis pas
devant ma console (le soir, le week-end)... :(

Je viens de mettre DBCC OPENTRAN en fonction dans une alerte type
"syslogs>99%" avec communication par DBMail , mais je n'ai pas encore de
retour.

Pour l'article de la KB, je l'avais déjà regardé, mais seules 2 conditions
sont compatibles avec mon contexte. Toutes deux tournent autour des
transactions (uncommitted et extremely large). DBCC REINDEX intervient après
le début des problèmes, donc on peut l'exclure, non ?

Merci encore.
"bruno reiter" wrote:

que dit le DBCC OPENTRAN?

peut etre ceci peut aider? http://support.microsoft.com/kb/317375/en-us#7

éventuellement faire sp_repldone sur la base peut supprimer le pb
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time =
0, @reset = 1

BR

"thelastjedi" news:
> Ainsi que je le disais dans l'énoncé, il s'agit de réplications snapshot,
> pas
> transactionnelle.
>
> Comme il s'agit de bases de 25 à 40 Go dont seule une petite partie des
> données est modifiée, il est prévu de basculer vers une solution
> transactionnelle, style "log shipping". J'ai préféré mettre en place une
> solution stable d'abord, donc simple. ;)
>
> Merci de la réponse.
>
> "bruno reiter" wrote:
>
>> S'il s'agit de réplication transactionnelle, certaines transactions sont
>> "marquées pour la réplication" et empêchent la purge du log tant que
>> l'agent
>> "log reader" n'est pas passé pour les récupérer.
>>
>> DBCC OPENTRAN le montre
>>
>> HTH
>>
>> BR
>




SQLpro
Le #17557081
Bonjour,

=> d'être virtualisées sous VMWare / ESX Server,

pas bon... Un serveur SQL se virtualise mal. Comme il est très
consommateur de ressources de toutes natures et possède son propre OS
(SQL OS ou SOS) alors c'est perturbant pour lui et conduit à des
performances TRES ERRATIQUE... ce que tu sembles avoir !

=> d'avoir chacune une publication en réplication snapshot d'une base
différente (compatibilité 2000) vers la 4ème machine commune
(datawarehouse),

quel est le temps de latence ?

=> que les bases répliquées soient en log de taille fixe et suffisant e
pour
la production.

idiot ! Que tu les taille suffisamment large c'est OK. mais que tu en
empêche la croissance c'est pas bon du tout. Il faut toujours laisser
une porte de sortie...

Apparemment vous répliquez une fois par nuit. Augmentez la fréquence
ou alors cahngez votre stratégie en faisant un restore complet.

A +




On 15 oct, 11:41, thelastjedi wrote:
Ce problème ne semble pas avoir d'écho auprès des collègues DBAs à ce que je
vois. J'en déduis qu'il doit être marginal et très contextuel... Me rci
d'autant plus de te préoccuper de mon sort ! :)

Le souci, c'est que ce "bug" arrive BIEN-SUR uniquement quand je ne suis pas
devant ma console (le soir, le week-end)... :(

Je viens de mettre DBCC OPENTRAN en fonction dans une alerte type
"syslogs>99%" avec communication par DBMail , mais je n'ai pas encore de
retour.

Pour l'article de la KB, je l'avais déjà regardé, mais seules 2 con ditions
sont compatibles avec mon contexte. Toutes deux tournent autour des
transactions (uncommitted et extremely large). DBCC REINDEX intervient ap rès
le début des problèmes, donc on peut l'exclure, non ?

Merci encore.

"bruno reiter" wrote:
> que dit le DBCC OPENTRAN?

> peut etre ceci peut aider?http://support.microsoft.com/kb/317375/en-us# 7

> éventuellement faire sp_repldone sur la base peut supprimer le pb
> EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,  @time =
> 0, @reset = 1

> BR

> "thelastjedi" >news:
> > Ainsi que je le disais dans l'énoncé, il s'agit de réplications snapshot,
> > pas
> > transactionnelle.

> > Comme il s'agit de bases de 25 à 40 Go dont seule une petite partie des
> > données est modifiée, il est prévu de basculer vers une solutio n
> > transactionnelle, style "log shipping". J'ai préféré mettre en place une
> > solution stable d'abord, donc simple. ;)

> > Merci de la réponse.

> > "bruno reiter" wrote:

> >> S'il s'agit de réplication transactionnelle, certaines transaction s sont
> >> "marquées pour la réplication" et empêchent la purge du log ta nt que
> >> l'agent
> >> "log reader" n'est pas passé pour les récupérer.

> >> DBCC OPENTRAN le montre

> >> HTH

> >> BR


Publicité
Poster une réponse
Anonyme