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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

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

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

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

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

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

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

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

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

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

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

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

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

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

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i

Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Lerox DB/2 Datenbankreferenz in QlikView für IBM System AS/400, iseries i5, System i Inhaltsverzeichnis Überblick... 3 Die QlikView Applikation im Kontext... 4 Technische Rahmenbedinungen... 5 Funktionelle

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

WhitePaper. Mai 2012. BIA Business Intelligence Accelerator. Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com

WhitePaper. Mai 2012. BIA Business Intelligence Accelerator. Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com WhitePaper BIA Business Intelligence Accelerator Mai 2012 Markus Krenn Geschäftsführer Mail: m.krenn@biaccelerator.com BIA Business Intelligence Accelerator GmbH Softwarepark 26 A-4232 Hagenberg Mail:

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

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

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

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

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

Backup & Recovery in Oracle 11g Funktionen und Features

Backup & Recovery in Oracle 11g Funktionen und Features Backup & Recovery in Oracle 11g Funktionen und Features Wolfgang Thiem Server Technologies Customer Center ORACLE Deutschland GmbH Warum werden Backups gemacht? Damit man im Fehlerfall auf einen konsistenten

Mehr

Geordnete Form...36 Erfassung und Speicherung...37 Relationale Datenbanken...37 Einfache Tabellen...37 Objekte und Begriffe relationaler

Geordnete Form...36 Erfassung und Speicherung...37 Relationale Datenbanken...37 Einfache Tabellen...37 Objekte und Begriffe relationaler Inhaltsverzeichnis Einleitung...13 SQL: Die Abfragesprache für Datenbanken...17 Kennzeichnende Merkmale von SQL...17 SQL-Dialekte...18 Kurze Entwicklungsgeschichte...18 SQL/86 oder SQL/1...19 SQL/89 oder

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

Effizientes und einfaches Staging in Near Real Time -Data-Warehouses

Effizientes und einfaches Staging in Near Real Time -Data-Warehouses Bei der Entscheidung für eine ETL-Technik mit hohen Aktualitätsansprüchen (Near-Real-Time) sind Effizienz und Stabilität zwei wesentliche Kriterien. Dies gilt natürlich für die Transformation der Daten

Mehr

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion

BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion independit Integrative Technologies GmbH Bergstraße 6 D 86529 Schrobenhausen BICsuite!focus Parallelisierung von Prozessen mit der BICsuite Dynamic Submit Funktion Dieter Stubler Ronald Jeninga July 30,

Mehr

SQL-Anweisungen. SELECT (SQL Data Query Language)

SQL-Anweisungen. SELECT (SQL Data Query Language) SQL-Anweisungen SELECT (SQL Data Query Language) SELECT * SELECT * FROM "meine Tabelle"; SELECT feldname1, feldname2 SELECT feldname1, feldname2 FROM meinetabelle ORDER BY feldname2, feldname1 DESC; WHERE

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

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

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

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

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Handover von Daten IBM Rational DOORS StartUp Training - Teil 2

Handover von Daten IBM Rational DOORS StartUp Training - Teil 2 Handover von Daten IBM Rational DOORS StartUp Training - Teil 2 Inhalt: Überblick Daten Import & Export Import von RTF Dateien Import von Spreadsheet Daten Export als RTF und HTML DOORS Repository In-Export

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

XML - Extensible Markup Language. Agenda - Oracle XML DB

XML - Extensible Markup Language. Agenda - Oracle XML DB Architektur und Funktionalitäten der Oracle XML DB - ein Überblick mit ausgewählten praktischen Beispielen - im Rahmen des 17. Workshop Grundlagen von Datenbanken 2005 in Wörlitz Annegret Warnecke Senior

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

SQL and PL/SQL unleashed. Neuheiten bei Oracle 11g und Oracle 12c im Bereich SQL und PL/SQL

SQL and PL/SQL unleashed. Neuheiten bei Oracle 11g und Oracle 12c im Bereich SQL und PL/SQL . Neuheiten bei Oracle 11g und Oracle 12c im Bereich SQL und PL/SQL Johannes Gritsch Themenübersicht Neue Scheduler Job Typen SQL_SCRIPT und BACKUP_SCRIPT SQL RowLimit: PERCENT und TIES WITH-Klausel mit

Mehr

IBM DB2 für Linux/Unix/Windows Monitoring und Tuning

IBM DB2 für Linux/Unix/Windows Monitoring und Tuning IBM DB2 für Linux/Unix/Windows Monitoring und Tuning Seminarunterlage Version: 4.05 Version 4.05 vom 9. Februar 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt-

Mehr

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung 3 Indizes 3.1 Indexarchitektur von SQL Server Die folgende Abbildung zeigt die Organisationsstruktur einer Tabelle. Eine Tabelle befindet sich in einer oder mehreren Partitionen, und jede Partition enthält

Mehr

Loader. Oracle SQL*Loader. Einsatzmöglichkeit für den Import von Massendaten. 2. Datenbankworkshop der Ag Bioinformatik BIC-GH / PDW IPK

Loader. Oracle SQL*Loader. Einsatzmöglichkeit für den Import von Massendaten. 2. Datenbankworkshop der Ag Bioinformatik BIC-GH / PDW IPK 2. Datenbankworkshop der Ag Bioinformatik Oracle SQL*Loader Loader Einsatzmöglichkeit für den Import von Massendaten Christian Künne IPK Überblick Oracle SQL*Loader - Hintergrund - Anmerkungen - Funktionsweise

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

Schlüsselworte Data Guard, Standby Datenbank, RMAN, Backup, Restore, Recovery

Schlüsselworte Data Guard, Standby Datenbank, RMAN, Backup, Restore, Recovery Betrifft Standby Datenbanken Backup Art der Info Lösungskonzept (November 2002) Autor Irina Flegler (irina.flegler@trivadis.com) Martin Wunderli (martin.wunderli@trivadis.com) Quelle Beratungstätigkeit

Mehr

Übung 1: Ein Website News-System mit MySQL

Übung 1: Ein Website News-System mit MySQL Übung 1: Ein Website News-System mit MySQL In der Vorübung haben wir bereits mit Hilfe eines ERMs den Datenbankentwurf erstellt und daraus die folgenden Tabellen abgeleitet: Nun muss diese Datenbank in

Mehr

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0 Leistungsbeschreibung PHOENIX Archiv Oktober 2014 Version 1.0 PHOENIX Archiv Mit PHOENIX Archiv werden Dokumente aus beliebigen Anwendungen dauerhaft, sicher und gesetzeskonform archiviert. PHOENIX Archiv

Mehr

GoVault Data Protection-Software Überblick

GoVault Data Protection-Software Überblick 1226-GoVaultSoftware-GermanTranslation-A4 13/3/08 09:16 Page 1 Das GoVault-System enthält die Windows-basierte Software GoVault Data Protection und bildet damit eine komplette Backup- und Restore-Lösung

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Oracle Backup und Recovery mit RMAN

Oracle Backup und Recovery mit RMAN Oracle Backup und Recovery mit RMAN Seminarunterlage Version: 12.04 Copyright Version 12.04 vom 16. Juli 2015 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt-

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

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

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

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

Oracle Datenbank - Recovery

Oracle Datenbank - Recovery Oracle Datenbank - Recovery H.-G. Hopf Georg-Simon-Ohm Fachhochschule Nürnberg Datenbank-Recovery / 1 Η. G.Hopf / 10.04.2003 Inhaltsverzeichnis Transaktionsablauf Prozess - Recovery Instanz - Recovery

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können

Mehr

Oracle Advanced Compresion 10g versus 11g

Oracle Advanced Compresion 10g versus 11g Regionaltreffen München/Südbayern am Montag, 12.01.2009, 17:00 Uhr Oracle Advanced Compresion 10g versus 11g Platz in der Datenbank optimal nützen Ihr Partner für Schulung, Betreuung und Beratung rund

Mehr

Transaktionen in der Praxis. Dr. Karsten Tolle

Transaktionen in der Praxis. Dr. Karsten Tolle Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);

Mehr

Oracle Warehousebuilder. Version 9.2.0.2.8 In Version 9.2er Umgebung

Oracle Warehousebuilder. Version 9.2.0.2.8 In Version 9.2er Umgebung Oracle Warehousebuilder Version 9.2.0.2.8 In Version 9.2er Umgebung Themenüberblick Architektur Vorbereitung Ablauf und Details Anmerkungen / Probleme Architektur GEBIS (Source) Datenfluss

Mehr

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse Seminar Advanced Data Warehouse Thema: Index Selection Vortrag von Stephan Rieche gehalten am 2. Februar 2004 Download:.../~rieche Inhalt des Vortrages 1. Einleitung - Was ist das Index Selection Problem?

Mehr

Inhaltsverzeichnis. Geleitwort der Fachgutachterin... 15 Vorwort... 17 Einführung... 19 1 Architektur eines Oracle-Datenbanksystems...

Inhaltsverzeichnis. Geleitwort der Fachgutachterin... 15 Vorwort... 17 Einführung... 19 1 Architektur eines Oracle-Datenbanksystems... Inhaltsverzeichnis Geleitwort der Fachgutachterin.............................. 15 Vorwort.................................................... 17 Einführung.................................................

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

Allgemein. Einrichtung. PHOENIX Tool WinUser2PHOENIXUser. Version: 3.5.2 Stand: 2013-04-16

Allgemein. Einrichtung. PHOENIX Tool WinUser2PHOENIXUser. Version: 3.5.2 Stand: 2013-04-16 PHOENIX Tool WinUser2PHOENIXUser Version: 3.5.2 Stand: 2013-04-16 Allgemein Das Tool ermöglicht es, Benutzerinformationen aus dem Windows Active Directory (AD) in den PHOENIX zu importieren. Dabei können

Mehr

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation

JOB SCHEDULER. Managed User Jobs. Dokumentation Juli 2005. MySQL-Job-Automation MySQL-Job-Automation Managed User Jobs JOB SCHEDULER Dokumentation Juli 2005 Software- und Organisations-Service GmbH Giesebrechtstr. 15 D-10629 Berlin Telefon (030) 86 47 90-0 Telefax (030) 861 33 35

Mehr

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index!

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index! 1/40 PHP-User-Group Stuttgart 14.01.2009 Warum Datenbanken einen Hals bekommen und was sich dagegen tun lässt. Tuning und Performancesteigerung ohne zusätzliche Hardware. Ein. Loblied auf den Tabellen-Index!

Mehr

Erste Schritte, um selber ConfigMgr Reports zu erstellen

Erste Schritte, um selber ConfigMgr Reports zu erstellen Thomas Kurth CONSULTANT/ MCSE Netree AG thomas.kurth@netree.ch netecm.ch/blog @ ThomasKurth_CH Erste Schritte, um selber ConfigMgr Reports zu erstellen Configuration Manager Ziel Jeder soll nach dieser

Mehr

Advanced Analytics mit EXAPowerlytics. Technisches Whitepaper

Advanced Analytics mit EXAPowerlytics. Technisches Whitepaper Advanced Analytics mit EXAPowerlytics Technisches Whitepaper Inhalt 1. Zusammenfassung... 3 2. Einführung... 4 3. Fachliche Einführung... 5 4. Beispiel: Zeichen zählen... 7 5. Fazit... 9 6. Anhang... 10-2

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

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

SQL-Befehlsliste. Vereinbarung über die Schreibweise

SQL-Befehlsliste. Vereinbarung über die Schreibweise Vereinbarung über die Schreibweise Schlüsselwort [optionale Elemente] Beschreibung Befehlsworte in SQL-Anweisungen werden in Großbuchstaben geschrieben mögliche, aber nicht zwingend erforderliche Teile

Mehr

IBM Informix Tuning und Monitoring

IBM Informix Tuning und Monitoring Seminarunterlage Version: 11.01 Copyright Version 11.01 vom 25. Juli 2012 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

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

Datawarehouses, Materialized Views, Materialized View Logs, Query Rewrite

Datawarehouses, Materialized Views, Materialized View Logs, Query Rewrite Betrifft DWH1: Materialized Views für Data-Warehouses Art der Info Technische Info, Oracle8i Quelle Aus dem AI8-EF Kurs der Trivadis (Enterprise Features) Autor Andri Kisseleff (andri.kisseleff@trivadis.com)

Mehr

Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch nichts zurücksichern.

Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch nichts zurücksichern. Exchange Daten wieder ins System einfügen (Dieses Dokument basiert auf einem Artikel des msxforum) Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr