Discussion :

[SQLpro]

Oui, vous continuez à vous tromper. Je vous ais déjà expliqué pourquoi. Le fait de bloquer une table n'assure en aucune manière la consistance transactionnelles. Mais comme vous ne savez visiblement pas ce qu'est une transaction, ni quels sont les mécanismes à mettre en jeu dans une sauvegarde....

Donc, je reprend l'exemple déjà mentionné :
A un temps T la sauvegarde copie la table des clients en la bloquant.
A un temps T+1 une transaction on insère un client et une nouvelle facture assortie à ce client.
A un temps T+2 la sauvegarde copie la table des factures.

A la restauration la tables des facture comporte une facture sans client. La cohérence de la base de données est morte.

Quand aux "transactions qui sont consistantes en lecture" ce n'est vraiment pas le problème, ce qui me renforce dans le fait que vous ne connaissez rien aux transactions... Alors arrêtez SVP de donner des conseils stupides et profitez de developpez.com pour en apprendre un peu plus sur les fonctionnement des SGBDR !

A +

[Antoun]

Je crois qu'il y a une vraie opposition de culture ici, qui est assez intéressante : culture OLTP, centrée sur la saisie, et culture OLAP, centrée sur la lecture et moyennement concernée par les question d'intégrité.

Pour ce qui concerne la problématique de sauvegarde à chaud, c'est évidemment une question OLTP (Jester indiquait d'ailleurs un peu plus haut que cette question lui semblait relativement exotique...).

[Jester]

J'ai effectué votre test et je me permets de ne pas être d'accord.

oltp> représente les opérations de BD habituelles et dump> un backup (dans des connections séparées).

/* création des tables en innodb, sinon ça ne marche pas */
oltp> create table client (clientId int) engine=innodb;
oltp> create table facture (fkClientId int) engine=innodb;

/* On débute la sauvegarde */
dump> start transaction;

/* On sauvegarde la table client sans la bloquer (vide) */
dump> select * from client;
Empty set (0.00 sec)

/* On ajoute un client et une facture dans une transaction tierce. */
oltp1> start transaction;
oltp1> insert into client values (1);
oltp1> insert into facture values (1);
oltp1> commit;


/* On affiche le contenu de la table facture avec une autre transaction pour bien prouver que pourtant quelque chose a été ajouté dans la table et est déjà visible */
oltp2> select * from facture;
+-----------+
| fkClientId |
+-----------+
| 1 |
+-----------+
1 row in set (0.00 sec)

/* On sauvegarde la table facture sans la bloquer */
dump> select * from facture;
Empty set (0.00 sec)
/* La table est toujours vue vide, donc il n'y a pas d'erreur dans la sauvegarde. */


Donc on vient de faire une sauvegarde consistante, à chaud et sans blocage.

PS : Il est vrai que je suis plus dans de l'OLAP, mais certaines tables peuvent être modifiées pendant mes sauvegardes, j'aimerais autant pas me planter. Ce n'est pas que le backup m'est exotique, mais que je n'ai pas besoin d'utiliser les méthodes exotiques comme LVM.

[orafrance]

Vous n'avez pas compris l'exemple de SQLPro

Créez le client 1 et la facture 1
Sauver client
Créez le client 2 et la facture 2
Sauver facture

Résultat : la facture 2 est sauvée alors que la sauvegarde de client ne contient que le client 1 vous avez alors dans vos sauvegardes une incohérence avec une facture sans client

[Jester]

Je pense que le problème est plutôt que pour moi le processus de sauvegarde est dans une transaction (suite de select into file ou mysqldump --single-transaction), ce qui ne semble pas le cas dans ce que vous présentez, de ce que j'en comprend du moins (sinon il n'y aurait pas d'incohérence comme le prouve mon exemple qui est comme le votre avec des transactions et sans client 1 et facture 1).

J'imagine qu'il y a de bonnes raisons pour ce que la technique de sauvegarde que vous utilisez dans votre exemple ne soit pas dans une seule transaction (vos deux sauver). Mais dans mon cas, pouvant dumper toutes mes tables dans une seule transaction (avec des select into file), je n'ai pas, je pense, ce problème d'incohérence même si l'exécution du backup et d'opérations tierces se déroule selon votre plan.

[Antoun]

