1. Oracle Release Planung

Transkript

1 Ist Oracle 12c bereit für produktive Systeme? Lussi Stefan Senior Consultant Oracle Databases

2 Der Oracle Datenbank Release 12c ist nun schon seit über einem Jahr verfügbar. Dies ist Grund genug, um sich mit der Release Planung von Oracle Datenbanken auseinanderzusetzen. In diesem Artikel stellen wir einige Entscheidungskriterien und Empfehlungen vor, die es erleichtern, eine Roadmap für Oracle RDBMS Versionen in Ihrem Unternehmen zu erstellen. Mittels Beispielen aus unserer Beratungsarbeit zeigen wir zudem auf, welche Faktoren für die Migration auf Oracle 12c bei unseren Kunden entscheidend waren. 1. Oracle Release Planung Das Patch Set wurde im Juli 2014 herausgegeben und ist seit Mitte November 2014 für alle unterstützten Plattformen/Betriebssysteme von Oracle bereitgestellt worden. Allerdings für einige Betriebssysteme erst die Enterprise Edition. Die Standard Edition ist für Q angekündigt ist bereits der Terminal Release für 12cR1. Für die 1. Hälfte 2016 ist die Version 12.2 angekündigt. Der Support für Oracle 11gR2 läuft jedoch bereits im Jahr 2015 aus. My Oracle Support (MOS) Note zeigt die jeweils aktuelle Release Planung und die geltenden Supportdauer von Oracle RDBMS Versionen. Info-Tel Datum Seite 2 / 10

3 Abbildung 1: Release und Support Roadmap MOS Es gilt zu beachten, dass der rote Support-Balken jeweils nur für den Terminal Release so gilt wie es in der Abbildung oben dargestellt ist. Alle anderen, tieferen Versionen können abweichende Supportregelungen haben. So gilt zum Beispiel für die Version der waived (free) Extended Support nur bis Ende August Nur der Terminal Release hat free Extended Support bis Ende Januar Ebenfalls ist in MOS festgehalten, dass für einige Betriebssysteme (IBM, Windows, HP ) das Patch Set 2 erst als Enterprise Edition (EE) verfügbar ist. Sobald ein offizieller Zeitplan für Standard Edition (SE) Datum seitens Oracle bekannt ist, wird diese Information an selbiger Stelle bekannt gegeben. info@trivadis.com. Info-Tel Datum Seite 3 / 10

4 Abbildung 2: MOS OS Certification Matrix RDBMS Über die Certifications Lasche in My Oracle Support (MOS) kann man die aktuell unterstützten Betriebssysteme und -versionen für Oracle RDBMS Versionen ermitteln. Linux x86-64 ist auch für Oracle Linux 7 & 6 und Red Hat Enterprise Linux RHEL 5 zertifiziert. Dies wurde jedoch im Screenshot oben aus Darstellungsgründen abgeschnitten. 2. Richtlinien für einen Upgrade Bevor Oracle RDBMS 12c für produktive Systeme genutzt wird, sollten einige Abklärungen getroffen werden und Vorbedingungen erfüllt sein. Wir haben einige Regeln und Empfehlungen zusammengestellt, die dabei helfen können die nötige Vorarbeit zu leisten. Dabei unterscheiden wir zwischen Regeln, die z. B. von aussen verlangt werden, um ein vom Hersteller unterstütztes System zu erhalten und Empfehlungen, die wir aus unserer Erfahrung ableiten. 2.1 Grundsätzliche Regeln Wir empfehlen für produktive Systeme nur zertifizierte Kombinationen von Betriebssystemen und Oracle Releases zu verwenden. Andernfalls kann sich Oracle darauf berufen und den Support verweigern oder an Auflagen knüpfen. Wie im ersten Kapitel bereits erwähnt gibt es eine Liste der mit 12c zertifizierten Betriebssysteme und Versionen. Zusätzlich sind in den jeweiligen Installationsanleitungen noch genauere Anforderungen aufgelistet. Z.B. die vorausgesetzten Betriebssystem Bugfixes, System und User Settings. Wenn eingekaufte Applikationen auf die Daten zugreifen, die neu in einer 12c Datenbank gespeichert werden sollen, so gilt es auch die Zertifizierung von den jeweiligen SW Herstellern zu konsultieren. Es gibt immer wieder Hersteller, die bislang keine R1 Version von Oracle unterstützen. Falls das Auffinden der Zertifizierungsinformationen Schwierigkeiten bereitet, helfen wir gerne mit unserer Erfahrung und unserem Expertenwissen. info@trivadis.com. Info-Tel Datum Seite 4 / 10

5 Unsere generelle Empfehlung, für produktive Systeme jeweils das erste Patch Set eines Release abzuwarten, hat sich für 12.cR1 erledigt. Die Empfehlung, auf zu warten, machte übrigens auch der Oracle Upgrade Spezialist Mike Dietrich am 12c Upgrade Workshop im Juni 2014 in Baden (Schweiz). Eine Liste der in behobenen Fehler findet sich in der MOS Note Ferner raten wir, den Upgrade zu testen. Diese Tests sollten mit den gleichen Versionen und Patch Sets erfolgen, die auch später in Produktion verwendet werden und auf Systemen stattfinden die bezüglich Prozessor-Architektur und Betriebssystem möglichst identisch sind wie die produktive Umgebung. Als Faustregel gilt, je wichtiger eine Datenbank für ein Unternehmen ist, desto besser sollte getestet werden. Regel Nur zertifizierte Kombinationen von Betriebssystemen und eingekaufter SW verwenden Erstes Patchset abwarten Abschliessende Tests mit gleicher Version und Patch Set inklusive PSU Abschliessende Tests mit gleicher Prozessor Architektur und gleichem OS Patchlevel 2.2 Empfehlungen Da ein Datenbank Upgrade meist eine einmalige und komplexere Aufgabe ist, empfiehlt es sich diese Aufgabe im Rahmen eines Projektes durchzuführen. Viele Schritte können vorbereitend erledigt werden. Deshalb lohnt es sich genügend Vorlaufzeit für ein Upgrade Projekt einzuplanen. Es hat sich gezeigt, dass selbst bei wenig komplexen Datenbank Systemen eine Vorlaufzeit von einem Monat schnell vorbei ist, vor allem, wenn für die Testphasen noch Testsysteme bereitgestellt werden müssen. Wenn neue Applikationen für ein Unternehmensfeld aufgebaut werden, die Daten in einer Oracle Datenbank halten, dann empfiehlt es sich gerade mit der aktuellsten Version der unterstützten Oracle Versionen zu starten. So kann oftmals ein nachfolgendes Upgrade Projekt vermieden werden. Die Regeln von vorhin sollten jedoch erfüllt sein. Speziell eingekaufte Software sollte für die neue Oracle Version zertifiziert sein. Die erste Datenbank, die mit einer neuen Oracle Version in Produktion geht, sollte nicht gerade diejenige sein, mit den unternehmenskritischen Daten oder der höchsten Verfügbarkeitsanforderungen. Wir empfehlen den ersten Upgrade mit einer Datenbank vorzunehmen die wenig kritisch ist und die nicht für das Hauptgeschäftsfeld einer Unternehmung benötigt wird. Als Pilot eignen sich zum Beispiel Datenbanken der inneren Administration wie Zeiterfassung, Mitarbeiter-Stammdaten oder Infrastruktur-Stammdaten. Mit der Einführung einer neuen Oracle Version erhöht sich die Komplexität des Datenbank Unterhaltes. Es braucht mehr Aufwand für das Patchen, für die Verwendung verschiedener Funktionalitäten, allfälliges Scripting usw. Deshalb empfehlen wir im Rahmen des Upgrade Projektes eine Roadmap für das Ablösen von alten Oracle Versionen zu erstellen. Weiterbildung ist für jeden IT Spezialisten wichtig. So gehört nach unserem Verständnis zum Aufgabengebiet eines DBAs, dass er sich mit neuen Funktionalitäten eines Oracle Releases auseinandersetzt. Trivadis bietet hierzu Trainings an verschiedensten Standorten an. Neue Funktionalität sollte jedoch nur genutzt werden, wenn der Nutzen die möglichen Zusatzkosten übertrifft. Deshalb empfehlen wir, für die Nutzung von neuen Funktionalitäten Info-Tel Datum Seite 5 / 10

6 einen Use Case zu erstellen, der die Vor- und Nachteile und die daraus resultierenden Kosten und Nutzen aufzeigt. Spätestens zu diesem Zeitpunkt ist das Wissen über die neue Funktionalität notwendig. Empfehlung Datenbank Upgrade als Projekt planen (Vorlaufzeit berücksichtigen) Neue Business Applikationen mit aktueller Oracle Version starten Klein anfangen Anzahl der produktiv verwendeten Versionen minimieren Wissen über neue Funktionalität aufbauen Benutzung von neuen Funktionen mit einem Business Case hinterlegen 3. Beweggründe für Upgrade Bevor wir uns den Kunden-Fallstudien zuwenden, möchte ich versuchen ganz generische Faktoren aufzustellen, die ein Unternehmen dazu bewegen, Software-Upgrades durchzuführen. In der nachfolgenden Grafik sind die Bereiche bewusst überlappend gezeichnet, da es grösstenteils keine klaren Grenzen gibt. So wird zum Beispiel vielerorts ein SW Lifecycle Management betrieben, um u.a. möglichst viele Datenbanken auf einer unterstützten Version zu betreiben. Neue Funktionalität kann Kosteneinsparungen ermöglichen. Security Bug Fixes (De)- Support New Features Kosten sparen Lifecycle Mgmt Konsoli dierung IT Strategie Abbildung 3: Generische Upgrade-Beweggründe Info-Tel Datum Seite 6 / 10

7 4. Fallstudien 4.1 Finanzinstitut mit 250 Datenbanken Dieser Kunde aus dem Finanzsektor betreibt 250 produktive Oracle Datenbanken und etwa 1000 Datenbanken in den verschiedenen Test und Entwicklungsumgebungen. Die Datenbanken laufen fast ausschliesslich auf IBM AIX Servern. Strategisch soll mittelfristig auf x86 Architektur (Linux) umgestellt werden. Zusätzlich hat der Kunde entschieden, dass für beide Plattformen Oracle Automatic Storage Management ASM als Storage-Einbindung verwendet werden soll. Damit soll eine Verbesserung und Vereinfachung der Dateiverwaltung und des Dateizugriffs erreicht werden. Ferner gibt es regulatorische Bestimmungen, dass für systemkritische Bankenapplikationen nur supportete Software eingesetzt werden darf. Für Oracle 11gR2 endet der "Premier Support" Ende Januar Um all diese Anforderungen zu erfüllen, wurde das Projekt Oracle 12c gestartet. An dem Projekt waren mehrere Datenbank Engineers beteiligt. Als erstes musste eine Vielzahl von Skripten für die Version 12c und ASM angepasst werden. Auch der Upgrade wurde mit Shell Skripten automatisiert. Dann galt es, sich mit der neuen Funktionalität vertraut zu machen, um allfälliges Potential für die Bank zu erkennen. Als Pilot Datenbanken wurden die neuen Oracle Internet Directory (OID) Infrastruktur Datenbanken und die DB einer unkritischen Geschäftsapplikation ausgewählt. Für Letztere ist ein neues Release geplant, das im Januar 2015 live gehen soll. Ausgangslage Motivation für 12c Vorgehen/ Herausforderung Resultat/ Lessons-Learned 250 DBs Produktion auf AIX, Versionen 11g, 10g (De)Support, LifecycleManagement, Strategie Entscheid ASM + Linux Automatisierte Migration auf 12c mit Verwendung von ASM Pilot DBs laufen stabil mit seit Mitte Oktober. ASM Skripte mussten von auf angepasst werden, da Oracle das Verhalten verändert hatte. 4.2 Tabakindustrie mit x86 Strategie Der Kunde aus der Tabakbranche hat ein Projekt gestartet, um die Daten seiner zentralen Finanzapplikation von Oracle Version 11.1 auf AIX nach 12c auf x86 (Linux) zu migrieren. Von Beginn an durften wir an diesem Projekt mitarbeiten. Auslöser für das Projekt war der auslaufende Support von Oracle Release 11.1 und die strategische Ausrichtung auf kostengünstigere x86 Hardware. Als maximale Unterbruchszeit war ein Tag vorgegeben. Dies musste reichen, um die 4TB Daten vom AIX Server auf Linux zu kopieren und die Endianness Konversion durchzuführen. Als Vorgehen wurde transportable Tablespaces gewählt. Der gesamte Migrationsprozess wurde mit Skripten automatisiert. Diese Skripts wurden getestet und die Durchlaufzeit kontinuierlich verkleinert. Im Test steht der volle Datenbestand von 4TB zur Verfügung. Die Tests sind erfolgreich abgeschlossen. Es ist geplant, die produktive Migration über das Osterwochenende 2015 durchzuführen. Ausgangslage 11.1 Datenbank auf AIX mit 4TB Daten, zentrale Finanzapplikation info@trivadis.com. Info-Tel Datum Seite 7 / 10

