Monday, August 29, 2022

Cloud and 555.1

В Оракле есть много разных патчей: 

- квартальный пачсет
- Recommended 555.1
- OJVM-патч, JDK, Perl, TZ …

Есть перечень патчей, которые Оракл ставит на свои Экзадаты в Облаке:
Oracle Exadata Database Cloud Jul 2022 Release Update (Doc ID 2817907.1)


Для сравнения патчей на СУБД cделалась табличка (жирным выделена разница):

Компонента СУБД

У меня в ноутбуке

В Облаке

Примечание

JDK

34113634

34113634

JDK BUNDLE PATCH 19.0.0.0.220719

Perl

33912872

33912872

DATABASE PERL UPDATE IN 19C TO V5.32-1 (CVE-2022-23990 - LIBEXPAT UPDATE)

 

 

 

555.1
Recommended

34320744

 

MERGE ON DATABASE RU 19.16.0.0.0 OF 29780459 34060122

34333986

 

AIM ORA-600 [KTUSCV1 CV BUF TOO BIG] - KTUSCV1

33510062

 

19C DATABASE SUDDENLY CANT START PROCESSES (BACKGROUND, JOB, SLAVE)

33195096

 

AIM ORA-600 [KDBBLKCHECKERROR] - KDB4CHK1

30691454

 

SYD E1POD DBHOME PATCHING COMPLETELY HUNG WITH KPDBHASHTABLE_FIND MULTIPLE INSTANCE HANG

29213893

 

DBMS_STATS FAILING WITH ERROR ORA-01422 WHEN GATHERING STATS FOR USER$ TABLE

 

 

 

Time Zone

34006650

34006650

DSTV38 UPDATE - TZDATA2022A - NEED OJVM FIX

34006614

34006614

RDBMS - DSTV38 UPDATE - TZDATA2022A

 

33613829
RDBMS - DSTV37 UPDATE - TZDATA2021E

 

32327201
RDBMS - DSTV36 UPDATE - TZDATA2020E

 

31335037
RDBMS - DSTV35 UPDATE - TZDATA2020A

 

30432118
MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 29997937
29997937 RDBMS - DSTV34 UPDATE - TZDATA2019B
28852325 RDBMS - DSTV33 UPDATE - TZDATA2018G

 

34086870

34086870

OJVM RELEASE UPDATE: 19.16.0.0.220719

 

34133642

34133642

Database Release Update: 19.16.0.0.220719

 

 

34122773

VIRTUAL IPS ARE NOT REACHABLE AFTER SERVICE CREATION IN DBCS SERVICES. 

 

29780459
INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
Bug 29780459 - High Waits On "latch :ges resource hash list" After Upgrading to 18c or Above

Этот баг возможен только в RAC.

High misses on "ges resource hash list" latch may be seen in database 18c and above, due to long hash chain of GES resources.

Prior to 18c, the default minimum number of hash buckets (_lm_res_hash_bucket) was 64k, but it has been changed to 32k in 18c.  This resulted in each hash bucket to hold longer hash chains, causing contention issues during GES locking operations when the system had high concurrency.

You may have encountered this problem if there is high contention on "ges resource hash list" latch on 18c or above, and explicitly setting the hash bucket size using hidden parameter _lm_res_hash_bucket=65536 or higher alleviates the problem. Note that the default value for _lm_res_hash_bucket derives to roughly GES resources/4. Set _lm_res_hash_bucket=65536 or higher depending on the number of ges_ress in v$resource_limit.

 

Разница :

- странно, что по-умолчанию Оракл не ставит патчи из Recommended 555.1

- Оракл ставит два дополнительных патча (в двух последних строках). Один из которых предназначен для виртуальных IP в DB Cloud Service. А второй просто изменяет значение одного параметра.

- Есть ещё несколько TZ-патчей. Но похоже, что в Облаке Оракл ставит один из них. Невозможно иметь сразу несколько TZ.

Does DEALLOCATE UNUSED or SHRINK SPACE will free space occupied by LOB segment?

Lets check how it works. My env is DB 19.20@Linux-x64 1) I created the table with 4 LOB columns of 4 different LOB types: BASICFILE BLOB, BA...