Ausgewählte Performance Technologien

Performance Technologien im Überblick
Buffer Cache, Result Cache, Column Store und Automatisierung mit ILM
Ulrike Schwinn
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Ulrike Schwinn
Business Unit Database
Oracle Deutschland B.V. & Co KG
http://blogs.oracle.com/dbacommunity_deutsch

Caching Technologien über die Jahre ...
• Buffer Cache Erweiterungen über KEEP und RECYCLE Pool für Segmente
• Full Database Caching
• Pre-Loading von Tabellen und Indizes
• Pinnen von PL/SQL Objekten wie Packages, Procedures etc. im Shared Pool
Copyright © 2014 Oracle and/or its affiliates. All rights reserved.
• Pinnen von PL/SQL Objekten wie Packages, Procedures etc. im Shared Pool
• Cachen von Resultaten
• Unterstützende Techniken wie Komprimierung, Partitionierung und
Automatisierung über ILM
• Erweiterung des Cache durch Column Store – optimiertes Spaltenformat im
Cache

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
TimesTen Application-Tier
Database Cache
Result
Cache
Shared Pool oder Client
Transparent für Anwendungen
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Hybrid Columnar Compression
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
Data Buffer Erweiterung
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
Object Cache / Data Grid
für verteilte
Anwendungen
Techniken der
Datenbank In-Memory Option 12c
Row und Column In-Memory
Formate auf der selben Tabelle
Simultan und transaktions-
konsistent
Column: Analytics & Reporting
Row : OLTPMemory optimierende
Techniken
Compression
Partitioning
Parallelisierung
OLAP
3

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
4

Standard System Global Area (SGA) Komponenten
Buffer Cache Shared Pool Large Pool
Redo LogFlashback Java
Pool
Fixed SGA

Der Buffer Cache
• Manuelle Konfiguration des (Default) Buffer Cache über
Parameter DB_CACHE_SIZE
– Nutzung der Standard Blockgröße
• Falls SGA_TARGET gesetzt ist, erfolgt automatische Konfiguration
– Setzen von DB_CACHE_SIZE entspricht Minimalwert
– Setzen von DB_CACHE_SIZE entspricht Minimalwert
• Buffer Cache mit nicht Standard Blockgröße über Parameter
DB_CACHE_nK_SIZE
– Voraussetzung für Tablespaces mit Nicht Standard Blockgrößen
• Hilfestellung über Memory Advisor

Monitoring der Buffer Cache Nutzung über V$BH
SELECT o.object_name, o.object_type, o.owner, COUNT(*) NUMBER_OF_BLOCKS
FROM dba_objects o, v$bh bh
WHERE o.data_object_id = bh.objd
• V$BH listet diejenigen Blöcke mit DATA_OBJECT_ID auf, die im Moment im
Buffer Cache sind.
WHERE o.data_object_id = bh.objd
AND o.owner in ('SH')
GROUP BY o.object_name, o.owner, o.object_type
ORDER BY COUNT(*);
OBJECT_NAME OBJECT_TYPE OWNER NUMBER_OF_BLOCKS
------------------------------ --------------- --------------- ----------------
CUSTOMERS TABLE SH 3

Buffer Cache Pools: KEEP und RECYCLE POOLS
• Häufig und weniger häufig genutzte Objekte in verschiedenen
Pools
– Initialisierungsparameter DB_KEEP_CACHE_SIZE und DB_RECYCLE_CACHE_SIZE
– Alle Buffer-Pools funktionieren gleich (LRU Algorithmus)
• Festlegung der Pools und danach Zuordnung der Objekte
• Festlegung der Pools und danach Zuordnung der Objekte
– Objekte im KEEP-Pool sollen nicht verdrängt werden
– Es werden nur soviele Objekte zugewiesen, bis der KEEP Pool voll ist
– Alle Segmenttypen unterstützt (LOB, INDEX, ...)
– Objekte im Recycle Pool sollen anderen „Hot“ Objekten keine Platz wegnehmen.
• Monitoring über V$DB_CACHE_ADVICE

KEEP-Pool: Vorgehensweise
1. Pool-Größe definieren: DB_KEEP_CACHE_SIZE
2. Objekte per Storage-Klausel dem KEEP-Pool zuweisen
ALTER TABLE ... STORAGE (buffer_pool keep)
ALTER INDEX ... STORAGE (buffer_pool keep)
3. Bei Bedarf: "Pre-Load" der Objekte in den KEEP-Pool
ALTER TABLE ... MODIFY LOB (lobcol) (STORAGE (buffer_pool keep))

Pre-Loading der Objekte
• Auslösen eines Objekt-Scans über die Tabelle, den Index, das Lobsegment
• Prinzipiell eine SELECT-Anweisung (u.U mit Hint)
SELECT /*+ FULL(T1) */ sum(numeric_column), min(txt_column) FROM tabelle T1;
SELECT /*+ FULL(T2) */ dbms_lob.getlength(lob_column) FROM tabelle T2;
• Achtung: Optimierungen des Buffer Cache beachten!
– Parameter _small_table_threshhold setzen (MOS Note: 787373.1)
– Beschreibung in DBA Community-Tipp: Pre-Loading von Tabellen in 11g
https://apex.oracle.com/pls/apex/GERMAN_COMMUNITIES.SHOW_RESOURCE_BY_FNAME?P_TIPP_ID=362&P_FILE_NAME=index.html
ALTER SESSION SET "_small_table_threshold"= 2000;
-- wobei Zahl die Blockgröße angibt, die größer als das Segment ist.
-- danach kann der FTS ausgeführt werden

Full Database Caching
• Ziel: Datenbank komplett in der SGA (Buffer Cache) halten
• Neues Feature in 12.1.0.2
• Force Full Caching Mode
Die Datenbank lädt alle Objekte in den Buffer Cache und hält sie dort (keine Auslagerung mehr). Auch
NOCACHE-Objekte sind betroffen.
NOCACHE-Objekte sind betroffen.
• Information in Dictionary View V$DATABASE
SELECT force_full_db_caching FROM V$DATABASE;
FORCE_FULL_DB_CACHING
-------------------------
NO

Full Database Caching: Vorgehensweise
• Sicherstellen, dass der Buffer Cache tatsächlich groß genug ist
• Force Full Database Caching aktivieren mit ...
ALTER DATABASE MOUNT;
ALTER DATABASE FORCE FULL DATABASE CACHING;
ALTER DATABASE OPEN;
• Full DB Caching wird auf Ebene der Container-Datenbank eingestellt
– Alle Pluggable Databases betroffen
• Objekte werden bei Zugriff (Access) geladen, nicht sofort

Sogar PL/SQL Objekte "In-Memory"
• PL/SQL-Objekte werden bei Nutzung in die SGA (Library Cache) geladen
– Packages, Procedures, Functions, Type Bodys, Trigger; nicht für Tabellen und Views
– Auch hier LRU Algorithmus
– Einfluß auf PL/SQL Performance
• Möglichkeiten, Empfehlungen, Tipps ...
• Möglichkeiten, Empfehlungen, Tipps ...
– Packages anstelle von einzelnen Procedures und Functions
– Library Cache groß genug dimensionieren
– Einzelne Objekte/Cursor pinnen mit DBMS_SHARED_POOL.KEEP
execute dbms_shared_pool.keep(name=> 'scott.hispackage', flag => 'P');
execute dbms_shared_pool.keep(name=> '4158E358 2329752635', flag=> 'C');

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
14

Database Smart Flash Cache ("Flash Cache")
• Erweiterung des Datenbank Buffer Caches
– SSD ist wie ein Level 2 Cache (SGA ist Level 1)
• Schneller als Platte (100x faster for reads)
• Günstiger als Memory
• Größere Kapazität
Flash Cache (Level 2)SGA Memory (Level 1)
• Weniger Platten Bessere Performance
– I/O Durchsatz braucht viele Platten
– Flash erhöht den I/O Durchsatz
• Verfügbar auf Linux und Solaris Plattformen
Disks (NAS/SAN)

