oracle 12c что это
Oracle 12c что это
По Вашему запросу ничего не найдено.
Рекомендуем сделать следующее:
Oracle Database 12c
Ознакомьтесь с новейшей СУБД — Oracle Database 19c
СУБД Oracle Database обеспечивала управление данными на протяжении последних 40 лет. Предприятия во всем мире в течение последних десятилетий используют ее как основу для своих самых важных производственных процессов.
Oracle Database 19c включает в себя инновационные возможности предыдущих выпусков, которые легли в основу сервисов Oracle Autonomous Database Cloud Service, такие как Multitenant (контейнерная архитектура БД), обработка нагрузок в ОЗУ, поддержка JSON и т. д., с прицелом на расширение их числа.
Что такое Oracle Autonomous Database
Oracle Autonomous Database объединяет в себе опыт десятилетий работы по автоматизации и оптимизации платформ и новые технологии (включая машинное обучение), чтобы создать полностью автономную базу данных.
Oracle Autonomous Database самостоятельно обеспечивает свою работоспособность, безопасность и восстановление. Использование инновационных технологий упрощает работу, исключает человеческие ошибки и повышает надежность, безопасность и операционную эффективность, при этом снизив расходы до минимума. Благодаря средствам самообслуживания, доступным на современной облачной платформе Oracle, специалисты по ИТ могут полностью изменить ИТ-операции, исключить времязатратную рутину по обслуживанию баз данных и сфокусироваться на задачах, приносящих прибыль.
Ресурсы для Oracle Database 12c
Oracle продолжает предоставлять новейшие локальные и облачные решения отличного качества, которые удовлетворяют требованиям к управлению базами данных компаний любого размера: от прошлых версий СУБД, включая Oracle Database 12c, до новой Oracle Database 19c.
Дополнительные сведения об Oracle Database 12c, включая сведения о возможностях и документацию, см. ниже.
Новые возможности Oracle Database 12.1.0.2
В процессе разработки новой версии Oracle Database компании Oracle было важно учесть две основные тенденции современной ИТ-индустрии. Во-первых, характерную для последних лет тенденцию изменения цены и доступных объемов оперативной памяти. Ведь стоимость оперативной памяти каждый год падает на 30 %, а типовой корпоративный сервер сегодня уже поставляется с объемом памяти 128 ГБ, причем многие серверы имеют 1 ТБ памяти. Это значит, что если научиться размещать базы данных непосредственно в оперативной памяти, то запросы к ним будут выполняться в десятки и сотни раз быстрее, что открывает возможность реализации бизнес-аналитики реального масштаба времени.
Во-вторых, важно помнить о том, что в условиях снижения затрат на ИТ разработчикам нужны новые инструменты, которые позволяют быстрее внедрять инновации и упрощать поддержку приложений. Так, например, для интеграции новых разработок с существующими корпоративными инфраструктурами разработчики уходят от монолитных приложений, сложных и тяжелых в разработке, в сторону архитектуры микросервисов, т. е. приложений, представляющих собой наборы независимо развертываемых сервисов. И для работы с новой архитектурой необходимо, чтобы база данных поддерживала новые инструменты и новые методы программирования.
Все это компания Oracle учла при разработке базы данных Oracle Database 12.1.0.2. Эта статья — обзор основных нововведений этой версии.
Oracle Database 12c
Начнем с того, что в 2013 г. компания Oracle выпустила версию Oracle Database 12c (версия 12.1.0.1), основными достоинствами которой стали снижение стоимости хранения, высокая доступность данных, простота консолидации баз данных и защита доступа к данным.
Говоря чуть подробнее, в этой версии появилась архитектура Oracle Multitenant, которая существенно облегчает консолидацию баз данных, ускоряет развертывание баз данных и позволяет управлять многими базами данных как одним целым — вместо администрирования сотен баз данных по отдельности администратор работает с одной базой данных, управляя многими базами данных, как одной. Все это сделало версию Oracle Database 12c на момент ее выпуска самой подходящей системой управления базами данных для облачных вычислений, особенно для SaaS-приложений, где особенно актуально скоростное создание новых баз данных по требованию пользователей, которое при поддержке технологии Snapshot Cloning (тонкое клонирование) занимает несколько минут.
Кроме того, в Oracle Database 12.1.0.1 появилась автоматическая оптимизация данных, сочетающая технологию «умного сжатия», которая автоматически выявляет блоки данных, к которым редко обращались («холодные» данные), и сжимает их, и технологию автоматизации многоуровневого хранения данных, которая автоматически переносит «холодные» данные на более дешевый уровень хранения.
Еще одна новая технология Oracle Database 12c, которая называется Data Guard Far Sync, обеспечивает нулевую потерю данных на больших расстояниях и позволяет держать резервные копии баз данных на большом удалении от основной базы данных. Дополнительный специальный экземпляр базы данных, не имеющий файлов данных, принимает изменения от основной базы данных в синхронном режиме и асинхронно передает эти изменения удаленным экземплярам базы данных, что обеспечивает и надежность синхронного режима, и производительность асинхронного режима.
Технология Application Continuity позволяет повторять аварийно прерванные транзакции — решая тем самым одну из главных проблем работы веб-приложений с базами данных. Технология делает отказ экземпляра базы данных прозрачным для веб-приложения и позволяет определить состояние последней транзакции. Если транзакция не прошла, она будет выполнена, а если она уже выполнена, то технология Application Continuity не позволяет выполнить ее повторно
Технология динамического маскирования данных Data Redaction прозрачная для приложений и позволяет задавать политики доступа к данным внутри базы данных. Данные остаются неизменными, но, в зависимости от прав конечного пользователя, его роли, он будет видеть только те данные, на доступ к которым он авторизован. Это позволяет приложениям прозрачно работать с базой данных, политика будет выполняться для всех приложений.
Наконец, в Oracle Database 12.1.0.1 была реализована мощная система анализа взаимосвязи строк Pattern Matching, которая позволяет анализировать тренды и находить в них статистические закономерности с помощью конструкций языка SQL. И это — не считая еще более пятисот других модификаций.
Уже в 2014 году компания Oracle выпустила Oracle Database 12.1.0.2, где эти возможности были улучшены и была добавлена новая опция Oracle In-Memory, самая важная.
Oracle Database 12.1.0.2: In-Memory
При разработке In-Memory компания Oracle стремилась создать технологию, которая сделает возможной аналитику в реальном масштабе времени для оперативного принятия бизнес-решений. Крайне важно то, что если у конкурентов Oracle для использования их вариантов опции In-Memory нужна другая база данных, другие технологии, то опция Oracle Database In-Memory встроена в базу данных, включается буквально одним параметром, полностью прозрачна для приложений и совместима со всеми возможностями базы данных. Опыт использования этой опции заказчиками показывает, что обработка транзакций ускоряется в два раза, вставка строк происходит в три-четыре раза быстрее, чем обычно, запросы для аналитики действительно выполняются в реальном масштабе времени, практически мгновенно.
Смысл технологии в том, что рядом с привычным буферным кэшем, который хранит строки таблиц и блоки индексов, создаётся новая разделяемая область для данных в оперативной памяти, в которой они хранятся в колоночном формате (Рис. 1). Таким образом, технология использует и строчный, и колоночный форматы хранения в памяти для одних и тех же данных таблиц, причем данные одновременно активны и транзакционно согласованны. Все изменения сначала производятся в традиционном буферном кэше, после чего отражаются в колоночном кэше.
При этом в колоночном кэше отражаются только таблицы, индексы не кэшируется. Кроме того, если данные читаются, но не изменяются, то в буферном кэше хранить их незачем, но если данные изменяются, то они хранятся в обоих кэшах, буферном и колоночном. Поэтому In-Memory ускоряет работу аналитики, ведь для аналитики более эффективно именно колоночное хранение данных.
Кроме того, опция In-Memory позволяет избавиться от аналитических индексов без ущерба для производительности, при этом появится гибкость: экономится дисковое пространство, можно строить запрос по любому столбцу, который размещен в In-Memory, и для быстрой работы запросов не нужно строить дополнительные индексы.
Важным элементом Oracle Database In-Memory является аппаратная поддержка. В частности, технология поддерживает набор инструкций SIMD (Single Instruction Multiple Data Values), предназначенный для обработки графики, — In-Memory использует эти инструкции, если они встроены в процессор, для сравнения сразу нескольких значений столбца с предикатом, значительно ускоряя скорость сканирования столбца — до 1 млрд строк в секунду.
Но это далеко не все. Серверы Oracle SPARC M7 и T7, выпущенные в конце 2015 г., содержат аппаратную поддержку In-Memory. Для этого в процессоры М7 и Т7 добавлены модуль векторного сканирования базы данных, модуль декомпрессии данных In-Memory и модуль аппаратной защиты памяти, который реализует проверку доступа к данным в оперативной памяти в режиме реального времени, обеспечивающую защиту данных от вредоносных вторжений и ошибок программного кода.
Для того чтобы использовать Oracle In-Memory, достаточно задать размер буфера памяти In-Memory Column Store, указать, какие таблицы, секции, столбцы будут размещаться в этой памяти, перестартовать базу данных и удалить аналитические индексы, если они больше не требуются для обеспечения производительности приложения. In-Memory легко управлять из Oracle Enterprise Manager, где есть отдельная страница In-Memory Central, которая отображает распределение памяти между объектами и позволяет конфигурировать In-Memory Column Store. В последней версии Enterprise Manager 13с имеется инструмент In-Memory Advisor, поддерживаемый для версий баз данных 11.2.0.3 и выше, который анализирует существующую нагрузку базы данных и предоставляет список объектов, загрузка которых в In-Memory Column Store даст максимальный выигрыш.
Сравнительное тестирование Oracle Database 12c In-Memory и SAP HANA на одном и том же количестве ядер Intel продемонстрировало вдвое более высокую производительность Oracle Database 12, чем SAP HANA (Рис. 2, сверху). Сравнительное тестирование масштабируемости Oracle Database 12c In-Memory и SAP HANA показало, что Oracle Database 12c In-Memory гораздо лучше масштабируется, чем SAP HANA — практически линейно (Рис. 2, снизу).
Новые возможности для разработчиков
Мы уже говорили о том, что от тяжелых монолитных приложений ИТ-отрасль переходит к веб-сервисам. Поскольку веб-сервисы все чаще обращаются друг к другу через REST интерфейс, компания Oracle предоставляет Java-приложение Oracle REST Data Services (ORDS), предоставляющее единый REST интерфейс для работы с СУБД Oracle (реляционные данные и JSON Document Store) и Oracle NoSQL Database. ORDS может использоваться как в автономном режиме, так и развёрнуто на серверах приложений WebLogic Server, Oracle Glassfish Server, Apache Tomcat. SQL Developer предоставляет удобную платформу для установки и настройки ORDS, в частности, он содержит мастер настройки, который автоматически создаёт REST-сервисы для доступа к таблицам базы данных. На Oracle Technology Network бесплатно доступна виртуальная машина VirtualBox с настроенными Big Data Lite Virtual Machine и сконфигурированными REST-сервисами. Поскольку один и тот же REST-вызов может применяться к различным базам данных, это повышает гибкость и скорость программирования, т.к. от разработчика не требуется знания SQL и специфики базы данных. В Oracle Database 12.1.0.2 встроена поддержка JSON-баз данных. REST-сервисы могут работать либо с JSON Document Store в базе данных версии 12с, либо с реляционными таблицами базы данных, которые представлены как REST Data Services, либо с NoSQL-базами данных.
Oracle Database 12с и Big Data
Oracle Big Data Appliance — это кластеры, предназначенные для работы Hadoop и NoSQL баз данных. В отличие от остальных программно-аппаратных комплексов Oracle, эти системы разработаны совместно с компанией Cloudera, одним из ведущих поставщиков дистрибутива Hadoop. Вопреки распространенному заблуждению, такие системы нужны не только компаниям из Интернет-бизнеса, потому что сегодня с потребностью обработки гигантских объемов данных сталкиваются любые компании, которые должны заниматься глубоким анализом поведения клиентов, планировать высокоточную рекламу, объединять и анализировать данные из многих источников, в том числе неструктурированных, бороться с мошенничеством и т. д.
Oracle NoSQL Database — это масштабируемая, высокопроизводительная, высокодоступная СУБД с прозрачной балансировкой нагрузки, весь объем данных в которой хранится в виде пар «ключ–значение».
Улучшения в Oracle Multitenant
Новые возможности Multitenant-баз данных версии 12.1.0.2 касаются в первую очередь клонирования PDB (pluggable db, подключаемых) баз данных. Часть табличных пространств теперь можно исключить из клонирования. Возможно клонирование только метаданных, что иногда требуется для разработки. Удаленное клонирование позволяет клонировать PDB базу данных между двумя контейнерными базами данных через database link. Наконец, появилось тонкое клонирование, основанное на встроенной в базу данных технологии Direct NFS и не зависящее от файловой системы.
Другие улучшения включают новое выражение SQL, которое позволяет делать агрегированные запросы по таблицам, которые расположены в нескольких подключаемых базах данных. Новая фраза «standbys» позволяет при создании подключаемой базы данных в явном виде задать или отменить создание резервной базы.
Oracle Database 12c
Oracle Database 12c: подключайтесь к облаку
Представляем Oracle Database 12c — первую в мире базу данных, созданную для облака
Что говорят клиенты
Подключиться к облаку с Oracle Multitenant
Консолидация баз данных — важнейший шаг на пути перехода к облачным вычислениям. Oracle Database 12c значительно ускоряет и упрощает данный процесс, обеспечивая высокую плотность консолидации ну уровне разных схем и не требуя при этом изменения имеющихся приложений.
Чтобы сделать это возможным, одна комплексная контейнерная база данных теперь может обслуживать множество «подключаемых» баз. Каждая консолидированная или «подключенная» в комплексный контейнер база данных воспринимается приложениями точно так же, как и до консолидации. Консолидация не только ускоряет переход к облачным вычислениям, но и упрощает управление, что является огромным преимуществом для организаций, которым приходится управлять сотнями и даже тысячами баз данных.
Автоматизация и оптимизация жизненного цикла информации
Управляя жизненным циклом информации, работники среднестатистической компании обычно вручную перемещают и сжимают данные в разных уровнях систем хранения, исходя главным образом из времени хранения данных.
Oracle Database 12c меняет эту ситуацию благодаря технологии автоматической оптимизации данных (Automatic Data Optimization), которая учитывает не только возраст данных, но и характер их использования или «температуру», после чего автоматически перемещает данные на соответствующие уровни системы хранения и сжимает их.
Максимальная доступность и безопасность баз данных
Упрощенная консолидация баз данных: Oracle Multitenant
Oracle Database 12c, оснащенная более 500 новых возможностей, предоставляет клиентам Oracle все необходимое для облачных вычислений, работы с большими объемами данных, обеспечения безопасности и высокой доступности.
Oracle 12c. Новые фичи приносят новые подводные камни
Разбирая новые возможности Oracle 12c, то тут, то там сталкиваюсь с подводными камнями, когда не всё работает так, как ожидалось, падает или просто не очевидно. Конечно, это стандартная ситуация когда в первом релизе новой версии много сырого… но, как известно, предупреждён — значит вооружен. Вероятно, кому-то пригодится, чтобы не повторять мои грабли.
Пишу грабли в порядке наступления на них.
PS: edited: добавил в конце баг о котором забыл написать сразу (использование в PL/SQL, SQL-конструкций в WITH которых испоьзован PL/SQL).
Знакомим PMON с локальным listener
Начнём с простого, что даже не совсем бага, а вопрос конфигурирования.
Инсталлировали в стандартной установке и настройке Oracle 12c (в моём случае — на Oracle Linux, но, думаю, не критично).
— Создаём CDB базу.
— Поключаем/создаём PDB-базы.
По-умолчанию добавленные базы не видится listener-ом. «Из коробки» PMON не подружился с listener-ом, живущим на том же сервере и автоматическая регистрация не происходит. Не трагедия, однако руками добавлять записи в listener.ora, как-то совсем не интересно в контексте новой фичи multitenant architecture.
Давайте познакомим PMON и локально живущий listener:
База зарегистрировалась, listener увидел, радость наступила. Нельзя сказать что это особенность именно 12-ки, но именно в ней появилась возможность буквально на ходу добавлять / управлять базами, и в рамках Multitenant architecture автоматическая регистрация баз в listener, как никогда актуальна. Раньше создание новой базы было намного большим «событием» и добавить пару строк в listener.ora не вызывало у меня каких-либо предубеждений.
Автозапуск PDB после перезагрузки
Перезапускаем сервер. CDB поднялась. PDB — не открыты (при подключении ошибка database shutdown or startup in progress).
Не знаю, может это и правильно, что после перезагрузки сервера администратор должен подключиться к CDB базе и сказать
Вроде как просто так базы не перезагружаются (не должны)… Но что-то мне подсказывает, что это, мягко говоря, не удобно. А DBA, которые поддерживают десятки и сотни баз одновременно — явно спасибо не скажут.
Настройки или команды которая бы убедила Оракл что автостартовать PDB-шки всё таки нужно, не обнаружилось (может плохо искал. Подскажите в коммантариях если кто нашёл).
Во всезнающем интернете этот момент уже давно не новость и наиболее распространённая рекомендация:
По личным убеждениям я не очень люблю триггеры, но в данном случае, это, похоже, самое малое из доступных зол.
Invisible columns
Особенность не Оракла, а PL/SQL developer-а (версия10.0.1.1694 — скачан с сайта PL/SQL Developer-а буквально недавно), но всё же.
Сравним поведение на невидимой колонке sqlplus (ведёт в соответсвии с документацией):
И PL/QSL Developer command window:
Не знает пока что Pl/Sql developer про новую фичу, что не удивительно. Но не все осознают что command window у PL/SQL-девелопера — это не честный sql*plus через какой-нибудь pipe, а просто псевдо-подобный интерфейс.
Думаю скоро образумятся, но в первый момент несколько удивился и задумался.
PL/SQL support in with
Как утверждает Оракл, эта фича была сделана в первую очередь для поднятия производительности (детальное рассмотрение фичи оставим за скобками, ибо оффтопик к теме поста), как и умолчим, что pragma UDF работает в этих целях не хуже, но…
«НО» заключается в баге обнаруженном Johnathan Lewis и описанном в его блоге.
Добавиви одну performance «фичу» поламали (в некоторых случаях) — другую — DETERMINISTIC.
Рассмотрим на примере кода:
Хотя, справедливости ради, проявляется это не во всех случаях:
SQL Text expansion
Ещё одно приятное нововведение — новая процедура DBMS_UTILITY.EXPAND_SQL_TEXT — я её уже описывал раньше на хабре.
Когда её испытывал, она замечательно отработала как на моих view и таблицах с VPD…, так и к примеру, на all_users… однако попытка применить её к all_objects привела к ошибке в пакете dbms_utility. Предполагаю, причина в том, что даже у пользователя с ролью DBA не обнаружилось доступа к каким-то совсем внутренним системным объектам… а может просто баг в коде.
И вот ещё пара вещей, с которыми столкнулся не сам, но тоже было интересно почитать у других:
DBMS_METADATA and session sequence
Найдено в одной из тем на sql.ru.
Похоже, DBMS_METADATA пока что не в курсе про новую фичу:
Pagination, массивы и run-time расчёт количества строк для fetch
Нашёл у человека в блоге
PS: В комментариях к источнику написали что о баге оракл уже знает и на металинке заведён bug #17404511
PPS: добавлено позже (вспомнил ещё)
PL/SQL support in SQL with in PL/SQL
Название — масло масляное. Давайте разберёмся.
Похоже, PL/SQL пока не в курсе о расширении SQL-языка, и пока не поддерживает таких SQL конструкций:
При этом нормально работает в dynamic SQL (ожиданно, но всё-же):
Oracle Database 12c: настройка производительности
Прежде чем говорить об оптимизации производительности баз данных, нужно пояснить, каким показателем эта производительность измеряется, — тем более что в памяти многих людей, связанных с базами данных, еще жив показатель «время отклика», который многие привыкли считать универсальным мерилом производительности СУБД.
Проблема с так называемым временем отклика состоит в том, что оно, увы, относительно. Для конечного пользователя, системного администратора, сетевого администратора и администратора баз данных, оно разное и зависит не только от чистого времени отклика СУБД, но и от производительности кода бизнес-логики на сервере приложений, производительности веб-интерфейса, взаимодействия компонентов сетевой инфраструктуры, работы брандмауэра, балансировщика нагрузки и т. д. Поэтому для того, чтобы адекватно выражать производительность базы данных, надо пользоваться показателем Database Time, который выражает время, потраченное СУБД на выполнение конкретного вызова (запроса), с момента его поступления в базу данных и до момента выдачи последнего фрагмента выборки результатов. Более строгое определение Database Time — общее время, проведенное пользовательскими процессами в активном выполнении или активном ожидании выполнения вызовов СУБД.
Концепцию Database Time прекрасно иллюстрирует страница Top Activity в Enterprise Manager (Рисунок 1), где мы видим количество активных сессий и, в виде разноцветного графика,- распределение потраченного времени СУБД т.е. собственно Database Time.
Инструменты настройки: вчера и сегодня
Раньше процесс настройки СУБД был сродни блужданию в потемках — администраторы пытались применять те или иные настроечные параметры, которые, по их мнению, могли повлиять на поведение оптимизатора, варьировали их значения, ориентируясь на отзывы конечных пользователей, которые далеко не всегда замечали изменения в лучшую или худшую сторону.
Современная методология настройки производительности, которая называется Find-Fix-Validate (Рисунок 2), позволяет точно диагностировать проблемы производительности с помощью инструментальных средств анализа производительности СУБД, решать их с использованием средств автоматической настройки, входящих в набор Tuning Pack, и проверять корректность принятых мер средствами тестирования, входящими в пакет Real Application Testing.
Ищем проблему
Новейшие версии СУБД Oracle, в том числе, конечно, Oracle Database 12c, буквально “облеплены датчиками” производительности и помимо своей основной работы (выполнения запросов, оптимизации, выдачи результатов, координации действий пользователей) постоянно сообщают о том, чем они занимаются, — публикуют события ожидания и временные характеристики вызовов. Поэтому всегда точно известно, сколько времени у СУБД ушло на ту или иную активность.
Надо сказать, что компания Oracle к реализации этой возможности подошла довольно элегантно и не стала изобретать собственный язык для доступа к диагностической информации, а оформила ее в виде специальных таблиц Базы Данных, доступ к которым можно получить с помощью языка SQL и графического интерфейса Enterprise Manager 12c. Таким образом, мониторинг, диагностика и поиск первопричин различных проблем для пользователей СУБД Oracle максимально упрощен.
Таблиц, которые содержат необходимую информацию, немало, уже несколько сотен, статистика в них довольно разрозненная и к тому же накопительная. Но, разумеется, нет необходимости сравнивать показатели вручную, поскольку для сравнительного анализа полученных данных разработан специальный диагностический репозиторий Automatic Workload Repository (AWR), который периодически (по умолчанию – ежечасно) снимает с таблиц диагностическую информацию — различные классы ожидания, метрики, основную статистику, статистику по SQL-запросам и так далее. Данные AWR сохраняются в БД и используются для диагностических отчетов. Технология AWR Baselines позволяет создавать эталонные интервалы времени, сопоставляя бизнес-операции, например закрытие операционного дня, отчетного периода, расчета зарплаты и т. п. с интервалами снимков AWR и периодически проводить сравнительный анализ производительности для выбранного интервала. Эта технология позволяет быстрее делать анализ вариаций нагрузки и облегчает диагностику производительности базы данных.
AWR-отчет по умолчанию сохраняется в формате HTML (Рисунок 3, слева). Есть и новый тип отчета – он называется Performance Hub, – который отображает статистику работы БД в удобной и наглядной графической форме (Рисунок 3, справа).
В Oracle Database 12.1.0.2 появилась еще одна новая, очень удобная форма AWR-отчета — Active-HTML-отчет. Он сочетает в себе возможности навигации и детализации Enterprise Manager для оффлайн-анализа, его можно сохранять и отправлять по почте, как другие активные отчеты, для его просмотра не требуется Enterprise Manager.
AWR Warehouse — центральный репозиторий для долговременного хранения AWR-данных. Он хранится в отдельной, выделенной Базе Данных — таким образом, можно увеличить период хранения снимков AWR хоть до бесконечности, чтобы анализировать хронологию, посмотреть, что было год назад, 2 года назад и т. д. AWR Warehouse интегрирован во все экраны производительности БД Enterprise Manager и позволяет получить сравнительный отчет за любой период времени.
Функциональность Active Session History (ASH) — средство мониторинга, которое появилось в Oracle Database 10g. ASH ежесекундно делает снимки состояния активных сессий и записывает их в специальную структуру памяти (см. Таблица 1). Практически это мониторинг в режиме реального времени. В Enterprise Manager 12c появился очень удобный графический интерфейс к Active Session History, который называется ASH Analytics.
Встроенный в базу данных советчик Automatic Database Diagnostic Monitor (ADDM) помогает интерпретировать диагностику и находить первопричину плохой производительности. Сам по себе AWR-отчет — это достаточно объемный документ, в котором легко запутаться. ADDM помогает интерпретировать статистику, сохраненную в Workload Repository и находить первопричину проблем. ADDM анализирует потребление Database Time, соотносит его с активностью сессий и создает отчет с конкретными рекомендациями. Важно, что ADDM не просто ставит вас в известность о проблемах производительности БД, а выявляет причины проблем и ранжирует их по степени влияния.
Наконец, в Oracle Database 12 появилась улучшенная версия Real-Time ADDM, которая автоматически запускается при превышениях пороговых значений ряда параметров, например: количества сессий, чрезмерном потреблении процессорного времени, конфликтах и прочих событиях, понижающих производительность базы данных. Новый Real-Time ADDM отличается возможностями автоматического обнаружения и анализа проблем в реальном времени, автоматической диагностикой серьезных проблем производительности.
ADDM-отчеты сохраняются в AWR-репозитории для исторического анализа. Real-Time ADDM – это, также, средство аварийного мониторинга, которое при невозможности обычного соединения с базой данных — если она «намертво зависла» — может выполнить специальное диагностическое соединение и снять диагностику прямо из памяти СУБД. Встроенный в базу данных советник поможет в диагностике проблем и определит их причину. Всегда лучше начинать анализ именно с ADDM-отчета, потому что он содержит информацию из AWR и из ASH в удобном для первичного анализа производительности виде.
Для детального анализа выполнения SQL-запросов в Enterprise Manager имеется окно Real-Time SQL Monitoring, которое позволяет следить за тем, как выполняется конкретный SQL-запрос, по какому он выполняется плану и на каком шаге плана выполнения тратится больше всего ресурсов. В Real-Time SQL Monitoring есть очень интересные показатели, такие как Actual Rows и Estimated Rows. С помощью Real-Time SQL Monitoring можно также контролировать выполнение PL/SQL-процедур.
Устраняем проблему
Практика показывает, что большинство проблем производительности Баз Данных возникают из-за SQL-запросов — либо некорректно написанных, либо, по разным причинам, неэффективно выполняющихся. Неполная статистика, новая версия оптимизатора, неправильные параметры, конфликты — есть тысяча причин, по которым SQL-запросы могут выполняться некорректно. Инструмент Oracle SQL Tuning Advisor дает рекомендации по повышению производительности проблемных SQL-запросов, используя все тот же оптимизатор SQL-запросов Cost Based Optimizer (CBO), но в специальном настроечном режиме, давая CBO больше времени на всесторонний анализ и проверку. В процессе анализа используются реальные и исторические AWR-данные и выявляются альтернативные планы выполнения запросов. Если при использовании параллельного SQL-профиля выполнение SQL-запроса ускорится в два или более раз, SQL Tuning Advisor порекомендует и его. Также, SQL Tuning Advisor проверит различные варианты рекомендаций и вы получите в Enterprise Manager отчет о том, какой SQL-запрос проанализирован и какие рекомендации по его настройке предложены.
Новая версия инструмента SQL Access Advisor, которая появилась в Oracle Database 12c, позволяет значительно сократить время анализа для больших SQL-нагрузок. SQL Access Advisor анализирует не единичные SQL-предложения, а SQL-нагрузку за определенный период времени. Теперь он работает гораздо производительнее и в десятки раз быстрее анализирует объекты БД.
И SQL Access Advisor, и SQL Tuning Advisor имеют графический интерфейс в Enterprise Manager.
Проверяем результат
Инструмент SQL Performance Analyzer (SPA), входящий в Real Application Testing обеспечивает тестирование в Oracle Database 10.2, 11g и 12c, позволяет предсказать влияние системных изменений Базы Данных на время отклика SQL, определяет результаты производительности SQL для каждого тестового выполнения SQL-нагрузки, анализирует различия в производительности и сравнивает результаты производительности конкретных SQL-запросов. При этом он оказывает минимальное влияние на производительность рабочей системы при захвате SQL-нагрузки в SQL Tuning Set (STS).
Новая возможность SQL Performance Analyzer — SPA Quick Check в Enterprise Manager позволяет быстро проверить изменения, скажем, параметров оптимизатора, влияющих на планы запросов. Например, если у вас в наборе тысяча запросов, а планы, в результате, изменятся только у десяти из них, то SPA Quick Check сначала выявит эти десять запросов и проведет сравнительное тестирование именно для них.
Отдельно стоило бы поговорить о проактивном подходе т.е. о том, как не допускать возникновения проблем с СУБД — об управлении планами запросов, но это отдельная тема, выходящая за рамки данной статьи.