Евгения Курмачева (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троенные СУБД RDB
CODASYL
Express
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

Автоматическая оптимизация данных
Добавление политик сжатия и перемещения к таблицам
Oldest Data
Most Recent Data
Сжать секции с помощью Advanced Compression,
Если они не изменялись более 30 дней
Выполнить сжатие Hybrid Columnar Compression секций, если они не изменялись более 180 дней

Температурная карта отслеживает активность сегментов и блоков
Oldest Data
Most Recent Data

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

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

Oldest Data
Most Recent Data

Уменьшается объем хранения, чтение выполняется быстрее
Oldest Data
Most Recent Data

Автоматическое перемещение данных для снижения стоимости хранения
Oldest Data
Most Recent Data
Если 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
•
•
Global Data Services
•
Улучшения в Data Guard
•
Улучшения в RMAN
•
Flex ASM
•
Другие улучшения
Oracle Database 12c: новые возможности высокой надёжности

Неизвестное состояние транзакции
Текущая ситуация
Пользователь выбирает товар и оплачивает его через web
Транзакция пользователя отправляется через сервер приложений в БД,
где создаётся транзакция БД
Серверы приложений
Серверы БД
Пользователь

Транзакция пользователя отправляется через сервер приложений в БД, где создаётся транзакция БД
Транзакция фиксируется в БД и результат возвращается серверу приложений.
Сбой в инфраструктуре может привести к тому, что сервер приложений никогда не получит ответ от БД.
Серверы
приложений
Серверы БД

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

Решения для разработчиков
Новое в Oracle Database 12c
Transaction Guard
Протокол и API,
которые возвращают состояние последней транзакции
Попытка автоматически повторить операции в транзакции при восстановлении после сбоя

Надёжное повторение транзакции
Пользователь выбирает товар и оплачивает его через 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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Евгения Курмачева (Oracle): Oracle Database 12c

Similar to Евгения Курмачева (Oracle): Oracle Database 12c (20)

More from Expolink

More from Expolink (20)

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