Discussion :

[hmira]

Bonjour,

Peut-on combiner efficacement le "Partitionnement" et les "Sauvegardes partielles" (par groupes de fichiers, etc) pour les "VLDB".
Autant, je suis au clair sur la mise en œuvre du Partitionnement, autant je suis confus et dubitatif concernant les Sauvegardes partielles (?)
Je suis à la recherche de la documentation, et d'exemples concrets, sur ces sujets et je fais donc appel à vos lumières.
J'ai pleins de questions :
1 - Les sauvegarde partielles fonctionnent-elles indifféremment pour les deux modes de récupération "Mode de récupération Simple" et "Mode de récupération Complet" ou bien y-a-t-il des subtilités et des différences pour chacun des deux modes ?
2 - Peut-on sauvegarder, partiellement, une fois pour toute, les groupes de fichiers (en lecture seule ou non) représentant les archives ?
3 - Et sauvegarder, partiellement, et régulièrement, les groupes de fichiers "Actives"
4 - Si Oui (pour 2 et 3), Comment en cas de problème reconstituer le Puzzle des différentes sauvegardes partielles, et restaurer la base ?
5 - Comment sont gérées les contraintes d'intégrité référentielles entre deux tables appartenant chacune à un groupe de fichiers différent sauvegardé partiellement à des moments différents dans le temps ?

Merci pour vos éclaircissements,

[Michel.Priori]

Peut-on combiner efficacement le "Partitionnement" et les "Sauvegardes partielles" (par groupes de fichiers, etc) pour les "VLDB".

Oui
Mais ça complique les restaurations. En cas de besoin combien de personnes savent gérer ça correctement ? (formation)
Rappel : on appelle VLDB une base pour laquelle il n'est pas opérationnellement concevable de la restaurer dans son intégralité.
Au vu de la rapidité des SSD et autre fusionIO, une restauration de plusieurs heures représente un sacré volume.

Autant, je suis au clair sur la mise en œuvre du Partitionnement, autant je suis confus et dubitatif concernant les Sauvegardes partielles (?)
Je suis à la recherche de la documentation, et d'exemples concrets, sur ces sujets et je fais donc appel à vos lumières.
J'ai pleins de questions :
1 - Les sauvegarde partielles fonctionnent-elles indifféremment pour les deux modes de récupération "Mode de récupération Simple" et "Mode de récupération Complet" ou bien y-a-t-il des subtilités et des différences pour chacun des deux modes ?

Le processus de restauration doit finir avec l'ensemble des fichiers "aux même niveaux".
Le mode complet est normalement requis.
Si on insiste pour être en mode simple :

On peut imaginer un scénario avec les groupes de fichiers en lecture seule combinée avec l'allocation des partitions mais c'est pas simple, et surtout, le volume non partitionné restera à charge
Quid de la perte de donnée du à l'absence de protection entre 2 campagnes de backup ?

2 - Peut-on sauvegarder, partiellement, une fois pour toute, les groupes de fichiers (en lecture seule ou non) représentant les archives ?

La sauvegarde complète initiale est importante. Longue, lourde et importante (on répartira la sauvegarde sur plusieurs fichiers de destination)
Une sauvegarde est une archive.
Sauvegarder partiellement les groupes de fichier revient à sauvegarder fichier par fichier.
Les groupes de fichiers en mode "lecture seule" sont suivi en tant que tel. Tant que l'attribut n'est pas enlevé, la dernière sauvegarde est utilisable.
Pour les groupes de fichiers qui ne sont pas en lecture seule, on ne peut être sûr qu'il n'y aura pas d'évolution => "une fois pour toute" n'est pas envisageable.
Ce sont les journaux qui feront "l’intérim" entre 2 rotations de backup

3 - Et sauvegarder, partiellement, et régulièrement, les groupes de fichiers "Actives"

La notion de groupe de fichier "actif" n'existe pas. Seule la notion de "lecture seule" existe.
A vous de définir les partitions sur les bons groupes de fichiers (et de gérer le volume de fichiers dans le temps)
La rotation des backup est couverte par le mode complet.
Si on est en mode simple alors il faut sauvegarder en 1 fois tous les groupes de fichiers qui ne sont pas en lecture seule.

4 - Si Oui (pour 2 et 3), Comment en cas de problème reconstituer le Puzzle des différentes sauvegardes partielles, et restaurer la base ?

En mode complet : restauration de ce qui a planté et restauration des journaux pour faire "revenir" le support à la même version que les autres.
C'est la magie de SQL de pouvoir s'appuyer sur une restauration robuste

5 - Comment sont gérées les contraintes d'intégrité référentielles entre deux tables appartenant chacune à un groupe de fichiers différent sauvegardé partiellement à des moments différents dans le temps ?

Les FK comme les jointures sont évaluées par rapport aux données présentes ; peut importe dans quel fichier ou groupe de fichiers, la donnée se trouve.
Le backup n'a pas d'incidence sur l'activité SQL.

[hmira]

Oui
Mais ça complique les restaurations. En cas de besoin combien de personnes savent gérer ça correctement ? (formation)
Rappel : on appelle VLDB une base pour laquelle il n'est pas opérationnellement concevable de la restaurer dans son intégralité.
Au vu de la rapidité des SSD et autre fusionIO, une restauration de plusieurs heures représente un sacré volume.

Oui c'est un problème général et récurent des procédures internes. Nous nous organisons pour former les personnes,et ce, afin d'assurer la continuité et la maintenance du service en cas de problème (nécessité de restaurer la base etc.).

1 - Le processus de restauration doit finir avec l'ensemble des fichiers "aux même niveaux".
Le mode complet est normalement requis.
Si on insiste pour être en mode simple :

On peut imaginer un scénario avec les groupes de fichiers en lecture seule combinée avec l'allocation des partitions mais c'est pas simple, et surtout, le volume non partitionné restera à charge
Quid de la perte de donnée du à l'absence de protection entre 2 campagnes de backup ?

1 - Je suis d'accord avec vous, il faudra effectivement imposer le mode récupération complet avec les sauvegardes des journaux de transaction pour pouvoir hisser les fichier au mêmes niveaux et même restaurer la base à un point dans dans le temps.

2 - La sauvegarde complète initiale est importante. Longue, lourde et importante (on répartira la sauvegarde sur plusieurs fichiers de destination)
Une sauvegarde est une archive.
Sauvegarder partiellement les groupes de fichier revient à sauvegarder fichier par fichier.
Les groupes de fichiers en mode "lecture seule" sont suivi en tant que tel. Tant que l'attribut n'est pas enlevé, la dernière sauvegarde est utilisable.
Pour les groupes de fichiers qui ne sont pas en lecture seule, on ne peut être sûr qu'il n'y aura pas d'évolution => "une fois pour toute" n'est pas envisageable.
Ce sont les journaux qui feront "l’intérim" entre 2 rotations de backup

2 - Je suis d'accord avec vous, Cela ma parait somme toute logique. cela me parait clair. Merci.

3 - La notion de groupe de fichier "actif" n'existe pas. Seule la notion de "lecture seule" existe.
A vous de définir les partitions sur les bons groupes de fichiers (et de gérer le volume de fichiers dans le temps)
La rotation des backup est couverte par le mode complet.
Si on est en mode simple alors il faut sauvegarder en 1 fois tous les groupes de fichiers qui ne sont pas en lecture seule.

3 - OK, je suis d'accord avec vous, vos propos me paraissent sur le principe cohérents et logiques

4 - En mode complet : restauration de ce qui a planté et restauration des journaux pour faire "revenir" le support à la même version que les autres.
C'est la magie de SQL de pouvoir s'appuyer sur une restauration robuste

4 - Donc si je comprends bien le principe reste le même, on sauvegarde la fin du journal (tail log backup) on restaure le ou les groupe de fichiers puis on enchaine la restaurations des journaux de transaction jusqu'à mettre le tout au même niveau (LSN)

5 - Les FK comme les jointures sont évaluées par rapport aux données présentes ; peut importe dans quel fichier ou groupe de fichiers, la donnée se trouve.
Le backup n'a pas d'incidence sur l'activité SQL.

