LOB Komprimierung mit Oracle 11g. Einführung. SecureFiles. Nötige Lizenzierungen. Mathias Zarick. Consultant. Oktober 2009

Größe: px
Ab Seite anzeigen:

Download "LOB Komprimierung mit Oracle 11g. Einführung. SecureFiles. Nötige Lizenzierungen. Mathias Zarick. Consultant. Oktober 2009"

Transkript

1 LOB Komprimierung mit Oracle 11g Mathias Zarick. Consultant. Oktober 2009 Mit Oracle Database 11g ist es möglich, Large Objects (LOBs) komprimiert in der Datenbank zu speichern. Durch dieses Feature aus der neuen kostenpflichtigen Advanced Compression Option ist es möglich Speicherplatz zu sparen. Lohnt sich der Aufwand? Was bedeutet das für die Application Performance? Dieser Artikel beleuchtet diese Fragen. Einführung Oracle hat die Implementierung der Large Objects (LOBs) in der Datenbank grundlegend überarbeitet. Oracle verspricht mit dieser neuen Implementierung verbesserte Performance und Verwaltung. Diese neuen LOBs sind ein weiteres Beispiel für die effektive Nutzung der Architektur von lokalen Tablespaces mit Automatic Segment Space Management (ASSM). ASSM Tablespaces sind daher auch eine Voraussetzug für das Anlegen dieser neuartigen LOBs, die Oracle SecureFiles nennt. SecureFiles Die Nutzung von Oracle SecureFiles ist transparent für Anwendungen und APIs, die auf diese LOBs zugreifen. Jegliche LOB Schnittstellen arbeiten wie auf den herkömmlichen LOBs, die es natürlich auch noch gibt und jetzt BasicFiles heißen. Sowohl für BasicFiles als auch für SecureFiles werden die drei Datentypen CLOB, NCLOB und BLOB unterstützt. Dennoch gibt es auch Einschränkungen: Der LogMiner versteht SecureFiles mit 11gR1 noch nicht, daher sind sie auf diesem Release nicht in Umgebungen mit Logical Standby Database oder Streams einsetzbar. Diese Einschränkung fällt mit 11gR2, ab diesem Release kann der LogMiner mit SecureFiles umgehen. Oracle SecureFiles können im Gegensatz zu BasicFiles komprimiert, dedupliziert oder verschlüsselt werden. Diese drei Technologien können orthogonal zueinander Anwendung finden, d.h. keines der Features schließt ein anderes aus. Komprimierung und Deduplizierung werden in diesem Artikel näher beleuchtet. Die Verschlüsselung, welche den SecureFiles wohl den Namen gab, ermöglicht es, die LOBs basierend auf Transparent Data Encryption (TDE) zu verschlüsseln. SecureFiles bieten außerdem eine zusätzliche Logging Option FILESYSTEM_LIKE_LOGGING mit welcher es nun möglich ist, Redo Informationen für Metadaten zu loggen, für Daten jedoch nicht. Nötige Lizenzierungen Für die Verwendung von SecureFiles ohne Komprimierung, Deduplizierung oder Verschlüsselung ist keine weitere Lizenz nötig. Sie sind sowohl in Standard Edition als auch in Enterprise Edition verfügbar. Sobald jedoch eines der drei erwähnten Features verwendet wird, ist die Enterprise Edition mit einer dazugehörigen Option notwendig. Für Komprimierung und Deduplizierung ist das die Advanced Compression Option und für die Verschlüsselung die Advanced Security Option. Bei einer kombinierten Anwendung werden entsprechend beide Optionen fällig. Seite 1 / 15

2 Speicherung von LOBs Um ein LOB zu speichern, verwendet Oracle auch für SecureFiles die gleichen Datenstrukturen, ein LOB Segment und einen LOB Index. Der LOB Index wird benötigt, um auf LOB Chunks (Erklärung folgt unten) aus dem LOB Segment zuzugreifen. LOBs können nach wie vor inline (enable storage in row) oder auch out-of-line (disable storage in row) gespeichert werden. Für LOBs, die out-of-line gespeichert werden, speichert Oracle einen LOB Locator in der entsprechenden Row. Der LOB Locator bietet dann den Einstieg, um über den LOB Index auf das LOB im LOB Segment zuzugreifen. Wird hingegen Inline Speicherung verwendet, so können kleine LOBs mit in der Row also zusammen mit den anderen Spalten der Tabelle in demselben Block gespeichert werden. Überschreitet das LOB jedoch eine Größe von ca Bytes wird es immer komplett out-of-line gespeichert. Inline Speicherung empfiehlt sich nur für kleine LOBs, die häufig zusammen mit den anderen Spalten der Tabelle gelesen werden. Gibt es hingegen viele Full Table Scans auf der Tabelle, die die LOB Daten nicht brauchen, so sollten sie unbedingt out-of-line gespeichert werden, um nicht ständig über unnötige Daten hinweglesen zu müssen. Der Default ist nach wie vor enable storage in row. Die Daten in den LOB Segmenten werden in Chunks unterteilt. Sie bilden eine kleinste Einheit für den Zugriff und die Manipulation und müssen ein Vielfaches der Blocksize sein. Bei BasicFiles können sie maximal 32K groß sein und sind immer gleich groß. Hier wird es mit Oracle 11g spannend. Mit dem Zeitalter der SecureFiles sind diese Chunkgrößen nämlich dynamisch und können auch weitaus größer als nur 32K werden. Der Parameter Chunk ist jedoch nach wie vor auch für SecureFiles gültig, er dient jedoch nur noch der Abwärtskompatibilität bzw. wird vom Oracle Server als Vorschlag erachtet. Lesekonsistenz Bezüglich Lesekonsistenz gibt es auch eine Neuerung im Vergleich zu BasicFiles. Der PCTVersion Parameter, mit welchem es möglich war, eine Prozentzahl des Platzes des LOB Segmentes für alte LOB Versionen anzugeben, ist für SecureFiles nicht mehr gültig 1. Hier kommt nur noch der Retention Parameter zum Einsatz. Bei diesem besseren Ansatz wird nicht ein Prozentsatz sondern eine Zeitperiode definiert. Und dieser Parameter wird mit den SecureFiles noch erweitert. Man kann neben dem Default AUTO, welches nur konsistentes Lesen sicherstellt, auch MIN plus eine Zeitspanne in Sekunden angeben. Ein weiterer Wert für Retention ist MAX. Alte LOB Versionen werden dann bis zu einer anzugebenen MAXSIZE (Größe des Segments) gespeichert. Sind alle aktuellen Versionen der LOBs jedoch größer als diese MAXSIZE wird keine alte Version mehr im Segment gespeichert. Keine alten Versionen kann man ebenso mit der Einstellung NONE für Retention erreichen. Caching Beim Caching gibt es nichts Neues. Der Default ist nach wie vor NOCACHE, d.h. auf ein LOB wird im Normalfall immer über direct physical reads bzw. writes zugegriffen, und es wird nicht im Buffer Cache abgelegt. CACHE READS ist eine Option, die es erlaubt die Blöcke des LOBs nur für das Lesen zu cachen, nicht für das Schreiben und CACHE cached die Blöcke letztendlich in beiden Fällen. Migration Um Daten von BasicFiles zu SecureFiles zu migrieren, gibt es leider keine einfachen Methoden. Die Daten müssen wirklich bewegt werden. Als Möglichkeiten zur Migration möchte ich Create table as select, insert into select, alter table move lob, export und import, Data Pump und Online Table Redefinition mittels DBMS_REDEFINITION 1 Versucht man ein LOB als SecureFile mit dem PCTVersion Parameter anzulegen, so bekommt man einen Fehler ORA-22853: invalid LOB storage option specification. Seite 2 / 15

