innovacion en oracle database 12c - joan espin

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

Innovación en Oracle Database 12c

Juan A. Espin

Principal Sales Consultant

Oracle Ibérica


Agenda

• Introducción

• Arquitectura Multitenant

• In-Memory Database

• Automatic Data Optimization

• Arquitectura Maxima Disponibilidad

• Seguridad

• Integración Big Data

• Soporte JSON


Oracle Database 12c

• Más de 5 años de desarrollo

• Más de 500 nuevas características

• Más de 2500 personas/año de desarrollo

• Más de 3000 sistemas utilizados en las pruebas

• Más de 1 millón de pruebas efectuadas a diario

• Más de 1,2 millones de horas consumidas en pruebas de stress

Introducción


Oracle Multitenant Consolidación simplificada con Oracle Database 12c


Arquitectura tradicional Oracle Database Requiere memoria, procesos y ficheros de database

System Resources


Nueva Arquitectura Multitenant Memoria y procesos requeridos unicamente a nivel de container

System Resources


System Resources

Nueva Arquitectura Multitenant Memoria y procesos requeridos unicamente a nivel de container


Arquitectura Multitenant

• Un Container Data Base (CDB) es una base de datos física que contiene cero, una, o muchas Pluggable DBs (PDBs) creadas por el usuario.

• Una base de datos conectable (PDB) es una colección de esquemas, objetos de esquema y objetos no-schema que se presenta a un cliente de Oracle Net como una no-CDB.

• Una base de datos no-CDB es una base de datos tradicional Oracle que no puede contener PDBs.

• A partir de Oracle Database 12c Release 1 (12.1), una base de datos debe crearse como una CDB o no-CDB. A continuación se puede conectar una no-CDB dentro de una CDB como una PDB.

• Los clientes deben conectarse a las PDBs utilizando un nombre de servicio que se ha creado dentro de la CDB durante la fase de creación de la PDB.

Descripción


Arquitectura Multitenant Componentes de un Multitenant Container Database (CDB)

Pluggable Databases (PDBs)

PDBs

Root

CDB



• Soporte para hasta 252 PDBs concurrentes

• Una PDB se percibe y opera de forma análoga a una no-CDB

• PDB o no-CDB no diferenciables desde el punto de vista de las conexiones de los clientes

Database Link



• PDBs comparten SGA y los procesos de background

• Las sesiones foreground de los clientes unicamente conocen la PDB a la que están conectadas


0

0,5

1

1,5

2

2,5

3

CRM HCM ERP BI

GB

Pluggable Database

MEMORY

0

0,5

1

1,5

2

2,5

3

CRM HCM ERP BI DW

GB

Pluggable Database

MEMORY Arquitectura Multitenant Escalabilidad

• Unicamente pequeños incrementos en el consumo de memoria para cada una de las PDBs añadidas

0

0,5

1

1,5

2

2,5

3

CRM HCM ERP

GB

Pluggable Database

MEMORY


Arquitectura Multitenant – Ficheros en la CDB

• Cada PDB tiene su propio conjunto de tablespaces incluyendo los de SYSTEM y SYSAUX

• Las PDBs comparten: UNDO, REDO y control files, (s)pfile

• Por defecto cada CDB tiene un único TEMP tablespace, pero pueden añadirse tantos como sean necesarios

Namespaces


Arquitectura Multitenant – Users • Los local users son los equivalentes a los users-

customer-defined en una no-CDB

• Un local user se define unicamente en una PDB

• Un local user puede administrar una PDB

• Un common user se define en el root y está representado en cada PDB

• Un common user puede conectarse a cualquier PDB donde tenga permiso de “Create Sesion” y puede administrarla

• Los propietarios del sistema Oracle son los common users


Arquitectura Multitenant - Unplug / plug Simplemente desenchufar la PDB de la CDB…


Arquitectura Multitenant - Unplug / plug …y enchufar en la nueva CDB…

• El movimiento entre CDBs re reduce al simple movimiento de los metadatos de la PDB

• Los Upgrades y parcheados se simplifican enormemente

• Una PDB desenchufada contiene toda su información particular, acerca de la clave de encriptación, opatch, etc.


Arquitectura Multitenant - Unplug / plug Ejemplo

alter pluggable database HCM

unplug into '/u01/app/oracle/oradata/…/hcm.xml'

create pluggable database My_PDB

