12cjetzt4 MAA

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |

Oracle Database 12c. Jetzt. Ohne Downtime. Die Wege nach 12c.

Sebastian Solbach Senior Leitender Systemberater, BU Database Oracle Deutschland B. V. & Co. KG Markus Geis Institut für Notfallmedizin, Uniklinik München

Beginn um 14:00 - die Audioübertragung erfolgt über

Ihre PC-Lautsprecher!

http://tinyurl.com/12cjetzt

Copyright © 2015 Oracle and/or its affiliates. All rights reserved.

Audio via Computer: Audio -> Integrated Voice Conference -> Join Conference

Oracle Database 12c. Jetzt. - Rückblick

15.09.2015 – Ohne Downtime. Die Wege nach 12c. 2 Oracle Database 12c. Jetzt.




Neue Architekturen. Neue Innovationen. Der Poll

15.09.2015 – Ohne Downtime. Die Wege nach 12c. Oracle Database 12c. Jetzt. 3

Ergebnisse sind interessant: • Konsolidierung mit Standardmethoden

• Neue Funktionen und Architekturen(noch)

nicht weit verbreitet – Multitenant – Engineered Systems – In-Memory DB

• Cloud als Architektur (noch) neu

• Oracle Cloud Angebote noch recht unbekannt



Nächster Halt: Oracle Database 12c.

Oder sind Sie vielleicht schon dort? IT-Architekten, System- und Datenbankadministratoren sowie Anwendungsentwickler sind bereits unterwegs. Mit den Innovationen der Oracle Database 12c sind Sie und ihre IT für künftige Entwicklungen bestens gerüstet.

• Abheben mit der Standard Edition • Durchstarten mit der Enterprise Edition • Größter Nutzen. In-Memory, Multitenant & Co. Erleben Sie, was den erfolgreichen Einsatz von Oracle Database 12c in der Praxis ausmacht!

Persönlicher Austausch darf ebenso nicht fehlen! Sprechen Sie mit den Database 12c Experten vor Ort und erfahren Sie mehr über die neuesten Entwicklungen. Diskutieren Sie mit anderen Kunden und lernen Sie, wie einfach und schnell Sie zum neuen Datenbank-Release gelangen; wenn Sie nicht schon angekommen sind. Wichtig! Bitte nutzen Sie diese separate Anmeldung zu dem exklusiven Event für Symposium. Treffen Sie das 12cjetzt Team!

Hyatt Regency Köln


https://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x24536715ee





12cjetzt auf der DOAG Konferenz


• 12cjetzt – Flag im Vortragsprogramm

– Hören Sie Vorträge rund um Oracle Database 12c

• Dienstag, 17.11.2015 12:00Uhr: Expert Panel: Oracle Database 12c. Jetzt. – Fragen, Erfahrungen, Austausch

– Mit Frank Schneede, Mike Dietrich, Ralf Durben, ....




http://twitter.com/oraclebudb



Oracle Database 12c. Jetzt.



CAMPUS INNENSTADT

INSTITUT FÜR NOTFALLMEDIZIN UND MEDIZINMANAGEMENT

ORACLE 12 UPGRADE / AUTOMATIC BIG TABLE CACHE

Markus Geis

15.09.2015

c

INSTITUT FÜR NOTFALLMEDIZIN

UND MEDIZINMANAGEMENT

KLINIKUM DER UNIVERSITÄT MÜNCHEN®

AGENDA

• INM

• Upgrade 12c

• Ausgangssituation

• Planung und Test

• Umsetzung

• Zusammenfassung / Fazit

• automatic big table cache

• Technik

• Einrichtung

• erste Erfahrungen

15.09.2015

Upgrade / automatic big table cache – Markus Geis

9




INM

Institut für Notfallmedizin und Medizinmanagement

Teil des Klinikums der Universität München (LMU)

Qualitätsmanagement in der Notfallmedizin und

im Rettungswesen

Interdisziplinäre Forschungseinrichtung

DWH: 2 MIO Rettungsdienst-Daten / pro Jahr

www.inm-online.de

