|
|
|
Publicité ' | |||||||||||||||||||||||
11/01/2008, 14h23
|
#1 |
|
Nouveau Membre du Club
 Inscription : janvier 2006 Messages : 116  |
Quel SGBD a une bonne gestion des LOGs ?
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 
|
|
00
|
|
11/01/2008, 21h29
|
#2 |
|
Membre Expert
  Inscription : août 2002 Messages : 1 249  |
POINT IN TIME
SQL Serveur permet d'aller assez loin avec cette commande :
http://www.sqlservercentral.com/arti...ntintime/1905/ |
|
00
|
|
15/01/2008, 14h56
|
#3 |
|
Membre expérimenté
  Inscription : mai 2005 Messages : 414 |
Tous les SGBDR de vrai production (avec du vécu) font cela : Sybase, Oracle, DB2 , SQLServer.
|
|
|
00
|
|
15/01/2008, 17h36
|
#4 |
|
Membre Expert
Inscription : août 2002 Messages : 1 249 |
restauration.
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... |
|
|
00
|
|
16/01/2008, 10h56
|
#5 |
|
Nouveau Membre du Club
Inscription : janvier 2006 Messages : 116 |
Salut,
Merci pour vos réponses. Par contre sauriez vous me comparer MySQL et PostgreSQL |
|
|
00
|
|
16/01/2008, 13h37
|
#6 |
|
Membre Expert
Inscription : août 2002 Messages : 1 249 |
forum MySQL
Je ne sais pas répondre... pose ta question sur le forum MySQL.
|
|
|
00
|
|
28/03/2008, 22h34
|
#7 |
    
  Frédéric BROUARDExpert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 |
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 +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
|
|
00
|
|
01/04/2008, 09h59
|
#8 |
Inscription : janvier 2004 Messages : 15 861 |
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
|
|
|
00
|
|
03/04/2008, 09h06
|
#9 |
|
Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 |
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 +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
|
|
00
|
|
03/04/2008, 09h27
|
#10 |
|
Inscription : janvier 2004 Messages : 15 861 |
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
)
|
|
|
00
|
|
03/04/2008, 10h07
|
#11 |
|
Membre expérimenté
Inscription : mai 2005 Messages : 414 |
DB2 a également le même fonctionnement qu'Oracle à la terminologie prêt
|
|
|
00
|
|
03/04/2008, 17h09
|
#12 |
|
Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 |
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...
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
|
|
00
|
|
03/04/2008, 17h17
|
#13 |
|
Inscription : janvier 2004 Messages : 15 861 |
T'inquiète pas on trouvera des sujets à approfondir
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com