using '/u01/app/oracle/oradata/…/hcm.xml'

Plug

Unplug


Gestionar muchas Databases como una con Multitenant Backup de todas las databases como una; recovery a nivel de PDB

Un Backup

Point-in-time recovery A nivel de PDB


Gestionar muchas Databases como una, con Multitenant Una única standby database incluye todas las PDBs

Dataguard


Parcheado y Mantenimiento simplificado Una única actualización y todas las PDBs actualizadas !!

Upgrade in-place


Upgrades Simplificados Selección flexible para el parcheado y upgrade de Databases


Cluster expandido para soportar un modelo de consolidación flexible

Services

Single SGA per CDB Instance

Agilidad mejorada para cargas de trabajo dinámicas

Node1

CDB Instance 1

Node2

CDB Instance 2

Multitenant Container Database (CDB)


Services

Single SGA per CDB Instance

Node1

CDB Instance 1

Node2

CDB Instance 2

Node3

CDB Instance 3

Multitenant Container Database (CDB)

Cluster expandido para soportar un modelo de consolidación flexible Agilidad mejorada para cargas de trabajo dinámicas


Aprovisionamiento ultra-rápido Pluggable databases aprovisionables desde 0 (“seed”)


Aprovisionamiento de Multitenant

PDBs clonables desde CDBs remotas (DB link)

PDBs clonables desde el interior de la misma CDB

Clonado rápido de PDBs


Clonado de una PDB Ejemplo

create pluggable database HCMBI from HCM

create pluggable database HCMBI from [email protected]

Remote (DB Link)

Local


Ventajas de la Arquitectura Multitenant Reducción CapEx & OpEx, mayor agilidad y facil adopción

PDB auto-conteniendo cada Aplicación Transparente a las Aplicaciones Aprovisionamiento rápido (via clones) Portabilidad (via plug/unplug)

Memoria y procesos background compartidos Más aplicaciones por servidor Mayor densidad de consolidación

Operaciones comunes efectuadas a nivel CDB Gestión muchos como uno (upgrade, HA, backup) Control granular cuando se necesita


OLTP benchmark comparison

• Para 50 Databases unicamente 3GB de RAM y 27% CPU vs. los 20GB de RAM y 36% CPU utilizados por las instancias con la arquitectura tradicional

• Las Pluggable databases escalan hasta más de 250 instancias mientras que las instancias por separado solo lo hacen hasta 50 sobre la misma infraestructura

Databases: Pluggable vs no-CDB Alta Eficiencia: 6x menos recursos H/W, 5x más escalabilidad


Beneficio Característica

Reducción CapEx • Más Aplicaciones por servidor

Reducción OpEx • Gestión muchos como uno • Procedimientos y SLA estandarizados • Aprovisionamiento rápido

Mayor Agilidad • Clonado para desarrollo / test • Portabilidad mediante “pluggability” • Escalabilidad via RAC

Facil Adopción • Transparente a las Aplicaciones

Beneficios clave


Oracle Database 12c In Memory Option


Oracle Database In-Memory Option

• Intimamente integrada con Oracle Database 12c

• Proporciona rendimiento extremo para – Análisis e informes ad-hoc sobre datos en vivo

– Enterprise OLTP y Data Warehousing

– Escalabilidad ascendente y descendente

• Despliegue trivial para todo tipo de Aplicaciones y Clientes

A la Vanguardia en tecnología In-Memory


Oracle 12c: Accede a los datos en memoria, en ambos formatos simultáneamente

Rendimiento optimizado de Transacciones y Querys

Databases en formato filas versus formato columnar

Filas

Transacciones más rapidas en formato filas

– Insert o query de una orden de ventas – Acceso rápido a pocas filas, muchas columnas

Columnas

Analytics más rápido en formato columnar

– Informe de totales de ventas por estado – Acceso rápido a pocas columnas, muchas filas

ORDER

SALES

SALES

STATE


Ambos formatos fila y columna, en memoria y para la misma tabla

Simultaneamente activos y transaccionalmente consistentes

100X más rápido para Analytics & reporting: columnar

2X más rápido OLTP: filas

In-Memory Database basada en formato dual

Column

Format

Memory

Row

Format

Memory

Analytics OLTP Sales Sales

Una única BBDD en disco


Oracle In-Memory, Tecnología Columnar

Memory

Pure Columnar

Formato columnar exclusivo en la memoria, sin logging (no efectua escritura a disco)