20.03.2015


10

http://www.inm-online.de/






UPGRADE 12C - AUSGANGSSITUATION

Betrieb eines 11g 3 Knoten Clusters (11.2.0.3 EE)

-> 3 Cluster-DB‘s mit ca. 3TB / 1.400 DB-Usern

Netapp Metro Cluster

Shared Disk Spaces sind über NFS eingebunden (kein ASM)

Optionen:

Partioning

Spatial (Routenberechnung und Geo-Analysen)

WICHTIG: Betrieb diverser Alt-Applikationen (Tomcat-Version)

15.09.2015


11





15.09.2015


12

Oracle-HTTP / Apache

Tomcat-Applikations-Server • JSP

Weblogic-Server • ADF • Java • MAP-Builder

Windows 7 & XP

RAC-Cluster

11.2.0.3





Frage: „Warum gleich auf Oracle 12c (12.1.0.2) ?“

Upgrade auf 11.2.0.5 genauso aufwändig (CRS + DB)

Nutzung neuer Techniken:

Routing Engine (Turn-Restrictions) -> Abbiegevorschriften

inMemory / automatic big table cache

Betriebssystem sollte auf den Knoten ebenfalls erneuert werden (RH 5 auf Oracle-Linux

6)

15.09.2015


13




UPGRADE 12C – PLANUNG UND TEST

Downtime planbar - Jahreswechsel 2014/2015

Upgrade sollte auf dem einfachsten und sichersten Weg durchgeführt werden

exp/imp (expdp/impdb) schieden auf Grund der Größe der DB’s aus ( >1,5 TB) (full-

export -> problematisch, DD-Objekte, usw.)

während des Upgrades sollten “readonly” DB’s die Infos für die Applikationen liefern

Test der Applikationen gegen 12.1.0.2

Funktionalität

Performance (Execution Pläne)

Rückfall-Ebene

15.09.2015


14





Test-Umgebung:

erzeugen DB-Kopien auf einem Test-Server via RMAN

-> (Cluster-DB nach single-instance)

WICHTIG:

preupgrd.sql

preupgrade_fixups.sql

manuelles Upgrade auf 12.1.0.2 (kein dbua)

Testbeginn:

compatible-parameter: 11.1

danach Umsetzung auf: 12.1.0.2.0

15.09.2015


15





Applikations-Test

Tomcat, VB, C++, Oracle-Mapbuilder, VPD, PL/SQL, APEX, TOAD, Java-ADF

erkanntes Problem:

alter Tomcat in Verbindung mit dem 12c-listener

Connect schlägt fehl -> Änderung der Connection Procedure

ORA-28040: No matching authentication protocol error

ORA-03134: Connections to this server version are no longer supported

sqlnet.ora (Server)

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8

15.09.2015


16




UPGRADE 12C – UMSETZUNG

Ugrade Live-System Teil-1:

RMAN -> DB-Kopien auf dem Ersatzserver

restore und recovery / kein –> DB-Clone

Schwenk der Applikationen (lesender Zugriff)

15.09.2015


17






Stoppen der CLUSTER-DB‘s

abhängen der NFS Shares

Reinstallation der Knoten:

Installation von Oracle-Linux 6

Installation von Oracle CRS und der DB-Software

Aufbau einer Cluster Test-DB

15.09.2015


18






Starten des Upgrades der vorhanden 11.2.0.3 DB‘s:

einhängen der NFS Shares

Start der DB‘s jeweils als single-instance (startup upgrade)

manuelles Upgrade

$ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql

create des Cluster-Services pro DB

single-instance DB wieder in Cluster-DB umgewandelt

zusätzliche voting-disks / ocr-Datei erzeugen

Applikationen auf die neue 12c zurückgeschwenkt

15.09.2015


19




UPGRADE 12C – ZUSAMMENFASSUNG

1.System Test mit Test-DB und Test-Applikationen

2.READONLY-DB‘s für Betrieb

3.Upgrade der Knoten

4.Upgrade auf 12c

5.Rückschwenk der Applikationen

15.09.2015


20