3 nennen. Die letztgenannte ist die einzige, die es ermöglicht online Migrationen durchzuführen, ohne zugreifende Applikationen zu behindern. Syntax und init.ora Parameter Die Syntax für die Anlage eines SecureFiles, ist hier schematisch dargestellt: CREATE TABLE <TABELLE> ( <SPALTEN>, <LOBSPALTE> BLOB,... ) <STORAGE KLAUSEL FUER TABELLENSEGMENT> LOB (<LOBSPALTE>) STORE AS SECUREFILE <LOBSEGMENTNAME> ( TABLESPACE <TABLESPACENAME> DISABLE STORAGE IN ROW <STORAGE KLAUSEL FUER LOBSEGMENT> ) ; Konkrete Beispiele werden im Laufe des Artikels folgen. Die vollständige Syntaxbeschreibung finden Sie in der Oracle Dokumentation. Sollten Sie keinen Zugriff auf die SQL Anweisungen haben, welche die Tabellen erstellen und die Speicherungsmethode nicht nachträglich mühsam ändern wollen, dann sind vielleicht folgende Parameter welche Sie auch auf Session Ebene ändern können interessant: Name Bedeutung Defaultwert DB_SECUREFILE NEVER bedeutet, dass PERMITTED SecureFiles mit Fehler verweigert werden. PERMITTED bedeutet, dass SecureFiles angelegt werden können, es muss aber auch so spezifiziert werden. Bei ALWAYS werden wenn möglich immer SecureFiles angelegt. Bei IGNORE werden SecureFiles immer ignoriert und BasicFiles angelegt. _KDLXP_LOBCOMPRESS Wenn TRUE wird ein FALSE SecureFile immer komprimiert (medium Kompression) unabhängig der Spezifikation. _KDLXP_LOBDEDUPLICATE Wenn TRUE wird ein FALSE SecureFile immer dedupliziert angelegt unabhängig der Spezifikation. BasicFile vs. SecureFile Oracle verspricht mit den neuen SecureFiles wie schon gesagt eine verbesserte Zugriffsperformance. Bei meinen Tests und Vergleichen von Performancewerten stellte ich fest, dass die Relation stark von der Leistung der Hardware abhängig ist. In der folgenden Tabelle sind Lese- und Schreibwerte eines 100 MB LOBs auf verschiedener Hardware Seite 3 / 15

4 zusammengestellt, installiert war jeweils Oracle Oracle Blocksize war 8k und die Chunksize des BasicFiles 8K. Das LOB stand auf dem Default LOGGING, die Datenbank war im NOARCHIVELOG Modus. Für die LOBs wurde der Default NOCACHE 2 verwendet. Hardware Lesen, Vergleich Lesen eines LOBs Schreiben des LOBs Lesen und von 2 LOBs mittels 100 MB mittels mittels Schreiben, Kopie dbms_lob.compare JDBC thin dbms_lob.loadfromfile eines LOBs (2 x 100MB) innerhalb des selben Segments mittels insert into select BF SF BF SF BF SF BF SF A1 1,8 s 1,2 s 3,6 s 3,2 s 4,2 s 1,5 s 5,2 s 3,6 s A2 17,9 s 5,1 s 12,2 s 4,9 s 4,7 s 4,1 s 15,2 s 6,3 s B1 4,0 s 11,5 s 2,9 s 3,6 s 22,1 s 79,0 s 12,5 s 79,7 s B2 2,6 s 1,5 s 2,9 s 3,5 s 8,3 s 75,3 s 6,7 s 76,3 s Hardware: A1: Linux x86, 2x Intel Xeon CPU 2.40GHz, I/O Durchsatz mit dd: 80 MB/s A2: wie A1, Datenfiles jetzt auf nfs, I/O Durchsatz nun 40 MB/s B1: Solaris 10, Sun Fire V210, 2x UltraSPARC-IIIi 1336 MHz, I/O Durchsatz mit dd: 48 MB/s. B2: wie B1, Datenfiles jetzt auf einer ramdisk BF.. BasicFile SF.. SecureFile Durch die Tests konnte ganz klar erkannt werden, dass BasicFiles lediglich Ansprüche an das I/O Subsystem und kaum an die CPU stellen. Das ist bei SecureFiles ganz offensichtlich nicht so. SecureFiles Performance ist stark von der CPU Leistung abhängig. SecureFiles können nur mit starken CPUs die BasicFiles auf der Strecke lassen, was sie dann aber auch sehr beachtlich machen. Ist die CPU hingegen schwach, so wird ein SecureFile Zugriff langsamer als ein BasicFile Zugriff auf derselben Hardware. Daraus folgt, dass für den Einsatz von SecureFiles adäquate Hardware verwendet werden muss, um auch den von Oracle prophezeiten Performancegewinn zu erzielen. Kurzum SecureFiles sind nur auf aktueller leistungfähiger Hardware schneller als BasicFiles. LOB Komprimierung Die LOB Komprimierung ermöglicht nun SecureFiles binär zu komprimieren. Dadurch kann der Speicherplatz abhängig von Komprimierbarkeit reduziert werden. Es ist als ein Trade Off zwischen Storage Reduzierung und CPU Nutzung zu verstehen, denn das Komprimieren und Dekomprimieren verlangt natürlich etwas mehr CPU Ressourcen. Komprimierung kann in zwei verschiedenen Stufen eingeschaltet werden: MEDIUM und HIGH. Sie steuert letztendlich die Aggressivität des Komprimierungsalgorithmus, der auf ZLIB 3 basiert. Die Komprimierung erfolgt transparent für die Zugriffsschicht, d.h. bestehende Applikationen brauchen darauf nicht angepasst zu werden. LOB Komprimierung lässt sich pro Segment also, pro Tabelle, Partition 2 In diesem Tests ging es um die native I/O Performance, daher wurde nicht gecached. Bei einem Caching des LOBs würden die Ergebnisse natürlich abweichen. 3 Eine Session mit dem Debugger gdb zeigte die verwendete Oracle Kernel Funktion: kgcczlibdo. Seite 4 / 15

5 oder Subpartition einstellen. Ohne diese neue LOB Komprimierung stand bisher lediglich eine manuelle Komprimierung auf Applikationsschicht oder in der Datenbank, z.b. durch das in 10g eingeführte Package UTL_COMPRESS zu Verfügung. Betrachten wir folgendes Beispiel: Ein großes Textfile und ein Zip Archiv, welches dieses File enthält werden betrachtet. # ls -al -rw-r--r-- 1 oracle dba Jul 14 11:57 large_txt_file.txt -rw-r--r-- 1 oracle dba Jul 15 16:15 large_txt_file.zip Die Textdatei ist ca. 100 MB groß. Das mit Standard zip gepackte Archiv ist ca. 26 MB groß. 74 Prozent des Storage wurden damit also eingespart. Jetzt wollen wir sehen, ob das mit der Oracle Datenbank auch möglich ist. Dafür legen wir 4 Tabellen an. Das LOB Feld in der Tabelle ist jedesmal anders gespeichert. Einmal als BasicFile, einmal als Standard SecureFile, einmal als medium komprimiertes SecureFile und zuguterletzt noch als hoch komprimiertes SecureFile. In diese LOBs laden wir dann die Textdatei und vergleichen die Größen: SQL> create table lobtest_bf 2 ( 3 id number not null, 4 data blob 5 ) 6 lob (data) store as basicfile datablob_bf (disable storage in row) 7 ; Table created. Elapsed: 00:00:00.06 SQL> create table lobtest_sf 2 ( 3 id number not null, 4 data blob 5 ) 6 lob (data) store as securefile datablob_sf (disable storage in row) 7 ; Table created. Elapsed: 00:00:00.04 SQL> create table lobtest_comp_med 2 ( 3 id number not null, 4 data blob 5 ) 6 lob (data) store as securefile datablob_comp_med (disable storage in row compress medium) 7 ; Table created. Elapsed: 00:00:00.03 SQL> create table lobtest_comp_high 2 ( 3 id number not null, 4 data blob 5 ) 6 lob (data) store as securefile datablob_comp_high (disable storage in row compress high) 7 ; Table created. Elapsed: 00:00:00.04 SQL> insert into lobtest_bf (id,data) values 2 (1,empty_blob()); 1 row created. Elapsed: 00:00:00.00 SQL> declare 2 dest_loc blob; 3 src_loc bfile; 4 amount integer; 5 begin 6 src_loc:= 7 bfilename('dir','large_txt_file.txt'); 8 select data into dest_loc 9 from lobtest_bf for update; 10 amount := dbms_lob.getlength(src_loc); 11 dbms_lob.open(src_loc, 12 dbms_lob.lob_readonly); 13 dbms_lob.open(dest_loc, 14 dbms_lob.lob_readwrite); 15 dbms_lob.loadfromfile(dest_loc, 16 src_loc, amount); 17 dbms_lob.close(dest_loc); 18 dbms_lob.close(src_loc); 19 end; 20 / Elapsed: 00:00:05.88 SQL> insert into lobtest_sf 2 select * from lobtest_bf; 1 row created. Elapsed: 00:00:03.26 SQL> insert into lobtest_comp_med 2 select * from lobtest_bf; 1 row created. Elapsed: 00:00:06.54 SQL> insert into lobtest_comp_high 2 select * from lobtest_bf; 1 row created. Elapsed: 00:00:21.13 SQL> commit; Commit complete. Elapsed: 00:00:00.02 SQL> select segment_name,bytes from user_segments 2 where segment_type = 'LOBSEGMENT'; SEGMENT_NAME BYTES DATABLOB_BF DATABLOB_SF DATABLOB_COMP_MED DATABLOB_COMP_HIGH Elapsed: 00:00: Seite 5 / 15