Overhead próximo a cero para cualquier cambio – incluyendo OLTP

Nuevo formato de compresión optimizado para la memoria – 2x a 10x

Datos cargados en-memoria para tablas activas o particiones

En arranque o al primer acceso


Queries en Sub-segundos

SIMD Compare all values in 1 cycle

Compare all values

in 1 instruction

Load multiple

State values

Ve

cto

r

Re

gist

er

In-Memory Column Store

State column Sales

Ejemplo: Ventas de CA

“CA”

>100X Más

rápido

• Cada CPU scanea en local las columnas en-memoria

Los Scans utilizan instrucciones de vector SIMD ultrarrápidas

Miles de millones de filas/seg. de media, por core de CPU

CPU SIMD: Single Instruction, Multiple Data


Scans y Combinaciones de Datos desde múltiples Tablas

Sales Stores

Type=outlet

Ejemplo: Encontrar todas las ventas en tiendas outlet

TYPE

Storeid in

15,38,64

STOREID

AMOUNT

Conversión de los procesos de join en scans columnares ultrarrápidos

Joins hasta10x más rápidos

Sum


Generación de Reports en Sub-segundos

In-Memory Report Outline

Ejemplo: Mostrar tendencias venta en productos de

deporte de tiendas outlet

Stores

Products

Sales

Sales

Creación dinámica del report en memoria

Contenido del Report obtenido durante el scan

Reports hasta 20x más rápidos sin necesidad de cubos predefinidos


OLTP es ralentizado por los índices Analíticos

Tabla 1 a 3

Indices OLTP

5 a 15 Indices

Analíticos

Muchos índices en databases OLTP (e.j.: ERP) son utilizados unicamente por queries analíticas

Los Indices trabajan bien para patrones de acceso predecibles ya sea en disco o en memoria

La inserción de una nueva fila en una tabla requiere de la modificación de 10 a 20 índices analíticos: Lentitud !!


El almacenamiento columnar reemplaza los Indices Analíticos

Tabla 1 a 3

Indices OLTP

Queries analíticas 100X + rápidas

OLTP & batch: 2X - 3X + rápidos

Sin el Overhead de los Indices Analíticos

El almacenamiento columnar elimina casi totalmente el overhead de los updates

Menor Tuning & Administración

Almacenamiento columnar

en-memoria


Oracle In-Memory – despliegue trivial

1. Configurar la Capacidad de la Memoria inmemory_size = XXXX GB

2. Configurar las tablas o particiones a residir en memoria alter table | partition … inmemory;

3. Drop índices analíticos para incrementar la velocidad del OLTP


Soporte administrativo desde OEM 12c IMC Store Central


Soporte administrativo desde OEM 12c In Memory Advisor


Demostración en Oracle Openworld 2013

43

Rendimiento de Scan columnar vs. Row scan - Ambos en memoria


Automatic Data Optimization with Oracle Database 12c ILM Inteligente


Oracle Advanced Compression Nuevas Características

Ora

cle

A

dva

nc

ed

Co

mp

re

ssio

n

Oracle Database 11g Oracle Database 12c

OLTP Compression Advanced Row Compression

Secure Files Compression Advanced LOB Compression

Secure Files De-duplication Advanced LOB Deduplication

Hybrid Columnar Compression Hybrid Columnar Compression

NEW Heat Map (Object and Row Level)

NEW Automatic Data Optimization

NEW Temporal Optimization


Automatic Data Optimization (ADO)

• Un nuevo servicio (Heat Map) se encarga de construir y mantener un mapa en memoria de los bloques y segmentos más utilizados – La Información se graba periodicamente a disco

– La Información es accesible desde views o stored procedures

• ADO Permite la asignación directa de políticas a las tablas para comprimir los datos en función de su acceso. – Las Tablas o Particiones pueden moverse dinamicamente mientras son

accedidas entre los niveles de compresión

Simplificando el ciclo de vida de los Datos

Po licy 1


Heat Map Seguimiento de:

“Heat Map” tracking

– A nivel de Database Heat Map hace seguimiento del uso de tablas y particiones

– A nivel de Storage Heat Map hace seguimiento de las últimas modificaciones a nivel de bloque/fila

Simple, facil e intuitivo

– A nivel de Segmento muestra reads y writes

– Distingue entre index lookups y full table scans

– Excluye automaticamente stats gathering, DDLs, table redefinitions, etc

Alto Rendimiento – A nivel de objeto, sin coste – A nivel de Bloque < 5%

Active

Frequent

Access

Occasional

Access

Dormant

Actively

updated

Infrequently

updated,

Frequently

queried

Infrequent

access for

query and

updates

Long term

analytics &

compliance

HOT

COLD


Descubriendo los patrones de utilización de los Datos Database ‘heat map’

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0

0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 1

1 1

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0


Heat Map para una mejor Compresión de Datos Reducción Tamaño Datos = Mayor rendimiento en el acceso a Datos

Hot Data

50

111010101010101001101010101011010001011011000110100101000001001110001010101101001011010010110001010010011111001001000010001010101101000

1010101011101010011010111

0000101000101101110101010

0101001001000010001010101

1010010110100111000010100

1001010000100100001000101

0101110011010

Warm Data

101010101110101001101011100001010001011011101010100101001001000010001010101101001011010011100001010010010100001001000010001010101101001

1010101011101010011010111000010100010110111

0101010010100100100001000101010110100101101

0011100001010010010100001001000010001010101

11001101110011000111010

Archive Data

101010101110101001101011100001010001011011101010100101001001000010001010101101001011010011100001010010010100001001000010001010101101001

1010101011101010011010111000010100010110111010101001

0100100100001000101010110100101101001110000101001001

0100001001000010001010101110011011100

3X Advanced Row Compression

10X

Columnar Query Compression

15X

Columnar Archive Compression


Automatic Data Optimization (ADO) • Especificación declarativa: Condición Accion

alter table sales ilm add policy row store compress advanced segment after 3 days of no modification;

– Condiciones basadas en: Período de tiempo despues creación, acceso, modificación datos.

– Acciones pueden ser: Compression Tiering o Tablespace Tiering

•Ejecución de Políticas en background, inmediatas o planificadas – Políticas ejecutadas por defecto durante la ventana de mantenimiento, a petición,

inmediatamente, o planificadas

• Políticas extensibles para incorporar Reglas de Negocio – Reglas a medida para tener en cuenta particularidades de Negocio (p.ej.: 3 meses después de la fecha de envio de un pedido)


Automatic Data Optimization Políticas automáticas compresión asociadas a la utilización de las tablas

52

Oldest Data Most Recent Data

Po licy 1

Po licy 2

Comprimir la partición con compresión avanzada si no ha sido modificada en 30 días

Comprimir la partición con compresión columnar si no ha sido modificada en 180 días


Automatic Data Optimization Seguimiento automático de la actividad y accesos a los Datos

53


Po licy 1

Po licy 2


Automatic Data Optimization Las políticas se aplican dinámica y automáticamente a las Tablas

54


Po licy 1

Po licy 2



55


Po licy 1

Po licy 2



56


Po licy 1

Po licy 2


Automatic Data Optimization Mayor y mejor Compresión = Mayor rendimiento en acceso a Datos

57


Po licy 1

Po licy 2


Automatic Data Optimization Movimiento automático entre categorías de almacenamiento orientado a la reducción de costes

58


Po licy 1

Po licy 2

Po licy 3

Si el tablespace pasa del 90% de ocupación , comprime la partición más antigua y muevela a un almacenamiento tier 2


Automatic Data Optimization

• Detalle del“mapa de temperatura” de los datos incluyendo los tablespaces/segmentos más activamente consultados o modificados

• Soporta la creación de políticas, edición y borrado a nivel de objeto para la compresión y el movimiento automático entre niveles de almacenamiento

Data Optimization Console


• Identificación de accesos a Datos

– Heat Map de: Top 100 Tablespaces, y Top 100 Objetos

• vistas Heat Map por:

– Last Access Date

– Last Lookup Scan Date

– Last Write Date

– Last Full Table Scan Date

Automatic Data Optimization Enterprise Manager Support


Oracle Database 12c Arquitectura Máxima Disponibilidad


Oracle Database 12c Arquitectura MAA– Novedades

Application Continuity

Global Data Services

Data Guard Enhancements

RMAN Enhancements

Flex ASM


En ciertas situaciones las paradas de la Database o de la infraestructura pueden ocasionar que el trabajo “al vuelo” pueda perderse sin el conocimiento de los usuarios y/o la Aplicación.

Estas situaciones producen:

Angustia de los usuarios Duplicación del trabajo Corrupciones lógicas de Datos Rearranques de los mid-tiers Complejidades en el Desarrollo ….

El rompecabezas de las Transacciones finalizadas en estado “desconocido”

Situación Actual

Application Servers

Database Servers

End User


La Solución a las Transacciones finalizadas en estado “desconocido”

Transaction Guard

Un protocolo fiable y una API que capturan el estado de la última

transacción

Nuevo en Oracle Database 12c


Repetición segura de transacciones no finalizadas como

consecuencia de una parada planificada o no


Transaction Guard Recupera y preserva el resultado de los COMMITs

API que soporta el estado conocido del commit para cada transacción

Sin Transaction Guard, la repetición de transacciones después de una parada puede conducir a corrupcion lógica de datos

Con Transaction Guard, las aplicaciones tienen garantizado por la Database el tratamiento de cualquier error relativo a la perdida del estado de la transacción

Funcionalidad utilizada transparentemente por Aplication Continuity

Application Servers

Database Servers

End User


Application Continuity Garantiza la finalización correcta y consistente de las transacciones

Mecanismo de repetición de trabajos no finalizados (en estado desconocido)

Soluciona multitud de problemas derivados de errores hardware, software, network, y almacenamiento garantizando la finalización correcta y consistente de las transacciones

Mejora la experiencia del usuario sin requerir de costosos mecanismos de validación en las aplicaciones

Transaction Replayed

Application Servers

Database Servers

End User





RMAN Enhancements

Flex ASM





• Extensión de tipo RAC que proporciona servicios de failover y load balancing (dentro y entre data centers), así como las funciones necesarias de Gestión, para un conjunto de databases replicadas

• Teniendo en cuenta: latencia red, lag de replicación, y las políticas de definición de los servicios

Load Balancing y Service Failover para Databases Replicadas



• Clientes Reporting redirigidos a la ‘mejor’ database

– En base a localización, tiempo respuesta, datos, lag aceptable datos

– Reports ejecutaran automáticamente en el servidor con menos carga

• Failover clientes Reporting

– Si la database preferida no se encuentra disponible, la petición se redirige a otra database en la misma región o a otra remota

• Migración Servicios Globales

– Migración automática de servicios para failover/switchover si la database primaria no esta disponible, -> Arrancar el servicio de Call Center en la nueva primaria

Ejemplo Active Data Guard

Active Data Guard

Reporting Service

Call Center Service


Global Data Services Caso Uso: Active Data Guard con GDS (Todo en HA)

Cuando la Standby activa se detiene … GDS efectua el failover del History Service a

la primaria, redirigiendo las conexiones mediante FAN/FCF

Primary Active Standby

Data Guard

Orders Service

History Service


Order History View

Order Capture

History Service


Global Data Services: Resumen Arquitectura Alta Disponibilidad, globalmente replicada

• Framework que proporciona balanceo de peticiones de usuarios entre múltiples sites, replicados

– En base a localización, carga y disponibilidad

• Alta disponibilidad global

– Soporta failover automático de servicios

• GDS integra un conjunto de databases disjuntas dentro de un cloud unificado de datos y servicios

GSM - Global Service Manager

Local Standby

Local Standby

Data Center #2 EMEA

Data Center #1 APAC

Active

Data Guard

Active

Data Guard

Primary

Local Standby

Active

Data Guard

GDSCTL GDS Catalog Primary

GDS Catalog Standby

Master

Oracle

GoldenGate

Active

Data Guard

SALES POOL (sales_reporting_srvc, sales_entry_srvc)

HR POOL(hr_apac_srvc, hr_emea_srvc)

All GDS client databases connected to all GSMs

Master

Remote Standby

Reader Farm

Active

Data Guard

Global Service Managers

Global Service Managers





RMAN Enhancements

Flex ASM



El reto del “Zero Data Loss”

La distancia incrementa la penalización en el rendimiento para los entornos configurados como “Zero Data Loss”

El ineludible compromiso entre Rendimiento y “Zero Data Loss”

Primary Standby

Commit

Commit Ack

Network Send

Network Ack


Primary Standby ASYNC

Data Guard Async – Actualmente Alguna pequeña exposición a la perdida de Datos en caso de desastre


• Far Sync: Instancia Oracle “ligera” (standby control file, standby redo logs, archived redo logs, no data files)

