Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

29.10.1999 - 

Datenbanken/Daten-Management sichert Wettbewerbsvorteile

Data-Warehouses bringen Schwung ins DB-Geschäft

MÜNCHEN - Effizientes Daten-Management gilt heute als unternehmenswichtig. Dies gilt vor allem beim Aufbau von Data-Warehouses, bei denen große Datenmengen übertragen werden. Philippe Carlier* beschreibt, worauf bei der Planung von Data-Warehouses und Datenbanken geachtet werden sollte.

Die effiziente Nutzung von Informationen ist das A und O für erfolgreiche Unternehmen. Firmen sind daher auf ein effizientes Daten-Management für die Klassifizierung und Bereitstellung von Know-how sowohl für interne Mitarbeiter als auch für Geschäftspartner und Kunden dringend angewiesen. Aufgrund dieser Anforderungen kommen zentrale Datenbanken und Daten-Center in Mode, die Know-how aus unterschiedlichen Quellen in Rechenzentren vereinen und allen autorisierten Personen zur Verfügung stellen. Ziel ist es stets, Daten zu Analysezwecken zu verknüpfen sowie mit geeigneten Suchprozessen dafür zu sorgen, daß sich Daten schnell auffinden lassen.

Um die benötigten Datenmengen handhaben zu können, setzen die meisten Unternehmen heute auf zentrale Rechenzentren mit umfangreichen Datenbanken. Diese bestehen aus einem oder mehreren Datenbankrechnern, die keine andere Aufgabe haben, als eingehende Nachfragen abzuarbeiten. Der Betreuer oder Operator erfaßt auf ihnen die eingehenden Daten, läßt Anfragen berechnen und greift bestimmte Daten nach vorgegebenen Kriterien heraus. Meist laufen die Abfragen über SQL-Kommandos ab, so daß sie plattformübergreifend eingesetzt werden können.

Alle Hersteller der großen Datenbanksysteme haben entsprechende Abfrage- und Entwicklungs-Tools im Angebot. Damit entwickeln Spezialisten Oberflächen, die dem Anwender lokal auf seinem Rechner zur Verfügung gestellt werden. Lokal setzen diese Frontends komplexe Anfragen in einen effektiven SQL-Code um. So verhindern die Verantwortlichen, daß alle Daten zu den lokalen Rechnern transportiert und dort ausgewertet werden müssen. Die Auswahl erfolgt statt dessen auf den zentralen Servern. Die Übertragung nur der wirklich benötigten Daten senkt die Übertragungszeit und gleichzeitig auch die Bandbreiten, da die ausgewählten Daten nur einen kleinen Ausschnitt der Gesamtdatenmenge eines Data-Warehouse-Systems darstellen.

Anforderungen an die Performance

Anwender greifen auf diese Daten auf unterschiedlichen Wegen zu, über ein lokales Netz oder über Weitverkehrsverbindungen wie ISDN-, FDDI- oder ATM-Verbindungen. Die Anforderungen sind jedoch in allen Fällen gleich. Sämtliche Anwender benötigen ihre Daten möglichst schnell, um mit ihren Applikationen weiterarbeiten zu können. Vielfach handelt es sich um Live-Abfragen, das bedeutet beispielsweise, daß eine telefonische Kundenanfrage in der Kundendienstzentrale beantwortet wird oder der momentane Aufenthalt eines Pakets ermittelt werden soll.

Doch gerade an dieser Stelle versagt oft das Projekt. Eine Studie der Yankee-Group belegt, daß 75 Prozent aller angefangenen Projekte nicht erfolgreich sind, weil die Anforderungen der Anwender nicht oder nur zu einem geringen Teil erfüllt werden. Gründe für den Mißerfolg liegen unter anderem darin, daß für die Entwicklung moderner Client-Server-Anwendungen neue, den veränderten Einsatzzwecken angepaßte Entwicklungsmodelle zugrunde gelegt werden müssen. Planten Entwickler bisher eine Testphase erst nach 80 Prozent der Entwicklungszeiten ein, womit sie hohe Kosten für ein komplettes Redesign der Anwendung riskierten, erlauben neuere Software-Tools bereits nach 20 Prozent der Entwicklung die ersten Tests auf Thread-Ebene in einem lokalen Netzwerksegment und eine Hochrechnung der Antwortzeiten auf reale Netze. So können Projektleiter und Entwickler potentielle Quellen für den Mißerfolg schon in einem frühen Stadium verstopfen.

Um die hohe Zahl der erfolglosen Entwicklungsbemühungen zu senken, gilt es, einige Punkte schon vor der ersten Zeile Programmcode zu beachten: Das Netzwerk muß als Bestandteil der Anwendung betrachtet werden, da deren Leistung immer auch vom Netz abhängt, vor allem bei Data-Warehouse-Systemen mit WAN-Anbindung. Außerdem müssen sich Entwickler und Administratoren zusammensetzen und die Frage klären, welche Einflüsse die Applikation auf das Netzwerk hat und umgekehrt.

Die eigentliche Analyse und Vorhersage erstreckt sich meist auf drei Schritte. Als erstes werden einzelne Tasks und Threads auf ihr Zeitverhalten untersucht. Anschließend kann in der zweiten Phase die Antwortzeit der Anwendung im WAN unter Berücksichtigung von Latenzzeiten, verfügbarer Bandbreite und Netzauslastung ermittelt werden. Auf Grundlage dieser Ergebnisse wird abschließend die Applikation optimiert, was in der Regel vor allem die Datenbank-Tools betrifft.

Ziel dieser Analysen ist es, zu ermitteln, wie sich die Antwortzeiten auf Client, Netzwerk und Server verteilen. Wie sieht der Datenverkehr zwischen Client, getesteter Applikation und den Datenbank-Servern aus? Die Auswertung der gesammelten Daten erfolgt grafisch und für jeden Aspekt getrennt. Dabei entstehen Bounce-Diagramme, die den Ablauf der einzelnen Tasks wiedergeben (siehe Abbildung "Bounce-Diagramm"). Mit Hilfe der Bilder und der ersten Auswertung, in der die Zeiten den einzelnen Abschnitten Client, Netzwerk und Server zugeordnet sind, sehen Entwickler und Administrator die Verteilung. Weiterhin erhalten sie Diagramme, die den Anteil an Nutzdaten im Verhältnis zum Protokoll-Overhead angeben. Abbildung "Payload" zeigt, daß der Protokoll-Overhead unverhältnismäßig hoch ist, was auf eine hohe Zahl von Paketen mit wenig Nutzdaten schließen läßt. Das ist der erste Hinweis auf ein notwendiges Redesign der Anwendung. Eine ineffektive Programmierung oder eine schlechte Anpassung an die Rahmenbedingungen für einen Einsatz im Weitverkehrsnetz können so vermieden werden.

Vorhersage der Antwortzeiten

Für eine Analyse ist hier eine möglichst isolierte Netzwerkumgebung unter Laborbedingungen vorteilhaft. Alle Größen für das Netzwerk sind dann bekannt, die Vorgänge sind ausschließlich auf das Verhalten der Anwendung im Netzwerk zurückzuführen - eine ideale Ausgangsbasis, die Responsezeiten der Anwendung in einem realen Netzwerk vorherzusagen.

Kennen Entwickler und Administratoren erst einmal die Antwortzeiten für die einzelnen Threads und Tasks der Anwendung in dieser isolierten Umgebung und können die ermittelten Zeiten den verschiedenen Komponenten und Übertragungswegen zuordnen, ist anschließend auch eine Vorhersage des Zeitverhaltens im Weitverkehrsnetz möglich.

Optimierung der Anwendung

Die Zeiten lassen sich durch die Vorgabe veränderter Parameter im Weitverkehrsnetz wie Latenzzeiten von Verbindungsknoten, vorgegebene Übertragungsbandbreite und Auslastung der Weitverkehrsnetz-Verbindungen bestimmen. Je nach den gewählten Einstellungen ändern sich Basiszeiten, Laufzeiten und Übertragungszeit für Nutzdaten. Liegen alle ermittelten Diagramme nebeneinander, so können die verantwortlichen Projektmitarbeiter die bestmögliche Einstellung auswählen. Außerdem ist schnell erkennbar, ob die im Pflichtenheft vorgegebenen Zeiten eingehalten werden. Teure Arbeitszeit für ein vorzeitiges Rollout zu Testzwecken wird dadurch nicht verbraucht, die Lösung kann sofort in Angriff genommen werden.

Eine Anwendung kann an die speziellen Eigenschaften von WAN-Verbindungen mehr oder weniger gut angepaßt sein. Hierbei gilt es beispielsweise, die Größe der übertragenen Nutzdatenpakete oder die Auswahl eines geeigneten Übertragungsprotokolls zu beachten. An obigen Abbildungen erkennt der Entwickler sofort, daß die Paketgröße für die Übertragung ungeeignet ist, da die Nutzdaten in zu kleine Pakete aufgeteilt werden. Dies ist insbesondere bei Datenbankabfragen leicht möglich: So hat ein großes, internationales Luftfahrtunternehmen die Erfahrung machen müssen, daß die SQL-Abfrage aus dem Entwicklungspaket für eine WAN-Abfrage ungeeignet war. Das Frontend initiierte bei der Abfrage für jedes einzelne Feld einen eigenen Abfrageprozeß, statt alle Felder in einem Paket zu senden. Dies hatte eine hohe Zahl an Paketen mit Protokoll-Overhead zur Folge. Außerdem zeigte ein Bounce-Diagramm, daß die Kommunikation zwischen einzelnen Stationen nicht bestmöglich für den Übertragungsweg eingerichtet war. Jede einzelne Anfrage führte zu einer hohen Anzahl von Kommunikationsschritten. Dieser übermäßige Datenverkehr konnte gesenkt werden, indem das Protokoll geändert oder die Aufbauroutine innerhalb des Programms gesenkt wurde.

Angeklickt

Im Bereich von Data-Warehouses und den damit verbundenen Applikationen ist eine Optimierung der Anwendung im frühen Stadium wichtig. Bei der Übertragung von großen Datenmengen und umfangreichen Abfrageergebnissen sinken so die Kosten und die Antwortzeiten erheblich. Als Folge reduziert sich auch der Hardwarebedarf trotz beständig wachsender Datenmengen auf Grund der besseren Ausnutzung. Und nicht zuletzt führen kurze Antwortzeiten zu zufriedenen Mitarbeitern und Kunden.

*Philippe Carlier ist Country-Manager Germany bei Optimal Networks in Frankfurt/M.