Wednesday, December 14, 2022

MAX_STRING_SIZE=EXTENDED, ORA-00910, ORA-14694

Появилась задача переключить одну БД в MAX_STRING_SIZE=EXTENDED.
Много лет назад уже приходилось выполнять эту операцию на 12.1, она была проблемной, скрипт utl32k.sql не доходил до конца, заводили SR и долго разбирались в проблеме.
Много времени утекло с тех пор и сейчас уже 19.12.

Что такое MSS и как оно работает: в БД имеется параметр MAX_STRING_SIZE который может иметь два значения STANDARD или EXTENDED.

В стандартной конфигурации (MSS=STANDARD) максимальная длина строки VARCHAR2 = 4000 байт. Возьмёшь на один байт больше - и получишь ошибку:

SQL> create table MSS (col_MSS varchar2(4001));

Error starting at line : 1 in command -
create table MSS (col_MSS varchar2(4001))
Error report -
ORA-00910: specified length too long for its datatype
00910. 00000 -  "specified length too long for its datatype"
*Cause:    for datatypes CHAR and RAW, the length specified was > 2000;
           otherwise, the length specified was > 4000.
*Action:   use a shorter length or switch to a datatype permitting a
           longer length such as a VARCHAR2, LONG CHAR, or LONG RAW


При MSS=EXTENDED длина VARCHAR2 может достигать 32767 байт.
Для демонстрации возможностей MSS=EXTENDED сделаем простой тест: создаём таблицу с столбцом VARCHAR2 длиной более 4000 байт и вставим в эту таблицу стрки длиной 4000 байт.
Вначале выполним пример на тестовой БД со стандартными настройками MSS=STANDARD (она у меня single instance версии 19.17 + MRP1, nonCDB ) :

drop table mss;
show parameter MAX_STRING_SIZE
create table MSS (col_MSS varchar2(4000));
insert into MSS values (rpad('x',4000));
insert into MSS values (rpad('x',4001));
insert into MSS values (rpad('x',32767));
select rownum, length(col_MSS) from MSS;

SQL> show parameter MAX_STRING_SIZE
NAME            TYPE   VALUE    
--------------- ------ --------
max_string_size string STANDARD

SQL> create table MSS (col_MSS varchar2(4000));
Table created.

SQL> insert into MSS values (rpad('x',4000));
SQL> insert into MSS values (rpad('x',4001));
SQL> insert into MSS values (rpad('x',32767));

   ROWNUM    LENGTH(COL_MSS)
_________ __________________
        1               4000
        2               4000
        3               4000


Интересный получается результат! Ошибок нет, но длина строки обрезается по 4000 байт.
При INSERT можно потерять данные и не узнать об этом!

И еще одно подтверждение:
SQL> select length (rpad('x',32767)) from dual;

   LENGTH(RPAD('X',32767))
__________________________
                      4000


---------------------------------------------
Тестовая миграция

Миграция на MSS=EXTENDED заключается в выполнении двух шагов:
1) установить в файле параметров MSS=EXTENDED
2) запустить БД startup upgrade и выполнить скрипт utl32k.sql

И применительно к промышленной миграции возникают ряд вопросов:
- вопрос про Fallback-стратегию: как после установки MAX_STRING_SIZE=EXTENDED вернуть БД в MAX_STRING_SIZE=STANDARD, если в ходе миграции что-то пойдёт не по плану?
- как устанавливать MSS=EXTENDED на стендбай? Надо ли устанавливать этот параметр до того, как мы установили его на основной БД или после? И будет ли стендбай с MSS=STANDARD накатывать редо от БД с MSS=EXTENDED ?

Попробуем выполнить MSS=EXTENDED на тестовой БД ( версия 19.17 + MRP1, nonCDB, single instance) и затем откатить БД к точке восстановления.

Есть нота
2383964.1 After changing parameter Max_string_size=extended can I revert back to Standard
которая категорично утверждает, что возврат к MSS=STANDARD - только путём восстановления из бэкапа:

"This is not supported per the Oracle documentation." 
"The only way to revert is to restore the database from backup ..."


