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 Optimizer und Netzwerktuning Steigende Datenmengen bei gleichbleibenden/schlechteren Diskanbindungen Ansätze innerhalb der Datenbank Ansätze im Hardwarebereich Server Storage Trennung OLTP und DSS/DWH

Oracle 12c performancerelevante Neuheiten Oracle 12c In-Memory Database Option Full Database Caching und automatisches Big Table Caching Optimizer Neuheitenüberblick Partitioning Neuheiten SQL Net Konfiguration

Oracle 12c In-Memory Database Cache Option SGA Bereich für In-Memory Cache In der SGA wird ein zusätzlicher Bereich der In-Memory Column Store bereitgestellt Sobald auf den Tabellen definiert ist, dass sie In-Memory nutzen sollen, landen diese auch im Column Store Innerhalb des Column Stores gibt es 1MB große Column Units in denen die Daten abgelegt werden. Verwaltungsstruktur (Transaktionsbereich) umfasst ca. 15% des Column Stores

Wie ist der Column Store aufgebaut Jede Column Unit gehört zu einer bestimmten Tabelle (eine Tabelle belegt mehrere/viele Column Units) und enthält die Daten von aufeinanderfolgenden Daten (Rows) Die Daten werden aber nicht zeilenweise (Row) sondern spaltenweise (Column) abgelegt dabei werden diese nach der Spalte sortiert und pro CU und Spalte gibt es einen MAX und MIN Information hilft bei Queries, CUs auszulassen, die keine relevanten Daten enthalten.

Was ist der Vorteil von In-Memory gegenüber anderen Lösungen?(Marketingeinschaltung) In Memory einschalten, Tabellen In-Memory aktivieren, fertig Applikationsanpassungen: keine (außer drop Index) Funktionseinschränkungen: keine, alle Features sind unterstützt Migrationsaufwand: keiner Änderungen Backup/Recovery: keine

Full Database Caching Offiziell ab Oracle 12.1.0.2 Datenbank muss komplett ins Memory passen Bei FTS wird die Tabelle komplett in den Cache geladen (davor nur dann wenn auf der Tabelle das CACHE Attribut gesetzt war) Buffer Cache LRU wird deaktiviert Einschalten: STARTUP MOUNT; ALTER DATBASE FORCE FULL DATABASE CACHING; ALTER DATABASE OPEN; SELECT force_full_db_caching FROM V$DATABASE;

Automatisches Big Table Caching Speziell bei Parallel Query / DML Oracle 11gR2 / 12.1.0.1 Full Tables Scan bei Parallel Query/DML Die Tabelle wurde mit DIRECT READS nur für die PQ/PX Prozesse eingelesen und landete nicht im normalen BufferCache mehrere Abfragen auf die gleiche Tabelle bedeutet mehrfaches einlesen von der Storage Oracle 12.1.0.2 Instanz Parameter DB_BIG_TABLE_CACHE_PERCENT_TARGET 0 bis 90 PARALLEL_DEGREE_POLICY AUTO oder ADAPTIVE Die hottest Big Tableswerden auch bei Parallel Verarbeitung ins BufferCache geladen, solange es sich ausgeht.

Oracle 12c Optimizer Neuheiten im Überblick (1) Adaptive Executionpläne Besteht aus zwei Funktionalitäten Dynamic Plans Reoptimization Voraussetzung der CBO bereitet alternative Pläne vor während der Ausführung wird auf einen anderen Plan umgeschaltet nutzt Laufzeit Statistik Feedback Beim nächsten Execute wird damit neu geparsed OPTIMIZER_FEATURE_ENABLE >= 12.1.0.1 OPTIMIZER_ADAPTIVE_REPORTING_ONLY CURSOR_SHARING FALSE EXACT oder FORCE

Oracle 12c Optimizer Neuheiten im Überblick (2) SQL Plan Directives Statistik Information über mehrere Spalten hinweg select count(*) from ZULASSUNGEN where Marke = 'VW' and Type = 'Golf' and Jahr = 2014; Ab Oracle 11g mit der Hilfe manuell erzeugten EXTENDED STATISTICS abdeckbar Ab Oracle 12c (12.1.0.1) werden Directivesvon CBO automatisch erkannt, in der SGA abgelegt und bei nochmaliger Nutzung in den SYSAUX Tablespace persistiert. Beim nächsten Statistiklauf auf der Tabelle wird die SQL Plan Directiveals Extended Statistic automatisch mitgerechnet

Oracle 12c Optimizer Neuheiten im Überblick (3) Automatisches Dynamic Sampling OPTIMIZER_DYNAMIC_SAMPLING neuer Default = 11 Es gibt zwei neue Histogrammtypen Top Frequency Histrogramm und Hybrid Histrogramms(der neue Default) Automatische Statistikerzeugung bei BULK Verarbeitungen CREATE TABLE AS SELECT INSERT INTO SELECT in eine leere Tabelle Weiter Statistikverbesserungen Verbesserung bei der Parallelisierung von GATHER_STATS Jobs Sinnvolle Session Statistiken für Globale Temporary Tabellen Extended Statistik Empfehlungen generieren lassen