6 Die längeren Laufzeiten der Inserts erklären sich durch den zusätzlichen Aufwand der Komprimierung. Der eigentliche Platzbedarf in den Segmenten ist noch geringer, da in der obigen Query auch leere vorreservierte Blöcke in den Extents mitgerechnet wurden. Der genaue Platzbedarf lässt sich mit dem DBMS_SPACE Package ermitteln, welches dafür mit 11g einen neuen Aufruf der Prozedur SPACE_USAGE bekommen hat. Dafür habe ich folgende PL/SQL Prozedur genutzt. Die Prozedur erwartet als Eingabe den Segmentnamen und funktioniert für SecureFiles im aktuellen Schema. create or replace procedure lobsegmentsize(lobsegment_name varchar2) as segment_size_blocks number; segment_size_bytes number; used_blocks number; used_bytes number; expired_blocks number; expired_bytes number; unexpired_blocks number; unexpired_bytes number; begin dbms_space.space_usage(user,lobsegment_name,'lob', segment_size_blocks,segment_size_bytes,used_blocks,used_bytes, expired_blocks,expired_bytes,unexpired_blocks,unexpired_bytes); dbms_output.put_line(lobsegment_name); dbms_output.put_line(' '); dbms_output.put_line('segment_size_bytes = ' segment_size_bytes); dbms_output.put_line('used_bytes = ' used_bytes); end; / SQL> exec lobsegmentsize('datablob_sf'); DATABLOB_SF segment_size_bytes = used_bytes = SQL> exec lobsegmentsize('datablob_comp_med'); DATABLOB_COMP_MED segment_size_bytes = used_bytes = SQL> exec lobsegmentsize(datablob_comp_high'); DATABLOB_COMP_HIGH segment_size_bytes = used_bytes = Der Platzbedarf des hoch komprimierten SecureFiles liegt also auch bei ca. 26 MB und kommt damit auch an die Rate von zip heran. Wir können also durchaus gute Platzersparnisse erzielen. Wie gut sich Daten jedoch überhaupt komprimieren lassen hängt natürlich so wie bei jeder Binärkomprimierung von ihrem Typ ab. LOB Deduplizierung Betrachtet man Komprimierungsalgorithmen im Allgemeinen, so gibt es immer ein wesentliches Prinzip: Wiederholt auftauchende Werte, Sequenzen, Symbole etc. werden nicht wiederholt gespeichert, sondern dedupliziert. Dieses Prinzip gibt es nun auch in der Oracle Datenbank für ganze LOBs. Legt man eine Tabelle, Partition oder Subpartition entsprechend an, so werden sich wiederholende LOBs nur einmal gespeichert. Das geschieht, indem beim Einfügen zur Laufzeit eine Checksumme berechnet wird. Gibt es diese Checksumme schon im gleichen Seite 6 / 15

7 Segment, so wird nur noch eine Referenz auf das schon existierende LOB gespeichert. Die Checksumme wird defaultmäßig mit SHA1 berechnet. 4 Die Erkennung von Duplikaten kann nur in demselben Segment erfolgen, d.h. es funktioniert nicht partitionsübergreifend und schon gar nicht tabellenübergreifend. Dieses Feature ist besonders interessant für Dokumentenmanagementsysteme, in welchen Dokumente in Form von LOBs durch zum Beispiel Multiversions- oder Multiusermanagement redundant gespeichert werden. Betrachten wir noch einmal das Beispiel von oben: SQL> create table lobtest_dedup 2 ( 3 id number not null, 4 data blob 5 ) 6 lob (data) store as securefile datablob_dedup (disable storage in row deduplicate) 7 ; Table created. Elapsed: 00:00:00.10 SQL> insert into lobtest_dedup select * from lobtest_sf; 1 row created. Elapsed: 00:00:06.90 SQL> insert into lobtest_dedup select * from lobtest_sf; 1 row created. Elapsed: 00:00:03.07 SQL> commit; Commit complete. Elapsed: 00:00:00.01 SQL> select count(*) from lobtest_sf; COUNT(*) Elapsed: 00:00:00.00 SQL> select count(*) from lobtest_dedup; COUNT(*) Elapsed: 00:00:00.01 SQL> select segment_name,bytes from user_segments 2 where segment_name in ('DATABLOB_SF','DATABLOB_DEDUP'); SEGMENT_NAME BYTES DATABLOB_DEDUP DATABLOB_SF Elapsed: 00:00:00.57 SQL> exec lobsegmentsize('datablob_sf'); DATABLOB_SF segment_size_bytes = used_bytes = Elapsed: 00:00:00.02 SQL> exec lobsegmentsize('datablob_dedup'); DATABLOB_DEDUP segment_size_bytes = used_bytes = Elapsed: 00:00: Der hidden Parameter _kdlxp_dedup_hash_algo legt den Algorithmus fest. SHA2 und MD5 sind ebenfalls verfügbar. Seite 7 / 15

8 Wir können sehen, dass das erneute Einfügen des LOBs, welches schon im Segment vorhanden ist zu dem gewünschten Effekt führt. Dadurch sparen wir Speicherplatz. Zusätzlich gewinnen wir in dem Falle eines Inserts wie hier auch an Performance, da nur noch der SHA1 Hash gespeichert werden muss. Performance Einflüsse der LOB Komprimierung LOB Komprimierung und LOB Deduplizierung können wie schon erwähnt einzeln oder auch kombiniert Anwendung finden. Doch welchen Performance Overhead kosten diese Features? Wie sollten die LOBs für beste Performance konfiguriert werden? Diese Fragen sollen nun beleuchtet werden. Ich habe dafür Tests mit LOBs in verschiedenen Szenarien gemacht. Die LOBs wurden dabei gelesen und geschrieben. Die LOBs wurden mit unterschiedlichen Einstellungen in Bezug auf ihre Art der Komprimierung, des Caching, der Blocksize des zugrundeliegenden Tablespaces angelegt. Leseperformance Zunächst ein Beispiel anhand einer kleinen Tuning Session : Ausgangspunkt ist eine Tabelle documents mit einem BLOB. SQL> desc documents Name Null? Type ID NOT NULL NUMBER VERSION NOT NULL NUMBER NAME NOT NULL VARCHAR2(255) MIME_TYPE VARCHAR2(30) BYTES NUMBER MODIFIED DATE DATA BLOB Diese Tabelle hat für diesen Test lediglich einen Datensatz mit dem bekannten Textfile: SQL> select * from documents; ID VERSION NAME MIME_TYPE BYTES MODIFIED large_txt_file.txt text/plain SEP-09 Folgender PL/SQL Block, welche das LOB liest, soll getuned werden. declare lob_1 blob; lob_2 blob; length number; begin select data,dbms_lob.getlength(data) into lob_1,length from documents where id=1 and version=1; dbms_lob.createtemporary(lob_2,cache => &1); dbms_lob.copy(lob_2,lob_1,length); end; / Ca. 10 Sekunden dauert der Lauf für das BasicFile 5 mit dem Default cache = false in dem CREATETEMPORARY Aufruf. Das kann man doch vielleicht noch schneller schaffen: Man ändert in der PL/SQL Prozedur in dem Aufruf von CREATETEMPORARY den Parameter cache auf true, und nun sind es knapp 3 Sekunden. Der Grund dafür ist, dass temporary LOBs die nicht gecached sind, durch I/O Operationen auf dem TEMP Tablespace realisiert werden, egal 5 Hardware: Linux x86, 2x Intel Xeon CPU 2.40GHz, I/O Durchsatz mit dd: 80 MB/s Seite 8 / 15

9 wie groß sie sind. In den Wait Events macht sich das durch vermehrtes direct path read/write temp bemerkbar. Cached temporary LOBs werden hingegen im Memory realisiert, was für kleine bis mittelgroße LOBs anzustreben ist. Okay, aber die I/Os auf das gelesene LOB sind auch noch alles direct path reads, d.h. die gelesenen Blöcke werden nicht gecached. Cached man das Ganze, dann wäre wohl noch mehr herauszuholen. SQL> alter table documents modify lob (data) (cache reads); Table altered. Nein Irrtum in meinen Tests verbessert es die Raten nicht. Wie sieht es nun allerdings mit SecureFiles und komprimierten SecureFiles aus? alter table documents move lob (data) store as securefile; alter table documents modify lob (data) (nocache); Gute 2 Sekunden dauert der PL/SQL Block auf dem SecureFile. Bringt das Caching hier etwas? alter table documents modify lob (data) (cache reads); Nein nicht wirklich. Die Werte für einen Lauf schwanken hier auf einmal zwischen 2 und 5 Sekunden. Na gut dann wird jetzt noch komprimiert: alter table documents move lob (data) store as securefile (compress high); alter table documents modify lob (data) (nocache); Ob es dadurch schneller wird? Wohl kaum, wir haben ja den Overhead des Dekomprimierens. In der Tat, es dauert ca. 5 Sekunden. Und bringt das Cachen hier etwas? alter table documents modify lob (data) (cache reads); Ja, es sind ca. 4 Sekunden! Auch schon im ersten Lauf ohne Cache Warmup. Aber warum? Warum bringt es was bei komprimierten Daten? Diese Frage wird später beantwortet. Zuguterletzt war da ja noch der Tablespace mit der größeren Blocksize: alter table documents move lob (data) store as securefile (compress high tablespace users_16k); alter table documents modify lob (data) (nocache); Ja das bringt auch etwas. Knapp 3 Sekunden läuft der PL/SQL Block nun. Warum hat das Cachen auf der komprimierten Tabelle nun etwas gebracht? In meinen Tests bemerkte ich, dass die Werte für physical read bytes in der View V$SESSTAT höher lagen, als das BLOB eigentlich groß war, und das obwohl ich erwartete, dass es durch die Komprimierung ja kleiner sein muss. Das LOB ist im Segment defacto ja auch kleiner, wie wir vorher schon gesehen haben. D.h. es kann nur so sein, dass gewisse Blöcke mehrfach gelesen werden. Und diese dunkle Ahnung hat sich bestätigt, als ich die Leseoperationen mit einem Trace mittels DBMS_MONITOR.SESSION_TRACE_ENABLE untersucht habe. Folgendermaßen sah das Lesen eines komprimierten LOBs aus: Seite 9 / 15

10 Lesen eines medium komprimierten LOBs Blocknummer Zeit In der Grafik sind von den Multiblock I/Os Operationen (direct path read) jeweils der Startblock angegeben. Der von Oracle gewählte Algorithmus zum Dekomprimieren erfordert offenbar das wiederholte Lesen von Blöcken. Warum das so ist, konnte oder wollte Oracle mir in einem laufenden Service Request bis heute nicht erklären. Nun, und durch das wiederholte Lesen der Blöcke bringt das Cachen natürlich etwas. Folgendes Beispiel zeigt das deutlich, hier werden zwei medium komprimierte LOB mittels DBMS_LOB.COMPARE verglichen: SQL> REM eine zweite Row mit demselben LOB erzeugen SQL> insert into documents select 1,2,name,mime_type,bytes,modified,data from documents; 1 row created. SQL> commit; Commit complete. SQL> alter table documents move lob (data) store as securefile (compress medium); Table altered. SQL> REM neu connecten um v$mystat zu "initialisieren" SQL> connect scott/tiger Connected. SQL> set serveroutput on timing on SQL> column name format a30 SQL> column value format SQL> REM Wie groß ist das LOB-Segment? SQL> exec lobsegmentsize('datablob'); DATABLOB segment_size_bytes = used_bytes = Elapsed: 00:00: Seite 10 / 15

11 SQL> REM der dbms_lob.compare Aufruf SQL> declare 2 lob_1 blob; 3 lob_2 blob; 4 retval integer; 5 begin 6 select data into lob_1 from documents 7 where id=1 and version=1; 8 select data into lob_2 from documents 9 where id=1 and version=2; 10 retval := dbms_lob.compare(lob_1, lob_2); 11 if retval = 0 then 12 dbms_output.put_line('equal'); 13 else 14 dbms_output.put_line('not equal'); 15 end if; 16 end; 17 / equal Elapsed: 00:00:47.76 SQL> REM Wieviel wurde gelesen? SQL> select name, value from v$mystat natural join v$statname where name = 'physical read bytes'; NAME VALUE physical read bytes Elapsed: 00:00:00.00 SQL> REM Und jetzt das LOB auf CACHE READS setzen SQL> alter table documents modify lob (data) (cache reads); Table altered. Elapsed: 00:00:02.33 SQL> REM den Buffer Cache ausleeren um etwaige Seiteneffekte auszuschließen SQL> conn / as sysdba Connected. SQL> alter system flush buffer_cache; System altered. Elapsed: 00:00:01.59 SQL> REM neu connecten um v$mystat zu "initialisieren" SQL> conn scott/tiger Connected. SQL> set serveroutput on SQL> REM der dbms_lob.compare Aufruf SQL> declare 2 lob_1 blob; 3 lob_2 blob; 4 retval integer; 5 begin 6 select data into lob_1 from documents 7 where id=1 and version=1; 8 select data into lob_2 from documents 9 where id=1 and version=2; 10 retval := dbms_lob.compare(lob_1, lob_2); 11 if retval = 0 then 12 dbms_output.put_line('equal'); 13 else 14 dbms_output.put_line('not equal'); 15 end if; 16 end; 17 / equal Elapsed: 00:00:18.10 SQL> REM Und wieviel wurde jetzt von Disk gelesen? SQL> select name, value from v$mystat natural join v$statname where name = 'physical read bytes'; NAME VALUE physical read bytes Elapsed: 00:00:00.00 Durch das Caching des LOBs wurden die physical reads von über 11 GB!! auf 61 MB reduziert. Das entspricht einer I/O Reduktion um 99,5 Prozent!!!. Die Laufzeit hat sich um ca. 60 Prozent verkürzt. Das sind enorme Faktoren. Seite 11 / 15

12 In folgender Tabelle sind die gemessenen Werte für verschiedene LOB Einstellungen zusammengefasst: LOB Einstellungen NOCOMPRESS KEEP_DUPLICATES COMPRESS MEDIUM KEEP_DUPLICATES COMPRESS HIGH KEEP_DUPLICATES NOCOMPRESS DEDUPLICATE COMPRESS MEDIUM DEDUPLICATE COMPRESS HIGH DEDUPLICATE LOB Segment Größe in MB NOCACHE Physical Zeit Reads in in s MB CACHE READS Physical Zeit Reads in in s MB I/O Einsparung in Prozent , , , ,7 99,5 62, , ,6 99,5 61, , ,2 99,2 94, ,5 31 4,9 96,5 24, ,0 26 4,4 96,7 37,1 Zeit Einsparung in Prozent Die Einstellung CACHE bei den LOBs ist nicht extra ausgewiesen, da sich bei lesenden Operationen der Effekt von CACHE nicht von dem von CACHE READS unterscheidet. Gut diese fiktiven Tuning Sessions bezogen sich lediglich auf das Lesen mittels DBMS_LOB. Dennoch werden hier einige wichtige Grundsätze klar: - Caching in der API oder am Client sind ein wesentlicher Aspekt. - Caching von temporären LOBs (hier in DBMS_LOB.CREATETEMPORARY) steigert die Performance, da TEMP Tablespace I/O-Operationen vermieden werden - Eine größere Blocksize verbessert die Leseperformance von großen LOBs 6. Außerdem ist hier noch der Aspekt des separaten Caches anzubringen. Durch einen eigenen Cache, der für das Betreiben von Tablespaces mit einer Blocksize verschieden der Datenbank Default Blocksize notwendig ist, wird die Cache Hit Ratio des Default Buffer Cache nicht durch etwaiges LOB Caching beeinflusst. Dadurch wird die Performance für normale Tabellen nicht in Gefahr gebracht. - Caching am Server lohnt sich im Spezialfall des Lesens von komprimierten und/oder deduplizierten LOBs und das nicht nur bei wiederholtem Lesen. Erstaunlich ist, dass auch die Deduplizierung diesen Effekt mit dem multiplen Lesen mit sich bringt, welcher im Falle NOCOMPRESS noch relativ dramatisch ist, sich jedoch mit der Komprimierung dann etwas relativiert, auch schon ohne Caching. Ähnliche Performancekennzahlen und -trends wurden auch beim lesenden Zugriff mit JDBC festgestellt, sowohl für JDBC OCI als auch für JDBC Thin Zugriffe. Daher kann ausgeschlossen werden, dass es sich bei den oben gemessenen Werten nur um ein Phänomen im Zusammenhang mit der DBMS_LOB API handelt. 6 Vorsicht: Verwenden Sie keine Blocksize für LOBs die größer ist als die durchschnittliche Größe der LOBs. Das verschwendet zu viel Platz. Seite 12 / 15

13 Schreibperformance Wir machen mit dem oberen Beispiel weiter und wollen nun schließlich noch die Schreibperformance untersuchen. Die 2 Datensätze aus der Tabelle werden dabei mittels Insert in eine vorbereitete Tabelle kopiert und dabei die Zeit sowie die physical reads und writes gemessen. Die Quelltabelle wird zunächst wieder auf Standard SecureFile zurückgestellt. Dann wird die neue Table erstellt und die Daten hineinkopiert: SQL> alter table documents move lob (data) store as securefile (nocache nocompress keep_duplicates); Table altered. Elapsed: 00:00:12.71 SQL> CREATE TABLE documents_comp_med 2 ( 3 ID NUMBER NOT NULL ENABLE, 4 VERSION NUMBER NOT NULL ENABLE, 5 NAME VARCHAR2(255) NOT NULL ENABLE, 6 MIME_TYPE VARCHAR2(30), 7 BYTES NUMBER, 8 MODIFIED DATE, 9 DATA BLOB 10 ) 11 LOB (DATA) STORE AS SECUREFILE DATABLOB_COMP_MED (DISABLE STORAGE IN ROW COMPRESS MEDIUM) 12 ; Table created. Elapsed: 00:00:00.06 SQL> REM neu connecten um v$mystat zu "initialisieren" SQL> conn scott/tiger Connected. SQL> insert into documents_comp_med select * from documents; 2 rows created. Elapsed: 00:00:26.32 SQL> commit; Commit complete. Elapsed: 00:00:00.11 SQL> select name, value from v$mystat natural join v$statname 2 where name in ('physical read bytes','physical write bytes','redo size'); NAME VALUE physical read bytes physical write bytes redo size Elapsed: 00:00:00.01 SQL> alter table documents_comp_med modify lob (data) (cache); Table altered. Elapsed: 00:00:00.04 SQL> truncate table documents_comp_med; Table truncated. Elapsed: 00:00:04.72 SQL> REM neu connecten um v$mystat zu "initialisieren" SQL> conn scott/tiger Connected. SQL> insert into documents_comp_med select * from documents; 2 rows created. Elapsed: 00:00:33.02 SQL> commit; Commit complete. Elapsed: 00:00:00.01 SQL> select name, value from v$mystat natural join v$statname 2 where name in ('physical read bytes','physical write bytes','redo size'); NAME VALUE physical read bytes Seite 13 / 15

14 physical write bytes 0 redo size Elapsed: 00:00:00.01 Es ist also festzustellen, dass das Caching hier das Schreiben verzögert, also eher einen negativen Effekt hat. Folgende Tabelle fasst die Performancedaten für diesen Lauf und für alle anderen Arten von Tabellen zusammen. Quelle der beiden Datensätze war immer die gleiche Tabelle mit dem Standard SecureFile. Da die Zeiten hier teilweise recht stark schwankten, habe ich hier die durchschnittlichen Werte aus 10 Läufen notiert: LOB Einstellungen der Zieltabelle NOCOMPRESS KEEP_DUPLICATES COMPRESS MEDIUM KEEP_DUPLICATES COMPRESS HIGH KEEP_DUPLICATES NOCOMPRESS DEDUPLICATE COMPRESS MEDIUM DEDUPLICATE COMPRESS HIGH DEDUPLICATE LOB Segment Größe in MB NOCACHE Physical Redo Writes in Size MB in MB Ø Zeit in s Physical Writes in MB 7 CACHE Redo Size in MB Ø Zeit in s ,6 8, , ,3 24, , ,2 70, , ,3 7, , ,1 26, , ,1 63, ,2 Die Einstellung CACHE READS bei den LOBs ist nicht extra ausgewiesen, da sich bei schreibenden Operationen der Effekt von CACHE READS nicht von dem von NOCACHE unterscheidet. Alle LOBs standen auf normalem LOGGING, d.h. über die Redo Logs wurde sichergestellt, dass sie wiederherstellbar / recoverable sind. Diese Zahlen offenbaren nun recht interessante Erkenntnisse: Wie schon erwähnt bei der Tabelle mit dem medium komprimierten LOBs macht das Caching fürs Schreiben wenig Sinn. Die Laufzeit erhöht sich im Schnitt um 10 Sekunden. Jedoch kippt dieses Bild bei Steigerung der Komprimierungsrate und/oder bei der Hinzunahme von Deduplizierung, auch wenn es nicht zu enormen Performancesteigerungen kommt. Jedoch Vorsicht: Die Raten für das Schreiben in cached LOBs sind auch stark von der Performance des Log Writers abhängig, z.b. von der Anzahl der Redo Log Member pro Redo Log Gruppe. In meinen Tests wurde nicht gespiegelt. In Produktionsumgebungen sollte aber unbedingt gespiegelt werden, d.h. dort relativiert sich das Bild wieder. Ein weiterer Aspekt ist, dass es sich hier um ein großes Textdokument handelte, welches sehr stark komprimiert werden konnte. Alles in allem denke ich, dass das Cachen von SecureFile LOBs schon beim Schreiben nicht generell zu empfehlen ist. Es mag aber den einen oder anderen Ausnahmefall geben, bei welchem es sich lohnt. Dieses wäre dann aber für die jeweilige Applikation in ausführlichen Tests zu verifizieren. Das Schreiben in LOBs mittels DBMS_LOB.LOADFROMFILE oder mit jdbc zeigte ähnliche Resultate. Im Falle der Verwendung von großen LOBs ist eine höhere Blocksize für die LOB Tablespaces auch im Hinblick auf die Schreiboperationen zu empfehlen. 7 Im Falle Cache wird nicht von der Server Session direkt in die Datafiles geschrieben. Das übernimmt hier der Database Writer mit einer Verzögerung. Daher misst die Session keinerlei physical write bytes. Seite 14 / 15

15 Empfehlungen zum Setup von komprimierten LOBs Folgende Empfehlungen für eine beste Performance ergeben sich nun unter anderem aus meinen Tests: - Verwenden Sie komprimierte LOBs nur auf aktueller leistungsfähiger Hardware. - Verwenden Sie enable storage in row nur, wenn in die Majorität der Queries auf der Table das entsprechende LOB mit abfragt, ansonsten verwenden Sie disable storage in row. - Verwenden Sie eigene Tablespaces für die großen LOBs und geben Sie diesen eine höhere Blocksize. Das hat auch den Vorteil, dass damit für die LOBs ein weiterer eigener Buffer Cache entsteht. - Setzen Sie die komprimierten LOBs auf CACHE READ. - Setzen sie die Parameter für die LOB Retention nur so gering wie nötig. - Erwägen Sie den Einsatz von FILESYSTEM_LIKE_LOGGING oder gar NOLOGGING nachdem Sie sich über das Risiko von Nologging Operationen bewusst sind. - Testen und verifizieren Sie Ihr Setup für die beste Performance. Fazit Oracle LOB Komprimierung und Deduplizierung sind eine gute Möglichkeit Speicherplatz zu sparen. Oracle verspricht auf seiner Homepage 8 auch die Performance zu verbessern. Zu diesem Punkt muss man jedoch ganz klar sagen, dass es von vielen Faktoren abhängt, ob die Performance wirklich besser wird. Sie kann unter gewissen Umständen auch schlechter werden. Gute Tests bevor man das Feature in Produktion einsetzt sind daher wichtig. Immer viel Freude an Ihren komprimierten LOBs wünscht Mathias Zarick Trivadis GmbH Millennium Tower Handelskai A-1200 Wien Tel.: Fax: Kontaktieren Sie mich bitte, wenn Sie weitere Details oder Hilfe beim Setup von komprimierten LOBs benötigen. Quellenangabe [1] Oracle, Oracle Database SecureFiles and Large Objects Developer's Guide, 11g Release 1, [2] Oracle, Oracle Database PL/SQL Packages and Types Reference, 11g Release 1, 8 Seite 15 / 15

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

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

Mehr

Oracle 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

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

die wichtigsten Caches (SGA) sind on-the-fly änderbar.

die wichtigsten Caches (SGA) sind on-the-fly änderbar. Betrifft Autor Umgang und Verwaltung von Oracle Memory Reno Glass (Reinhold.Glass@trivadis.com) Art der Info Technische Background Info (April 2002) Quelle Aus dem NF9i -Kurs und NF9i-Techno-Circle der

Mehr

Verschlüsseln als Überlebensstrategie

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

Mehr

DOAG 2015. Demo Kino: Advisors, Monitoring Werkzeuge in der Datenbank Ulrike Schwinn Business Unit Database Oracle Deutschland B.V.

DOAG 2015. Demo Kino: Advisors, Monitoring Werkzeuge in der Datenbank Ulrike Schwinn Business Unit Database Oracle Deutschland B.V. DOAG 2015 Demo Kino: Advisors, Monitoring Werkzeuge in der Datenbank Ulrike Schwinn Business Unit Database Oracle Deutschland B.V. & Co KG Monitoring Werkzeuge, Advisors... Einfaches Framework zum Monitoring

Mehr

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

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

Mehr

www.informatik-aktuell.de

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

Mehr

Datenbankstatistiken im Griff mit DBMS_STATS. DOAG 2012 Konferenz + Ausstellung Nürnberg 21. November 2012

Datenbankstatistiken im Griff mit DBMS_STATS. DOAG 2012 Konferenz + Ausstellung Nürnberg 21. November 2012 Datenbankstatistiken im Griff mit DBMS_STATS DOAG 2012 Konferenz + Ausstellung Nürnberg 21. November 2012 Herrmann & Lenz Services GmbH Herrmann & Lenz Solutions GmbH Erfolgreich seit 1996 am Markt Firmensitz:

Mehr

Objektrelationale und erweiterbare Datenbanksysteme

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

Mehr

Oracle Database 11gR2 Effiziente Datenspeicherung. Vorteile von Komprimierung

Oracle Database 11gR2 Effiziente Datenspeicherung. Vorteile von Komprimierung Oracle Database gr2 Effiziente Datenspeicherung Vorteile von Komprimierung Einsparung von Plattenplatz (Storage) Kosten- und Ressourcenreduktion (Green IT) Effizientere Buffer Cache Nutzung Effizientere

Mehr

Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur. Subject. New Features Oracle 9i Architecture

Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur. Subject. New Features Oracle 9i Architecture Naxtron GmbH Schlosstalstrasse 210 8408 Winterthur Subject New Features Oracle 9i Architecture Author Edo Bezemer Oracle Engineering Date August 2002 INHALTSVERZEICHNIS ARCHITEKTUR...3 SERVER PARAMETER

Mehr

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

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

Mehr

Automatisierte Datenmigration mit dynamischen SQL

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

Mehr

SPARC LDom Performance optimieren

SPARC LDom Performance optimieren SPARC LDom Performance optimieren Marcel Hofstetter hofstetter@jomasoft.ch http://www.jomasoftmarcel.blogspot.ch Mitgründer, Geschäftsführer, Enterprise Consultant JomaSoft GmbH 1 Inhalt Wer ist JomaSoft?

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

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

NoSQL mit Postgres 15. Juni 2015

NoSQL mit Postgres 15. Juni 2015 Tag der Datenbanken 15. Juni 2015 Dipl.-Wirt.-Inform. Agenda l Vorstellung l Marktübersicht l Warum PostgreSQL? l Warum NoSQL? l Beispielanwendung Seite: 2 Vorstellung Dipl.-Wirt.-Inform. [1990] Erste

Mehr

Firebird Database Cache Buffer

Firebird Database Cache Buffer Firebird Database Cache Buffer Norman Dunbar 20. Juli 2013 Version 1.3.1-de - deutsche Version Übersetzung ins Deutsche: Martin Köditz Inhaltsverzeichnis Einleitung... 3 Der Firebird-Cache... 3 MON$IO_STATS

Mehr

Oracle Automatic Storage Management (ASM) Best Practices

Oracle Automatic Storage Management (ASM) Best Practices Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management

Mehr

Performance Tuning mit @enterprise

Performance Tuning mit @enterprise @enterprise Kunden-Forum 2005 Performance Tuning mit @enterprise Herbert Groiss Groiss Informatics GmbH, 2005 Inhalt Datenbank RMI JAVA API HTTP Konfiguration Analyse Groiss Informatics GmbH, 2005 2 Datenbank

Mehr

Oracle 12c: Neuerungen in PL/SQL. Roman Pyro DOAG 2014 Konferenz

Oracle 12c: Neuerungen in PL/SQL. Roman Pyro DOAG 2014 Konferenz Oracle 12c: Neuerungen in PL/SQL Roman Pyro DOAG 2014 Konferenz Herrmann & Lenz Services GmbH Herrmann & Lenz Solutions GmbH Erfolgreich seit 1996 am Markt Firmensitz: Burscheid (bei Leverkusen) Beratung,

Mehr

Views in SQL. 2 Anlegen und Verwenden von Views 2

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

Mehr

Datenbank Objekte (Tabellen, Segemente, Extents, Blöcke)

Datenbank Objekte (Tabellen, Segemente, Extents, Blöcke) Datenbank Objekte (, Segemente,, Blöcke) 5. Juni 2007 Datenbank Objekte (, Segemente,, Blöcke) Datenbank Objekte (, Segemente,, Blöcke) Aufbau eines Datenblocks Zeilenverkettung und -verschiebung Freispeicherverwaltung

Mehr

Datenbanken SQL Einführung Datenbank in MySQL einrichten mit PhpMyAdmin

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

Mehr

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

Urs Meier (urs.meier@trivadis.com) Art der Info Technical Info (Februar 2002) Aus unserer Projekterfahrung und Forschung

Urs Meier (urs.meier@trivadis.com) Art der Info Technical Info (Februar 2002) Aus unserer Projekterfahrung und Forschung Betrifft Optimizer Autor Urs Meier (urs.meier@trivadis.com) Art der Info Technical Info (Februar 2002) Quelle Aus unserer Projekterfahrung und Forschung Einführung Mit jedem Oracle Release nimmt die Anzahl

Mehr

WS 2010/11 Datenbanksysteme Fr 15:15 16:45 R 1.008. Vorlesung #6. SQL (Teil 4)

WS 2010/11 Datenbanksysteme Fr 15:15 16:45 R 1.008. Vorlesung #6. SQL (Teil 4) Vorlesung #6 SQL (Teil 4) Fahrplan Besprechung der Übungsaufgaben Einschub: Self Joins (relevant fürs Praktikum) Dynamische Intergritätsbedingungen, das Trigger - Konzept von Oracle Prozedurale Erweiterungen,

Mehr

... Kontrolldatei administrieren

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

Mehr

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL 1 Transaktionen in SQL Um Daten in einer SQL-Datenbank konsistent zu halten, gibt es einerseits die Möglichkeit der Normalisierung, andererseits sog. Transaktionen. 2 Was ist eine Transaktion Eine Transaktion

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Einstellungen zur Verwendung von Flashback-Abfragen

Einstellungen zur Verwendung von Flashback-Abfragen Thema Autor REISE IN DIE VERGANGENHEIT Kamel Bouzenad (kamel.bouzenad@trivadis.com) Art der Info Infos für Entwickler und DBAs (April 2002) Quelle Oracle-Dokumentation sowie beratende Aktivitäten Überblick

Mehr

Prozedurale Datenbank- Anwendungsprogrammierung

Prozedurale Datenbank- Anwendungsprogrammierung Idee: Erweiterung von SQL um Komponenten von prozeduralen Sprachen (Sequenz, bedingte Ausführung, Schleife) Bezeichnung: Prozedurale SQL-Erweiterung. In Oracle: PL/SQL, in Microsoft SQL Server: T-SQL.

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

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

IO Performance in virtualisierten Umgebungen

IO Performance in virtualisierten Umgebungen IO Performance in virtualisierten Umgebungen Bruno Harsch El. Ing. HTL/FH Managing Partner Tel +41 52 366 39 01 bruno.harsch@idh.ch www.idh.ch IDH GmbH Lauchefeld 31 CH-9548 Matzingen 2 Die Firma IDH wurde

Mehr

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Moderne Datenbanksysteme sind nach der 3-Ebenen-Architektur gebaut: Anwendung 1 Web-Anwendung Anwendung 2 Java-Programm... Anwendung n Applikation

Mehr

Dynamisches SQL. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München

Dynamisches SQL. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München Kapitel 4 Dynamisches SQL Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester

Mehr

Oracle und.net sind ein populäres Gespann. Doch wie lassen sich Oracle Features mit.net nutzen?

Oracle und.net sind ein populäres Gespann. Doch wie lassen sich Oracle Features mit.net nutzen? Betrifft Autor Oracle und.net im n-tier Umfeld Urs Meier (urs.meier@trivadis.com) Art der Info Technical Info (April 2003) Quelle Aus unserer Projekterfahrung Einführung Oracle und.net sind ein populäres

Mehr

Dokumentation QuickHMI-Schnittstelle für Oracle Datenbanken

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

Mehr

Roland Tilgner. Solution Architects & Team Coaching DEVELOPMENT. ORACLE TEXT AUS PL/SQL-SICHT Features und Möglichkeiten

Roland Tilgner. Solution Architects & Team Coaching DEVELOPMENT. ORACLE TEXT AUS PL/SQL-SICHT Features und Möglichkeiten Roland Tilgner Solution Architects & Team Coaching DEVELOPMENT ORACLE TEXT AUS PL/SQL-SICHT Features und Möglichkeiten ZURPERSON Roland Tilgner ZURFIRMA Roland Tilgner Solution Architects & Team Coaching

Mehr

Datenbanken für Online Untersuchungen

Datenbanken für Online Untersuchungen Datenbanken für Online Untersuchungen Im vorliegenden Text wird die Verwendung einer MySQL Datenbank für Online Untersuchungen beschrieben. Es wird davon ausgegangen, dass die Untersuchung aus mehreren

Mehr

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

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

Mehr

S W I S S O R A C L E U S E R G R O U P. N e w s l e t t e r 2 / 2 0 1 1 A p r i l 2 0 1 1. Oracle 11g

S W I S S O R A C L E U S E R G R O U P. N e w s l e t t e r 2 / 2 0 1 1 A p r i l 2 0 1 1. Oracle 11g S W I S S O R A C L E U S E R G R O U P www.soug.ch N e w s l e t t e r 2 / 2 0 1 1 A p r i l 2 0 1 1 Edition Based Redefinition Erfolgreicher Datenschutz Hybrid Columnar Compression Archive Log Maintenance

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Datumsangaben, enthält mindestens Jahr, Monat, Tag

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

Mehr

Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle.

Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle. Rundbrief 6 Aktuelles aus der SAS Softwarewelt. 0.1 Zeit Server Update Werte Anwender Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle. Das Update wurde aus Kompatibilitätsgründen

Mehr

Relationales Datenbanksystem Oracle

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

Mehr

Aufbau einer Testumgebung mit VMware Server

Aufbau einer Testumgebung mit VMware Server Aufbau einer Testumgebung mit VMware Server 1. Download des kostenlosen VMware Servers / Registrierung... 2 2. Installation der Software... 2 2.1 VMware Server Windows client package... 3 3. Einrichten

Mehr

Oracle Exadata Storage Server Performance erklärt SmartScan

Oracle Exadata Storage Server Performance erklärt SmartScan Products 31 Daniel Rey, OPITZ CONSULTING Schweiz GmbH Oracle Exadata Storage Server Performance erklärt SmartScan Im Herbst 2008 präsentierte Oracle an der OpenWorld den Exadata Storage Server und die

Mehr

Dokumentation zur Anlage eines JDBC Senders

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

Mehr

Oracle Enterprise Manager Cloud Control 12c: Installation von Ralf Durben, ORACLE Deutschland B.V. & Co. KG

Oracle Enterprise Manager Cloud Control 12c: Installation von Ralf Durben, ORACLE Deutschland B.V. & Co. KG Nach Abschluß der Softwareinstallation konfigurieren Sie den Listener (mit netca) und erzeugen eine Datenbank. Der einfachste Weg zur Erzeugung der Datenbank ist die Nutzung des Database Config Assistants

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

Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009

Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009 Hochschule Darmstadt DATENBANKEN Fachbereich Informatik Praktikum 3 Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009 PL/SQL Programmierung Anwendung des Cursor Konzepts und Stored Procedures Und Trigger

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

MySQL 101 Wie man einen MySQL-Server am besten absichert

MySQL 101 Wie man einen MySQL-Server am besten absichert MySQL 101 Wie man einen MySQL-Server am besten absichert Simon Bailey simon.bailey@uibk.ac.at Version 1.1 23. Februar 2003 Change History 21. Jänner 2003: Version 1.0 23. Februar 2002: Version 1.1 Diverse

Mehr

Themen des Kapitels. 2 Grundlagen von PL/SQL. PL/SQL Blöcke Kommentare Bezeichner Variablen Operatoren. 2.1 Übersicht. Grundelemente von PL/SQL.

Themen des Kapitels. 2 Grundlagen von PL/SQL. PL/SQL Blöcke Kommentare Bezeichner Variablen Operatoren. 2.1 Übersicht. Grundelemente von PL/SQL. 2 Grundlagen von PL/SQL Grundelemente von PL/SQL. 2.1 Übersicht Themen des Kapitels Grundlagen von PL/SQL Themen des Kapitels PL/SQL Blöcke Kommentare Bezeichner Variablen Operatoren Im Kapitel Grundlagen

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

Objektrelationale Datenbanken

Objektrelationale Datenbanken Vorlesung Datenbanksysteme vom 26.11.2008 Objektrelationale Datenbanken Konzepte objektrelationaler DBs SQL:1999 OO vs. OR Konzepte objektrelationaler Datenbanken Große Objekte (LOBs: Large Objects) Mengenwertige

Mehr

Parallele Programmierung in SQL und PL/SQL. Peter Bekiesch Dierk Lenz DOAG 2011 Konferenz und Ausstellung 17. November 2011

Parallele Programmierung in SQL und PL/SQL. Peter Bekiesch Dierk Lenz DOAG 2011 Konferenz und Ausstellung 17. November 2011 Parallele Programmierung in SQL und PL/SQL Peter Bekiesch Dierk Lenz DOAG 2011 Konferenz und Ausstellung 17. November 2011 Herrmann & Lenz Services GmbH Herrmann & Lenz Solutions GmbH Erfolgreich seit

Mehr

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

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

Mehr

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

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

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz Oracle Datenbank Architektur nicht nur für Einsteiger Martin Klier Klug GmbH integrierte Systeme, Teunz DOAG Webinar, 08.03.2012 Referent Martin Klier Datenbankadministrator für Fachliche Schwerpunkte:

Mehr

Lets talk about LOBs please

Lets talk about LOBs please Beate Künneke BK Unternehmensberatung bk@berlin.de Lets talk about LOBs please DOAG Konferenz 19.11.2015 Nürnberg Agenda Strukturiert, semistrukturiert, unstrukturiert Migration LOBs Warum alles in der

Mehr

DB2 for VM / VSE 7.5. News & Experiences. Torsten Röber. GSE Frühjahrstagung April 2008, Bonn. IBM Software Group

DB2 for VM / VSE 7.5. News & Experiences. Torsten Röber. GSE Frühjahrstagung April 2008, Bonn. IBM Software Group DB2 for VM / VSE 7.5 News & Experiences IBM Software Group Torsten Röber GSE Frühjahrstagung April 2008, Bonn Agenda DB2 Server/Client for VSE & VM 7.5 Migrationsprojekte Performance Hints & Tipps Lessons

Mehr

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

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

Mehr

Dedup-Technik wie funktioniert es?

Dedup-Technik wie funktioniert es? Dedup-Technik wie funktioniert es? v.1.3. Stand: Oktober 2010 Wiesbaden Deduplizierung Wie funktioniert es? 2 Inhalt Was ist Deduplizierung? Was bewirkt Deduplizierung? Source- Target- und Speichermanagement-Deduplizierung

Mehr

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte

27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Ole Raether raether@oraservices.de 27. 03. 2007 IT-Frühstück IT Trend Virtualisierung Hype oder Nutzen? Praxisaspekte Inhalt oraservices.de Probleme: Failover Cluster, RAC 24*7 Fazit Was tun? oraservices.de

Mehr

IT-Symposium 2008 05.06.2008

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

Mehr

Folgendes PL/SQL Codefragment zeigt das grundlegende Statement für diesen Test: Java. http://www.trivadis.com/images/javaperf_tcm16-7133.

Folgendes PL/SQL Codefragment zeigt das grundlegende Statement für diesen Test: Java. http://www.trivadis.com/images/javaperf_tcm16-7133. Page 1 of 7 Betrifft: Java oder PL/SQL? Art der Info: Technische Background Info Autor: Guido Schmutz (guido.schmutz@trivadis.com) Quelle: Aus unserer Schulungs- und Beratungstätigkeit Mit Oracle8.1 besteht

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

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

desk.modul : WaWi- Export

desk.modul : WaWi- Export desk.modul : WaWi- Export Die Schnittstelle besteht aus einem Programm, welches die Daten aus der OfficeLine ausliest und in eine XML-Datei exportiert. Die Schnittstelle ist als ein eigenständiges Programm

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

Safexpert Oracle Datenbank Konnektor. Stand: 02.01.2012. IBF-Automatisierungs-und Sicherheitstechnik GmbH A-6682 Vils Bahnhofstraße 8

Safexpert Oracle Datenbank Konnektor. Stand: 02.01.2012. IBF-Automatisierungs-und Sicherheitstechnik GmbH A-6682 Vils Bahnhofstraße 8 Safexpert Oracle Datenbank Konnektor Stand: 02.01.2012 IBF-Automatisierungs-und Sicherheitstechnik GmbH A-6682 Vils Bahnhofstraße 8 Tel.: +43 (0) 5677 5353 0 E-Mail: office@ibf.at 1 Kurzüberblick über

Mehr

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

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

storage management (c) Till Hänisch 2003, BA Heidenheim

storage management (c) Till Hänisch 2003, BA Heidenheim storage management (c) Till Hänisch 2003, BA Heidenheim warum? haenisch@susi:~ > df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 35115800 16351708 16980076 50% / /dev/sda1 23300 3486 18611

Mehr

Abfragen (Queries, Subqueries)

Abfragen (Queries, Subqueries) Abfragen (Queries, Subqueries) Grundstruktur einer SQL-Abfrage (reine Projektion) SELECT [DISTINCT] {* Spaltenname [[AS] Aliasname ] Ausdruck} * ; Beispiele 1. Auswahl aller Spalten SELECT * ; 2. Auswahl

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

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Oracle: Abstrakte Datentypen:

Oracle: Abstrakte Datentypen: Oracle: Abstrakte Datentypen: Oracle bietet zwei mögliche Arten um abstrakte Datentypen zu implementieren: Varying Array Nested Table Varying Array (kunde) kdnr kdname gekaufteart 1 Mustermann 1 4 5 8

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

Oracle Real Application Clusters: Requirements

Oracle Real Application Clusters: Requirements Oracle Real Application Clusters: Requirements Seite 2-1 Systemvoraussetzungen Mind. 256 MB RAM (mit 128 MB geht es auch...) Mind. 400 MB Swap Space 1,2 GB freier Speicherplatz für f r Oracle Enterprise

Mehr

SQL Cockpit & SAP HANA Prüfen Sie Ihre SQL Abfragen auf HANA-Tauglichkeit

SQL Cockpit & SAP HANA Prüfen Sie Ihre SQL Abfragen auf HANA-Tauglichkeit SQL Cockpit & SAP HANA Prüfen Sie Ihre SQL Abfragen auf HANA-Tauglichkeit Johann Fößleitner Cadaxo GmbH email: johann.foessleitner@cadaxo.com Twitter: @foessleitnerj Agenda 1 SAP HANA Integrationsszenarien

Mehr

Performance Probleme aufspüren

Performance Probleme aufspüren Performance Probleme aufspüren Oberhausen, 2013 Hans-Jürgen Schönig Gründe für schlechte Performance 1. Dumme Anfragen - das passiert häufiger als man denkt 2. Suboptimale PostgreSQL Parameter 3. Schlechte

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

Komplexe Excel-Berichte mit APEX und jxls erstellen

Komplexe Excel-Berichte mit APEX und jxls erstellen Komplexe Excel-Berichte mit APEX und jxls erstellen Dietmar Aust Opal-Consulting Köln Schlüsselworte: Oracle APEX, MS Excel, jxls, Bericht, Template, Open Source Einleitung In fast jeder Webapplikation

Mehr

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

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

Mehr

Markus Feichtinger. Power Systems. Der Weg zu POWER! 2009 IBM Corporation

Markus Feichtinger. Power Systems. Der Weg zu POWER! 2009 IBM Corporation Markus Feichtinger Power Systems Der Weg zu POWER! Agenda Motivation Lösung Beispiel Export / Import - Überblick - Migration Beispiel XenoBridge - Überblick - Migration Benefits 2 Motivation Strategisch

Mehr

1.5. Passwort-geschützte Seiten

1.5. Passwort-geschützte Seiten TYPO3 - the Enterprise Open Source CMS: Documentation: Der... 1 von 5 1.4.Editieren und erstellen von Seiten und Inhalt Table Of Content 1.6.Spezielle Content Elemente 1.5. Passwort-geschützte Seiten Nun

Mehr

PostgreSQL Wartungsstrategien

PostgreSQL Wartungsstrategien Jens Wilke PGConf.DE 11. November 2011 Wartungsstrategien Warum Wartung? Autovacuum Tuning Repairtools Warum Wartung? Statistiken pg statistic ANALYZE MVCC (Multiversion Concurrency Control) Wiederverwendung

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

Erhöhung der Manageability durch SQL-Profile

Erhöhung der Manageability durch SQL-Profile Erhöhung der Manageability durch SQL-Profile Ein Erfahrungsbericht 20.11.2007 Dr. Frank Haney 1 Inhalt 1. Problemstellung 2. Der SQL-Tuning-Advisor (STA) 3. Anlegen und Implementieren von SQL-Profilen

Mehr

2011 Oracle Corporation Customer Presentation Version 5.2.2/20110526

2011 Oracle Corporation Customer Presentation Version 5.2.2/20110526 1 Neues zur Lizensierung der Oracle Sun Storage Archive Manager Software und Oracle Sun QFS Software Dirk Nitschke Sales Consultant The following is intended to outline our general

Mehr

Martin Bracher (martin.bracher@trivadis.com) Technische Background Info und Trivadis Scripts

Martin Bracher (martin.bracher@trivadis.com) Technische Background Info und Trivadis Scripts Betrifft Autor Art der Info Quelle Resize von Tablespaces mit Oracle8i und Oracle9i Martin Bracher (martin.bracher@trivadis.com) Technische Background Info und Trivadis Scripts Aus dem AI9-A Kurs der Trivadis

Mehr

MySQL Installation. AnPr

MySQL Installation. AnPr Name Klasse Datum 1 Allgemeiner Aufbau Relationale Datenbank Management Systeme (RDBMS) werden im Regelfall als Service installiert. Der Zugriff kann über mehrere Kanäle durchgeführt werden, wobei im Regelfall

Mehr