8 Motivation für 12c Vorgehen/ Herausforderung Resultat/ Lessons-Learned (De)Support, OS Strategie: X86-64, um Kosten zu sparen Automation der Migration mit Skripten, Tests mit Datenabzug aus Prodution. Konversion von Big - auf Little Endianness mit transportable Tablespace und RMAN, Möglichst kleiner Unterbruch vom Business vorgegeben Tests mit akzeptierter Unterbruchsdauer abgeschlossen. 4.3 Staatsbetrieb mit Daten-Lifecycle-Management Anforderungen Der Kunde ist ein staatliches Amt. Es bestehen gesetzliche Bestimmungen, dass alte Daten gelöscht werden müssen. Zusätzlich wollte der Kunde unterscheiden können zwischen aktiven und archivierten Daten. Das vormalige Daten Lifecycle Management war mit komplexen Regeln implementiert und die Daten wurden in verschiedene Datenbanken gehalten. Es fand kein Löschen der Daten statt. Deshalb wurde der Speicherplatz knapp und somit entstand ein weiteres Problem. Die von uns vorgeschlagene Lösung basiert auf neuer Funktionalität im Information Lifecycle Management (ILM). Mit 12c gibt es neu Automatic Data Optimization (ADO) basierend auf Heat Map Statistiken. Damit können Archivierungsregeln basierend auf Zugriffsmustern implementiert werden. Die Tests verliefen positiv. Die produktive Datenbank wurde migriert und läuft nun mit12c und ADO Regeln. Die Umstellung verlief ohne Probleme und mit vollster Zufriedenheit des Kunden. Ausgangslage Motivation für 12c Vorgehen/ Herausforderung Resultat/ Lessons-Learned 11.2 DBs, Archivieren + Löschen von Daten verlangt Neue Funktionalität in ILM: ADO basierend Heat Map Statistiken Archivierungs- und Löschregeln aufgestellt und getestet. Das schnell wachsende Datenvolumen konnte so eingedämmt werden. Produktive DB auf 12c migriert und die ADO Regeln scharf geschaltet. 4.4 Smart-Karten Firma mit neuer Business Applikation Dieser Hersteller von Smart Karten und Security Print Produkten hat eine Geschäftsanwendung neu entwickelt. Im Rahmen der Einführung der neuen Applikation wurde ein Integrationsprojekt gestartet. Es wurde vorgesehen die Daten in einer Oracle 12c DB zu speichern. Eine Evaluation ergab, dass die Standard Edition für die Bedürfnisse ausreichend ist. Damit können nun erhebliche Lizenzkosten gespart werden. Für eine erhöhte Verfügbarkeit wurde ein Real Application Cluster (RAC) aufgesetzt. Zusätzlich wurde die Ausfallsicherheit mit einer Standby Datenbank verbessert. Die Standby- Datenbank wird mit unserem Produkt TVD-Standby TM betrieben. Ausgangslage Motivation für 12c Vorgehen/ Herausforderung Resultat/ Lessons-Learned Neue Business-Applikation, bestehendes SLA Neue DB für Applikation auf neuem System Aufsetzen neuer Test Systeme mit 12c, Aufsetzen produktive Systeme. Evaluation neuer Funktionalitäten 12c SE RAC System + TVD-Standby TM Es muss nicht immer die Enterprise Edition sein. info@trivadis.com. Info-Tel Datum Seite 8 / 10