Partitioningverbesserungen Bei REFERENCE PARTITIONING (gibt es seit Oracle 11g) ist jetzt auch TRUNCATE und EXCHANGE Partition CASCADE möglich ADD, DROP, TRUNCATE, SPLIT, MERGE unterstützen jetzt mehrere/viele Partitions gleichzeitig ADD, DROP, TRUNCATE bis jetzt immer nur eine Partition SPLITT, MERGE bis jetzt immer nur zwei Partitions PARTIAL partitionierte Indexes Trick in älteren Oracle Releases: Index Partitionen auf UNUSABLE setzen Jetzt geht das mit PARTIAL offiziell Global Index Maintainancekann jetzt später erfolgen ohne dass der Index unusable wird

SQL Net Konfiguration ab 12.1.0.1 SDU Size kann jetzt viel größer konfiguriert werden (ideal mit JumboFrames) SQLNET.ORA DEFAULT_SDU_SIZE Default ist 8k (seit 11g, davor 2k) Oracle 11g: 64k, Oracle 12c: 2M Kann man auch im LISTENER.ORA und TNSNAMES.ORA einstellen Komprimierung von Daten innerhalb von SQL Net mit Advanced Compression Option SQLNET.ORA SQLNET.COMPRESSION SQLNET.COMPRESSION_LEVELS ON OFF SQLNET.COMPRESSION_THRESHOLD 1024 LOW HIGH

Sonstige Performanceverbesserungen Ein Überblick PGA kann jetzt limitiert werden PGA_AGGREGATE_TARGET war eine Empfehlung / ein Vorschlag, den Oracle aber oft genug ignoriert hat, wodurch es zu SWAPPING gekommen ist. PGA_AGGREGATE_LIMIT ist jetzt eine echte Grenze Default = PGA_AGGREGATE_TARGET * 2 aber mindestens 2GB Hintergrundprozesse unterliegen NICHT diesem Limit! Database Smart Cache Support Oracle 11gR2 eine SSD, kein Support für Parallelverarbeitung Oracle 12c bis zu 16 SSDs, Support für Parallelverarbeitung Temporary UNDO für Temporary Tables Weniger REDO Information Temporary Tables können jetzt auch in Read Only Datenbank genutzt werden

Steigende Datenmengen bei gleichbleibenden/schlechteren Diskanbindungen Ansätze innerhalb der Datenbank Ansätze im Hardwarebereich Server Storage Ideen zu einem unkonventionellen Ansatz mit ASM Trennung OLTP und DSS/DWH

Einleitung Das Thema ist nicht neu auch zu Oracle 6 war das Thema trennen von OLTP und DSS/DWH bzw. Archivierung schon vorhanden. Leider wird es bei den meisten Software Projekten nicht als verpflichtende Funktionalität gleich mit eingebaut Später oft nur sehr kompliziert oder überhaupt nicht sinnvoll anhängbar

Ansätze innerhalb der Datenbank Oracle 12c bringt zum Thema ILM Information Livecycle Mangement einige Features wie Heat Map und Automatic Data Optimization Verschieben von Daten auf andere Storage Tiers und/oder Komprimierung In-Database Archiving Temporale Validity und Temporal History Partitioning(meisten RANGE über die ZEIT) Hilft und bringt Performance solange die Abfragen ebenfalls zeitlich eingeschränkt sind Sauber ist aber immer noch weg von Hybrid hin zu OLTP und DWH Nur die aktuell benötigten Daten im OLTP Alle anderen Daten in einem DSS/DWH System

Ansätze im Hardwarebereich Server Datenbank in Memory oder Flash/SSD halten Neue Funktionalitäten wie Oracle 12c 12.1.0.2 In-Memory Database Cache Option Oracle 12c 12.1.0.2 Full Database in Memory Oracle 11g & 12c Flash Cache Support Man kann vieles aber auch mit sinnvoll dimensioniertem BufferCache und optionalem CACHE Attribute auf den Tabellen auch in älteren Oracle Releases (zumindest ab 9i) und allen Editions erreichen Gemeinsam mit Virtualisierungslösungen(VMware) SSD Read Cache im VMware Server Einsatz von Oracle Engineered Systems Vor allem die Exadataaber auch der SuperClustersind dafür gebaut

Kundenprojekt / SGA Sizing für SAP BW Landschaft Teil 1: Auswirkung auf den I/O Bedarf Oracle Memory Advisor: alles OK, 60GB Buffer Cache sind super Unsere Empfehlung: mindestens 200GB Buffer Cache, Umsetzung: 240GB Vorher: 300MB/Sec, Peaks 450MB/Sec, 7.000-8000 IOPS, Peaks >10.000 IOPS Nachher: wenige MB/sec, Peaks 40MB/Sec, wenige 100 IOPS, Peak <1.000 IOPS

Kundenprojekt / SGA Sizing für SAP BW Landschaft Teil 2: Entlastung der Storage Die Storage hat vor der Umstellung eine CPU Belastung von durchschnittlich 75% ausgewiesen, Peaks bis auf knapp 100%, praktisch nicht unter 50% Nach der Umstellung dieser einen Datenbank ist die CPU Auslastung auf der Storage auf durchschnittlich 50-55% gefallen Peaks unter 90%, Auslastung zeitweise unter 35% ca. 20% weniger CPU Belastung

Kundenprojekt / SGA Sizing für SAP BW Landschaft Teil 3: Was ist beim Endbenutzer angekommen? Einige Auswertungen und Reports sind teilweise um den Faktor 50-100 schneller fertig. Durchschnittlich ist ein Faktor zwischen 3 und 10 über alle Auswertungen und Reports beim Endbenutzer angekommen. Reaktion der Benutzer: Auswertungen werden öfter und über größere Zeitbereiche durchgeführt (bessere) ausführlichere Informationen für Entscheider Zusätzliche Auswertungen und Reports werden erstellt Ergebnis: Durch die zusätzliche Last steigt die I/O Belastung wieder Eine aktuelle SizingAnalyse hat ergeben, dass das BufferCache nochmals verdoppelt werden muss um die aktuelle Last zu tragen

Kundenprojekt / SGA Sizing für SAP BW Landschaft Zusammenfassung Das ganze läuft auf Oracle 11gR2 unter Linux Somit können noch keine der neuen In-Memory Funktionen der Oracle 12c genutzt werden Abgesehen davon, dass SAP diese (noch) nicht unterstützt In einem Proof ofconceptwurde bei einigen Auswertungen mit Oracle 12c In Memory getestet und haben weitere Performanceverbesserungen im Bereich von Faktor 5 gebracht, allerdings gibt es auch Auswertungen die davon nicht profitiert haben. Details dazu haben wir in unserer Veranstaltung Oracle 12c In Memory Cache Option vom 18. Sep 2014 berichtet Sie können sich diesen Vortrag auf Youtube ansehen/anhören. https://www.youtube.com/playlist?list=plhjsh_lb3go5dmaqejijrtocdb_w_vv3c

Ansätze im Hardwarebereich Storage Einsatz von SSD/Flash Eigene All-Flash Storages Nur Flash Raidgruppen/ Aggregates Flash als Caching in der Storage Aufpassen bei Automatischen Tiering Kann dazu führen, dass nach jedem Backup ein Re-Tiering erfolgt Hier ist der Einsatz von Oracle ILM / AutomaticData Optimizationvermutlich eine sinnvolle Ergänzung

Unkonventioneller Ansatz mit ASM Mit ASM kann man Daten spiegeln (Normal or High Redundency) Normalerweise nutzt man dieses Feature um die Daten auf zwei Storagelocations zu spiegeln Man kann ASM aber auch so konfigurieren, dass Eine Failgroup auf einer (oder mehreren) SSDs/HDDs liegt Die 2. (und optional 3.) Failgroup auf Storages Mit der Einstellung ASM_PREFERRED_READ_FAILURE_GROUPS erreicht man, dass vom den lokalen Devices gelesen wird Geschrieben wird auf alle Locations Sollten die lokalen Devices defekt werden, gehen keine Daten verloren!

Trennung von OLTP und DSS/DWH (Der alte Hut) Im OLTP System sollten nur die wirklich aktiven Daten sein Beispiel WebShop Aktuelle Artikel, Bestellungen & Bestellabwicklung, Lager und Buchhaltung Alle Daten die älter sind als 3-6 Monate gehören hier nicht mehr hinein DSS / DWH hier sind alle Daten, die nicht mehr aktiv sind Beispiel WebShop Archive Bereich: Nicht mehr verfügbare Artikel, inaktive (oder alle) Kunden (Konto geschlossen,..), Verkaufshistorie und dazugehörende Buchhaltung in diesem Bereich greift die Applikation (transparent) zu, wenn der Kunde ältere Bestellinformationen ansehen möchte, DSS / DWH Bereich: Hier sind nur noch jene Daten, die für Auswertungen und Analysen benötigt werden in denormalisierter, aggregierter Form für (STAR) Query Abfragen

Zusammenfassung Es gibt gerade im Performance Bereich einige gute Gründe, auf Oracle 12c umzusteigen leider ist Einiges davon eine kostenpflichtige Option Langsam aber sicher sollten aktuelle Hardwaretechnologien im Datenbankumfeld besser genutzt werden Hauptspeichergrößen >=768GB auch in Commodity2 Sockel Server möglich SSD / FLASH Technologie dort wo es nötig ist.

Q & A