Soyons précis ! Je rejoins Jester, mais avec une série de réserves : dans une transaction en REPEATABLE READ (qui est le mode d'isolation par défaut), une série de SELECT INTO OUTFILE, ou encore un mysqldump avec --single-transaction, on aurait la sauvegarde à chaud d'un snapshot cohérent.

J'attire néanmoins votre attention sur une réserve importante : la sauvegarde ne reste cohérente que tant qu'aucune session concurrente ne fait de DDL :

--single-transaction
Creates a consistent snapshot by dumping all tables in a
single transaction. Works ONLY for tables stored in
storage engines which support multiversioning (currently
only InnoDB does); the dump is NOT guaranteed to be
consistent for other storage engines. While a
--single-transaction dump is in process, to ensure a
valid dump file (correct table contents and binary log
position), no other connection should use the following
statements: ALTER TABLE, DROP TABLE, RENAME TABLE,
TRUNCATE TABLE, as consistent snapshot is not isolated
from them. Option automatically turns off --lock-tables.

Tout ça évidemment sous réserve de test... Au final, je pense donc qu'on peut aussi bien dire "InnoDB permet la sauvegarde cohérente à chaud" que "InnoDB ne garantit pas que la sauvegarde cohérente à chaud soit 100% sécurisée".

[SQLpro]

Non, car une transaction peut porter aussi bien sur du DML que sur du DDL.
Or dans l'exemple cité, les transactions s'enchainent et la cohérence de la base est perdue. A la restauration la facture est orpheline de son client. Pire avec une transaction encapsulant du DDL que MySQL n'a jamais sut traiter...

A +

[Jester]

Or dans l'exemple cité, les transactions s'enchainent et la cohérence de la base est perdue. A la restauration la facture est orpheline de son client.

Je suis tout à fait d'accord alors. Si le backup est dans deux transactions distinctes, alors la cohérence n'est pas assurée. Mais si c'est dans une seule transaction, ce qui est mon cas, alors la cohérence est assurée.

Pire avec une transaction encapsulant du DDL que MySQL n'a jamais sut traiter...

Oracle non plus aux dernières nouvelles.

[orafrance]

Oracle non plus aux dernières nouvelles.

Si si, RMAN utilisant les archivelogs, tu as toutes les transactions backupées idem pour SQL Server grâce au transaction log

[Antoun]

On est d'accord, InnoDB ne gère pas le DDL dans les transactions, ni dans la transaction considérée ni même dans les transactions concurrentes. Ton point de vue rigoriste "ce n'est pas conforme à 100%, donc ce n'est pas conforme, point barre" est parfaitement exact. Il n'empêche pas que le point de vue plus laxiste "ça marche sauf si" est également exact... tant qu'on ne fait pas sauter le "sauf si".

Du point de vue du comparatif de fadace, il faut évidemment choisir le point de vue rigoriste, sinon on rentre dans trop de détail.

[Jester]

Si si, RMAN utilisant les archivelogs, tu as toutes les transactions backupées idem pour SQL Server grâce au transaction log

Je répondais juste à ce que je citais, sur le fait que mysql ne savait pas gérer les requêtes DDL dans le transactions. Il me semble qu'il fait un commit avant et après une telle requête. Ayant débuter sur Oracle, ça me semblait normal. Je me souviens avoir été bluffé que postgresql sache faire des rollback sur des transactions avec des requêtes DDL.

Pour les sauvegardes, j'imagine bien qu'Oracle ou SQL Server savent presque tout faire. Je n'ai jamais eu besoin de le savoir d'ailleurs.

[Antoun]

Je suis tout à fait d'accord alors. Si le backup est dans deux transactions distinctes, alors la cohérence n'est pas assurée. Mais si c'est dans une seule transaction, ce qui est mon cas, alors la cohérence est assurée.

Non : même si tu fais le backup dans une seule transaction, ça n'empêche pas UN AUTRE UTILISATEUR dans une transaction concurrente de balancer un ordre DDL qui vient foutre la merde dans ton backup.

[Jester]

Non : si tu fais le backup dans une transaction, ça n'empêche pas UN AUTRE UTILISATEUR dans une transaction concurrente de balancer un ordre DDL qui vient foutre la merde dans ton backup.

En effet, voilà un point intéressant auquel je n'avais pas pensé.

PS : et qui met mysql en échec.

[Vincent Rogier]

MS SQL Server 2008 :

Avantages :
Niveau de SQL très près de la norme SQL et implémente presque toutes les possibilités de SQL.

Affirmation non vérifiable (donc subjective) car le souci est qu'il est impossible de trouver quoi que ce soit la dessus. Donc aucun élément de référence objectif.

A moins que SqlPro m'en sorte de son chapeau magique.

D'autres SGBD publient leur conformance à la norme ISO mais SqlServer apparemment non...

On sait que Oracle n'est pas 100% conforme (et de loin) mais au moins eux ils le disent et sont clairs la dessus (description détaillée de leur conformance module par module de la norme)

De plus la norme ne concerne pas que le langage SQL au sens strict du terme, mais aussi par exemple la fourniture de embedded SQL, etc..

sinon concernant le comparatif en lui même, les introductions de Oracle et Sybase me semblent un peu trop subjectives
Celle d'oracle carrément hors propos avec la comparaison avec MySql qui n'a pas de sens car il sont dans des niches différentes... On aurait pu faire la même intro pour Sybase ou BD2 en les comparant en MySql....

Ma foi...

[SuperNiKo]

Hello tous,

Je me permets d'embrayer là dessus pour savoir qui, selon vous, domine le marché ?
Je veux dire, j'ai quelques vagues notions de BDD vu en cours et principalement sur du Oracle à cause d' un enseignant chercheur qui a travillé avec eux. Selon lui c 'est Oracle et le reste du monde.

Est ce vraiment comme ça ? De tête et avec ma toute petite expérience, j'ai l 'impression que c 'est :
- IBM DB2 pour les trés grands comptes (3suisses, la redoute...)
- Mysql pour les joujous sur internet ( à quelques exceptions prêt comme toujours ), trés utilisé mais pour des petites bases.
- Microsoft SQL pour les utilisateurs de .Net
- Oracle tout le reste..

Vrai/ faux ?

[orafrance]

Non, il n'y a pas particulièrement de partage comme ça, tu trouves aussi de très grosses bases sous SQL ou Oracle pour des sites web... et du MySQL pour des outils de gestion... donc bon... on peut pas vraiment classifier de la sorte

[Vincent Rogier]

- IBM DB2 pour les trés grands comptes (3suisses, la redoute...)

Il y a beaucoup plus de "tres grand compte" sous oracle que sous DB2....
Oracle est surtout présent dans le bancaire et l'industriel puis ensuite dans le reste

[al1_24]

Tu as sans doute fait un raccourci entre grands comptes et gros systèmes.
DB2 est très présent sur les gros systèmes, plus utilisés par des grands comptes que par des petites structures

[SQLpro]

Affirmation non vérifiable (donc subjective) car le souci est qu'il est impossible de trouver quoi que ce soit la dessus. Donc aucun élément de référence objectif.

A moins que SqlPro m'en sorte de son chapeau magique.

D'autres SGBD publient leur conformance à la norme ISO mais SqlServer apparemment non...

C'est bien plus simple dans SQL Server puisque c'est automatisé au niveau du moteur. En effet la mise en place du flag SET FIPS_FLAGGER permet de flaguer toutes les commandes et leur niveau de conformité. Vous pouvez donc juger par vous même !

Syntaxe

SET FIPS_FLAGGER 'level'


Arguments
' level '
Niveau de conformité à la norme FIPS 127-2, vérifié dans toutes les opérations effectuées dans les bases de données. Si une opération de base de données entre en conflit avec le niveau des normes ISO choisi, Microsoft SQL Server génère un avertissement.

Le paramètre level doit prendre l'une des valeurs suivantes :

Valeur Description
ENTRY
Vérification des normes pour la conformité ISO de base.

FULL
Vérification des normes pour la conformité ISO complète.

INTERMEDIATE
Vérification des normes pour la conformité ISO de niveau intermédiaire.

OFF
Pas de vérification des normes.


Remarques
L'option SET FIPS_FLAGGER est appliquée lors de l'analyse, et non pas lors de l'exécution. Par conséquent, si l'instruction SET est présente dans la procédure stockée ou le traitement d'instructions, elle devient effective, que l'exécution du code ait réellement atteint ou non ce point ; l'instruction SET devient effective avant l'exécution de toute autre instruction

A +

[Fabien Celaia]

J'ai corrigé (enfin... re-re-re-corrigé) les sauvegardes à chaud sur MySQL en supprimant la remarque Innodb.

J'en profite pour assumer ma remarque, toujours sur MySQL, concernant les vues matérialisées, selon un échange d'email que j'ai eu:

Ce Monsieur réagis au comparatif des SGBD qui spécifie que pour MySQL, les vues matérialisées n'existent pas.

A l'époque (2005), je me suis référé à un commentaire dans un forum : http://mysql.ifrance.com/archive/index.php/t-150.html

En v.5, on en eat toujours à de la simulation : http://dev.mysql.com/doc/refman/5.0/en/create-view.html

Il se peut que dans sa dernière version, MySQL comprenne cette notion de vue matérialisée, mais je ne l'ai pas encore trouvée... donc pas encore modifié le désavantage du comparatif.

Ils en parlent souvent, mais simulent en fait la MV avec une table de travail qu'ils rafraichissent par purge... ce qui n'est pas de la MV à proprement parler...

En cas de preuve du contraire, je corrigerai

m.s.
Fadace

Bonjour Fadace,

Ci dessous un msg reçu d'un internaute, je ne vois pas trop de quelle page il parle . Peux-tu voir et me dire si çà retombe chez moi ?



--------- Message transféré ----------
De : <pxxxxxxxxxxxxx@viamichelin.com>
Date : 30 juin 2009 17:59
Objet : Dans l'article Quel SGBD choisir ...
À : sgbd@redaction-developpez.com



Bonjour,

Dans la partie MySQL, il semble que les vues soient présentes contrairement à ce qu'il est indiqué.

Cordialement,

Paul