UPGRADE 12C – FAZIT

Oracle 12c (12.1.0.2) seit 06.01.2015 produktiv (seit ca. 250 Tagen)

stabile Release

Performanter als 11.2.0.3

(kein Kippen von Execution Plänen)

einfaches Upgrade / eigentliches Upgrade nur ca. 15 Minuten (DD)

Test und Plan ist wichtig; erfordert mehr Zeit als direktes Upgrade

(4 Monate);

nicht zu viele Varianten probieren - weniger ist oft mehr

Rückfall-Ebene schaffen

15.09.2015


21




AGENDA

• INM

• Upgrade 12c

• Ausgangssituation

• Planung und Test

• Umsetzung

• Fazit

• automatic big table cache

• Technik

• Einrichtung

• erste Erfahrungen

15.09.2015


22




AUTOMATIC BIG TABLE CACHE

Teil der Oracle „inMemory“ Technologie

verfügbar ab der Version 12.1.0.2

Feature

in allen Edition verfügbar:

SI (EE): bei sequentiellen Abfragen (PX)

RAC / EE: nur parallel-query

15.09.2015


23





Performance der DB wird durch den CACHE bestimmt

der Zugriff auf die DB-Daten sollte über den CACHE realisiert werden (DB-Blöcke)

Plattenzugriffe sollten vermieden werden

15.09.2015


24





bisheriges CACHE-Verhalten des DB-BLOCK-BUFFERS:

LRU (last recently used)-> Algorithmus

LRU-Liste verwaltet den CACHE (DB-BUFFER)

bei vollem CACHE, werden die am längsten nicht genutzten Blöcke aus dem CACHE

entfernt, um Platz für neue Blöcke zu schaffen

wichtige Objekte/Blöcke können so aus dem CACHE herausfallen

(Abfragen werden langsam / lesen von Disk)

15.09.2015


25





eine Möglichkeit in der Vergangenheit, um das Herausfallen von Objekten aus dem CACHE

zu verhindern -> KEEP-Mechanismus

bestimmte Tables konnten in den Hauptspeicher gepinnt werden

es war eine Technologie für kleine Tables

es konnten keine „Partitionen“ angesprochen werden

der Workload spielte keine Rolle / die Technik wurde durch den Administrator bestimmt

15.09.2015


26





Automatic big table cache: „ABTC“

die Technologie soll verhindern, daß oft genutzte Objekte aus dem CACHE herausfallen

der workload soll die bestimmende Größe für das CACHE-Verhalten sein

ein bestimmter Teil des DB-Block-Buffers wird für diese Technologie reserviert (bis 90%)

Technologie für große Tables (DWH)

15.09.2015


27





zwei Einstellungen für die Aktivierung:

ALTER SYSTEM SET db_big_table_cache_percent_target=55;

ALTER SYSTEM SET compatible='12.1.0.2.0‘

RAC-Cluster: „parallel query“ eingeschaltet

(automatic / adaptive)

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY=AUTO;

single instance : auch Verarbeitung von sequentiellen Abfragen

15.09.2015


28




UPGRADE 12C – TECHNIK

über einen Algorithmus wird die „Temperatur“ von Objekten berechnet (je mehr Zugriffe,

desto höher die Temperatur)

je höher die „Temperatur“ des Objekts, desto eher verbleiben diese im CACHE („ABTC“)

Es können folgende Objekte in den „ABTC“ geladen werden:

15.09.2015


29

OBJEKTE OBJECT-TYPE (v$bt_scan_obj)

Table TABLE PARTITION

Table-Partition TABLE SUBPARTITION

Index INDEX

Index-Partition INDEX SUBPARTITION




AUTOMATIC BIG TABLE CACHE - TECHNIK

SYS-Views für den “ABTC”:

Single-Instance

V$BT_SCAN_CACHE -> CACHE-Infos

V$BT_SCAN_OBJ_TEMPS -> Objekte im “ABTC”

RAC:

gV$BT_SCAN_CACHE

gV$BT_SCAN_OBJ_TEMPS

15.09.2015


30