9 4.5 Autohersteller mit grosser Datenbank Population auf 10g, 11g Das letzte Kundenbeispiel kommt aus der Automobilbranche. Dieser Kunde hat eine grosse Population von 10gR2 und 11gR2 Datenbanken. Die Meisten sind RAC Cluster, die auf Grid Infrastructure Cluster (GI) mit unterliegendem Automatic Storage Management (ASM) aufgebaut sind. Im Rahmen des normalen Lifecycle Managements wurde die neue 12c Funktionalität getestet. Flex ASM steht kurz vor der Einführung auf produktiven 12c RAC Systemen. Weitere neue Funktionalität wie Multitenant Database und die neuen ILM Funktionen werden derzeit geprüft. Hier gilt es zu beachten, dass u.a. die neuen ILM Funktionen (HeatMap, ADO) in Kombination mit Multitenant noch nicht unterstützt sind (siehe MOS FAQ Multitenant). Ausgangslage Mehrere hundert Produktive Datenbanken 10.2, 11.2, RAC, GI 11.2 Motivation für 12c Vorgehen/ Herausforderung Resultat/ Lessons-Learned Lifecycle Management, New Features, (De)Support Proof of Concept, Tests, Upgrade RAC, GI, Aufsetzen Flex ASM Business Case ILM, Multitenant (nicht in Kombination möglich) 12c flex ASM + RAC in Produktion Multitenant hat grossen Einfluss auf den Betrieb von Oracle Datenbanken 5. Fazit Oracle 12c ist produktionsbereit und es gibt bereits eine Vielzahl von produktiven 12c Datenbanken. Wir empfehlen die Migration auf 12c als Projekt mit vorgesehenen Tests aufzugleisen. So ist man durchgehend auf einem supporteten Release. Wir raten jedoch, die Zertifizierung von eingekaufter Software bezüglich Oracle 12cR1 vorab zu prüfen. In den oben erwähnten Kundenbeispielen finden sich viele weitere unserer Empfehlungen. Wir empfehlen, die neue Funktionalität von Oracle 12c und deren Potenzial für Ihre Unternehmung zu prüfen. Viele Datenbank und Systemadministratoren unserer Kunden setzen sich seit längerem aktiv mit 12c und den neuen Features auseinander. Besteht bei Ihnen diesbezüglich noch Handlungsbedarf, können unsere Trivadis 12c Trainings hierbei einen wertvollen Beitrag leisten und den Einstieg in Oracle 12c erheblich erleichtern. Bislang haben wir noch von keinem unserer Kunden einen valablen Business Case für die Multitenant Option gesehen. Bei einigen Kunden mit einer grossen Anzahl von Oracle Datenbanken klären wir eine mögliche Integration von Multitenant Option im Rahmen eines Proof of Concepts ab. Wir sehen hier vor alle Potenzial für grössere Test- und Entwicklungsumgebungen. Die Auswirkungen auf die bestehenden Betriebsorganisationen darf aber nicht unterschätzt und ausser Acht gelassen werden. Viel Erfolg beim Einsatz von Trivadis-Know-how und Oracle 12c wünscht Ihnen Stefan Lussi Trivadis AG Europa-Strasse 5 Tel: CH-8152 Glattbrugg Fax: Internet: Mail: info@trivadis.com info@trivadis.com. Info-Tel Datum Seite 9 / 10

10 Literatur und Links Trivadis 12c Trainings: Mike Dietrich s Upgrade Blog: "Upgrade/Migrate/Consolidate to Oracle 12c" Slide deck Wichtige MOS Notes: : Oracle Database (RDBMS) Releases Support Status Summary : Release Schedule of Current Database Releases :Complete Checklist for Upgrading to Oracle Database 12c Release 1 using DBUA : Complete Checklist for Manual Upgrades to Oracle Database 12c Release : Known Issues Introduced in Base Release : Patch Set - List of Bug Fixes by Problem Type : Multitenant Option 12c FAQ Oracle 12c Installationsanleitungen: DOAG Artikel Verfügbarkeit SE : Abkürzungsverzeichnis Abkürzung ASM GI OID RAC SE EE Bedeutung in diesem Dokument Oracle Automatic Storage Management: für Datenbanken optimierte Speichereinbindung. Grid Infrastructure: Oracle Software Paket für Cluster- und ASM Funktionalität Oracle Internet Directory: Oracle s LDAP Implementation Real Application Cluster: Oracle s Datenbank Cluster Produkt Oracle Standard Edition: abgespeckte, günstigere Ausgabe des RDBMS le Enterprise Edition: teurere RDMS Lizenz mit zusätzlichen Optionen, z.b.parallel Query, DataGuard, Advanced Compression info@trivadis.com. Info-Tel Datum Seite 10 / 10