Smart Metering Germany edit Out copy move delete

New Response

New Response with History

Check

Smart Metering Germany>Cuculus GmbH>RFQ>?EWE>?EWE A-L Contrib for Cu Review Re: 6.7-c Backup Konzept

Created By: Horst Toddenroth 31/08/2011 07:31:56 Updated By: Horst Toddenroth 31/08/2011 07:34:16 [Response to: Re: 6.7-c Backup Konzept by Ralf Kurschat] Grundstzlich untersttzt die Datenbanksicherung bei MySQL keine inkrementelle Siche rung. Ein Lsung gibte es ber das Bin-Log, wodurch inkrementelle Backups mglich wren, demen tsprechend auch inkrementelle Wiederherstellungen. http://dev.mysql.com/doc/refman/5.1/de/point-in-time-recovery.html

Bei Oracle sind Funktionen fr ein inkrementelles Backup vorhanden: http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/bkup004.htm 4.4 RMAN Incremental Backup ------------------------------------Smart Metering Germany edit Out copy move delete New Response New Response with History Check

Smart Metering Germany>Cuculus GmbH>RFQ>?EWE>?EWE A-L Contrib for Cu Review Welches Datenbanksystem wird konkret angebote? Re: 6.7-c Backup Konzept

Created By: Ralf Kurschat 01/09/2011 11:28:58 Updated By: Ralf Kurschat 01/09/2011 11:33:46 [Response to: Re: 6.7-c Backup Konzept by Horst Toddenroth] Um die Antwort zu 6.7-c abzuschliessen, knnten wir die Aussage zum Backupvolumen erst mal komplett weglassen.

Im Rahmen der Betrachtung der Backup-Strategie habe ich jedoch den Eindruck erha lten, das wir noch nicht entschieden haben, welches Datenbanksystem wir einsetze n wollen und wie wir mit den Datenmengen bezglich Backup und Archivierung umgehen . Hier sollte dringend eine Entscheidung getroffen werden, um berhaupt die Kosten a bschtzen zu knnen. Hier mein Input fr die Diskussion:

Backup / Restore: Erstellung Backup, Lastenheft Punkt 6.7-a ist ein KO Kriterium. Bei 500000 Zhlern und 15 Minuten Raster bei einer Speicherdauer von 2 Jahren bele gt ein kompletes Backup unkomprimiert ca. 132 Terabyte. Bei 3,5 Mio Zhlern sind die Volumina entsprechend 7x hher! 2 Jahre ist der Dimensonierungsansatz von Cuculus (siehe Beschreibung 6.5-g ). Im Lastenheft steht 37 Monate, siehe 3.5-i "Speicherung der Rohdatenstze". 132 Terabyte knnen gesichert werden, aber es wird ein "Monster" bentigt, z.B. eine HP EML 442e Tape Library mit 442 Cartridges, 16 aktiven Laufwerken, einer Kapaz itt von 1326 TB und einem Durchsatz von 16 TB/Stunde. Zustzlich werden natrlich Fibre Channel SAN, Diskarray zu Puffern, zentale BackupServer und Software bentigt. EWE sollte darber nachdenken, ob wirklich 37 Monate online gehalten werden mssen. Warum sollten angesichts der Kosten 13 Monate nicht ausreichen? Mein Vorschlag zum Backup-Konzept ist: vollstndiges Backup wchentlich, dazwischen tglich ein inkrementelles Backup. Ein tgliches inkrementelles Backup knnte bezogen auf die oben genannten 500000 Zhle r bei "niedlichen" 200 GB liegen. Allerdings msste das eingesetzte Datenbanksyste m ein solches Verfahren mit akzeptabler Performance untersttzen.

Datenbanksystem: Gefordert von EWE wird Oracle oder MS-SQL, wir untersttzen Oracle und MySQL (sieh e 6.6-c). Vom DB-System abhngig ist das Backup/Restore Konzept. Incrementelles Backup wird eigentlich nur ber Oracle mit hoher Performance unters ttzt. Mit dem MySQL Binlog-Mechanismus ist es theoretisch mglich, aber reicht die Perfo rmance und wollen wir wirklich MySQL anbieten, wenn der Kunde Oracle oder MS-SQL mchte? Welches DB-System bieten wir konkret an? (betrifft Leistungsbeschreibung, Kosten aufstellung)

Archivierung: Lastenheft Forderung 3.5-h: "Archivierung der Rohdatenstze" ist ein KO Kriterium und es gibt eine gesetzliche Verpflichtung. Soweit ich weiss gibt es so eine Funktion im Zonos bisher nicht. Wir mssen mindestens Erfllungsgrad 3 "nur mit erheblichem Aufwand, z. B. durch Ent wicklung individueller Software- Add-Ons realisierbar (mehr als 2 Leistungstage) " angeben. Gefordert wird nach meinem Verstndnis aber nur die Anbindung an ein Archiv, nicht die Bereitstellung des Archivs selbst. Zu den genannten Systemen OpenText und SER habe ich noch Fragezeichen. In welche m Format sollen wir die Daten der AMM Plattform an das Archiv bergeben? Warum sol lten wir Datenbankinhalte wie Zhler in ein Archivierungssystem bergeben, das sich primr um die Archivierung von Text-Dokumenten kmmert? Wre im Hinblick auf die sptere Auswertung nicht die bergabe an ein Datenbank-basiertes System (Datawarehouse od er oder z.B. IBM Cognos) sinnvoller? Ausserdem: Sollen wir 10 Jahre alte Archivdaten wirklich in das AMM System zurckl aden? Ist es nicht sinnvoller einen separaten Reporting-Server aufzusetzen, der das AMM-System nicht belastet und selbstndig die archivierten Daten barbeitet? Wa hrscheinlich braucht der dann aber nicht nur die archivierten Daten, sondern auc h die aktuellen Online-Daten, was dafr sprche, dass Daten nicht erst nach 37 Monat en achiviert werden, sondern so frh wie mglich.