Performance: Interbase vs. Firebird

[IBExpert]

schau dir noch mal an ob beide datenbanken auch forced writes true sind (bei firebird default, bei interbase nicht!).

Am besten beide auf forced writes=true stellen (in ibexpert unter services-database properties).
Verbesserungsvorschlag: Deine ganze schleife sollte am besten vor der schleife ein aml starttransaction
machen und nachher einmal commit (außerhalb der schleife) machen.

das ergibt dann bei gleicher forced writes Einstellung ein reales Bild

Gruß
Holger
www.firebird-conference.com

[Nico80]

Das Commiten für jeden DS habe ich bewusst gemacht.
Aber es scheint das das Schließen bzw. Commiten einer Transaktion bei Firebird länger braucht.

[IBExpert]

wie steht denn forced writes jeweils?

Gruß
Holger
www.firebird-conference.com

[Nico80]

Interbase ist Forced Writes nicht markiert
Bei Firebird ist es markiert...

Was bedeutet Forced writes?

Nun habe ich bei Firebird das Häkchen weggenommen und siehe da, die Zeiten haben sich verbessert.
Leider ist Interbase immer noch schneller.

[Elvis]

Zitat von Nico80:

Das Commiten für jeden DS habe ich bewusst gemacht.

Das ist aber ein komplett unrealistisches Modell von den Anforderungen, die eine Applikation an ein DBMS stellt.
Keine sinnvoll entworfene Anwendung würde das machen, warum sollte dir das Ergebnis eines so unsinnigen Versuches eine Entscheidungshilfe sein?

Zitat:

Aber es scheint das das Schließen bzw. Commiten einer Transaktion bei Firebird länger braucht.

Sicher, dass beide Forced-writes aktiviert haben?
der Unterschied wäre höchstens minimal, bestenfalls kaum messbar. Bei realistischen Transaktionen wäre es wohl nicht messbar.

[IBExpert]

forced writes ist ein sicherheitsaspekt, der der wichtig ist.

forced writes aktiv=
beim commit werden alle geänderten datenpages in korrekter Reihenfolge so auf die Festplatte
geschrieben, das auch im Fehlerfall (serverabsturz) immer noch eine korrekte Datenbankdatei
auf der Festplatte zu finden ist und beim Neustart des Servers sofort weiter gearbeitet
werden kann

forced writes nicht aktiv=
beim commit werden die geänderten datenpages an das windows Betriebssystem übergeben, welches
dann bei Gelegenheit irgendwann mal die Daten auch auf die Festplatte schreibt. Das geschieht
aber in einer anderen Reihenfolge. Sollte dabei nun der Server ausfallen ist keineswegs
sichergestellt, das nach dem Neustart die DB benutzbar ist.

Was macht firebird anders?
Bei forced writes false wird trotzdem nach n operation oder n sekunden die datei in der richtigen
reihenfolge geschrieben. das kostet ggf Leistung. Das lässt sich bei Bedarf in der firebird.conf datei
anpassen.

Für einen Test sind 1000 Operationen mit 1000 Commits durchaus legitim, wenn das denn wirklich
so auftauchen wird. Bei derartigen minimaloperationen wie einem simplen Update ist das aber
eher nicht der Fall.

Wie schon gesagt: In meinem Test habe ich aber 800000 Operation in einer Transaktion gemacht und
da sieht fb2 wesentlich besser aus. Du solltest deine Testläufe auch erheblich vergrößeren, 1000
Operation lassen viel zu viel Raum für zufällige Einflüsse.

Ich würde aber ebenfalls immer versuchen mit den Transaktionen sparsam umzugehen. Das kostet nur
unnötig Performance. So etwas wie prepare und starttransaction sollte immer außerhalb einer
Schleife stehen.

Gruß
Holger
www.firebird-conference.com

[Nico80]

Habe mal die 4 DB-Aktionen gepostet.
Ich bin mir nicht sicher ob ich die Transaktionen richtig nutze?
Muss ich bei einem Select oder bei einer Stored Procedure die Transaktion commiten oder kann ich das DataSet einfach schließen?
Danke für die Hilfe...

Delphi-Quellcode:

function TDBFIBPlus2.GetPrimaryKey: Integer;
begin
  FStoredProcPrimaryKey.Transaction.StartTransaction;
  FStoredProcPrimaryKey.StoredProcName := 'GET_PRIMARYKEY';
  FStoredProcPrimaryKey.ExecProc;
  Result := FStoredProcPrimaryKey.Fields[0].AsInteger;
  FStoredProcPrimaryKey.Commit;
end;
//------------------------------------------------------------------------------
procedure TDBFIBPlus2.Insert(DataRec: TDataRec);
begin
  DataRec.Id := GetPrimaryKey;
  DataRec.LastUpdate := Now;
  FQueryInsert.Transaction.StartTransaction;
  if (not FQueryInsert.Prepared) then begin
    FQueryInsert.SQL.Text :=  'INSERT INTO table_test (id, name, number, lastupdate)'+
                                 ' VALUES(:id, :name, :number, :lastupdate)';
    FQueryInsert.Prepare;
  end;
  FQueryInsert.ParamByName('id').AsInteger := DataRec.Id;
  FQueryInsert.ParamByName('name').AsString := DataRec.Name;
  FQueryInsert.ParamByName('number').AsInteger := DataRec.Id;
  FQueryInsert.ParamByName('lastupdate').AsDateTime := DataRec.LastUpdate;
  FQueryInsert.ExecQuery;
  FQueryInsert.Commit;
