Bonjour,
Je suis à la recherche des différentes possibilités d'avoir en finalité
sur
deux serveurs 2k (A et B) sur deux sites distant, le double d'une base SQL
2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
avec le serveur A. D'après mes connaissances (car je ne suis pas un
spécialiste de SQL 2k), la sauvegarde/restauration peut être une solution,
la duplication (+complexe), l'export/import.....Je n'est pas de contrainte
de temps réel... pour les données, au pire J-1. Les données non pas besoin
d
'être synchronisées dans les deux sens, simplement de A vers B. Eh oui !!
Çà
a l'ère simple. !
Merci d'avance de vos propositions.
Cordialement
Bonjour,
Je suis à la recherche des différentes possibilités d'avoir en finalité
sur
deux serveurs 2k (A et B) sur deux sites distant, le double d'une base SQL
2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
avec le serveur A. D'après mes connaissances (car je ne suis pas un
spécialiste de SQL 2k), la sauvegarde/restauration peut être une solution,
la duplication (+complexe), l'export/import.....Je n'est pas de contrainte
de temps réel... pour les données, au pire J-1. Les données non pas besoin
d
'être synchronisées dans les deux sens, simplement de A vers B. Eh oui !!
Çà
a l'ère simple. !
Merci d'avance de vos propositions.
Cordialement
Bonjour,
Je suis à la recherche des différentes possibilités d'avoir en finalité
sur
deux serveurs 2k (A et B) sur deux sites distant, le double d'une base SQL
2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
avec le serveur A. D'après mes connaissances (car je ne suis pas un
spécialiste de SQL 2k), la sauvegarde/restauration peut être une solution,
la duplication (+complexe), l'export/import.....Je n'est pas de contrainte
de temps réel... pour les données, au pire J-1. Les données non pas besoin
d
'être synchronisées dans les deux sens, simplement de A vers B. Eh oui !!
Çà
a l'ère simple. !
Merci d'avance de vos propositions.
Cordialement
Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
répliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
régulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
coûteuse.
S. L.
"Jim" wrote in message
news:cffvok$tto$
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
> la duplication (+complexe), l'export/import.....Je n'est pas de
> de temps réel... pour les données, au pire J-1. Les données non pas
> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
répliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
régulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
coûteuse.
S. L.
"Jim" <ext.boyer@sncf.fr> wrote in message
news:cffvok$tto$1@muguet.sncf.fr...
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
> la duplication (+complexe), l'export/import.....Je n'est pas de
> de temps réel... pour les données, au pire J-1. Les données non pas
> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
répliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
régulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
coûteuse.
S. L.
"Jim" wrote in message
news:cffvok$tto$
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
> la duplication (+complexe), l'export/import.....Je n'est pas de
> de temps réel... pour les données, au pire J-1. Les données non pas
> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" wrote in message
> news:cffvok$tto$
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:etfyXrIgEHA.596@TK2MSFTNGP11.phx.gbl...
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" <ext.boyer@sncf.fr> wrote in message
> news:cffvok$tto$1@muguet.sncf.fr...
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" wrote in message
> news:cffvok$tto$
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
à
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
de
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
et
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes
de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
basesrépliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervallerégulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
avecdeux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
pluscoûteuse.
S. L.
"Jim" wrote in message
news:cffvok$tto$
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,> la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte> de temps réel... pour les données, au pire J-1. Les données non pas
besoin> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
à
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
de
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
et
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:etfyXrIgEHA.596@TK2MSFTNGP11.phx.gbl...
Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes
de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
répliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
régulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
plus
coûteuse.
S. L.
"Jim" <ext.boyer@sncf.fr> wrote in message
news:cffvok$tto$1@muguet.sncf.fr...
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
à
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
de
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
et
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
réplication serait un bon choix mais vous risquez d'avoir des problèmes
de
time-out s'ils sont situés sur Internet. L'entretien à long terme de
basesrépliquées est également problématique, surtout si elles sont toujours en
phase de développement.
Dans votre cas, l'utilisation du Log Shipping serait probablement la
meilleure solution. Elle est disponible avec la version Entreprise de
SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervallerégulier et copier les données mais comme pour la réplication, vous aurez
des problèmes si les bases sont toujours en phase de développement.
Finalement, si votre compagnie a les moyens de se le payer, un cluster
avecdeux (ou trois) SQL-Server serait la solution ultime: dès que le premier
SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien), le
second le remplacerait automatiquement. C'est cependant la solution la
pluscoûteuse.
S. L.
"Jim" wrote in message
news:cffvok$tto$
> Bonjour,
>
>
>
> Je suis à la recherche des différentes possibilités d'avoir en finalité
> sur
> deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL> 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> problème
> avec le serveur A. D'après mes connaissances (car je ne suis pas un
> spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,> la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte> de temps réel... pour les données, au pire J-1. Les données non pas
besoin> d
> 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!> Çà
> a l'ère simple. !
>
>
>
> Merci d'avance de vos propositions.
>
>
>
> Cordialement
>
>
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" wrote in message
> news:cffvok$tto$
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:etfyXrIgEHA.596@TK2MSFTNGP11.phx.gbl...
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" <ext.boyer@sncf.fr> wrote in message
> news:cffvok$tto$1@muguet.sncf.fr...
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>
Merci pour ces réponses....
Utiliser le Log Shipping me semble la méthode la plus appropriée dans mon
cas.
Les deux serveurs se trouve dans le même intranet. Il s'agit bien de tenir
jour une
base de donnée sur le serveur B en attente, à partir du serveur A. En cas
soucis
avec A, la base peux être rendu disponible sur B.
Mais une question? Pensez vous que cette solution puisse être applicable
avec
SQL2k Standard Edition? Car impossible de mettre la main sur l'utilitaire.
Toute la documentation fait référence a la SQL entreprise serveur, et je
dispose dans mon cas
de la version standard. Il y a t il une possibilité?
Les autres méthodes me semble effectivement assez lourd a mettre en place
demande un suivie plus ardue.
Il faudra que je prospect encore un peu.....
info, bienvenue....
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
> Lorsque les deux serveurs sont sur le même LAN, l'utilisation de la
> réplication serait un bon choix mais vous risquez d'avoir des problèmes
> time-out s'ils sont situés sur Internet. L'entretien à long terme de
bases
> répliquées est également problématique, surtout si elles sont toujours
> phase de développement.
>
> Dans votre cas, l'utilisation du Log Shipping serait probablement la
> meilleure solution. Elle est disponible avec la version Entreprise de
> SQL-Server ou avec le "SQL Server 2000 Resource Kit" (livre à environ
> 80$US), si ma mémoire est bonne mais je ne l'ai jamais utilisé.
>
> Vous pouvez également utilisez une tâche DTS qui va s'exécuter à
intervalle
> régulier et copier les données mais comme pour la réplication, vous
> des problèmes si les bases sont toujours en phase de développement.
>
> Finalement, si votre compagnie a les moyens de se le payer, un cluster
avec
> deux (ou trois) SQL-Server serait la solution ultime: dès que le premier
> SQL-Server tomberait en panne (ou déconnécté pour raison d'entretien),
> second le remplacerait automatiquement. C'est cependant la solution la
plus
> coûteuse.
>
> S. L.
>
> "Jim" wrote in message
> news:cffvok$tto$
> > Bonjour,
> >
> >
> >
> > Je suis à la recherche des différentes possibilités d'avoir en
> > sur
> > deux serveurs 2k (A et B) sur deux sites distant, le double d'une base
SQL
> > 2k. Ceci afin de pouvoir basculer du serveur A vers B en cas de
> > avec le serveur A. D'après mes connaissances (car je ne suis pas un
> > spécialiste de SQL 2k), la sauvegarde/restauration peut être une
solution,
> > la duplication (+complexe), l'export/import.....Je n'est pas de
contrainte
> > de temps réel... pour les données, au pire J-1. Les données non pas
besoin
> > d
> > 'être synchronisées dans les deux sens, simplement de A vers B. Eh oui
!!
> > Çà
> > a l'ère simple. !
> >
> >
> >
> > Merci d'avance de vos propositions.
> >
> >
> >
> > Cordialement
> >
> >
> >
> >
>
>