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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter
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" wrote in message 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.
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:213217BA-F7DA-44B3-B82E-299B37553747@microsoft.com...
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.
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" wrote in message 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
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
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.
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
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" wrote in message 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
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:6F2E03D9-4EC8-45D9-AA8C-37A3FE42F949@microsoft.com...
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.
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" wrote in message 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
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" wrote in message 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 >
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" <thelastjedi@discussions.microsoft.com> wrote in message
news:6F2E03D9-4EC8-45D9-AA8C-37A3FE42F949@microsoft.com...
> 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
>
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" wrote in message 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
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" wrote in message >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
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 <thelastj...@discussions.microsoft.com>
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" <thelastj...@discussions.microsoft.com> wrote in message
>news:6F2E03D9-4EC8-45D9-AA8C-37A3FE42F949@microsoft.com...
> > 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.
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" wrote in message >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.
