Whitepaper. Features der Oracle Datenbank aus der Data-Warehouse-Perspektive

Größe: px
Ab Seite anzeigen:

Download "Whitepaper. Features der Oracle Datenbank aus der Data-Warehouse-Perspektive"

Transkript

1 Whitepaper Features der Oracle Datenbank aus der Data-Warehouse-Perspektive

2 Features der Oracle Datenbank aus der DWH-Perspektive Autor: Timo Bergenthal für OPITZ CONSULTING Haben Sie Fragen zu diesem Thema? Dann sprechen Sie uns gerne an! Ihr Ansprechpartner: Stefan Raabe, Managing Consultant OPITZ CONSULTING Inhaltsübersicht Vorwort Features zur Beladung eines DWH SQL Loader &External Tables Change Data Capture Export und Import Transportable Tablespace Multitable Insert Table Functions Physikalische Datenspeicherung Compression Features zur Herstellung guter Datenqualität Constraints Dimensions Features zur Steigerung der Performance Partitionierung Partition Exchange Loading Indizes Materialized Views Online Analytical Processing (OLAP) Parallelisierung Features zur Aggregation Analytische Funktionen Datensicherheit Sicherung von Daten vor unbefugtem Zugriff Backup und Recovery Resümee Quellenangaben Die Oracle Datenbank wird stetig weiter entwickelt. Mittlerweile liegt sie in Version 11gR2 für alle gängigen Betriebssysteme vor. Mit jeder neuen Version nimmt auch der Funktionsumfang der Datenbank zu, der mit kostenpflichtigen Zusatzoptionen sogar noch erweiterbar ist. Viele der Features haben ein sehr spezielles Anwendungsgebiet und werden daher nur von einem kleinen Anwenderkreis benötigt. Andere Features gehören zum Allgemeingut und dürfen in keinem Data Warehouse (DWH) fehlen. Mit diesem Whitepaper möchte ich DWH-Entwicklern einen groben Überblick über Data-Warehouse-relevante Features der Oracle Datenbank geben. Der Nutzen und die möglichen Anwendungsfälle des Features steht hierbei im Vordergrund. Auf technische Detailfragen werde ich im Rahmen dieses Dokuments nicht eingehen. Texte und Abbildungen wurden mit größter Sorgfalt erarbeitet. OPITZ CONSULTING kann jedoch für eventuell verbleibende fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Das Recht an dargestellten Verfahren, Showcases, Implementierungsbeispielen und Sourcecodes liegt ausschließlich bei OPITZ CONSULTING. OPITZ CONSULTING Deutschland GmbH 2015 Whitepaper Features der Oracle Datenbank aus der DWH-Perspektive Seite 2

3 Features zur Beladung eines DWH Ein DWH ist nach der Definition von William H. Inmon eine themenorientierte, integrierte, zeitorientierte und nicht flüchtige Sammlung von Daten (vgl. Quellenangaben [5]). Zum Aufbau dieser Datensammlung wird meist ein relationales Datenbankmanagementsystem (RDBMS) verwendet. Darin werden ausgewählte Daten aus verschiedenen Quellen gesammelt, integriert und über einen längeren Zeitraum gespeichert, damit zeitliche Analysen möglich werden. Dieses Kapitel widmet sich der Frage, mit welchen Mitteln Daten aus anderen Systemen in eine Oracle-Datenbank geladen werden können. Dabei wird davon ausgegangen, dass im ersten Schritt der reine Abzug von Quelldaten in eine Stage durchgeführt wird, ohne dabei bereits nennenswerte Transformationen auszuführen. Die folgende Tabelle stellt einige weit verbreitete Möglichkeiten vor. Methode Datenbanklink External Table SQL Loader Transportable Tablespace Change Data Capture SQL Loader & External Tables Anwendungsfälle Abzug von Daten aus anderen Oracle Datenbanken; Bei Verwendung eines Transparent Gateways können auch andere Datenbanken, ggf. unter Verwendung eines ODBC-Treibers, per DB- Link angebunden werden. Direkter Zugriff in Form einer virtuellen Tabelle auf strukturierte Dateien (CSV) in einem vordefinierten, für die Datenbank erreichbaren Verzeichnis Laden von strukturierten Dateien (CSV) Import von Tablespaces Automatisierte Protokollierung von Änderungen in Tabellen in einer Oracle Datenbank und Überführung der geänderten Daten in sogenannte Change Tables in der gleichen oder einer anderen Oracle Datenbank; Die Daten werden aus den Change Tables entfernt, wenn die sogenannten Subscriber diese nicht mehr benötigen und freigeben External Tables und der SQL Loader sind eng miteinander verknüpft. Der SQL Loader ist ein externes Programm, mit dem CSV-Dateien in eine Tabelle geladen werden können. Eine sogenanntes Control File steuert, wie die CSV-Datei interpretiert werden soll. Darin kann neben der zu beladenden Zieltabelle und den relevanten Spalten konfiguriert werden, wie in der CSV -Datei die Einzelwerte voneinander abgegrenzt sind. Üblicherweise kennzeichnet der Zeilenumbruch einen neuen Eintrag, während die Spalteninhalte durch ein Trennzeichen getrennt werden. Bei Bedarf kann eine definierte Anzahl von Zeilen zu Beginn der CSV-Datei übersprungen werden, weil diese zum Beispiel Überschriften enthalten. Das Control File selbst kann neben weiteren Parametern als Command Line Parameter übergeben werden. Mit der Angabe direct=true können die Daten performant über den direkten Pfad in die Zieltabelle geladen werden. Der SQL Loader kann von einem Clientrechner aus ausgeführt werden und von dort aus zugreifbare CSV-Dateien in die Datenbank laden. Zur Veranschaulichung des Vorgehens nachfolgend ein kurzes Beispiel: 1. Anlegen eines Control File (sh_sales.ctl) LOAD DATA INFILE sh_sales.dat APPEND INTO TABLE sales FIELDS TERMINATED BY " " (PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD) 2. Ausführen des SQL Loaders auf der Kommandozeile sqlldr control=sh_sales.ctl direct=true External Tables sind virtuelle Tabellen, mit deren Hilfe ein direkter Zugriff auf eine CSV-Datei seitens der Datenbank möglich wird. Für den Anwender ist transparent, ob es sich um eine gewöhnliche Tabelle oder eine externe Tabelle handelt. Das Auslesen der Daten ist dabei mit einer beliebigen SQL-Abfrage möglich, wodurch ein Staging der Daten unter Umständen überflüssig wird. Die Daten müssen demnach nicht in einem zusätzlichen Prozessschritt in die Datenbank geladen werden, sondern können direkt aus der Datei extrahiert und verarbeitet werden. DML-Statements können auf externen Tabellen allerdings nicht abgesetzt werden. Meist basieren External Tables auf dem Oracle Loader. Die Definition der Zugriffsparameter erfolgt in diesem Fall analog zum SQL Loader. Auch External Tables bieten die Möglichkeit zu Direct-Path-Operationen, wie das Beispiel auf der folgenden Seite aus dem DWH-Guide von Oracle (vgl. [1]) zeigt. Insbesondere bei wiederholtem Auslesen aus einer stets gleich geformten Datei ist der Einsatz einer External Table sinnvoll und gegebenenfalls dem SQL Loader vorzuziehen, da die External Table in diesem Fall als Datenbankobjekt unverändert bleiben und in einen ETL-Prozess wie eine gewöhnliche Tabelle eingebunden werden kann. OPITZ CONSULTING Deutschland GmbH 2015 Seite 3

4 CREATE TABLE sales_transactions_ext ( PROD_ID NUMBER, CUST_ID NUMBER, TIME_ID DATE, CHANNEL_ID NUMBER, PROMO_ID NUMBER, QUANTITY_SOLD NUMBER, AMOUNT_SOLD NUMBER(10,2), UNIT_COST NUMBER(10,2), UNIT_PRICE NUMBER(10,2) ) ORGANIZATION EXTERNAL ( TYPE oracle_loader DEFAULT DIRECTORY data_file_dir ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE CHARACTERSET US7ASCII BADFILE log_file_dir:'sh_sales.bad_xt' LOGFILE log_file_dir:'sh_sales.log_xt' FIELDS TERMINATED BY " " LDRTRIM ( PROD_ID, CUST_ID, TIME_ID DATE(10) "YYYY- MM-DD", CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, UNIT_COST, UNIT_PRICE ) ) LOCATION ('sh_sales.dat') )REJECT LIMIT UNLIMITED; INSERT /*+ APPEND */ INTO COSTS (TIME_ID, PROD_ID, UNIT_COST, UNIT_PRICE) SELECT TIME_ID, PROD_ID, AVG(UNIT_COST), AVG (AMOUNT_SOLD/QUANTITY_SOLD) FROM sales_transactions_ext GROUP BY TIME_ID, PROD_ID; =true Die CSV-Datei muss allerdings bei External Tables in einem Serververzeichnis liegen und über ein Directory-Objekt erreichbar sein. Im Falle von unterschiedlichen Satzarten innerhalb einer Datei ist dagegen eher der SQL Loader als Mittel zu wählen. Dieser muss die Datei in diesem Fall nur einmal lesen und kann die Datensätze abhängig von der Satzart in unterschiedliche Tabellen einfügen. Eine External Table hat hingegen eine vorgegebene Struktur, die jeweils nur die dazu passenden Datensätze verarbeiten kann. Daher ist pro Satzart eine eigene External Table erforderlich, bei der jeder Lesezugriff mit dem Lesen der kompletten Datei einhergeht. External Tables können statt über den Oracle Loader über das sogenannte ORACLE_DATAPUMP auf die Dateien zugreifen. Damit können External Tables auch zum performanten und parallelisierten Export von Daten in eine Datei genutzt werden. Die resultierende Datei ist in diesem Fall allerdings nicht lesbar, da sie in einem Oracle-internen Format gespeichert wird. Der Import solcher Dateien kann erneut über External Tables durchgeführt werden. Change Data Capture Change Data Capture dient der Erkennung von Änderungen in definierten Quelltabellen. Diese Änderungen werden in Change Tables protokolliert. Change Tables werden geschachtelt in Change Set und unter Umständen Change Source. Dieser Part obliegt in jedem Fall einem Datenbankadministrator in der Rolle des Publishers. Dazu kommt die Vergabe von Zugriffsrechten für sogenannte Subscriber, was auf Ebene einzelner Spalten erfolgen kann. Änderungen an den Quelltabellen werden je nach angewandtem Typ von Change Data Capture mit geringer Latenzzeit in die Change Tables überführt. OPITZ CONSULTING Deutschland GmbH 2015 Seite 4

5 Die Subscriber melden mit ihrer Subscription Bedarf an den Change-Daten an. Der Zugriff auf die Change-Daten erfolgt daraufhin über Views. Diese weisen initial jedoch eine leere Ergebnismenge auf. Erst durch Aufruf der Prozedur EXTEND_WINDOW aus dem Package DBMS_CDC_SUBSCRIBE verschaffen sich die Subscriber Zugriff auf die aktuellen Change-Daten. Ruft der Subscriber nach der Verarbeitung der Change-Daten die Prozedur PURGE_WINDOW aus dem gleichen Package auf, sind diese im Anschluss für ihn nicht mehr sichtbar. Physisch werden sie aber erst gelöscht, wenn alle Subscriber mit Aufruf der Prozedur PURGE_WINDOW anzeigt haben, dass sie die Change-Daten nicht mehr benötigen. Change Data Capture kann in verschiedenen Modi betrieben werden: Synchronous Asynchronous HotLog Asynchronous Distributed HotLog Asynchronous AutoLog Synchrones Change Data Capture arbeitet triggerbasiert und belastet damit das Quellsystem, was in vielen Fällen vermieden werden sollte. Außerdem arbeiten die Trigger zeilenbasiert, sodass Direct Path Operationen nicht erkannt und in den Change Tables nachgespielt werden können. Synchrones Change Data Capture überführt die Datenänderungen noch in der gleichen Transaktion in die Change Tables. Dies bietet in Bezug auf die Latenzzeit Vorteile, ist aber auf der anderen Seite kritisch zu bewerten, da die eigentliche Datenänderung erst dann erfolgreich abgeschlossen werden kann, wenn auch die Änderungen fehlerfrei in die Change Tables übertragen werden konnten. Dies kann ein System nicht nur ausbremsen, sondern im Falle von Fehlern sogar gänzlich blockieren und die schnelle Intervention eines Administrators erfordern. Als positiv zu bewerten ist des Weiteren, dass für synchrones Change Data Capture keine zusätzlichen Lizenzkosten anfallen. Die asynchronen Modi setzen auf den Redo- bzw. Archive-Logs der Quelldatenbank auf. Dadurch können auch nach dem Abschluss einer Transaktion die darin durchgeführten Änderungen ermittelt werden. Auch Direct Path-Operationen werden zuverlässig in die Change Tables überführt. Die asynchronen Modi unterscheiden sich wie folgt: HotLog erzeugt Change Tables in der Quelldatenbank. Distributed HotLog wertet die Redo-Logs in der Quelldatenbank aus und schreibt die Change- Daten in eine andere, sogenannte Staging-Datenbank. AutoLog kann in zwei unterschiedlichen Varianten betrieben werden. AutoLog Online schreibt Redodaten gleichzeitig in die Quell- und die Staging-Datenbank. AutoLog-Archive basiert auf den Archive-Logs. Diese werden in die Staging -Datenbank kopiert, sobald Redo-Logs archiviert werden, weil diese voll sind oder die Archivierung über ALTER SYSTEM SWITCH LOGFILE erzwungen wurde. Damit ist eine erhöhte Verzögerung zwischen der Änderung und der Veröffentlichung der Change-Daten gegeben. Modus Systemkonfiguration Protokollmechanismus Synchron Asynchrones HotLog Asynchrones Distributed HotLog Asynchrones AutoLog Online Asynchrones AutoLog Archive Change Tables in der gleichen Datenbank Change Tables in der gleichen Datenbank Change Tables liegen in einer Remote-Datenbank; Unterschiede bei Hardware, OS und Datenbankrelease zulässig Change Tables liegen in einer Remote-Datenbank; Hardware, OS und Datenbankrelease müssen übereinstimmen Change Tables liegen in einer Remote-Datenbank; Hardware, OS und Datenbankrelease müssen übereinstimmen Triggerbasierte Protokollierung in der gleichen Transaktion Protokollierung mittels Online- Redo-Log; Aktualisierung der Change Tables nach Abschluss jeder Transaktion Protokollierung mittels Online- Redo-Log; Aktualisierung der Change Tables nach Abschluss jeder Transaktion in der Zieldatenbank Protokollierung mittels Standby- Redo-Logs; Aktualisierung der Change Tables nach Abschluss einer Transaktion in der Zieldatenbank Protokollierung mittels archivierter Redo-Logs; Aktualisierung der Change Tables nach Übertragung der archivierten Redo-Logs zur Zieldatenbank Performanceauswirkung auf das Quellsystem Erhöhte Rechenlast in der Quelldatenbank Erhöhte Rechenlast in der Quelldatenbank durch umfangreicheres Logging im Redo-Log und insbesondere durch Extraktion der Änderungen aus dem Redo-Log in die Change Tables Leicht erhöhte Rechenlast durch umfangreicheres Logging im Redo- Log und durch zusätzliche Auswertung des Redo-Logs Minimal erhöhte Rechenlast durch umfangreicheres Logging im Redo- Log und durch den Transport der Logs zum Zielsystem Minimal erhöhte Rechenlast durch umfangreicheres Logging im Redo- Log und durch den Transport der Logs zum Zielsystem OPITZ CONSULTING Deutschland GmbH 2015 Seite 5