5 - Là je suis moins sûr. Il semble que l'on ne peut pas mettre la base en mode RECOVRY tant que les journaux de transaction n'ont pas été restaurés et que les groupes de fichiers ne soient pas au même niveau. Mais, bon, je ne suis pas sûr de moi. j'ai prévu de réaliser un scénario complet grandeur nature pour tester et valider tout ces process.

Encore une fois Merci beaucoup Michel.Priori pour vos réponses claires et précises.

[Michel.Priori]

4 - Donc si je comprends bien le principe reste le même, on sauvegarde la fin du journal (tail log backup) on restaure le ou les groupe de fichiers puis on enchaine la restaurations des journaux de transaction jusqu'à mettre le tout au même niveau (LSN)

Oui sur le principe, non dans le détail : on restaure le plus petit élément possible : page, fichier puis groupe de fichiers.
Moins on déplace de volume mieux on se porte.
C'est là que se porte l'expertise lors du restaure : analyse de l'incident et prise de décision.

Note : Il va de soit que le groupe de fichier primary n'est plus, immédiatement après création de la base, le groupe de fichier "par défaut".

5 - Là je suis moins sûr. Il semble que l'on ne peut pas mettre la base en mode RECOVRY tant que les journaux de transaction n'ont pas été restaurés et que les groupes de fichiers ne soient pas au même niveau. Mais, bon, je ne suis pas sûr de moi. j'ai prévu de réaliser un scénario complet grandeur nature pour tester et valider tout ces process.

Je ne vois pas la relation entre les FK et le mode RECOVERY ou alors je n'ai pas compris la question.
Ce qui me rassure c'est que vous avez planifié des POC.
Gardez les scripts, ils vont vous servir pour la formation

Note : le seul talon d’Achille est le fichier LOG lui même. Une défaillance sur ce fichier et c'est une restauration un peu plus compliquée. Un bon RAID vaut mieux (??que 2 tu l'auras???)

Encore une fois Merci beaucoup Michel.Priori pour vos réponses claires et précises.

Pas de soucis c'est le rôle du forum.
Un pouce ou résolu aussi

oups, avais pas vu le pouce, merci.

[SQLpro]

Vous devez comprendre que si la sauvegarde partielle par fichier ou groupe de fichiers et supportée, seule la restauration totale est possible.
Vous devez donc à un moment donné, avoir toutes les informations pour pouvoir restaurer.

• Pour des GF en READ ONLY, une seule sauvegarde suffit.
• Pour des GF en READ / WRITE, il faudra compléter par des sauvegardes transactionnelles.

A +

[hmira]

Merci SQLPro pour cette précision, effectivement, très importante.
J'en déduis que les sauvegardes partielles ne contribuent pas (ce n'est peut-être leur rôle) à réduire le RTO.

A+

[Michel.Priori]

Scénario de récupération fragmentaire :
https://docs.microsoft.com/fr-fr/sql...ql-server-2017

[hmira]

Merci Michel.Priori pour le lien. Je vais regarder cela de plus près.

[SQLpro]

Merci SQLPro pour cette précision, effectivement, très importante.
J'en déduis que les sauvegardes partielles ne contribuent pas (ce n'est peut-être leur rôle) à réduire le RTO.

Oui et non. Une base étant un tout, tu ne peut pas restaurer des factures sans avoir aussi les clients… etc.

Donc, tu dois impérativement restaurer l'intégralité de la base. Sinon, cela ne s'appelle pas restauration (la restauration étant la remise en état du système), mais export des quelques données.

Tu peut faire deux choses pour réduire le RTO :
Solution 1 comme indiqué par Michel Priori, jouer avec la restauration fragmentaire. C'est pour cela que dans nos cours d'admin SQL nous insistons pour que le groupe de de fichier PRIMARY ne contienne RIEN (aucune table de production). Il n'y aura donc que les métadonnées de la base… Et donc, la base devient partiellement disponible dans ce cas de figure dès restauration de ce groupe de fichier donc en quelques secondes…. Il faut donc ensuite appliquer par ordre de priorité la restauration des groupes de fichiers les plus urgents…
Solution 2, adoptée pour les VLDB chez certains clients : on est tout le temps en train de restaurer sur 1 ou 2 serveurs… façon "Log Shipping". La tu peut descendre le RTO à quelques minutes si tu te débrouilles bien !!!!

