[2005] Réplication ou DTS ?

Version imprimable

14/04/2010, 18h07
ApprentiOracle

[2005] Réplication ou DTS ?

Bonjour,

Nous avons une base version SQLserver 2005 sur un serveur sur un site distant.

Les utilisateurs voudraient avoir une copie de la base en local.

Mes questions :

Que faut il utiliser : Une réplication ou les lots DTS ? (pour infos la base 1Go, data et log compris)

Est ce que on peut utiliser une sqlserver2005 express pour l'une ou l'autre technique ?

Merci beaucoup pour vos infos.

Cordialement

ApprentiOracle
14/04/2010, 22h52
dbaffaleuf

Hello,

Le problème de la réplication à mon sens c'est qu'il faut pouvoir la gérer, et ce n'est pas le truc le plus simple du monde. Il faut en plus éviter de mettre à jour la base répliquée, et si tes utilisateurs ont besoin d'accéder aux données aussi en écriture, c'est difficilement viable comme solution.

Quelle est le besoin en termes de fraîcheur des données ? 1 fois par jour ? 2 fois par jour ? 1 fois par heure ? Au fil de l'eau, etc...

En fonction de cette information, différentes possibilités sont envisageables.

David B .
14/04/2010, 23h38
SQLpro

Notamment un mirroring avec snapshot si la base répliquée est en lecture seule.

A +
14/04/2010, 23h46
zinzineti

Pour compléter dbaffaleuf, pourquoi les utilisateurs ont-ils besoin chacun d'avoir la base en local ? Est-ce pour des raisons de mobilité de ces utilisateurs ? ce sont des commerciaux ? cette question en cache une autre, celle de la mise à jour des données. La mise à jour est-elle dans les 2 sens (synchronisation dans les 2 sens) ? En gros c'est quoi le besoin ?

A+

Etienne ZINZINDOHOUE
15/04/2010, 09h17
ApprentiOracle

Bonjour à tous,

Pour répondre aux différentes questions :

- Le besoin en terme de données est de 1 seule fois par jour.
- La base en local sera en lecture seule. (Ils n'ont pas besoin d'avoir CHACUN une base en local, ca sera une seule pour tous)
- Si réplication, ca ne sera que dans un sens.
- Le besoin, c'est un sorte de infocentre.

Merci
15/04/2010, 10h13
kagemaru

Dans ce cas là, je ferais un backup de la base, je zipperais le backup, le transfererais et le restaurerais en local. Je ne vois pas l'intêret de faire plus compliqué.
15/04/2010, 11h40
dbaffaleuf

Pareil ;-)

David B.
15/04/2010, 14h05
ApprentiOracle

Ok.

Et le log shipping ? C'est pas mal non plus et ca à l'air d'être simple à mettre en oeuvre. Quand pensez vous ?
15/04/2010, 14h12
Ptit_Dje

Comparé à un backup/restore, le log shipping implique plus de complexité même s'il est simple à mettre en oeuvre.
Il implique aussi que la base de donnée source soit en mode de recovery FULL.
Si les utilisateurs souhaitent un rafraichissement de donnée 1 fois par jour, le log shipping va modifier les données de la base restaurée, et donc les données de midi seront différentes de celles du matin et de celles du soir. C'est à prendre en considération aussi selon l'usage souhaité de la base.

Un backup/restore permet aussi de pouvoir donner des droits en écriture sur la base (par exemple pour implémenter des index spécifiques pour des requètes de reporting...).

Après à vous de voir.
15/04/2010, 15h46
zinzineti

Citation:

Envoyé par kagemaru

Dans ce cas là, je ferais un backup de la base, je zipperais le backup, le transfererais et le restaurerais en local. Je ne vois pas l'intêret de faire plus compliqué.

