Announcement

Collapse
No announcement yet.

Umstieg 2.5. auf 3.0

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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.

    Comment


    • #3
      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?

      Comment


      • #4
        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.

        Comment


        • #5
          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?

          Comment


          • #6
            Originally posted by iki View Post
            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

            Comment


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

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by iki View Post
                  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

                  Comment


                  • #10
                    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?

                    Comment


                    • #11
                      Bei 3 bist du schon richtig. Wenn es nur um die Performance dieses einen Dings geht wäre eine Upgrade von 2.5 auf 3, wenn das Aufwand bedeutet, aber im Moment dann auch nicht so relevant das ich das persönlich machen würde. Performanceoptimierung, wie wir hier gerade besprechen, macht man eher anders bzw. an anderer Stelle.

                      Ich vermute mal wegen der Inkompatibilität zwischen 2.5 und 3 sowie der damit einhergehenden Problematik das ein Upgrade eben nicht nur ein simples Ausführen eines Setup ist, das man der 2.5er Version zumindest noch Bugfixes und Security Updates zukommen lässt und das auch weiterhin für eine mir jetzt gerade nicht bekannte Zeit.

                      Comment


                      • #12
                        Also ich habe die Datenbank mit gbak -b mit Firebird 2.5 gesichert und mit Firebird 3.0 gbak -c zurück gesichert.
                        Meine Anwendungssoftware Software läuft und ich kann auf die Daten zugreifen. Allerdings wird die gds32.dll benötigt.
                        Ist das normal oder verwendet die Anwendungssoftware einen alten Treiber?

                        Comment


                        • #13
                          Möglicherweise. Aber letztlich weis ich nicht was deine Anwendung da tut Ich vermute mal das die Anwendung nicht speziell für Firebird ausgelegt ist sondern sich auch mit Interbase verträgt und da heißt die entsprechende Biliothek gds32.
                          Was du probieren kannst. Schau mal in deinen Firebird Installationsordner dort solltest du eine fbclient.dll findest. Kopier dir die, belasse die Kopie in diesem Ordner neben der fbclient.dll aber nenne die Kopie gds32.dll.

                          Comment


                          • #14
                            Ok, das geht auch.
                            Was bedeutet das nun, wenn ich mit der original gds32.dll arbeite oder mit der umbenannten fbclient.dll?

                            Comment


                            • #15
                              Kommt drauf an wo. Auf dem Server würde die alte dll nicht funktionieren da mußt du schon die zur Datenbank (besser dem Datenbankfile) passende Bibliothek nehmen. Ich gehe also mal davon aus du die irgendwie auf dem Client brauchst.
                              Da habe ich jetzt keine direkte Erfahrung warum man die da braucht und kann nur spekulieren das in der Bibliothek auch eine Art Interface Definition steckt oder ein Layer der das sprechen mit der serverseitigen API erleichtert und das von deinen Zugriffskomponenten benutzt wird.
                              Dann würde ich davon ausgehen das es egal ist welche man nimmt mit leichter Tendenz zur alten Version der dll weil das die ist gegen den deine Zugriffskomponente vom Hersteller mal ursprünglich programmiert wurde.

                              Comment

                              Working...
                              X