SQL Azure 1.0 Governance DB2 im Unternehmen Windows 7

• Marktübersicht - offen für den Business-Einsatz
• db40 - objektorientiertes Datenmanagement
• NoSQl - die Zukunft für Daten im Web 2.0
ab S. 68
ab S. 74
ab S. 31
JAHRESARCHIV 2009
• Ausgaben 6/08 bis 6/09
• Über 900 Seiten Profiwissen
• Mit Index und schneller Suche
IBM DB2
•
•
•
•
IBM DB2 Express-C 9.7
Quest Toad for DB2 (Trial)
DB2 Add-in for Visual Studio
Redbook: DB2 Workload Manager
DATENBANKEN
•
•
•
•
MySQl5.1
PostgreSQl 8.4.1.1
Firebird 2.1.3
MariaDB 5.1.39
SQL Azure 1.0
Governance
So funktioniert Microsofts
Datenlösung in der Cloud 5. 36
Daten und Informationen
steuern für den Erfolg s. 87
DB2 im Unternehmen • Transaktionen und Workload Management 5. 46
• Natives XML mit pureXML 5. 59
• Hochverfügbarkeit mit DB2 pureScale 5.82
ORACLE-IDEs
•
•
•
•
•
Toad DBA Suite for Orade 10.1
SQl Navigator 6.2.1
PlISQl Developer 8.0
Hora 8.1.8.3
Orade SQl Developer 1.5.5
Windows 7 - stark 'mit 64 Bit Umfassendes Basiswissen für den Betriebssystem-Wechsel 5. 20
SPECIAL
• combit list & label 15
• Quest Spotlight on SQl Server Enterpr. 6.0
• KeepTool9
DT-Control
geprüft:
Nicht jugend­
beeinträchtigend
Tipps, Tests & Trends Gupta-Datenbankumstieg mit sqlPorter und sqlTranslator 5. 42
Dazu: Oracle-IDEs, MySQL unter Windows, XML-Schema,
Datenbankspiegelung, Lotus Notes Ansichten, SQLite-Workshop,
Geschichte der Datenbanken
LÖSUNGEN
Datensicherung
Datenspiegelung - Ansatz für ein durchgängiges Backup
Aus eins mach zwei Eine vollständige Datensicherung umfasst mehr als die Spiegelung der Daten in der Datenbank­
ein durchgängiges Konzept berücksichtigt auch die Umgebungsdaten. LarsAlbrecht
Auf einen Blick
m eine Standby-Da tenbank aufzubauen,
wird eine Kopie der Originaldatenbank auf
ein anderes System im lokctlen Netz (LAN) oder
in ein entferntes Netz (Wide Area Network,
WAN) tran sferiert. Transaktionen der Echtda­
tenbank werden dann auf das Spiegelsystem
übertragen und der Spiegeldatenbank zuge­
führt. Kommen die Recovery-Dateien zeitver­
setzt bei der Spiegeldatenbank an - zum Beispiel
nach vier Stunden - , bietet di ese Lösung einen
optimalen Schutz vor logischen Fehlern. Wird
beispielsweise um 14:00:00 Uhr di e Echtdaten­
bank durch einen logischen Fehler zers tört, lä sst
sich die Spiegelseite au f 13:59:59 Uhr wiederher­
stellen und so die Datenbank mit gü ltigen Daten
wieder nutzen (Bild 1).
Setzt man eine Standby-Datenbank mit den
Hausmitteln der Oracle Enterprise Edition auf,
sind die Komplexität und das erforderliche
Know-how eine erste Hürde. Die größere Her­
ausforderung aber ist, dass konzeptionell und
funktionell wichtige Anforderungen nich t be­
rücksichtigt werden. Diese müssen entweder
manuell per Zusatzskript geregelt werden oder
sie entfallen komplett. Wie sehen diese An forde­
rungen aus, und wie können sie gelöst werd en?
Die Oracle-Hausmittel sind per Definition da­
tenbankzentrisch und spiegeln deshalb keine
U
I Inhalt
Die hauseigenen Mittel der
Datenbankhersteller taugen
nur zum Spiegeln der in der
Datenbank abgelegten Daten.
Dateien , die außerhalb der
Datenbank vorliegen, und No­
logging-Operationen bemerkt
das Spiegelsystem nicht. Eine
besondere Herausforderung
ist die Spiegelung von Multi­
Daten ba nk-U mgeb ungen.
I Plattform Plattformübergreifend I Autor
Lars Albrecht ist Geschäftsfüh­
rer der Libelle AG. Davor war er
bei IBM Deutschland als IBM
Certified Consultant und Busi­
ness Development Manager
beschäftigt.
Grundprinzip der Daten sicherung
durch Spiegelung auf einem anderen
System (Bild 1)
Entfernungsunabhängig :
Datensicherung in
einem anderen Gebäude,
einer anderen Stadt.
einem anderen Land ,
einem anderen Kontinent.
einfach und ohne
Programmierkennlnisse
~1iIII.!1"""" zu bedienen
1.
Produktivsystem
2. ~
Datentransfer via
TCP/IP·Sockels
102
Spiegelsystem
Dateien außerhalb der Datenbank. Mit zu­
nehmender Verbreitung sogenannter "Service
Oriented Architectures" (SOA) belegen Daten­
banken in Applikationsumgebungen zwar den
größten Bereich, es gibt aber noch andere Teile.
Beispiel SAP-Umgebungen: Hier werden viele
Dateien außerhalb der Datenbank geha lten. So
speichert ein SAP-Portal den gesamten java­
Stack in einfachen Dateien. Werden diese nicht
mitgespiegelt, gehen nach dem Umschal ten auj
das Standby-System w ichtige Unternehmens­
daten verloren. In der Praxis werden diese Da­
teien typischerweise manuell per Skript kop.iert.
Es gib t aber auch Lösungen, die diese Dateien
gleich mitspiegeln.
Spiegeln von Nologging· Operationen Nologging-Operationen sind Datenbankände­
rungen, die direkt auf Datenfile-Ebene der Da­
tenbank ohne Logda teien durchgeführt werden.
Da eine Standby-Datenbank mit Logdateien ar­
beitet, werden diese Operationen nie auf die
Spiegeldatenbank übertragen. Konzeptionell
können Nologging-Operationen jedoch auto­
matisch erkannt und auf das Spiegelsystem
übertragen werden, sodass keine manuellen
Nacharbeiten oder ein kompletter Neuaufbau
des Spiegels erforderlich sind. Eine Umsetzung
dieses Kon ze pts findet sich beispielsweise in
den Spiegellösungen von Libelle [1] . Al ternativ
bleibt oft nur d ie Lösung, die gesamte Applika­
tionsumgebung auf "forced logging" zu setzen.
Ein konzeptioneller Punkt unabhängig vom
verwende ten Spiegelungswerkzeug ist die N ut­
zung vo n "Secondary Archive Destinations".
Dabei werden Logda teien in einem primären
lind einem (op tionalen) sekundären Verzeichnis
gehalten. Beim Betrieb von Standby-Lösungen
wird auf dieselben physikalischen Logdateien
zugegriffen, die in der Regel bereits von einer
Backup-Software verwal tet werden. Eine Tren­
nung in ein primäres und ein sekundäres Ver­
zeichnis bietet mehr Transparenz in Betrieb und
Verwaltung. Listlng 1 zeigt die entsprechenden
Oracle-Befehle.
Ein einmaliges Definieren von Log Archive er­
fordert einen Neustart der Datenbank. Anschl ie­
ßend kann die Anzahl der Destinations ohne
Neustart erweitert werden. Übertragene Datei­
database pro 1/2 010
LÖSUNGEN
Datensicherung
Listing 1: Oracle-Befehle zur Spiegelung
SOL> -- Ist die Datenbank im Archive Mode? SOL> archive log list SOL> -- Welche Archive-Methode wird verwendet? SOL> show parameter l og_archive_dest SO L> -- Wenn l og_archi ve_dest_x aktiviert ist, kan n zwe i te Destination so aktiviert werden: SO L> alter system set 10g_archi ve_dest_Z- 'LOCATI ON=<Znd destination> optiona l reopen=60' scope- both; SO L> SO L>
OPTIONAL bedeutet, die Log-Dest i nation ist optional und vermeidet Archive Stuck, SO L>
MANDA TORY bedeutet, die LOG-Destination ist zwingend und kann zu Archive Stuck führen. SO L>
Oa der Oefault bei den LOG-Destinations OPTIONA L ist, ist zu überlegen, ob eine SOL>
LOG-Destination für Tapebackup nicht auf MANDATORY gesetzt werden muss. SO L>
REOPEN=60 Alle 60 Sekunden wird versucht, ob die Destination wieder beschreibbar ist. SOL> -- Zum Deaktivieren der LOG-Destination: (erfordert Neustart der Datenbank) SOL> alter system reset 10g_archive_dest_Z scope=spfile sid=' *'; SO L>
SO L>
SO L>
SO L>
SO L>
-- Wird noch die alte LOG_ARCHIVE_DEST eingesetzt, ist Folgendes zu tun: alter sys tem reset log_archive_dest scope-spfile sid= ' *'; alter system set 10g_archive_dest_l='LOCATION=<1. Pfad zu Log -Dateien> mandatory' scope- spfi l e; alter system set 10g_archive_dest_Z='LOCATION- <Z. Pfad zu Log-Dateien> optio nal ' scope=spf il e; - - Durchstarten der OB. Beim Ein satz des init-Fi l e mu ss dieses ebenfa ll s geä nd ert werden. en aus dem zweiten Verzeichnis lassen sich dann
entweder per Skript oder durch Tools automati­
sier t löschen.
Der Standby-Betrieb ist vor allem in WAN­
Spiegelungen gefährdet, wenn keine ausrei­
chende Bandbreite zur Verfügung steht oder die
Netzwerke instabil sind. Generelle Basisfunktio­
nen in Orade l1g enthalten zwar einen rudimen­
tären Kompression salgorithmus, d as reicht im
Praxisbetrieb bei großen Datenmengen aber oft
nicht aus. Zusätzlich zu einer erweiterten, para­
metrisierbaren Kompression empfieh lt es sich,
das IP-Protokoll so zu erweitern, d ass mit grö­
ßeren IP-Paketen gearbeitet wird, die parallel
übers Netz geschick t werden. Libelle hat sehr
gute Erfahrun gen in Projekten gemacht, wenn
der Datentransfer über die Standard-Kompri­
mierung hinaus op timiert wurde. Speziell dafür
wurde ein Verfahren entwickelt, das einzelne
Datenpakete in kleinere Pakete auftei lt und die­
se parallel an den Ziel rechner schickt.
Multi-Datenbank-Umgebungen
spiegeln
Eine weitere Herausforderung ist das Spiegeln
von Umgebungen mit mehreren Datenbanke n.
Bezüglich de r SOA von SAP-App lika ti onen be­
deute t dies, dass ein und derselbe Gesc häftspro­
zess über versch iedene SAP-App lika ti onen und
d am it in mehreren Datenbanken geha lten und
verändert wird. Das Absichern mit Standby-Lö­
sungen erfordert, kon zeptionell und in der Um­
setzung per Skript oder per Software-Werkzeug,
1/2010 www.databasepro.de
... sogenannte Recovery Consistency Points [2]
über d as Dateisystem und gegebenenfalls über
verschiede ne Sta ndby-Systeme zu verwalten.
0:
CI)
c:
:z
C)
Per Knopfdruck auf das Spiegelsystem
umschalten
IT'I
:z
Als letzter Schritt im Standby-Betrieb müssen
beim Umschalten der Datenbank die Nutzer auf
das Spiegelsystem umgelenkt werden. SAP­
Lösungen erwarten zum Beispiel, dass der
Spiegel mit dem identischen Hostnamen startet,
damit das SAP-System überhaupt aktiv werden
kann. In einem Ne tzw er k wird idealerweise
auch die gleiche IP-Adresse verwendet. Ent­
sprechend erweiterte Spiegelungslösungen wie
beispielsweise Libelle BusinessShadow beinhal­
ten genau diese Funktionalität. Dadurch ist es
möglich, nicht nur die Datenbank, sondern a uch
die gesa mte Ap plikation auf Knopfdruck um­
zuschalten.
Das Verfahren der Standby-Datenbank deckt
die kritischen Anforderw1gen an Datenbank­
spiegelunge n in weiten Teilen ab. Die Oracle­
Hausmittel sind aber nicht ausreichend, um die
genann ten Anforderungen komplett zu erfüllen.
Um eine durchgängige Spiegelung zu erreichen,
empfieh lt es sich deshalb - falls diese Bereiche
nicht durch eine durchgehende automatisierte
Spiegellösung abgedeckt werden -, die Lücken
zumindes t konzeptionell zu schließen.
[bi]
[J 1wunu.libelle.col/I
[21 htlp://cn.wikiprdinorg/wiklj
Recovery_Collsislfllcy_Objeclive
103