Но эта нота ничего не пишет про FLASHBACK TO RESTORE POINT. Можно ли использовать  Flashback DB для возврата к MSS=STANDARD? Т.е. после миграции на MAX_STRING_SIZE=EXTENDED откатить БД на заранее созданную точку восстановления и вернуть  MAX_STRING_SIZE=STANDARD ?

-- Попробуем проверить
-- Создаём точку восстановления BEFORE_MSS
SQL> create restore point BEFORE_MSS guarantee flashback database;
Restore point created.


RMAN> list restore point all;

SCN              RSP Time            Type       Time                Name
---------------- ------------------- ---------- ------------------- ----
2359859                              GUARANTEED 2022.12.11 15:55:35 BEFORE_MSS



-- Выполняем миграцию
-- Поскольку данная миграция затрагивает код приложений, то предварительно необходимо собрать информацию об инвалидных объектах.
-- А после миграции посмотреть - не появилось дополнительно что-то инвалидное ?

SQL> conn / as sysdba
Connected.
SQL> ALTER SYSTEM SET max_string_size=EXTENDED scope=spfile;
System SET altered.

SQL> shutdown immediate
SQL> startup upgrade
SQL> @?/rdbms/admin/utl32k
--
во время первого прогона случайно нажал Ctrl+C, скрипт свалился и был запущен повторно, никаких проблем поле этого не было, похоже, что можно запускать этот скрипт несколько раз

-- Поскольку в процессе миграции на 32К некоторые объекты могут стать инвалидными, то откомпилируем весь софт в БД еще раз
SQL> @?/rdbms/admin/utlrp

SQL> shutdown immediate
SQL> startup

-- Теперь наша БД с MSS=EXTENDED
-- С помощью нашего тестового примера проверим как работает 32K

SQL> show parameter max_string
NAME            TYPE   VALUE    
--------------- ------ --------
max_string_size string EXTENDED

drop table mss;
create table MSS (col_MSS varchar2(32767));
insert into MSS values (rpad('x',4000));
insert into MSS values (rpad('x',4001));
insert into MSS values (rpad('x',32767));
select rownum, length(col_MSS) from MSS;
select length (rpad('x',32767)) from dual;

SQL> select rownum, length(col_MSS) from MSS;

   ROWNUM    LENGTH(COL_MSS)
_________ __________________
        1               4000
        2               4001
        3              32767

SQL> select length (rpad('x',32767)) from dual;

   LENGTH(RPAD('X',32767))
__________________________
                     32767
-- Вполне ожидаемый результат: VARCHAR2 длиной до 32767 байт.


-- Переходим к FLASHBACK TO RESTORE POINT:

SQL> alter system set max_string_size='STANDARD' scope=spfile;
SQL> shutdown immediate
$ rman target /
RMAN> startup mount
RMAN> flashback database to restore point BEFORE_MSS;

Starting flashback at 11-DEC-22
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=137 device type=DISK

starting media recovery
media recovery complete, elapsed time: 00:00:07

Finished flashback at 11-DEC-22

RMAN> alter database open resetlogs;


SQL> show parameter max_string
NAME            TYPE   VALUE    
--------------- ------ --------
max_string_size string STANDARD



-- Создадим таблицу и посмотрим что получится:
drop table mss;
create table MSS (col_MSS varchar2(32767));
insert into MSS values (rpad('x',4000));
insert into MSS values (rpad('x',4001));
insert into MSS values (rpad('x',32767));
select rownum, length(col_MSS) from MSS;
select length (rpad('x',32767)) from dual;

SQL> drop table mss;

Table MSS dropped.


-- Возникает ожидаемая ошибка:
SQL> create table MSS (col_MSS varchar2(32767));

Error starting at line : 1 in command -
create table MSS (col_MSS varchar2(32767))
Error report -
ORA-00910: specified length too long for its datatype
00910. 00000 -  "specified length too long for its datatype"
*Cause:    for datatypes CHAR and RAW, the length specified was > 2000;
           otherwise, the length specified was > 4000.
*Action:   use a shorter length or switch to a datatype permitting a
           longer length such as a VARCHAR2, LONG CHAR, or LONG RAW

SQL> create table MSS (col_MSS varchar2(4000));

Table MSS created.

SQL> insert into MSS values (rpad('x',4000));

1 row inserted.

SQL> insert into MSS values (rpad('x',4001));

1 row inserted.

SQL> insert into MSS values (rpad('x',32767));

1 row inserted.

SQL> commit;

Commit complete.

SQL> select rownum, length(col_MSS) from MSS;

   ROWNUM    LENGTH(COL_MSS)
_________ __________________
        1               4000
        2               4000
        3               4000

SQL> select length (rpad('x',32767)) from dual;

   LENGTH(RPAD('X',32767))
__________________________
                      4000



-- Поведение полностью повторяет то, что было до миграции.
-- Подтверждаем, что откат на точку восстановления возможен.

-- Не забудьте удалить точку восстановления:
SQL> drop restore point BEFORE_MSS ;

Sunday, December 4, 2022

Block Change Tracking

Начиная с 19.16 BCT-файл будет кешироваться в Flash Cache.

Начиная с 19.17 CTWR назначает операциям В/В высокий приоритет при высокой загрузке В/В.

Wednesday, November 16, 2022

Новости HW

Компания Seagate обновила семейство HDD с двумя независимыми блоками магнитных головок для пользователей, которым необходима повышенная производительность. Диски доступны в модификациях с интерфейсом SATA-3 и SAS-3, при этом SAS-модели выглядят для хоста как два независимых логических HDD.
https://servernews.ru/1077354
В два раза больше IOPS, надо полагать.
Не только в процессорах бывает HyperThreading.
Ну а потом будут диски с тремя блоками, с четырьмя ...


Компания AMD выпустила новое 4-е поколение процессоров AMD EPYC: 96 ядер,  12 каналов памяти DDR5, PCIe 5.0 и поддержка памяти CXL.
Оракл уже предлагает в своём Облаке серверы OCI E5 с этими процессорами.
https://www.amd.com/en/press-releases/2022-11-10-offering-unmatched-performance-leadership-energy-efficiency-and-next

Ждём Экзадату на этих ЦПУ.
Наверное будет только в Облаке Оракл.


Wednesday, October 19, 2022

Новое в политике выпуска патчей:отказ от RUR, рождение MRP

 Два изменения, касающиеся выпуска обновлений.
1) Оракл прекращает выпускать RUR (Release Update Revision)
2) Оракл начинает выпускать MRP (Monthly Recommended Patches)


1) Sunsetting of 19c RURs and FAQ (Doc ID 2898381.1)

В этом документе описывается прекращение выпуска обновлений RUR:
No additional RURs will be delivered on any platform after the delivery of Oracle Database 19c RUR 19.16.2 in January, 2023. All customers should instead simply use the latest, recommended 19c Release Update, such as 19.17.0, 19.18.0, or 19.19.0, etc.

2) Introducing Monthly Recommended Patches (MRPs) and FAQ (Doc ID 2898740.1)

To provide customers more frequent access to recommended and well-tested collections of patches, Oracle is pleased to introduce Monthly Recommended Patches (MRPs).

Выпуск квартальных патчей остаётся неизменным, т.е. каждый квартал будет выпускаться квартальный патч.

Дополнительно к этому каждый месяц будет выходить сборка = квартальный патч + набор критических патчей, а именно:

MRPs will include the
- fixes documented in "Oracle Database Important Recommended Patches" (Note 555.1)
- critical fixes from the 19c Known issues MOS Note
- plus the prior MRPs for the RU (MRP будут кумулятивными, т.е. каждый последующий будет включать в себя патчи всех предыдущих MRP)

MRP будут выпускаться только для платформы Linux-x64.

Для каждого RU будут выпускаться 6 MRP.
MRP1 для 19.17 стартует в ноябре 2022.

Это сделано для того, чтобы "Customers get access to recommended, well-tested, one-off patches without having to request a patch bundle after the release of an RU".

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...