Cette solution, je suis d'accord est la plus simple. Mais simple en apparence ;)
Elle est simple si on le fait de façon MANUELLLE.
Mais si c'est à automatisée (donc scriptée) , là, ce n'est plus aussi simple !
Démonstration :
1. Backupé -> simple à scripté
2. Zippé le backup -> pas aussi simple, mais faisable
3. transféré le zip -> dépend fortement du réseau, de la taille du zip,
des problèmes de droits de lecture/ecriture sur disque,...
4. Dézippé le backup -> pas simple à scripté :
Gestion des zips dans le répertoire de
destination pour prendre en compte le bon
zip à dézipé, etc....
5. Restauré le backup -> simple à scripté
Au vue de tout celà, le mode automatique n'est pas aussi simple à mon avis.

Par contre si ces opérations doivent se faire manuellement, alors se pose la question de :
Qui va le faire ?
Quand (à 1H du matin ?) faut-il le faire ?
Et pendant les vacances qui va le faire ? et les imprévus ?....
Je suis plutôt pour une REPLICATION TRANSACTIONNELLE planifiée pour se lancer une fois/jour tous les soirs vers 23H.

Au suivant ...

Etienne ZINZINDOHOUE
15/04/2010, 16h06
Ptit_Dje

Je dirais non à la réplication transactionnelle.
Celle-ci à une granularité au niveau de l'objet, et de plus provoque une retention des entrées dans le journal de transaction, ce qui ne permet pas de recycler celui-ci après un log backup.

Si effectivement le volume du backup est relativement important, un log shipping peut être approprié, cependant pas disponible sur la version SQL Express.

D'ailleurs, étant donné la version de SQL Server, la base de donnée ne devrait pas faire plus de 4GB. Donc un backup/restore ne devrait pas poser de problème.

On peut éviter l'étape du zippage d'après moi, sauf si on a du temps à consacrer à ca...

Pour répondre à Etienne, exemple d'un fichier .BAT (non testé), lancé automatiquement par le planificateur de tâches, avec un utilisateur ayant les droits sur les 2 serveurs aui supposons-le sont sur le même réseau:
Code:

1 2 3 4 5 6 sqlcmd -S serveur_local -Q"backup database mabase to disk='c:\mabase.bak'" -E compact /c c:\mabase.bak copy c:\mabase.bak \\mon_serveur\c$\mabase.bak compact /u \\mon_serveur\c$\mabase.bak sqlcmd -S serveur_distant -Q"restore database mabase from disk='c:\mabase.bak' with replace, etc...." -E del \\mon_serveur\c$\mabase.bak
compact.exe, natif à windows, a qq limitations, par exemple, il faut que le volume ntfs ait la taille de cluster par défaut.

15/04/2010, 17h44
zinzineti

1.

Citation:

copy c:\mabase.bak \\mon_serveur\c$\mabase.bak

Si et seulement si le compte service de SQL Server à le droit d'écriture sur le serveur \\mon_serveur\c$\
N'oublions que seul 2 types de comptes de service permettent de se connecter sur une machine distante via un lecteur de réseau mappé :
- Network Service : généralement c'est le compte local qui est utilisé lors de l'installation de sql server => donc le modifié si possible...
- et un compte utilisateur du domaine. Celà impose que les 2 serveurs soient dans 1 même domaine... !

2.

Citation:

fichier .BAT (non testé), lancé automatiquement par le planificateur de tâches, avec un utilisateur ayant les droits sur les 2 serveurs aui supposons-le sont sur le même réseau:

Si et seulement si SQL Agent le planificateur de tâche de SQL Server est configuré comme un compte de service type :
- Network Service
- ou compte du domaine. => Modification de la configuration du service SQL Agent !
Pensez à l'impact que celà pourrait avoir sur les autres applications qui utilise SQL Agent ....!

A+

Etienne ZINZINDOHOUE
15/04/2010, 19h10
SQLpro

