Discussion :

[StringBuilder]

Bonjour,

Après avoir testé (et été très déçu) la fonction de réplication de SQL Server Standard, je préfère utiliser une méthode moins automatisée, mais plus fiable dans la mesure où je suis sûr que TOUT est répliqué, à savoir la restauration de backups à intervalle réguliers.

J'ai donc écrit un programme qui backup la base source toutes les 10 minutes.

Le premier backup est un FULL, tandis que les suivants sont des DIFFERENTIAL, plus les LOG.

Dans la foulée, le lance la restauration de ce que j'ai backupé sur le serveur de cible.

Pour le backup FULL, j'utilise "WITH REPLACE" étant donné que la base a changé de serveur...

En revanche, pour le DIFFERENTIAL et les LOG, je ne peux pas utiliser REPLACE, il faut bien ajouter les données.

Du coup, je me prends un "The log or differential backup cannot be restored because no files are ready to rollforward." : évidement, il n'y a rien à restaurer depuis le backup, étant donné que c'est un backup d'une autre base.

Comment faire comprendre/croire à SQL Server que le backup de ma base d'origine est bien un backup valide de ma base cible ?

Il faut que je restaure le FULL systématiquement en NORECOVERY avant ?

[mikedavem]

Hello,

Ce que tu veux faire s'apparente à du log-shipping sur SQL Server. Est-ce que tu n'aurais pas intérêt à regarder de ce côté?
Sinon oui lorsque tu restaures une sauvegarde FULL et que tu désires restaurer une suite de backup par la suite il faut effectivement la restaurer en NORECOVERY ou éventuellement en standby si tu veux y accéder en lecture seule.

++

[SQLpro]

Après avoir testé (et été très déçu) la fonction de réplication de SQL Server Standard, je préfère utiliser une méthode moins automatisée, mais plus fiable dans la mesure où je suis sûr que TOUT est répliqué, à savoir la restauration de backups à intervalle réguliers.

C'est normal. Vous n'avez pas compris ce à quoi servait une réplication.... Ce terme est souvent mal utilisé par des produits concurrents. La réplication consiste à répliquer des données, c'est à dire un sous ensemble de lignes et de colonnes provenant d'une ou plusieurs tables d'une base A vers une base B quelque soit les formes des tables en jeu dans la réplication - les tables n'ont même pas besoin d'être identique, pourvu que pour les tables T1, T2, T3 dont les données C1T1, C2T1, C1T2... sont à répliquer (avec d'éventuels filtres) aient des colonnes correspondante dans les tables de destination...

Ce que vous cherchez à faire c'est DUPLIQUER votre base et non répliquer des données. Et de manière générale lorsque l'on utilise un marteau pour visser.... ça va pas bien !

Comme indiqué par mikedavem, pour faire ceci il existe différentes solutions :

• basique asynchrone : log shipping
• plus avancé synchrone ou asynchrone : mirroring ou AlwaysOn

A +

[StringBuilder]

AlwaysOn et Mirroring sont pas dispos dans la version Standard (d'où ma grande déception).

J'espérais bénéficier d'une réplication des bases (et non des données) gérée de façon native dans la version Standard, mais visiblement y'a rien qui va dans ce sens, mise à part le clustering, au détail près qu'on n'a pas l'infrastructure nécessaire.

Du coup j'ai tenté la réplication, mais comme rappelle SQLPro, c'est que les données qui sont répliquées. Parfait pour construire une base de BI en temps réel, mais ça ne vaut rien en termes de sauvegarde.

Donc pour en revenir à nos moutons, voici ce que j'ai fait :

Le programme tourne donc toutes les 10 minutes.

Si ça fait plus de 24 heures qu'un FULL backup a été fait, alors il en fait un.
Sinon si ça fait plus de 1 heure qu'un DIFF backup a été fait, alors il en fait un.
Il fait ensuite systématiquement un backup des LOG.

Et dans la foulée, sur le serveur cible :
- Il restaure le FULL le plus récent avec les options "WITH REPLACE, NORECOVERY"
- Il restaure le DIFF le plus récent, avec les mêmes options
- Il restaure l'ensemble des LOG consécutifs au dernier backup des données (FULL ou DIFF) avec les mêmes options, sauf le dernier qu'il lance en RECOVERY.

Et du coup j'ai ma base cible à jours (avec un delta de 10 minutes) prête à prendre la relève si le serveur source tombe en rade.

Le seul truc, c'est que ça met 3 plombes à restaurer les FULL + DIFF + ensemble de LOG depuis le dernier backup...

Ce que vous préconisez, c'est de laisser la base toujours en NORECOVERY et de simplement restaurer le dernier LOG à chaque fois ?

[SQLpro]

AlwaysOn est bien dispo dans la version standard, tout comme le mirroring (même s'il est désapprouvé à partir de la v2012). La seule restriction c'est que vous devez le faire fonctionner en synchrone.

A +

[SQLpro]

Ce que vous préconisez, c'est de laisser la base toujours en NORECOVERY et de simplement restaurer le dernier LOG à chaque fois ?

C'est surtout de passer par l'assistant qui met en place et gère tout cela de manière automatique !

Clic droit sur ta base, menu "Taches" / "Envoyer les journaux..."

A +

[mikedavem]

AlwaysOn est bien dispo dans la version standard

Juste une petite correction. AlwaysOn n'est pas disponible en version standard pour les versions 2012 et 2014.
Je rejoins SQLPro sur l'envoi des journaux sur SQL Server. A moins d'avoir des besoins spécifiques, tu as tout ce qu'il faut en natif sur SQL Server avec en sus du monitoring ...

++

[StringBuilder]

En fait, on a pour moitié des serveurs avec des bases Express et pour moitié avec Standard.
Du coup, j'ai créé ma procédure de log shipping "à la main" pour les Express.
Et plutôt que de devoir gérer deux méthodes en simultané, je l'ai déployée aussi sur les standard...
Mais effectivement, ça a l'air de faire la même chose