AUTOMATIC BIG TABLE CACHE – TECHNIK

Beispiel: Platzbedarf und Infos über den „ABTC“

SELECT bt_cache_alloc, bt_cache_target, object_count, memory_buf_alloc

FROM v$bt_scan_cache;

SELECT * from gV$BT_SCAN_CACHE

15.09.2015


31

BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC

.400005755 40 3 50685

INST_ID BT_CACHE_ALLOC BT_CACHE_TARGET OBJECT_COUNT MEMORY_BUF_ALLOC

2 0,550005216490914 55 204 1706599

1 0,550000710281341 55 2563 1659568

3 0,550000788577281 55 234 1732373





Objekte im „ABTC“:

SELECT distinct obj.object_name,ts.name ts_name,subobject_name,object_type,

temperature,policy, (cached_in_mem*8192)/1024/1024 cached_mb, dataobj# , btt.inst_id

FROM gv$tablespace ts,gv$bt_scan_obj_temps btt,dba_objects obj

WHERE ts.ts# = btt.ts#

AND obj.object_id = DATAOBJ#

order by temperature desc, dataobj# ;

15.09.2015


32

OBJECT_NAME TS_NAME SUBOBJECT_NAME OBJECT_TYPE TEMPERATURE POLICY CACHED_MB DATAOBJ# ID

ILS_EINSATZMITTEL ARLIS_DATA RDB_303 TABLE PARTITION 405000 MEM_ONLY 64,4140625 1251086 2

ARLIS_DATA ARLIS_DATA ED_2012_RDB_303 TABLE SUBPARTITION 9813 MEM_ONLY 44,7109375 1029063 3

ARLIS_DATA_FA_EDAT ARLIS_INDEX ED_2008_RDB_302 INDEX SUBPARTITION 2000 MEM_ONLY 1,3671875 1046850 1





Ausprägungen des „ABTC“ (POLICY)

MEM_ONLY Objekt wird komplett im Cache gehalten

MEM_PART Teile des Objektes werden im CACHE gehalten

DISK Objekt wird komplett von DISK gelesen

15.09.2015


33

OBJECT_NAME TS_NAME TEMPERATURE POLICY CACHED_MB

ARLIS_DATA_FIRMA_P_O_IDX ARLIS_INDEX 2000 DISK 0

ARLIS_DATA_FIRMA_P_O_IDX ARLIS_INDEX 2000 MEM_PART 1,2578125

DM_TG_RDS_BODEN ARLIS_DATA 26563 MEM_ONLY 888,8046875




AUTOMATIC BIG TABLE CACHE – ERSTE ERFAHRUNGEN

einfach einzurichten / keine Änderung an Strukturen

besonders gut für partitionierte Tables verwendbar

bei Simulationsberechnungen mit wiederkehrenden SQL-Abfragen auf gleiche Table-

Partitionen

der workload bestimmt den Inhalt des CACHES

es benötigt einige Zeit, damit der workload sich richtig einpendelt

erheblicher Performance-Gewinn in unserer Umgebung

z.B. Procedure vor „ABTC“ 45 Minuten / jetzt 12 Minuten

produktiv seit ca. 3 Monaten

15.09.2015


34




VIELEN DANK FÜR IHRE AUFMERKSAMKEIT

ANSPRECHPARTNER:

Markus Geis

Klinikum der Universität München

INM - Institut für Notfallmedizin

und Medizinmanagement

Telefon: 089 / 4400-57101

E-Mail: [email protected]

Internet: www.inm-online.de

15.09.2015 35

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |

Sebastian Solbach

„12cjetzt. Ohne Downtime. Die Wege nach 12c“

15.09.2015 – Ohne Downtime. Die Wege nach 12c.



Datenbank Upgrade Möglichkeiten

Exp/Imp

Transportable Tablespaces

Golden Gate Expdp/Impdp

DBUA

Manueller Upgrade (catctl.pl)

Transient Logical Standby

Full Transportable Export / Import

Transportable Tablespaces +

RMAN Inkremental CTAS / COPY

SQL* Loader




Wichtige Fragen

