Discussion :

[jbovrou]

Bonjour / Bonsoir à tous

Je souhaite faire la mise à jour de la base de données A d'une filiale vers la base de données A' connecter au siège.
L'objectif est de retrouver les mêmes informations dans les deux bases à l'instant T ou T -1.
Je précise que les deux instances sont dans différents réseaux et domaines et la mise à jour doit se faire de façon périodique.
L'interconnexion permettra aux deux serveurs de communiquer entre eux.
La base localisée au siège ne servira que pour une consultation; la principale est celle de la filiale.
J'ai essayé la copie de la base de la filiale vers le siège = Echec
J'ai essayé la méthode backup and restore ça fonctionne mais impossible d'automatiser du fait de la date changeante du fichier log
J'ai essayé la méthode de la réplication mais je m'y perds un peu
Quelqu'un aurait t'il une solution simple et efficace à mettre en place?

[SQLpro]

Bonjour,

Je souhaite faire la mise à jour de la base de données A d'une filiale vers la base de données A' connecter au siège.
L'objectif est de retrouver les mêmes informations dans les deux bases à l'instant T ou T -1.
Je précise que les deux instances sont dans différents réseaux et domaines et la mise à jour doit se faire de façon périodique.
L'interconnexion permettra aux deux serveurs de communiquer entre eux.
La base localisée au siège ne servira que pour une consultation; la principale est celle de la filiale.
J'ai essayé la copie de la base de la filiale vers le siège = Echec

Qu'entendez vous par copie de la base ? Copie des fichiers ???
Cela est possible mais c'est une très mauvaise pratique car :
1) il faut mettre la base source hors ligne en utilisant la procédure stockée sp_detachdb
2) il faut copier les fichiers vers la cible
3) remettre la base source en ligne avec CREATE DATABASE ... FOR ATTACH
4) supprimer la base cible avec DROP DATABASE après avoir déconnecté tout le monde (ALTER DATABASE ... SET SINGLE_USER WITH ROLBACK IMMEDIATE)
5) mettre la base cible en utilisant la commande CREATE DATABASE ... FOR ATTACH

J'ai essayé la méthode backup and restore ça fonctionne mais impossible d'automatiser du fait de la date changeante du fichier log

Parfaitement possible car toutes les sauvegardes sont tracées... Il suffit d'interroger les tables systèmes adéquat pour composer un script de restauration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT * FROM msdb.dbo.backupset
SELECT * FROM msdb.dbo.backupmediafamily

J'ai essayé la méthode de la réplication mais je m'y perds un peu

Il existe de nombreux mécanismes différents de réplication dans MS SQL Server :

• réplication transactionnelle
• réplication snapshot
• réplication point à point
• réplication de fusion
• réplication via Service Broker
• mirroring (cible pas lisible)
• alwaysOn
• log shipping

Pour une réplication de l'intégralité de la base en temps, réel le mieux est AlwaysOn en mettant le réplicas lisible.
En mode asynchrone (si grande distance) c'est au fil de l'eau (quelques ms de différence entre la production et le réplica.
ATTENTION : ceci nécessite la version Enterprise et le paiement des licences qui va avec...

Quelqu'un aurait t'il une solution simple et efficace à mettre en place?

ALwaysOn
Log Shipping
Sinon, backup/restore tous les jours

A +

[jbovrou]

Bonjour,



Qu'entendez vous par copie de la base ? Copie des fichiers ???
Cela est possible mais c'est une très mauvaise pratique car :
1) il faut mettre la base source hors ligne en utilisant la procédure stockée sp_detachdb
2) il faut copier les fichiers vers la cible
3) remettre la base source en ligne avec CREATE DATABASE ... FOR ATTACH
4) supprimer la base cible avec DROP DATABASE après avoir déconnecté tout le monde (ALTER DATABASE ... SET SINGLE_USER WITH ROLBACK IMMEDIATE)
5) mettre la base cible en utilisant la commande CREATE DATABASE ... FOR ATTACH

Bonjour,
Merci pour la réponse. Je me doutais que ça ne ferait pas partir des bonnes pratiques.
Donc j'abandonne cette démarche.