– Recibe el redo sincronamente desde la DB primaria y lo reenvia asincronamente en tiempo-real a la standby

– Failover: Async standby transparentemente obtiene el último redo commiteado desde Far Sync y lo aplica: zero data loss failover

– Puede configurarse una segunda instancia Far Sync para transmitir en dirección inversa despues de un failover/switchover

– Las standbys terminales requieren Active Data Guard

Active Data Guard Far Sync Zero Data Loss para configuraciones en modo Async


Primary Standby

Far Sync Instance

Active Data Guard Far Sync Diagrama de flujo operacional

ASYNC

SYNC


Primary Standby

Far Sync Instance

Active Data Guard Far Sync Diagrama de flujo operacional (cont.)

No Compromise Between Availability and Performance!

ASYNC

SYNC

Zero Data Loss


Active Data Guard Real-Time Cascading Elimina el delay de la propagación entre Standby’s

Primary Standby 1 Standby 2

En 12.1, la Standby 1 reenvía el redo a la Standby 2 en tiempo real, tal como lo recibe: no se produce el delay del log switch

La Standby 2 (Active Data Guard Standby) se mantiene actualizada permanentemente y disponible para queries read-only y reports

SYNC or ASYNC ASYNC

En 11.2, la Standby 1 espera hasta el log switch antes de reenviar el redo desde los archived logs a la Standby 2





RMAN Enhancements

Flex ASM



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 0 0 0 0

1 0 0 1 1 0 1

1 0 1 0

0 1

Recovery Fine-grained de Tablas desde Backup

• Simple comando RECOVER TABLE para recuperar una o más tablas (desde la más antigua a la más reciente) desde un backup RMAN

• Elimina el tiempo y la complejidad asociada con las tareas manuales de restore, recover & export

– Facilita el recovery fine-grained + point-in-time de tablas individuales en lugar del tablespace completo

RMAN Backups


1 1 1 0 1

1 0 1 1 0 1 1 1 1 0 1

0 0 1 0 1 0 0 0 0 1

1 0 0 1

1 1 1 0 1

1 0 1 1 0

1 1 1 1 0 1

0 0

1 0 1 0

0 0

0 1

1 0 0

1

Cross-Platform Backup & Restore

• Simplifica notablemente el procedimiento de migración entre Plataformas

• Minimiza el impacto de read-only con multiples backups incrementáles

Migración simplificada entre Plataformas

Source Database (AIX)

Backup to Disk/Tape

(data files, optional endian conversion, metadata export)

Restore Backup (optional endian

conversion, metadata import)

Destination Database (Linux)


• Soporte para backup & recovery específicos para pluggable databases con nuevos parametros : RMAN> BACKUP PLUGGABLE DATABASE <PDB1>, <PDB2>;

• El comando BACKUP DATABASE efectua el backup de la CDB, incluyendo todas las PDBs

• El comando RECOVER DATABASE efectua el recovery de la CDB, incluyendo todas las PDBs

• Recovery selectivo de PDB

– RESTORE PLUGGABLE DATABASE <PDB>;

– RECOVER PLUGGABLE DATABASE <PDB>;

• Recovery Point-in-Time de PDB

– RMAN> RUN {

– SET UNTIL TIME 'SYSDATE-3';

– RESTORE PLUGGABLE DATABASE <PDB>;

– RECOVER PLUGGABLE DATABASE <PDB>;

– ALTER PLUGGABLE DATABASE <PDB> OPEN RESETLOGS; }

Pluggable Database Backup & Restore Fine-Grained Backup & Recovery para soportar Consolidaciones





RMAN Enhancements

Flex ASM



Automatic Storage Management (ASM) Overview

ASM Cluster Pool of Storage

Disk Group B Disk Group A Shared Disk Groups Wide File Striping

Correspondencia 1-1 entre instancias ASM y Servidores

ASM Instance

Database Instance

ASM Disk

RAC Cluster

Node4 Node3 Node2 Node1 Node5 ASM ASM ASM ASM ASM

ASM Instance

Database Instance

DBA DBA DBB DBB DBC DBB

Estado actual


Flex ASM: Elimina el 1:1 entre ASM y el Servidor Nuevo: Consolidación almacenamiento con ASM en Oracle Database 12c

ASM Cluster Pool of Storage

Disk Group B Disk Group A Shared Disk Groups Wide File Striping

Las Databases comparten las instancias ASM

ASM Instance