A +

[Michel.Priori]

Vous devez comprendre que si la sauvegarde partielle par fichier ou groupe de fichiers et supportée, seule la restauration totale est possible.

Je pense qu'ici la formulation "restauration totale" est ambiguë.

Je laisse le soin à SQLPro à préciser le fond de sa pensée et plus particulièrement si oui ou non en cas de perte circonscrite :
* on doit restaurer l'intégralité du volume préalablement sauvegardé par partie (fichier ou groupe de fichiers)
* on doit avoir tout le matériel nécessaire pour mettre l'ensemble des fichiers de la base "à niveau" parce qu'un RECOVERY est forcément cohérent.

[SQLpro]

En général on fait de la sauvegarde pour remonter la base au dernier moment de sa vie => restauration totale.
Le concept de restauration partielle (des objets sont manquants) n'existant pas.

En revanche, la restauration peut s'arrêter à un point dans le temps. C'est une autre histoire. Il ne s'agit pas de remonter la base au dernier moment de sa vie, mais a un moment antérieur. Ceci suppose d'utiliser les journaux de transaction et n'est pas utilisable sans cela.

Il y a enfin la restauration par rapiéçage qui consiste à rechercher dans les journaux de transaction, certaines pages qui ont été endommagées dans la base "live". Cette restauration peut être faite in vivo dans l'édition Enterprise.

A +

[Michel.Priori]

la restauration par rapiéçage [...] Cette restauration peut être faite in vivo dans l'édition Enterprise.

La traduction par le site de M$ de "Piecemeal" est visiblement devenue "fragmentaire".

La précision sur l'édition est importante (même si pour une VLDB ce serait assez étonnant de choisir la version standard)

[SQLpro]

La traduction par le site de M$ de "Piecemeal" est visiblement devenue "fragmentaire".

J'ai proposé il y a fort longtemps de corriger cette traduction car fragmentaire est inappropriée… En effet, dans ce terme on croit que l'on peut restaurer une table par exemple… Ce n'est bien évidemment pas le cas. On répare un trou physique dans la bases (des pages abimées) comme on le ferait d'une chaussettes trouée !


A +

[hmira]

Oui et non. Une base étant un tout, tu ne peut pas restaurer des factures sans avoir aussi les clients… etc.

Donc, tu dois impérativement restaurer l'intégralité de la base. Sinon, cela ne s'appelle pas restauration (la restauration étant la remise en état du système), mais export des quelques données.

Tu peut faire deux choses pour réduire le RTO :
Solution 1 comme indiqué par Michel Priori, jouer avec la restauration fragmentaire. C'est pour cela que dans nos cours d'admin SQL nous insistons pour que le groupe de de fichier PRIMARY ne contienne RIEN (aucune table de production). Il n'y aura donc que les métadonnées de la base… Et donc, la base devient partiellement disponible dans ce cas de figure dès restauration de ce groupe de fichier donc en quelques secondes…. Il faut donc ensuite appliquer par ordre de priorité la restauration des groupes de fichiers les plus urgents…
Solution 2, adoptée pour les VLDB chez certains clients : on est tout le temps en train de restaurer sur 1 ou 2 serveurs… façon "Log Shipping". La tu peut descendre le RTO à quelques minutes si tu te débrouilles bien !!!!

Merci SQLPro pour ces précisions complémentaires, très constructives et éclairantes.
On verra à l'usage, mais pour le moment je vais opter pour la Solution 1. La solution N° 2 me parait aussi très intéressante, mais elle nécessite plus de ressources, une réflexion et une étude plus approfondie, mais je garde l'idée sous le coude.

[hmira]

Merci à vous aussi Michel.Priori pour vos contributions et vos éclairage très instructives

[hmira]

Je pense maintenant disposer des éléments clés pour mettre en ouvre le partitionnement combiné aux sauvegardes partielles. La tâche sera vraisemblablement ardue, mais au moins je suis au clair. Je vais donc "clore" et marquer "Résolue" cette discussion. Merci à vous tous.

A+