6 Bei den anderen asynchronen Modi werden die Änderungen nach jeder abgeschlossenen Transaktion in den Change Tables protokolliert. Alle asynchronen Modi können naturgemäß Operationen, die mit NOLOGGING arbeiten, nicht in die Change Tables überführen. Abschließend betrachtet haben alle Modi Vor- und Nachteile, die in der folgenden Tabelle (vgl. [1]) übersichtlich dargestellt werden. Eine weitere Möglichkeit für Change Data Capture stellt Oracle über sein Produkt GoldenGate zur Verfügung. Dies ist ebenfalls kostenpflichtig, bietet aber auch in heterogenen Systemlandschaften die Möglichkeit, Änderungen in Realzeit von einer Quelldatenbank in eine Staging-Datenbank zu kopieren. Für weitere Informationen zu diesem Produkt sei auf Quellenangabe [6] verwiesen. Export und Import Zum Datentransport können die Tools exp und imp verwendet werden. Mittels exp werden die Tabellenstruktur und, sofern nicht in Form eines Parameters unterbunden, die Tabelleninhalte exportiert. Die resultierende Datei hat ein nicht lesbares Format. Das Tool imp versucht, die exportierten Tabellen mitsamt Daten anzulegen. Auch hier kann der Datenimport durch einen Parameter ausgeschlossen werden. Existiert eine importierte Tabelle bereits, können mit ignore=y Fehler beim Anlegen der Tabelle übergangen werden und auf diese Weise nur die Daten, nicht aber die Tabellenstruktur importiert werden. Beide Programme sollten nicht mehr verwendet werden, da Oracle sie nur noch zum Erhalt der Rückwärtskompatibilität herausgibt. Sie werden vollständig ersetzt und erweitert durch das sogenannte Export Data Pump bzw. Import Data Pump. Export Data Pump (expdp) und Import Data Pump (impdp) zeichnen sich im Vergleich zu exp und imp durch größere Performance, Skalierbarkeit und Parallelisierbarkeit aus. Die Tools stellen vier unterschiedliche Methoden für den Ex- und Import zur Verfügung, wobei automatisch die performanteste Methode gewählt wird. Die Methoden, sortiert nach absteigender Performance, sind: Direkte Kopie eines Datafiles Direct Path Operationen External Tables Import über einen Netzwerklink Der Job des Ex- bzw. Imports wird in einer Mastertabelle überwacht. Damit sind sie gewöhnlich nach einem Abbruch resümierbar. Der Import direkt über das Netzwerk entspricht dem Absetzen eines INSERT INTO SELECT Statement. Beim Start von expdp und impdp kann über den Parameter CONTENT eine Auswahl getroffen werden, ob nur Metadaten (Tabellenstruktur), nur Daten (Tabelleninhalte) oder beide geladen werden sollen. Seit Version 11g der Datenbank kann zudem mit Hilfe des Parameters COMPRESSION gesteuert werden, ob Metadaten und/oder Dateninhalte komprimiert werden sollen. Auf diese Weise lässt sich der Speicherbedarf von Dump-Dateien deutlich reduzieren. Beim Aufruf über die Kommandozeile greifen Datapump-Export und - Import auf die Funktionalitäten der PL/SQL-Packages DBMS_DATAPUMP und DBMS_METADATA zurück. Es ist daher nicht überraschend, dass Export und Import bei Bedarf auch ausschließlich mit Hilfe von Prozeduraufrufen in DBMS_DATAPUMP bewerkstelligt werden können. Transportable Tablespace Ein Tablespace ist ein Container für die physikalische Speicherung von Daten und besteht aus einem oder mehreren Datafiles, während ein Datafile umgekehrt nur einem Tablespace zugeordnet sein kann. Dank des Transportable Tablespace Features ist die zügige Überführung eines kompletten Tablespace in eine andere Datenbank möglich. Sowohl der Export von Daten aus dem Quellsystem als auch das Laden der Daten in das Zielsystem werden durch dieses Feature obsolet. Der Transport der Daten beschränkt sich auf eine Kopie von Dateien innerhalb des Dateisystems bzw. über das Netzwerk. Voraussetzung hierfür ist allerdings, dass beide beteiligten Oracle- Datenbanken den gleichen Zeichensatz verwenden. Ältere Datenbankversionen unterliegen weiteren Einschränkungen. Um einen Tablespace von einer Datenbank in eine andere zu befördern, müssen folgende Schritte durchgeführt werden: 1. Der Quell-Tablespace wird read-only gesetzt ALTER TABLESPACE ts_temp_sales READ ONLY; 2. Die Metadaten der enthaltenen Tabellen werden exportiert expdp user/passwd DIRECTORY=dir DUMPFILE=tts.dmp TRANSPORT_TABLESPACES=ts_temp_sales 3. Datafiles und Metadatenexport werden zum Zielsystem kopiert 4. Im Quellystem kann der Tablespace bei Bedarf auf read-write gesetzt werden 5. Die exportierten Metadaten werden nun importiert impdp user/passwd DIRECTORY=dir2 DUMPFILE=tts.dmp TRANSPORT_DATAFILES=('/dbdir/users01.dbf') OPITZ CONSULTING Deutschland GmbH 2015 Seite 6

7 Multitable Insert Mit diesem Feature können zur gleichen Zeit mit einem einzigen DML- Statement mehrere Tabellen beladen werden. Der Vorteil bei diesem Vorgehen liegt insbesondere darin, dass beim Absetzen eines INSERT SELECT Statements die Abfrage nur ein einziges Mal ausgeführt werden muss. Daher sollten Multitable Inserts immer dann verwendet werden, wenn sich die Bewirtschaftung mehrerer Tabellen mit einer Abfrage abdecken lässt. Bei Verwendung des Oracle Warehouse Builders zur Modellierung der ETL- Strecke kann von diesem Feature ebenfalls Gebrauch gemacht werden, indem innerhalb eines Mappings mehrere Tabellen befüllt werden. Der Oracle Warehouse Builder generiert daraus im Set Based Modus automatisch ein Multitable Insert. Je nach Bedarf können die Abfrageergebnisse dann in keine, eine oder mehrere Tabellen geschrieben werden, wobei Bedingungen definiert werden können, unter welchen Umständen welche Tabellen als Ziel dienen sollen. Das Beispiel auf der linken Seite erleichtert das Verständnis. Mit dem Schlüsselwort FIRST zu Beginn des Statements wird sichergestellt, dass jeder Datensatz in höchstens eine Tabelle geschrieben wird, nämlich gerade in die Tabelle, bei der erstmalig die angegebene Bedingung erfüllt ist. Bei Verwendung des alternativen Schlüsselworts ALL wird das Schreiben einzelner Datensätze in mehrere Tabellen ermöglicht, sofern der Datensatz mehr als eine der angegebenen Bedingungen erfüllt. INSERT FIRST WHEN (sum_quantity_sold > 10 AND prod_weight_class < 5) AND sum_quantity_sold >= 1 OR (sum_quantity_sold > 5 AND prod_weight_class > 5) THEN INTO large_freight_shipping VALUES (time_id, cust_id, prod_id, prod_weight_class, sum_quantity_sold) WHEN sum_amount_sold > 1000 AND sum_quantity_sold >= 1 THEN INTO VALUES express_shipping (time_id, cust_id, prod_id, prod_weight_class, sum_amount_sold, sum_quantity_sold) WHEN (sum_quantity_sold >= 1) THEN INTO default_shipping VALUES (time_id, cust_id, prod_id, sum_quantity_sold) ELSE INTO incorrect_sales_order VALUES SELECT (time_id, cust_id, prod_id) s.time_id, s.cust_id, s.prod_id, p.prod_weight_class, SUM (amount_sold) AS sum_amount_sold, SUM (quantity_sold) AS sum_quantity_sold FROM sales s, products p WHERE s.prod_id = p.prod_id AND s.time_id = TRUNC (SYSDATE) GROUP BY s.time_id, s.cust_id, s.prod_id, p.prod_weight_class; Table Functions Table Functions zeichnen sich im Vergleich zu herkömmlichen Funktionen dadurch aus, dass sie Collections zurückliefern. Diese können unter Zuhilfenahme des Schlüsselworts TABLE wie eine gewöhnliche Tabelle abgefragt werden. Dadurch werden beispielsweise die zusätzliche Verwendung von Java-Abfragen möglich, die alle Dateien in einem Verzeichnis auf dem Server zurückliefern. Aber auch die Verwendung innerhalb eines ETL-Prozesses ist ein legitimer Anwendungsfall, wenn während eines Prozessschritts keine Speicherung der Zwischenergebnisse erfolgen soll und gleichzeitig spezifische PL/SQL- Operationen, wie beispielsweise das gezielte Logging von Informationen in einer Datei, das Durchlaufen von Schleifen oder der Versand einer durchgeführt werden sollen. Als Eingabe werden neben skalaren Werten auch Cursors akzeptiert. Auf diese Weise können Table Functions komplexe, prozedurale Vorgänge auf einem Satz von Zeilen abbilden und einen Satz von Zeilen zurückliefern, ohne diese Zeilen zwischenzeitlich in einer Tabelle zu speichern. Mit dem Schlüsselwort PIPELINED können einzelne Zeilen noch vor der Berechnung der kompletten Collection zurückgeliefert werden. Dies kann sich positiv auf die Ausführungsdauer auswirken. Für ein besseres Verständnis siehe das Beispiel auf der folgenden Seite, in dem an Hand eines Trennzeichens eine Zeichenkette in einzelne Token zerteilt und anschließend wie eine Tabelle gehandhabt wird. OPITZ CONSULTING Deutschland GmbH 2015 Seite 7

8 CREATE OR REPLACE FUNCTION f_zerteile_string (p_string IN VARCHAR2, p_trennzeichen IN VARCHAR2) RETURN SYS.odcivarchar2list --table of varchar2 PIPELINED --inkrementelle Rückgabe IS lv_start PLS_INTEGER := 1; lv_ende PLS_INTEGER; BEGIN LOOP --Position des nächsten --Trennzeichens ermitteln lv_ende := INSTR (p_string, p_trennzeichen, lv_start); --Rückgabe eines einzelnen Tokens --als "Zeile" PIPE ROW (SUBSTR ( p_string, lv_start, CASE lv_ende WHEN 0 THEN LENGTH (p_string) + 1 ELSE lv_ende END - lv_start)); EXIT WHEN lv_ende = 0; lv_start := lv_ende + 1; END LOOP; RETURN; --Abschluss der Funktion END f_zerteile_string; / --Aufruf der Funktion wie bei einer Tabelle SELECT COUNT ( * ) FROM TABLE ( f_zerteile_string ('Die Anzahl der Wörter beträgt sechs', ' ') ); Physikalische Datenspeicherung Compression Compression wird zur Komprimierung von Tabellen und Indizes genutzt. Dadurch kann eine Reduzierung der Hardwareanforderungen für Storage, Netzwerkbandbreite und RAM erzielt werden, was in einer Kostenersparnis münden und zugleich unter Umständen die Abfrageperformance steigern kann. Die Komprimierung wird bei Tabellen auf Basis der Datenblöcke durchgeführt. Dabei werden in einem Header auftretende Inhalte gesammelt. In den eigentlichen Datenblöcken wird daraufhin nur noch eine Referenz auf den Eintrag im Header gespeichert. Folglich kann eine besonders hohe Komprimierungsrate erreicht werden, wenn sich in einem Block Werte häufig wiederholen. Um diesen Effekt noch zu verstärken, bietet sich die Wahl einer großen Blockgröße an. In der Praxis lässt sich oft ein Komprimierungsfaktor zwischen zwei und drei erzielen. Bei Compression muss zwischen zwei Varianten unterschieden werden: Basic Compression Die Basic Compression wurde mit der Datenbank in Version 9i eingeführt und ist in der Enterprise Edition enthalten. Die Komprimierung wird nur bei Bulk Operationen angewandt, was zu einer leicht erhöhten Prozessorlast führt. Da häufig nicht die Prozessorleistung, sondern der Datendurchsatz den begrenzenden Faktor bei einer Bewirtschaftung darstellt, können durch Komprimierung in den meisten Fällen sogar kürzere Antwortzeiten und eine schnellere Datenverarbeitung erwirkt werden. Lediglich im Falle umfangreicher Datenaktualisierung wirkt sich die Komprimierung negativ auf die Performance aus. Persistent gespeicherte Daten belegen immer physischen Speicherplatz. Der Umfang des belegten Speichers sowie der erzielte Datendurchsatz sind hingegen von vielerlei Faktoren abhängig. Die Auseinandersetzung mit vielen dieser Faktoren obliegt in den meisten Fällen einem Administrator und gehört daher nicht zum Fokus dieses Artikels. Fragestellungen wie das Sizing von Blöcken und Tablespaces und die Verwendung von Compression ragen schon wesentlich weiter in den Zuständigkeitsbereich eines Entwicklers oder Architekten. Daher wird im folgenden Abschnitt mit der Komprimierung auf einen wichtigen Aspekt in Bezug auf die physikalische Datenspeicherung eingegangen. Advanced Compression Mit der Datenbankversion 11g wurde eine weitere Komprimierungsvariante eingeführt, die die Komprimierung auf OLTP-Systeme mit vielen kleinen Änderungen über den konventionellen Pfad erweitert. Da die sofortige Komprimierung der Daten in diesem Fall zu deutlichen Performanceeinbußen führen würde, werden einzelne Änderungen zunächst unkomprimiert durchgeführt. Ab einem definierten Füllgrad des Datenbankblocks führt ein interner Prozess in regelmäßigen Abständen die Komprimierung des Blocks durch. Um die OLTP Compression anwenden zu dürfen, muss die Advanced- Compression-Option lizenziert werden. Diese Option ermöglicht zudem die Komprimierung und gegebenenfalls Deduplizierung von Dateien, die als LOB in der Datenbank gespeichert werden. OPITZ CONSULTING Deutschland GmbH 2015 Seite 8

9 Abschließend sei noch einmal erwähnt, dass Export Data Pump neuerdings ebenfalls die Komprimierung der Dumpdateien erlaubt. Dies kann über den Parameter COMPRESSION={ALL DATA_ONLY METADATA_ONLY NO- NE} festgelegt werden. Und auch beim Backup mittels RMAN muss auf die Komprimierung nicht verzichtet werden. Features zur Herstellung guter Datenqualität Datenqualität spielt bei fast jeder Verarbeitung von Daten eine Rolle. Aus unvollständigen oder fehlerhaften Daten können keine oder schlimmstenfalls sogar falsche Rückschlüsse gezogen werden, aus denen dann wiederum unpassende Maßnahmen abgeleitet werden. So fallen unter Umständen sehr schnell immense Kosten an direkt oder indirekt (z. B. durch Imageschäden). Dies erklärt, warum viele Unternehmen einen großen Teil ihres IT-Budgets in die Optimierung der Datenqualität investieren. Viele Datenfehler lassen sich nur mit Kenntnis komplexer Geschäftsprozesse und -regeln aufdecken. Andere wiederum lassen sich einfach identifizieren und können durch einfache Datenbankmittel unterbunden werden. Im Folgenden wird eine Auswahl dieser Mittel näher erläutert. Constraints Constraints sind keine eigenständigen Objekte. Sie gehören, abgesehen von wenigen Ausnahmen, zu einer Tabelle und gewährleisten die Integrität der Tabelleninhalte. Sie können sicherstellen, dass Spalten nicht leer sind (NOT NULL Constraint) Werte innerhalb einer Spalte oder Wertkombinationen über mehrere Spalten eindeutig sind (UNIQUE oder PRIMARY KEY) alle Werte einer Spalte in einer Spalte einer anderen Tabelle vorhanden sind (FOREIGN KEY) definierte Bedingungen erfüllt sind (CHECK Constraint) Constraints können mit unterschiedlichen Status angelegt werden. Vier Status ergeben sich durch die Kombination der Schlüsselwörter ENABLE bzw. DISABLE und VALIDATE bzw. NOVALIDATE, die im Wesentlichen darüber entscheiden, ob die zum Zeitpunkt der Erstellung bereits vorliegenden Daten in Bezug auf den Constraint validiert werden sollen bzw. ob der Constraint für nachfolgende Datenmanipulationen aktiviert sein soll. sie nicht valide sind. Zu beachten ist dabei, dass der Parameter QUERY_REWRITE_INTEGRITY nicht auf ENFORCED gesetzt sein darf. RELY Constraints werden außerdem durch manche externe Tools interpretiert und können sogar für Views angelegt werden. Dimensions Dimensions sind in erster Linie in Zusammenhang mit Materialized Views von Bedeutung. Sie weiten insbesondere die Funktionalität von Query Rewrite aus und sollten daher in einem solchen Szenario mit besonderem Augenmerk betrachtet werden. Dimensions definieren hierarchische Datenbeziehungen zwischen Tabellenspalten innerhalb einer oder mehrerer relationaler Tabellen. Eine hierarchische Beziehung ist dadurch gekennzeichnet, dass jedes Element in der Hierarchie nur ein übergeordnetes Elternelement haben darf. Ein einleuchtendes Beispiel stellt die Zeitdimension dar, bei der jeder einzelne Tag nur einem Monat, jeder Monat nur einem Quartal und jedes Quartal nur einem Jahr zugeordnet sein darf. Eine alternative Hierarchie könnte durch Tag, Kalenderwoche und Jahr definiert werden. Die Verschmelzung beider Hierarchien ist hingegen nicht möglich, da eine Kalenderwoche nicht immer eindeutig einem Monat zugeordnet werden kann. Informationen wie der Wochentag können in einer Dimension als Attribut zu der Hierarchieebene Tag definiert werden. Dimensions können durch Aufruf von DBMS_DIMENSION.VALIDATE_DIMENSION validiert, aber nicht permanent und im Zuge jeder Änderung überwacht werden, wie es standardmäßig bei Constraints der Fall ist. Dimensions stellen lediglich Metainformationen dar und benötigen folglich keinen eigenen Speicherplatz. Die somit vorhandenen Metainformationen sind im DWH-Umfeld essentiell wichtig für Query Rewrite oder unter Umständen bei der Aktualisierung von Materialized Views. Es gilt allerdings zu beachten, dass Dimensions nur interpretiert werden, wenn QUERY_REWRITE_INTEGRITY auf TRUSTED oder STALE_TOLERATED gesetzt ist. Abseits der Materialized Views werden Dimensions von einigen BI-Tools ausgelesen, um Drilldown-Pfade zwischen unterschiedlichen Hierarchieebenen zu ermitteln. Eine weitere Eigenschaft eines Constraints wird mit dem Schlüsselwort RELY definiert. Auf diese Weise definierte Constraints können für die Query -Rewrite-Funktionalität bei Materialized Views genutzt werden, auch wenn OPITZ CONSULTING Deutschland GmbH 2015 Seite 9

10 Features zur Steigerung der Performance Theoretisch könnte ein DWH nur aus Tabellen und der Verarbeitungslogik zur Bewirtschaftung dieser Tabellen bestehen. Ohne weitere Objekte wie beispielsweise Indizes würden aber die Laufzeiten der Bewirtschaftungen und gerade auch der Abfragen durch Endanwender schnell Ausmaße annehmen, die einen akzeptablen Rahmen übersteigen. Daher hat Oracle eine ganze Palette von Features zur Steigerung der Performance in seine Datenbank integriert. Einige der Features sind für OLTPund Data-Warehouse-Systeme gleichermaßen von Bedeutung. In einem DWH stellen sich zum Teil aber auch andere Herausforderungen, da dort meist große Datenmengen in einem einzigen Batchlauf verarbeitet werden. Dieser muss häufig in einem definierten Zeitfenster abgeschlossen werden. OLTP-Systeme müssen im Gegensatz dazu in der Lage sein, viele kleinere Datenänderungen in kurzer Zeit zu verarbeiten. Die zunehmend in Mode kommenden Begriffe des Near- oder Realtime-DWH weichen diese Trennung allerdings auf, da in solchen Systemen binnen kurzer Zeit Änderungen in den Vorsystemen verarbeitet werden müssen. Diese Änderungen werden zum Beispiel mit Change Data Capture protokolliert und im DWH als Delta verarbeitet. echt größer ist als der Wert der Partitionsspalte und die mit dieser Eigenschaft die minimale Obergrenze im Vergleich zu den anderen Partitionen aufweist. Bei Bedarf kann eine weitere Partition angelegt werden, die alle Zeilen aufnimmt, deren Partitionspalte den Wert aller anderen Partitionsobergrenzen übersteigt. Diese Form der Partitionierung kommt in DWHs sehr häufig zum Einsatz. In den meisten Fällen repräsentiert die Partitionsspalte einen Zeitpunkt oder Zeitraum. Die Range-Partitionierung definiert auf dieser Basis zusammenhängende Zeiträume, die in einer Partition gebündelt werden. So könnte beispielsweise wie im folgenden Beispiel stets ein ganzer Monat einer Partition zugewiesen werden. Je nach Datenmenge und Verarbeitungslogik ist aber auch eine Partitionierung nach Tag, Kalenderwoche oder Jahr denkbar, wobei sogar unterschiedliche Intervallgrößen gewählt werden können. PARTITION BY RANGE (month_id) (PARTITION p_ VALUES LESS THAN (200802), PARTITION p_ VALUES LESS THAN (200803),, PARTITION p_mv VALUES LESS THAN (MAXVALUE) ) Partitionierung Partitionierung ist eine kostenpflichtige Datenbankoption, die im DWH- Umfeld sehr weit verbreitet ist. Sie bezeichnet die Speicherung einer logischen Tabelle in vielen physikalischen Tabellen, sogenannten Partitionen. Diese können gezielt ausgelesen oder mit DML- oder DDL-Statements verarbeitet werden. Das erleichtert die Verwaltung der Daten und sorgt bei größeren Datenmengen durch die Reduktion des I/O-Transfers für eine deutliche Steigerung der Performance. Die Partitionierung richtet sich nach einer konkreten Spalte der Tabelle. Abhängig von dem darin enthaltenen Wert entscheidet sich, in welcher Partition ein Datensatz abgelegt werden muss bzw. in welcher Partition ein Datensatz im Falle einer Abfrage zu suchen ist. Möglichkeit Nr.2: List-Partitionierung List-Partitionierung erlaubt die Vorgabe konkreter, fest definierter Werte für eine Partition. Hat die Partitionsspalte einen dieser Werte, so wird die zugehörige Zeile in dieser Partition gespeichert. Beispiel: PARTITION BY LIST (store_id) (PARTITION west VALUES (1,2),..., PARTITION other VALUES (DEFAULT)) Die Partitionierung kann auf drei unterschiedliche Weisen vorgegeben werden: Möglichkeit Nr.1: Range Partitionierung Range-Partitionierung definiert für jede Partition eine Obergrenze. Ein Datensatz wird immer genau in die Partition eingefügt, deren Obergrenze OPITZ CONSULTING Deutschland GmbH 2015 Seite 10

11 Möglichkeit Nr.3: Hash-Partitionierung Hash-Partitionierung führt die Partitionierung auf Basis eines Hash-Werts durch, der mit Hilfe eines internen Algorithmus für das Partitionsattribut berechnet wird. Welche Hash-Werte in welcher Partition gespeichert werden, ist für den Anwender nicht ersichtlich. Bei der Partitionierung einer Tabelle nach diesem Schema bleibt dem Anwender daher nur die Vorgabe des Partitionsattributs und der Partitionsanzahl, z. B.: PARTITION BY HASH (vertrag_id) PARTITIONS 4 Composite-Partitionierung Partitionen selbst können je nach Partitionsart selbst wieder partitioniert werden. Die dadurch entstehenden Partitionen heißen Subpartitionen. In diesem Fall spricht man von Composite-Partitionierung. Seit Datenbankversion 11g ist eine nahezu beliebige Kombination von Partitionierungsmethoden möglich. Lediglich die Subpartitionierung einer Hashpartitionierten Tabelle ist nicht möglich. Vorteile der Partitionierung Partitionierte Tabellen können vom Anwender wie gewöhnliche Tabellen gehandhabt werden. Die Anwendung der Partitionierung ist demnach für den Anwender transparent. Mit dem sogenannten Partition Pruning können Filterkriterien, die in einer Abfrage enthalten sind, gegebenenfalls so interpretiert werden, dass die Datenbank nicht die komplette Tabelle lesen muss, sondern sich gezielt auf das Auslesen relevanter Partitionen beschränken kann. Des Weiteren verbessert sich durch Partitionierung die Handhabbarkeit. Sollen zum Beispiel alle Daten einer Partition gelöscht werden, kann die Ausführung eines zeitintensiven DELETE-Statements durch das zügige Löschen oder Leeren der Partition ersetzt werden. Dieses Szenario ist gerade bei der Partitionierung über die Zeitachse gegeben, wenn veraltete Daten in regelmäßigen Zeitabständen gelöscht werden sollen. Zu beachten ist aber, dass die Ausführung von DROP/TRUNCATE PARTITION nicht rückgängig gemacht werden kann. Außerdem werden globale bzw. nicht partitionierte Indizes durch diese Aktion ungültig und müssen im Anschluss erneut aufgebaut werden. Daher macht es in den meisten Fällen Sinn, die Indizes mit dem Schlüsselwort LOCAL anzulegen und so eine identische Partitionierung von Index und Tabelle zu sichern. Die Logik für das Hinzufügen, Splitten, Zusammenführen, Löschen oder Leeren von Partitionen muss meist zu Beginn eines Projekts implementiert werden entsprechend der spezifischen Anforderungen. Mit dem im Datenbankrelease 11.2 eingeführten Interval-Partitioning kann die Partitionierung bei Zerteilung der Zeitachse in gleich große Intervalle automatisch durch die Datenbank fortgesetzt werden. In diesem Fall muss keine Eigenimplementierung angewandt werden. Partitionen können unterschiedliche physikalische Eigenschaften haben, z. B. in anderen Tablespaces abgelegt sein und auf diese Weise read-only gesetzt werden. Partitionen können einzeln gesichert werden. Partitionen können einzeln komprimiert werden. So können ältere Partitionen, die nur wenigen Änderungen ausgesetzt sind, komprimiert gespeichert werden, während neue Partitionen zur Vermeidung von Performanceeinbußen unkomprimiert gespeichert werden. Partitionen ermöglichen häufig eine effiziente parallele Verarbeitung disjunkter Datenmengen. Genauso können Hash- oder Merge-Joins von der Partitionierung profitieren, wenn diese partitionsweise arbeiten. In diesem Fall führt die Datenbank mehrere kleinere anstelle eines sehr großen Joins aus. So kann die Performance sowohl bei paralleler als auch bei serieller Verarbeitung gesteigert werden. Rentabel bei großen Objekten Partitionierung hat den Nachteil, dass bei jedem DML-Statement die Partitionierung berücksichtigt werden muss: So muss beim Einfügen eines neuen Datensatzes die zugehörige Partition ermittelt werden, bei einer Aktualisierung der Partitionierungsspalte die entsprechende Zeile gegebenenfalls in eine andere Partition verschoben werden oder bei gewöhnlichen Abfragen durch den Optimizer ermittelt werden, welche Partitionen benötigt werden, um daraufhin an den zugehörigen physikalischen Speicherorten die jeweiligen Zeilen auszulesen. Aufgrund des daraus resultierende Overheads rentiert sich Partitionierung nur bei großen Objekten. Partition Exchange Loading Partition Exchange Loading ist ein weiteres Feature, das erst durch die Partitionierung von Tabellen ermöglicht wird. Beim Partition Exchange Loading wird eine nicht partitionierte Tabelle als Partition in eine andere, partitionierte Tabelle eingehängt. Eventuell vorhandene Indizes können im gleichen Zuge übernommen werden. Mit diesem Vorgehen können Tabelleninhalte offline berechnet werden und anschließend ohne Rechenlast als Partition eingehängt werden. Bei diesem Schritt findet intern nur eine Aktualisierung des Dictionaries statt. Der sich daraus ergebende Vorteil ist die uneingeschränkte Verfügbarkeit der partitionierten Zieltabelle während der Berechnung der Daten. Andernfalls kann es zu Sperren kommen, die auf diese Weise umgangen werden können. Das Beispiel auf der nächsten Seite verdeutlicht die zugehörige Syntax. OPITZ CONSULTING Deutschland GmbH 2015 Seite 11

12 ALTER TABLE partitionierte_tabelle EXCHANGE PARTITION partition WITH TABLE tabelle INCLUDING INDEXES WITHOUT VALIDATION; Es ist zu beachten, dass NULL-Werte im Index nicht enthalten sind, weshalb die gezielte Abfrage nach NULL-Werten vom Index keinen Gebrauch machen kann. Voraussetzung für Partition Exchange Loading ist die vollständige Übereinstimmung der Spalten und Datentypen inklusive ihrer Länge sowie der Constraints beider Tabellen. Indizes Indizes dienen in erster Linie der Steigerung der Abfrageperformance und werden zu diesem Zweck häufig auf Join-Spalten, Sortierspalten und Filterspalten angelegt. Das Anlegen von Indizes als Universalrezept ist hingegen nicht adäquat, auch wenn dieses Denken in vielen Köpfen immer noch vorzuherrschen scheint. Sie verbrauchen Speicherplatz und verlängern die Laufzeiten bei Datenmodifikationen innerhalb der indizierten Tabelle unter Umständen drastisch. Daher sollten Indizes stets gezielt und mit Bedacht eingesetzt werden. Eine gute Möglichkeit zum Test der Auswirkungen eines Index ist seit Datenbankrelease 11gR1 durch sogenannte Invisible Indexes gegeben. Wird ein Index als unsichtbar gekennzeichnet, wird er in Abfragen nicht mehr in den Ausführungsplan eingebunden, solange dessen Verwendung nicht explizit per Hint erzwungen wird. Dieses Verhalten ermöglicht zudem die gezielte Verwendung von Indizes bei datenbankinternen Operationen, während externe Applikationen weiter so agieren, als gäbe es den entsprechenden Index nicht. Es gibt zwei Typen von Indizes, die sich grundlegend voneinander unterscheiden: B-Tree-Indizes B-Tree-Indizes sind bekannt und in DWHs und vor allem OLTP-Systemen weit verbreitet. Sie haben eine balancierte und sortierte Baumstruktur, die bei jeder DML-Operation aufrecht erhalten werden muss. Der Indexbaum besteht aus Datenblöcken, die entweder als Knoten oder als Blatt geartet sind. In den Knoten finden sich Verweise auf untergeordnete Knoten oder Blätter. In den Blättern befindet sich hingegen der jeweilige Wert der Indexspalte(n) zusammen mit der korrespondierenden Speicheradresse, der sogenannten ROWID. Über diese können einzelne Zeilen innerhalb der Tabelle äußerst rasch adressiert und ausgelesen werden. Bei einer Abfrage mit einem Filter auf eine indizierte Spalte wird bei Verwendung des Index die relevante Ergebnismenge im Index mittels Navigation durch den Baum vom Wurzelknoten bis hin zu den Blättern ermittelt und die Zeilen aus der Tabelle mithilfe der ROWID ausgelesen. Die Verwendung des Index ist nur bei Spalten mit hoher Selektivität von Vorteil, da andernfalls der Overhead für die Navigation durch den Baum und das anschließende Auslesen der Zeile mittels der ROWID die Dauer der Abfrage sogar eklatant in die Höhe treiben kann. Als Richtwert kann beim Auslesen von mehr als fünf Prozent der Tabellenzeilen davon ausgegangen werden, dass die Verwendung des B-Tree-Index kontraproduktiv ist. Eine weitere Funktion von B-Tree-Indizes ist die Unterstützung von Unique und Primary Keys. Ohne das Konzept dieses Index wäre eine zügige Erkennung, ob ein Wert bereits in einer Spalte vorhanden ist, nicht denkbar. Bitmap-Indizes Bitmap-Indizes haben eine grundlegend andere Struktur. Für jede Ausprägung in einer Spalte auch NULL speichert ein Bitmap-Index eine komprimierte Bitmap, die mit Nullen und Einsen für jede Zeile ausweist, ob die entsprechende Ausprägung darin enthalten ist. Die Komprimierung der Bitmap erfolgt so, dass bei längeren Blöcken mit anderen Werten, was einer Null in der Bitfolge entspricht, die Bitfolge unterbrochen wird und anstelle dessen gespeichert wird, wie viele Nullen in Folge auftreten (vgl. [7]). Im Normalfall verbrauchen Bitmap-Indizes daher nur einen Bruchteil des Speichers, den B-Tree-Indizes für sich in Anspruch nehmen. Bitmap-Indizes arbeiten am effektivsten, wenn sich Filterbedingungen über mehrere Spalten mit Bitmap-Indizes erstrecken. Die in diesem Fall erforderliche Verkettung von Bitmaps basiert auf logischen Bitoperationen und gehört damit zu den Operationen, die ein Prozessor höchst performant ausführen kann. Erst im Anschluss an diese Operation sind die Rückschlüsselung der Bitpositionen in ROWIDs und der anschließende Zugriff auf die Tabelle erforderlich. Werden mit der Abfrage nur Aggregatfunktionen über bitmapindizierte Spalten berechnet, kann sogar gänzlich auf den Tabellenzugriff verzichtet werden. Da Filterkriterien über mehrere Spalten derart effizient miteinander verknüpft werden können, werden Bitmap-Indizes normalerweise nicht über mehrere Spalten angelegt. Bitmap-Indizes versprechen im Gegensatz zum B-Tree-Index einen Vorteil, wenn die zugrundeliegende Spalte nicht besonders selektiv ist. Je kleiner das Verhältnis von Ausprägungen in einer Spalte zu der Gesamtzeilenanzahl, desto eher ist das Anlegen eines Bitmap-Indizes zu empfehlen. Als Richtwert, ab dem das Anlegen eines Bitmap-Index sinnvoll ist, gibt Oracle eine durchschnittliche Zeilenanzahl von 100 pro Ausprägung an (vgl. [1]). OPITZ CONSULTING Deutschland GmbH 2015 Seite 12

13 Des Weiteren empfiehlt Oracle die Verwendung der Klausel NOLOGGING COMPUTE STATISTICS beim Anlegen eines Bitmap-Index. Ein klassischer Kandidat für einen Bitmap-Index ist die Spalte Geschlecht. Diese zeichnet sich durch eine geringe Anzahl von Ausprägungen aus und hat des Weiteren den Vorteil, dass die Ausprägungen relativ gleichmäßig verteilt sind. Ein weiterer Aspekt, der bei Bitmap-Indizes beachtet werden muss, ist die Wartbarkeit bei DML-Operationen. Hier zeigt sich eine Schwäche dieses Indextyps. Es ist daher gängige Praxis, alle Bitmap-Indizes vor einer Bewirtschaftung zu löschen und im Anschluss erneut zu erstellen. Die Erstellung des Index geht im Allgemeinen relativ zügig vonstatten. Die Verwendung von Bitmap-Indizes macht auf Grund ihrer Eigenschaften gerade im DWH-Umfeld Sinn, da sich dort große Datenmengen, häufig in Ad-hoc-Abfragen gefiltert über einen Strauß von Kriterien, mit einer geringen Frequenz von DML-Operationen paaren. Bei Abfragen auf ein Star-Schema kann ferner die sogenannte Star- Transformation zur Anwendung kommen. Es handelt sich dabei um eine Methode, die sich im Ausführungsplan widerspiegelt und die auf der Verwendung von Bitmap-Indizes fußt. Voraussetzung hierfür ist die Existenz von Bitmap-Indizes auf den Fremdschlüsselspalten der Faktentabelle. Ist diese Voraussetzung erfüllt und wird dann eine Abfrage mit mehreren Filtern auf die angeschlossenen Dimensionen ausgeführt, so werden zunächst nur auf Basis der Dimensionen alle relevanten Ausprägungen der Fremdschlüsselspalten in der Faktentabelle ermittelt. Dadurch ergeben sich mehrere Filterbedingungen für die Faktentabelle, die unter Einsatz der Bitmap-Indizes durch logische Bitoperationen miteinander verknüpft werden. Aus der Faktentabelle muss im Anschluss nur der relevante Anteil geladen werden. Eine Erweiterung der Bitmap-Indizes stellen Bitmap-Join-Indizes dar. Bei dieser Variante wird bereits bei der Erstellung des Index der Join mit einer Fremdtabelle durchgeführt und die Bitmaps anhand des Wertes aus einer gewünschten Spalte der Fremdtabelle berechnet. Bei Abfragen auf die Tabelle mit Filterprädikaten auf die referenzierte Spalte der Fremdtabelle ergibt sich freilich ein Performancevorteil. Es sei darauf hingewiesen, dass Bitmap-Join-Indizes einer Reihe von Einschränkungen unterliegen, die vor der Entscheidung für diese Indexvariante beachtet werden müssen. Indizes auf partitionierten Tabellen Bei partitionierten Tabellen können B-Tree-Indizes entweder nicht partitioniert, global (andere Partitionierung als in der Tabelle) oder lokal (identische Partitionierung wie bei der Tabelle) angelegt werden. Bei Verwaltungsoperationen wie TRUNCATE/DROP PARTITION werden nicht-lokale Indizes invalid und müssen erneut aufgebaut werden. Daher ist in den meisten Fällen die Erstellung des Index mit dem Schlüsselwort LOCAL zweckmäßig. Ein nicht partitionierter Index kann nötig sein, wenn die Eindeutigkeit von Datensätzen über Partitionsgrenzen hinaus sichergestellt werden muss. Bei Bitmap-Indizes erübrigt sich die Frage nach einer eigenen Partitionierung. Diese Indizes müssen immer lokal angelegt werden, sodass Partitionierung von Index und zugrundeliegender Tabelle stets einander entsprechen. Materialized Views Materialized Views werden im DWH-Umfeld in erster Linie zur Performancesteigerung, in selteneren Fällen auch zu Replikationszwecken verwendet. Sie entsprechen einer View, deren Abfrageergebnisse persistent in einer Tabelle gespeichert werden. Damit können sie performant ohne die erneute Berechnung von enthaltenen Joins und Aggregationen abgefragt werden, verbrauchen aber Speicherplatz. Sie müssen aktualisiert werden, sobald sich Datenänderungen in den Quelltabellen auch Mastertabellen genannt ergeben und sich diese in der Materialized View widerspiegeln sollen. Aktualisierung einer Materialized View Materialized Views können auf unterschiedliche Art und Weise aktualisiert werden. Sie können so angelegt werden, dass sie sich selbst regelmäßig oder im Zuge jeder Datenmodifikation an einer der Mastertabellen beim Absetzen des Commit-Befehls aktualisieren. Verzichtet man bei der Erstellung einer Materialized View aber auf entsprechende Klauseln, muss die Aktualisierung der Materialized View per Prozeduraufruf initiiert werden. Es ist ferner zu unterscheiden zwischen verschiedenen Aktualisierungsmethoden: Beim COMPLETE-Refresh wird die Materialized View geleert und anschließend komplett neu berechnet. Beim FAST-Refresh wird hingegen ein inkrementelles Verfahren angewandt, das gezielt die Änderungen seit der letzten Aktualisierung in die Materialized View überführt. Die dafür nötige Protokollierung der Änderungen wird durch Materialized View Logs bewerkstelligt, die zuvor für jede relevante Mastertabelle angelegt werden müssen. Wie die Materialized View Logs angelegt werden müssen und welche Informationen sie protokollieren sollen, ist in erster Linie von der Abfrage der Materialized View abhängig. OPITZ CONSULTING Deutschland GmbH 2015 Seite 13

14 Mit der Prozedur EXPLAIN_MVIEW im Package DBMS_MVIEW wird dem Entwickler diesbezüglich eine effektive Hilfe an die Hand gegeben. Bei Existenz eines Materialized View Logs werden alle Änderungen an der Mastertabelle über den konventionellen Pfad im Materialized View Log protokolliert. Bei Direct-Path-Operationen auf den Mastertabellen wird anstelle dessen in der View ALL_SUMDELTA der neue Zeilenbereich in der Mastertabelle mittels zweier ROWIDs abgesteckt. Durch die einfache Möglichkeit, mittels Materialized View Logs Änderungen auf den Mastertabellen zu protokollieren, eignen sich Materialized Views unter anderem zu Replikationszwecken. In diesem Szenario wird meist eine exakte Kopie einer Tabelle in eine Remote-Datenbank repliziert. Die Replikation wiederum kann zur Reduktion der Netzwerklast, zur Steigerung der Verfügbarkeit, zur Sicherung oder zur Performancesteigerung seitens der Remote-Datenbank eingesetzt werden. Abfragen umzuformulieren. Damit kann es in Ausnahmefällen zu inkonsistenten Abfrageergebnissen kommen. Die Option STALE_TOLERATED lässt zusätzlich sogar die Verwendung von Materialized Views zu, die wissentlich nicht den aktuellen Stand der Mastertabellen repräsentieren. In der Konsequenz muss beurteilt werden, wie die Faktoren Abfrageperformance, Datenkonsistenz und Datenaktualität im Einzelfall gewichtet werden. Beim Einsatz von Materialized Views muss abgewägt werden, ob der erhöhte Speicherbedarf und der Aufwand zur Aktualisierung der Materialized Views mit der Optimierung der Abfrageperformance zu rechtfertigen ist. Häufig ausgeführte, womöglich sogar zeitkritische Abfragen auf Materialized View stellen ein klares Argument für ebenjene dar. Daher sind sie insbesondere bei intensiver Verwendung von Query Rewrite sinnvoll. Um die Zahl der Anwendungsfälle von Query Rewrite zu erhöhen, ist die umfangreiche Ausstattung von Mastertabellen mit Constraints und Dimensions anzustreben. Query Rewrite Ein weiteres Feature in Zusammenhang mit Materialized Views nennt sich Query Rewrite. Dank der Verknüpfung einer Abfrage mit der zugehörigen Ergebnismenge kann die Datenbank andere Abfragen auf die gleichen Mastertabellen direkt und transparent auf die Materialized View umleiten. Identifiziert ein Entwickler also eine Abfrage, deren Ergebnisse an anderer Stelle wiederverwendet werden können, so kann er diese Abfrage als Basis einer Materialized View verwenden und für diese das Feature Query Rewrite freischalten. Darauf aufbauende Applikationslogik verwendet, sofern der Optimizer es für sinnvoll erachtet, ohne weitere Anpassung die Materialized View und kann damit unter Umständen deutlich schneller Ergebnisse zurückliefern. Dank dieses Features können Materialized Views ähnlich wie ein Index gezielt zur Steigerung der Performance eingesetzt werden. Die Eignung einer Materialized View für Query Rewrite hängt in großem Maße vom Parameter QUERY_REWRITE_INTEGRITY ab. Dieser steuert mit seinen Ausprägungen ENFORCED, TRUSTED oder STALE_TOLERATED den Grad der Verwendung. Im ersten Fall werden nur Materialized Views genutzt, bei denen sichergestellt ist, dass das Umschreiben der Abfrage exakt zu den gleichen Ergebnissen führt. Bei der Option TRUSTED werden neben Constraints im Status VALIDATE auch Constraints im Status RELY sowie Dimensions ausgewertet, um die Online Analytical Processing (OLAP) OLAP ist eine Analysemethode, die dazu dienen soll, Hypothesen der Anwender zu stützen oder zu widerlegen. Anders als das Data-Mining sucht OLAP nicht nach Mustern zur Bewertung von Detaildatensätzen, sondern legt im Allgemeinen den Fokus auf die Auswertung aggregierter Daten. Die Kerneigenschaft von OLAP ist die Darbietung einer multidimensionalen konzeptionellen Sicht auf die Daten. Auf dieser Basis soll die intuitive Datenanalyse möglich sein, insbesondere mittels Rollup und Drilldown innerhalb der Dimensionshierarchien. Der Anwender darf dabei nicht durch lange Antwortzeiten ausgebremst werden. Seine Berichtsanforderungen müssen binnen kurzer Zeit bearbeitet werden. Zur Erfüllung der Anforderungen werden Daten häufig voraggregiert gespeichert. Des Weiteren wird vielfach auf eine eigene Speicherungsart der Daten zurückgegriffen. An dieser Stelle muss man zwischen den weit verbreiteten Varianten des relationalen (ROLAP) und multidimensionalen (MOLAP) OLAP unterscheiden, auch wenn OLAP und MOLAP häufig gleichgesetzt werden. Auch die Oracle Datenbank stellt OLAP-Funktionalität zur Verfügung. Zur Anwendung von MOLAP muss zuvor eine kostenpflichtige Datenbankoption erworben werden. Diese ermöglicht eine besonders schnelle Analyse der Daten durch die persistente Speicherung voraggregierter Kennzahlen in einem sogenannten Würfel. Der Würfel ist meist nach einem Starschema aufgebaut, mit einer zentralen Faktentabelle und den darum liegenden Dimensionstabellen. OPITZ CONSULTING Deutschland GmbH 2015 Seite 14

15 Mit Datenbankversion 11g hat Oracle das Konzept auf Materialized Views ausgeweitet. Diese werden als "cube-organized" Materialized Views bezeichnet und haben den Zweck, die Abfrageperformance zu steigern. Bei Gebrauch des Query-Rewrite-Features werden entsprechende Abfragen auf die Mastertabellen direkt zum Cube umgeleitet. Dies verschafft insbesondere externen Applikationen die Möglichkeit, mithilfe von gewöhnlichen, unveränderten SQL-Abfragen performant auf einen OLAP-Würfel zuzugreifen. Parallelisierung Parallelisierung bezeichnet die Aufteilung einer Datenbankoperation auf mehrere Threads. Zu unterscheiden ist zwischen zwei Varianten, die die Oracle Datenbank beide beherrscht: Bei Shared Nothing arbeitet jeder Thread mit einer eigenen, disjunkten Datenmenge. Die einzelnen Datenbereiche sind physisch zum Beispiel in Form von Partitionen voneinander getrennt. Auf der anderen Seite kann die komfortable Aktualisierung von Materialized Views auch für den zugrundeliegenden Cube verwendet werden. Die Aktualisierung kann automatisiert entweder sofort nach Änderungen, zyklisch oder ab einem definierten Grad der Abweichung von aktuellen Daten und Inhalten der Materialized View gestartet werden. Die Erstellung einer solchen "cube-organized" Materialized View geht wie folgt vonstatten: 1. Erstellung der zugehörigen Dimensionen 2. Erstellung der Materialized View nach gewohntem Schema declare mycubemv varchar2(32); begin mycubemv := dbms_cube.create_mview( mvowner =>user, mvname =>'sales_mon_ite_cit_cha_mv', sam_parameters=>'logdest=serverout,build=immediate' ); end; / 3. Aufruf der Prozedur DBMS_CUBE.CREATE_MVIEW unter Angabe des Namens der bereits erstellten Materialized View begin dbms_cube.refresh_mview (mvowner =>user,mvname =>'CB$SALES_MON_ITE_CIT_CHA'); end; / Im Gegensatz dazu besteht bei Shared Everything keine physikalische Trennung der Daten. Jeder Prozess kann theoretisch auf alle Daten zugreifen. Die Datenbank sorgt in diesem Fall intern für die Aufteilung der Daten. Diese kann auf Basis von Partitionen oder auf Basis der Datenblöcke erfolgen. Sofern die Möglichkeit besteht, nutzt die Datenbank die Vorteile von Shared Nothing (Beispiel: Parallele partitionsweise Joins). Mit dem Laden und Abfragen von Daten, RMAN Backups, dem Aufbau von Indizes und dem Erstellen von Statistiken können nahezu alle Datenbankoperationen parallelisiert werden. Die Parallelisierung von Abfragen kann über drei verschiedene Wege aktiviert werden: Parallele Verarbeitung von Tabellen ALTER TABLE sales PARALLEL; Parallel Hint in SQL-Statements SELECT /*+ parallel(s) */COUNT(*) FROM sales s; Parallele Verarbeitung innerhalb einer Session ALTER SESSION FORCE PARALLEL QUERY; Grundsätzlich sollte bei der Parallelisierung darauf geachtet werden, dass das System nicht überlastet wird. Parallele Ausführungen sind besonders I/O-lastig und stellen erhöhte Anforderungen an den Arbeitsspeicher. Mithilfe des Systemparameters PARALLEL_MAX_SERVERS kann daher eine Obergrenze für die Anzahl der parallel arbeitenden Prozesse definiert werden. Des Weiteren sollte der Grad der Parallelisierung (DOP) an der Anzahl der CPU-Kerne orientiert sein. Bei Verzicht auf die explizite Vorgabe des DOP wird dieser üblicherweise über die folgende Formel berechnet: 2 * (Anzahl der CPU-Kerne) * (Anzahl der Knoten des Clusters) 4. Bei Bedarf Aktualisierung der Materialized View Bei den meisten Abfragen werden sogenannte Producer ausgeführt, die auf unterer Ebene Berechnungen durchführen und damit Zwischenergebnisse produzieren. Diese werden von Consumern konsumiert und weiterverarbeitet. OPITZ CONSULTING Deutschland GmbH 2015 Seite 15

16 Kommen Producer und Consumer zum Einsatz, ergibt sich die Anzahl der parallelen Threads als der doppelte Wert des DOP. Die Standardeinstellung ist sinnvoll, wenn ein User alle Ressourcen beanspruchen darf. Andernfalls sollte eher ein kleinerer DOP gewählt werden. Bei entsprechenden Ressourcen kann sich die Ausführungsdauer linear mit dem DOP reduzieren. Generell sollte sich der DOP an der Größe der Tabellen orientieren. Kleine Tabellen mit weniger als 1000 Zeilen sollten niemals parallel angelegt werden, um damit keine Parallelprozesse zu belegen, die an anderer Stelle wesentlich effizienter genutzt würden. Es ist durchaus zweckmäßig, den DOP mit zunehmender Tabellengröße zu steigern. Features zur Aggregation Oft müssen Daten in unterschiedlicher Granularität aggregiert werden. So könnten beispielsweise die Verkäufe pro Monat auf der einen und pro Quartal oder Jahr auf der anderen Seite von Interesse sein. Beide Ergebnismengen könnten mithilfe zweier unterschiedlicher Abfragen unter Verwendung des UNION-ALL-Statements vereint werden. Die Datenbank stellt aber Funktionen zur Verfügung, die helfen, die vereinigte Ergebnismenge komfortabel mit einer einfachen Syntax innerhalb eines Statements zu berechnen. Die Anwendung dieser Funktionen ist im Bedarfsfall auch aus Performancegesichtspunkten zu empfehlen, zumal sich mit der Kombination der im Folgenden dargestellten Funktionen eine Fülle von Möglichkeiten bietet. Rollup In diesem Beispiel wäre die Spalte Monat identisch dem Wert NULL, sobald die Aggregationsebene (Jahr, Quartal, Monat) überschritten wird. Die anderen Attribute verhalten sich analog. Die ROLLUP-Funktion ist zwar häufig entlang von dimensionalen Hierarchiepfaden zu finden, grundsätzlich aber unabhängig davon einsetzbar. Cube Der Begriff Cube (Würfel) ist ebenfalls im OLAP-Umfeld bekannt. Die gleichnamige Funktion CUBE wird analog zu ROLLUP eingesetzt. Allerdings wird dabei jede mögliche Aggregationsebene der übergebenen Parameter berechnet. Daraus ergibt sich mit zunehmender Spaltenanzahl ein exponentielles Wachstum der Aggregationslevel. Daher sollten der Funktion zur Vermeidung unnötiger Rechenlast nur Spalten übergeben werden, die in sämtlichen Kombinationen von Belang sind. Zur Veranschaulichung abschließend folgendes Beispiel: SELECT t.jahr, t.monat, sum(s.revenue) FROM sales s JOIN d_zeit t on (s.tag_id = t.tag_id) GROUP BY CUBE(t.jahr, t.monat); Die Ergebnismenge beinhaltet die Aggregation auf den Ebenen (Jahr, Quartal, Monat) (Jahr) (Monat) () Grouping Sets Der Begriff Rollup ist als konträres Vorgehen zum Drilldown durch Dimensionshierarchien hinlänglich bekannt. Beim Rollup werden Detailergebnisse weiteraggregiert und auf übergeordneter Ebene dargestellt. Eine solche Funktionalität bietet auch die Funktion ROLLUP. Diese wird in die GROUP- BY-Klausel integriert. Das folgende Beispiel verdeutlicht die Anwendung: SELECT t.jahr, t.quartal, t.monat, SUM(s.revenue) FROM sales s JOIN d_zeit t ON (s.tag_id = t.tag_id) GROUP BY ROLLUP(t.jahr, t.quartal, t.monat); Mit Grouping Sets können gezielt gewünschte Aggregationsstufen vorgegeben werden. Auf diese Weise können anstelle der Berechnung aller Kombinationen mit CUBE nur diejenigen ausgewählt werden, die im jeweiligen SELECT t.jahr, t.quartal, t.monat, sum(s.revenue) FROM sales s JOIN d_zeit t on (s.tag_id = t.tag_id) GROUP BY GROUPING SETS ( t.jahr, (t.jahr, t.quartal, t.monat) ); Die Ergebnismenge beinhaltet die Aggregation auf den Ebenen (Jahr, Quartal, Monat) (Jahr, Quartal) (Jahr) () Anwendungsfall von Interesse sind. Im Beispiel: Die Ergebnismenge beinhaltet die Aggregation auf den Ebenen (Jahr, Quartal, Monat) (Jahr) OPITZ CONSULTING Deutschland GmbH 2015 Seite 16

17 Gruppierungsfunktionen Kommt in einer der Spalten innerhalb der GROUP-BY-Klausel ein NULL- Wert vor, kann die Unterscheidung zwischen NULL-Werten aus den Quelldaten und NULL-Werten, die durch die weitergehende Aggregation entstehen, sehr umständlich werden. Daher bietet die Datenbank Funktionen, die bei der Unterscheidung helfen. kann für jede Zeile beispielsweise ein Ranking bezüglich eines frei wählbaren Kriteriums berechnet und in einer zusätzlichen Spalte dargestellt werden. Die Anwendung der RANK-Funktion könnte folgendermaßen aussehen: SELECT m.*, RANK() OVER (PARTITION BY m.abteilung ORDER BY m.gehalt DESC NULLS LAST) FROM mitarbeiter m; Die Funktion GROUPING erwartet als Parameter eine Spalte aus der GROUP-BY-Klausel, in obigem Beispiel könnte dies die Spalte Quartal sein. Als Rückgabewert liefert die Funktion eine 1, wenn der Wert der Spalte wegen der Aggregation als NULL dargestellt wird. Dies ist für die Aggregation auf Jahresebene der Fall. In allen anderen Fällen ist ihr Rückgabewert 0. Die PARTITION-BY-Klausel gibt an, für welche Spalten die jeweils gleiche Kombination von Werten als eine Gruppe von Zeilen interpretiert wird. Diese Angabe ist vergleichbar mit der GROUP-BY-Klausel bei einer gewöhnlichen Aggregation und nicht zu verwechseln mit Partitionen in Zusammenhang mit der Partitionierung von Tabellen. Der weiteren Funktion GROUPING_ID kann hingegen ein Satz von Spalten aus der GROUP-BY-Klausel übergeben werden. Sie liefert für jeden Aggregationslevel bezüglich der übergebenen Spalten einen eindeutigen Wert zurück. Die nachfolgende Tabelle verdeutlicht dies am Beispiel der Funktion CUBE(a, b). Aggregationslevel Bitfolge GROUPING_ID(a, b) a, b 00 0 a 01 1 b Materialized Views enthalten häufig voraggregierte Daten und greifen dabei auch auf Funktionen wie ROLLUP oder GROUPING SETS zurück. Zur Kennzeichnung des Aggregationslevels wird in diesem Fall häufig die GROUPING_ID Funktion in die Abfrage der Materialized View aufgenommen. Dies erweitert die Möglichkeiten der Datenbank bei der Aktualisierung der Materialized View bzw. bei deren Verwendung in Zusammenhang mit Query Rewrite. Die Funktion GROUP_ID komplettiert die Riege dieser Hilfsfunktionen. Mit ihr können Dubletten auf Grund einer unglücklich gewählten GROUP-BY- Klausel durch einen Wert größer als Null in der Ergebnismenge kenntlich gemacht werden. Alle drei Hilfsfunktionen können sowohl in der Ergebnismenge dargestellt werden als auch in HAVING- oder ORDER-BY-Klausel Verwendung finden. Analytische Funktionen Analytische Funktionen ermöglichen die Berechnung von Ergebnissen auf Basis mehrerer Zeilen, dem sogenannten Fenster. Die Gesamtergebnismenge reduziert sich dabei aber, anders als bei Aggregatfunktionen, nicht. So Die ORDER-BY-Klausel definiert das Attribut, anhand dessen der Rang berechnet werden soll. In obigem Beispiel würde folglich für jede Abteilung der Rang der Mitarbeiter in Bezug auf ihr Gehalt bestimmt. Der Mitarbeiter mit dem größten Gehalt erhält Rang 1. Für andere analytische Funktionen kann explizit das Fenster angegeben werden, auf dessen Basis die Ergebnisse berechnet werden sollen. Dieses Fenster wird für jede Gruppe, bestimmt durch die PARTITION-BY-Klausel, von Neuem initialisiert. Das angegebene Fenster orientiert sich immer an der aktuellen Zeile. Seine Größe kann über die physikalische Anzahl von Zeilen oder ein logisches Intervall, z. B. über die Inhalte einer Spalte vom Datentyp DATE definiert werden. Die ORDER-BY-Klausel schreibt die Reihenfolge innerhalb eines Fensters vor. Mithilfe von Fensterfunktionen kann beispielsweise eine rollende Summe berechnet werden. SUM(amount_sold) OVER (PARTITION BY c.cust_id ORDER BY c.cust_id, t.calendar_quarter_desc ROWS BETWEEN UNBOUNDED PRECEDING --beginnend bei der ersten --Zeile der "CUST_ID-Partition" --bei gegebener Sortierung AND CURRENT ROW) --Fenster endet bei --aktueller Zeile Andere Beispiele stellen die Fensterfunktionen LAG und LEAD dar. Diese gewähren Einsicht in Zeilen, die auf Basis einer gewählten Sortierreihenfolge eine definierte Anzahl von Zeilen vor (LAG) bzw. nach (LEAD) der aktuellen Zeile liegen. Auf diese Weise ist ein direkter Vergleich unterschiedlicher Zeilen möglich, ohne zuvor einen Self-Join implementieren zu müssen. Dies spart nicht nur Implementierungsaufwand, sondern häufig auch Rechenlast. Der Aufruf der LAG-Funktion zum Auslesen der Verkaufsmenge des Vortags könnte wie folgt lauten: LAG(verkaufsmenge, 1) OVER (ORDER BY tag_id) OPITZ CONSULTING Deutschland GmbH 2015 Seite 17

18 Die Datenbank bietet darüber hinaus eine ganze Palette von analytischen Funktionen, deren Erwähnung den Rahmen dieses Artikels sprengen würde. Hinzu kommt, dass mit dem Oracle Data Cartridge Interface (ODCI) eigene Aggregatfunktionen entwickelt werden können, die sich auch als analytische Funktion nutzen lassen. Datensicherheit Datensicherheit ist im Zeitalter der elektronischen Datenverarbeitung in vielen Bereichen wichtig. Im DWH-Umfeld spielt Datensicherheit eine besonders große Rolle, weil viele aussagekräftige und sensible Daten von einer Vielzahl von Anwendern mit unterschiedlichen Rechten und unterschiedlichen Zielen interpretiert werden sollen. Unternehmen investieren daher große Summen in können Spalten angegeben werden, die als besonders sensibel zu werten sind und deren Abfrage nur durch autorisierte Benutzer zulässig ist. Nach Abschluss dieser Schritte werden Abfragen auf die jeweilige Tabelle durch die Datenbank intern und transparent umformuliert und um die Zeichenkette erweitert, die die Policy-Funktion zurückliefert. So werden die Tabelleninhalte gefiltert. Grafisch dargestellt könnte dies folgendermaßen aussehen: die Abschirmung von Daten vor unbefugtem Zugriff die Sicherung der Daten, damit diese nach einem partiellen oder sogar kompletten Datenverlust lückenlos wiederhergestellt werden können. Sicherung von Daten vor unbefugtem Zugriff Neben der normalen Vergabe von Rechten auf Objektebene, stellt Oracle weitere Funktionen zur Verfügung, die je nach angemeldetem Benutzer eine unterschiedliche Sicht auf die Daten ermöglichen. Virtual Private Database (VPD) Virtual Private Database ermöglicht eine sehr feingranulare Vergabe von Rechten, sodass unterschiedliche Benutzer eine andere Sicht auf das gleiche Tabellenobjekt erhalten können. Es können je nach Benutzer Filterkriterien, sogenannte Policies, definiert werden, die dazu führen, dass der eine Benutzer andere Zeilen und Spalten sieht als der nächste Benutzer. Diese Policies können ferner auf DML-Statements ausgeweitet werden, damit die Änderung von Datensätzen nur innerhalb eines definierten Datenbereichs erfolgen kann. Mittels einer Policy bzw. der Kombination mehrerer Policies lassen sich nahezu beliebig komplexe Zugriffsbeschränkungen anhand unterschiedlichster Geschäftsregeln definieren. Zur Anwendung von VPD müssen folgende Schritte ausgeführt werden: 1. Optional: Setzen eines Applikationskontexts mit Hilfe eines After- Logon-Triggers 2. Implementierung einer PL/SQL-Funktion, die eine Policy in Form einer Zeichenkette zurückliefert. Diese Policy steuert den Datenzugriff und bedient sich ggf. des Applikationskontexts. 3. Registrierung der Policy-Funktion zur betreffenden Tabelle, View oder zu einem Synonym durch Aufruf von DBMS_RLS.ADD_POLICY( ). Dabei kann u.a. die Art des Statements festgelegt werden, für das die Policy greift. Des Weiteren Database Vault Database Vault stellt eine Technologie dar, mit der es möglich wird, Daten vor internen Bedrohungen zu schützen. Diese internen Bedrohungen sind real und durch diverse repräsentative Studien belegt. Die Absicherung gegen diese Risiken ist daher gerechtfertigt und gründet im Allgemeinen nicht auf mangelndem Vertrauen in die eigenen Mitarbeiter. Mit Database Vault lassen sich innerhalb einer Webschnittstelle oder mithilfe einer API Schutzzonen, sogenannten Realms, definieren, die privilegierten Benutzern oder Administratoren den Zugriff auf sensible Daten verwehren. Zusätzlich können Kriterien festgesetzt werden, die für die Benutzerauthentifizierung erforderlich sind und die die gewöhnliche Authentifizierung erweitern. Auf diese Weise wird die Gefahr minimiert, dass sich Benutzer unter Vorgabe einer falschen Identität unbefugten Zugriff auf Daten verschaffen. Diese Kriterien, Factors genannt, stellen Vorgaben in Bezug auf folgende Fragen dar: Wer greift auf die Daten zu? Zu welchem Zeitpunkt erfolgt der Zugriff? Welche Daten werden angefordert? Von wo erfolgt der Zugriff? Die Grafik auf der folgenden Seite zeigt beispielhaft und sehr vereinfacht eine mögliche Konfiguration. OPITZ CONSULTING Deutschland GmbH 2015 Seite 18

19 6. Auswahl der zu schützenden Tabellen: Diese Tabellen erhalten eine zusätzliche Spalte, deren Name frei gewählt und die bei Bedarf unsichtbar gemacht werden kann, sodass die nachträgliche Änderung von Applikationslogik wegfällt. 7. Klassifizierung von Daten durch explizite Aktualisierung der Label- Spalte bzw. durch das Einfügen neuer Datensätze: Beim Einfügen neuer Datensätze wird die Klassifizierung des Benutzers im Attribut ROWLABEL automatisch als Daten-Label gesetzt. Mittels der Definition von Command Rules können außerdem Regeln bestimmt werden, die den erlaubten Satz von Datenbankbefehlen eines Benutzers beschränken. So kann einem Benutzer beispielsweise das Löschen von Tabellen in seinem eigenen Schema untersagt werden. Beim Zugriff auf die Daten geht die Datenbank daraufhin nach folgendem Schema vor: Database Vault erlaubt dabei die Verwendung von vordefinierten Standardrollen, betitelt als Separation of Duty. Beispiel einer solchen Rolle ist die Benutzeradministration. Einem Datenbankadministrator ohne diese Rolle kann damit das Recht entzogen werden, weitere Benutzer anzulegen. Neben der reinen Zugriffskontrolle bietet Database Vault ein zusätzliches Auditing, sodass versuchte Zugriffsverletzungen in vordefinierten Standardberichten dargestellt werden können. Database Vault ist verfügbar für die Datenbankreleases 9i R2, 10g R2 und 11g. Label Security Label Security ist eine kostenpflichtige Datenbankoption. Diese ermöglicht ähnlich wie VPD die Beschränkung des Zugriffs von Benutzern auf ausgewählte Datensätze einer Tabelle. Dank des Enterprise Managers ist es jedoch nicht erforderlich, eigene Policy-Funktionen zu entwickeln. Stattdessen können in der Programmoberfläche auf Datenebene sogenannte Labels vergeben werden, die sich in sogenannte Levels, Compartments und Groups untergliedern. Durch diese Unterteilung ist eine feingranulare Abbildung der Sensibilität der Daten möglich. Jedes Level, jedes Compartment und jede Group wird vom Administrator mit einer numerischen Repräsentation versehen. Je größer der Wert, desto sensibler sind die Daten. Das grundsätzliche Vorgehen lässt sich wie folgt zusammenfassen: 1. Definition von Levels 2. Optional: Definition von Compartments 3. Optional: Definition von Groups und Einordnung derselben in eine Hierarchie 4. Klassifizierung von Benutzern durch die zuvor definierten Labels 5. Unterscheidung zwischen lesendem und schreibendem Zugriff Data Masking Data Masking bezeichnet die Maskierung von sensiblen Daten zur Erstellung reell wirkender Testdaten. Zu diesem Zweck bietet die Oracle- Datenbank ein Management Pack, das über den Enterprise Manager genutzt werden kann. Dieses bietet eine Suchfunktionalität, mit der sensible Daten ausfindig gemacht werden können. Wurden sensible Daten in der Datenbank identifiziert, können diese mittels vordefinierter oder eigener Maskierungsfunktionen maskiert werden. Die vordefinierten Funktionen bieten neben der Generierung von zufälligen Werten auch Formatmasken zur Generierung von Telefonnummern oder Kreditkartennummern. Darüber hinaus ermöglicht Data Masking das deterministische Vertauschen von Werten. Auf diese Weise erhalten vormals gleiche Werte auch nach der Maskierung einen identischen Wert. Weitere Möglichkeiten sind dadurch gegeben, dass abhängig von Bedingungen unterschiedliche Maskierungsfunktionen angewandt werden können und dass durch die Definition zusammengehöriger Spalten die in den Daten vorliegenden Zusammenhänge aufrecht erhalten werden können. Die Maskierung der Daten basiert auf PL/SQL-Routinen, die bei Bedarf durch einen Administrator angepasst werden können und sich in andere Prozesse einbinden lassen. So kann die Anwendung von Data Masking im Zuge des Duplizierens von Tabellen oder während des Datenexports mit Export Data Pump erfolgen. OPITZ CONSULTING Deutschland GmbH 2015 Seite 19

20 Transparent Data Encryption Transparent Data Encryption ist Teil der Advanced Security Option für die Enterprise Edition der Datenbank. Mit diesem Feature lassen sich Daten nach einer umfangreichen Auswahl von Algorithmen verschlüsseln. Der Vorteil ist, dass diese Daten, sollten sie einmal in falsche Hände geraten, nicht im Klartext gelesen werden können. Zuvor müssen sie entschlüsselt werden, wofür die Kenntnis eines passenden Schlüssels erforderlich ist. Die Verschlüsselung ist transparent für die Applikationen, die die Daten weiterverarbeiten. Folglich ist eine Anpassung von Applikationslogik nicht erforderlich. Datenbankintern werden die Daten vor dem Schreiben auf die Festplatte automatisch verschlüsselt und beim Lesen wieder entschlüsselt, noch bevor sie an die Applikation übergeben werden. Wird eine Sicherung durchgeführt, bleiben die Daten hingegen verschlüsselt. Die Verwaltung der Schlüssel zum Ver- und Entschlüsseln geschieht ebenfalls datenbankintern in einem sogenannten Wallet, das seinerseits auch verschlüsselt ist. ORA-28365: WALLET IS NOT OPEN Die Verschlüsselung von Datenbankinhalten ist auf verschiedene Art und Weise möglich: Es können einzelne Spalten verschlüsselt werden. Ist die ausgewählte Spalte indiziert, werden das Löschen des Index und die anschließende Neuanlage desselben auf Basis der nunmehr verschlüsselten Spalte empfohlen. Seit Datenbankversion 11g können ganze Tabellen und Secure Files/ LOBS verschlüsselt werden. Ebenfalls seit 11g ist die Verschlüsselung ganzer Tablespaces möglich Bei der Verschlüsselung einzelner Spalten sind folgende Schritte einzuhalten: 1. Identifizierung der sensiblen, zu verschlüsselnden Spalten 2. Überprüfung auf Unterstützung des Datentyps und die Verwendung der Spalte in einem Fremdschlüssel (Ausschlusskriterium) 3. Verschlüsselung der Spalten mittels ALTER TABLE tabelle MODIFY (spalte ENCRYPT); Bei der Verschlüsselung eines Tablespace werden alle darin enthaltenen Objekte, inkl. LOBS, automatisch verschlüsselt. Die Verschlüsselung ist allerdings nur bei der Erstellung eines neuen Tablespace möglich. Die datenbankinterne Weiterverarbeitung der Daten geschieht ebenfalls verschlüsselt (Temporary Tablespace, Undo Tablespace, Redo Logs). Für dieses Wallet muss initial ein Master Key gesetzt werden, der systemweite Gültigkeit besitzt. Das Wallet muss zur Verarbeitung der Daten geöffnet sein, was nach einem Neustart der Instanz nicht gewährleistet ist. Das Wallet kann durch den folgenden Befehl geöffnet werden, wobei "mypassword" mit dem sogenannten Master Key substituiert werden muss. Ein Vorteil bei der Verschlüsselung eines ganzen Tablespace ist die Unterstützung von Index Range Scans sowie von verschlüsselten Spalten in Fremdschlüsseln. Neben der verschlüsselten Ablage von Daten im Dateisystem kann auch die Kommunikation mit der Datenbank verschlüsselt werden, um gegen das Auslesen von Inhalten über den Netzwerkverkehr abzusichern. In diesem Fall ist die Anpassung der Datei sqlnet.ora auf Server und Clients vonnöten. Unterstützung für die Verschlüsselung des Netzwerkverkehrs bietet zum Beispiel der Oracle Net Manager. ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "mypassword"; Wenn das Öffnen des Wallets vergessen wurde beziehungsweise das Wallet explizit mit dem Befehl ALTER SYSTEM SET WALLET CLOSE; Backup und Recovery Die Oracle Datenbank bietet mit Version 11g eine Reihe von Features, die in Zusammenhang mit Backup und Recovery stehen. Auf diese wird auf der folgenden Seite näher eingegangen: geschlossen wurde, erhält der Anwender bei einer Abfrage auf eine verschlüsselte Tabelle folgenden Fehler: OPITZ CONSULTING Deutschland GmbH 2015 Seite 20

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P Index- und Zugriffsstrukturen für Data Warehousing Holger Brämer, 05IND-P Index- und Zugriffstrukturen für Data Warehousing Materialisierte Sichten Bitmap-Indexe Verbundindexe Materialisierte Sichten gehören

Mehr

Oracle-Statistiken im Data Warehouse effizient nutzen

Oracle-Statistiken im Data Warehouse effizient nutzen Oracle-Statistiken im Data Warehouse effizient nutzen Reinhard Mense ARETO Consulting Köln Schlüsselworte: DWH, Data Warehouse, Statistiken, Optimizer, Performance, Laufzeiten Einleitung Für die performante

Mehr

Performance by Design Wie werden performante ETL-Prozesse erstellt?

Performance by Design Wie werden performante ETL-Prozesse erstellt? Performance by Design Wie werden performante ETL-Prozesse erstellt? Reinhard Mense ARETO Consulting Bergisch Gladbach Schlüsselworte: DWH, Data Warehouse, ETL-Prozesse, Performance, Laufzeiten, Partitionierung,

Mehr

Data-Warehouse-Features der Datenbank 11g R2

Data-Warehouse-Features der Datenbank 11g R2 Die Oracle-Datenbank wird stetig weiterentwickelt. Mittlerweile liegt sie in Version 11g R2 für alle gängigen Betriebssysteme vor. Mit jeder neuen Version nimmt auch der Funktionsumfang der Datenbank zu,

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

Oracle Warehouse Builder 3i

Oracle Warehouse Builder 3i Betrifft Autoren Art der Info Oracle Warehouse Builder 3i Dani Schnider (daniel.schnider@trivadis.com) Thomas Kriemler (thomas.kriemler@trivadis.com) Technische Info Quelle Aus dem Trivadis Technologie

Mehr

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel

Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Powerful PL/SQL: Collections indizieren mit VARCHAR2- Indizes ein Praxisbeispiel Schlagworte Autor: Klaus Friemelt, MT AG dynamisches BULK SQL, VARCHAR2-indizierte PL/SQL-Tabellen Einleitung Mit den letzten

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Automatisierte Datenmigration mit dynamischen SQL

Automatisierte Datenmigration mit dynamischen SQL Automatisierte Datenmigration mit dynamischen SQL Rolf Wesp Consultant Rolf.Wesp@trivadis.com Düsseldorf, 27. Oktober 2009 Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br.

Mehr

www.informatik-aktuell.de

www.informatik-aktuell.de www.informatik-aktuell.de Luxaviation Germany GmbH Wer bin ich? Marek Adar/ Bj. 1970 / 4 Kinder 2, 5, 15, 20 Luxaviation Group / IT-Leitung Luxaviation Germany Gruppenweit zuständig für Oracle, Monitoring,

Mehr

Eine völlig andere Form Abfragen zu erstellen ist, sie mit Hilfe der Datenbankabfragesprache SQL zu gestalten.

Eine völlig andere Form Abfragen zu erstellen ist, sie mit Hilfe der Datenbankabfragesprache SQL zu gestalten. Einführung SQL 2010 Niko Becker Mit unseren Übungen zu ACCESS können Sie Aufbau und Struktur einer relationalen Datenbank kennenlernen. Wir zeigen Ihnen wie Sie Tabellen, Formulare und Berichte erstellen

Mehr

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo.

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo. Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten

Mehr

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken Version 2.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs])

Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Hochschule für Technik, Wirtschaft und Kultur Leipzig 06.06.2008 Datenbanken II,Speicherung und Verarbeitung großer Objekte

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Oracle-Statistiken im Data Warehouse effizient nutzen

Oracle-Statistiken im Data Warehouse effizient nutzen Zur performanten Ausführung von Berichten und Ad-hoc-Abfragen eines BI-Systems sind beim Oracle Optimizer aussagekräftige und aktuelle Statistiken für die Tabellen und Indizes von essenzieller Bedeutung.

Mehr

Objektrelationale und erweiterbare Datenbanksysteme

Objektrelationale und erweiterbare Datenbanksysteme Objektrelationale und erweiterbare Datenbanksysteme Erweiterbarkeit SQL:1999 (Objekt-relationale Modellierung) In der Vorlesung werden nur die Folien 1-12 behandelt. Kapitel 14 1 Konzepte objekt-relationaler

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Inhalt. 1. Indextypen B*Baum-Index Reversed Key Index Bitmap Index Funktionsbasierter Index

Inhalt. 1. Indextypen B*Baum-Index Reversed Key Index Bitmap Index Funktionsbasierter Index Inhalt 1. Indextypen B*Baum-Index Reversed Key Index Bitmap Index Funktionsbasierter Index 2. Indexverwendung Vergleich von B*Baum und Bitmap Steuerung der Indexverwendung Richtlinien für die Indizierung

Mehr

Near Realtime ETL mit Oracle Golden Gate und ODI. Lutz Bauer 09.12.2015

Near Realtime ETL mit Oracle Golden Gate und ODI. Lutz Bauer 09.12.2015 Near Realtime ETL mit Oracle Golden Gate und ODI Lutz Bauer 09.12.2015 Facts & Figures Technologie-orientiert Branchen-unabhängig Hauptsitz Ratingen 240 Beschäftigte Inhabergeführt 24 Mio. Euro Umsatz

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. Integration der Ansicht "Adressen" in eigene Solution

Whitepaper. Produkt: combit Relationship Manager / address manager. Integration der Ansicht Adressen in eigene Solution combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager Integration der Ansicht "Adressen" in eigene Solution Integration der Ansicht "Adressen" in

Mehr

Data Warehouse schnell gemacht Performanceaspekte im Oracle DWH

Data Warehouse schnell gemacht Performanceaspekte im Oracle DWH Data Warehouse schnell gemacht Performanceaspekte im Oracle DWH Dani Schnider Principal Consultant Business Intelligence BI Trilogie, Zürich/Basel 25./26. November 2009 Basel Baden Bern Lausanne Zürich

Mehr

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen.

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. 1 In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. Zunächst stellt sich die Frage: Warum soll ich mich mit der Architektur eines DBMS beschäftigen?

Mehr

Relationales Datenbanksystem Oracle

Relationales Datenbanksystem Oracle Relationales Datenbanksystem Oracle 1 Relationales Modell Im relationalen Modell wird ein relationales Datenbankschema wie folgt beschrieben: RS = R 1 X 1 SC 1... R n X n SC n SC a a : i=1...n X i B Information

Mehr

1001 Möglichkeiten eine Staging Area zu füllen. Sven Bosinger its-people GmbH

1001 Möglichkeiten eine Staging Area zu füllen. Sven Bosinger its-people GmbH Ausgangslage Szenarien Populate the Stage - 1001 Möglichkeiten eine Staging Area zu füllen Sven Bosinger its-people GmbH 1 Sven Bosinger Solution Architect BI und Portfoliomanagement BI its-people GmbH

Mehr

Partitionieren über Rechnergrenzen hinweg

Partitionieren über Rechnergrenzen hinweg Partitionieren über Rechnergrenzen hinweg Erkan Yanar erkan.yanar@linsenraum.de Blog: linsenraum.de/erkules Xing: www.xing.com/profile/erkan Yanar 24. November 2011 Was tun wenn: Daten übersteigen die

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur. Subject. New Features Oracle 9i Tuning. Edo Bezemer. Author

Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur. Subject. New Features Oracle 9i Tuning. Edo Bezemer. Author Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur Subject New Features Oracle 9i Tuning Author Edo Bezemer Oracle Engineering Date August 2002 INHALTSVERZEICHNIS PERFORMANCE UND TUNING...3 TABELLEN ONLINE

Mehr

SQL-Loader. Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1

SQL-Loader. Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1 SQL-Loader Prof. Dr. Waldemar Rohde Dipl.-Ing. Jörg Höppner 05.05.2006 1 Beschreibung Definition transferiert Daten aus einer oder mehreren externen Dateien in eine oder mehrere Tabellen einer Oracle-Datenbank.

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

KURZANLEITUNG CLOUD OBJECT STORAGE

KURZANLEITUNG CLOUD OBJECT STORAGE KURZANLEITUNG CLOUD OBJECT STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung... Seite 03 2. Anmelden am Cloud&Heat Dashboard... Seite 04 3. Anlegen eines Containers... Seite 05

Mehr

6. Datenintegrität. Integritätsbedingungen

6. Datenintegrität. Integritätsbedingungen 6. Integritätsbedingungen dienen zur Einschränkung der Datenbankzustände auf diejenigen, die es in der realen Welt tatsächlich gibt. sind aus dem erstellten Datenmodell ableitbar (semantisch) und können

Mehr

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Boris Meißner 05-INDT Fachbereich Informatik, Mathematik und Naturwissenschaften HTWK-Leipzig 05. Juni 2008 Boris Meißner (Fb IMN - HTWK-Leipzig)

Mehr

Inhaltsverzeichnis. jetzt lerne ich

Inhaltsverzeichnis. jetzt lerne ich Inhaltsverzeichnis jetzt lerne ich Einführung 15 1 Erste Schritte 21 1.1 Datenbanken und Datenbank-Managementsysteme 21 1.2 Zugriff auf Datenbanken 22 1.3 Was der Großvater noch wusste... 22 1.4 Einordnung

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

Mehr

PostgreSQL unter Debian Linux

PostgreSQL unter Debian Linux Einführung für PostgreSQL 7.4 unter Debian Linux (Stand 30.04.2008) von Moczon T. und Schönfeld A. Inhalt 1. Installation... 2 2. Anmelden als Benutzer postgres... 2 2.1 Anlegen eines neuen Benutzers...

Mehr

Physische Datenbankdefinition in. Arthur Bauer

Physische Datenbankdefinition in. Arthur Bauer Physische Datenbankdefinition in Arthur Bauer Inhalt Cluster Index-Cluster Hash-Cluster Vor- und Nachteile Index-Organisierte Tabelle (IOT) Partitionierung STORAGE-Klausel in DDL Indexstrukturen Oracle

Mehr

Datenbanken und Oracle, Teil 2

Datenbanken und Oracle, Teil 2 Datenbanken und Oracle, Teil 2 Mathias Weyland Linux User Group Switzerland 29. Juni 2007 SQL*Plus CHAR/VARCHAR2 Dokumentation Teil I Nachträge 1 SQL*Plus 2 CHAR/VARCHAR2 3 Dokumentation SQL*Plus SQL*Plus

Mehr

Oracle Datenbankadministration Grundlagen

Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Grundlagen Seminarunterlage Version: 12.02 Version 12.02 vom 14. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

Oracle Backup und Recovery

Oracle Backup und Recovery Seminarunterlage Version: 11.05 Version 11.05 vom 27. Mai 2010 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

IT-Symposium 2008 05.06.2008

IT-Symposium 2008 05.06.2008 Selftuning Database Ein Traum oder Wirklichkeit Ralf Durben Oracle Deutschland GmbH www.hp-user-society.de 1 Die Arbeitswelt des Gestern, heute und morgen Früher Ein für wenige Datenbanken

Mehr

Mehr Ergebnisse: Linguistische Funktionen und Ähnlichkeitssuche mit SQL. Carsten Czarski ORACLE Deutschland B.V. & Co KG München

Mehr Ergebnisse: Linguistische Funktionen und Ähnlichkeitssuche mit SQL. Carsten Czarski ORACLE Deutschland B.V. & Co KG München Mehr Ergebnisse: Linguistische Funktionen und Ähnlichkeitssuche mit SQL Carsten Czarski ORACLE Deutschland B.V. & Co KG München Einleitung Jede Suche in den Tabellen im Data Warehouse ist eine SQL-Abfrage

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Whitepaper. Produkt: combit Relationship Manager. Datensatzhistorie mit dem SQL Server 2000 und 2005. combit GmbH Untere Laube 30 78462 Konstanz

Whitepaper. Produkt: combit Relationship Manager. Datensatzhistorie mit dem SQL Server 2000 und 2005. combit GmbH Untere Laube 30 78462 Konstanz combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager Datensatzhistorie mit dem SQL Server 2000 und 2005 Datensatzhistorie mit dem SQL Server 2000 und 2005-2 - Inhalt

Mehr

Funktion definieren Gibt Summe der Gehälter zurück. Aufruf in einem SQL-Statement

Funktion definieren Gibt Summe der Gehälter zurück. Aufruf in einem SQL-Statement Funktion definieren Gibt Summe der Gehälter zurück Aufruf in einem SQL-Statement Dr. Christian Senger Einführung PL/SQL 1 Procedures & Transaktionen CREATE OR REPLACE PROCEDURE write_log ( log_code IN

Mehr

Kurs. Teil 7 UNDO-Management. Universität Hannover. Agenda. Einführung. Nutzung RBS Oracle 9i Einführung Performance Tuning.

Kurs. Teil 7 UNDO-Management. Universität Hannover. Agenda. Einführung. Nutzung RBS Oracle 9i Einführung Performance Tuning. Kurs Oracle 9i Performance Tuning Teil 7 UNDO-Management Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 23 Seite 1 von 23 1. 2. Nutzung des Rollback Segments 3. 4. 5. Größe von UNDO- TBS berechnen 6.

Mehr

IBM SPSS Data Access Pack Installationsanweisung für Windows

IBM SPSS Data Access Pack Installationsanweisung für Windows IBM SPSS Data Access Pack Installationsanweisung für Windows Inhaltsverzeichnis Kapitel 1. Übersicht.......... 1 Einführung............... 1 Bereitstellen einer Datenzugriffstechnologie.... 1 ODBC-Datenquellen...........

Mehr

TimeSafe Leistungserfassung

TimeSafe Leistungserfassung Keep your time safe. TimeSafe Leistungserfassung Adressimport 1/8 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 Allgemeines... 3 1.1 Adressen in der TimeSafe Leistungserfassung... 3 1.2 Organisationen und/oder

Mehr

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

Mehr

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

MySQL Queries on "Nmap Results"

MySQL Queries on Nmap Results MySQL Queries on "Nmap Results" SQL Abfragen auf Nmap Ergebnisse Ivan Bütler 31. August 2009 Wer den Portscanner "NMAP" häufig benutzt weiss, dass die Auswertung von grossen Scans mit vielen C- oder sogar

Mehr

Einführung in SQL. 1. Grundlagen SQL. Structured Query Language. Viele Dialekte. Unterteilung: i. DDL (Data Definition Language)

Einführung in SQL. 1. Grundlagen SQL. Structured Query Language. Viele Dialekte. Unterteilung: i. DDL (Data Definition Language) Einführung in SQL 1. Grundlagen Structured Query Language Viele Dialekte Unterteilung: i. DDL (Data Definition Language) ii. iii. DML (Data Modifing Language) DRL (Data Retrival Language) 1/12 2. DDL Data

Mehr

Backup und Restore von Oracle- Datenbanken in Niederlassungen

Backup und Restore von Oracle- Datenbanken in Niederlassungen Regionaltreffen München/Südbayern am Dienstag, 07.07.2008, 17:00 Uhr Backup und Restore von Oracle- Datenbanken in Niederlassungen Entfernte DBs einfach sichern Ihr Partner für Schulung, Betreuung und

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

SQL Optimizer und SQL Performance

SQL Optimizer und SQL Performance SQL Optimizer und SQL Performance Schlüsselworte SQL, Optimizer, Explain Plan, SQL Trace Marco Mischke Robotron Datenbank Software GmbH Dresden Einleitung Dieser Vortrag beschäftigt sich mit grundlegenden

Mehr

... Kontrolldatei administrieren

... Kontrolldatei administrieren 6... Kontrolldatei administrieren Lektion 6: Kontrolldatei administrieren Ziele Ziele Nach dieser Lektion sollten Sie Folgendes können: Arbeiten mit der Kontrolldatei erklären Inhalt der Kontrolldatei

Mehr

COLLECTION. Installation und Neuerungen. Märklin 00/H0 Jahresversion 2009. Version 7. Die Datenbank für Sammler

COLLECTION. Installation und Neuerungen. Märklin 00/H0 Jahresversion 2009. Version 7. Die Datenbank für Sammler Die Datenbank für Sammler COLLECTION Version 7 Installation und Neuerungen Märklin 00/H0 Jahresversion 2009 Stand: April 2009 Inhaltsverzeichnis Inhaltsverzeichnis... 2 VORWORT... 3 Hinweise für Anwender,

Mehr

Java Application 1 Java Application 2. JDBC DriverManager. JDBC-ODBC Br idge. ODBC Driver Manager. Dr iver C. Dr iver D.

Java Application 1 Java Application 2. JDBC DriverManager. JDBC-ODBC Br idge. ODBC Driver Manager. Dr iver C. Dr iver D. 1 Copyright 1996-1997 by Axel T. Schreiner. All Rights Reserved. 7 Datenbankzugriff Prinzip Dieser Abschnitt beschäftigt sich mit dem Paket java.sql, das eine SQL-Schnittstelle für Java verkapselt. Java-Programme

Mehr

Datenaustausch mit Mac / PC & HeadCook / Ecoshop

Datenaustausch mit Mac / PC & HeadCook / Ecoshop Datenaustausch mit Mac / PC & HeadCook / Ecoshop 2008-2011 InnoBytes, Wolfgang Kohrt 1 Inhalt! Allgemeines! 3 1. Vorbereitungen! 4 1.1 Vorbereitungen für MacOSX 10! 4 1.2 Vorbereitungen für Windows XP/Vista/7!

Mehr

Oracle OLAP 11g: Performance für das Oracle Data Warehouse

Oracle OLAP 11g: Performance für das Oracle Data Warehouse Oracle OLAP 11g: Performance für das Oracle Data Warehouse Marc Bastien Oracle BI Presales Agenda Performanceprobleme in Oracle DWH: gibt s das überhaupt? Mögliche Gründe und Lösungen

Mehr

Release Notes für die Online-Version der Perinorm - September 2014

Release Notes für die Online-Version der Perinorm - September 2014 Release Notes für die Online-Version der Perinorm - September 2014 Mit der Ausgabe September 2014 wird die Software für die Online-Version von Perinorm aktualisiert. Einige Verbesserungen, die mit diesem

Mehr

8 Access-Abfragen migrieren

8 Access-Abfragen migrieren Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 8 Access-Abfragen migrieren Mit der Migration der Tabellen Ihrer Anwendung zu einer SQL Server-Datenbank und dem Verknüpfen der SQL Server-Tabellen

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Datenbanken SQL Einführung Datenbank in MySQL einrichten mit PhpMyAdmin

Datenbanken SQL Einführung Datenbank in MySQL einrichten mit PhpMyAdmin Datenbanken SQL Einführung Datenbank in MySQL einrichten mit PhpMyAdmin PhpMyAdmin = grafsches Tool zur Verwaltung von MySQL-Datenbanken Datenbanken erzeugen und löschen Tabellen und Spalten einfügen,

Mehr

Der Neue Weg zur Verschlüsselung von Datenbankinhalten

Der Neue Weg zur Verschlüsselung von Datenbankinhalten Der Neue Weg zur Verschlüsselung von Datenbankinhalten Da Häufigkeit und Schwere von Datendiebstahl zunehmen, ist es immens wichtig, dass Unternehmen vertrauliche und sensible Daten zusätzlich durch Verschlüsselung

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 CARL HANSER VERLAG Christopher Allen Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 www.hanser.de Inhaltsverzeichnis Danksagung...XI Einleitung...XIII

Mehr

1 Die Active Directory

1 Die Active Directory 1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure

Mehr

Microsoft SQL Server 2005 für Administratoren

Microsoft SQL Server 2005 für Administratoren Microsoft SQL Server 2005 für Administratoren Irene Bauder ISBN 3-446-22800-4 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22800-4 sowie im Buchhandel Sichern von

Mehr

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2 Jörg Kapelle 15:19:08 Filterregeln Inhaltsverzeichnis Filterregeln... 1 Einführung... 1 Migration der bestehenden Filterregeln...1 Alle eingehenden Nachrichten weiterleiten...2 Abwesenheitsbenachrichtigung...2

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

Datumsangaben, enthält mindestens Jahr, Monat, Tag

Datumsangaben, enthält mindestens Jahr, Monat, Tag Datenbanken mit SQL Informatik - Sprenger Häufig wird mit Tabellenkalkulationen gearbeitet, obwohl der Einsatz von Datenbanken sinnvoller ist. Tabellenkalkulationen wie Microsoft Excel oder LibreOffice

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

Es geht also im die SQL Data Manipulation Language.

Es geht also im die SQL Data Manipulation Language. 1 In diesem Abschnitt wollen wir uns mit den SQL Befehlen beschäftigen, mit denen wir Inhalte in Tabellen ( Zeilen) einfügen nach Tabelleninhalten suchen die Inhalte ändern und ggf. auch löschen können.

Mehr

Verschlüsseln als Überlebensstrategie

Verschlüsseln als Überlebensstrategie Verschlüsseln als Überlebensstrategie Netzwerk- und Datenverschlüsselung in Oracle Datenbanken Heinz-Wilhelm Fabry ORACLE Deutschland GmbH 1 Agenda Datentransfer über das Netzwerk

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

6. Sichten, Integrität und Zugriffskontrolle. Vorlesung "Informa=onssysteme" Sommersemester 2015

6. Sichten, Integrität und Zugriffskontrolle. Vorlesung Informa=onssysteme Sommersemester 2015 6. Sichten, Integrität und Zugriffskontrolle Vorlesung "Informa=onssysteme" Sommersemester 2015 Überblick Sichten Integritätsbedingungen Zugriffsrechte SQL- Schema und SQL- Katalog Das Informa=onsschema

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Einführung relationale Datenbanken. Themenblock: Erstellung eines Cube. Schlüssel. Relationenmodell Relationenname Attribut. Problem.

Einführung relationale Datenbanken. Themenblock: Erstellung eines Cube. Schlüssel. Relationenmodell Relationenname Attribut. Problem. Themenblock: Erstellung eines Cube Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Praktikum: Data Warehousing und Data Mining Idee Speicherung der Daten in Form von Tabellen

Mehr

Andrea Held. Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken. Empfehlungen

Andrea Held. Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken. Empfehlungen Andrea Held Motivation ILM: Definition und Strategien Lösungen für Oracle Datenbanken Partitionierung Komprimierung ILM Assistant Flashback Data Archive Empfehlungen 1 Datenwachstum Wachsende Kosten Schlechtere

Mehr

www.informatik-aktuell.de

www.informatik-aktuell.de www.informatik-aktuell.de Luxaviation Germany GmbH Multitenant Wer bin ich? Marek Adar/ Bj. 1970 / 4 Kinder 2, 5, 15, 20 Luxaviation Group / IT-Leitung Luxaviation Germany Gruppenweit zuständig für Oracle,

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format.

Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH. Software mit Format. Fördercontrolling im öffentlichen Bereich Aspekte beim Aufbau eines DWH Gerd Schandert, Neuss den 18.03.2014 Agenda 1. Vorstellung Auftraggeber 2. Förderung allgemein 3. Schichten im Data Warehouse 4.

Mehr

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper)

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper) Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10 Technische Informationen (White Paper) Inhaltsverzeichnis 1. Über dieses Dokument... 3 2. Überblick... 3 3. Upgrade Verfahren... 4

Mehr

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6HKUJHHKUWH6RIW&OHDQ $QZHQGHU LQ XQVHUHP 6RIW&OHDQ 8SGDWHV 'RZQORDGEHUHLFK ILQGHQ 6LH ]ZHL $UWHQ YRQ 8SGDWHV 1DFKIROJHQGHUIDKUHQ6LHZHOFKHV8SGDWHI U6LHGDVULFKWLJHLVWXQGZLH6LHGDV8SGDWHDXI,KUHP$UEHLWVSODW]GXUFKI

Mehr

WIE KANN ICH ACCESS XML FÄHIGKEITEN UNABHÄNGIG VON DER VERSION BEIBRINGEN?

WIE KANN ICH ACCESS XML FÄHIGKEITEN UNABHÄNGIG VON DER VERSION BEIBRINGEN? XML 1 WIE KANN ICH ACCESS XML FÄHIGKEITEN UNABHÄNGIG VON DER VERSION BEIBRINGEN? Mit den verschiedenen Versionen von Access wurde die Unterstützung von XML immer mehr verbessert. Vollständig ist sie aber

Mehr

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht Dipl. Inf. Eric Winter Entwicklungsleiter PTC GPS-Services GmbH PostgreSQLals HugeData Storage Ein Erfahrungsbericht Inhalt 1. Problembeschreibung 2. Partielle Indexierung 3. Partitionierung 1. Vererbung

Mehr

www.informatik-aktuell.de

www.informatik-aktuell.de www.informatik-aktuell.de Flashback Reise in die Vergangenheit einfach. gut. beraten. Warum Oracle Zeitreisen anbieten kann, der Microsoft SQL Server aber leider nicht. IT-Tage Datenbanken 18.12.2015,

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

TOP 10 Monitoring SQL Befehle

TOP 10 Monitoring SQL Befehle TOP 10 Monitoring SQL Befehle Autor(en): Marco Patzwahl, MuniQSoft GmbH Viel Kunden haben schon mehr als 100 Datenbanken zu betreuen. Da kommt man ohne automatisierte Überwachungsskripte nicht sehr weit.

Mehr

7 Die Reorganisation von DB2

7 Die Reorganisation von DB2 Ab und an sollte eine Tabelle reorganisiert werden. Besonders, nachdem größere Datenmengen eingefügt oder gelöscht wurden, muß über eine Reorganisation nachgedacht werden. Eine optimale Performance ist

Mehr

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 12 Materialized Views. Universität Hannover. Praxisbeispiel. Migration.

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 12 Materialized Views. Universität Hannover. Praxisbeispiel. Migration. Kurs Oracle 9i Einführung Performance Tuning Teil 12 Materialized Views Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 9 Seite 1 von 9 Agenda 1. Einführung Materialized Views 2. 3. Materialized View

Mehr

Datenbanken: Datenintegrität. www.informatikzentrale.de

Datenbanken: Datenintegrität. www.informatikzentrale.de Datenbanken: Datenintegrität Definition "Datenkonsistenz" "in der Datenbankorganisation (...) die Korrektheit der gespeicherten Daten im Sinn einer widerspruchsfreien und vollständigen Abbildung der relevanten

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr