Евгения Курмачева (oracle): oracle database 12c

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

Oracle Database 12c Новые Возможности

Евгения Курмачева Представитель на Урале Oracle CIS


Oracle - №1 на рынке RDBMS

Source: Gartner’: “Market Share: All Software Markets, Worldwide 2012,” March 29, 2013, By Colleen Graham, Joanne Correia, David Coyle, Fabrizio Biscotti, Matthew Cheung, Ruggero Contu, Yanna Dharmasthira, Tom Eid, Chad Eschinger, Bianca Granetto, Hai Hong Swinehart, Sharon Mertz, Chris Pang, Asheesh Raina, Dan Sommer, Bhavish Sood, Marianne D'Aquila, Laurie Wurster and Jie Zhang

Oracle 48,3%

IBM 18,9%

Microsoft 17,8%

SAP 5,8%

Teradata 3,9%

InterSystems 1,0%

Progress 0,8%

Others 3,6%


У Oracle много СУБД

Oracle Database 12c

TimesTen

BerKeley DB

Oracle Lite

MySQL

Вcтроенные СУБД RDBCODASYLExpress

Hyperion Essbase NoSQL DB

Oracle Databases


Oracle Database 12c

• Более 5 лет разработки • Более 500 новых возможностей • Более 2,500 человеко-лет разработки • Более 3,000 систем протестировано • Более 1 миллиона тестов ежедневно • Более 1.2 миллиона часов стресс тестирования


Консолидация Баз Данных Традиционные способы

Сте

пень

кон

соли

даци

и

Консолидация Схем

Разделяемые серверы, ОС и БД

Виртуальные Машины

Разделяемые серверы

Кластерные Базы Данных

Разделяемые серверы и ОС

Public 7


Сте

пень

кон

соли

даци

и

Консолидация Баз Данных Oracle Database 12c Multitenant

Разделяемые серверы, ОС и БД

Подключаемые БД Кластерные Базы Данных

Разделяемые серверы и ОС

Виртуальные Машины

Разделяемые серверы

Public 8


Oracle Database: Традиционная архитектура Требуются память, процессы и файлы базы данных

Системные Ресурсы


Новая Мультиарендная Архитектура Память и процессы нужны только для контейнерной базы



Новая Мультиарендная Архитектура Память и процессы нужны только для мультиарендного контейнера



Преимущества мультарендной архитектуры

Самостоятельная PDB для каждого приложения Приложения не меняются Быстрое развертывание (через клоны) Переносимость (через pluggability)

Разделяемые память и фоновые процессы Больше приложений на сервере

Общие операции выполняются на уровне CDB Управление многими как одной (upgrade, HA, backup) Гранулярный контроль там, где надо


• Сравнение на OLTP-тесте Всего 3Гб памяти из 20Гб было использовано для 50 баз данных

• Контейнер БД-х был масштабирован до 250 баз, тогда как отдельные БД – максимум до 50 !

Сравнение: БД в контейнере и отдельные БД Очень эффективно: в 6x меньше ресурсов H/W, в 5x раз больше масштабируемость


1. Разработка/ Тестирование – начните отсюда!

2. Консолидация разрозненных приложений

3. База данных как сервис (DBaaS) в частном облаке

4. Software as a Service (SaaS)

5. ISV: Распространение пакетных приложений и их данных

Варианты использования Oracle Database 12c Multitenant


Снижение затрат на хранение данных

v


Проблемы роста объема данных

• IT должны поддерживать постоянно растущие объемы данных – Взрывной рост из-за онлайн доступа и нового контента – Правительственные законы о сохранении данных

• Производительность снижается при увеличении объемов данных

• IT бюджеты не растут • Необходимо обеспечить рост объема данных

– Без снижения производительности – Без роста стоимости – Решение – сжатие и несколько слоев хранения


Автоматическая оптимизация данных (ADO)

• Температурная карта в памяти (heat map) отслеживает доступ к сегментам и блокам – Данные периодически пишутся на диск – Информация доступна через views или хранимые процедуры

• Можно описать политики сжатия или перемещения на основе информации о доступе к данным – Таблицы или секции могут быть сжаты и при этом доступ к ним

сохранится

Упрощение управления жизненным циклом информации (ILM)


Автоматическая Оптимизация Данных Сжатие с различной степенью в зависимости от использования

Oldest Data Most Recent Data

No Compression Advanced Row Compression

Hybrid Columnar Query

Compression

Hybrid Columnar Archive

Compression

3X Compression

OLTP

10X Compression

Reporting

15X Compression

Compliance

Public 18


Автоматическая оптимизация данных Добавление политик сжатия и перемещения к таблицам


Сжать секции с помощью Advanced Compression, Если они не изменялись более 30 дней

Выполнить сжатие Hybrid Columnar Compression секций, если они не изменялись более 180 дней


Автоматическая оптимизация данных Температурная карта отслеживает активность сегментов и блоков



Автоматическая оптимизация данных Политики автоматически применяются к таблицам


Если в течение 30 дней секции не изменялись, они будут сжаты с помощью advanced row compression




После180 дней без модификации старые секции будут сжаты с помощью Hybrid Columnar compression


