La réplication des bases SQL Server 2000 étant toujours très compliquée à
mettre en oeuvre, j'aurai besoin de quelques réponses:
Contexte: base de production d'environ 20 Go sur un Bi-Pro Xeon 3,08 Ghz / 4
Go Ram / W2003 SP1 et SQL 2000 SP4 Edt. Standard. Cette base doit être
répliquée vers des sites distants reliés par des liaisons SDSL ou ADSL (4 Mo
symétriques), et ce pour des raisons de sécurité.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de
SQL Server 2000 que sur le site de production ?
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés
au groupe Admin Locaux du serveur ?
3) - Les sites distants doivent être des abonnés ou des distributeurs ?
(sachant que la base répliquée ne sert à rien d'autre qu'une sorte de
sauvegarde)
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au
travers des pare-feux et autres routeurs ?
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou
Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas
de sinistre) ?
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ?
Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le
sont pas ?
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Merci de vos conseils éclairés.
Cordialement,
Houdini
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
Rudi Bruchez
Houdini a écrit:
Bonjour à toutes et à tous,
bonjour, Mes réponses peuvent être vagues, je ne suis pas un grand expert de la réplication.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE. Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la réplication transactionnelle, et ne peut pas adresser un distributor distant. Donc il peut par exemple être distributeur + distributor pour une réplication snapshot.
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages réseaux pour poser les snapshots, par exemple.
3) - Les sites distants doivent être des abonnés ou des distributeurs ? (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule distribution. Pour raisons de performances et cela peut aussi permettre par exemple à tes abonnés de venir chercher les publications par FTP, pour éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont dans un autre réseau. Le placement du distributeur dépend un peu de la charge de ton publisher. S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés viennent chercher les publications par FTP
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme de dump. La réplication transactionnelle copie les modifications de données enregistrées dans le log. Donc : le snapshot te permet des copies régulières mais n'est pas adapté pour une synchronisation continue. Le transactionnel peut copier pratiquement en temps réel.
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la publication. Contenu des tables, DDL des vues et procédures. Le reste est hors réplication.
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
Merci de vos conseils éclairés. Cordialement, Houdini
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Houdini a écrit:
Bonjour à toutes et à tous,
bonjour,
Mes réponses peuvent être vagues, je ne suis pas un grand expert de la
réplication.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de
SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE.
Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la
réplication transactionnelle, et ne peut pas adresser un distributor
distant. Donc il peut par exemple être distributeur + distributor pour une
réplication snapshot.
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés
au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages
réseaux pour poser les snapshots, par exemple.
3) - Les sites distants doivent être des abonnés ou des distributeurs ?
(sachant que la base répliquée ne sert à rien d'autre qu'une sorte de
sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule
distribution. Pour raisons de performances et cela peut aussi permettre par
exemple à tes abonnés de venir chercher les publications par FTP, pour
éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont
dans un autre réseau.
Le placement du distributeur dépend un peu de la charge de ton publisher.
S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au
travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés
viennent chercher les publications par FTP
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou
Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas
de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme
de dump. La réplication transactionnelle copie les modifications de données
enregistrées dans le log. Donc : le snapshot te permet des copies
régulières mais n'est pas adapté pour une synchronisation continue. Le
transactionnel peut copier pratiquement en temps réel.
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ?
Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le
sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la
publication. Contenu des tables, DDL des vues et procédures. Le reste est
hors réplication.
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
Merci de vos conseils éclairés.
Cordialement,
Houdini
bonjour, Mes réponses peuvent être vagues, je ne suis pas un grand expert de la réplication.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE. Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la réplication transactionnelle, et ne peut pas adresser un distributor distant. Donc il peut par exemple être distributeur + distributor pour une réplication snapshot.
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages réseaux pour poser les snapshots, par exemple.
3) - Les sites distants doivent être des abonnés ou des distributeurs ? (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule distribution. Pour raisons de performances et cela peut aussi permettre par exemple à tes abonnés de venir chercher les publications par FTP, pour éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont dans un autre réseau. Le placement du distributeur dépend un peu de la charge de ton publisher. S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés viennent chercher les publications par FTP
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme de dump. La réplication transactionnelle copie les modifications de données enregistrées dans le log. Donc : le snapshot te permet des copies régulières mais n'est pas adapté pour une synchronisation continue. Le transactionnel peut copier pratiquement en temps réel.
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la publication. Contenu des tables, DDL des vues et procédures. Le reste est hors réplication.
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
Merci de vos conseils éclairés. Cordialement, Houdini
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Houdini
Bonjour,
Merci pour tous ces renseignements, mais dans le cas d'une simple réplication de base (sans abonné), exemple un éditeur qui réplique vers "x" distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela veut-til dire qu'il faudra tous les recréer à la mano ?
Merci d'avance Houdini
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Houdini a écrit:
> Bonjour à toutes et à tous,
bonjour, Mes réponses peuvent être vagues, je ne suis pas un grand expert de la réplication.
> > 1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de > SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE. Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la réplication transactionnelle, et ne peut pas adresser un distributor distant. Donc il peut par exemple être distributeur + distributor pour une réplication snapshot.
> > 2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés > au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages réseaux pour poser les snapshots, par exemple.
> > 3) - Les sites distants doivent être des abonnés ou des distributeurs ? > (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de > sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule distribution. Pour raisons de performances et cela peut aussi permettre par exemple à tes abonnés de venir chercher les publications par FTP, pour éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont dans un autre réseau. Le placement du distributeur dépend un peu de la charge de ton publisher. S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
> > 4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au > travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés viennent chercher les publications par FTP
> > 5) - Quel type de réplication est le mieux adapté ? Transactionnel ou > Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas > de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme de dump. La réplication transactionnelle copie les modifications de données enregistrées dans le log. Donc : le snapshot te permet des copies régulières mais n'est pas adapté pour une synchronisation continue. Le transactionnel peut copier pratiquement en temps réel.
> > 6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? > Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le > sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la publication. Contenu des tables, DDL des vues et procédures. Le reste est hors réplication.
> > 7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
> > Merci de vos conseils éclairés. > Cordialement, > Houdini
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Bonjour,
Merci pour tous ces renseignements, mais dans le cas d'une simple
réplication de base (sans abonné), exemple un éditeur qui réplique vers "x"
distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand
même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela
veut-til dire qu'il faudra tous les recréer à la mano ?
Merci d'avance
Houdini
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Houdini a écrit:
> Bonjour à toutes et à tous,
bonjour,
Mes réponses peuvent être vagues, je ne suis pas un grand expert de la
réplication.
>
> 1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de
> SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE.
Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la
réplication transactionnelle, et ne peut pas adresser un distributor
distant. Donc il peut par exemple être distributeur + distributor pour une
réplication snapshot.
>
> 2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés
> au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages
réseaux pour poser les snapshots, par exemple.
>
> 3) - Les sites distants doivent être des abonnés ou des distributeurs ?
> (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de
> sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule
distribution. Pour raisons de performances et cela peut aussi permettre par
exemple à tes abonnés de venir chercher les publications par FTP, pour
éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont
dans un autre réseau.
Le placement du distributeur dépend un peu de la charge de ton publisher.
S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
>
> 4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au
> travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés
viennent chercher les publications par FTP
>
> 5) - Quel type de réplication est le mieux adapté ? Transactionnel ou
> Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas
> de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme
de dump. La réplication transactionnelle copie les modifications de données
enregistrées dans le log. Donc : le snapshot te permet des copies
régulières mais n'est pas adapté pour une synchronisation continue. Le
transactionnel peut copier pratiquement en temps réel.
>
> 6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ?
> Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le
> sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la
publication. Contenu des tables, DDL des vues et procédures. Le reste est
hors réplication.
>
> 7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
>
> Merci de vos conseils éclairés.
> Cordialement,
> Houdini
Merci pour tous ces renseignements, mais dans le cas d'une simple réplication de base (sans abonné), exemple un éditeur qui réplique vers "x" distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela veut-til dire qu'il faudra tous les recréer à la mano ?
Merci d'avance Houdini
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Houdini a écrit:
> Bonjour à toutes et à tous,
bonjour, Mes réponses peuvent être vagues, je ne suis pas un grand expert de la réplication.
> > 1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de > SQL Server 2000 que sur le site de production ?
Non. Par exemple l'abonné peut-être un MSDE. Par exemple, MSDE, sauf erreur, peut être publisher sauf pour la réplication transactionnelle, et ne peut pas adresser un distributor distant. Donc il peut par exemple être distributeur + distributor pour une réplication snapshot.
> > 2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés > au groupe Admin Locaux du serveur ?
Pas que je sache. Par contre ils devront avoir des droits sur des partages réseaux pour poser les snapshots, par exemple.
> > 3) - Les sites distants doivent être des abonnés ou des distributeurs ? > (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de > sauvegarde)
Tu as avantage à faire un distributeur centralisé pour générer une seule distribution. Pour raisons de performances et cela peut aussi permettre par exemple à tes abonnés de venir chercher les publications par FTP, pour éviter d'ouvrir les ports netbios/SMB vers ton LAN, si les abonnés sont dans un autre réseau. Le placement du distributeur dépend un peu de la charge de ton publisher. S'il est déjà bien sollicité, place ton distributeur sur une autre machine.
> > 4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au > travers des pare-feux et autres routeurs ?
Justement SMB. Mais tu as la possibilité de faire en sorte que tes abonnés viennent chercher les publications par FTP
> > 5) - Quel type de réplication est le mieux adapté ? Transactionnel ou > Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas > de sinistre) ?
Le snapshot (capture instantanée) copie toutes les données, dans une forme de dump. La réplication transactionnelle copie les modifications de données enregistrées dans le log. Donc : le snapshot te permet des copies régulières mais n'est pas adapté pour une synchronisation continue. Le transactionnel peut copier pratiquement en temps réel.
> > 6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? > Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le > sont pas ?
La réplication copie les objets que tu ajoutes comme articles à la publication. Contenu des tables, DDL des vues et procédures. Le reste est hors réplication.
> > 7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Il peut, mais tu dois avoir SQL Server version entreprise.
> > Merci de vos conseils éclairés. > Cordialement, > Houdini
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Rudi Bruchez
Houdini a écrit:
Merci pour tous ces renseignements, mais dans le cas d'une simple réplication de base (sans abonné), exemple un éditeur qui réplique vers "x" distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela veut-til dire qu'il faudra tous les recréer à la mano ?
Rebonjour,
Il n'y a pas de simple réplication de base sans abonné. S'il n'y a pas d'abonné, il n'y a pas de réplication. Tu peux avoir la distribution et l'abonnement sur le même serveur, auquel cas tu auras à paramétrer distribution et abonnement sur ce serveur. La réplication comporte toujours les trois éléments : publication, distribution, abonné. Tu peux placer ces éléments un peu comme tu veux sur tes serveurs.
La réplication ne copie pas les users et les droits, mais c'est une chose que tu n'auras à faire à la main qu'une fois. Pour les logins, tu as une tâche en DTS pour ce faire, pour les users, tu peux utiliser comme base du code présent ici : http://www.babaluga.org/doku.php/sql_server/snippets/administration
Comme tu as l'air de faire ton choix, soit aussi conscient que répliquer une structure de tables te limite dans ta souplesse de modification des structures. Regarde par exemple sp_repladdcolumn dans l'aide en ligne.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Houdini a écrit:
Merci pour tous ces renseignements, mais dans le cas d'une simple
réplication de base (sans abonné), exemple un éditeur qui réplique vers "x"
distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand
même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela
veut-til dire qu'il faudra tous les recréer à la mano ?
Rebonjour,
Il n'y a pas de simple réplication de base sans abonné. S'il n'y a pas
d'abonné, il n'y a pas de réplication. Tu peux avoir la distribution et
l'abonnement sur le même serveur, auquel cas tu auras à paramétrer
distribution et abonnement sur ce serveur.
La réplication comporte toujours les trois éléments : publication,
distribution, abonné. Tu peux placer ces éléments un peu comme tu veux sur
tes serveurs.
La réplication ne copie pas les users et les droits, mais c'est une chose
que tu n'auras à faire à la main qu'une fois. Pour les logins, tu as une
tâche en DTS pour ce faire, pour les users, tu peux utiliser comme base du
code présent ici :
http://www.babaluga.org/doku.php/sql_server/snippets/administration
Comme tu as l'air de faire ton choix, soit aussi conscient que répliquer
une structure de tables te limite dans ta souplesse de modification des
structures. Regarde par exemple sp_repladdcolumn dans l'aide en ligne.
Merci pour tous ces renseignements, mais dans le cas d'une simple réplication de base (sans abonné), exemple un éditeur qui réplique vers "x" distributeurs, juste pour faire "une sauvegarde" de la base ? faut-il quand même un publicateur ?
Les comptes de connexions ne sont apparemment non pris en compte, cela veut-til dire qu'il faudra tous les recréer à la mano ?
Rebonjour,
Il n'y a pas de simple réplication de base sans abonné. S'il n'y a pas d'abonné, il n'y a pas de réplication. Tu peux avoir la distribution et l'abonnement sur le même serveur, auquel cas tu auras à paramétrer distribution et abonnement sur ce serveur. La réplication comporte toujours les trois éléments : publication, distribution, abonné. Tu peux placer ces éléments un peu comme tu veux sur tes serveurs.
La réplication ne copie pas les users et les droits, mais c'est une chose que tu n'auras à faire à la main qu'une fois. Pour les logins, tu as une tâche en DTS pour ce faire, pour les users, tu peux utiliser comme base du code présent ici : http://www.babaluga.org/doku.php/sql_server/snippets/administration
Comme tu as l'air de faire ton choix, soit aussi conscient que répliquer une structure de tables te limite dans ta souplesse de modification des structures. Regarde par exemple sp_repladdcolumn dans l'aide en ligne.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
bruno reiter
pour avoir une sauvegarde, un log shipping est beaucoup plus simple. tu peux créer des jobs pour le faire sans la version enterprise.
br
"Houdini" a écrit dans le message de news:
Bonjour à toutes et à tous,
La réplication des bases SQL Server 2000 étant toujours très compliquée à mettre en oeuvre, j'aurai besoin de quelques réponses:
Contexte: base de production d'environ 20 Go sur un Bi-Pro Xeon 3,08 Ghz / 4 Go Ram / W2003 SP1 et SQL 2000 SP4 Edt. Standard. Cette base doit être répliquée vers des sites distants reliés par des liaisons SDSL ou ADSL (4 Mo symétriques), et ce pour des raisons de sécurité.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de SQL Server 2000 que sur le site de production ?
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés au groupe Admin Locaux du serveur ?
3) - Les sites distants doivent être des abonnés ou des distributeurs ? (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de sauvegarde)
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au travers des pare-feux et autres routeurs ?
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas de sinistre) ?
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le sont pas ?
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Merci de vos conseils éclairés. Cordialement, Houdini
pour avoir une sauvegarde, un log shipping est beaucoup plus simple.
tu peux créer des jobs pour le faire sans la version enterprise.
br
"Houdini" <Houdini@discussions.microsoft.com> a écrit dans le message de
news: C3A3E594-275C-43DB-A162-3113044844C3@microsoft.com...
Bonjour à toutes et à tous,
La réplication des bases SQL Server 2000 étant toujours très compliquée à
mettre en oeuvre, j'aurai besoin de quelques réponses:
Contexte: base de production d'environ 20 Go sur un Bi-Pro Xeon 3,08 Ghz /
4
Go Ram / W2003 SP1 et SQL 2000 SP4 Edt. Standard. Cette base doit être
répliquée vers des sites distants reliés par des liaisons SDSL ou ADSL (4
Mo
symétriques), et ce pour des raisons de sécurité.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de
SQL Server 2000 que sur le site de production ?
2) - Les comptes de services (notamment Agent SQL) doivent-ils être
intégrés
au groupe Admin Locaux du serveur ?
3) - Les sites distants doivent être des abonnés ou des distributeurs ?
(sachant que la base répliquée ne sert à rien d'autre qu'une sorte de
sauvegarde)
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au
travers des pare-feux et autres routeurs ?
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou
Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en
cas
de sinistre) ?
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués
?
Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le
sont pas ?
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication
?
Merci de vos conseils éclairés.
Cordialement,
Houdini
pour avoir une sauvegarde, un log shipping est beaucoup plus simple. tu peux créer des jobs pour le faire sans la version enterprise.
br
"Houdini" a écrit dans le message de news:
Bonjour à toutes et à tous,
La réplication des bases SQL Server 2000 étant toujours très compliquée à mettre en oeuvre, j'aurai besoin de quelques réponses:
Contexte: base de production d'environ 20 Go sur un Bi-Pro Xeon 3,08 Ghz / 4 Go Ram / W2003 SP1 et SQL 2000 SP4 Edt. Standard. Cette base doit être répliquée vers des sites distants reliés par des liaisons SDSL ou ADSL (4 Mo symétriques), et ce pour des raisons de sécurité.
1) - Sur chacun des sites distants, faut-il utiliser les mêmes éditions de SQL Server 2000 que sur le site de production ?
2) - Les comptes de services (notamment Agent SQL) doivent-ils être intégrés au groupe Admin Locaux du serveur ?
3) - Les sites distants doivent être des abonnés ou des distributeurs ? (sachant que la base répliquée ne sert à rien d'autre qu'une sorte de sauvegarde)
4) - Quels sont les ports éventuels à ouvrir pour la réplication SQL au travers des pare-feux et autres routeurs ?
5) - Quel type de réplication est le mieux adapté ? Transactionnel ou Capture Instantanée (pour des fins uniques de sauvegarde et de reprise en cas de sinistre) ?
6) - Lors de la réplication, tous les objets sont-ils réellement répliqués ? Je crois me souvenir que les comptes de connexions (Windows ou SQL) ne le sont pas ?
7) - En cas de doute, le log shipping pourrait-il remplacer la réplication ?
Merci de vos conseils éclairés. Cordialement, Houdini
