Discussion :

[joker vb]

Salut à tous,

Je dois, pour un projet, faire un choix entre différents moteurs : MySQL, Access, Oracle, PostgreSQL, OpenOffice, Sybase, SQL Server.

Pour cette base nous devons nous assurer de récupérer le maximum de données au moment du plantage car ce sont des données assez sensibles. Qui serait en mesure de hiérarchiser ces moteurs sur ce point, merci d'avance

Il s'agit donc de savoir si la gestion des log permet de remonter jusqu'au crash

N.B : je posais cette question en particulier sur l'aspect LOG, mais si vous avez des remarques supplémentaires concernant les stratégies de sauvegardes de ces moteurs je suis toutes ouïes.

Oup's : j'ai oublié de vous demander un truc : la possibilité de faire des sauvegardes à chaud

[ylarvor]

SQL Serveur permet d'aller assez loin avec cette commande :
http://www.sqlservercentral.com/arti...ntintime/1905/

[gregory.broissard]

Tous les SGBDR de vrai production (avec du vécu) font cela : Sybase, Oracle, DB2 , SQLServer.

[ylarvor]

il existe une autre technique qui permet d'aller assez loin dans la récupération... il s'agit de sauvegarder le journal de transaction juste aprés le crash. On appelle ca la queue de journal je crois et de restaurer ce dernier journal qui contient les informations à l'instant du crash.

Un DBA confrmé pourra vous en dire, je ne connais que la théorie...

Quelque soit la base, le DBA sera indispensable...

[joker vb]

Salut,

Merci pour vos réponses.

Par contre sauriez vous me comparer MySQL et PostgreSQL

[ylarvor]

Je ne sais pas répondre... pose ta question sur le forum MySQL.

[SQLpro]

MysSQL est encore très jeune dans la gestion des transaction et travaille table à table ce qui est très pénalisant.
PostGreSQL à bien plus de bouteille sur le sujet et implémente le même algorithme de gestion de journal de transaction que Oracle ou SQL Server (ARIES).

A +

[orafrance]

Oracle a l'avantage de proposer un archivage des redologs (fichier de journalisation) ce qui permet de restaurer à l'archive près même en cas de perte des redos (qui en plus peuvent être multiplexé). Je ne crois pas que SQL Server propose ce type de sécurité sur le fichier logs en revanche on peut se tourner vers le log shipping

[SQLpro]

C'est pas différent fonctionnellement de ce que fait SQL Server. En pratique la différence est que Oracle utilise deux fichier (si je ne m'abuse) l'un avant, l'autre après, alors que pour SQL Server c'est le même fichier.

A +

[orafrance]

la différence c'est qu'Oracle utilise au moins 2 fichiers et que quand il passe de l'un à l'autre, ce qui n'est plus actif est archivé, ce qui permet de le sauvegarder. Alors que sous SQL, le log est un fichier unique et je ne sais pas ce qui se passe quand tu perds le disque... sous Oracle tu restaures la précédente sauvegarde et tu appliques toutes les archives pour retrouver la base dans l'état juste avant le crash au redolog actif près (qui lui évidemment est perdu )

[gregory.broissard]

DB2 a également le même fonctionnement qu'Oracle à la terminologie prêt

[SQLpro]

Sous SQL Server tu peut sauvegarder le journal de transaction à la fréquence que tu veut, la granularité étant au minimum d'une minute (mais paramétrable à la seconde).

Le mécanisme revient donc au même.

A +

PS : je ne vais plus rien avoir à t'apprendre...

[orafrance]

T'inquiète pas on trouvera des sujets à approfondir