Extended statistics и invalid objects

После миграции на 12с c удивлением обнаружили, что у нас стали появляться столбцы с расширенной статистикой


select count(*) from dba_tab_col_statistics where column_name like 'SYS_ST%';

COUNT(*)
----------
432

Функционал в принципе известный, проблема только в том, что мы не запускали DBMS_STATS.CREATE_EXTENDED_STATS.

После внимательного исследования архивных журналов выяснилось, что столбцы создаются в моменты сбора статистика по таблице. Чтение кода пакета DBMS_STATS показало, что в новой версии безусловно вызывается процедура создания расширенной статистики по объектам. Эта процедура сканирует таблицу COL_GROUP_USAGE$ и, если там есть новые записи, создаёт по ним расширенную статистику. Для создания расширенной статистики достаточно собрать статистику на уровне таблицы.

Посмотреть объекты, по которым создаётся статистика, можно запросом:


SELECT CU.OBJ# OBJN, CU.COLS,
(CASE WHEN BITAND(CU.FLAGS, 1) = 1
THEN 'FILTER ' ELSE '' END) ||
(CASE WHEN BITAND(CU.FLAGS, 2) = 2
THEN 'JOIN ' ELSE '' END) ||
(CASE WHEN BITAND(CU.FLAGS, 4) = 4
THEN 'GROUP_BY ' ELSE '' END) USAGE,
CU.FLAGS USAGEFLG, timestamp
FROM SYS.COL_GROUP_USAGE$ CU
WHERE
(BITAND(CU.FLAGS, 8) = 0)
order by timestamp desc;

Стало интересно: а кто и как помещает записи в таблицу COL_GROUP_USAGE$ ? Опять помог logminer. Записи создаются рекурсивными транзакциями пользовательских сессий. Например, в моём исследовании для таблицы CSI_I_PARTIES была обновлена запись о столбцах PARTY_SOURCE_TABLE, RELATIONSHIP_TYPE_CODE, CONTACT_FLAG, ACTIVE_END_DATE. Сделано это было на этапе hard parse запроса:


SELECT parties.PARTY_ID PartySourceId ,
parties.RELATIONSHIP_NAME CsietParty_RelaTypeName ,

Plan hash value: 502729463

--------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 21750 (100)| |
| 1 | HASH GROUP BY | | 1 | 469 | 21750 (1)| 00:00:01 |
...
|* 20 | TABLE ACCESS FULL | CSI_I_PARTIES | 21 | 735 | 97 (0)| 00:00:01 |
...
|* 78 | INDEX RANGE SCAN | PER_PEOPLE_F_N55 | 2 | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
20 - filter(("CIP"."PARTY_SOURCE_TABLE"='PO_VENDORS' AND "CIP"."RELATIONSHIP_TYPE_CODE":SYS_B_07 AND
NVL("CIP"."ACTIVE_END_DATE",SYSDATE@!+:SYS_B_08)>SYSDATE@! AND "CIP"."CONTACT_FLAG"=:SYS_B_06))

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- this is an adaptive plan
- 5 Sql Plan Directives used for this statement

Краткое описание процесса также можно найти в документе Are Extended Statistics Collected Automatically on Oracle 12c? (Doc ID 1964223.1)

А также читаем в документе Optimizer with Oracle Database 12c:

SQL plan directives are also used by Oracle to determine if extended statistics, specifically column
groups, are missing and would resolve the cardinality misestimates. After a SQL directive is used the optimizer decides if the cardinality misestimate could be resolved with a column group. If so, it will
automatically create that column group the next time statistics are gathered on the appropriate table.

Директива плана выполнения, которая послужила источником изменений, находится запросом:


SELECT TO_CHAR(d.directive_id) dir_id,
o.subobject_name col_name, o.object_type, d.type, d.state, d.reason, d.created, d.last_used
FROM dba_sql_plan_directives d, dba_sql_plan_dir_objects o
WHERE d.directive_id=o.directive_id
AND o.object_name = 'CSI_I_PARTIES'
ORDER BY reason, created, object_type, col_name, dir_id;

...
4865599916191841433 ACTIVE_END_DATE COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE 14.05.15 22.05.15

4865599916191841433 CONTACT_FLAG COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE 14.05.15 22.05.15

4865599916191841433 PARTY_SOURCE_TABLE COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE 14.05.15 22.05.15

4865599916191841433 RELATIONSHIP_TYPE_CODE COLUMN DYNAMIC_SAMPLING USABLE SINGLE TABLE CARDINALITY MISESTIMATE 14.05.15 22.05.15
...

Здесь видим несколько записей с одинаковым значением directive_id для разных столбцов, а также что эта статистика появилась в результате работы механизма Dynamic Sampling из-за неверной оценки селективности ранее.

Какие объекты расширенной статистике для таблицы уже были созданы, можно посмотреть через представление dba_stat_extensions. В нашем случае запрос показал, что такой статистики ещё нет (об этом же косвенно говорит статус ‘USABLE’ и директивы):

Во всём этом великолепном механизме есть только одна ложка дёгтя: Bug 19450314 : INVALIDATIONS IN 12C

Утром на второй день после миграции я с некоторым удивлением обнаружил в нашей системе порядка 30 000 инвалидных объектов. Пришлось всё останавливать, компилировать их скриптом utlrp, и только потом подавать пользовательскую нагрузку снова.

Баг весьма неприятный, в простых случаях не воспроизводится, однако под нагрузкой проявляет себя так: добавление столбцов для расширенной статистики в таблицу может приводить к тому, что зависимые объекты инвалидируются. Как правило затрагивает это те объекты, с которыми больше всего работают. Далее в системе появляется множествеенные library cache pin/lock, и приходится принимать экстренные меры.

С нетерпением ждём, когда же баг исправят, а пока что живём со значением параметра _optimizer_dsdir_usage_control=0 и не создаём новую расширенную статистику …

P.S. Вышел патч на Bug 19450314 “UNNECESSRAY INVALIDATIONS IN 12C” – у нас уже установлен в production и пока что проблем с инвалидацией не наблюдаем.

Extended statistics и invalid objects

Баги 12c

Ниже список багов, с которыми пришлось столкнуться при работе с Clusterware + Database 12c. Некоторые весьма забавны, не могу не поделиться 🙂

Clusterware

Вообще багов clusterware множество, всё-таки, код был местами весьма сильно переписан. Что-то действительно стало работать лучше. Но вот на что удалось наткнуться

1. При выполнении скрипта root.sh (создание или upgrade кластера) падает с ошибкой


PRIF-15: INVALID FORMAT FOR SUBNET

Воспроизводится проблема очень просто. Предположим, мы хотим добавить подсеть 5.255.219.0. Это честные “белые” IPv4 адреса. Выполняем команду:


/opt/oracle/product/grid/12.1.0.2/bin/oifcfg setif -global eth0/5.255.219.0:public -force
PRIF-15: invalid format for subnet

Поведение описано в документе root.sh fails with CLSRSC-287 due to: PRIF-15: invalid format for subnet (Doc ID 1933472.1). Проблема состоит в том, что в имени подсети содержится цифра 255.
workaround: не использовать подсети с 255 в имени

Лечится Patch 19777496: ROOT.SH FAILED: PRIF-15: INVALID FORMAT FOR SUBNET

2. При выполнении root.sh падает на попытке старте ctssd


CRS-2676: Start of 'ora.diskmon' on 'appl2' succeeded
CRS-2676: Start of 'ora.cssd' on 'appl2' succeeded
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'appl2'
CRS-2672: Attempting to start 'ora.ctssd' on 'appl2'
CRS-2883: Resource 'ora.ctssd' failed during Clusterware stack start.
CRS-4406: Oracle High Availability Services synchronous start failed.
CRS-4000: Command Start failed, or completed with errors.
2015/02/03 19:56:34 CLSRSC-117: Failed to start Oracle Clusterware stack

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

На эту тему находятся
Bug 19317963 : FAILED TO START ORA.CTSSD WHEN RUNNNING ROOT.SH ON 12.1.0.2
Bug 19453778 : CTSSD FAILED TO START WHILE RUNNING ROOTUPGRADE.SH

workaround: использовать ноды с одинаковой длиной имени

После небольшого исследования выяснилось, что патчи включены в PSU2, лечится только его установкой.

Database

По основным багам уже прошёлся Игорь Усольцев, я лишь немного дополню список

3. ORA-01792: maximum number of columns in a table or view is 1000

После апгрейда во вполне безобидных запросах вылазит ошибка ORA-01792: maximum number of columns in a table or view is 1000

Баг описан в Select Statement Throws ORA-01792 Error (Doc ID 1951689.1), там же fix_control для его лечения

4. ORA-04036: Объем памяти PGA, используемой экземпляром, превышает PGA_AGGREGATE_LIMIT

На самом деле это не баг, это новая фича, теперь можно контролировать максимальный объем используемого PGA.

Поведение описано в Limiting process size with database parameter PGA_AGGREGATE_LIMIT (Doc ID 1520324.1)

На самом деле фич и фенечек теперь огромное количество, на этой мажорной заметку желаю закончить, иначе список можно продолжать ещё очень долго.

Баги 12c

Настройка OeBS с использованием SQL Profile

Некоторое время назад сообщили о возникшей в OeBS проблеме: один из concurrent процессов завершился с ошибкой, в логах

ERROR:ORA-01555: слишком старый снимок: сегмент отката номер 147 по имени “_SYSSMU147_1401594481$” слишком мал

Процесс лечения оказался нетривиален, решил поделиться его деталями

Continue reading “Настройка OeBS с использованием SQL Profile”

Настройка OeBS с использованием SQL Profile

5-й КИТ

Закончился 5-й по счёту курс информационных технологий (КИТ)

Я там читал несколько лекций по основам БД, ничего сильно специфичного, несколько монологов о технологиях БД:

1. Базы данных: какие они бывают, что такое реляционная алгебра, SQL, нормальная форма и зачем нужна система управления БД

2. Базы данных: атомарность транзакций, способы ведения журналов транзакций и принципы построения транзакционных систем высокой доступности (на примере СУБД Oracle)

Кажется, что курс вышел достаточно интересным 🙂

Полный список лекций можно найти на странице проекта

5-й КИТ

Hadoop на распутье?

5 августа Майкл Стоунбреейкеер в своём блоге опубликовал интересную заметку Hadoop at a Crossroads?  

Ниже мой (местами вольный :)) перевод этой заметки. Кажется, что её нужно читать “на одном дыхании”, не отвлекаясь на необходимость переводить на родной язык.


 

С моего последнего в этом блоге постинга в 2012 году совместно с Джереми Кепнером (Jeremy Kepner) утекло уже много воды, и я считаю своим долгом указать на некоторые факты и мнения, а также сообщить о паре анонсов. В заключение я сделаю предположение о том, куда же “стек Hadoop” движется.

Первый анонс – выпуск Cloudera релиза новой DBMS Impala [2], работающей на HDFS. Упрощенно говоря, Impala спроектирована ровно также, как и все остальные параллельные shared-nothing SQL СУБД, работающие на рынке витрин данных. Особенно стоит отметить, что в релизе отказались от слоя MapReduce, и заслуженно. Как некоторые из нас доказывают уже на протяжении нескольких лет, MapReduce непрактичен для использования в качестве основного интерфейса внутри SQL (или Hive) СУБД [3,4]. Impala была спроектирована весьма здравомыслящими разработчиками СУБД, знакомыми с этими парадигмами. В действительности, схожая с Impala активность наблюдалась и среди разработчиков HortonWorks и FaceBook. Это, конечно же, поставило поставщиков Hadoop перед диллемой. Исторически Hadoop-ом называют open-source версию MapReduce, написанную Yahoo. Однако Impala выкинула этот слой из стека. Как же в этом случае можно быть поставщиком Hadoop, если сам Hadoop в его первоначальном смысле больше не является частью основного стека?

Ответ прост: переопределить термин “Hadoop”, и это ровно то, что было сделано поставщиками. Слово “Hadoop” теперь используется для обозначения всего стека. Иными словами, в основе HDFS, поверх которой запускается Impala, MapReduce и другие системы. Поверх этих систем работает высокоуровневое ПО типа Mahout. Слово “Hadoop” используется для обозначения всего набора.

Второй свежий анонс пришёл от Google, который объявил, что MapReduce – вчерашние новости и они идут дальше, строя свои программные решения поверх лучших систем, таких как Dremmel, Big Table, и F1/Spanner [5]. Вообще, Google должно быть тихонько посмеивается сейчас. Они изобрели MapReduce с целью поддержки процесса обхода web для своего поискового движка в 2004. Через несколько лет они заменили в своих приложения MapReduce на BigTable, потому что хотели интерактивную систему хранения, в то время как MapReduce обеспечивает только пакетную обработку. Так что основное приложение, использующее MapReduce, уже давно сменило платформу на лучшую. И теперь Google сообщает, что они не видят в будущем необходимости в MapReduce.

Весьма иронично, что Hadoop продолжает получать поддержку основной части сообщества уже около пяти лет после того, как Google перешёл на использование лучших технологий. Таким образом, весь остальной мир следует за Google в мир Hadoop с отставанием почти в десятилетие. А Google уже давно отказался от MapReduce. Интересно, сколько времени всему остальному миру понадобиться, чтобы двинуться в том же направлении, что и Google сейчас.

