wenn du es schaffst, das dein server (z.B. weil firebird.exe als applikation läuft und nicht als service)
auf das netzwerklaufwerk zugreifen kann, was in dem fall gehen würde, dann wäre damit der erste
Teil des Problems gelöst. Alternativ ginge auch irgend protokoll was physikalische netzwerklaufwerke
als lokale erscheinen lässt (iSCSI zB)
Mit dem Einrichten des Shadows gibt es noch parameter AUTO/CONDITIONAL/MANUAL die ganz unterschiedlich reagieren
falls das shadow nicht erreichbar ist, der default (oder AUTO) hängt das shadow einfach ab wenn es nicht mehr erreichbar
ist, vorteil, die
db kann weiter benutzt werden, nachteil, die
db wird weiter benutzt ohne shadow
bei MANUAL ist die
db nicht mehr benutzbar wenn das shadow nicht erreichbar ist, beim Betrieb über das Netzwerk
gibt es da viele gründe warum das so sein könnte.
Und ganz wichtig: mit aktivem Shadow wird beim commit alles was an pages geschrieben werden muss in die
db und
auch in alle shadows geschrieben.
Solltest du nun zB einen sehr schnellen nvme ssd based server mit 2gb read/write pro sekunde und 200000 iops
über ein netzwerk deiner wahl an einen gleich schnellen als shadow partner anbinden, dann wirst du sehen,
wie lahmarschig netzwerke im vergleich zu
ram/mainboard/cpu/pci/nvme
da ist es auch völlig egal ob du 1gbit oder 10gbit leitung hast, die latenz für den schreibvorgang
ist dabei das problem (die leben bei der performance davon, das man große pakete über den draht
schickt und nicht wie bei
fb eher sehr viele sehr kleine pakete).
wenn die bei ausführen eines sqls in ibexpert zB die performance analyse anzeigt das der schreibvorgang
zB 100000 reads und 10000 writes ausgelöst hat, dann kannst du davon ausgehen, das die 100000 reads nicht
das problem sind, weil lesende pages werden immer aus der lokalen
db geholt und nicht aus dem shadow,
die 10000 writes brauchen aber nu nicht nur einfach per dma o.ä. vom
ram via mainboard chipsatz in die
ssd kopiert werden, sondern wandern zusätzlich durch den ganzen
OS Overhead
tcp/
ip socket, werden dann
durch ein kabel in anderen strom/spannung verwandelt und dabei serialisiert (so viel drähte hat dein
netzwerk ja nicht wie pins am
ram modul sind), dann kommt je nach kabellänge noch einstein ins spiel
mit lichtgeschwindigkeit eiert aber evtl noch mal durch einen router oder switch
und auf der gegenseite macht dann wieder ein
OS und der treiber aus dem Strom wieder daten,
überlegt sich, welcher Prozess dafür gerade zuständig ist, der Prozess selber überlegt sich, ob
er gerade zeit und lust zum schreiben hat, übergibt das wieder aus dem
ram and das mainboard, von da an
die lokale ssd usw. usw.
ich weiss, ich schweife ab, aber als Zusammenfassung
Wenn du eine sehr geringe Schreiblast auf einer kleineren
DB hast, dann könntest du ein Shadow im Netz
mit MANUAL auf einem möglichst schnellen server in einem eigene netzwerksegment mal antesten ,
es wird aber garantiert auch dann alles deutlich langsamer was schreibvorgänge sind bis hin zur blockade
wenn der shadow rechner gerade kein bock hat, warum auch immer. Im Auto Modus wird das shadow schneller
abgehängt sein als du denkst und dann ist das ganz gefährliche pseudo sicherheit, weil es sein kann,
das dir das shadow zwar bis zu den datapages alles sauer geschrieben wurde, die transaktioninventory
page dann aber nicht mehr. Mit MANUAL passiert das nicht, weil du ab dem Fehlerhaften Schreibvorgang
eh nicht wieter arbeiten kannst und damit der Schreibvorgang da auch nicht abgeschlossen ist.
Und mehr infos als die Systemtabelle rdb$files hast du nicht um auf fehlersuche zu gehen
Eine Replikation (was wir ja nun schon seit jahren machen und da nur per
sql zwischen
den datenbanken sachen repliziert) wird so wie wir das machen niemals irgendwelche
pages halb übertragen.
bei fb4 wird es ja eine replikation geben, was ich davon halten soll ewiss ich noch nicht, weil das
was wir brauchen und praktisch einsetzen weit über das hinaus geht, was auch nur für fb5 geplant ist,
das mag aber für deinen anwendungsfall anders sein.
Ein replikationsersatz ist ein shadow aber garantiert nicht