• Welches Ausgangsrelease ?

• Neue Hardware / Neues Betriebssystem ?

• Characterset Upgrade ?

• Größe der Datenbank ?

• Fallback ? Wie / Wie lange ?

• Wie lange darf die Datenbank nicht verfügbar sein (Downtime) ?

– Wieviel darf Zero Downtime kosten ?

– Welcher Aufwand kann betrieben werden ?

– Wichtig bei Zero Downtime: Testen, Testen, Testen!




Upgrade/Migration nach 12c pro Release

Release exp / imp

TTS exdp / impdp

DBUA catctl CTAS DG Rolling

Full TTS + RMAN Inc.

+ GG

<=8

8i ()

9i ()

9.2 ()

10.1 ()

10.2 () () ()

11.1 ()

11.2.0.1

11.2.0.2 ()

11.2.0.3/4




Datenbankgröße vs. Upgradezeit (in Stunden)

0,1

1,0

10,0

100,0

10 GB 100 GB 1 TB 10 TB

Export/Import

DBUA / Catctl.pl

(Full) TTS

TTS + RMAN inkr.

Data Guard Rolling

Golden Gate




Export / Import (Data Pump Expdp / Impdp)

± Downtime abhängig von

± DB Größe

± CPU Leistung

± I/O Leistung

± Export / Import in jeder Oracle DB Version verfügbar (>6)

± Funktioniert mit jedem Betriebssystem (Cross Endianess)

± Funktioniert auch nach Multitenant

± Neu mit 12c: Konvertierung von LOBs nach Securefiles

• Empfehlung: Kleine Datenbanken, Nicht Downtime kritisch




Expdp/Impdp – Schneller?

• Expdp / Imdp die erste Wahl

– Wiederaufsetzbar

– PARALLEL Export & Import

– EXCLUDE (z.B. Statistiken) & INCLUDE

– COMPRESS = ALL

– Mächtige TRANSFORM Funktionen (Lobs, NOARCHIVELOG Modus)

– NETWORK_LINK

• Master Note for Data Pump (Doc ID 1264715.1)

• Export/Import DataPump Parameter VERSION - Compatibility of Data Pump Between Different Oracle Versions (Doc ID 553337.1)


https://support.oracle.com/epmos/faces/DocumentDisplay?id=1264715.1











Export/Import Downtime

Start Upgrade (Start Expdp)

Ende Upgrade (End Impdp)

Downtime: Applikation nur Read Only verfügbar




DBUA

± Nur auf derselben Hardware

± Architektur bleibt bestehen (nonCDB)

± Unabhängig von der Datenbank Größe

± Graphisches Benutzerinterface

± Datenfile Migration (z.B. nach ASM)

± Fallback Integration

• Empfehlung: Einfachste Lösung, jede Datenbank, etwas Downtime, kein OS/HW/Plattform Wechsel




Catctl.pl

± Architektur bleibt bestehen (nonCDB)

± Manuelles Vorgehen

± Unabhängig von der Datenbank Größe

± Hardwarewechsel (ggf. sogar Betriebssystem – gleiche Endianess)

• Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1) (Doc ID 1503653.1)

• Empfohlen: Bei Plattformwechsel mit etwas Downtime

$> $ORACLE_HOME/perl/bin/perl catctl.pl -n 8 catupgrd.sql






DBUA/Catctl geringere Downtime

• Dictionary Statistiken 24h vor dem Upgrade

• Audit Trail (wenn nicht benötigt Löschen)

• Catctl.pl in Parallel (= CPU Anzahl)

• Utlprp n (Paralleles Rekompilieren)

• Plattformmigration: mit RMAN & inkrementelle Backups – RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support (Doc ID 1079563.1)

• Plattformmigration: Data Guard – Mixed Oracle Version support with Data Guard Redo Transport Services (Doc ID 785347.1)

– Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration (Doc ID 413484.1)








Catctl.pl Downtime

Start Process (Pre Upgrade)

Ende Upgrade (Post Upgrade)


Kopieren auf Neues System

Änderungen Nachziehen