Обратите внимание, что поставщики Hadoop сейчас движутся встречным курсом с поставщиками витрин данных. Они сейчас реализуют (или уже реализовали) ту же самую архитектуру, что практикуется в мире витрин данных. Как только они получат несколько лет на кристаллизацию своих реализаций, они скорее всего смогут предложить конкурентную производительность. Между тем большинство поставщиков витрин данных поддерживают HDFS, а многие представляют функционал для работы с полу-структурированными данными. Так что рынки витрин данных и Hadoop вскорости сольются. Возможно, в результате шумного противостояния выиграет лучшая система.

А сейчас я хотел бы вернуться к HDFS, который остался единственным общим блоком в стеке Hadoop. Очевидно, что HDFS – файловая система, способная хранить байты данных, свойство, ожидаемое от любой вычислительной платформы. Есть два вИденья, куда HDFS могло бы двинуться в будущем. Если принять точку зрения будущего как файловой системы, то пользователям нужна обычная распределенная файловая система и HDFS – отличная разумная альтернатива.

С другой стороны, с точки зрения параллельной SQL/Hive СУБД HDFS “хуже смерти”. СУБД ВСЕГДА хочет отправлять запрос (несколько килобайт) к данным (много гигабайт) и никогда наоборот. Так что попытка спрятать месторасположение данных от СУБД – это смерть, и СУБД пойдёт на многое, только бы избавиться от этой особенности. Все параллельные СУБД, неважно, от поставщиков витрин данных или Hadoop, обязательно отключат прозрачность (в смысле transparency, когда приложениее не знает, где физически хранятся данныее) расположения данных, заставляя HDFS вести себя как набор файловых систем Linux, одна на узел. Точно также, как ни одна СУБД не нуждается в репликах файловой системы. См. в [6] обширную дискуссию на эту тему. Вкратце, соображения балансировки нагрузки, оптимизации запросов и транзакционности играют в пользу поддержки систем репликации на уровне СУБД.

Если окажется, что на рынке в течение длительного времени будет преобладать точка зрения СУБД, то HDFS атрофируется, поскольку поставщики СУБД откажутся от её специфичных свойств. В этом мире на каждом узле будет своя локальная файловая система, параллельная СУБД, поддерживающая высокоуровневый язык запросов, и различные утилиты на его основе или расширения, определенные с использованием пользовательских функций. В таком сценарии Hadoop трансформируется в обычную shared-nothing СУБД с набором поставщиков СУБД, конкурирующих за ваш бюджет.

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

В обоих сценариях единственной общей частью ПО является файловая система, и поставщики Hadoop будут продавать основанные на файловой системе утилиты, либо только для СУБД или остальных продуктов (или, возможно, их обоих). Фактически они присоединятся к когорте поставщиков системного ПО, продающих ПО или сервисы. Возможно победит лучший продукт!

 

Ссылки:

[1] http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext

[2] http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html

[3] http://dl.acm.org/citation.cfm?id=1629197

[4] Pavlo, A. et. al., “A Comparison of Approaches to Large-Scale Data Analysis,” SIGMOD 2009.

[5] http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/

[6] Stonebraker, M., et. al., “Enterprise Data Applications and the Cloud: A Difficult Road Ahead,” Proc IEEE IC2E, Boston, Ma., March 2014

Hadoop на распутье?

Софтверный mdraid

Обычно, когда говорят о стратегии размещения блоков в массиве RAID, имеют в виду защиту от выхода из строя части дисков. На производительность же влияет уровень RAID либо размер stripe, либо параметры памяти контроллера. Это некий шаблон, сформированный миром больших дисковых систем. Тем удивительней было узнать, что в случае mdraid это не так и не меняя уровень RAID, изменяя лишь стратегию распределения блоков, можно существенно увеличить производительность.

 

Опыт работы с mdraid в кластере Vertica

Софтверный mdraid

Кластеризация Oracle Identity Management

О кластеризации IDM было уже сказано не раз, подборку материалов по этой теме можно найти в конце статьи. Я же хочу далее обратить внимание на практическую сторону вопроса. Да, во всех встречавшихся мне документах достаточно подробно и широко рассмотрены многочисленные вопросы обеспечения HA для продуктов Fusion Middleware, в общем, и Identity management, в частности. Однако же им не хватает деталей конкретной реализации: как заставить все перечисленные отдельные HA компоненты работать совместно?

Ниже описано, как все это работает в нашей картине мира на кластере из нескольких серверов в разных ДЦ.

Continue reading “Кластеризация Oracle Identity Management”

Кластеризация Oracle Identity Management