Parfaitement possible car toutes les sauvegardes sont tracées... Il suffit d'interroger les tables systèmes adéquat pour composer un script de restauration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT * FROM msdb.dbo.backupset
SELECT * FROM msdb.dbo.backupmediafamily

Ce code permet t'il de faire la restauration automatique de la base de données?

Il existe de nombreux mécanismes différents de réplication dans MS SQL Server :

• réplication transactionnelle
• réplication snapshot
• réplication point à point
• réplication de fusion
• réplication via Service Broker
• mirroring (cible pas lisible)
• alwaysOn
• log shipping

Pour une réplication de l'intégralité de la base en temps, réel le mieux est AlwaysOn en mettant le réplicas lisible.
En mode asynchrone (si grande distance) c'est au fil de l'eau (quelques ms de différence entre la production et le réplica.
ATTENTION : ceci nécessite la version Enterprise et le paiement des licences qui va avec...

C'est la réplication transactionnelle j'avais essayé mais je ne suis pas allez jusqu'au bout.
Le mode que je préfère est le mode asynchrone, pas besoin d'avoir du temps réel. Peut t'on le faire avec la version standard ?

ALwaysOn
Log Shipping
Sinon, backup/restore tous les jours

A +

C'est le backup/restore je veux automatiser. Est ce que c'est possible? Si oui comment le faire ?

[SQLpro]

Oui, si la base est petite (au max 100 Go) le BACKUP RESTORE est jouable...

Tout dépend des sauvegardes mises en place...

Si uniquement des sauvegardes FULL alors il suffit de retrouver dans la table msdb.dbo.backupset la dernière sauvegarde FULL de la base considérée et en jointure avec msdb.dbo.backupmediafamily tu auras la (ou les) fichier(s) de sauvegarde.

Préalable : créer un serveur lié dans ton serveur cible, pointant vers le serveur source.

1) à la fin de la sauvegarde (sur le serveur cible), copier cette sauvegarde vers le serveur de destination
2) dans l'Agent SQL du serveur cible faire un script qui reconstitue la sauvegarde en interrogeant les tables distantes msdb.dbo.backup...

Exemple (partiel) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
WITH
T AS
(
SELECT TOP 1 backup_set_id, database_name
FROM   msdb.dbo.backupset 
WHERE  type = 'D'
  AND  database_name = 'DB_BOATON_MIGRATION'
ORDER  BY backup_finish_date DESC
)
SELECT N'RESTORE DATABASE [' + database_name + '] FROM DISK = ''' + physical_device_name + ''';' AS SQL_COMMAND
FROM   T
       JOIN [msdb].[dbo].[backupmediafamily] AS BMF
          ON T.backup_set_id = media_set_id;

Si les chemins des fichiers ne sont pas les mêmes, alors utilisez WITH MOVE... dans la commande RESTORE

A +

[jbovrou]

Hello
Merci pour votre réponse. Désolé de ne pas avoir vite répondu mais je testais la mise en place du Log Shipping.
Cependant je bute sur un élément. J'ai suivi toutes les étapes de configuration mais j'ai toujours la même erreur qui survient.
Je pense avoir donné toutes les autorisations nécessaires mais toujours rien.
J'ai joint le message d'erreur et les détails du message




Avez vous une idée de comment la résoudre? Peut être je ne donne pas les bonnes autorisations ou peut être la config a été mal faite

[SQLpro]

C'est normal. Le répertoire vers lequel vous voulez envoyer vos sauvegarde ne fait sans doute pas partie des espaces autorisée au niveaux Windows pour le compte de service de SQL Server.

Dans un tels cas, deux solutions :

• changer le compte de service pour un compte de l'AD avec des droits sur toutes les machines utilisées
• ajouter un proxy pour lancer le travail de l'Agent SQL

A +

[jbovrou]

Je vais essayer la 2ème méthode parce que les bases doivent fonctionner sur des domaines différents.

[SQLpro]

Sur deux domaines différents il faudrait faire une approbation des domaines pour certains comptes...

A +