5
Access-Datenbanken auf replizierten DFS-Ordnern
Hallo liebe Administrator.de-Gemeinde !
Ich versuche mein Problem so kompakt wie möglich darzustellen und unnötige Infos zu vermeiden. Falls doch noch Fragen zur Lösung des Problems offen sein sollten, gebt bitte kurz bescheid, dann reiche ich die Antworten kurzfristig nach...
Ich muss eine Domäne für die Verwendung an 2 Standorten einrichten. Es soll an beiden Standorten der Zugriff auf die selben Dokumente und Anwendungsdaten gewährleistet werden. Dafür wird weitestgehend DFS-Replizierung eingesetzt.
Es werden jedoch mehrere Anwendungen eingesetzt, die ihre Daten in Access-Datenbanken speichern. Das Problem, dass sich für mich darstellt ist nun, dass wenn ich die DFS-Replizierung für die entsprechenden Ordner nicht verwende, dass der Zugriff auf die Anwendungen am jeweils entfernten Standort sehr langsam ist (der Uplink an beiden Standorten liegt bei ca. 512 kBit/s). Allerdings ist es mir nicht ganz geheuer, die mdbs replizieren zu lassen. Das würde bei einem gleichzeitigen, schreibenden Zugriff ja später unvermeidlich zu einem Replizierkonflikt und damit zu Datenverlust für den, der zuerst gespeichert hat, führen.
Leider lassen die fraglichen Anwendungen keine Migration auf andere Datenbankformate wie z.B. MSSQL zu. Gibt es (abgesehen von einer Erhöhung des Uplinks) eine gängige Lösung, um einen sicheren und schnelleren Zugriff auf die mdbs an beiden Standorten zu gewährleisten ?
Ich danke schon mal für eure Aufmerksamkeit und Mühe !
Gruß,
Eicky
Ich versuche mein Problem so kompakt wie möglich darzustellen und unnötige Infos zu vermeiden. Falls doch noch Fragen zur Lösung des Problems offen sein sollten, gebt bitte kurz bescheid, dann reiche ich die Antworten kurzfristig nach...
Ich muss eine Domäne für die Verwendung an 2 Standorten einrichten. Es soll an beiden Standorten der Zugriff auf die selben Dokumente und Anwendungsdaten gewährleistet werden. Dafür wird weitestgehend DFS-Replizierung eingesetzt.
Es werden jedoch mehrere Anwendungen eingesetzt, die ihre Daten in Access-Datenbanken speichern. Das Problem, dass sich für mich darstellt ist nun, dass wenn ich die DFS-Replizierung für die entsprechenden Ordner nicht verwende, dass der Zugriff auf die Anwendungen am jeweils entfernten Standort sehr langsam ist (der Uplink an beiden Standorten liegt bei ca. 512 kBit/s). Allerdings ist es mir nicht ganz geheuer, die mdbs replizieren zu lassen. Das würde bei einem gleichzeitigen, schreibenden Zugriff ja später unvermeidlich zu einem Replizierkonflikt und damit zu Datenverlust für den, der zuerst gespeichert hat, führen.
Leider lassen die fraglichen Anwendungen keine Migration auf andere Datenbankformate wie z.B. MSSQL zu. Gibt es (abgesehen von einer Erhöhung des Uplinks) eine gängige Lösung, um einen sicheren und schnelleren Zugriff auf die mdbs an beiden Standorten zu gewährleisten ?
Ich danke schon mal für eure Aufmerksamkeit und Mühe !
Gruß,
Eicky
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 74394
Url: https://administrator.de/contentid/74394
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo Eicky,
Das Problem mit den konkurierenden änderungen bei der Replikation hast du richtig erkannt. Es wird auf jeden fall Probleme geben. Die einzige Chance besteht in einer Art Lockmechanismus auf DB-Ebene. Zb. wenn ein User an Standort A die DB öffnet erstellt diese eine lockdatei. Diese darf nicht offen gehalten werden und muss schnellstmöglich repliziert werden (zb. in einer extra Replikationsgruppe mit möglichst wenigen Files) ODER du legst die Datei für alle zugreifbar an einer Zentralen stelle im VPN ab (1k sind schnell geschrieben). Wenn ein User die DB wieder schließt, wird das lock entfernt und die DB ist beschreibbar. Oder du schreibst einen Timecode in das lock und solange ein Feld in der DB nicht gleich dem Wert in der lockfile ist kann keiner in die DB schreiben (wenn sie repliziert wurde, ist Timestamp im lockfile gleich timestamp in der DB). Das ist nicht schön und es besteht das Risiko wenn zu viele an einem Standort in der DB werkeln kein anderer Standort zugreifen kann. Als Alternative sehe ich nur Terminaldienste.
Das Problem mit den konkurierenden änderungen bei der Replikation hast du richtig erkannt. Es wird auf jeden fall Probleme geben. Die einzige Chance besteht in einer Art Lockmechanismus auf DB-Ebene. Zb. wenn ein User an Standort A die DB öffnet erstellt diese eine lockdatei. Diese darf nicht offen gehalten werden und muss schnellstmöglich repliziert werden (zb. in einer extra Replikationsgruppe mit möglichst wenigen Files) ODER du legst die Datei für alle zugreifbar an einer Zentralen stelle im VPN ab (1k sind schnell geschrieben). Wenn ein User die DB wieder schließt, wird das lock entfernt und die DB ist beschreibbar. Oder du schreibst einen Timecode in das lock und solange ein Feld in der DB nicht gleich dem Wert in der lockfile ist kann keiner in die DB schreiben (wenn sie repliziert wurde, ist Timestamp im lockfile gleich timestamp in der DB). Das ist nicht schön und es besteht das Risiko wenn zu viele an einem Standort in der DB werkeln kein anderer Standort zugreifen kann. Als Alternative sehe ich nur Terminaldienste.
Hi Datasearch,
danke schon mal für die Optionen, die Du mir aufgezeigt hast.
An die Lösung mit dem Terminalserver habe ich noch nicht gedacht. Das scheint mir wirklich fast schon eine ultimative Lösung für solche Probleme. Leider fällt die Lösung aus folgenden Gründen unter den Tisch:
- Die benötigten CALs sind leider nicht ganz günstig. Da wäre eine Erhöhung des Uploads schon fast die "wirtschaftlichere" Lösung.
- Die Server sind für ihre jetzigen Aufgaben (DC, Fileserver, Sharepoint Services, WSUS, MSSQL 2005 Express (für einige, wenige Anwendungdatenbanken), Symantec AntiVirus Server) von der Performanz her "gerade passend". Ich befürchte da starke Leistungseinbußen bei Verwendung eines Terminalservers...).
- Der Nutzerkreis ist einfach viel zu klein. Konkret geht es hier um eine Schule mit 2 Standorten. Da arbeiten regelmäßig die beiden Schulleiter und die Sekretärin (an eigenen PCs) sowie die beiden Lehrerzimmer an jeweils einem PC. Die Schulleiter und die Sekretärin arbeiten wechselnd an beiden Standorten und das nicht immer zusammen an einem. Daher meine Sorgen...
Was die Lockfiles angeht: Werden bei der Benutzung von Access-Datenbanken nicht ldb-Dateien angelegt, die in etwa das tun, was du beschrieben hast? Der Dokumentation bei Microsoft zufolge werden hier die Datensätze, die gerade in Benutzung sind, für weitere Zugriffe gesperrt.
Ich muss gestehen, dass ich noch nicht ausprobiert habe, ob das reicht. Ich befürchte nur irgendwie, dass es auf Grund der Replikationsverzögerung vielleicht doch irgendwann "knallen" könnte...
Hat jemand vielleicht schon Praxisbeispiele oder Erfahrungen zu dem Thema ldb-Dateien auf DFS-Pfaden ?
Herzlichen Dank schon mal !
Gruß, Eicky
danke schon mal für die Optionen, die Du mir aufgezeigt hast.
An die Lösung mit dem Terminalserver habe ich noch nicht gedacht. Das scheint mir wirklich fast schon eine ultimative Lösung für solche Probleme. Leider fällt die Lösung aus folgenden Gründen unter den Tisch:
- Die benötigten CALs sind leider nicht ganz günstig. Da wäre eine Erhöhung des Uploads schon fast die "wirtschaftlichere" Lösung.
- Die Server sind für ihre jetzigen Aufgaben (DC, Fileserver, Sharepoint Services, WSUS, MSSQL 2005 Express (für einige, wenige Anwendungdatenbanken), Symantec AntiVirus Server) von der Performanz her "gerade passend". Ich befürchte da starke Leistungseinbußen bei Verwendung eines Terminalservers...).
- Der Nutzerkreis ist einfach viel zu klein. Konkret geht es hier um eine Schule mit 2 Standorten. Da arbeiten regelmäßig die beiden Schulleiter und die Sekretärin (an eigenen PCs) sowie die beiden Lehrerzimmer an jeweils einem PC. Die Schulleiter und die Sekretärin arbeiten wechselnd an beiden Standorten und das nicht immer zusammen an einem. Daher meine Sorgen...
Was die Lockfiles angeht: Werden bei der Benutzung von Access-Datenbanken nicht ldb-Dateien angelegt, die in etwa das tun, was du beschrieben hast? Der Dokumentation bei Microsoft zufolge werden hier die Datensätze, die gerade in Benutzung sind, für weitere Zugriffe gesperrt.
Ich muss gestehen, dass ich noch nicht ausprobiert habe, ob das reicht. Ich befürchte nur irgendwie, dass es auf Grund der Replikationsverzögerung vielleicht doch irgendwann "knallen" könnte...
Hat jemand vielleicht schon Praxisbeispiele oder Erfahrungen zu dem Thema ldb-Dateien auf DFS-Pfaden ?
Herzlichen Dank schon mal !
Gruß, Eicky
Ja, die LDB macht genau das. Ich habe nur die Befürchtung das die Replikation nicht schnell genug erfolgt. Mit einer zentral abgelegten lockfile sollte das Problem vom Tisch sein. Allerdings weiß ich nicht wie so etwas geht, Anwendungssoftware und DB-Programmierung sind leider nicht mein Themengebiet. Ich weiß aber das ein bekannter so etwas ähnliches in seiner Umgebung gebaut hat.
Hi nochmal,
by the way: Ich hab grad noch mal selbsttätig Recherchen angestellt und musste lesen, dass ldb-Dateien wohl unter die Ausnahmen der DFS-Replizierung fallen (wie z.B. bak-Dateien auch...) und somit nicht repliziert werden.
Das Thema Replizierung von Access-Datenbanken ist damit wohl gestorben.
Bleibt immer noch das Problem der Geschwindigkeit
Da z.B. die Access-DB des aktuellen Schulverwaltungsprogramms ca. 6 MB umfasst, wird bei einem Upload von 512 KBit/s eine Erstladezeit von mindestens 1,5 Minuten erreicht. Das ist natürlich untragbar...
Die künftige Anwendung konnte ich zum Glück auf SQL Server 2005 Express umstellen, sodass der Netzwerkverkehr vom 2. zum 1. Standort relativ gering sein sollte. Aber Access-DBs werden bekanntlich immer als komplette Kopie auf den eigenen Rechner gezogen...
@datasearch: Wenn Du vielleicht nochmal in Erfahrung bringen könntest, wie dein Bekannter das Problem gelöst hat, wäre ich Dir sehr dankbar.
Falls sonst noch Ideen aufkommen sollten, wäre ich natürlich ebenfalls sehr zu Dank verpflichtet
Gruß, Eicky
by the way: Ich hab grad noch mal selbsttätig Recherchen angestellt und musste lesen, dass ldb-Dateien wohl unter die Ausnahmen der DFS-Replizierung fallen (wie z.B. bak-Dateien auch...) und somit nicht repliziert werden.
Das Thema Replizierung von Access-Datenbanken ist damit wohl gestorben.
Bleibt immer noch das Problem der Geschwindigkeit
Da z.B. die Access-DB des aktuellen Schulverwaltungsprogramms ca. 6 MB umfasst, wird bei einem Upload von 512 KBit/s eine Erstladezeit von mindestens 1,5 Minuten erreicht. Das ist natürlich untragbar...
Die künftige Anwendung konnte ich zum Glück auf SQL Server 2005 Express umstellen, sodass der Netzwerkverkehr vom 2. zum 1. Standort relativ gering sein sollte. Aber Access-DBs werden bekanntlich immer als komplette Kopie auf den eigenen Rechner gezogen...
@datasearch: Wenn Du vielleicht nochmal in Erfahrung bringen könntest, wie dein Bekannter das Problem gelöst hat, wäre ich Dir sehr dankbar.
Falls sonst noch Ideen aufkommen sollten, wäre ich natürlich ebenfalls sehr zu Dank verpflichtet
Gruß, Eicky
Ui, da seh' ich grad, dass dieser Topic noch offen ist...
Habe das Problem inzwischen mit einem kleinen VB-Script gelöst:
Statt direkt auf die ausführbare Datei der betroffenen Anwendungen zu verlinken, starten die Benutzer jetzt ein Script, was im Prinzip nur 2 Sachen abfragt:
Ist die MDB am entfernten Standort erreichbar ? Falls nein, wird das Script mit einer Fehlermeldung abgebrochen (entfernter Standort nicht erreichbar).
Existiert eine zu der entfernten MDB passende LDB (gleicher Dateiname mit der Endung .ldb)? Falls ja, wird wird das Script mit einer Fehlermeldung abgebrochen (Anwendung wird bereits am entfernten Standort ausgeführt).
Wenn das Script bisher noch nicht verlassen wurde, wird das Programm gestartet.
Zwar sind die Anwendungen so nur an einem Standort ausführbar, das war allerdings leichter zu verschmerzen als das Risiko des Datenverlustes.
Viele Grüße,
Eicky
Habe das Problem inzwischen mit einem kleinen VB-Script gelöst:
Statt direkt auf die ausführbare Datei der betroffenen Anwendungen zu verlinken, starten die Benutzer jetzt ein Script, was im Prinzip nur 2 Sachen abfragt:
Ist die MDB am entfernten Standort erreichbar ? Falls nein, wird das Script mit einer Fehlermeldung abgebrochen (entfernter Standort nicht erreichbar).
Existiert eine zu der entfernten MDB passende LDB (gleicher Dateiname mit der Endung .ldb)? Falls ja, wird wird das Script mit einer Fehlermeldung abgebrochen (Anwendung wird bereits am entfernten Standort ausgeführt).
Wenn das Script bisher noch nicht verlassen wurde, wird das Programm gestartet.
Zwar sind die Anwendungen so nur an einem Standort ausführbar, das war allerdings leichter zu verschmerzen als das Risiko des Datenverlustes.
Viele Grüße,
Eicky
