Konzept zur Datenbanktrennung.

[Pro_RJ]

Das Problem ist, was will ich in der Software optimieren?
So wird ein Backup ausgeführt:

Delphi-Quellcode:

Function Backup_Ausfuerhen(BackSer : TIBBackupservice;DBFile,BackupFile1 : String; Memo1 : TMemo;ProtocolGes1 : TProtocol;ServName : String;Pan : TPanel;MSG,Garb : Boolean) : Boolean;
Var i   : Integer;
    ok  : Boolean;
    //Anz : String;
    //Fo : TForm;
Begin
  //Fo := NIL;
  if Memo1 <> NIL then
  Begin
    //if Memo1.Owner IS TFOrm then Fo := TForm(Memo1.Owner);
    Memo1.Font.Size := 8;
  end;


  BackupFile1 := Copy(DBFile,1,Length(DBFile)-4)+'_Backup.gbk';
  i := 0;
  with BackSer do
  begin
    if Pan <> NIL then
    Begin
      Pan.Visible := true;
      Pan.caption := 'Backup wird ausgeführt';
      Pan.Refresh;
    end;
    Params.Clear;
    Params.Add('user_name='+G_DB_user);
    Params.Add('password='+G_DB_kw);
    Protocol       := ProtocolGes1;
    ServerName     := ServName;
    Verbose        := True;


    if Garb = true
    then Options        := []
    else Options        := [NoGarbageCollection];

    //Options        := [NoGarbageCollection];

    DatabaseName   := DBFile;   // ersetzen
    LoginPrompt    := False;
    Active         := True;
    BackupFile.Clear;
    BackupFile.Add(BackupFile1);

    if Memo1 <> nil then Memo1.Lines.Clear;
    try
      ServiceStart;
      ok := True;
    except
      on E:exception do
      Begin
        if MSG then  Showmessage(e.Message);
        FehlerProtokollSchreiben(13,[e.Message],[],[]); // Fehler beim Backup
        ok := False;
      end;
    end;
    if ok = true then
    begin
      try
        While not Eof do
        Begin
          INC(i);
          if Memo1 <> nil then Memo1.Lines.Add(AuffuellenAufN(X(i),4)+': '+GetNextLine);
          Application.ProcessMessages;
        end;
        ok := True;
      except
        on E:exception do
        Begin
          if MSG then  Showmessage(e.Message);
          FehlerProtokollSchreiben(13,[e.Message],[],[]); // Fehler beim Backup
          ok := False;
        end;
      end;
    end;
    try
      PfadPruefUAnleg(G_Path + Log_Datei_BackUp_Restore(1));
      if Memo1 <> nil then Memo1.Lines.SaveToFile(G_Path + Log_Datei_BackUp_Restore(1));
    except
    end;
    if Memo1 <> nil then Memo1.Lines.clear;
    Active := False;

    if Pan <> nil then
    Begin
      Pan.caption := 'Backup wurde ausgeführt';
      Pan.Refresh;
    end;
  end;
  result := ok;
end;

Sicherlich könnte man durch bessere Hardware nochmal Zeit rausholen aber an der Grundsätzlichen Programierung kann ich nicht viel ändern. oder Seht ihr in den Text noch was was ich anderes machen könnete?

Das Problem ist halt, das das Handling besser werden soll --> und das geht nur mit ner Kleineren DB.
Sicherlich ist aber der Ansatz, das ich die Daten die ich nicht immer brauche archiviere ganz ok.
Ich hab auf meinem Schreibtisch ja auch nicht die Akten der letzten 10 Jahre.

[mikhal]

Sichert der Kunde seine Datenbank über eine Leitung von einem anderen Standort?. Bei uns wird eine Sicherung zweier Datenserver über eine 2 MBit Leitung realisiert, dabei dauert die Sicherung einer Oracle-Datenbank mit etwa 2,5 GByte Tablespace tatsächlich etwa 5 Stunden.

Grüße
Mikhal

[Pro_RJ]

der sichert einmal über eine Normale WindoofKopie im Explorer und auf USBPlatte was aber "Normal" schnell geht.

[Billa]

Muß die Sicherung wirklich innerhalb des Programms laufen? Was ist mit gbak? Das hat den Charme, daß man nicht auf das Backup warten muß, es läuft transaktionsgesteuert und erzeugt einen schönen Schnappschuss ... im übrigen gebe ich s.h.a.r.k. und elvis Recht: Ich würde das Konzept überdenken.

[mkinzler]

Die Komponente verwendet m.W. gbak

[Pro_RJ]

Ich hab gerade nochmal mit meinem Cheff gesprochen.
Die Aufgabenstellung lautet: das Backup/Restore soll in 1.5-2.5 Stunden fertig sein.
Wie ich das anstelle hat er mir eben frei gestellt.
Das Backup/Restore wird zu einer Zeit gemacht, wo niemand auf der Datenbank arbeitet.
Welchen Lösungsansatz könntet ihr mir ür diese Aufgabenstellung geben?

[eddy]

Wie wäre es denn mit der Version:
2. PC hinstellen (muß auch nicht der neueste sein), Datenbank packen und auf Festplatte des Sicherungs-PC speichern.
Beim Packen werden die meisten Datenbanken auf 10 % zusammengeschrumpft.

mfg
eddy

[Pro_RJ]

Zitat:

Zitat von eddy

Wie wäre es denn mit der Version:
2. PC hinstellen (muß auch nicht der neueste sein), Datenbank packen und auf Festplatte des Sicherungs-PC speichern.
Beim Packen werden die meisten Datenbanken auf 10 % zusammengeschrumpft.

mfg
eddy

:gruebel:
und wo liegt die Zeitersparniss beim Backup/Restore?

[Elvis]

Teste mal ein Backup auf eine andere Platte auf dem gleichen System wie der FB Server.
Oder eine andere Maschine, die dann aber mindestens mit GBit LAN mit dem FB Server verbunden ist. (gbak läuft dann auf der anderen Maschine)

Woher wisst ihr überhaupt, dass ein Backup/Restore(B&R) so lange dauert? :zwinker:
Kann es sein, dass ihr das öfters macht? Normal sollte das nur notwendig sein, wenn irgendetwas Schlimmes passiert ist...

Viele machen den Fehler und verwenden B&R um die DB files kleiner zu kriegen, oder ganz schlimm: offene Transaktionen zu schließen.
Firebird wird ein DB file niemals von sich aus schrumpfen lassen, und das macht auch Sinn:
Denn wenn die Datei einmal so groß wurde, wird sie wieder so groß werden. Wenn FB den Platz vorreserviert muss keine Kopie der Datei angefertigt werden (denn genau das passiert wenn Dateien wachsen) und die Dateifragmentierung bleibt auch noch im grünen Bereich.

@Pro_RJ
Die Erssparnis liegt darin, dass du den DB Server in der Zeit im Readonly Modus weiterlaufen lassen könntest.
Allerdings riecht das ein wenig "fishy" nach einer VB'ler-Lösung. ;-)

[Der Jan]

Nur so als Gedanke... Setz mal Verbose := false
Oder brauchst du die detaillierten Ausgaben? Das kann ganz schön bremsen, wenn die Leitung vlt belastet oder nicht so dick ist...