Wann nutze ich den Database Flash Cache ...?
1. Datenbank läuft auf Linux oder Solaris
2. Performance-Flaschenhals liegt beim Buffer Cache
3. Top-Wait-Event db_file_sequential_read
4. Freie CPU Ressourcen (gilt eigentlich immer)
Flash Cache (Level 2)

Nutzung des Database Flash Cache
• Init-Parameter einstellen
– db_flash_cache_file = {OS-Pfad zur Flash Disk}
– db_flash_cache_size = {Größe der Flash Disk}
• Strategien zum Pre-Loading von Objekten beachten
– Storage Klausel FLASH_CACHE { KEEP | NONE } auf Tabellenebene setzbar
Storage Klausel FLASH_CACHE { KEEP | NONE } auf Tabellenebene setzbar
• Zusätzlicher SGA-Bedarf für Metadaten-Verwaltung
– Pro Datenbank-Block 100 Byte; auf RAC-Systemen 200 Byte
– Beim Memory-Sizing berücksichtigen
• Flash Disks werden von einer Instanz exklusiv genutzt
Flash Cache (Level 2)

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
18

• Eigener Cache im Shared Pool
• Automatischer Refresh bei Daten-Änderungen !
• Einfaches Setup und Monitoring der Cache-Nutzung
• Einfache Form des Tunings für
Query und PL/SQL Result Caches
• Einfache Form des Tunings für
– SQL-Abfragen
– PL/SQL-Funktionen
• Gedacht für:
– Vorhersehbare Abfragen/sich wiederholende Abfragen
– Abfragen mit kleinen Ergebnismengen
– Langlaufende Abfragen mit teuren Berechnungen

Query und PL/SQL Result Caches - Konfiguration
• Initialisierungsparameter
RESULT_CACHE_MAX_RESULT 5 (%)
RESULT_CACHE_MAX_SIZE abh. von O/S
RESULT_CACHE_MODE MANUAL/FORCE
RESULT_CACHE_REMOTE_EXPIRATION 0 (min)
• Session Parameter RESULT_CACHE_MODE
• Einstellung RESULT_CACHE in der Tabellendefinition
• Über Hint RESULT_CACHE
0 (min)
ALTER TABLE tabelle RESULT_CACHE FORCE;
SELECT /*+ RESULT_CACHE*/ * FROM tabelle;

• Informationen über einzelne Statements und ihre Cache-
Informationen => Ausführungsplan
Monitoring
• Informationen über den Gesamtcache als Report
=> dbms_result_cache.memory_report
• Informationen über Cache Results und ihren abhängigen Objekten
=> V$RESULT_CACHE_OBJECTS

Query Result Cache: Ein Beispiel
SELECT
a.department_id "Department",
a.num_emp/b.total_count "%_Employees",
a.sal_sum/b.total_sal "%_Salary"
FROM (
SELECT department_id,
COUNT(*) num_emp,
SUM(salary) sal_sum
SUM(salary) sal_sum
FROM employees
GROUP BY department_id
) a, (
SELECT
COUNT(*) total_count,
SUM(salary) total_sal
FROM employees
) b
ORDER BY a.department_id;

Result Cache: Query Hints

Result Cache-Informationen im Ausführungsplan
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=3; dependencies=(HR.EMPLOYEES);
name="SELECT /*+ result_cache */ a.department_id "Department",a.num_emp/b.total_count
"%_Employees",
a.sal_sum/b.total_sal "%_S"
5 - column-count=2; dependencies=(HR.EMPLOYEES); attributes=(single-row); name="SELECT
5 - column-count=2; dependencies=(HR.EMPLOYEES); attributes=(single-row); name="SELECT
/*+ result_cache */ COUNT(*) total_count, SUM(salary) total_sal FROM employees"
9 - column-count=3; dependencies=(HR.EMPLOYEES); name="SELECT /*+ result_cache */
department_id, COUNT(*) num_emp, SUM(salary) sal_sum FROM employees

Result Cache-Informationen in den Statistiken
Statistiken
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
1304 bytes sent via SQL*Net to client
1304 bytes sent via SQL*Net to client
491 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed

Monitoring des Result Cache
SQL> set serveroutput on
SQL> execute dbms_result_cache.memory_report()
R e s u l t C a c h e M e m o r y R e p o r t
[Parameters]
Block Size = 1K bytes
Maximum Cache Size = 6M bytes (6K blocks)
Maximum Result Size = 307K bytes (307 blocks)
[Memory]
[Memory]
Total Memory = 151840 bytes [0.022% of the Shared Pool]
... Fixed Memory = 5296 bytes [0.001% of the Shared Pool]
... Dynamic Memory = 146544 bytes [0.021% of the Shared Pool]
....... Overhead = 113776 bytes
....... Cache Memory = 32K bytes (32 blocks)
........... Unused Memory = 27 blocks
........... Used Memory = 5 blocks
............... Dependencies = 1 blocks (1 count)
............... Results = 4 blocks
................... SQL = 4 blocks (3 count)

PL/SQL Result Cache
• Result Cache für PL/SQL Function Results
– Aktiv, wenn PL/SQL-Funktionen von PL/SQL aus aufgerufen werden
CREATE OR REPLACE FUNCTION get_datum (
p_id NUMBER, p_format VARCHAR2
) RETURN VARCHAR2
RESULT_CACHE
http://www.oracle.com/global/de/community/tipps/resultcache/index.html
RESULT_CACHE
IS
v_datum DATE;
BEGIN
select hiredate into v_datum
from emp where empno = p_id;
RETURN TO_CHAR(v_datum, p_format);
END;

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
28

Neue SGA Komponente: In-Memory Area
Buffer Cache Shared Pool Large Pool
In-Memory Area
Redo LogFlashback Java
Pool
Fixed SGA

In-Memory Column Store – Kurzbeschreibung
• Reines In-Memory Format
• Nutzung unterschiedlicher
Komprimierungsarten (2x bis
20x)
• Einschaltbar auf Objektebene
Pure In-Memory Columnar
• Einschaltbar auf Objektebene
• Verfügbar auf allen Plattformen
• Voraussetzungen
– Datenbank Release 12.1.0.2
– Manuelle Aktivierung
– Gebunden an In-Memory Option
SALES

• Der Column Store ist statisch und folgt keinem LRU (Least Recently
Used) Algorithmus
• Der Column Store ist ein reines Memory Format
• Der Column Store ist geeignet für einheitliche Zugriffe (alle Zeilen einer
Tabelle) => typisch für analytische Abfragen
Prinzipielle Unterschiede zum (traditionellen) Buffer Cache
Tabelle) => typisch für analytische Abfragen
• Der Buffer Cache hingegen ist vorgesehen für nicht einheitliche Zugriffe
(z.B. einige Zeilen einer Tabelle) => typisch für OLTP
• Der Column Store ist mit zusätzlichen neuen Optimizerzugriffen und
Komprimierungsalgorithmen ausgestattet

• Beides - Row und Column
In-Memory Formate - für
die gleiche Tabelle
• Real Time Analysen nutzen
das neue Column Format
Memory Memory
SALES SALES
Das duale Format in der Datenbank
das neue Column Format
• OLTP Applikationen nutzen
das Row Format
• Erhalt der
Transaktionskonsistenz
SALES SALES
Row
Format
Column
Format

1. Memory Allokation in der SGA über neuen Initialisierungsparameter
und danach Start der Datenbank
– Setzen von INMEMORY_SIZE Parameter (mindestens 100 MB); DEFAULT
2. Auswahl der Objekte (Spalten, Tabellen, Materialized Views,
Tablespace oder Partitionen) und Belegung mit den entsprechenden
Konfiguration in 2 Schritten
Tablespace oder Partitionen) und Belegung mit den entsprechenden
Eigenschaften (Komprimierung/Priorität)
– Über CREATE oder ALTER Kommando
Hinweise:
- u.U. überflüssige analytische Indizes löschen!
- Nicht alle Objekte müssen im Column Store vorliegen!
CREATE TABLE customers …
PARTITION BY LIST
(PARTITION p1 … INMEMORY,
(PARTITION p2 … NO INMEMORY);

Monitoring von In-Memory Scans im Ausführungsplan
• Beispiel: Schlüsselwort INMEMORY FULL
SQL> select * from table(dbms_xplan.display_cursor(format=>'BASIC'));
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
EXPLAINED SQL STATEMENT:
------------------------
Public
------------------------
select count(*) from customers_mem where cust_gender='F'
Plan hash value: 1973973873
-----------------------------------------------------
| Id | Operation | Name |
-----------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | TABLE ACCESS INMEMORY FULL| CUSTOMERS_MEM |
-----------------------------------------------------

Verwendung
• Kostenintensive Abfragen, die aus Table Scans resultieren, identifizieren
(Anwender, AWR, statspack, Advisor)
• Einige Beispiele für Abfragen, die vom In-Memory Column Store profitieren
– Scannen von vielen Zeilen und Anwendung von Filtern wie z.B. =, <, >, und IN etc.
– Abfragen einer Teilmenge von Spalten einer Tabelle (5 von 100 Spalten)
– Abfragen einer Teilmenge von Spalten einer Tabelle (5 von 100 Spalten)
– Joins von kleinen Tabellen mit einer großen Tabelle, wobei die Filter viele Zeilen
herausfiltern
– Abfragen die Operationen verwenden wie min, max und sum, group by, distinct and
count(distinct())
• Unbedingt auch weitere Tuning Techniken mitberücksichtigen
– Statistikmanagement, Plan Baseline, Result Cache etc.
.
Public

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
36

Partitionierung und mehr ...
• Tabellen partitionieren
– "Heiße" Daten in einer Partition In Memory
– "Normale" in weiteren Partitionen Standard-Storage
– "Ältere" Daten komprimieren Archive Storage
in Kombination mit verschiedenen Komprimierungsalgorithmen
Mai 2014
Apr 2014
Mär 2014
in Kombination mit verschiedenen Komprimierungsalgorithmen
• Partitionen In Memory
– Buffer Cache Strategien (KEEP, RECYCLE)
– In Memory Database (neu ab 12c)
• Voraussetzung
– Partitioning Option
Feb 2014
Jan 2014
Dez 2013

• ILM Integration in den Datenbank Kern selbst
durch neue Features wie (*)
– Heat Map
– Automatic Data Placement /Optimization
– Database Archiving
Automatisierung in 12c über ILM
– Database Archiving
• Voraussetzung: Advanced Compression Option

Das Konzept: Heat Map Tracking
• Eine Heat Map liefert Zugriffsinformationen auf die
Daten
• Ebenen
Segment: Welche Tabellen/Partitionen werden wie
Active
Frequent
HOT
– Segment: Welche Tabellen/Partitionen werden wie
verwendet?
– Block: Welche Blöcke wurden wann verändert?
• Umfassend
– Überwacht Reads ,Writes, Index und Full Table Scans
– Ausschluss der Operationen Statistics Gathering, DDLs usw.
• Performant
Frequent
Access
Occasional
Access
Dormant
COLD

Heat Map im Enterprise Manager

Automatische Datenoptimierungen
• Vor: Aktivierung der Heat Map
• Umfassen folgende Aktionen
– Komprimieren von Daten
Bewegen von Daten (auch Storage Tiering )
Less
Active
Active Historical
– Bewegen von Daten (auch Storage Tiering )
• Komprimieren in Abhängigkeit von Bedingungen wie
– Zeit nach Erzeugung (CREATION), Zugriffsverhalten (ACCESS),
Änderung an Daten (MODIFICATION) oder eigene Bedingung
• Implementierung über Policies mit CREATE/ALTER Befehlen
• Lizenzierung: EE mit Advanced Compression Option

Automatische Segment Komprimierung
• Für Tabellen (Vererbung auf Partitionen)
ALTER TABLE sh.sales
ILM ADD POLICY
row store compress advanced SEGMENT
ORDERS
• Für einzelne Partitionen
AFTER 1 DAY OF NO MODIFICATION;
ALTER TABLE sh.sales MODIFY PARTITION sales_q4_2000
ILM ADD POLICY
AFTER 1 DAY OF NO MODIFICATION;

Automatische Verlagerung (Storage Tiering)
SOURCE
Tablespace
TARGET
Tablespace
SOURCE
Tablespace
T1 Zugriff letzte Woche
T2 Zugriff heute
MOVE
55% T1
60%
55%
T3 Zugriff gestern
T2 Zugriff heute55%
T3
T2
T1 55%
SELECT * FROM dba_ilmparameters;
NAME VALUE
------------------------------ ----------
TBS PERCENT USED 55
TBS PERCENT FREE 45
...

Automatische Verlagerung am Beispiel
Policy anlegen
ALTER TABLE scott.employee
ILM ADD POLICY
TIER TO low_cost_store;
ORDERS
• Tablespace Threshold setzen/prüfen
TIER TO low_cost_store;
dbms_ilm_admin.customize_ilm(dbms_ilm_admin.tbs_percent_used,85);
dbms_ilm_admin.customize_ilm(dbms_ilm_admin.tbs_percent_free,25);
SELECT * FROM dba_ilmparameters;

Zusammenfassung
Daten Klassifikation Automatisches Durchführen
Bereiche(Scope) Aktionen
Automatische Erkennung
Bedingungen
• Welche Operationen?
WHAT IF and WHEN Then AUTOMATICALLY do
• Tablespace
• Segment
• Row/Block
Voraussetzung:
Heat Map
• Komprimieren
• Verlagern nach Storage Tier
• Beides
• Welche Operationen?
– Erzeugen
– Keine Daten-
Änderung
– Kein Daten-Zugriff
– Business Regel
• Wann?
– Nach 3 Tagen
– Nach 1 Monat
– Falls Tablespace voll

Database Buffer
Default Cache
Keep Cache
Recycle Cache
LRU-Algorithmus
TimesTen IMDB
Database Cache
Result
Cache
In-Memory
Techniken der
In-Memory
Techniken der
Middle-Tier
Exadata X4
Smart Scan
Storage Index
Smart Flash Cache
(Read/Write)
Smart Flash Logging
(Redo-Write)
TimesTen for
Exalytics
Flash
Cache
2nd level Cache
Auch für Datafiles
Coherence
Data Grid
für verteilte
Anwendungen
Techniken der
konsistent
Techniken
Compression
Partitioning
Parallelisierung
OLAP
46

Fazit
• In-Memory Technologien und Caches der Oracle-Datenbank
– Buffer Cache: KEEP und RECYCLE, Flash Cache, Result Cache, Column Store
• Mehrwert liegt in der Kombination der Technologien
– Aggregate auf normale, relationale Tabellen: In Memory DB
– LOBs, JSON, XML, Geodaten: Buffer Cache KEEP Pool
– LOBs, JSON, XML, Geodaten: Buffer Cache KEEP Pool
– Query Result Cache
• Unbedingt auch weitere Tuning Techniken mitberücksichtigen
– Statistikmanagement, Plan Baseline, Result Cache etc.
Alles mit minimalem Einfluß auf die Applikation!

Ausgewählte Performance Technologien

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Ausgewählte Performance Technologien

Similaire à Ausgewählte Performance Technologien (20)

Plus de oraclebudb

Plus de oraclebudb (6)

Ausgewählte Performance Technologien