end;
//------------------------------------------------------------------------------
function TDBFIBPlus2.Select(Id: Integer): TDataRec;
begin
  Result := nil;
  FDataSetSelect.AutoCommit := True;
  if (not FDataSetSelect.Prepared) then begin
    FDataSetSelect.Close;
    FDataSetSelect.SelectSQL.Text := 'SELECT * FROM table_test where id=:id';
    FDataSetSelect.Prepare;
  end;

  FDataSetSelect.Close;
  FDataSetSelect.ParamByName('id').AsInteger := Id;
  FDataSetSelect.Open;

  if (not FDataSetSelect.IsEmpty) then begin
    Result := TDataRec.Create;
    Result.Id         := Id;
    Result.Name       := FDataSetSelect.FieldValues['name'];
    Result.Number     := FDataSetSelect.FieldValues['number'];
    Result.LastUpdate := FDataSetSelect.FieldValues['lastupdate'];
  end;
end;
//------------------------------------------------------------------------------
procedure TDBFIBPlus2.Update(DataRec: TDataRec);
begin
  DataRec.LastUpdate := Now;
  FQueryUpdate.Transaction.StartTransaction;
  if (not FQueryUpdate.Prepared) then begin
    FQueryUpdate.SQL.Text := Format('UPDATE table_test SET name=:name, number=:number, lastupdate=:lastupdate WHERE id=:id',[]);
    FQueryUpdate.Prepare;
  end;
  FQueryUpdate.ParamByName('id').AsInteger := DataRec.Id;
  FQueryUpdate.ParamByName('name').AsString := DataRec.Name;
  FQueryUpdate.ParamByName('number').AsInteger := DataRec.Id;
  FQueryUpdate.ParamByName('lastupdate').AsDateTime := DataRec.LastUpdate;
  FQueryUpdate.ExecQuery;
  FQueryUpdate.Commit;
end;
//------------------------------------------------------------------------------
procedure TDBFIBPlus2.Delete(DataRec: TDataRec);
begin
  FQueryDelete.Transaction.StartTransaction;
  if (not FQueryDelete.Prepared) then begin
    FQueryDelete.SQL.Text := 'Delete FROM table_test where id=:id';
    FQueryDelete.Prepare;
  end;
  FQueryDelete.ParamByName('id').AsInteger := DataRec.Id;
  FQueryDelete.ExecQuery;
  FQueryDelete.Commit;
end;
//------------------------------------------------------------------------------

[Nico80]

@mkinzler
ODS-Version: Interbase 11.1
Firebird 11.0

laut IBExpert

[IBExpert]

wie schon gesagt, wenn du auf Performance wert legst, dann lege dein starttransaction und commit außerhalb der schleifen.

weiterhin wenn du getprimary key schon umständlicherweise extra abfragst, um den dann wieder hinzuschicken, dann mach
das in der insert transaktion. Einfacher (jedenfalls bei firebird): mach auf der Tabelle einen Autoincrement Trigger
(geht in IBExpert im Tabelleneditor durch doppelklick auf das pk feld unter autoincrement), so das der wert von
einem generator vergeben wird. (geht aber auch ohne ibexpert)
create generator id;

create table test
(id integer not null primary key,
bez varchar(80));

create trigger test_bi for test
active before insert position 0
as
begin
if (new.id is null) then
new.id = gen_id(id,1);
end;

Bei deinem Insert kannst du mit der returning anweisung diesen dann auch lesen

INSERT INTO TEST(BEZ) VALUES (:BEZ) returning ID;

(geht aber nur bei firebird >=2, nicht bei interbase)

damit kann der insert in einem sql abgehakt werden und brauch nicht noch weitere befehle, du
kannst aber trotzdem den vergebenen Wert auslesen.

und außerdem: wer manuell einen prepare macht, der sollte irgendwann auch den unprepare machen.
der belegt sonst speicher im server. Ist bei wenigen Datasets zwar fast egal, wird aber später mit
mehreren immer schwieriger, das im Griff zu haben. Den unprepare in der Schleife zu machen wäre
jetzt aber denkbar ungeschickt.

und noch was: ich hoffe deine get_primarykey prozedur benutzt zumindest einen generator und nicht
irgendeinen Tabelleninhalt, sonst wird dir das irgendwann im netzwerkbetrieb probleme machen.

Gruß
Holger
www.firebird-conference.com

[Nico80]

Das mit dem StartTransaction ist mir klar geworden...

Soll auch ein "Worst Case"-Test sein

Zitat:

und noch was: ich hoffe deine get_primarykey prozedur benutzt zumindest einen generator und nicht
irgendeinen Tabelleninhalt, sonst wird dir das irgendwann im netzwerkbetrieb probleme machen.

Jawohl...