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

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

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

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

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

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

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

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

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

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

DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS)

DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS) DOAG 2010 ORACLE PLATTFORM MIGRATION CROSS PLATFORM TRANSPORTABLE TABLESPACES (XTTS) METHODE UND ERFAHRUNGSBERICHT JOSEF LIPPERT FREIBERUFLICHER IT CONSULTANT MÜNCHEN Wer bin ich Freiberuflicher IT Consultant

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

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

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

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

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

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

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

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

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

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

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

ORACLE und IBM DB2 Datentypen 14.12.2011

ORACLE und IBM DB2 Datentypen 14.12.2011 1/27 ORACLE und IBM DB2 Datentypen PHP-User-Group Stuttgart 14.12.2011 ORACLE Datentypen ein Überblick IBM DB2 Datentypen ein Überblick 2/27 ORACLE und IBM DB2 Datentypen Wer Wer bin bin ich ich?? Thomas

Mehr

Martin Wunderli (martin.wunderli@trivadis.com)

Martin Wunderli (martin.wunderli@trivadis.com) Betrifft Standby Aber logisch! Art der Info Lösungskonzept (Januar 2003) Autor Quelle Martin Wunderli (martin.wunderli@trivadis.com) Beratungstätigkeit Schlüsselworte Data Guard, Logische Standby Datenbank

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

Einleitung. SPFILE und INIT.ORA. Umgang mit SPFILE und INIT.ORA. Petra Knöbl (petra.knoebel@trivadis.com)

Einleitung. SPFILE und INIT.ORA. Umgang mit SPFILE und INIT.ORA. Petra Knöbl (petra.knoebel@trivadis.com) Betrifft Autor Umgang mit SPFILE und INIT.ORA Petra Knöbl (petra.knoebel@trivadis.com) Art der Info Technische Background Info (März 2002) Quelle Aus dem NF9i-Kurs und NF9i-Techno-Circle der Trivadis Einleitung

Mehr

Automatisierung durch Information Lifecycle Management

Automatisierung durch Information Lifecycle Management Automatisierung durch Information Lifecycle Management Ralf Lange Oracle Deutschland B.V. & Co. KG Storage Management: Herausforderungen Verwalten von mehr Daten ohne ansteigende Kosten Komprimieren von

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

3. Architektur eines DBS (Oracle)

3. Architektur eines DBS (Oracle) 3. Architektur eines DBS (Oracle) aus Sicht des Datenbank Server Rechners Connectivity Komponente(n) des DBS (z.b. Oracle Listener) Installation ORACLE_HOME Instanz ORACLE_SID Datenbank Oracle: 1 (aktive)

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

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

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

Kuriositäten in der Oracle-Datenbank

Kuriositäten in der Oracle-Datenbank Kuriositäten in der Oracle-Datenbank 19. Deutsche ORACLE-Anwenderkonferenz Do. 16.11., 14.00 Uhr, Variohalle 1 Dr. Peter Alteheld, Systemberater MT AG, Bereich Solutions Development, FB Plattform Services

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

Backup und PiTR mit MySQL

Backup und PiTR mit MySQL Backup und PiTR mit MySQL DOAG Konferenz 2014 Nürnberg Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com 1 / 20 Über FromDual GmbH FromDual bietet neutral und unabhängig:

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

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Kurs. Teil 4 Shared Pool. Universität Hannover. Agenda. Überblick. Library Cache Oracle 9i Einführung Performance Tuning. Trefferquote.

Kurs. Teil 4 Shared Pool. Universität Hannover. Agenda. Überblick. Library Cache Oracle 9i Einführung Performance Tuning. Trefferquote. Kurs Oracle 9i Einführung Performance Tuning Teil 4 Shared Pool Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 22 Seite 1 von 22 1. 2. 3. SQL Area / 4. 5. 6. Shared Pool Reserved Area 7. Wiederverwendung

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

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 9 Sortiervorgänge. Universität Hannover. Sortiervorgänge. Migration. Konfiguration.

Oracle 9i Einführung. Performance Tuning. Kurs. Teil 9 Sortiervorgänge. Universität Hannover. Sortiervorgänge. Migration. Konfiguration. Kurs Oracle 9i Einführung Performance Tuning Teil 9 Anhang Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 14 Seite 1 von 14 Agenda 1. Einführung 2. 3. 4. Der Sortiervorgang 5. 6. Statische Informationen

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

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

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

Themen des Kapitels. 2 Oracle Features und Architektur

