[Débat] utilité mode complet et virtualisation

[castorameur]

bonjour,

je voudrais ouvrir un débat.
Pour planter le décor : je ne suis pas un GRAND spécialiste SQL, j'ai passé mon exam de DBA en 2000 et j'ai appris sur le tas 2005 et 2008. Je n'ai cette compétence SQL que dans mon boulot d'Admin de base ERP.
Le SI de la société dans laquelle je travaille a été virtualisé, ainsi que le serveur SQL.

Maintenant mon questionnement :

La mise en mode complet d'une base sert à palier à de nombreuses situations via la sauvegarde des journaux.
Or avec la virtualisation, je me pose la question de la pertinence et j'envisage de passer en mode simple.
En effet en cas de petit problème il me faut remonter la base sur un autre serveur pour récupérer la donnée perdue dans une table. Le mode complet ne m'aidera pas.
En cas de gros problème il me faut refaire la base, avec le back des journaux, et de la base. Mais j'ai en parallèle la sauvegarde de l'image virtuelle.

J'attends vos remarques

merci

[zinzineti]

Envoyé par castorameur

bonjour,
La mise en mode complet d'une base sert à palier à de nombreuses situations via la sauvegarde des journaux. Or avec la virtualisation, je me pose la question de la pertinence et j'envisage de passer en mode simple.

si le backup des fichiers de transaction n'est pas prévu dans la stratégie du plan de maintenance des bases de données alors il faut appliquer le mode de récupération des bases à 'SIMPLE'. Que ça soit dans un contexte de virtualisation ou non.

Envoyé par castorameur

En effet en cas de petit problème il me faut remonter la base sur un autre serveur pour récupérer la donnée perdue dans une table. Le mode complet ne m'aidera pas.
En cas de gros problème il me faut refaire la base, avec le back des journaux, et de la base. Mais j'ai en parallèle la sauvegarde de l'image virtuelle.

C'est exact. malheureusement SQL SERVER ne met pas à disposition de telle fonctionnalité. Sous ORACLE il y a le FLASHBACK TABLE qui permet de régler ce genre de problème (par ex. rattraper une table supprimer malencontreusement) [/QUOTE]

[SQLpro]

Le mode complet ne garantit pas que la reprise dans le temps de données perdues, il permet aussi de reprendre 100 % de la base en cas de crash de l'un des fichiers de la base. C'est simple. Si un fichier de données est mort il suffit de faire une sauvegarde du JT pour récupérer tout. Si le JT est mort, une sauvegarde complète de la base suffit pour tout récupérer...

Vous pouvez simuler le mode flashback en utilisant un snapshot de bases de données. Pour un de mes clients, j'ai fait une rotation de 3 snapshot toutes les heures.

A +

[zinzineti]

Envoyé par SQLpro

Vous pouvez simuler le mode flashback en utilisant un snapshot de bases de données. Pour un de mes clients, j'ai fait une rotation de 3 snapshot toutes les heures.
A +

Dommage que SQL SERVER ne permet pas dans sa version actuelle de faire un snapshot niveau table comme le permet ORACLE avec l'utilisation de FLASHBACK TABLE :

--> flashback avec une référence date-time du point de restauration

Code :

1
2
FLASHBACK TABLE MaTable TO TIMESTAMP 
      TO_TIMESTAMP('2011-12-16 10:26:26', 'YYYY-MM-DD HH:MI:SS')

--> flashback before DROP (restauration de la table juste après la suppression )

Code :

FLASHBACK TABLE MaTable TO BEFORE DROP;

--> ...

ça devrait donner des idées à MS

[castorameur]

@zinzineti
Il y a bien une sauvegarde des JT tous les midi avec troncature du log.Et une sauvegarde complète tous les soirs.
En fait la base a été installé comme n'importe quelle base SQL.
ET aujourd'hui qu'il y a la virtualisation je me demande si cela vaut le coup d'avoir autant de sauvegardes.
A force cela consomme beaucoup d'espace disk pour le serveur d'une PME.

Pour le flashback c'est effectivement très dommage que cela n'existe pas.

Mais si je résume aucun de vous ne trouve incongru d'aller vers le mode simple pour un serveur virtualisé.

Pour moi les avantages seraient:
- petit gain de perf
- petit gain d'espace disk

[zinzineti]

Envoyé par castorameur

@zinzineti
Mais si je résume aucun de vous ne trouve incongru d'aller vers le mode simple pour un serveur virtualisé.
Pour moi les avantages seraient:
- petit gain de perf
- petit gain d'espace disk

Tout dépend du niveau de risque qu'accepte l'entreprise. une chose est sûre s'il n'y avait pas des sauvegardes de JT tu peux passer la base en mode SIMPLE. Autrement dit si tu passes la base en mode SIMPLE il est impossible de faire des sauvegardes de JT. le fait de position la base en mode SIMPLE fait qu'il y a moins de bavardage dans le JT => réduction de la taille du JT => gain d'espace disque

[SQLpro]

C'est simple :

• mode simple => reprise au plus tôt = dernière sauvegarde.
• mode complet => reprise au plus tôt = dernière transaction ou au pire dernier checkpoint...

• Dans le premier cas vous perdez au pire une journée de production
• dans le second une minute.

La virtualisation n'y change rien !

A +

[castorameur]

Tout d'abord joyeux Noël à tous

