UDS-D zeichnet sich durch folgende Merkmale aus:
Zugriff auf mehrere Datenbankkonfigurationen
Ein Anwenderprogramm kann über UDS-D auf Datenbanken mehrerer Mono- oder Multi-DB-Konfigurationen zugreifen.
Die DB-Konfigurationen können auf geografisch getrennte Verarbeitungsrechner verteilt sein, die über ein Netz miteinander verbunden sind.Für die Art der Verteilung gibt es keine Einschränkungen. Sie richtet sich ausschließlich nach den Bedürfnissen des Anwenders. Grundsätzlich sollte sich jedoch jede Datenbank dort befinden, wo sie am häufigsten bearbeitet wird. Bei einem Zugriff auf Datenbanken entfernter DB-Konfigurationen werden die Daten über das Netz transportiert. In diesem Fall hängen die Antwortzeiten in erster Linie von den Übertragungseinrichtungen im Netz ab. Deshalb können Zugriffe über das Netz erheblich langsamer sein, als Zugriffe auf Datenbanken der lokalen DB-Konfiguration.
Ortsunabhängigkeit der Anwenderprogramme
Der Anwender braucht die Verteilung der Datenbanken nicht zu kennen. Dem Anwenderprogramm müssen grundsätzlich nur die Namen der zu bearbeitenden Subschemata bekannt sein. Nicht bekannt sein müssen die dazugehörige DB-Konfiguration und der entsprechende Verarbeitungsrechner.
Anwenderprogramme können mit Datenbanken arbeiten, ohne zu wissen, an welche DB-Konfiguration sie angeschlossen sind. Das bedeutet, dass Anwenderprogramme keine verteilungsspezifischen Informationen enthalten.
DML-Anweisungen werden anhand einer Verteiltabelle zu der DB-Konfiguration an dem Verarbeitungsrechner geschickt, wo die angesprochene Datenbank liegt.Konfigurationsübergreifende Konsistenz und Deadlockauflösung
UDS-D garantiert Ihnen die netzweite logische Konsistenz aller beteiligten Datenbanken.
Eine Transaktion, die in Datenbanken mindestens einer entfernten DB-Konfiguration geändert hat, wird von UDS-D so beendet, dass die Änderungen entweder auf den Datenbanken aller beteiligten DB-Konfigurationen durchgeführt werden oder auf keiner Datenbank. UDS-D verwendet dazu ein Zwei-Phasen-Ende-Protokoll (Two Phase Commit). Das Transaktionsende ist aufgeteilt in zwei Phasen. In der ersten Phase werden alle Änderungen der Transaktion ausfallsicher protokolliert. Erst nach erfolgreichem Abschluss der ersten Phase werden in der zweiten Phase alle Änderungen auf den Datenbanken festgeschrieben. So ist zu jedem Zeitpunkt des Transaktionsendes sichergestellt, dass entweder alle Änderungen festgeschrieben oder alle Änderungen zurückgesetzt werden können.
Konfigurationsübergreifende Deadlocks werden automatisch erkannt und aufgelöst.