Themen des Kapitels. 2 Oracle Features und Architektur 2 Oracle Features und Architektur Einführung in die Eigenschaften und die Funktionsweise von Oracle. 2.1 Übersicht Themen des Kapitels - Oracle Features und Architektur Themen des Kapitels Oracle Produkte

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

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris

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

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at DB2 & SQL E I N F Ü H R U N G T U N I N G O P T I M I E R U N G S E C R E T S ANDREAS PROUZA andreaspr@aon.at andreas@prouza.at http://www.prouza.at Wien, 2015-03-27 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis...

Mehr

Inhaltsverzeichnis. Installationsübersicht. A. Installationsübersicht

Inhaltsverzeichnis. Installationsübersicht. A. Installationsübersicht Inhaltsverzeichnis A. Installationsübersicht B. und Optimierungsbereiche B.1 Hardware B.2 OperatingSystem Z/OS B.3 Databasemanagementsystem DB2 B.4 Applikation C. Organisation BSS_Chart-library 1 Installationsübersicht

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

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

Objektrelationale, erweiterbare Datenbanken WS 04/05

Objektrelationale, erweiterbare Datenbanken WS 04/05 Eidgenössische Technische Hochschule Zürich Swiss Federal Institute of Technology Zurich Institut für Informationssysteme Dr.C.Türker Objektrelationale, erweiterbare Datenbanken WS 0405 Übung 8 Aufgabe

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

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

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

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

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

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

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

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

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

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

MySQL Konfiguration - die wichtigsten Parameter

MySQL Konfiguration - die wichtigsten Parameter MySQL Konfiguration - die wichtigsten Parameter DOAG SIG MySQL Performance 13. März 2012, Wiesbaden Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com www.fromdual.com 1

Mehr

Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen?

Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen? Portierung einer DB2/VM-Datenbank nach DB2 unter zlinux 4 Jahre später - Wie würde ich heute vorgehen? Tipps aus der Praxis zur Anwendungsentwicklung, Migration und Performanceuntersuchung 1 Einleitung

Mehr

Übung: Data Warehousing und Data Mining

Übung: Data Warehousing und Data Mining Übung: Data Warehousing und Data Mining Sebastian Wandelt 20. Oktober 2011 wandelt@informatik.hu-berlin.de Überblick Organisatorisches Kurze Einführung JDBC PL/SQL 1. Aufgabenblatt Ablauf des Semesters

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

Darüber hinaus wird das Training dazu beitragen, das Verständnis für die neuen Möglichkeiten zu erlangen.

Darüber hinaus wird das Training dazu beitragen, das Verständnis für die neuen Möglichkeiten zu erlangen. Ora Education GmbH www.oraeducation.de info@oraeducation.de Lehrgang: Oracle 11g: New Features für Administratoren Beschreibung: Der Kurs über fünf Tage gibt Ihnen die Möglichkeit die Praxis mit der neuen

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

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

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

1. Ablöse der Streams Multimaster-Replikation

1. Ablöse der Streams Multimaster-Replikation Data Guard durch Firewalls? Kein Problem mit Connection Manager! Mathias Zarick Principal Consultant September 2013 Data Guard hat sich als Hochverfügbarkeitstechnologie für Oracle etabliert. Er spiegelt

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

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

IO Performance - Planung Messung, Optimierung. Ulrich Gräf Principal Sales Consultant Oracle Deutschland B.V. und Co. KG

IO Performance - Planung Messung, Optimierung. Ulrich Gräf Principal Sales Consultant Oracle Deutschland B.V. und Co. KG IO Performance - Planung Messung, Optimierung Ulrich Gräf Principal Sales Consultant Oracle Deutschland B.V. und Co. KG The following is intended to outline our general product direction. It is intended

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

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein.

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein. Systemanforderungen Die unten angeführten Systemanforderungen für Quark Publishing Platform sind grundlegende Anforderungen, Ihre Benutzerzahl, Asset-Anzahl und Anzahl der Asset-Versionen beeinflussen

Mehr

Software oder Appliance basierende Deduplikation Was ist die richtige Wahl? Storagetechnology 2010

Software oder Appliance basierende Deduplikation Was ist die richtige Wahl? Storagetechnology 2010 Software oder Appliance basierende Deduplikation Was ist die richtige Wahl? Storagetechnology 2010 Frank Herold Manager PreSales CEE Quantums Portfolio StorNextSoftware DXiSerie ScalarSerie ManagementTools

Mehr