Database Instance

ASM Disk

RAC Cluster

Node5 Node4 Node3 Node2 Node1

Node5 runs as ASM Client to Node4




ASM ASM ASM

ASM Instance

DBA DBA DBB DBB DBC DBB


Oracle Database 12c Seguridad


• Enmascaramiento en tiempo real de información sensible basada en el contexto de la sesión de database

• Librería de políticas y definición rápida y simple de las mismas desde OEM

• Granular – por usuario/sesión

• Transparente a las Aplicaciones y a las actividades operacionales corrientes

Oracle Advanced Security

Presentación enmascarada de datos sensibles Control preventivo para Oracle Database 12c

Credit Card Numbers 4451-2172-9841-4368 5106-8395-2095-5938 7830-0032-0294-1827

Redaction Policy

xxxx-xxxx-xxxx-4368 4451-2172-9841-4368

Billing Department Call Center Application


Oracle Database Vault

Análisis de uso de Privilegios y Roles Control Administrativo para Oracle Database 12c

Privilege Analysis

Create… Drop… Modify… DBA role APPADMIN role

Reporting sobre privilegios y roles definidos y utilizados por la database

Ayuda en la eliminación de privilegios innecesarios/no utilizados

Reduce los riesgos de seguridad limitando la exposición de datos a privilegios innecesarios

Transparente a las Aplicaciones


Oracle Database 12c Integración Big Data

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Public 90

Oracle Big Data SQL

Una misma query SQL , para todos los datos.

Oracle SQL on Hadoop • Con un servicio Smart Scan inspirado por Exadata • Con operadores SQL nativos • Con la seguridad y fiabilidad de Oracle Database


Oracle Big Data SQL – Una nueva Arquitectura

• SQL de alto rendimiento tembién en Hadoop – Capacidades completas de Oracle SQL sobre Hadoop

– Procesos locales de querys SQL sobre los nodos Hadoop

• Integración simple de datos entre Hadoop and Oracle DB – Un único lenguaje SQL para el acceso a todos los datos

– Joins escalables entre datos Hadoop y RDBMS

• Hardware Optimizado – Red InfiniBand de alta velocidad entre Hadoop and Exadata

Public 91


Accediendo Big Data Hadoop Cluster Sin SQL Push Down

Hadoop Cluster

All columns and rows from the table are returned

100’s of Terabytes of Data WEB_LOGS

Request for Data

Low utilization of available resources

High load on database server

Select w.sess_id, w.cust_id, w.page_id From web_logs w Where w.source_country = ‘Brazil’ And w.category = ‘TV’ And w.channel = ‘Mobile’

Public 92


Accediendo Big Data Hadoop Cluster Con SQL Push Down

Select w.sess_id, w.cust_id, w.page_id From web_logs w Where w.source_country = ‘Brazil’ And w.category = ‘TV’ And w.channel = ‘Mobile’

WEB_LOGS

SQL shipped to BDA

10’s of Gigabytes of Data

Only columns and rows needed to answer query are returned

Good utilization of available resources.

SQL executed on Hadoop cluster

Lower load on Server, Faster response

Big Data SQL

Hadoop Cluster

Public 93


Oracle Database 12c Soporte Json


Soporte JSON en Oracle Database Flexible Application Development + Powerful SQL Analytics

JSON

Data accessed via RESTful service or native API’s

Data persisted in database In JSON

Data analyzed via SQL

Oracle Database 12c

SQL

Public 95

JSON, acrónimo de JavaScript Object Notation, es un formato de intercambio de datos, alternativo a XML en AJAX

http://es.wikipedia.org/wiki/AJAX


Soporte JSON en Oracle Database

• Gestión y almacenamiento de documentos JSON en Oracle Database • JSON almacenado como texto (VARCHAR2 or CLOB)

• Índices completos (inverted index) sobre documentos JSON

• Índices Funcionales sobre atributos específicos en documentos JSON

• Acceso JSON via API’s • REST services

• Document-store API for Java (más soporte de lenguajes a futuro)

• Capacidades de query SQL para documentos JSON • Reporting y análisis directamente sobre documentos JSON

• Integration simplificada con datos relacionales

Public 96

innovacion en oracle database 12c - joan espin

Technology

oracle andor

oracle net como una

una cdb como una pdb

innovacin en oracle

defined en una

datos tradicional oracle

databases como una recovery

memoria para cada una