Discussion :

[sardin.pierre]

Bonjour,

je suis nouveau sur le forum mais aussi en SQL Server .

Pour vous faire un exposé rapide:

J'ai deux serveurs, un de production et un de back-up avec 3 instances chacun. Toutes les nuits chaque instances est répliquée sur le serveur de back-up a partir du serveur de production ( publication et abonnement).

Chaque instance possède un fichier *.mdf d'environ 400 Mo et un fichier *.ldf de 1 à 2 Go; ce qui aux vues des divers informations que j'ai pu lire sur ce forum semble tout à fait normal.

Mon problème est qu'une fois la réplication est réalisée, les fichiers *.ldf font presque 20 Go (en fait leur poids est multiplié par 10 mais cela n'est constaté qu'au bout d'un mois de production).

J'ai donc restauré une instance de production vers le back-up à la main (à l'aide d'un *.bak sur une instance de test) et le fichier *.ldf fait bien le même poids sur les deux serveurs (action réalisée ce jour).


Donc ma question est: est-il possible que lors de la réplication (en mode pull) les fichiers ldf s'incrémentent ? Si oui comment désactiver cette option?


Pour info il s'agit de haute disponibilité et non de sauvegarde (solution préconisé par l'entreprise qui nous a fournit une solution informatique basé sur SQL Serveur et s'engageant sur une réplication sans savoir la mettre en œuvre ).

J'ai été un petit peu long mais je préfère donner le plus d'info.

Je vous remercie par avance de m'avoir lu et vous remercie pour les informations que vous pourrez m'apporter.

Cordialement.

[SQLpro]

1) sans connaître le type de réplication (transactionnelle, snapshot, fusion, peer to peer) difficile de vous répondre.
2) une réplication n'est JAMAIS une solution de haute dispo. C'est d'une haute stupidité de présenter cela et prouve la méconnaissance crasse de certains professionnel.
3) en matière de haute dispo, prendre le mécanisme de réplication pour ce faire est non seulement stupide, mais pompe dramatiquement les ressources. Il convient d'utiliser soit le log shipping (mais latence importante), soit le mirroring de BD (disponible à partir de 2005) solution simplissime et temps réel, soit enfin le clustering (solution globale de serveur à serveur).

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...disponibilite/

A +

[sardin.pierre]

Pour commencer, merci d'avoir pris le temps de me répondre.

1/ Il s'agit d'une réplication de capture instantanée

2/ J'ai peut-être fait un abus de langage en parlant de haute disponibilité, en effet, la réplication ne s'effectue qu'une fois par nuit (donc par tranche de 24h), la haute disponibilité tenait au fait que le serveur de back-up est accessible en cas de panne du serveur de production.
Toutefois, concernant la méconnaissance de certains professionnel, je ne peux que vous rejoindre car mon expérience en cours me démontre qu'un prestataire peut vendre une solution basée sur SQL sans pouvoir en assurer la maintenance.

3/ La solution de réplication de capture instantanée semble néanmoins répondre à nos besoin en terme de perte acceptable de perte de donnée.

Merci d'avance.

[SQLpro]

Mais il serait beaucoup plus intéressant à tous niveau de faire ceci par exemple avec du LOG SHPPING. En effet, cela diviserait par un facteur 20 les ressources nécessaire à ce mécanisme et permettrait de diminuer le temps de latence (par exemple en descendant à 1h.

A +

[sardin.pierre]

Mais il serait beaucoup plus intéressant à tous niveau de faire ceci par exemple avec du LOG SHPPING. En effet, cela diviserait par un facteur 20 les ressources nécessaire à ce mécanisme et permettrait de diminuer le temps de latence (par exemple en descendant à 1h.

A +

Merci pour toutes ces informations.
Je ne suis pas décisionnaire concernant ce sujet, je ne peux que mettre en place cette solution pour l'instant. Les solutions apportées à ce jour par la société en charge de l'application sont des solutions paliatives et non pas des solutions curatives.

Je ne sais donc toujours pas pourquoi le fichier ldf est plus volumineux à chaque réplication sur le serveur de back-up et conserve sa taille normale sur le serveur de production.

Je vous remercie encore pour les éclaircissements que vous m'avez apportés.
Cordialement.

[SQLpro]

Je ne sais donc toujours pas pourquoi le fichier ldf est plus volumineux à chaque réplication sur le serveur de back-up et conserve sa taille normale sur le serveur de production.

Probablement parce que vous n'avez pas fait la maintenance nécessaire. En effet la réplication étant faite sur deux bases différentes (une réplication ne "clone" pas et les bases peuvent être totalement différentes car on réplique de articles qui sont des sous ensembles de tables : quelques lignes et quelques colonnes), il faut prévoir la même maintenance que sur une base de production, à savoir sauvegarde du JT, défragmentation, vérification d'intégrité des storages....

Bref, pour ne pas avoir pris le bon outil ou la bonne technique, vous allez devoir faire le double de boulot en plus de consommer un maximum de ressources !

A +

[sardin.pierre]

Probablement parce que vous n'avez pas fait la maintenance nécessaire. En effet la réplication étant faite sur deux bases différentes (une réplication ne "clone" pas et les bases peuvent être totalement différentes car on réplique de articles qui sont des sous ensembles de tables : quelques lignes et quelques colonnes), il faut prévoir la même maintenance que sur une base de production, à savoir sauvegarde du JT, défragmentation, vérification d'intégrité des storages....

Bref, pour ne pas avoir pris le bon outil ou la bonne technique, vous allez devoir faire le double de boulot en plus de consommer un maximum de ressources !

A +

Merci beaucoup pour toutes ces informations. Je crois que la meilleure solution serait de demander une formation en administration de serveur SQL.

Encore une fois merci pour tout.
Cordialement.

[abda1000]

Bonjour,
Votre problème est normal. Le fichier.ldf est fait pour sauvegarder toutes les transactions passées sur la base de données (On ne peut pas le supprimer mais on peut le vider facilement en faisant une sauvegarde)
Donc vous avez 3 réplications et chaque réplications inscrit beacoup des transactions dans le .ldf
Maintenant vous pouvez programmer des taches (via les plans de maintenance de Sqlserver ) afin de sauvegarder et vider les journaux de transactions après chaque réplication
Bonn chance

[sardin.pierre]

Bonjour,
Votre problème est normal. Le fichier.ldf est fait pour sauvegarder toutes les transactions passées sur la base de données (On ne peut pas le supprimer mais on peut le vider facilement en faisant une sauvegarde)
Donc vous avez 3 réplications et chaque réplications inscrit beacoup des transactions dans le .ldf
Maintenant vous pouvez programmer des taches (via les plans de maintenance de Sqlserver ) afin de sauvegarder et vider les journaux de transactions après chaque réplication
Bonn chance

Merci , je ne connaissais pas cette fonctionnalité.
Je vais explorer cette piste où je trouverai certainement aussi pourquoi l'application est extrêmement lente.

Cordialement.