IBPhoenix Superserver vs. Interbase 6.0.x

[Holger Deubel]

Hallo zusammen,

wo genau ist denn der Unterschied zwischen dem Superserver von IBPhoenix und der Interbase 6.0.x (von z.B. Mers.com)? Welche Version ist denn empfehlenswerter und vor allem: Welche Version ist perfomanter?

Hintergrund: Massive Performanceprobleme mit der Interbase 6.0.1.6. Die vorige Version / Interbase 5.6 war gegen den momentanen Zustand (Bobbycar) ein Formel1wagen.

Grüße,
Holger

[Klemmo]

Das Problem liegt mit Sicherheit nicht in der grundsätzlichen Performance, sondern muß analysiert werde anhand der jeweiligen Befehle, die eben jetzt langsamer sind.

Es kann durchaus sein, das ein Befehl jetzt eine andere Indexstrategie benutzt (Ist bei einer DB auch mal aufgetreten beim Wechsel von 6.0.1 auf 6.0.1.6 ). Mit einer Umstellung der Where Bedingung, einem zusätzlichen Order by oder einem Indexplan ließ sich das beheben.

Gruß

Holger Klem

[Holger Deubel]

Hallo Herr Klemt,

Sie kennen doch die Komplexität unserer Datenbank... Um jedes Statement zu prüfen würden wir Ewigkeiten brauchen. Es ist nicht so, dass einzelne Abfragen extreme Performanceeinbußen haben, sondern scheinbar sämtliche SQL-Statements langsamer geworden sind.

Offensichtlich arbeitet der interne Optimizer der Interbase 6 nach einem anderen Regelwerk. Rulebased - Costbased???? Unklar ist, ob der Optimizer konfigurierbar ist. Kann man ihn nach dem Regelwerk der 5.6er einstellen?

Die andere Frage war: Was ist der Unterschied zwischen Firebird und Interbase?

Viele Grüße,
Holge

[Klemmo]

leider geht das so einfach nicht. Beide Datenbanken arbeiten costbased, aber es gab in der Umstellung von ib5 auf ib6 einige
Veränderungen, die auch die Indexbenutzung betraf. Grundsätzlich langsamer ist aber keine der verfügbaren Varianten.

Eventuell hilft ein Test mit der Version 6.5 (als trial bei www.borland.com verfügbar).

Man könnte auch den benutzten Querys ein Ergeignis beforeOpen und afterOpen zuweisen, in denen eine Textdatei mit dem SQL Text geschrieben wird und die Zeit zur Ausführung gemessen wird
(man braucht ja nur die sqls zu schreiben, wenn die zeit n ms überschritten hat).

Die dabei auftauchenden SQLs müßte man dann analysieren.

Gruß

Holger Klem

[Gesine Kuhlmann]

Hi,

Kann sein, dass ich mich täusche: Aber ist der Unterschied zwischen IB5.6 und V6.0 nicht gerade die SS-Architekur ??

Gruß
Gesin

[Karsten Strobel]

> Aber ist der Unterschied zwischen IB5.6 und V6.0 nicht gerade die SS-Architekur ??

Nein, die SS-Architektur wurde schon mit einer IB4.x Version eingeführt und ist seitdem (bei Win32) die einzige die es gibt.

Gruss
Karsten Strobe

[Holger Deubel]

<I>leider geht das so einfach nicht. Beide Datenbanken arbeiten costbased, aber es gab in der Umstellung von ib5 auf ib6 einige Veränderungen, die auch die Indexbenutzung betraf. Grundsätzlich langsamer ist aber keine der verfügbaren Varianten. </I>

man kann bei einem renomierten dbms aber eigentlich davon ausgehen, dass bei query's vorhandene indices auch genutzt werden. das ist aber leider nicht der fall! außerdem werden driving tables einfach ignoriert und daten willkürlich aus den tabellen gezogen. ein umstellen der joins brachte zwar veränderungen im plan, aber niemals ein befriedigendes ergebnis. interbase doch dumm...?

<I>Eventuell hilft ein Test mit der Version 6.5</I>

nicht schon wieder...

<I>Nein, die SS-Architektur wurde schon mit einer IB4.x Version eingeführt und ist seitdem (bei Win32) die einzige die es gibt.</I>

und was macht die superserver architektur genau? was ist das?

grüße,
holge

[Andreas Kosch]

Hallo,

&gt; man kann bei einem renomierten dbms aber eigentlich davon ausgehen,<br>
&gt; dass bei query's vorhandene indices auch genutzt werden. das ist aber leider nicht der fall!

ein SQL-Server wäre schlecht beraten, wenn ein vorhandener Index in <b>jedem</b> Fall genutzt würde.

Angenommen, eine Tabelle hätte 100 Datensätze, wobei jeweils 10 Datensätze auf eine Datenbankseite (Page) passen. Angenommen, der Index ist so aufgebaut, dass jeder Eintrag in seiner Reihenfolge auf einer anderen Datenbankseite liegt. Wenn man in diesem einfachen Fall den Datenbank-Cache ignoriert, würde folgende Situation entstehen:

Fall A (mit Index): Der InterBase müsste 100 Pages einlesen (d.h. 100 I/O-Operationen der Festplatte), da jeder neue Datensatz über den Index auf einer anderen Seite liegt.

Fall B (ohne Index): Der InterBase liest alle 10 Seiten der Datenbank sequentiell ein (d.h. 10 I/O-Operationen der Festplatte) und sortiert erst danach im Arbeitsspeicher.

Da heute die CPU deutlich schneller sortieren kann als die mechanische Festplatte Daten liefert, ist Fall B immer dann besser, wenn es nicht nur 100 Datensätze sind. Daher ist es richtig, wenn der Optimizer die Kosten der verschiedenen Zugriffspfade schätzt und dann seine Wahl trifft. In der Regel wird auch das Optimimum erreicht - aber es gibt immer Ausnahmen von der Regel (die im Einzelfall über den QUERY PLAN überstimmt werden können).

&gt; und was macht die superserver architektur genau? was ist das?

Der Superserver spaltet nicht mehr für jeden Client einen neuen Prozess ab, sondern verwaltet alle Clients in einem Prozess über verschiedene Threads. Der Vorteil des Superservers liegt darin, dass Threads viel effektiver arbeiten und der Datenbank-Cache für alle Clients gemeinsam genutzt werden kann.

Steht eine 2. Festplatte zur Verfügung? Noch besser wären 2 Festplatten, die als RAID 0 konfiguriert werden. In diesem Fall würde ich in der Konfigurationsdatei <b>ibconfig</b> den Pfad für die temporären Dateien ändern (oder die System-Umgebungsvariable <b>INTERBASE_TMP</b> entsprechend setzen):
<pre>
TMP_DIRECTORY 1000000000 "d:\temp"
</pre>
&#10

[Holger Deubel]

Hallo Andreas,

also, wir haben unterschiedliche Raid-Configurationen...

Raid 1 (gespiegelt) fürs Betriebssystem (auch Temppfad)<BR>
Raid 5 (3 Platten) für die Datenbank

Das ganze hängt an einem SCSI Ultra 160 Controller, der wohl Performant genug ist. Raid 0 halte ich hinsichtlich der Datensicherheit für nicht geeignet.

Wie wäre es mit einem RAM-Laufwerk für die Interbase Tempdateien? Insgesamt stehen 3 GB zur Verfügung und werden von Interbase sowieso nicht voll ausgenutzt.

Apropos RAM: Wir haben soviel Speicher auf dem Rechner und Interbase will ihn einfach nicht nutzen. <B>Kann ich Interbase nicht sagen, dass er mehr nutzen soll?</B> Die Auslagerungen auf der Festplatte sind bei unserem Server sowieso überflüssig.

BTW. Sollte der Database Sweep Interval überhaupt eingeschaltet sein? Und wenn ja, welcher Wert empfielt sich bei vielen Inserts?

Grüße,
Holge

[Andreas Kosch]

Hallo,

&gt;Raid 0 halte ich hinsichtlich der Datensicherheit für nicht geeignet.

für temporäre Dateien bringt RAID5 nichts, aber RAID 0 mit 2 Platten verdoppelt die Lese-Leistung. Im Idealfall stehen zwei getrennte RAID-Plattenarrays zur Verfügung (1 x Daten, 1 x Temp.).

&gt;..und Interbase will ihn einfach nicht nutzen.

Man hat es hier gleich mit 2 Stellen zu tun: <br>
a) DATABASE_CACHE_PAGES, und <br>
b) gfix -buffers<br>
Nur dann, wenn die Datenbank über b) keine eigene Cache-Größe definiert, nutzt der InterBase den Wert von a).

Was passiert, wenn der Puffer für diese Datenbank über <i>GFIX -BUFFERS 5000 TEST.GDB</i> explizit gesetzt wird? Der tatsächliche Pufferwert sollte experimentell ermittelt werden, weil beim InterBase "größer" nicht unbedingt "schneller" bedeutet.

&gt;...Database Sweep Interval ...

Der Sweep kommt erst dann ins Spiel, wenn der Wert für OAT (Oldest Active Transaction) und OIT (Oldest Interesting Transaction) zu weit auseinanderläuft. Der InterBase 6 hat an dieser Stelle sein Verhalten geändert, so dass kein Benutzer mehr Gefahr läuft, in die "Sweep-Falle" zu tappen und entsprechend lange warten zu müssen

[Gesine Kuhlmann]

Hi,

1)
Bei >=3GB RAM, unterstelle ich sogar Windows, dass Plattenzugriffe als Karussellbremser ausfallen. ( Sofern eure DB nicht weit über einem GB liegt. ). Von daher ist der Hinweis von Andreas bzgl. RAID0 etc. zwar 100%ig richtig, kommt in eurem Fall aber wahrscheinlich weniger zum Tragen.

2)
Bei der beschriebenen Problemstellung würde ich zuallererst die 'Komplexität' des Systems untersuchen, D.h. ich würde mir mittels SQL-Monitor anschauen, ob nicht evtl irgendwelche Indizes aufgrund des Versionswechsels nicht mehr zum Tragen kommen. Ein 'Missgeschick' diesbezgl. bremst jedes DB-System auch in der leistungsfähigsten Hardwareumgebung massiv aus.

Gruß
Gesin

[Holger Deubel]

Hallo,

erstmal vielen Dank für Eure Antworten...

Nochmal Hintergrundinfos:<BR>Unsere DB liegt mittlerweile bei über 5 GB. Tagsüber haben wir 30 - 40 User, die damit arbeiten und Daten einhacken - etwa 60.000 bis 70.000 Datensätze pro Tag werden hier inserted/updated. Nachts haben wir 8 Clients, die Daten aus über 200 Fachgeschäften replizieren... Im Monat kommen wir auf etwa 3 Millionen Datensätze, die "bewegt" werden.

Ich denke, ein Hardware-Problem können wir auf alle Fälle ausschließen, das System ist gut und schnell (Normales Backup der DB dauert 30 Minuten).

Es hätte ja nur möglich sein können, dass bestimmte Unterschiede in den Interbase-Versionen bekannt sind und diese einfach zu umgehen... Ich mache schon seit geraumer Zeit so meine Analysen mit der Datenbank, so dass zum Beispiel Abfragen mit der Funktion UPPER nach und nach verschwinden. Man kann von einem Anwender schon so viel Logik verlangen, dass er einen Namen auch mit Groß- Kleinschreibung findet... Trotzdem ist das Gesamtsystem einfach nicht tragbar. Es treten immer wieder Database Page Errors auf - die nicht erklärbar sind. Das schwierige an der Sache ist, dass ich die Datenbank nicht designed habe, sondern auch nur "reingewachsen" bin...

Bleibt mir wohl nichts anderes, als "rumzuprobieren"...

Grüße,
Holge

[Holger Deubel]

noch ein Zusatz:

Mir ist grad aufgefallen, dass sich die Performance sehr verschlechtert, je größer die Differenz zwischen Oldest Active und Next Transaction ist. Leider ändert sich aber nichts an der Differenz, auch wenn ich den Wert für Sweep Interval auf 5000/10000/20000 setze.

Was kann man denn da machen, ausser Datenbank einmal runter- und wieder hochfahren (Bin ich wohl ausversehen auf den Knopf gekommen :-)?

Grüße,
Holge

[Torsten Grundke]

Hallo Holger,

es sieht so aus, als ob die Clients die Transaktionen sehr lange offen lassen (so nach dem Motto Transaktion starten und dann erst einmal Kaffee trinken oder vielleicht sogar in den Urlaub fahren?). Aber mal Spass beiseite, die Client's scheinen nicht optimal für die Client/Server Architektur designed zu sein.

Tschüß

Torste

[Patrick Sack]

Hi,
<br>
<br>wie arbeiten die Clients? Überwiegend mit CommitRetaining oder mit einem harten Commit?
<br>
<br>mfg
<br>P