Catctl.pl




Transportable Tablespace

± Kopierzeit der Tablespaces

± Expdp abhängig von Anzahl Objekte

± Nachziehen von Benutzern, Synonymen, Trigger, Rollen, Sequencen

± Perfekt für Wechsel der Hardware & OS bei anderer Endianess

± Architektur kann leicht geändert werden

• How to restore a pre-12c backup to a cross-platform, cross-endian 12c database (Doc ID 1644693.1)

• Empfehlung: Geeignet bei „einfachen“ Datenbanken mit wenig Objekten, Triggern, Sequenzen. Gut für Cross Plattform.














Transportable Tablespace Downtime

Start Process (Tablespace Read Only)

Import Source (Tablespace Rea/Write)


RMAN Copy RMAN Convert Datapump

Export Import Meta

Daten




TTS + Inkrementelles Backup

• Sukzessive inkrementelle Backup werden konvertiert und angewendet (Tablespace = Read/Write)

• Letztes inkrementelles Backup wird gezogen (Tablespace Read-Only), inklusive Data Pump Metadaten Export

• Nach der letzten Anwendung des inkrementellen Backup (und Konvertierung), werden die Tablespaces eingehängt

Verringern der “Read-Only” Downtime

Oracle Database 10.2 und 11g Backups können

Restored & Recovered Cross-Platform auf Oracle Database 12c




TTS + Inkrementelles Downtime

Start Process (Inconsistent

Backup)

Import Source (Tablespace Rea/Write)


RMAN Copy / RMAN Convert

Inkrementelle Backup & Apply

Read Only / Datapump

Export

Import Meta Daten




TTS Anmerkungen

• Master Note for Transportable Tablespaces (TTS) -- Common Questions and Issues (Doc ID 1166564.1)

• Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1)

• How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN (Doc ID 371556.1)

• 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)

• 12C - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1)

• http://www.oracle.com/goto/maa







































http://www.oracle.com/goto/maa



(Full) Transportable Tablespace

± Kopierzeit der Tablespaces => RMAN Inkrementell

± Expdp abhängig von Anzahl Objekte

± Nachziehen von Benutzern, Synonymen, Trigger, Rollen, Sequenzen => Data Pump

± Perfekt für Wechsel der Hardware & OS bei anderer Endianess

± Architektur kann leicht geändert werden

• Verfügbar mit 11.2.0.3

$> impdp … VERSION=12 FULL=Y TRANSPORTABLE=ALWAYS …




Zero Downtime

• Auch ein “Rolling Upgrade” konfrontiert Entwickler mit 5 Problemen:

– Ausfall feststellen

– Wiederaufnahme im vorgegebenen Zeitfenster

– Exception Handling

– Transaktionsstatus herausfinden

– Weiterführung der aktuellen Transaktion

Richtige Zero Downtime geht über die Datenbank hinaus!




Zero Downtime

• http://www.oracle.com/goto/maa

– Client Failover Best Practices for Highly Available Oracle Databases - Oracle Database 12c

– Client Failover Best Practices for Data Guard 11g Release 2

• http://www.oracle.com/goto/rac

– Application Continuity

– Application Continuity with Oracle Database 12c

– Transaction Guard with Oracle Database 12c

Clients richtig konfigurieren

Application Servers

Database Servers

End User

Network Switches

1

2

3

4

5

6


http://www.oracle.com/goto/maa

http://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf





http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf

http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf

http://www.oracle.com/goto/rac

http://www.oracle.com/technetwork/database/options/clustering/application-continuity-wp-12c-1966213.pdf

http://www.oracle.com/technetwork/database/options/clustering/application-continuity-wp-12c-1966213.pdf

http://www.oracle.com/technetwork/database/database-cloud/private/transaction-guard-wp-12c-1966209.pdf

http://www.oracle.com/technetwork/database/database-cloud/private/transaction-guard-wp-12c-1966209.pdf



Oracle Golden Gate

± Zusätzliche Lizenz

± Replikation aufwändiger (als Data Guard)

± Datentyp Restriktionen / Performance für Hochlast

± Asynchrone Replikation

± Unabhängig Datenbankgröße

± Architektur / Cross Plattform

± Bidirektional

• Empfehlung: Near Zero Downtime für Cross Plattform, wo Data Guard nicht funktioniert und schneller Fallback sehr wichtig ist.




Flexible Logical Replication

Oracle GoldenGate

• Zieldatenbank ist “logische” Kopie und Read/Write geöffnet

• Asynchronous Replikation

• http://www.oracle.com/technetwork/middleware/goldengate/overview/ggzerodowntimedatabaseupgrades-174928.pdf

Source & Target Oracle & Non-Oracle Database(s)

Target & Source Oracle 12c

Capture Trail

Files Pump Delivery

LAN / WAN / Internet

Over TCP/IP

Trail

Files


http://www.oracle.com/technetwork/middleware/goldengate/overview/ggzerodowntimedatabaseupgrades-174928.pdf






Golden Gate Downtime

Start Process (Setup

GoldenGate)

„Umschalten Replikation“


Replikation anhalten

„Standby“ Upgraden

Restart Replikation

Clients umleiten. Kurz warten (Asynchron)




Data Guard Rolling Upgrade

± Datentyp Restriktionen

± 11 Schritte

± Nicht über alle Plattformen

± Keine Architekturänderung

± Unabhängig Datenbankgröße

± Gleichzeitig Desaster Recovery, Testumgebung

± Sehr schnell

• Empfohlen: Zero Downtime für gleiche Plattform




Patch Sets & neue Oracle Datenbank Releases

Datenbank Rolling Upgrades

STBY Synchronize – redo apply

Installation neuer Oracle Version in neues Oracle Home (A+B)

Garantierter Restore Point (A)

Datenbank A Datenbank B

Release n Release n+1

Siehe: MOS Note 949322.1

PROD STBY

Synchronize – sql apply PROD Konvertierung zur Transient Logical &

Upgrade zu neuer Version (B) PROD STBY

SWITCHOVER

Switchover, Flashback zu GRP, Mount mit neuem OH (A) STBY STBY PROD

Synchronize – redo apply Upgrade durch Redo & Synchronisation

(A) STBY STBY PROD


https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=949322.1



Einfacheres, besseres Datenbank Rolling Upgrade

12c: Active Data Guard Rolling Upgrades

Start Switchover Finish




Ziel

• Frühe Problemerkennung

• Dediziertes Interface: DBMS_ROLLING PL/SQL Package

• Zentralisierte, einfachere Ausführung

• Fehlertolerant

• Konfiguration von Rollback

• Zentalisierte Überwachung: DBA_ROLLING Views

• Data Guard Integration

Einfach, Verlässlich, Wiederholbar




Upgrade von RAC Umgebungen

• Rolling Upgrade für RAC immer möglich

• Rolling Upgrade für ASM ab 11.1

• Getrennt vom DB Upgrade (da 12c Grid Infrastruktur perfekt mit 11.2 DB)

• Gute Alternativen:

– Neuinstallation eines Knotens und „ASM Daten Diskgruppe“ umhängen

– Neuen Cluster mit Data Guard aufbauen




Upgrade RAC Umgebungen und mehr zu Data Guard

• Strategien zum RAC Upgrade

• ASM Filter Driver

• Grid Infrastruktur Management DB

• ORACHK

• DBMS_ROLLING

• 12c HA - Client Anpassungen

• PSU / DB Bundle Patch

15.10 Hyatt Regency Köln














Oracle Database 12c. Jetzt. Informationen

• Kampagnen Webseite: https://tinyurl.com/12cjetzt

– Zusatzinformationen, Foliendownload, Replay

• Twitter: @oraclebudb

• DBA Community: https://blogs.oracle.com/dbacommunity_deutsch/

• BU DB Mobile APP: https://tinyurl.com/oraclebudb


https://tinyurl.com/12cjetzt


https://blogs.oracle.com/dbacommunity_deutsch/

https://tinyurl.com/oraclebudb






Documents

12cjetzt4 MAA