Le débat sur la virtualisation ne tient pas au données perdues mais au temps de redémarrage.
Je ne sais pas si c'est le cas dans toutes les PME, mais pour le directeur le temps d’indisponibilité est du chiffre d'affaire perdu. Nous sommes donc plus proche de haute disponibilité ( c'est pour cela qu'avant la virtualisation nous avions un serveur miroir)
Et c'est d'ailleurs comme cela que la société, qui à installée la virtualisation, l' a vendue => pas de perte de temps

En cas de plantage, il y a donc un conflit de moyen entre
- remonter une base avec les sauvegardes SQL du JT
- reprendre le dernier snapshot.

Or l'administrateur système garanti de remonter un snapshot en moins d'1 heure.
Je ne suis pas sûr d'être aussi rapide, donc je n'ai pas les arguments pour maintenir une sauvegarde complète.

[Jinroh77]

Si l'on ne prend en comtpe que la partie base de données, avec du SQL 2012 et le AlwaysOn, on a vu basculer des bases de plusieurs Téra en moins d'1minute....

Par contre, il y a aussi le côté applicatif.
Dans ce cas, je suis pour la virtualisation des applicatifs tout en gardant les BDD sur un serveur séparé, physique avec les méthodes de hautes disponibilités intégrées.

[mikedavem]

Or l'administrateur système garanti de remonter un snapshot en moins d'1 heure.
Je ne suis pas sûr d'être aussi rapide, donc je n'ai pas les arguments pour maintenir une sauvegarde complète.

Je pense que vous devez inclure la perte de données dans votre raisonnement. Votre directeur ne parle que de RTO ici qui pourrait éventuellement lui faire perdre du chiffre d'affaire en fonction du temps perdu mais il ne faut pas oublier que la perte de données peut également faire perdre de l'argent à une entreprise. Je prendrais un exemple simple d'une production ... effectivement il faut revenir le plus vite possible à une situation pérenne mais le fait de perdre des commandes clients lui fera également perdre de l'argent et du temps (eh oui il faudra bien récupérer les commandes perdues que ce soit d'un backup ou de façon manuelle comme j'ai pû le voir quelques fois). La virtualisation ne pourra rien pour vous dans ce cas contraitement à une bonne stratégie de sauvegarde avec SQL Server.

Maintenant au niveau rapidité, il faut comparer. Dans le cadre d'un PRA en combien de temps pouvez-vous revenir à une situation pérenne ?

Si vous cherchez de la haute disponibilité il faudra bien entendu vous orienter soit vers des solutions que SQL Server propose en natif soit vers la virtualisation qui reste également une bonne solution candidate.

++

[mikedavem]

Si l'on ne prend en comtpe que la partie base de données, avec du SQL 2012 et le AlwaysOn, on a vu basculer des bases de plusieurs Téra en moins d'1minute....

Je précise quand même que l'on peut faire exactement la même chose avant SQL Server 2012 avec du mirroring par exemple

++

[Ptit_Dje]

Remonter un snapshot d'une VM revient a remonter toutes les bases des instances tournant sur la VM.
Ce qui signifie que vous perdez la granularite quand au restore d'une seule base de donnees d'une instance specifique... Est ce quelque chose que l'on souhaite ?!
De plus le restore de snapshot n'est pas supporte par Microsoft pour SQL Server:
http://support.microsoft.com/?id=956893

[mikedavem]

Très juste même si dans la majorité des cas la restauration d'un snapshot fonctionnera.

++

[castorameur]

Très juste même si dans la majorité des cas la restauration d'un snapshot fonctionnera.

et c'est bien pour cela que l'utilisation de la sauvegarde SQL risque de disparaître. Il n'y a pas beaucoup de compétence de DBA dans les PME, et les sociétés vendant la virtualisation la vende clés en main avec un système de reprise facile.

Donc à terme je vais peut être perdre mes connaissances de DBA et la journalisation SQL ne servira plus à l’entreprise.

Mais comme tout débat, chacun peut faire en fonction de son propre avis et je vous remercie des vôtres qui m'ont éclairé dans ma réflexion.
Je clos la discussion.

[mikedavem]

Mais comme le dit bien Ptit_Dje, un snapshot ne remplacera pas une sauvegarde granulaire de bases de données par SQL Server.

Si vous n'avez qu'une seule base à restaurer, le snapshot sera plus long à remonter (remontage du snapshot + restauration de la base) qu'une simple restauration de base. A vous de voir ce que cela impliquera pour votre entreprise.

++

[SQLpro]

Il n'y a pas si longtemps, quelqu'un (que je ne nommerais pas) nous a parlé d'un client (dont je tairais le nom) qui avait virtualisé 800 bases de données.
Suite à un incident, et après 3 jours avec la hot line de MS il a pu récupérer 600 bases sur 800. Soit 200 bases perdues sur 800, c'est à dire 25% de pertes...

Bref, vive les PRA avec la virtualisation...

A +

[Ptit_Dje]

Envoyé par SQLpro

Il n'y a pas si longtemps, quelqu'un (que je ne nommerais pas) nous a parlé d'un client (dont je tairais le nom) qui avait virtualisé 800 bases de données.
Suite à un incident, et après 3 jours avec la hot line de MS il a pu récupérer 600 bases sur 800. Soit 200 bases perdues sur 800, c'est à dire 25% de pertes...

Bref, vive les PRA avec la virtualisation...

A +

Y a t'il un pattern spécifique\commun qui à pu être dégagé entre les bases remontées et celles perdues ? (volumétrie, workload, taille de la ram des vms, ...)

[SQLpro]

Impossible d'en savoir plus. En général ce genre d'incident est tellement grave que les entreprises communiquent peu sur le sujet !

A +