Überwachung von Oracle Datenbanken mit check_oracle_health

Überwachung von Oracle Datenbanken mit check_oracle_health Überwachung von Oracle Datenbanken mit check_oracle_health Gerhard Laußer aus München arbeite bei der Firma ConSol* Wer bin ich? Entstehungsgeschichte Anforderung mit etlichen Punkten. Es gibt ein paar

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

Installation MySQL Replikationsserver 5.6.12

Installation MySQL Replikationsserver 5.6.12 Ergänzen Konfigurationsdatei my.ini auf Master-Server:!!! softgate gmbh!!! Master und Slave binary logging format - mixed recommended binlog_format = ROW Enabling this option causes the master to write

Mehr

Oracle Datenbank / Ubuntu

Oracle Datenbank / Ubuntu Oracle Datenbank / Ubuntu Sebastian Gath & Hannes Schwarz Seminar Database Tuning & Administration Universität Konstanz - SS 2007 Administration Vorbereitung Zeitmessung Erste Zeitmessung 2 Ausgangssituation

Mehr

Komprimierung in der Datenbank

Komprimierung in der Datenbank ORACLE DOJO NR. 8 ULRIKE SCHWINN Komprimierung in der Datenbank Tabellen, Large Objects, Indizes, RMAN, Data Pump, Netzwerk, Data Guard, Information Lifecycle Management Oracle Dojo ist eine Serie von

Mehr

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012 Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch

Mehr

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs Betrifft Art der Info Quelle WHERE Klausel Generierung mit.net und Oracle Technical Info Aus unserer Projekterfahrung und Architektur-Kurs Where ist the WHERE? Der Artikel untersucht die Möglichkeiten,

Mehr

MySQL Performance Tuning für Entwickler

MySQL Performance Tuning für Entwickler MySQL Performance Tuning für Entwickler Cebit 2015, Hannover Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com 1 / 18 FromDual GmbH Support Beratung remote-dba Schulung

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

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

Oracle Datenbank Performance

Oracle Datenbank Performance Oracle Datenbank Performance Was gibt es Neues? Oder Gibt es überhaupt etwas Neues? Themenübersicht Oracle 12c performancerelevante Neuheiten Oracle 12c In-Memory Database Option & Co Partitioning Neuheiten

Mehr

Johannes Ahrends Geschäftsführer CarajanDB GmbH. 2013 CarajanDB GmbH

Johannes Ahrends Geschäftsführer CarajanDB GmbH. 2013 CarajanDB GmbH Johannes Ahrends Geschäftsführer CarajanDB GmbH Vorstellung CarajanDB GmbH Ziel Zeichenkonvertierung Umstellung der Datenbank Migration mit Export / Import Planung einer Migration Minimal Downtime Migration

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

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

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

Sicherheit Konzepte für die Datenbanksicherheit. TOAD User Konferenz 2008 Dr. Günter Unbescheid Database Consult GmbH

Sicherheit Konzepte für die Datenbanksicherheit. TOAD User Konferenz 2008 Dr. Günter Unbescheid Database Consult GmbH Konzepte für die Datenbanksicherheit TOAD User Konferenz 2008 Dr. Günter Unbescheid Database Consult GmbH Besinnliches... Cryptography is a branch of mathematics,...(it) is perfect. Security,... involves

Mehr

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen Transaktionen Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2015 Motivation ACID-Eigenschaften Übersicht Transaktionen Motivation ACID-Eigenschaften Ursachen für Logging und Backup

Mehr

ORACLE Database Migration

ORACLE Database Migration ORACLE Database Migration Hürden und Best Practices in einer hochverfügbaren Umgebung GUUG FFG 2013 Andrea Held 27.2.2013 10:47:05 A. Held: Oracle DB Migration 1 Agenda Oracle Hochverfügbarkeit: Eine Auswahl

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

Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap

Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap Prof. Stefan Keller (Fach-)Hochschule für Technik Rapperswil (bei Zürich) 11.11.2011 PGConf.DE - Stefan Keller 1 Was ist OpenStreetMap? Wikipedia

Mehr

Inkrementelles Backup und Block Change Tracking mit RMAN

Inkrementelles Backup und Block Change Tracking mit RMAN Tipps & Tricks: September 2014 Bereich: DBA Erstellung: 09/2014 HE Versionsinfo: 11.2, 12.1 Letzte Überarbeitung: 09/2014 HE Als PDF Downloaden! Inkrementelles Backup und Block Change Tracking mit RMAN

Mehr