Aufgabe: es soll ein Redesign für das Backup durchgeführt werden

Redesign des vorhandenen Backup
Gliederung
Seite
I; Einleitung
- Entwicklungstendenzen
- Entfernen nicht mehr benötigter Daten
2
II; Lifecycle Management
A; Informationslebenszyklus-Management (ILM)
B; Implementierung von ILM auf 10g
1; Definition von Daten-Klassen
2; Erstellen von Speichermedientypen zu den Daten-Klassen
3; Verwaltung der Daten für den Zugang
3.1 Sicherheit auf DB-Ebene
3.2. Virtuelle private DB (VPD)
3.3 Auditing
3.4 Verschieben der Daten unter Verwendung von Partitioning
3.5 Datenverschlüsselung
III; Ergänzungen zu ILM in 10g
3
4
5
6
7
8
9
11
A; Storage Management
12
- ASM (Automatic Storage Management)
B; Data Movement
13
C; Informationstransfer zwischen DBs
1; Transportable Tablespaces
2; Data Pump
14
3; Streams
D; Datensicherheit
15
1; Anwenden von Flashback
2; Schutz vor Korruption
3; Schutz vor Verlust der Gesamt-DB
4; Sicherheit und Schutz der Daten vor Veränderung
16
4.1; XML
5; Verfahren zur Reduzierung des Speichers
17
- Datenkompression und Beseitigen ungenutzten Speicherplatzes
- Advanced Compression
6; Konsolidierung der Daten (Materialized Views)
18
IV; Anhang
A; Erstellung von Speicherungstypen in der Oracle DB
B; Beispiel zu VPD (virtuelle private DB)
C; Der ILM-Assistent
D; Konvertierung in XML (Beispiel)
19
21
22
23
1
I: Einleitung
Entwicklungstendenzen
Die Entwicklung geht dahin, dass das klassische Backup auf Tape nicht mehr dem
technologischen Fortschritt entspricht. Im Mittelpunkt steht nunmehr das „Lifecircle
Management“ der Daten. Es erfolgt kein Backup mehr. Die Daten werden bevorzugt in
Partitionen gespeichert.
Grund für den technologischen Wandel ist, dass es verhältnismäsig preiswerte ATALaufwerke auf dem Markt gibt. Die Kosten hierfür sind nur unwesentlich höher pro Terrabyte
als wie beim Tape.
Ferner ergeben sich aus der Archivierung mittels Tape zahlreiche Probleme, die bei ONLINEArchivierung nicht auftreten.
-
werden Daten vom Tape benötigt, so muß das Tape erst einmal gefunden werden
ferner sollten die Daten auf dem Tape noch lesbar sein
im Lauf der Jahre hat sich das Verfahren für den Reload der Daten aus dem TapeArchiv geändert, sodaß weitere Entwicklungsarbeit notwendig wird.
Ein wichtiger Vorteil der Speicherung der Daten auf Low Cost Disk ist die online
Verfügbarkeit der Daten in der DB und deren aktuelles Format.
Indem die historischen Daten in der DB gehalten werden, so hat dies keine Auswirkung
auf den Sachverhalt der Zeit für das Backup und den Umfang des Backup.
Wenn RMAN angewiesen wird die DB zu sichern, so werden von RMAN nur die
Änderungen erfasst. Da die historischen Daten sich nicht weiter ändern, so können diese
auf READ ONLY gesetzt werden. Das Backup hierfür erfolgt nur einmalig.
Deswegen ist sind die Anforderungen an die Zeit des Backups und an die Speicherung in
etwa gleich der Archivierung per Tape. Im letzteren Fall werden die Daten in einem Set
von Bändern gesichert.
Entfernen nicht mehr benötigter Daten:
Ein weiteres Problem besteht in der physischen Entfernung der Daten aus der DB. Im
Falle der Verwendung von Tape ist dies ein sehr zeitaufwendiger Prozeß.
Insbesonders ist dies der Fall von SQL-DELETE.
Der schnellste um Daten aus der DB zu entfernen, ist die vorangegangene Speicherung in
der jeweiligen Partition. Um diese Daten nun zu entfernen genügt z.B. die Anweisung:
ALTER TABLE orders DROP PARTITION orders_pre_2008.
2
II; Lifecycle Management
Die Herausforderungen für die Organisation ist das Verständnis dafür, wie sich die Daten
entwickeln, ihre Verwendung sich im Laufe der Zeit verändert und schließlich wie lange diese
erhalten bleiben.
ILM ist dafür geeignet diesen Herausforderungen zusammen mit einer Kombination von
Prozessen, Policies, Software und Hardware zu begegnen, sodaß die geeignete Technologie
für jede Phase des Daten-Lebenszykluses angewendet werden kann
Für die Datensicherung in Verbindung mit Partitioning wird von Oracle das Produkt
ILM (Informationslebenszyklus-Management) empfohlen.
A; Informationslebenszyklus-Management (ILM)
Mit ILM lassen sich Daten effektiver verwalten. Der ILM Assistent von Oracle für 10g ist kostenlos.
Aber auch EMC bietet dieses Produkt an. Zusammen mit Partitionierungsfunktionen ermöglicht dieses
Tool die rechtzeitige Migration oder Löschung der Daten.
Die Entwicklung von ILM wurde von EMC erweitert. Es dient u.a. der Verwaltung von Mails,PDFDateien und EXCEL-Dateien. Selten genutzte Dateien oder ungenutzte Dateien werden auf
langsamere und billigere Speicher-Systeme ausgelagert. Häufig benutzte Inhalte hingegen werden auf
teure Speichermedien (SAN-Maschinen) hinterlegt.
E-Mail, Dokumente, Images und weitere Datentypen
Die Oracle DB speichert sowohl strukturierte als auch unstrukturierte Daten.
Bisher werden diese Daten wie E-Mail, Dokumente, Images und weitere Datentypen außerhalb der DB
gespeichert und außerdem manuell verwaltet. Dieses Scenario kann die Ursache für zahlreiche
Probleme sein. U.a. können diese Dokumente verloren gehen. Ferner kann nicht kontrolliert werden,
wer diese Dokumente unberechtigt liest.
Oracle begegnet diesem Problem mit „Oracle Collaboration Suite (OCS).
OCS ermöglicht ermöglicht die Speicherung von beliebigen Typen an Dokumenten bezw. Images.
Dabei merkt der Anwender nicht, dass diese Daten aus der Oracle DB stammen. Ebenso könnten die
E-Mails des gesamten Unternehmens zentral in der Oracle DB gespeichert werden.
Für die Speicherung der Daten in der DB spricht die Performance, leichtere Verwaltbarkeit und ihre
Sicherheit.
3
B; Implementierung von ILM auf 10g
Die Implementierung von ILM erfolgt in den Stufen:
1; Definition von Daten-Klassen
2; Erstellen von Speichermedientypen zu den Daten-Klassen
3; Verwaltung der Daten für den Zugang, bezw. Migration getrennt nach Klassen
1; Definition von Daten-Klassen
Die am meisten angewendete Klassifizierung ist die je nach Alter oder Datum. Es kann jedoch auch
nach anderen Klassen klassifiziert werden, wie z:B. nach Produkt oder Sicherheit. Es sind auch
zusammengesetzte Klassen möglich.
Beispiel Bestellsystem:
Es wird das Datum der Bestellung auf Zeilenebene als Klasse ausgewählt. Alle Bestellungen für das
Produkt Q1 werden als klassenunabhängige Einheit angesehen. Die Bestellungen für das Produkt Q2
werden einer anderen Klasse zugeordnet.
Nun können die Klassen über Partitionierung implementiert werden. Hierbei werden zwar die Daten
physikalisch separiert, die Applikation sieht jedoch alle Bestellungen.
Partitioning
In der Partitionierung werden die Daten anhand eines Wertes physikalisch platziert.
Oracle unterscheidet folgende Partitionierungstechniken:
-
Range ( bevorzugt)
Hash
Composite
List
Vorteil der Partitionierung besteht in der Möglickeit, die Daten über das jeweilige Speicher-Medium
zu verteilen. Das Verteilkriterium ist dabei die Häufigkeit der Nutzung. Der Anwender sieht die Daten
online, unabhängig von dem Speichermedium. Es werden keine Änderungen in der Aplikation
notwendig. Wenn neue Partitionen angehängt werden sollen (z.B. wegen weiteren Datums),
so wird dies mit der Anweisung ADD PARTITION bewirkt.
Ein weiterer Vorteil bei der Partitionierung ist die Möglichkeit, dass jede Partition ihren eigenen
lokalen Index hat. Die Performance der Query wird erhöht, wenn der Optimizer Partition Elimnation
verwendet. Dabei richtet sich die Query nicht an alle Partitionen, sondern nur an die relevanten.
4
2; Erstellen von Speichermedientypen zu den Daten-Klassen
Die Abbildung zeigt die Verwendung der Daten im Laufe der Zeit.
Im Beispiel werden drei Speicherungstypen definiert. Sie enthalten zusammen alle Daten.
- High Performance
- Low Cost
- Historical
Auf dem „High Performance“ Speichertyp werden alle wichtigen und häufig angegangen Daten
gespeichert. Er liegt auf schnellen SAAN Disks.
In obigem Beispiel ist dies die Partition, welche die aktuellen Bestellungen zum Produkt Q1 enthält.
Diese Bestellungen werden als besonders wichtig klassifiziert.
Der „Low Cost“ Speicherungstyp ist der Ort wo die meisten Bestellungen gespeichert werden. Im
Beispiel sind dies die Bestellungen für das Produkt Q2, Q3 und Q4. Dieser Speicherungstyp besteht
aus großen ATA Disks oder Disks mit großer Kapazitat, wie z.B. in modularen Speicher-Arrays.
Kennzeichnend für den Speicherungstyp ist, dass für diesen nur geringe Kosten anfallen.
Der Speichertyp zu „Historical“ ist der Ort wo Daten liegen, auf die relativ selten zugegriffen wird
oder die selten modifiziert werden. Als Speichertyp werden hier besonders preiswerte Medien
verwendet, wie z.B. ATA Laufwerke. Laufwerke deren Kosten kaum höher sind als die für die
Speicherung auf Tape. Zusätzlich entfallen hier die Nachteile wie in der Einleitung beschrieben.
Im Beispiel Bestellungen käme zu den Produkten der Typ „alte Bestellungen“, der hier „Historical“
zugeordnet wird.
Im Anhang befindet sich ein Beispiel für das Erstellen von Speicherungstypen sowie ein Screenshot
von ILM.
5
3; Verwaltung der Daten für den Zugang, bezw. Migration getrennt nach
Klassen
Der letzte Schritt dient dazu dass nur berechtigte User Zutritt zu den Daten haben. Es gibt eine
Sammlung von Techniken zur Datenmigration zwischen den Speicherungstypen.
Kontrolle des Datenzugangs
Eine Kontrolle des Datenzugangs ist besonders bedeutsam für das Livecycle Management. Im Laufe
der Jahre kann sich die Zugangsberechtigung zu den Daten ändern. Zusätzlich gibt es regulatorische
Anforderungen zur Datenhaltung, wenn diese im elektronischen Format gehalten werden.
Zum Beispiel verlangt gegebenenfalls das Finanzamt den Nachweis, dass die Daten vor
unberechtigtem Zugriff und Änderungen sicher sind. Ferner muß bei geänderten Daten der Nachweis
geführt werden, wer diese verändert hat.
Sicherung der Daten ist ganz erheblich einfacher, wenn diese in der DB gehalten werden.
Die Sicherung wird unterstützt von:
3.1; Datenbank Sicherheit
3.2; Virtuelle private Datenbank
3.3; Auditing
3.4; Partitioning
3.5; Daten-Verschlüsselung
3.1; Sicherheit auf Datenbank Ebene
Ursprünglich wird die DB über das Passwort abgesichert.
Zusätzliche Sicherheit wird über GRANT / REVOKE realisiert.
3.2; Virtuelle private DB (VPD)
Schützt den Datenzugang. Der User erhält einen View zu einen oder mehreren Tabellen.
Es werden Policies mit sehr differenzierten Details für den Zugang erstellt. Z.B. welche Spalten und
Zeilen ein User sehen darf. Multiple Policies können definiert werden, sodaß verschiedene User in
ihren Applikationen nur ausgewählte Views der Daten sehen. Da die Policies auf DB-Ebene definiert
sind, so erzwingen sie die Einhaltung der Policies, und zwar unerheblich wie der Dateizugriff erfolgt.
z.B. Wenn eine Policy festlegt, dass ein User nur seine eigenen Daten sehen darf , formt VPD um:
aus SELECT * FROM table formt VPD um in:
SELECT * FROM table WHERE employee = ‚username’.
Daraus läßt sich eine sehr sichere Umgebung definieren. In ihr kann man sichergehen, dass kein
authorisierter Zugang erfolgt.
Ein weiterer Vorteil von VPD ist, dass hinsichtlich historischer Daten man genau festlegen kann,
welche Daten der User sehen darf.
z.B.
Eine Standard Policy legt fest, dass kein Zugang zu historischen Daten erfolgen darf. Eine weitere
Policy legt fest, dass bestimmte User historische Daten ab dem Jahr 2008 sehen dürfen.
Wenn ein User eingibt „SELECT * FROM orders, so formt VPD diesen String um in:
SELECT * FROM orders WHERE time_id > `31-Dec-2007`.
Ein weiteres Beispiel siehe im Anhang
6
3.3; Auditing
Aus Gründen des Business bezw. wegen Richtlinien ist es erforderlich, dass nicht nur die
Daten geschützt werden, sondern es ist von Interesse, wer auf die Daten zugegriffen hat.
Für die Aufsicht mag es erforderlich sein, dass man in der Lage ist zu benennen, wann der Datensatz
erstellt worden ist, sondern auch wann auch immer dieser abgeändert wurde und durch wen.
Auditing sollte auf „enabled“ gesetzt werden. Dann landen alle Daten über den Datenzugriff im AuditTrail.
Beispiel:
SQL> AUDIT insert,update,delete ON ilm_orders BY ACCESS.
Eine Abfrage des Audit-Trail zeigt, dass der User ILM_NORMAL versucht hat einige Bestellungen
abzuändern. Dabei war er nicht erfolgreich.
SQL> SELECT username, timestamp ,returncode, sql_text FROM dba_audit_trail;
USERNAME TIMESTAMP RETURNCODE SQL_TEXT
ILM_POWER 20-JAN-05 0
insert into orders select * from orders where time_id > '01-Jan-1994'
ILM_NORMAL 20-JAN-05 2004
delete from ilm.orders where time_id ='01-Jan-2007'
Für weitere Details zu Auditing wird das vom selben Author erstellte Paper
“Fine Grained Auditing” (30 Seiten) empfohlen.
3.4; Verschieben der Daten unter Verwendung von Partitionierung
Im Laufe des Lebenszyklus der Daten wird es notwendig sein, diese zu verschieben. Einbeziehung von
Partitioning im DB-Design, erleichtert ganz erheblich die Verschiebung der Daten, jeweils gemäß
ihrer Verwendung in ihrem Lebenszyklus.
Wird die in einer Partition enthaltene Information nicht mehr regelmäßig benötigt, so kann diese
Partition mit dem Kommando MOVE PARTITION auf preiswertere Platten verschoben werden.
Beispiel:
Eine neue Partition wird für den hoch performanten Speicherungstyp angelegt. Er dient der
Speicherung der Bestellungen von Oktober bis Dezember 2008. Die Bestellungen von Juli bis
September 2008 werden von dem hoch performanten Speicherungstyp auf den kostengünstigeren
Speicherungstyp LOW_COST verschoben.
ALTER TABLE orders ADD PARTITION orders_octdec_2008
VALUES LESS THAN (TO_DATE('1/10/2008','DD/MM/YYYY'))
TABLESPACE ilm_high_performance UPDATE INDEXES
ALTER TABLE orders MOVE PARTITION orders_julsep_2008
TABLESPACE ilm_low_cost UPDATE INDEXES;
7
Partitionierung kann auch dazu verwendet werden, um zwischen partitionierten und nicht
partitionierten die Daten zu verschieben mittels
EXCHANGE PARTITION
So können Daten in einer normalen Tabelle zuerst gesammelt werden und dann in eine partitionierte
Tabelle verschoben werden. Das Gleiche umgekehrt.
Zeilen können automatisch von einer Partitition zur anderen verschoben werden wenn für die Partition
ROW MOVEMENT eingeschaltet worden ist.
z.B. ein Kunde hat seit den vergangenen 12 Monaten nichts bestellt. Falls hier ein Update erfolgt, so
wird der Datensatz zu dem Kunden automatisch zu einer Partition im Low-Cost Speichertyp
weitergeleitet.
8
3.5; Datenverschlüsselung
Die Sicherheit auf DB-Basis reichte vor einigen Jahren noch aus. Im Laufe der Jahre entwickelte sich
die Notwendigkeit nachzuweisen, dass die Daten von Niemanden verändert worden sind.
Der Nachweis dafür, dass eine Datei niemals verändert worden ist kann mit der cryptograpischen
Signatur erfolgen. Dieses gleicht einer persönlichen Unterschrift unter ein Dokument.
Oracle DB 10g erstellt eine cryptographische Signatur mittels des Package DBMS_CRYPTIO.
Eine Spalte, ein Datensatz oder ein Abfrage-Ergebnis kann in das Package eingegeben werden. Die
daraus resultierende Signatur kann dann mit den Daten oder an einem anderen neutralen Ort
abgespeichert werden. Jederzeit kann die Signatur wieder erstellt werden und mit der ursprünglichen
Signatur verglichen werden zum Nachweis, dass die Datei ganz und gar nicht verändert worden ist.
Beispiel:
Es wird das Package DBMS_CRYPTO verwendet. Damit wird die in der DB gespeicherte
KreditkartenNr verschlüsselt und entschlüsselt. Diese Nummer wird im Bestellsystem verwendet.
DECLARE
cc_number VARCHAR2(16) := '4567123443215678';
cc_raw RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(cc_number,'AL32UTF8','US7ASCII'));
key_string VARCHAR2(8) := 'ilm7demo';
raw_key RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(key_string,'AL32UTF8','US7ASCII'));
encrypted_cc RAW(2048);
encrypted_string VARCHAR2(2048);
decrypted_cc RAW(2048);
decrypted_string VARCHAR2(2048);
BEGIN
dbms_output.put_line('Credit Card Number : ' ||
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(cc_raw),'US7ASCII','AL32UTF8'));
encrypted_cc := dbms_crypto.Encrypt(
src => cc_raw, typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
dbms_output.put_line('Encrypted Credit card Number : ' ||
rawtohex(UTL_RAW.CAST_TO_RAW(encrypted_cc)));
decrypted_cc := dbms_crypto.Decrypt(
src => encrypted_cc, typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
decrypted_string :=
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(decrypted_cc),'US7ASCII','AL32UTF8');
dbms_output.put_line('Decrypted Credit Card Number : ' || decrypted_string);
END;
Implementing
DECLARE
cc_number VARCHAR2(16) := '4567123443215678';
cc_raw RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(cc_number,'AL32UTF8','US7ASCII'));
key_string VARCHAR2(8) := 'ilm7demo';
raw_key RAW(128) :=
UTL_RAW.CAST_TO_RAW(CONVERT(key_string,'AL32UTF8','US7ASCII'));
encrypted_cc RAW(2048);
encrypted_string VARCHAR2(2048);
decrypted_cc RAW(2048);
decrypted_string VARCHAR2(2048);
BEGIN
dbms_output.put_line('Credit Card Number : ' ||
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(cc_raw),'US7ASCII','AL32UTF8'));
9
encrypted_cc := dbms_crypto.Encrypt(
src => cc_raw, typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
dbms_output.put_line('Encrypted Credit card Number : ' ||
rawtohex(UTL_RAW.CAST_TO_RAW(encrypted_cc)));
decrypted_cc := dbms_crypto.Decrypt(
src => encrypted_cc, typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => raw_key);
decrypted_string :=
CONVERT(UTL_RAW.CAST_TO_VARCHAR2(decrypted_cc),'US7ASCII','AL32UTF8');
dbms_output.put_line('Decrypted Credit Card Number : ' || decrypted_string);
END;
Implementing
Der Output der PL/SQL Prozedur zu der Kreditkarte 4567123443215678 lautet verschlüsselt:
334441423444433532353134383644323339423344454638323839393146423639434134323543343445363742453030
Entschlüsselt: 4567123443215678
10
III; Ergänzungen zu ILM in 10g
Folgende Bereiche ergänzen ILM:
- Partitioning (siehe im Anhang)
- Storage Management
- Data Movement
- Sicherheit und Schutz der Daten vor Veränderung
-
Verfahren zur Reduzierung des Speichers
A;Storage Management
Für die Betrachtung des Lifecycle Management sind die Hardware zur Datenhaltung sowie die Art
und Weise wie die Daten verwaltet, gesichert und deren Zugang gestaltet wird.
Es werden drei Gruppen unterschieden:
- Disk Storage (SCSI,ATA,Cached Disk Array, usw.)
- Optical Disk (CD-ROM,WORM, usw)
- Tape (eignet sich nicht für den Online Zugang)
Der Zugang der Daten auf Tape ist nur sequentiell. Der wahlfreie Zugang auf Optical Disk ist relativ
langsam. Der große Vorteil der Optical Disk ist die längere Erhaltungsdauer der Daten im Gegensatz
zu Tape oder Disk. Die Optical Disk ist unempfindlich gegenüber Magnetismus in der Umgebung.
Eine (welche ?) Studie in den U.S.A. belegte, dass bei großem Datenumfang (Terrabyte) die Optical
Disk gegenüber dem Tape die kostengünstigere Lösung darstellt.
Automatic Storage Management (ASM)
Das Angebot preiswerter ATA Disks hat auf dem Markt für Speicherungssysteme einen entscheidenen
Technologiewandel bewirkt. Siehe hierzu auch in der Einletung (Entwicklungstendenzen).
Oracle begegnet dieser technischen Entwicklung mit zahlreichen Tools für die Disk-Verwaltung.
Eines dieser Tools ist „Automatic Storage Management“ ASM. ASM ermöglicht es, große Pools von
Disks relativ einfach zu verwalten. Dabei werden Disks und Dateien in sogenannten „Diskgroups“
erfasst. Alle DB-Dateien mit entsprechenden Strukturen beziehen sich nunmehr auf eine Disk-Group
und nicht mehr auf einen physischen Speicherort.
Der DBA kann über ASM nunmehr Disks dynamisch zuordnen oder entfernen. So kann die DB ohne
Shutdown vergrößert werden. Daten können gespiegelt werden. Ferner werden dieDaten über die
Disks gleichmäßig verteilt, sodaß keine „Hot Spots“ entstehen.
11
Bei der Verwendung von ILM (siehe -> ILM) empfiehlt sich die Einteilung in die Gruppen:
- high performance
- low cost
- historical
Jedem dieser Gruppen kann nun eine Diskgroup zugeordnet werden.
Wenn ASM zusammen mit Data Partitioning auf eine Table angewendet wird, so können sich die
Partitionen über alle Disk – Gruppen erstrecken. Wenn sich später ergeben sollte, die Daten auf eine
andere Disk-Gruppe zu transferrieren, so kann dies geschehen mit:
- MOVE PARTITION
- ONLINE REORGANIZATION
- COPY eines Tablespace gefolgt von RENAME
12
B; Data Movement
Datendateien und Tabellen einen anderen Speicherort zuweisen
Die Zuweisung eines anderen Speicherortes erfolgt mit:
ALTER TABLESPACE RENAME DATAFILE
Dieser Schritt erfordert voraussehende Planung, um sicherzugehen, dass die zu bewegende Datei keine
Zahlreiche Zugriffe hat.
Tabellen können auch bewegt werden unter Anwendung des Packages: DBMS_REDEFINATION
Vorteil hierbei ist, dass User auf die Tabelle online zugreifen können, obwohl dieser ein neuer
Speicherort zugewiesen wird.
C; Informationstransfer zwischen DBs
Informationsaustausch zwischen DBs kann erfolgen mit:
- Transportable Tablespaces
- Data Pump
- Streams
1;Transportable Tablespaces
In der Vergangenheit dauerte ein EXPORT/IMPORT im Extremfall mehrere Stunden..
„Transportable Tablespaces“ ist ein Mittel, um umfangreiche Datenvolumina unter Datenbanken
relativ schnell zu bewegen, unabhängig vom Betriebssystem. Es werden nicht mehr einzelne
Datensätze extrahiert. Unter der Voraussetzung, dass die Daten in der Tablespace in sich geschlossen
sind, also keine Links zu Daten außerhalb, kann eine Tablespace komplett in eine andere DB
transferriert werden.
Dieses Verfahren eignet sich besonders für Partitionen.
Transportable Tablespaces lassen sich auf CDROM oder DVD speichern. Diese CD kann dann
gemountet werden. Mittels des Kommandos IMPDP kann das Tablespace in eine andere DB
eingefügt werden.
Normalerweise werden Daten, die aus der DB entfernt worden sind, nicht wieder zurückgeschrieben .
Im Falle einer Revision kann ein Restore notwendig werden. In diesem Fall kann der Tablespace
schnell zurückgeladen werden.
Beispiel siehe Anhang
13
2; Data Pump
Das Verfahren mit „Transportable Tablespaces“ für den Fall umfangreichen Datentransfers kann
manchmal nicht den vorgesehenen Zweck erfüllen. Dies ist z.B. der Fall, wenn im darunterliegenden
Betriebssystem die Reihung der Bytes unterschiedlich ist.
“Data Pump“ ist neu ab Version 10g. Es umgeht die Problematik des Export/Import Utility, wenn auf
Beiden Seiten unterschiedliche ORACLE Versionen vorhanden sind.
“Data Pump“ wird dazu verwendet, Daten in das Dateisystem des Betriebssystem zu
transferrieren.Auf dem Zielsystem wird dann die transferrierte Datei in die DB geladen.
3; Streams
Oracle Streams ermöglicht das Sharing von Informationen zwischen DBs. Es ermöglicht bequem und
effizient Daten für andere Datenbanken zu replizieren. Jede Veränderung in der ursprünglichen DB sei
es mittels DML oder DDL, wird erfasst und bei anderen DBs repliziert. Mittels Rules kann eine
Auswahl der zu sendenden Daten getroffen werden. Auf die zu sendenden Daten können auch
Transformationen angewendet werden.
Für den Transfer von Tablespaces wird das Package DBMS_STREAMS_TABLESPACE_ADM
empfohlen. Vorteil hierbei ist, dass die einzelnen Zwischenschritte für den Transfer von Tablespaces
entfallen. Es kann im Zusammenhang mit „Transportable Tablespaces“, „Data Pump“ und dem
Package DBMS_FILE_TRANSFER angewendet werden.
Mittels Streams entfällt die Notwendigkeit Anwendungen für individuellen Datenauszug und
Ladevorgänge zu entwickeln.
14
D; Datensicherheit
Wenn große Datenmengen online gehalten werden so sollten folgende Störfälle zur Datensicherheit
berücksichtigt werden:
-
Hardwarefehler (RAC & ASM)
Menschliche Fehler (Flashback)
Daten Korruption (RMAN / Flash Recovery Area)
Komplettes Disaster (Data Guard)
ungewollte Datenänderungen
Datenstruktur (Datentyp, weitere Spalte, DB-Version, Platform) haben sich geändert
Oracle bietet die folgenden Möglichkeiten zur Störungsbeseitigung an:
1; Anwenden von Flashback
Daten werden ungültig. Dies ist z.B. der Fall wenn eine Applikation die DB korrumpiert oder der DBAdministrator einen Batch zweimal startet.
Diese Störung kann mit Flashback relativ einfach behoben werden. Es bedarf nur eines Kommandos
um die DB in einen zeitlich verschiedenen Zustand zu wandeln. Da die die DB nur die veränderten
Blöcke aufzeichnet berührt ein Flashback-Kommando nur die veränderten Datenblöcke.
2; Schutz vor Korruption
Wenn die DBs an Umfang zunehmen so vergrößert sich auch die Zeit für das Backup. Gleichzeitig
vergrößern sich die Anforderungen an den Speicher. Oracle empfiehlt hier das „inkrementielle
Backup“ als Ersatz für das Full Backup.Diese inkrementiellen Backups sollten auf ATA – Laufwerken
online gespeichert werden und nicht auf Tape. Damit lässt sich innerhalb kürzester Zeit das Recovery
bei Bedarf durchführen.
Um im Umfang vor größerer Korruption zu schützen, die z.B. ein komplettes Restore der DB
erfordern, empfiehlt Oracle eine „Flashback Recovery Area“.
Letztere fasst alle Dateien, die für das Recovery maßgeblich sind.
Dabei wird die „Flasback Recovery Area“ online gehalten und erfasst auch das letzte Backup der
Datenbank. Mit den inkrementiellen Backups auf Disk (ATA) dauert ein Recovery nunmehr nur noch
einzelne Minuten. Die Verwendung von ATA und „Flash Recovery Area“ ist der Lösung unter
Verwendung von Tape eindeutig überlegen.
3; Schutz vor Verlust der Gesamt-DB
Im Hause ist existiert eine „Cold Standby“. Bei Umwandlung in eine Warm-Standby kann bei
Verwendung ab DB-Version 11g diese als Backup Server mit eingesetzt werden. Eine Logical
Standby empfiehlt sich für „Hot Patching“ und für „Rolling Upgrades“.
Auch für Zeiten der Wartung ist diese Vorgehensweise zu empfehlen, da die Downtime hier entfällt.
15
4; Sicherheit und Schutz der Daten vor Veränderung
Im Laufe der Jahre kann die Notwendigkeit entstehen, dass sich die Daten nicht mehr
verändern.
Informationen werden in der Oracle DB in Tablespaces gespeichert. Im laufe der Zeit altern
diese Daten . Die Tablespaces sollten dann auf READ-ONLY gesetzt werden mit
ALTER TABLESPACE ilm_historical READ ONLY
Mit diesem Kommando wird verhindert, dass sich die Daten unter keinen Umständen ändern.
Da die Daten in dem READ_ONLY Tablespace sich nicht mehr ändern können werden diese in
Zukunft nicht mehr mit RMAN gesichert, wenn sie einmal gesichert worden sind. Diese Technik
angewendet auf „historische Daten“ verhindert dass keine Resourcen für das Backup nicht mehr
veränderbarer Daten verwendet werden.
Ein weiterer sehr beachtlicher Vorteil bei READ ONLY ist, dass diese sich für die Speicherung auf
CDROM,DVD oder WORM anbieten.
Wenn der Parameter READ_ONLY_OPEN_DELAYED Parameter in der INIT<SID>.ORA auf
TRUE gesetzt wird, dann wird Oracle erst den Zugriff auf diese READ_ONLY Tablespaces
realisieren, wenn dieser real angefordert wird.
Datenstruktur (Datentyp, weitere Spalte, DB-Version, Platform) haben sich geändert
Sollte nun entschieden werden die Daten auf Tape zu archivieren, so müßte dabei bedacht
werden dass aus der DB entfernte Daten zu einem zukünftigen Zeitpunkt evtl. wieder
benötigt werden.
Wichtig ist dieser Punkt wenn ein Datensatz für die Revision aufgefunden und dargestellt
werden soll. Die Daten müssen bis mindestens 10 Jahre rückwirkend darstellbar bleiben,
unabhängig von der DB Version (vielleicht schon 14g) und unabhängig von der Platform.
Deswegen sollte ein Format gewählt werden welches diesen Umstand berücksichtigt.
Eine beliebte Lösung ist das XML-Format.. Im XML-Format lassen sich Daten
unabhängig von der Hardware bezw. Software verwenden. Man umgeht hiermit auch die
Schwierigkeit, dass das Format im Laufe der Zeit abgeändert wird.z.B. wenn ein
Datentyp umgewandelt worden ist oder wenn an den Datensatz neue Felder anghängt
worden sind.
Kurzum die Daten können in XML rückwirkend dargestellt werden, unabhängig von der
Art der Speicherung und unabhängig von der Platform.
ORACLE 10g bietet für die Wandlung in XML-Format XML DB an.
Beispiel für ein third Party Tool siehe unter:
http://www.stylusstudio.com/convert_to_xml.html
Beispiel für eine XML-Konvertierung siehe Anhang
16
5; Verfahren zur Reduzierung des Speichers
Datenkompression und Beseitigen ungenutzten Speicherplatzes
Wenn sich die Daten nicht mehr ändern, sollten diese komprimiert werden.
Deswegen, wenn die Partition zur Peripherie mit geringen Kosten verschoben wird, so können
diese zugleich komprimiert werden. Zu ILM wird weiter unten eingegangen.
Komprimierung kann die Performance für den Datenzugriff beschleunigen. Ebenso ist dies der Fall für
Backup und Recovery.
ALTER TABLE orders MOVE PARTITION orders_octdec_2008
TABLESPACE ilm_low_cost COMPRESS
Für Entfernen ungenutzten Speicherplatzes: ALTER TABLE orders SHRINK SPACE;
Ferner kann PCTFREE auf Null gesetzt warden.
Oracle bietet ab Version 11g „Advanced Compression“ an.
Advanced Compression
Hilft beim Verwalten der Daten. Es komprimiert jeden Datentyp, inklusive unstrukturierte
Daten, wie z,B. Dokumente, Bilder und Multimedia. Ebenso komprimiert es den Verkehr im
Netz sowie die Daten die gerade in einem Backup gesichert werden.
Eigenschaften sind:
- OLTP Kompression: ermöglicht die Kompression von strukturierten Daten
bei DML Operationen.
- Absicherung replizierter Daten: entdeckt und entfernt doppelte Datei-Kopien
gespeicherter Daten.
- komprimiert auch unstrukturierte Daten
- komprimiert RMAN Backups und DATApump Export
- komprimiert bei DATA-GUARD die über das Netzwerk gesendeten Redo-Logs
17
6; Konsolidierung der Daten (Materialized Views)
Wenn Informationen erhalten werden, so wird zuerst daran gedacht diese in der ursprünglichen
Form zu erhalten. Nach einiger Zeit ist man nicht mehr daran interessiert z.B. an den Details zu
einem Kunden an einem bestimmten Tag.
Nach einiger Zeit genügt die Zusammenfassung der Daten.
Oracle bietet hierzu die Möglichkeit der „Materialized Views“ an. Diese können den Umfang der
Speicherung reduzieren. Ist ein Materialized View aus der ursprünglichen Datenquelle erst einmal
erstellt, so genügt für den Datenrefresh , dass nur die inkrementiellen Änderungen angewendet
werden.
Beispiel:
Ein Materialized View wird angelegt. Dieser speichert die Bestellungen des Kunden,
zusammengefasst nach Anzahl und Gesamtwert pro Monat.
CREATE MATERIALIZED VIEW Cust_orders
BUILD IMMEDIATE
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS
SELECT o:cust_id,T.month,COUNT(*) AS num_orders,
sum(amount_sold) as total_spend
FROM orders o, time t
WHERE o.time_id=t.time_id
GROUP BY o.cust_id,t.month;
“QUERY REWRITE” richtet automatisch und transparent eine Annfrage an den Materialized
View, zum schnelleren Zugang zu den aufsummierten Daten. Und dies obwohl sich die Anfrage
an die ursprüngliche Datenquelle richtet.
18
IV; Anhang
A; Erstellung von Speicherungstypen in der Oracle Datenbank
Es werden Tablespaces definiert, die sich auf unterschiedlichen Speichermedien befinden.
In diesem Fall ist es das Tablespace ILM_HIGH_PERFORMANCE
auf der hoch performanten Disk „/hdsk1“
CREATE TABLESPACE "ILM_HIGH_PERFORMANCE"
DATAFILE '/hdsk1/oradata/orcl/ilm_high_perf' SIZE 10G
AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
Der low cost Speichertyp ist eine Disk bekannt als „/lcdsk1“
CREATE SMALLFILE TABLESPACE "ILM_LOW_COST"
DATAFILE '/lcdsk1/oradata/orcl/ilm_low_cost' SIZE 100G
AUTOEXTEND ON NEXT 10G MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO ;
Da der Speichertyp “Historical” sehr umfangreiche Daten enthält, wird dieser als solcher mit multiplen low cost
Speicherlaufwerken definiert. Diese werden hier als „lcdisk0“ und als „lcdisk11“ benannt.
CREATE SMALLFILE TABLESPACE "ILM_HISTORICAL"
DATAFILE '/lcdisk10/oradata/orcl/ilm_hist1' SIZE 15T
AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED,
'/lcdisk11/oradata/orcl/ilm_hist2' SIZE 5T
AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED
LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE
MANAGEMENT AUTO ;
Nachdem nun die Speichertypen erstellt worden sind, so werden die Datenklassen wie im
Step 1 definiert physikalisch in der DB unter Verwendung von Partitionen implementiert.
Im folgenden die Struktur der Tabelle „ORDERS“. Es werden dann die Datenklassen
(Partitionen) den entsprechenden Speichertypen (Tablespaces) zugeordnet. Diese
Vorgehensweise ist sehr komfortabel, wenn es darum geht die Daten über die SpeicherungsMedien zu verteilen, und dies in Abhängigkeit von ihrer Häufigkeit des Gebrauchs.
Zugleich werden die Daten online gehalten und sind sofort zugänglich auf den am ehesten
kosteneffektiven Laufwerk.
19
Im folgenden Beispiel werden die aktuellsten Bestellungen auf dem Laufwerkstyp mit der höchsten
Performance gespeichert. Die Bestellungen der letzten drei Vierteljahre werden in dem „Low Cost“
speicherungstyp gespeichert. Der Rest kommt zu dem Speicherungstyp „Historical“.
CREATE TABLE orders (
prod_id NUMBER NOT NULL,
cust_id NUMBER NOT NULL,
time_id DATE NOT NULL,
channel_id NUMBER NOT NULL,
promo_id NUMBER NOT NULL,
quantity_sold NUMBER(10,2) NOT NULL,
amount_sold NUMBER(10,2) NOT NULL)
--- partitions
-PARTITION BY RANGE (time_id)
( partition orders_pre_2005 VALUES LESS THAN
(TO_DATE('1/1/2006','DD/MM/YYYY')) TABLESPACE ILM_HISTORICAL,
partition orders_2006 VALUES LESS THAN
(TO_DATE('1/1/2007','DD/MM/YYYY')) TABLESPACE ILM_HISTORICAL ,
partition orders_janmar_2007 VALUES LESS THAN
(TO_DATE('1/4/2007','DD/MM/YYYY')) TABLESPACE ILM_LOW_COST ,
partition orders_aprjun_2007 VALUES LESS THAN
(TO_DATE('1/7/2007','DD/MM/YYYY')) TABLESPACE ILM_LOW_COST ,
partition orders_julsep_2007 VALUES LESS THAN
(TO_DATE('1/10/2007','DD/MM/YYYY')) TABLESPACE ILM_LOW_COST,
partition orders_octdec_2007 VALUES LESS THAN
(TO_DATE('1/1/2008','DD/MM/YYYY'))
TABLESPACE ILM_HIGH_PERFORMANCE );
ASM – beschrieben an einer anderen Stelle - kann zur Verteilung der Daten
über die Speicherungstypen zusätzlich herangezogen werden.
20
B; Beispiel zu VPD (virtuelle private DB)
The first step is to create a function which specifies that user ILM_POWER may view all data, and user
ILM_NORMAL can only see data from 2004. All other users will not be allowed to view this data.
Zuerst wird eine Funktion erstellt, die festlegt daß der User ILM_POWER alle Daten sehen darf. Und User
ILM_NORMAL kann nur die Daten ab dem Jahr 2004 sehen.
CREATE OR REPLACE FUNCTION ilm_seehist
(oowner IN VARCHAR2, ojname IN VARCHAR2)
RETURN VARCHAR2 AS con VARCHAR2 (200);
BEGIN
If SYS_CONTEXT('USERENV','SESSION_USER') = 'ILM_POWER' THEN
-- see all data
con:= '1=1';
ELSIF
SYS_CONTEXT('USERENV','SESSION_USER') = 'ILM_NORMAL ' THEN
-- see 2004
con := 'time_id > ''31-Dec-2007''';
ELSE
-- no data
con:= '1=2';
END IF;
RETURN (con);
END ilm_seehist;
Erstellung der Sicherheitspolitik mit dem Package DBMS_RLS. Das Package verwendet die Function
ilm_seehist s.o.
BEGIN
DBMS_RLS.ADD_POLICY (object_schema=>'ILM', object_name=>'orders',
policy_name=>'ilm_view_history_data',
function_schema=>'ilm', policy_function=>'ilm_seehist',
sec_relevant_cols=>'time_id');
END;
Nun kann die Wirkung dieser Sicherheits-Politik überprüft werden, wenn mehrere User die Daten abfragen.
Die Abfrage des Users ILM_POWER liefert alle Zeilen zurück.
SQL> connect ilm_power/ilm;
SQL> select count(*) from ilm.orders;
COUNT(*)
916039
Der User ILM_NORMAL kann nur die Date nab dem Jahr 2008 abfragen.
SQL> connect ilm_normal/ilm;
SQL> select count(*) from ilm.orders;
COUNT(*)
6039
21
C; Beispiel: Der ILM-Assistent:
22
D; Beispiel zu Konvertierung in XML mittels Package DBMS_XMLGEN
Im folgenden BEISPIELE WERDEN ALLE Bestellungen vor 2008 in das XML Format konvertiert
CREATE TABLE temp_clob (result CLOB);
DECLARE
qryCtx DBMS_XMLGEN.ctxHandle;
result CLOB;
BEGIN
-- Select all Orders prior to 2008
qryCtx := DBMS_XMLGEN.newContext
('SELECT * from orders WHERE time_id < ''1-Jan-08 '' ');
-- set row header to be ORDERS prior to 1996
DBMS_XMLGEN.setRowTag(qryCtx, 'ORDERS_PRIOR_2008');
-- now get result
result := DBMS_XMLGEN.getxml(qryCtx);
insert into TEMP_CLOB values(result);
dbms_xmlgen.closeContext(qryCtx);
END;
Eine andere einfache Methode besteht darin, die in Oracle DB 10g vorhandenenen XML – Funktionen in
SQL einzubauen.
SELECT XMLELEMENT("Orders",
XMLElement ("timeid", time_id ),
XMLElement ("prodid", prod_id ),
XMLElement ("Customer", cust_id ),
XMLElement ("amount", amount_sold) ) AS "RESULT"
FROM orders WHERE time_id < '1-Jan-08 ';
23