Firebird 2.5 mehrere Processore smp

edv.cobinet.de

Benutzer
Beiträge
5
Hallo,

wir nutzen Firebird 2.5 Superserver als Datenbank
Unser Datenbankserver han mehrere Processore
Benutzt zurzeit wird nur einer davon, da nur mit einem und dem selben User von vershiedenen Rechnern gleichzeitig zugegriffen wird
Bei einigen SQL-Abfragen ist Processor belegt, und andere Clients müssen warten
Damit ich mehrere Processore nutzen kann, muss ich Superclassic statt Superserver installieren
Das ist mir aber zu heiß, da ich Angst habe, dass bei mehreren Usern Superclassic die Datenbank nicht richtig synchronisiert
Jetzt die Frage:
Wenn ich einen zweiten User für Firebird Datenbank erstelle und dem nur Leserechte auf die Datenbank gebe? Wird die Datenbank trotzdem nach jedem Zugriff von beiden Nutzern synchronisiert? Oder passieren Synchronisierungen nur nach Schreibzugriffen? Und wenn nur ein User schreibt, gibt es keine Synchronisierungen mehr?

Ich hoffe, habe mich verständlich ausgedruckt

Danke für die Antwort
 
Werbung:
Benutzt zurzeit wird nur einer davon, da nur mit einem und dem selben User von vershiedenen Rechnern gleichzeitig zugegriffen wird

What? Startet da nich je Connection ein Prozess, der dann eine andere CPU anheizt?

Bei einigen SQL-Abfragen ist Processor belegt, und andere Clients müssen warten
Damit ich mehrere Processore nutzen kann, muss ich Superclassic statt Superserver installieren
Das ist mir aber zu heiß, da ich Angst habe, dass bei mehreren Usern Superclassic die Datenbank nicht richtig synchronisiert

Nochmals: ist das echt so? Dachte, nur Oracle bevormundet seine zahlenden Kunden derart. Schon mal über bessere Alternativen nachgedacht?
 
What? Startet da nich je Connection ein Prozess, der dann eine andere CPU anheizt?

Wenn ich die Dokumentation vom Firebird richtig lese, wird CPU nicht pro Connection, sondern pro Datenbank-User verteilt

Nochmals: ist das echt so? Dachte, nur Oracle bevormundet seine zahlenden Kunden derart. Schon mal über bessere Alternativen nachgedacht?

Ich habe nicht kapiert, worauf sich "ist das echt so?" bezieht. Bessere Alternative sind schwierig, da die Datenbank schon sehr gross und komplex ist, und Umstellung viel Zeit und Nerven kostet
 
Das 'ist das so' bezog sich auf eine CPU/User. Das ist ja konzeptionell Mega-FAIL.

Tja, wenn Migration nicht vorstellbar ist dann halt eben nicht. Dann bleibt nur, den derzeitigen Zustand zu zementieren.
 
Nicht unbedingt

Man könnte mit Superclassic das Problem lösen
Ich könnte von veschiedenen Clients mit verschiedenen Nutzern zugreifen
Performanzproblem wäre damit gelöst
Allerdings habe ich dann möglicherweise ein grösseres Problem: Datenbankintegritätsverletzung
Ich traue allen Datenbanksynchronisierungen nicht seit MS Access

Deswegen könnte man vielleicht eine Zwischenlösung integrieren
Schreiben nur mit einem User und lesen mit mehreren
Da wären beide Probleme gelöst - sowohl Performanz würde steigen als auch Datenbank bliebe heil

Allerdings ich weiß nicht, ob Datenbanksynchronisierung bei mehreren Usern auch nicht bei Lesezugriffen passiert

Wie sieht es eigentlich bei den anderen Datenbänken aus? Wie Oracle oder SQL Server?
Die haben doch das selbe Problem
Können die das sauber synchronisieren?
Oder müssen die Datenbankadministratore jeden Monat die Datenbank reparieren bzw. aus dem Backup wiederherstellen?
 
Allerdings ich weiß nicht, ob Datenbanksynchronisierung bei mehreren Usern auch nicht bei Lesezugriffen passiert

Wie sieht es eigentlich bei den anderen Datenbänken aus? Wie Oracle oder SQL Server?
Die haben doch das selbe Problem

Quatsch. PostgreSQL und ganz sicher auch Ora und M$SQL können das out-of-the-Box. PostgreSQL wäre dazu frei.
 
Wenn ich richtig verstanden habe, alle Datenbänke funktionieren mit mehreren Processoren auf folgende Weise:
jeder Processor bekommt eine Kope von der Datenbank, und am Ende werden verschiedene Kopien synchronisiert
Das erinnert mich an MS Access. Der zog auch auf jeden Client lokale Kopie der Datenbank. Nachdem man Access auf dem Client zumachte, wurde seine Kopie mit der hauptbank synchronisiert. Damals gab es viele Probleme
Ok. Datenbankserver laden die Kopien nicht auf lokale Clients, aber die verteilen diese Kopien auf Processore. Und obwohl der Augenblick, wo Kopien sich von der Hauptdatenbank unterscheiden, wesentlich kleiner sind (eine Transaktion), und deswegen wahrscheintlich viel weniger Probleme entstehen, Prinzip ist der selbe. Und Gefahr, dass nach einer Synchronisierung Datenbank nicht mehr zu verwenden ist, ist meiner Meinung da
Unsere jetzige Datenbank läft im echten Betrieb seit 2003 ohne einen einzigen Ausfall, und ich möchte, dass es so bleibt. Perfomanz steht für mich nur an der zweiten Stelle
 
Vereinfacht gesagt: Es gibt einen Haupt-Serverprozess. Bei jeder Anfrage (Client verbindet sich zum Server) wird ein neuer Prozess gestartet. Dieser 'kümmert' sich um 'seine' Anfrage. Sollten 2 oder mehr Prozesse z.B. auf dieselbe Zeile einer DB zugreifen und ändern, so ist das für jeden in 'seiner' Transaktion. MVCC - Multi Version Concurrency Control. Dazu hat (Beispiel PostgreSQL) jeder Datensatz 2 extra und sonst unsichtbare Spalten: xmin und xmax (und weitere, hier irrelevant). das steht für die minimale und maximale Transaktionsnummer, in der der Datensatz sichtbar ist.

Im Grunde genommen kann Dir das aber alles egal sein: es funktioniert halt einfach. Zumindest in PostgreSQL. Und wenn Dir absolute Robustheit und Datenintegrität wichtig sind (so hab ich Dich verstanden), dann ist PostgreSQL exakt das richtige für Dich.
 
Werbung:
Zurück
Oben