Автоматическая оптимизация данных Уменьшается объем хранения, чтение выполняется быстрее



Автоматическая оптимизация данных Автоматическое перемещение данных для снижения стоимости

хранения


Если tablespace почти заполнено, сжать старые секции с помощью Archive Hybrid Columar Compression и переместить их на 2 уровень хранения


Oracle Database 12c Heat Map и ADO

• Простота – Автоматически – Прозрачно

• Уменьшается стоимость хранения • Увеличивается производительность

Особенности


Новые Возможности Высокой Надежности

v


Maximum Availability Architecture

Active Data Guard – Защита от катастроф – Нагрузка на чтение

GoldenGate – Active-active – Heterogeneous

RMAN, Oracle Secure Backup – Backup to tape / cloud

Активная реплика

Edition-based Redefinition, Online Redefinition, Data Guard, GoldenGate – минимальное время планового простоя, миграции

RAC – масштабируемость – Защита от сбоя сервера

Flashback – Защита от

ошибок человека

Промышленная зона

Application Continuity – Защита приложения

Global Data Services – Защита от сбоя сервиса – Балансировка нагрузки

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 29

• Application Continuity • Global Data Services • Улучшения в Data Guard • Улучшения в RMAN • Flex ASM • Другие улучшения

Oracle Database 12c: новые возможности высокой надёжности


Неизвестное состояние транзакции Текущая ситуация

Пользователь выбирает товар и оплачивает его через web

Транзакция пользователя отправляется через сервер приложений в БД, где создаётся транзакция БД

Серверы приложений

Серверы БД

Пользователь




Транзакция фиксируется в БД и результат возвращается серверу приложений.

Сбой в инфраструктуре может привести к тому, что сервер приложений никогда не получит ответ от БД.



Серверы БД



Приложение находится в неопределённом состоянии. Приложение возвращает пользователю ошибку, который может заказать товар второй раз, или даже оплатит дважды.



Серверы БД


Решения для разработчиков Новое в Oracle Database 12c

Transaction Guard

Протокол и API, которые возвращают состояние

последней транзакции

Application Continuity

Попытка автоматически повторить операции в

транзакции при восстановлении после сбоя


Application Continuity Надёжное повторение транзакции

Пользователь выбирает товар и оплачивает его через web




Серверы БД



Происходит сбой инфраструктуры БД непосредственно перед фиксацией транзакции



Серверы БД



Драйвер jdbc определит сбой, найдёт исправный узел кластера и используя “Transaction Guard” выяснит была ли транзакция зафиксирована или нет

Если транзакцию нужно повторить, Application Continuity прозрачно для приложения повторит операции на исправном узле кластера и выполнит COMMIT.



Серверы БД



Пользователь получит подтверждение , что заказ товара был успешно выполнен


Серверы БД



Новые Возможности Безопасности

v


Задачи сокрытия данных

Скрыть данные в приложении для

некоторых пользователей,

запросах и отчетах

Защитить персональную информацию

Чтобы не пришлось переписывать приложения,

запросы и отчеты


Soc. Sec. # 115-69-3428

DOB 11/06/71

PIN 5623

Политики сокрытия секретных данных

Сокрытие секретных данных Маскирование данных на “лету” – в приложении

Call Center Operator

Payroll Processing


Oracle Data Redaction Сокрытие приватных данных в приложении

• Сокрытие данных “на лету” в зависимости от IP-адреса, контекста приложения (application context) и других факторов

• Полностью прозрачно для приложения, не сохраняя данные на диске

• Минимальное влияние на производительность


Поддерживаемые преобразования

Oracle Database 12с: опция In-Memory

Powering the Real-Time Enterprise

Доступна в 12.1.0.2


до сих пор приходилось выбирать между форматами

Десятилетия Разногласий, Что Лучше: Построчное или Поколоночное Хранение Данных?

Row

Для OLTP оптимален построчный формат – Оперирует несколькими строками, многими

столбцами

Column

Для Аналитики - поколоночный формат – Оперирует несколькими столбцами, многими

строками


Оба формата в памяти- для одной таблицы

Активны одновременно, консистентны на уровне транзакций

Аналитика & отчеты используют Новый поколоночный формат

OLTP использует традиционный построчный формат

Опция In-Memory: оба формата одновременно

Memory Memory

SALES SALES Row

Format Column Format


Аналитические Индексы замедляют OLTP

Таблица от 1 до 3

OLTP индексов

от 5 до 15 аналитических

индексов Большинство индексов в OLTP

базах со смешанной нагрузкой (e.g. ERP) используются только для аналитики

Хорошо работают для заранее известных запросов

Отрицательно влияют на производительность OLTP


Производительность для Аналитики и OLTP

Таблица

от 1 до 3 OLTP

индексов Поколоночное хранение в

памяти заменяет аналитические индексы и избавляет от их влияния на производительность

Как для заранее известных, так и для ad-hoc запросов

OLTP & batch работают до 300% быстрее

In-Memory Column Store

Меньше затрат на сопровождение


Oracle In-Memory легко использовать

1. Задайте размер In-Memory буфера • inmemory_size = XXX GB

2. Сконфигурируйте таблицы или их секции • alter table | partition … inmemory;

3. Впоследствии удалите аналитические

индексы


Oracle In-Memory Прозрачен для Приложений

Полная функциональность - нет ограницений на SQL Легкая имплементация - не требует миграции Полная совместимость - приложения не меняются Поддержка DBaaS - Oracle Multitenant in-memory

Uniquely Achieves All In-Memory Benefits With No Application Changes


Увеличение производительности Database Creation

Up to 100x faster

Database Upgrade

Up to 40% faster

Asynchronous Global Indexes

Instant partition maintenance

Adaptive Query Optimization

Up to 6x faster

Materialized View Refresh

Up to 5x faster

Parallel Execution

Up to 4x faster

Spatial Queries

Up to 40x faster

Network Encryption

Up to 10x faster

Large Parallel Sorts

Up to 2x faster

Parallel Union All

Up to 4x faster

String operations in PL/SQL

Up to 30x faster

Auditing

Up to 5x faster


SPARC T5 & Oracle Solaris: Более 20 рекордов Более важно, что SPARC имеет лучше TCO

• Три рекорда в базах данных – #1 single-server TPC-C – #1 single-server TPC-H 3TB & 10TB

• Восемь рекордов в приложениях – #1 Java: SPECjEnterprise2010, #1 virt SPEC jEnterprise – #1 Java 2-chip: SPECjbb2013 – #1 JD Edwards Online/Batch, #1 JD Edwards Batch-only – #1 Siebel CRM – #1 8-chip SAP-SD 2-tier – #1 Oracle FLEXCUBE UBS

• Три рекорда в аналитике – #1 Oracle TimesTen, #1 Oracle OLAP, etc

• Девять рекордов в других тестах

HCM ERP

SRM

SCM

FMS

OLTP

BI-DW

№1 в любой области

CRM

SPARC T5


Беспрецедентная производительность M6 Big Memory Machine: ТЕРАБАЙТЫ для вычислений

Лучшая платформа для вычислений в памяти 32 ТЕРАБАЙТА СИСТЕМНОЙ ПАМЯТИ

3 ТЕРАБАЙТА В

СЕКУНДУ ПРОПУСКНОЙ

СПОСОБНОСТИ СИСТЕМЫ

1.4 ТЕРАБАЙТА В

СЕКУНДУ ПРОПУСКНОЙ

СПОСОБНОСТИ ПАМЯТИ

1 ТЕРАБАЙТ В СЕКУНДУ

ПРОПУСКНОЙ СПОСОБНОСТИ

I/O

384 ядра, 3,072 потока, виртуализация: внедряйте нагрузку любого масштаба


M7 1st Software in Silicon для ускорения DB и приложений::

> Ускорение запросов к In-Memory DB > Защита целостности данных приложений > Кластеризация с низкой латентностью

M8 Future

SPARC T5, M6, M7 и дальше – Лучшее продолжает становиться еще лучше

Растущие инвестиции Oracle в разработку


M7 Ускоритель обработки запросов In-Memory DB

16

Сжатый колоночный формат

ПАМЯТЬ или L3$

Строчный формат

DB DB

До 32 одновременных результатов

ПАМЯТЬ или L3$ Упакованные и индексированные векторы

M7 встроенные ускорители

запросов БД

До 32 одновременных потоков DB

• Аппаратный ускоритель оптимизирован для Oracle Database In-Memory • Ускоритель уровня задачи работает с колоночными векторами • Работает с сжатыми и несжатыми форматами

• Функции ускорителя запросов • Конвертация форматов In-Memory • Сравнение значения по диапазону • Поиск вхождений подмножеств

• Аппаратная декомпрессия + запрос еще больше снижают время работы, количество тактов ЦП и требования к памяти для запроса


M7 увеличение производительности запросов

19

• SPARC T5, M7 & Oracle Database In-Memory • Производительность одного потока

• Аппаратная декомпрессия на ускорителях • Невыравненный упакованный формат • 1 из 32 конвейеров ускорителя

• Аппаратный ускоритель M7 обрабатывает декомпрессию и фильтрацию сразу

• Еще большее ускорение класса “WHERE” в SQL запросе

• Потоковая обработка предикатов сохраняет полосу пропускания памяти

• Бизнес-аналитика работает с полной пропускной способностью системы

T5 Baseline (1 Thread)

M7 (1 Query Pipeline)


СХД Oracle Лучшая эффективность, производительность и управление хранением данных

Триада инноваций Разработано для эры конвергенции баз данных

Oracle SPARC Производительность,

эффективность, лучшее для Oracle, Software in Silicon

Oracle Database 12c Созданные совместно для лучшей функциональности, производительности и возможностей мультиарендности

61


Дополнительная информация

• White papers • Quick Start Guide и обучение • Форум • И многое другое

http://www.oracle.com/technetwork/database

Евгения Курмачева (oracle): oracle database 12c

Business

oracle andor

oracle oracle database

c oracle cis

c multitenant

software markets

david coyle

marianne daquila

fabrizio biscotti