Vous vous emmerdez beaucoup la vie pour des conneries !!! En effet autant faire simple et direct en utilisant le mirroring.
Une fois le miroir de la base mis en place avec le script que j'ai donné ici :
http://blog.developpez.com/sqlpro/p7...-base-de-donn/
Il suffit de faire un snapshot de la base avec la commande :
CREATE DATABASE XXX ... AS SNAPSHOT OF YYYY
J'ai aussi fait un script pour générer le snapshot :
http://blog.developpez.com/sqlpro/p5...n-snapshot-de/
Il suffit de le planifier toutes les nuit dans l'agent SQL en supprimant préalablement la base snapshot avec DROP DATABASE !

AVANTAGES

1) vous disposez d'une base de secours en cas de crash de la base principale et cette base miroir peut même être synchrone (aucune perte de données en cas de défaillance du serveur principal et basculement automatique des applications !)
2) vous avez votre base de reporting (le snapshot) en READ ONLY, c'est à dire qu'aucune mise à jour ne peut être fait et il n'y a aucun verrous de poser lors des SELECT...

Bref, simplicité, secours et performances !

A +
16/04/2010, 09h01
Ptit_Dje

Ce n'est pas supporté sur une version Express, ni le mirroring, ni le snapshot des bases.
16/04/2010, 09h31
kagemaru

Citation:

Bref, simplicité, secours et performances !

Paye ta licence pour le snapshot (Enterprise Edition nécessaires) et puis encore une fois, plus de monitoring, plus de compétences nécessaires. Donc en effet, si tu as de l'argent à balancer et que ton besoin de copie de base en local est vital, je pense que le miroir est la meilleure solution.

Pour encore répondre à Etienne, ces traitements ne sont pas lancés par SQL Server. Le planificateur de tâches, ce n'est pas le SQL Agent mais le Planificateur de tâches (jusched.exe). Au pire, rien ne t'empêche de faire tourner le job avec un compte windows qui a des droits locaux sur chaque serveur et d'utiliser un compte SQL pour lancer les jobs.
16/04/2010, 14h46
ApprentiOracle

Citation:

Envoyé par Ptit_Dje

Ce n'est pas supporté sur une version Express, ni le mirroring, ni le snapshot des bases.

C'est supporté par du standard edition ?
16/04/2010, 14h58
ApprentiOracle

Citation:

Envoyé par ApprentiOracle

C'est supporté par du standard édition ?

A priori, j'aurais des standard editions. Et je n'ai plus 1 base d'une instance mais 5. En tout elles sont relativement petites 1Go au total.

A priori le log shipping c'est mort. Car la base "destinatrice" n'est pas ouvert aux utilisateurs.

La réplication m'a l'air assez difficile à mettre en oeuvre.

Le mirroring et snapshot demande une enterprise edition :(

Je crois que je vais tester la mise à jour de la base local via une restauration basique :(

En tout cas merci pour votre aide à tous, cela m'a permis de voir les avantages et defaut de toutes ces techno.
16/04/2010, 15h01
Ptit_Dje

Le mirroring oui, avec certaines restrictions:
Single REDO thread and the safety setting is always on.

Les snapshots, non, c'est uniquement une feature Enterprise. Donc vous ne pourrez pas lire votre base de données mirrorée.
16/04/2010, 15h45
mikedavem

Bonjour,

Je pense qu'il faut te concentrer sur ton besoin ...

Si on les reprend :

- 1 seule fois par jour.
- La base en local sera en lecture seule
- Le besoin, c'est un sorte de infocentre.

Il me semble que pour un simple besoin d'infocentre une version standard suffit avec une simple copie de ta base à planifier une fois par jour (avec les commandes backup et restore)

Est ce que tes données doivent être "fraîches" ?
Si ce n'est pas nécessaire, pourquoi implémenter quelque chose de plus complexe (mirroring, réplication ...) l'administration est quand même plus lourde
Dans le cas contraire effectivement une des autres solutions peut te convenir ..

++