Discussion :

[Maysa56]

Bonjour à tous,

tout est dans le titre .
Nous installons chez nos clients une version de SQL Server Express avec leurs bases de données.
A ce jour ils n'ont aucune sauvegarde de leurs données. Si le PC plante tout est perdu. .

J'aimerais avoir les conseils des pros à ce sujet. quel est le meilleurs moyen d'avoir , en cas de crash, une copie des données ?
Si je vais des sauvegardes régulières, je n'aurais pas les données à l'instant T du crash de la machine.

je sais qu'il faut qu'on change notre version se SQL Server car Express neest très limitée en action.

Quelles différences entre la réplication et la mise en miroir ?

Merci d'avance pour vos éclaircissement.

Maysa

[StringBuilder]

Bonjour,

Si je vais des sauvegardes régulières, je n'aurais pas les données à l'instant T du crash de la machine.

Si, ou pas. En fait, si vous passez le mode de journalisation en FULL (complet en français) alors vous serez capable de remonter un backup + rejouer le journal de transaction jusqu'à la transaction près.
Après, pour rejouer le journal de transactions actif, il faut évidement que le serveur ne soit pas complètement planté... ça peut être utile notamment suite à une défaillance qui corrompt le fichier de données, ou une erreur de manipulation qui détruit des données et qu'on sait identifier à quel moment l'erreur a été faite.

je sais qu'il faut qu'on change notre version se SQL Server car Express neest très limitée en action.

C'est sûr que de la haute dispo avec SQL Express c'est pas évident.
Avec, avec une Standard, vous n'avez pour ainsi dire RIEN de plus (mise à par le log shipping automatisable par défaut).
Donc soit vous passez sur une Entreprise et vous pouvez sortir le chéquier, soit vous pouvez déjà voir ce que vous pouvez scripter à la main.

Quelles différences entre la réplication et la mise en miroir ?

Il est possible que j'intervertisse les deux termes, donc je ne vais pas les nommer.

L'un consiste simplement à restaurer au fur et à mesure des backup du premier serveur sur un second, voir même le journal des transaction (log shipping).
L'autre consiste à mettre en place des automatismes permettant d'avoir l'ensemble des données synchronisées entre les deux serveurs, de manière transactionnelle ou non.

Le premier est possible avec SQL Express et Standard. Il permet, si par exemple vous répliquez le journal des transactions sur le serveur de secours toutes les 10 minutes, de perdre au plus 10 minutes en cas de destruction du premier serveur. C'est très simple à mettre en place. Le second serveur peut prendre le relai en quelques secondes en le repassant en mode "normal" (en log shipping, il reste en mode "recovery" et est donc inutilisable tel quel).
Si vous êtes intéressé par ce mode, je peux vous envoyer un programme que j'ai fait qui permet de backuper des bases et les restaurer en mode log shipping sur des serveurs SQL Express (il ne fait que jouer des scripts que vous pouvez aussi écrire directement vous-même).

Le second n'est possible qu'avec Entreprise, et demande (probablement, jamais mis en place) plus de boulot/expertise à mettre en place. En revanche, l'avantage c'est que le second serveur est "vivant", et peu permettre par exemple de la BI dessus sans surcharger le serveur de production, avec des données mises à jour en temps réel. Pour ce second scénario, je sais qu'il y a au moins 3 ou 4 mécanismes différents, avec leurs avantages et inconvénients, notamment en termes d'infrastructure.

[Boubou2020]

Le second n'est possible qu'avec Entreprise, et demande (probablement, jamais mis en place) plus de boulot/expertise à mettre en place. En revanche, l'avantage c'est que le second serveur est "vivant", et peu permettre par exemple de la BI dessus sans surcharger le serveur de production, avec des données mises à jour en temps réel. Pour ce second scénario, je sais qu'il y a au moins 3 ou 4 mécanismes différents, avec leurs avantages et inconvénients, notamment en termes d'infrastructure.

Dans le mirroirng le serveur secondaire n'est pas accessible (Restaurer log WITH NORECOVERY )

et il est possible de le mettre en place avec l'Edition standart limitation en nombre de Thread 1 thread par miroir

[StringBuilder]

Dans le mirroirng le serveur secondaire n'est pas accessible (Restaurer log WITH NORECOVERY )

et il est possible de le mettre en place avec l'Edition standart limitation en nombre de Thread 1 thread par miroir

C'est le log shipping ça, donc le premier mode dont je parle.

Le second mode dont je parle, c'est celui qui permet de faire de la "vraie" haute dispo, ainsi que du load balancing.
Ce mode là n'est pas dispo en Standard.

[Boubou2020]

C'est le log shipping ça, donc le premier mode dont je parle.

Le second mode dont je parle, c'est celui qui permet de faire de la "vraie" haute dispo, ainsi que du load balancing.
Ce mode là n'est pas dispo en Standard.

Même avec le log shipping le serveur secondaire n'est pas toujours accessible (l base n'est pas accessible pendant la restauration du LOG)

Pour info toutes les solution du load balancing (alwayson ou FCI Failover cluster instance ) sont disponible dans Le standart Edition

alors que le pire c'est que vous considérer la réplication comme une solution du load balancing (le seconde Mode)

[Maysa56]

Merci à tous pour vos réponses ! cela est beaucoup plus clair maintenant.

[SQLpro]

...
C'est sûr que de la haute dispo avec SQL Express c'est pas évident.
Avec, avec une Standard, vous n'avez pour ainsi dire RIEN de plus (mise à par le log shipping automatisable par défaut).
Donc soit vous passez sur une Entreprise et vous pouvez sortir le chéquier, soit vous pouvez déjà voir ce que vous pouvez scripter à la main....

Non, c'est faut !

1) depuis la version 2016 SP1 Standard, vous pouvez faire un AlwaysOn basique à deux noeuds
2) depuis la version 2019 Standard, vous pouvez faire un AlwaysOn basique à deux trois
3) avec n'importe quelle version Standard depuis 2005 vous pouvez faire du mirroring.

A +