Patches for 12c Oracle Database in EBS environment

After migration to Oracle Database 12c and OeBS 12.2 we’ve faced a strange problem with searching database patches.

I’m used to a simple paradigm: we have our own set of patches. It could be a huge list but if we meet a problem it happens quite rarely and I had a plenty of time to investigate it.

But in 12.2 everything has changed. Now we have 2 set of patches. First is the old set that comes from our peculiarities – customizations, hardware and workload. Second is the new set which is recommended by OeBS development team (see Oracle E-Business Suite Release 12.2: Consolidated List of Patches and Technology Bug Fixes (Doc ID 1594274.1) ).

The problem is in an overall number of patches:

1. Our own list of bugs consists of about 10 items (among them are mainly patches for wrong query results (like 18650065: WRONG RESULTS ON QUERY WITH SUBQUERY USING OR EXISTS ) and RAC-specific issues (like 19124336 – ORA-600 [kjblcwscn:!wr]can occur when handling a stale but valid write completion) ).
2. List of OeBS patches (that should be installed too) from Doc ID 1594274.1 consists of 34 bugs and 22 patches (for 12.1.0.2).
3. In addition to that 4 times a year is released Patch Set Update. It’s highly advisable install it (and in our case I can’t imagine how we would maintain our system without PSU).

All would be nothing, but some of the patches conflicts each other or PSU (and some conflicts both). So in order to meet all the requirements I should install PSU, all patches that haven’t been included in PSU, overlay patches that conflict PSU, merge patches that conflict each other and overlay merge patches that conflicts all of them.

I’ve made it once – for April 2015 PSU – checked each bug, find all patches and opened a couple of SR for missing ones.

After half a year I returned to the task and was horrified – number of bugs increased twice! I commenced to work with a list of bugs but this time was fortunate enough – in a one SR met engineer who gave me the proper list of links. Here it is:

1. There is no need to search recommended OeBS patches for each PSU by yourself. Just read Database Patch Set Update Overlay Patches Required for Use with PSUs and Oracle E-Business Suite ( Doc ID 1147107.1 ) – in my case all patches was in ‘Table 1 Release 12.1.0.2 PSUs and Patch Lists for EBS r12.2 customers not using the In-Memory option’

2. There is no need to check list of patches on conflicts by hand. My Oracle Support has Conflict Checker Tool that could be used not only for analyzing but also for requesting patches. See How to Use the My Oracle Support Conflict Checker Tool for Patches Installed with OPatch [Video] ( Doc ID 1091294.1 )

So I installed October 2015 PSU, get my oracle inventory, list of patches from set 1. and Doc ID 1147107.1, perform “Analyze for Conflicts” steps, click “Request Patch” and made special query for missing merge overlay patch. I didn’t expect, but my merge patch was ready next day! And it’s all, I just downloaded patches from Download table and installed it in my system.

Patches for 12c Oracle Database in EBS environment

Upgrade Identity Management

It was the spring when we upgraded our IDM system for EBS authentication. Now a few months have passed and all seems to have been working fine so I’d like to share a brief notes about issues we met and a final configuration.

We have a classical for identity management 3-Nodes configuration and now we’re running on:
OEL6 with UEK R3 kernel
Oracle Database 12.1.0.2 + PSU3
Java 1.7_75
Weblogic 10.3.6.11
OAM 11.1.2.2 + PSU5
Webgate 11.1.2.2
OID/OVD 11.1.1.7 + PSU3
AccessGate 1.2.3.4

The most difficult (for me) question was where could I find documentation for upgrading? Here what I collected:
Database upgrade guide
Oracle® Fusion Middleware Upgrade Guide for Oracle Identity and Access Management 11g Release 2 (11.1.2.2.0)
Patch Management of an Oracle Identity Management Deployment
OAM Bundle Patch Release History [ID 736372.1]
How to Upgrade OID/ OVD 11.1.1.5 To 11.1.1.7 (IDM PatchSet 6) (Doc ID 1962045.1)
Considerations When Applying Patch Sets to FMW 11g Release 1 Identity Management (Doc ID 1298815.1)
Master Note on Fusion Middleware Proactive Patching – Patch Set Updates (PSUs) and Bundle Patches (BPs) (Doc ID 1494151.1)
Oracle Internet Directory (OID) Version 11.1.1.7 Bundle Patches For Non-Fusion Applications Customers (Doc ID 1614114.1)
Integrating Oracle E-Business Suite Release 12 with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate [ID 1484024.1]

I cannot say that there weren’t any problems at all but the vast majority of SR I opened were on OAM. They were mostly related to misconfigurations in oam-config.xml file. Either because of upgrade or because of old errors. All this is our local particularity and not so interesting.

All works great in a test environment but the first day after upgrade production system was quite strained:

1. It appears that index IDX_JPS_PARENTDN in schema OID_OPSS was replaced by composite index. The old non-unique index was extended by unique key entity_id. This led to that the index grew from 300 to 600 MB. Explain plans also changed. All still works fine for a single client session. But when clients commenced connect at the same time execution time of search queries increased significantly (because of heavy disk IO) and method “ldapbind” was timing out. I recreated the old index and the majority of problems has gone.

2. Some queries still used the new one (composite) index. After some investigation we noticed too high cost of their explain plans. It was new 12c query re-optimization functionality named “SQL Plan Directives”. Igor Usoltsev wrote about it. We just disabled those SQL Directives.

3. Http GET response significantly increased. For some type of browsers (IE11 for example) it became more than 8K. We terminated SSL/TLS at a proxy side. And proxy (we use nginx) drops large packets by default. Large packets could get from both client and server sites. For nginx we increased buffer sizes (there are several settings, one for client side and other for server).

P.S. It would be useful also read this community thread. We haven’t faced with Coherence issues yet, our 3.7.1.1 versions works fine but folks reports that 3.7.1.19 is more stable.

Upgrade Identity Management

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