Я или не знал, или забыл или both..
Коллеги перенесли базу на другой сервер и просел перформанс на нескольких запросах. Посмотрел. Столбец CLOB, внутри английский текст (XML), медианная длина - 2800, ~97% строк - короче 3900 bytes. STORAGE IN ROW.

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit

Сервер 1: почти все в табличном сегменте, размер 7G, NLS_CHARACTERSET WE8MSWIN1252
Сервер 2: почти все в LOB segment, размер 18G, NLS_CHARACTERSET AL32UTF8

это ожидаемо? Пофиксить можно? Мне казалось, что документация уверяла, что al32utf8 без нужды не раздувает размеры, но нашел у Льюиса

"Remember that if the CLOB uses a multibyte character set it will be translated internally to a fixed two-byte character set" - то бишь надежды нет? Я понимаю когда мы создаем varchar2(10 CHAR) нет информации о фактических значениях и резервироваться приходится по максимуму, но как-то ожидал, что клоб не будет вываливаться в оверхед если фактическая длина данных достаточно мала..

Очепятка, пардон, о сиськах, наверное, думал. Намекаете, что при al32utf16 все волшебным образом меняется?

на всякий случай, нашел Doc ID 257772.1 который подтверждает Льюиса "However , CLOB's (and NCLOB's) of varying-width character sets (ex: UTF8, AL32UTF8) are stored in an internal fixed-width Unicode character set on disk." и в большинстве случав это будет AL16UTF16.
То есть остается 1982 ascii символа которые могут храниться вместе с таблицей. Шедро.

В дополнение: BUG 3324897 - LOBS LESS THAN 3964 BYTES ARE STORED OUT-OF-LINE WHILE LOADING USING SQLLDR -- Closed as not a bug

ElicСлишком глубоко копнул. Это общедоступно задокументировано Как по мне - слишком расплывчато для документации. Устав должен быть понятен последнему дураку :)
"compatible with UCS2" даже не вызывает дискомфорта - ну компатибл и хорошо. Тем более, что тут же везде написано двадцать раз про размер LOB до 4000 In row (как я теперь понимаю подразумевая внутренний размер) и ниже совсем плохо - Data size 3500 enable storage in row. Без всяких экивоков. Для меня термин data в данном контексте - это про полезную составляющую, и совершенно не подразумевает внутренние размеры, заголовки, списки и т.п. Может я просто не достаточно sapienti, спорить не буду. Я надеялся что может есть\появилась какая малозаметная clause при создании лоба (чтонить типа "predictable content" или возможности указать локальный character set), которая позволит таки запихнуть данные :)

ElicЯ поступаю так: Я предложил тоже самое, сказали что какие-то сложности с hibernate и проще пересоздать инстанс, так как al32utf8 никому собственно не нужен, на том и остановились, тем более что инстанс будет использоваться с вероятностью 99% одним приложением. Спасибо.

Упс, забыл главную причину - строк короче 1982 относительно немного, так что все равно почти все пойдет в клоб.

Блин, туплю.. 3964, конечно, таких много, так что причина не главная.