Firebird und Geschwindigkeit mit SSD

[Dumpfbacke]

Hallo Leute,
ich habe hier http://www.firebirdnews.org/?paged=6 einen Interesanten Beitag gesehen.

Delphi-Quellcode:

# Intel Core i7 930 2.93 @ 4.0 Ghz
# 6GB DDR3 1600 Cas 7
# Mobo Gigabyte x58-UD3R
# Professional 64-bit Windows 7
# Firebird 2.1.3

2. Hard Drives :
a. Western Digital 1TB 64MB Cache Sata III Black
b. Crucial 128GB RealSSD C300

The test consisted in the creation of a database with 1 table :

    CREATE TABLE COR_PRUEBA (
    INTEGER INTEGER NOT NULL,
    CHARACTER CHAR (20),
    CARACTER2 CHAR (10),
    “DOUBLE” DECIMAL (15, 2),
    INTEGER1 INTEGER);
    ALTER TABLE COR_PRUEBA
    PK_COR_PRUEBA ADD CONSTRAINT PRIMARY KEY (INT); 

The test is done with the IBExpert 2009.08.19 and consisted of the insertion of 500,000 records (Insert operations) with random data.
Results:

Disc A (HDD): 1hr 11m 40s 43ms
Disc B (SSD): 3m 42s 224ms

What really stunned me was the Big difference and both tests were performed with exactly the same parameters.
Judge yourself whether it is worth mounting a SSD for storage xD.

Hat dieses schon mal jemand von Euch versucht ?
Wenn ja dann
1.) Sind die SSD wirklich so schnell ?
2.) Genügt es das Database File auf die SSD zu legen oder muß ich dann das Windows + den Firebird auch darauf installien ?

Ich muß hier jede Woche ca. 800 MB Excel Daten mit den Firebird Daten vergleichenund updaten.

Danke Dunpfbacke

[mquadrat]

Firebird habe ich noch nicht getestet, aber bei Forced Writes dürfte das schon schneller sein. Aber mehr als eine Stunde bei 500k Datensätzen?!

[DelphiBandit]

Firebird ist erfahrungsgemäß bei "langsamen" Medien nicht ganz so flott. Liegt aber nicht an der DB-Engine, sondern daran, dass sie nicht schnell genug Daten geliefert bekommt. Sieht man u.a. daran, dass der Prozessor die ganze Zeit vor sich dümpelt und nichts zu tun bekommt, obwohl die Platte rödelt wie Weltmeister.

Wenn Du die regelmässige Arbeit alleine machst und Dein Rechner genügend RAM hat, dann gibt es glaube ich noch eine andere Option. Installiere eine RAM-Disk und pack die Firebird Datenbank dort drauf und sprich sie lokal an. Machen wir hier immer für Datenkonvertierungen und der Proz hat dann richtig Last hinterher zu kommen. Will mal eben schauen, wie mein Freeware-Teil heisst.... Gavotte RamDisk. Windows und Firebird können ruhig irgendwo auf HD installiert sein, Prozess läuft eh als Dienst im Hintergrund.

Forced Writes sollte ausgeschaltet sein, sonst wird dauernd weggeschrieben. Hilfreich auch vorher ein Backup/Restore mit UseAllSpace machen.

Außerdem kann man in der firebird.conf noch einige Sachen "tunen", wie z.B.

Code:

DefaultCachePages = 10240 # Mindestens, mehr bringt meist nicht viel
TempDirectories = R:\Temp 100000000;D:\Temp # 100 MB Temp-Directory auf die RAM-Disk (R:)
MaxUnflushedWrites = 5000
MaxUnflushedWriteTime = 15 # Verzögertes Schreiben einschalten
CPUAffinity = 2 # Vom ersten Kern wegnehmen

[Satty67]

Wird sich ja fast schon alleine durch die unterschiedliche Zugriffszeit von HD und SSD erklären.

Bei einer organisierten Datenbank sind 500.000 Inserts u.U. auch 500.000 Kopfbewegungen.

500.000 x 7 ms = 58 min für die HD
500.000 x 0.1 ms = 1 min für die SSD

Ist zwar nur theoretisch, aber erklärt den Unterschied scheinbar ganz passend.

[IBExpert]

forced writes deaktivieren lass mal lieber, ist zwar bei Firebird nicht ganz so kritisch wie bei Interbase, aber sollte man trotzdem nie machen, sonst landet nachher wieder so eine DB bei mir zur Reparatur, und die Forced writes inactive Fehler sind selten unkritisch, oft eher irreparabel.

SSDs bringen schon einiges an Speed, insbesondere wegen der Zugriffszeit. Wenn du dir mal mit sysinternals processmonitor anschaust, wo Firebird bei ganz normalen Operationen schreibt, dann siehst du, das das immer von vorne nach hinten im Dateioffset hin und her geht. Daher hilft da der Festplatten interne Cache nur wenig weiter.

wenn du das selber testen willst, dann nimm dir zum Beispiel einfach die db1 demodb aus ibexpert (findest du nach der installation unter C:\Program Files (x86)\HK-Software\IBExpertDemoDB) und mach aus dem Script einfach eine DB. Dann einfach mal die Prozedur initall mit parameter 10000 starten, das macht genau auf deiner Hardware mit deinen Einstellungen dann ca. 800000 Operationen, sprich individuelle insert/update/delete/select statements.

Das ist kein künstlicher Benchmark nur auf einer Tabelle, sondern nutzt eine simples Shop Datenmodell, die Prozedur ist ziemlich selbsterklärend.

Wenn du bei dem Script die DB auf unterschiedliche Datenträger legst, dann wirst du die Unterschiede sehen. Gewinner bei mir war eine RAM Disk, danach kam dann die SSD, danach dann eine normale Festplatte. Wenn du aber ausreichend Speicher hast und die cache buffers groß genug sind und du am besten auch noch die 64 Bit Firebird Version nimmst, dann kann auch eine 10GB DB komplett im RAM betrieben werden (http://www.firebirdsql.org/rlsnotesh...gine-cachesize). Das ist aber kein Limit, wenn du 100GB physikalisch hast dann kannst du auch das komplett mit FB25x64 für Firebird benutzen.

Wenn FB dann also im Cache arbeiten kann ist es relativ egal, wie schnell der Datenträger ist, es sei denn, du schreibst extrem oft Transaktionen von unterschiedlichen Clients. Für die von dir angesprochene Auswertung würde ich möglichst nur die Daten von Excel in einem Abwasch in die FB DB pumpen, um dann von dort aus den Vergleich per SP zu machen. SPs können durchaus 1000-5000% schneller sein, als Zugriffe von externen Clients. Wenn deine Exceldaten dann ggf noch in das Firebird external file format übertragen wird (einfaches Textformat mit fester Satzbreite), dann sind auch schnell mal bis zu 100000 Datensätze pro Sekunde in die Datenbank übertragen.

Je nach Anwendung solltest du auf fb25x64 auch noch andere FB Params aus der conf datei anpassen, aber nicht alle bringen Vorteile. Firebird selbst muß nicht auf den schnellen Datenträger, aber FIREBIRD_LCK sollte auch angepasst werden, weil gerade da sehr viel geschrieben wird.

Zusammenfassung: SSD bringt schon vorteile, aber auch nachteile, ich hatte schon 2 Totalausfälle auf SSDs, seit dem empfehl ich die nicht mehr. Firebird schreibt sehr viel und sehr oft, das macht manhce ssd langsamer bis hin zum Stillstand. eine Festplatte WD Raptor o.ä. ist so weit nicht entfernt im Speed und mit ausreichend RAM udn 64 Bit dauerhaft die bessere Lösung, das ist jedenfalls meine Meinung

[Dumpfbacke]

Ich hätte da noch zwei Fragen. Die weiteren wenn dann mit der Zeit kommen :oops:

Zitat:

Zitat von IBExpert (Beitrag 1083761)

Für die von dir angesprochene Auswertung würde ich möglichst nur die Daten von Excel in einem Abwasch in die FB DB pumpen, um dann von dort aus den Vergleich per SP zu machen. SPs können durchaus 1000-5000% schneller sein, als Zugriffe von externen Clients. Wenn deine Exceldaten dann ggf noch in das Firebird external file format übertragen wird (einfaches Textformat mit fester Satzbreite), dann sind auch schnell mal bis zu 100000 Datensätze pro Sekunde in die Datenbank übertragen.

Wie bekomme ich denn die Daten von Excel in einem Abwasch in Firebird ? Ich habe 66 Dateien in Summe ca. 800 MB groß.

Beim Einlesen mittles meines Programmes benutzte schon StoredProcedures. Es sind unterschiedlich Daten. Bei den meisten Daten suchen ich mittels der SP ob der Datensatz schon vorhanden ist (einige Felder müssen hierzu übereinstimmen), wenn ja wir er geupdatet, wenn nein wird er neu eingefügt. Am Ende einer Datei wird geprüft ob noch Datensätze in der DB sind welche nicht neu oder geupdatet sind und die Kriterien von den Geupdateten / Neuen Datensätzue entsprechen diese werden dann gelöscht. Nun wird mit der nächsten Excel Datei weitergemacht bis alle Dateien eingelesen worden sind.

Bei einigen Date muss ich vorher noch Daten aus anderen Tabelle suchen usw. Ob das in einer Sp möglich ist weis ich im Momant nicht. Nur wenn es schon mal mit den anderen Daten schneller geht wäre das schon mal nicht schlecht.

Zitat:

Zitat von IBExpert (Beitrag 1083761)

Je nach Anwendung solltest du auf fb25x64 auch noch andere FB Params aus der conf datei anpassen, aber nicht alle bringen Vorteile. Firebird selbst muß nicht auf den schnellen Datenträger, aber FIREBIRD_LCK sollte auch angepasst werden, weil gerade da sehr viel geschrieben wird.

Wo kann ich FIREBIRD_LCK denn anpassen ?

So das wars mal für erste. Ich hoffe ich darf bei weiteren Fragen dich nochmals Fragen. :stupid:

Danke Tanja

[Hansa]

Zitat:

Zitat von Dumpfbacke (Beitrag 1083867)

Wie bekomme ich denn die Daten von Excel in einem Abwasch in Firebird ?

Hat er doch geschrieben :

Zitat:

Zitat von IBExpert (Beitrag 1083761)

Wenn deine Exceldaten dann ggf noch in das Firebird external file format übertragen wird (einfaches Textformat mit fester Satzbreite), dann sind auch schnell mal bis zu 100000 Datensätze pro Sekunde in die Datenbank übertragen.

Die Excel-Tabellen müssen zuerst in geeignetem Format exportiert werden (eben am besten feste Feldlängen, statt "CSV" zu wörtlich zu nehmen). Das wäre erst mal Excel.

Wie das auf der FB Seite aussieht steht hier :

http://www.firebirdsql.org/index.php...eful&id=netzka

[IBExpert]

bei aktuellen Excel Versionen geht "speichern unter ...., typ formatierter Text Leerzeichen getrennt", das könnte man dann ggf von Firebird als externe Tabelle benutzen.
ggf ist das aber mit Makroprogrammierung auch schnell erledigt, ich mach mit excel nur das was man nicht vermeiden kann ;-) Manchmal schreibt excel dabei nämlich die dateien nicht so wie man die braucht, auch wenn das laut format theoretisch richtig wäre.

Ggf macht es sinn, einfach die Tabelle mittels einer geeigneten Excel Komponente in einem Delphiprogramm verwursten und in ein passendes Format schreiben, das lässt sich ggf besser automatisieren. Würde ich jedefalls bei vielen Dateien und großen Datenmengen so machen. Wenn das relativ wenig Daten sind kannst du auch über ODBC an die Tabelleinhalte ran, das geht unter anderem mit der ibeblock Sprache in IBExpert oder mit Tools-ODBC Viewer. Bei großen Menge ist das über ODBC aber zu lahm.

FIREBIRD_LCK ist einfach eine Umgebungsvariable für deinen Computer, geb einfach in Windows "Start - Suchen" Umgebungsvariable ein, dann unten als neue Systemvariable ergänzen und den Pfad, wo das hin soll, eintragen.

[tsteinmaurer]

Wenn bzgl. Datentransfer etwas Out-Of-The Box nicht geht, dann würde ich zu einem professionellen ETL Tool wie z.B. Pentaho Data Integration (formals Kettle) greifen. Damit kannst du eine Fülle an Datenquellen anzapfen, verwursten (bereinigen, transformieren ...) etc. und dann wieder irgendwo einfügen. Im Falle von Firebird einfach mit dem JDBC-Treiber.

Für so ein ETL-Tool braucht man zwar etwas Einarbeitungszeit, aber wenn man mal den Dreh heraus hat, dann ist so etwas immer sehr hilfreich.

Thomas

[Blup]

Um einen einzelnen Datensatz tatsächlich physisch zu speichern muss die SSD einen komplette Page lesen, die Änderung vornehmen und diese Page wieder speichern. Ich habe die Erfahrung gemacht, das SSD mit "forced writes" beim Schreiben extrem langsamer sind als normale HDD. Sobald man "forced writes" deaktiviert sind SSD wieder schneller.

Wenn das in diesem Beispiel nicht so ist, vermute ich, das der Treiber oder die Firmware der SSD trotz aktivem "forced writes" weiterhin Schreibzugriffe verzögert ausführt.

[borwin]

Zitat:

Wenn du bei dem Script die DB auf unterschiedliche Datenträger legst, dann wirst du die Unterschiede sehen. Gewinner bei mir war eine RAM Disk, danach kam dann die SSD, danach dann eine normale Festplatte. Wenn du aber ausreichend Speicher hast und die cache buffers groß genug sind und du am besten auch noch die 64 Bit Firebird Version nimmst, dann kann auch eine 10GB DB komplett im RAM betrieben werden (http://www.firebirdsql.org/rlsnotesh...gine-cachesize). Das ist aber kein Limit, wenn du 100GB physikalisch hast dann kannst du auch das komplett mit FB25x64 für Firebird benutzen.

Da habe ich doch eine Frage. Wenn die Daten im RAM liegen und es zu einem Stromausfall kommt sind die Daten doch weg?
Ist zwar aus meiner Sicht schnell aber auch ein erhöhtest Risiko.
Oder habe ich da was übersehen?

Gruß BORWIN

[himitsu]

Ja, was im RAM liegt ist dann weg ... genauso natürlich auch eine RAMDisk.

Darum wird ein ordentlicher Server ja auch mit Notstrom versorgt und hatt dann genügend Zeit um den Stromausfall zu überbrücken oder um in Ruhe alles zu sichern (ordentlich Runterfahren oder Ruhezustand).

[IBExpert]

Firebird bietet dir da noch eine ergänzende Alternative, das Shadow.
Du kannst nämlich zum Beispiel eine DB auf einer Ramdisk betreiben und das
zugehörige Shadow auf einer physikalischen Platte.

Der Vorteil ist dabei dass in der DB auf der Ramdisk alle Lese und Schreibvorgänge
stattfinden, auf dem Shadow aber nur die Schreibvorgänge, die dadurch zwar ein
wenig an Performance verlieren. Außerdem musst du beim hochfahren des Servers
erst mal vom Shadow die neue DB in die Ramdisk kopieren, um dann von dort das
Shadow neu zu erzeugen.

Leseintensive Anwendungen können dadurch schon einiges gewinnen, aber wenn die
komplette db eh im Cache ist bringt das keine Vorteile. Daher am besten fb25x64
mit ordentlich RAM und einen schnellen Datenträger, ob schnelle SSD oder lieber
schnelle HDD ist dann Geschmackssache und persönliche Risikoeinschätzung.

Wichtig bei forced writes ist in erster Linie die Schreibreihenfolge, weil nur
dabei immer eine als Datenbank benutzbare konsistente Datei auf dem Datenträger
bleibt. Bei forced writes off schreibt windows selbst in der Reihenfolge wie es das
für sinnvoll hält und das hinterlässt im Fehlerfall durchaus mal Müll auf der Platte.

USV hilft ja auch nur in Ausnahmefällen, beim Bluescreen bleibt der halt noch länger
sichtbar, aber ob der Speicherinhalt es noch auf die Festplatte schafft, hängt von
vielen Faktoren ab.

Ich finde zwar auch das Hardware mittlerweile recht stabil ist, aber im Worst Case
hilft einem das auch nicht weiter.

[borwin]

Zitat:

Zitat von IBExpert (Beitrag 1084016)

Firebird bietet dir da noch eine ergänzende Alternative, das Shadow.
Du kannst nämlich zum Beispiel eine DB auf einer Ramdisk betreiben und das
zugehörige Shadow auf einer physikalischen Platte.

Das ist sicher der beste Weg, wenn man mit RAM Disk arbeitet.
Wenn mann es richtig schnell braucht, DB im Ramdisk und Shadow auf einer SSD-Platte.
Da hat man maximale Geschwindigkeit und optimale Sicherheit. Der etwas Mehraufwand beim Starten des
Servers (Shadow von SSD-Platte in den RAM übertragen) spielt da keine Rolle.



Gruß Borwin

[Hansa]

Zitat:

Zitat von borwin (Beitrag 1084152)

...Da hat man maximale Geschwindigkeit und optimale Sicherheit...

Von wegen Sicherheit. Die Ram-Disk kann man ja direkt den Hasen geben. :shock: Das Shadow auf SSD oder umgekehrt. Noch nie erlebt, dass auf USB-Sticks Daten nicht richtig geschrieben waren ? Dafür gibts ja sogar "Hardware sicher entfernen". Das Shadow dient ja eigentlich dazu, selbst bei defekter Festplatte noch eine Sicherungskopie auf anderer Platte zu haben. Und diese Kopie noch dazu automatisch verwaltet wird und den Zustand der DB zum Zeitpunkt des Crashs spiegelt. Und das bei vielleicht messbarem aber kaum merkbarem Geschwindigkeitsverlust. RAM-Disk und SSD sind in punkto Sicherheit IMHO Wackelkandidaten. Mir wärs jedenfalls viel zu riskant.

Einen kleinen Nachteil hat das Shadow allerdings doch : wenn ich mich nicht irre, dann geht das nur mit einem Rechner, das darf also kein Netzlaufwerk sein. Externe Festplatte mit USB 3.0 dürfte dann wohl das beste sein. Oder ist das vielleicht seit FB 2.5 anders ?

[IBExpert]

Zitat:

Zitat von Hansa (Beitrag 1084204)

Einen kleinen Nachteil hat das Shadow allerdings doch : wenn ich mich nicht irre, dann geht das nur mit einem Rechner, das darf also kein Netzlaufwerk sein. Externe Festplatte mit USB 3.0 dürfte dann wohl das beste sein. Oder ist das vielleicht seit FB 2.5 anders ?

ja, das geht bei aktuellen FB Versionen mit Windows nur auf einer lokalen physikalischen Platte, da aber egal ob an SATA, SCSI, USB o.ä. Über ein Netzwekkabel würde ich das aber auch nicht unbedingt machen (geht bei Linux schon länger, ich meinte auch was zu fb25 oder fb3 gelesen zuhaben, das das dann ggf auch unter windows via netzwerk geht, bin mir da aber nicht sicher).

Mit ist aber e-Sata sympatischer, weil schon länger verfügbar und auch heute schon 08/15 Technik, trotzdem fast genauso schnell wie USB3. Ein E-SATA Leergehäuse kostet keine 30 Euro, ein Controller mit externem Anschluß oder Kabel zum internen auch nicht mehr, 08/15 s-sata platte rein (lieber klein und schnell als groß und lahm) und schon hat man eine recht gute absicherung, auch wenn die eigene DB auf der internen Platte ohne RAM Disk läuft. So kann man auch mal ein Worst case Szenario durchspielen, nämlich zum Beispiel Mainboardausfall auf dem Server.

Wie lange braucht man um unter der gleichen IP wieder eine Kiste am laufen zu haben mit dem letzten Stand der DB?

Das kann bei Backup-Restore und vorher auf band suchen wo was zum restoren hat, ganz schön lange dauern, je nach Datenbankgröße auch mal diverse Stunden. Das wir das bei Kunden auch via Replikation live machen ist eine andere Baustelle, erspart viel Heckmeck bei Mission Critical Anwendungen, die mal nicht eben eine Stunde stehen können.

Replikation ist nicht im Lieferumfang von FB, lässt sich aber mit vergleichsweise wenig Aufwand mit internen Objekten realisieren, wenn das DB Modell den prinzipiell dafür geeignet ist. Das bekommt man aber als OneWay Replikation eigentlich immer hin (Master Slave Replikation). Wenn das DB Modell passt ist aber auch eine Multimaster Replikation im Online/Offline Betrieb realisierbar, haben wir mehrfach für Kunden gemacht. Das eignet sich das nicht nur als Ausfallsicherheit, sondern auch für Skalierbarkeit.

Beim Betrieb einer DB via Netzwerk erhöht sich die Wahrscheinlichkeit von Schreibfehlern erheblich. Wenn die internen Platten nicht reichen, dann würde ich schon eher ein SAN anschliessen und fertig. Da kann im fehlerfall auch gleich ein anderer Server auf das gleich Volume ohne hin und her kopieren. So was kann leider ziemlich teuer sein, bringt aber teilweise irre Performance (setzt ein Kunde in einer süddeutschen Uniklinik mit fb21 ein, lesen und schreiben ging mit je ca. 1GB pro Sekunde, das war schon ein Feeling wie in der RAMdisk, aber im Vergleich dazu wesentlich sicherer, weil weiß ich wie oft intern gespiegelt. Soweit ich gehört hatte, war das wohl aber auch preislich irgendwo im Breich mit 6 Stellen vor dem Komma nicht für jeden geeignet. Das SAN verhält sich intern aber wie eine physikalische Platte, hat daher weder mit DB noch mit Shadow Probleme.

Beim Netzwerk hast du auch schnell mal den Draht voll, weil das Kabel im Gegensatz zu SATA von allen Netzwerkclients gemeinsam benutzt wird, um da auch nur annähernd auf SATA Speed zu kommen (300MB pro sekunde theoretisch, mit schnellen Platten bzw SSD auch problemlos zu 50-75% erreichbar). Das muß schon ein dicker Draht sein, Gigabit reicht da nicht annähernd aus. Daher arbeiten SAN Systeme meistens auch mit eigenen Protokollen und eigener Hardware.

Ich stimme aber Hansa zu, ich würde bei einer SSD als einzigem physikalischen Datenräger für das Shadow der Ramdisk DB auch nicht so wirklich ruhig schlafen, gebranntes Kind scheut das Feuer. Ein Crash kann zwar auch mit einer normalen Festplatte passieren, aber in den letzten 5 Jahren hatte ich bisher nur mit SSD unvorhersehbare Totalausfälle, HDDs haben sich da immer irgendwie zickig gezeigt, seltsame Geräusche von sich gegeben oder waren ruckelig, so das man noch mal eben den Kram zumindest noch ein mal absichern konnte. Auch die SMART Infos sollte man nicht ignorieren.

Auf der SSD jedoch war in beiden Fällen gar nichts mehr, das hat in einem Fall auch der SSD Hersteller untersucht, weil der sich nicht erklären konnte, wie die SMART Daten der SSD aus meinem letzten Test vor dem Crash zustande kamen. Der Hersteller hat auf jeden Fall von deutlicher Überlastung gesprochen, außerhalb der Spezifikation liegende zu hohe Frequenz von Schreibvorgängen. Die SSD war auch eine MLC, evtl. hätte eine SLC das überlebt, aber mit Produktivdaten werde ich das nicht ausprobieren ohne Plan B. Und ohne produktiv entstandene Schreiblast über mehrere Monate bekommt man kein wirklich relevantes Ergebnis, Benchmark hin oder her.

[BUG]

Zitat:

Zitat von Hansa (Beitrag 1084204)

Noch nie erlebt, dass auf USB-Sticks Daten nicht richtig geschrieben waren ? Dafür gibts ja sogar "Hardware sicher entfernen".

Das hat aber eher mit dem Schreibpuffer und Plug'n'Play zu tun ... aber schon eine statische Entladung reicht manchmal, um einen USB-Stick zu entschärfen.
Man weiß nie genau, wie es in der SSD wirklich aussieht und was der Controller so treibt :-D

[Dumpfbacke]

Hallo Leute,
ich muss leider noch mal nachfragen, da ich es einfach nicht hinbekomme.

Ich habe schon geändert:
Einen RamDisk mit 1 GB angelegt Laufwerk R:

Umgebungsvariabele : FIREBIRD_LCK R:\Temp

Dann in der Firbird Conf

TempDirectories = R:\Temp 200000000;D:\Temp
DefaultDbCachePages = 10240
RemoteServicePort = 3051

#CpuAffinityMask = 1 habe ich nicht geändert, da ja die Version 2.5 mit mehr als einem Proz können soll

Firebird läuft als Dienst

C:\Programme\Firebird\Firebird_2_5\bin\fb_inet_ser ver.exe -s DefaultInstance -m

Die DB habe ich auf die RAMDisk gelegt und nun das Ergenis. Auf Festplatte dauert es ca. 33 Minuten und auf der RAM Disk 30 Minuten. Ich dachte so wie Ihr es mir beschrieben habt das hier nun die Kuh fliegt, jedoch 3 Minuten schneller ?
Das ganze geht auch nur so schnell, da keine neuen Daten vorhanden sind wenn dann noch Daten geändert oder neue hinzugefügt werden dauert es locker 3 Stunden.

Ich habe eine Datei mit ca. 5 Milionen Daten aus welche ich 178404 herausfiltere und diese dann mit den Daten in der DB vergleicht und ggf. Update mitteles einer StoredProcedure.

Könnt Ihr mir hier bitte noch mal helfen ?

Daten zu meinem System:
Dell Server, 8GB Hauptspeicher, 2 Intex Xeon 3.20 GHZ Prozessoren. Das Programm lauft in einer Terminalsitzung auf dem selben Server und greift per TCIP zu .

Danke Dumpfbacke

[himitsu]

Wenn/falls der DB-Server so schlau war und die entsprechende Tabelle in der Zwischenzeit in seine Cache (ebenfalls im RAM) geladen hatte, dann treten beim Lesen keine/kaum noch Dateizugriffe auf, was dann also keinen großen Unterschied zwischen SSD und normaler HDD ausmacht. :gruebel:

[Phoenix]

File I/O ist bei Dir nicht der Flaschenhals. Es hilft übrigens nahezu nie, die Datenbank lediglich auf eine schnellere Platte zu legen. Die Datenbanken selber optimieren schon selber so gut, dass die ganzen Indices über die die Abfragen laufen eh schon in Memory gecached liegen. Die Tabellen auf denen viel gearbeitet wird liegen dazu auch meist komplett in Memory. Eben um den potentiellen Flaschenhals File I/O von vorneherein auszuschliessen. Das heisst Du hast etwas wegoptimiert, was die Datenbank schon von sich aus wegoptimiert ;-)

[MarcoWarm]

schon dran gedacht?

teste bitte mal, ob deine Queries auch optimiert laufen. Ein richtiger Index hie und da macht aus ner halben stunde manchmal ne halbe Minute.

Gruß Marco

[DelphiBandit]

Das war eben auch meine erste Idee - wenn das Selektieren der Daten schon so lange dauert, kann auch eine RAM-Disk das nicht immens beschleunigen. Hier zeigt sich der Geschwindigkeitszuwachs eher beim Rückschreiben in die Datenbank.

Was sich im Laufe der Zeit (Bereich viele Monate bis Jahre) auch negativ bemerkbar macht ist die Fragmentierung der Datenbank. Oder selektierst Du Blobs mit? Das ist auch einen mögliche Bremse.

[IBExpert]

ich würde auch einfach mal so behaupten, das es bei 5 Millionen Datensätzen keinen Grund gibt, das irgendeine
Operation 30 Minuten dauert. Stored Procs kann man genauso schlecht programmieren wie alles andere auch.

Hast du dir die Performance Analyse in IBExpert Vollversion oder Trial nach dem Ausführen der Stored Proc mal
angesehen? Der Ansatz, die internen Operationen zu optimieren ist wesentlich erfolgversprechender als an der
Hardware rumzuschrauben.

Eventuell postest du einfach mal die wichtigsten Metadaten, bei Bedarf kannst du auch gerne mal eine leere
DB (backup nur metadaten) an meine email (support at ibexpert punkt com) senden, dann kann man deutlich
mehr Hinweise geben