Discussion :

[MAndris]

Bonjour,

Je souhaiterais éclater une BDD volumineuse (100 Gb) en plusieurs parties. Le but est de pouvoir gagner du temps lors de la sauvegarde et/ou d'une éventuelle restauration.

Quelques tests ont été réalisés en créant 2 groupes de fichiers supplémentaires et en répartissant les tables dans les différents groupes. Cela fonctionne très bien mais en cas de restauration d'un des groupes de fichiers, il est difficilement possible de retrouver un état antérieur à celui du dernier journal de transaction.

Je voudrais solutionner le scénario suivant : Une BDD est en mode de journalisation "Complet", une erreur a été commise dans une table bien précise (update massif, par exemple), la sauvegarde du journal de transactions a déjà eu lieu et je souhaiterais retrouver la situation avant l'update.

Evidemment en restaurant la BDD complète et en rejouant les journaux de transactions, pas de problème mais le but étant de gagner du temps, je voulais restaurer uniquement le groupe de fichiers concernés.

Dans ce cas, même en utilisant les LSN, il a toujours fallu rejouer le dernier journal de transactions et donc, le dernier update afin de pouvoir remettre la BDD en ligne

Quelle serait la meilleure manière de procéder dans ce cas de figure ?
Comment pratique-t-on de manière générale avec de grosses BDD ?

Merci de votre avis.

Michel.

[SQLpro]

1) vous obtiendrez de mauvaise performances de sauvegarde en les générant sur du RAID 5 / 6 ou sur un serveur virtuel (les serveurs virtuels sont à bannir).
Dans ce cas en passant en RAID 1, 0+1 ou 10 vous divisez par un facteur entre 1,6 et 2,5 minimum... le temps de sauvegarde
2) vous pouvez paralléliser la sauvegarde de la base complète sur plusieurs fichiers pourvu qu'ils soient sur plusieurs disques physiques. Ainsi vous diviser par n (n étant le nombre d'axes physiques) la vitesse de la sauvegarde et éventuellement de la restauration
3) avec 2008 vous pouvez compresser les sauvegardes ce qui améliore grandement la sauvegarde et un bon peu la restauration
4) faites attention aux sauvegardes partielles de fichiers ou groupes de fichiers :
- a) les tables n edoivent pas être interdépendantes entre les divers unités
- b) la restauration ne peut se faire qu'en totalité
5) la restauration par le JT ne peut que concerner la totalité de la base
6) restaurer une base en production à un temps T n'est pas chose courante. EN générale on restaure à côté de la production (clone) et l'on repique les données manque du clone vers la production
7) il existe d'autres outils pour ce genre de scénario, comme les scripts de rétro insertion de données que la lecture du JT permet à travers par exemple LogExplorer de Lumigent ou SQL log d'Apex

A +

[WOLO Laurent]

sur un serveur virtuel (les serveurs virtuels sont à bannir).

Quel que soit le type de virtualisation ?

[dbaffaleuf]

Quel que soit le type de virtualisation ?

Par type on entend bare metal (ESX / HYPER-V), on ne parle pas de paravirtualisation (Xen) ou de host-based (Virtual Server, VMWare Server).

Disons que le matériel n'est pas encore à niveau pour espérer avoir des performances comparables avec une machine physique. Il y a eu de gros espoirs avec l'arrivé de l'IntelVT et des proc PACIFICA chez AMD, avec la prise en charge d'un ring-1, des pagetables internes pour gérer la mémoire, mais pour l'instant, comme personne n'y va vraiment sérieusement, on n'a pas un bon retour, et MS met en garde contre certains types d'utilisation (beaucoup d'IOS, beaucoup de CPU, etc...). Après je pense qu'il ne faut pas diaboliser l'outil, c'est juste un outil. Il faut plutôt se méfier de son utilisation qui si elle n'est pas faite dans le cadre de ce qu'elle est censée faire (de la consolidation, du déploiement rapide, etc...), ne donne pas le résultat escompté et provoque un ressentiment général chez les DBAs et les utilisateurs. Mais bon, j'ai bon espoir que la techno s'améliore avec le temps.

[SQLpro]

C'est surtout que les SGBDR utilisent un OS interne dont les caractéristiques sont incompatible avec les OS systèmes. Par exemple le pas d'horloge de l'OS SQL Server (SELECT @@TIMETICKS qui donne 31,250ms) est notablement plus lent que celui de l'OS Windows, et ainsi de suite comme la granularité de lecture des données (page de 8Ko, extensions de 64 Ko) du SGBDR contre celle de l'OS (1 à 2 Ko - formatage).

Bref, la virtualisation faite sur de tels paramètres système, contrarie systématiquement le comportement du SGBDR.

Demandez vous pourquoi chaque SGBDR possède son propre planificateur de tâche alors que maint quantité d'outil existe (du planificateur de tache de Windows aux outils comme $universe...). C'est simplement pour ques les processus planifiés puissent s'activer en se calant sur le pas d'horloge du SGBDR et non pas sur celui de l'OS afin de ne pas géner les transactions en cours !

A +

[dbaffaleuf]

Bref, la virtualisation faite sur de tels paramètres système, contrarie systématiquement le comportement du SGBDR.

Là je ne suis pas convaincu. Que l'instance soit dans une VM ou pas, cette 'adaptation' est réalisée de toutes façons. L'hyperviseur ne génère pas plus de changements de contexte que l'OS, par exemple. Ces incompatibilités existent bel et bien aussi en dehors d'une VM.

Il y a effectivement toujours des problèmes avec le comptage du temps dans une VM, mais par contre je ne vois ce que tu entends par 'pas d'horloge du SGBDR' ? Les ticks sont obtenus via RDTSC ou QueryPerformanceCounter() , ils ne sont pas générés par SQL Server (??)

[kagemaru]

Enfin, bon, c'est toujours pareil, le "à bannir" est un raccourci un peu trop simpliste.

Une entreprise utilise une multitude d'applications. Par exemple, sur une centaine d'applis (inventaire, compta, feuilles de temps, incidents, et j 'en passe...), disons max une dizaine critique (et grand max) où la performance et la haute dispo doivent être au rdv, pour lesquelles la boîte risque gros si les perfs sont mauvaises ou en cas de crash. J'exigerais des machines physiques pour ces applis vraiment critiques.

Ormis un nombre limité d'applications, le reste peu très facilement atterrir sur une ou plusieurs instances tournant dans des machines virtuelles. Bien sûr qu'il y a un surcoût de ressource mais cela reste négligeable pour toutes ces applications utilisées par qq personnes, 1 ou 2 par jour, par mois.

Je pense qu'un des ressentiments qu'ont les DBA par rapports aux environnement virtuels est :
- qu'il est difficile de mesure la véritable performance
- que c'est souvent le domaine des admins système
- qu'ils nous détournent souvent des techniques de haute dispo natives auxx SGBD (miroring, repli, cluster) pour aller sur des techniques propres aux environnements virtuels (VMotion, High Availability pour vmware). Je ne cautionne pas ce point mais c'est ce que je constate souvent, car la connaissance du DBA n'est soit disant plus requise.

Bref, des VMs pour des SGBD, oui, dans la mesure où la criticité de l'application le permet .... (troll en cours de génération....)

[SQLpro]

N'oubliez pas que nous somme dans un thread d'optimisation. Dans ce sens, la première des optimisations consiste à éviter de consommer inutilement du temps, ce que la couche de VM fait allégrement !

Pour le reste "ressentiments" tu as parfaitement raison. Et il m'arrive de prôner la VM dans certains cas, afin de réaliser des économies d'échelle, sans compromis sur la perf.

A +