09_12c_Ueberblick_ORACLEDayt_18092013
Werbung
Oracle Database 12c Ein Überblick Michael Reick Technischer Account Manager STCC Mitte [email protected] Oracle12c: Ein Überblick Oracle Multitenant RMan Real Application Cluster DataGuard Information Lifecyle Management Oracle Enterprise Manager12c Wo ist was! Oracle Database12c ist da Weltweite Launch Veranstaltungen seit Anfang Juni – Deutschlandweit in München, Stuttgart, Köln und Hamburg Im Juli: Webcasts für Kunden und Partner 3. September interner Webcast mit Andy Mendelsohn “Oracle Database 12c is the most advanced database solution of any type in the IT market. It will support the IT priorities and business needs of our customers for many years. The “c” stands for cloud and this updated product includes impressive cloud capabilities, allowing our customers to improve efficiency and flexibility, while delivering data centre consolidation.” (Loïc le Guisquet) Oracle Database 12c in Zahlen 5 Jahre Entwicklung 500 neue Features 2.500 Personen-Jahre 3.000 Systeme für die Tests 1 Million Feature-Tests täglich 1,2 Millionen Stunden Stresstests Lifetime Support Policy Sustaining Support Extended Support Premier Support heute JUL-2018 AUG-2012 JUL-2010 R2 JAN-2018 JAN-2015 R2 JUL-2021 AUG-2015 JUL-2013 2019 2018 2017 2016 2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf Schwerpunkte der neuen Datenbank SOCIAL BLOG 101100101001 001001101010 101011100101 010100100101 SMART METER BIG DATA ENGINEERED SYSTEMS CLOUD COMPUTING Gartner: Enterprise Private Cloud Umfrage Verfolgen Sie eine Private Cloud Computing Strategie bis 2014? 5% 17% Yes Maybe No 78% Gartner Data Center Conference Poll December 2011 Source: Gartner Top Five Trends for Private Cloud Computing, February 2012, Thomas J Bittman Private Cloud Datenbank Architekturen Mit Oracle Database 11g Virtuelle Maschinen Gemeinsame Server Dedizierte Datenbanken Gemeinsamer Server und OS Zunehmende Konsolidierung Schema Konsolidierung Gemeinsamer Server, OS und Datenbank Private Cloud Datenbank Architekturen Mit Oracle Database 12c Virtuelle Maschinen Gemeinsame Server Dedizierte Datenbanken Gemeinsamer Server und OS Zunehmende Konsolidierung Multitenant Datenbank Gemeinsamer Server, OS und Datenbank Oracle Datenbank Architektur Benötigt Hauptspeicher, Prozesse und Datenbank Dateien System-Ressourcen Die neue Multitenant Architektur Hauptspeicher und Prozesse werden nur noch auf Ebene des System-Ressourcen “multitenant containers” benötigt Die neue Multitenant Architektur Hauptspeicher und Prozesse werden nur noch auf Ebene des System-Ressourcen “multitenant containers” benötigt Multitenant Architektur Komponenten einer Multitenant Container Database (CDB) PDBs Root Pluggable Databases (PDBs) CDB Multitenant Architektur Die Multitenant Architektur unterstützt Database Link derzeit bis zu 252 PDBs Eine PDB verhält sich identisch zu einer non-CDB Ein DB-Client kann nicht erkennen, ob er an einer PDB oder einer non-CDB angemeldet ist. Multitenant Architekture – Dynamische Anteile PDBs “teilen sich” SGA und Hintergrundprozesse Vordergrundprozesse (DB Sessions) “sehen” nur die PDB an der sie angemeldet sind Multitenant Skalierbarkeit MEMORY MEMORY MEMORY 3 2,5 GB 2 1,5 1 0,5 0 CRM HCM ERP HCM ERP HCM ERP Pluggable Database Pluggable Database Pluggable Database BIBI DW Jeweils nur kleiner Speicherzuwachs beim Hinzufügen weiterer PDBs Dateien in der CDB Namespaces Jede PDB hat einen eigenen Satz Tablespaces, inkl. SYSTEM und SYSAUX PDBs teilen sich UNDO, REDO und control files, (s)pfile Als Default hat die CDB einen einzelnen TEMP Tablespace, PDBs können aber ihren eigenen anlegen Benutzer (DB User) Lokale Nutzer (“local user”) entsprechen selbst erstellen Nutzern in einer non-CDB …sind nur in einer PDB definiert …können eine PDB administrieren Ein “common user” ist im “root” definiert und wird in jeder PDB repräsentiert Ein “common user” kann sich an jede PDB anmelden, in der er “Create Session”-Privileg hat und kann diese auch administrieren Oracle-eigene Systemobjekte gehören “common users” Common Users und Privilegien Authorisierung wird genauso geprüft wie vor 12.1 Einem “common user” können Privilegien lokal für eine PDB (oder “root”) zugewiesen werden und daher in jedem Container unterschiedlich sein Alternativ können einem “common user” System Privilegien auch allgemein (“commonly”) zugewiesen werden – der Grant gilt dann im root und jeder PDB (auch in zukünftigen) Es können “common roles” erstellt werden Eine “common role” kann einem “common user” allgemein (“commonly”) zugewiesen werden Autorisierung erfolgt ausschließlich mit den Rechten die der User in dem Container hat, im dem er das SQL ausführen will Unplug / Plug Einfach aus der alten CDB “ausklinken”… Unplug / Plug …und in die neue CDB “einklinken”… Verschieben zwischen CDBs erfordert lediglich das Verschieben der Metadaten der PDB Upgrades und Patching werden dadurch einfacher Eine “ausgeklinkte” PDB beinhaltet Infos zu lineage, opatch, encryption keys etc. Unplug / Plug Beispiel Unplug alter pluggable database HCM unplug into '/u01/app/oracle/oradata/…/hcm.xml' Plug create pluggable database My_PDB using '/u01/app/oracle/oradata/…/hcm.xml' “Manage Many as One” mit Multitenant Gemeinsames DB-Backup; Recovery auf Pluggable Database Ebene Ein Backup Point-in-time Recovery auf Pluggable Database - Ebene “Manage Many as One” mit Multitenant Eine Standby Datenbank deckt alle Pluggable Databases ab Multitenant für vereinfachtes Patching Änderungen nur einmal anwenden, alle Pluggable Databases sind aktualisiert Upgrade in-place Multitenant für Upgrades Flexibilität beim Patchen und & Upgraden von Datenbanken Verbesserte Agilität bei Änderungen der DB-Last Cluster-Erweiterung für flexible Konsolidierungsmodelle Services CDB Instance 1 CDB Instance 2 Single SGA pro CDB Instanz Node1 Multitenant Container Database (CDB) Node2 Verbesserte Agilität bei Änderungen der DB-Last Cluster-Erweiterung für flexible Konsolidierungsmodelle Services CDB Instance 1 CDB Instance 3 CDB Instance 2 Single SGA pro CDB Instanz Node1 Node3 Multitenant Container Database (CDB) Node2 Vorteile von Flexibilität und Portabilität Eine PDB kann SLAs “durchwandern” je mehr “mission critical” sie wird GOLD SILBER BRONZE RAC, Data Guard, Tägliche inkr. Backups Data Guard, Tägliche inkr. Backups Wöchtentliche Full Backups Multitenant für schnelles Ausrollen von DBs Pluggable Datenbanken können schnell aus “seed DB” erzeugt werden Multitenant für schnelles Ausrollen von DBs Schnelles Cloning von PDBs PDBs können innerhalb der gleichen CDB geklont werden PDBs können aus “remote CDBs” geklont werden Klonen einer PDB Beispiel Lokal create pluggable database HCMBI from HCM Remote (über DB Link) create pluggable database HCMBI from [email protected] “pro PDB” vs “pro CDB” Feingranulare Kontrolle wo angemessen – trotz gemeinsamer CDB-Operationen Pro CDB Pro PDB Eine Oracle Software Version RMAN point-in-time recovery Data Guard “Ad hoc” RMAN Backups Geplante RMAN Backups Flush shared pool Einige Eigenschaften/Parameter, z.B. einheitl. Character Set Parameter für die gilt Redo und Undo IsPDB_Modifiable = 'TRUE' Vorteile der Multitenant Architektur Weniger Kosten, Mehr Agilität, Einfache Einführung “Self-contained PDB” für jede Anwendung Applikationen laufen unverändert Schnelles Ausrollen (über Clones) Portabilität (durch “Plug/Unplug”) Gemeinsame Nutzung von RAM und Prozessen Mehr Applikationen pro Server Gemeinsame Verwaltung auf CDB-Ebene “Manage many as one” (Upgrade, HA, Backup) Granulare Kontrolle wo angemessen Verwalten von geteilten Ressourcen Resource Management in einer Multitenant Umgebung Niedrige Priorität Mittlere Priorität Hohe Priorität Verteilen von Ressourcen zwischen PDBs Grundsätzlich: PDBs konkurrieren um gemeinsame Ressourcen Mit dem Resource Manager stellt man daher pro PDB ein: – CPU – Exadata I/O – Sessions – Anzahl der “Parallel Execution Servers” Konfigurierte Policies regeln, wie Ressourcen benutzt werden: – …über eine Default Konfiguration die auch bei Hinzufügen/Entfernen von PDBs funktioniert – …über harte Limits (“you get what you pay for”) Verteilen von Ressourcen zwischen PDBs Das zugrundelegende Standardmodell basiert auf folgenden Annahmen: – Eine Anzahl “Shares” wird jeder PDB zugewiesen (Default: 1 Share pro PDB) – Die Summe der Shares ist beliebig – Die Summe der Shares entspricht der Gesamtleistung – Zusätzlich: Ein optionales “Cap” (d.h. ein maximales Nutzungslimit) kann jeder PDB zugewiesen werden (Default: Kein Cap, d.h. max 100%) Zuteilen von CPU-Leistung Ein “CDB Resource Plan” nutzt “Shares” zur Verteilung von CPU-Leistung für PDBs 2 Shares 1 Share 1 Share Pluggable Database Shares Garantierte CPU-Leistung Maximale CPU-Leistung HCM 2 2/4 = 50% 100% CRM 1 1/4 = 25% 100% ERP 1 1/4 = 25% 100% Upgrade auf Multitenant Schritt 1: Upgrade der “alten” Datenbank “in-place” Upgrade in Place Upgrade auf Multitenant Schritt 2: Aktualisierte Datenbanken “einklinken” Upgrade auf Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen Upgrading to Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen Keine Applikationsänderungen nötig Upgrade auf Multitenant - Syntaxbeispiel „Frisch upgegradete“ Non-CDB im READ ONLY-Modus starten, dann: SQL> BEGIN DBMS_PDB.DESCRIBE( pdb_descr_file => '/home/oracle/ncdb.xml'); END; / Resultat: XML-Datei mit Metadaten (Speicherort und Einstellungen aller Datendateien) Upgrade auf Multitenant - Syntaxbeispiel (Forts.) Non-CDB herunterfahren, DB-Dateien und zuvor erzeugte XML-Datei auf neuen Server kopieren, dann: SQL> CREATE PLUGGABLE DATABASE pdb1 USING '/home/oracle/ncdb.xml' SOURCE_FILE_NAME_CONVERT= FILE_NAME_CONVERT= STORAGE (MAXSIZE 100G ('/oradata/noncdb', '/oradata/tmp' ('/oradata/tmp', '/oradata/pdb1‚ ) MAX_SHARED_TEMP_SIZE 900M); Skript $ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql ausführen Neue PDB Read/Write öffnen Upgrade auf Multitenant – Variante 2: Migration über Replikation ① Neue PDB “from Seed” erzeugen ② Inhalte replizieren z.B. über Oracle GoldenGate oder Data Pump 1. Multitenant für Test und Entwicklung Schnelle, flexible Kopien und Snapshots von Pluggable Databases 2. Konsolidierung von vereinzelten Anwendungen “Teilt” den Overhead von Speicher und Prozessen System-Ressourcen 3. Self-Service Database as a Service (DBaaS) Auswählen von Größe und Service Level ✔ ✔ GOLD RAC, Data Guard, Tägl. Incrementals SILBER Data Guard Tägl. Incrementals BRONZE Wöchentl. Full Backups 4. Multitenant. Ideal für SaaS. Mandantenfähig durch die Datenbank, nicht die Anwendung 5. Multitenant. Ideal für ISVs. Anstelle von langwierigen Setup-Skripten u.ä.: Verteilung von vorkonfigurierten Anwendungen als PDB Kundenzitate “Oracle Multitenant will help lower our administrative costs since we can now manage many databases as one with fewer software installations and patches during the lifetime of our applications.” (Postbank) “Oracle Multitenant allows us to consolidate hundreds of databases onto an Oracle Real Application Clusters environment whilst guaranteeing the separation that drove us to put them on separate servers previously.” ( Logical Technology) “.. Das muß ich sofort ausprobieren ... ” ( Kunde beim Launch in Stuttgart) Einige interessante RMAN Features … Einfacher Befehl um einzelne Tabellen aus dem Backup wiederherzustellen 1 0 1 0 1 0 1 0 1 1 1 0 1 0 0 1 1 0 1 1 0 1 1 1 1 0 0 0 1 0 1 00 0 0 1 0 0 1 1 0 1 1 0 1 0 0 1 Source Database (AIX) RMAN Backups – Eliminiert komplexes und zeitaufwendiges TSPITR mit Export RMAN> RECOVER TABLE … Destination Database (Solaris) Cross-Platform Backup & Restore – Einfach und schnell, kein Skripting 1 1 1 01 1 0 1 1 0 1 1 1 1 0 1 0 0 1 0 1 00 0 0 1 1 00 1 10 1 1 1 1 0 1 1 1 1 0 1 1 0 1 1 0 0 00 1 0 1 0 0 1 00 1 Backup to Disk/Tape – Ideal für Migrationen Restore Backup Oracle Flex Cluster HA für Applikationen Neue Oracle Clusterware basierende HA Topology 2 Arten von Clusterknoten Leaf Nodes Hub nodes Traditionelle Knoten, eng mit Netzwerk und Storage verbunden für I/O íntensiven Workload Hub Nodes Leaf nodes Neuer Typ in 12c mit weniger Abhängigkeiten Eigene Fehler bzw. Heartbeat Einstellungen Brauchen keinen direkten Shared Storage Zugriff Geeignet für Applikationen Oracle Flex Cluster HA für Applikationen Neue Oracle Clusterware basierende HA Topology 2 Arten von Clusterknoten Leaf Nodes Hub nodes Traditionelle Knoten, eng mit Netzwerk und Storage verbunden für I/O íntensiven Workload Hub Nodes Leaf nodes Neuer Typ in 12c mir weniger Abhängigkeiten Eigene Fehler bzw. Heartbeat Einstellungen Brauchen keinen direkten Shared Storage Zugriff Geeignet für Applikationen ASM Überblick Oracle Database Oracle Database ASM Operating System File System and Volume Management File System Logical Volume Manager Server Operating System Server Automatic Storage Management • Der bevorzugte Storage Manager für Oracle Datenbanken ( Striping / Mirroring ) • Einfache Verwaltung • Performance von Raw Volumes • ASM Status > 65% aller RAC-Installationen > 30% aller 11g-Kunden > 10TB auf ASM (VLDB) ASM Überblick Oracle Datenbank 11.2 RAC Cluster Database Instance One to One Mapping of ASM Instances to Servers ASM Instance Node1 Node2 Node3 Node4 Node5 ASM Cluster Pool of Storage Shared Disk Groups Wide File Striping Disk Group A Disk Group B ASM Disk ASM Überblick 12c RAC Cluster Database Instance One to One Mapping of ASM Instances to Servers ASM Instance Node1 Node2 Node3 Node4 Node5 ASM Cluster Pool of Storage Shared Disk Groups Wide File Striping Disk Group A Disk Group B ASM Disk Flex ASM Oracle 12c: Kein 1 zu 1 Mapping mehr RAC Cluster Database Instance Databases share ASM instances ASM Instance Node1 Node2 Node3 Node4 Node2 Node1 runs as runs as ASM ASM Client to Client to Node3 Node2 Node4 ASM Cluster Pool of Storage Shared Disk Groups Wide File Striping Disk Group A Node5 Node5 runs as ASM Client to Node4 Disk Group B ASM Disk Flex ASM Verbesserungen 511 Diskgruppen Kommando zum Umbenennen von ASM Disk ASM Patch-Level Verifizierung (nicht während eine Rolling Upgrades) Replikation von physischen Metadaten – Virtuelle Metadaten wurden bisher schon über ASM Mirroring repliziert ASM Verbesserungen 12c Datenverteilung – Failure Group Repair Timer – Schnellerer Plattenaustausch (Ohne Rebalance) – Disk Resync (Checkpointing) – „Priority“ Rebalance (Controlfile & Redologs zuerst) Datensicherheit – Data Scrubbing Performance – Gleichmäßigere I/O Verteilung (Preferred Mirror Read) – Typisierung der ASM Diskgruppe Oracle Data Guard Architektur Data Guard Protektion Modi Daten Sicherheit, Performance, Verfügbarkeit Mode Risk of data loss Transport If no acknowledgement from standby: Maximum Protection Zero Data Loss Double Failure Protection SYNC Stall primary until acknowledgement is received from replica Maximum Availability Zero Data Loss Single Failure Protection SYNC Stall primary until acknowledgement is received or timeout threshold period expires – then resume processing Maximum Performance Potential for Minimal Data Loss ASYNC Primary never waits for standby acknowledgement Active Data Guard Far Sync Redolog-"Repeater" für Data Guard Optimierter Transport der Redo-Daten über große Entfernungen – Minimale Oracle-Instance Standby Control File, Standby Redo Logs, Archived Redo Logs, keine Datendateien – Redo wird synchron von der Primärdatenbank empfangen … – … und asynchron an die Standby Datenbank weitergeleitet Verbessertes Failover: – Standby erhält "letzte Änderungen" automatisch von Far Sync Instanz – Zweite "Far Sync Instance" zur Unterstützung der Gegenrichtung Standby Datenbanken müssen Active Data Guard Standbys sein Active Data Guard Far Sync Systematische Darstellung Standby Primary SYNC ASYNC Far Sync Instance % 67 der gestohlenen Daten kamen aus Datenbanken % 76 der Datendiebstähle wurden erst möglich durch schwache oder gestohlene Zugangsdaten 69% der Datendiebstähle wurden nicht vom Eigentümer der Daten bemerkt, sondern von Dritten gemeldet % 97 der Datendiebstähle wären durch einfache Schutzmassnahmen zu verhindern gewesen Was macht Datenbanken so verwundbar? 80% der IT Security Programme gehen an der Datenbank vorbei Forrester Research “Unternehmen setzen sich Risiken aus, von deren Existenz sie nicht einmal etwas ahnen. Vor allem, weil immer mehr Angriffe auf Datenbanken über legitimierte Zugänge erfolgen." Netzwerk Security Authentifizierung & Benutzer Security Email Security SIEM Datenbank Sicherheit Web Application Firewall Endpoint Security Höchste Sicherheit durch Schutz auf allen Ebenen PRÄVENTION DETEKTION ADMINISTRATION Verschlüsseln Aktivitäten überwachen Privilegien analysieren Redigieren und Maskieren Auditieren und Berichten Sensible Daten finden Privilegierte Benutzer kontrollieren Database Firewall Konfigurationen verwalten Höchste Sicherheit durch Schutz auf allen Ebenen PRÄVENTION DETEKTION ADMINISTRATION Verschlüsseln Aktivitäten überwachen Privilegien analysieren Redigieren und Maskieren Auditieren und Berichten Sensible Daten finden Privilegierte Benutzer kontrollieren Database Firewall Konfigurationen verwalten Verschlüsseln ist die Basis Oracle Advanced Security (ASO) Transparent Data Encryption Speichermedien Schützt Daten auf Speichermedien Backups Erfordert keine Änderungen von Anwendungen Exports Enthält das Schlüssel Management Dezentrale Aufbewahrung Systembelastung vernachlässigbar Integriert in die Oracle Technologien – Exadata, Advanced Compression, ASM, Golden Gate, DataPump etc. Anwendungen Transparent Data Encryption Oracle Advanced Security (ASO) Neue, eigene Syntax zur Verwaltung von Wallet und HSM – Voraussetzung ADMINISTER KEY MANAGEMENT Privileg oder SYSKM ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '$ORACLE_HOME/network/admin' IDENTIFIED BY einpasswort; – Schlüssel können importiert, exportiert, zusammengeführt (merge) und automatisch gesichert werden Neue Views zur besseren Kontrolle von Wallets und Schlüsseln – V$ENCRYPTION_WALLET, V$ENCRYPTION_KEYS und andere Höchste Sicherheit durch Schutz auf allen Ebenen PRÄVENTION DETEKTION ADMINISTRATION Verschlüsseln Aktivitäten überwachen Privilegien analysieren Redigieren und Maskieren Auditieren und Berichten Sensible Daten finden Privilegierte Benutzer kontrollieren Database Firewall Konfigurationen verwalten Daten unkenntlich machen Oracle Advanced Security (ASO) Data Redaction Abhängig von Umgebungsvariablen wird JEDE AUSGABE in Echtzeit maskiert Kreditkarten 4451-2172-9841-4368 5106-8395-2095-5938 7830-0032-0294-1827 Redaction Policy Bibliothek mit gängigen Policies ist im Lieferumfang enthalten Transparent für Anwendungen, xxxx-xxxx-xxxx-4368 4451-2172-9841-4368 Call Center Mitarbeiter Rechnungsabteilung Benutzer und Datenbankadministratoren Graphische Unterstützung schon heute Data Redaction in EM Cloud Control 12c Daten für Entwicklung und Test maskieren Oracle Enterprise Manager Cloud Control Data Masking Pack NAME Oracle Data Masking Sensible Daten durch typgerechte harmlose Daten ersetzen Referentielle Integrität wird erhalten Bibliothek mit editierbaren Vorlagen und Formaten ist im Lieferumfang enthalten Vorlagen für Anwendungen verfügbar Unterstützt auch das Maskieren in Nicht-Oracle Datenbanken Production SOZIALVERSNR GEHALT AGUILAR 203-33-3234 40.000 BENSON 323-22-2943 60.000 Produktion Entwicklung, Test NAME SOZIALVERSNR GEHALT ANSKEKSL 323—23-1111 60.000 BKJHHEIEDK 252-34-1345 40.000 Information Lifecycle Management in Oracle12c Direkte Integration in den Datenbankkern – Heat Map: automatisches Monitoring und Klassifikation (Hot/Cold Data) – Automatic Data Optimization/Placement – Policies werden automatisiert in der Datenbank ausgeführt Zusätzlich Erweiterungen in Bereichen wie ... – Kompression – Partitionierung Heat Map Tracking Active Frequent Access Occasional Access Dormant HOT Einfaches Setup : ein Parameter Actively updated Monitoring: Views, Packages, Enterprise Manager Infrequently updated, Frequently Queried Infrequent access for query and updates Long term analytics & compliance COLD 2 Ebenen: Segment und Block – Welche Tabellen und Partitionen werden verwendet? – Welche Blöcke wurden zuletzt verändert? Umfassend – Trackt Reads und Writes, Lookups, Scans – Aktuell und in Historie Performant Heat Map für Tabellen und Partitionen OR RS DE Welche Tabellen und Partitionen werden wie verwendet? Ein Ausschnitt ... OWNER ---------SH SCOTT SCOTT SCOTT SCOTT SCOTT SCOTT OBJECT_NAME ----------------------CUSTOMERS_PK DEPT EMP EMP EMP PK_EMP PK_EMP TRACK_TIME ---------------25.06.2013 22:48 25.06.2013 12:48 26.06.2013 12:30 25.06.2013 12:48 24.06.2013 11:47 26.06.2013 22:30 25.06.2013 22:48 WRI --NO NO YES NO NO NO NO FUL --NO YES YES YES YES NO NO LOO -YES NO NO NO NO YES YES Automatische Daten Optimierung OLTP Reporting Compliance & Reporting 10x komprimiert 15x komprimiert Im Quartal Advanced Row Compression für OLTP Im Jahr Columnar Query Compression für schnelle Analysen Jahre zuvor Columnar Archive Compression für max. Kompression Automatisch und Online Komprimierung/ Verlagerung Storage Tiering Automatische Daten Optimierung D OR S ER ALTER TABLE EMPLOYEE ILM ADD POLICY TIER TO <LOW_COST_TABLESPACE> 1. Tabellen wachsen Daten werden komprimiert 2. Tablespace mit Partitionen erreicht Grenze 3. Partitionen werden in einen anderen Tablespace verlagert Heat Map im Oracle Enterprise Manager Cloud Control 12c und die Datenbank 12c Cloud Control 12c unterstützt Oracle Database 12c Voraussetzung – Cloud Control 12c Release 2 (12.1.0.2) mit aktuellem Plugin – Verfügbar seit Februar 2013 In Kürze komplette Feature-Unterstützung EM Database Express Neues Werkzeug mit Oracle Database 12c Automatische Installation Monitoring und Management einer einzelnen Oracle Datenbank 12c Nicht für die komplette Administration (aktueller Stand) – Einfache Konfigurationen – Kein Backup/Recovery, Resource Management etc. – Sehr gut geeignet für Performance Monitoring (Performance Hub) Oracle12c Database Express Nicht zu vergessen: SQL Developer Unterstützt Oracle Database 12c Seit Release 3.0 DBA Unterstützung – Oracle Multitenant – Data Redaction – Resource Manager – Data Pump – SQL Tuning Advisor : Informationen in deutscher Sprache Tipp "Oracle Database 12c ist verfügbar" Communities – DBA Community – APEX Community – Linux und Virtualisierung – Exadata Community Veranstaltungen – http://tinyurl.com/odd12c Graphic Section Divider
