oracle datenbank performance - db masters · adaptive executionpläne – besteht aus zwei...

Datenbanken sind unsere Welt www.dbmasters.at

Oracle Datenbank Performance

Was gibt es Neues?

Oder

Gibt es überhaupt etwas Neues?


Themenübersicht

Oracle Datenbank Performance – Was gibt es Neues?

● 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 In-Memory Database Option

● Full Database Caching und automatisches Big Table Caching

● Optimizer Neuheitenüberblick

● Partitioning Neuheiten

● SQL Net Konfiguration


Oracle 12c performancerelevante Neuheiten


Oracle 12c In-Memory Database Cache OptionSGA 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 CachingOffiziell 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 CachingSpeziell 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 Buffer Cache � 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 Tables werden auch bei Parallel Verarbeitung ins Buffer Cache geladen, solange es sich ausgeht.


Oracle 12c Optimizer Neuheiten im Überblick (1)


● Adaptive Executionpläne

– Besteht aus zwei Funktionalitäten

� Dynamic Plans … der CBO bereitet alternative Pläne vor �während der Ausführung wird auf einen anderen Plan umgeschaltet

� Reoptimization … nutzt Laufzeit Statistik Feedback �Beim nächsten Execute wird damit neu geparsed

– Voraussetzung

� OPTIMIZER_FEATURE_ENABLE >= 12.1.0.1

� OPTIMIZER_ADAPTIVE_REPORTING_ONLY FALSE

� CURSOR_SHARING EXACT oder FORCE




● SQL Plan Directives

– Statistik Information über mehrere Spalten hinwegselect 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 Directives von CBO automatisch „erkannt“, in der SGA abgelegt und bei nochmaliger Nutzung in den SYSAUX Tablespacepersistiert.

– Beim nächsten Statistiklauf auf der Tabelle wird die SQL Plan Directive als Extended Statistic automatisch mitgerechnet




● 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 Maintainance kann jetzt „später“ erfolgen ohne dass der Index unusable wird


SQL Net Konfigurationab 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 CompressionOption

– SQLNET.ORA

� SQLNET.COMPRESSION ON | OFF

� SQLNET.COMPRESSION_LEVELS LOW | HIGH

� SQLNET.COMPRESSION_THRESHOLD 1024


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


● Ansätze innerhalb der Datenbank

● Ansätze im Hardwarebereich

– Server

– Storage

● Ideen zu einem unkonventionellen Ansatz mit ASM

● Trennung OLTP und DSS/DWH


Steigende Datenmengen bei gleichbleibenden/schlechteren Diskanbindungen


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 HardwarebereichServer


● 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 Buffer Cache 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 Exadata aber auch der SuperCluster sind dafür gebaut


Kundenprojekt / SGA Sizing für SAP BW LandschaftTeil 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 LandschaftTeil 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 LandschaftTeil 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 Sizing Analyse hat ergeben, dass das Buffer Cache nochmals verdoppelt werden muss um die aktuelle Last zu tragen


Kundenprojekt / SGA Sizing für SAP BW LandschaftZusammenfassung


● 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 of Concept wurde 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 Youtubeansehen/anhören. https://www.youtube.com/playlist?list=PLHjsH_lB3gO5dMAQeJiJRTOcdB_w_vv3c


Ansätze im HardwarebereichStorage


● 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 / Automatic Data Optimization vermutlich 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 Commodity 2 Sockel Server möglich

– SSD / FLASH Technologie dort wo es nötig ist.



Q & A

oracle datenbank performance - db masters · adaptive executionpläne – besteht aus zwei...

Documents