Willkommen bei Entwickler-Forum.
Seite 1 von 2 1 2 LetzteLetzte
Ergebnis 1 bis 10 von 15
  1. #1
    Aufsteiger
    Registriert seit
    09.04.2011
    Beiträge
    56

    Standard Umstieg 2.5. auf 3.0

    Hallo Zusammen,

    wir möchten von Firebird 2.5 auf 3.0 umstellen.
    Gibt es eine deutsche Anleitung?

    Vielen Dank
    Iki

  2. #2
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.857

    Standard

    Wäre mir nicht bekannt.

    Letztlich läuft es darauf hinaus in 2.5 ein Backup zu machen und in 3.0 wiederherzustellen (zum Beispiel mit gbak, Backup mit der 2.5er Version Restore mit der 3er Version von gbak) da die Fileformate zueinander inkompatibel sind.
    Für die Client Seite sollte es in den meisten Fällen egal sein was auf dem Server genau passiert außer man benutzt sehr merkwürdige Zugriffskomponenten.

    Wenn du spezielle Fragen hast die du dir nicht aus der englischen Doku beantworten kannst versuch es hier. Ich habe es zumindest schonmal selbst mit der Embedded Version gemacht. Solltest du keine speziellen Serverfragen haben oder Zugriffskomponentenspezifische Fragen ist die Wahrscheinlichkeit hoch das ich weiterhelfen kann.

  3. #3
    Aufsteiger
    Registriert seit
    09.04.2011
    Beiträge
    56

    Standard

    Hallo,
    Ok ich habe das gemacht, die Datenbank läuft.
    Ich habe mit allen drei Installationsarten versucht, aber Firebird benutzt immer nur ein Prozessor Kern, die Kerne werden
    zwar durchgewechselt, aber bei einer längeren Aufgabe wird dennoch nur ein Kern verwendet. Liegt das an Firebird, kann
    das nicht mehr auf einmal?

  4. #4
    Stammgast
    Registriert seit
    26.02.2003
    Beiträge
    4.857

    Standard

    Für Firebird gilt das du je Connection einen Thread (oder Prozess je nach Firebird Architektur die du da gerade installiert hast) bekommst. Eine Aufgabe benutzt also näherungsweise nur einen Thread. Viel Aufgaben können aber natürlich parallel laufen.

    Das ist auch eigentlich das übliche Verhalten der meisten Datenbanksystemen. Das Aufteilen einer Aufgabe in viele Threads wäre nur ein Vorteil für ein Single User System wo dieser eine User die verfügbaren Ressourcen möglichst komplett ausnutzen will. In einer Multiuserumgebung mit vielen Aufgaben in parallelen Threads ist es fast immer kontraproduktiv die einzelnen Aufgaben auch noch in mehrere Threads aufzuteilen. Die Systeme die das können (Sql Server, Oracle etc.) fallen üblicherweise auch sehr schnell auf das "Ein Thread pro Aufgabe" Schema zurück sobald die Last steigt. Beim SQL Server habe ich das Verhalten wenn ich mal Ausführungspläne auswerte nur gesehen auf meinen Testsystemen die ich alleine verwende die selbe Anwendung im realen Multiuser Einsatz macht das dann nicht mehr.

  5. #5
    Aufsteiger
    Registriert seit
    09.04.2011
    Beiträge
    56

    Standard

    Ok, Vielen Dank.
    Heist das dann, wenn eine Auswertung "zu lange" dauert braucht man einen schnelleren Prozessor (wir haben 2,67 GHz) oder eine bessere Programmierung
    der Software die darauf zugreift?

  6. #6
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.341

    Standard

    Zitat Zitat von iki Beitrag anzeigen
    Ok, Vielen Dank.
    Heist das dann, wenn eine Auswertung "zu lange" dauert braucht man einen schnelleren Prozessor (wir haben 2,67 GHz) oder eine bessere Programmierung der Software die darauf zugreift?
    Ja, so sieht es aus.

    SQL Tuning ist der erste Ansatz. Hardware, also idR Festplatte(n) und CPU ebenfalls.
    Bei nicht optimalem Code kann man häufig Faktoren an Performancegewinn erreichen, durch bessere Algorithmen, Indizierung, Abfrageoptimierung. Bei Hardware sind es die Prozent, die die Hardware eben schneller ist.
    Gruß, defo

  7. #7
    Forenheld
    Registriert seit
    26.02.2003
    Beiträge
    7.043

    Standard

    Wie groß ist die Datenbank? Bei sehr großen Datenbanken ist auch ein mehr an RAM sehr hilfreich. Oder statt Festplatten SSD.

  8. #8
    Aufsteiger
    Registriert seit
    09.04.2011
    Beiträge
    56

    Standard

    Die Datenbank ist 1,5 GB und liegt auf einer SSD. Die Installation von Firebird ist als Superserver und keine weiteren Veränderung als
    von der Installation vorgeschlagen. Die firebird.conf Datei ist original.

  9. #9
    Stammgast
    Registriert seit
    24.10.2011
    Beiträge
    1.341

    Standard

    Zitat Zitat von iki Beitrag anzeigen
    Die Datenbank ist 1,5 GB und liegt auf einer SSD.
    Das ist nicht so viel, vermutlich würde sie komplett ins RAM des Rechners passen (Und trotzdem nicht viel schneller werden)?
    Da ist wahrscheinlich SQL / Code Tuning angesagt.

    "Reports", die zu langsam sind, sind auch was anderes als "der laufende Betrieb". Reports aggregieren, vergleichen, ..
    . Das kann beliebig schief laufen. Vlt. fehlen nur ein paar Indices, ..
    Worauf basieren die Reports? Welche Ausgabeform? Ein Generator, Hand gestrickt, Grafik, Papier, Webseiten .. ?
    Gruß, defo

  10. #10
    Aufsteiger
    Registriert seit
    09.04.2011
    Beiträge
    56

    Standard

    Welche version wird eigentlich weiter entwickelt 2.5 oder 3.0.
    Auf der Webseite gibt es ein Update auf 2.5.8 vom 2.5.18
    von 3.0 gibt es das letzte Update vom 22.3.17
    Wann sollte man welche Version verwenden? Welche ist denn die bessere?

 

 
Seite 1 von 2 1 2 LetzteLetzte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •