CLOB-хранилище Oracle 11g

Я столкнулся с очень странным поведением Oracle LOB. Ситуация: у нас есть секционированный IOT, который содержит CLOB столбца. CLOB имеет отдельное хранилище LOB с параметрами LOGGING RETENTION и DISABLE IN ROW STORAGE. CHUNK размер 8192 байта. PCTFREE устанавливается по умолчанию (ноль в dba_tables). Теперь нам нужно создать тестовый пример с загруженным определенным количеством CLOBs. мы выбрали 19,5 КБ CLOB. После загрузки этого CLOB 40 миллионов раз (используется для тестирования производительности, не имеет значения содержание) - размер в файловой системе и в dba_data_files составляет 1230 ГБ.

Вопрос:

Мы оценили размер 40mil. CLOBs размером от 19,5 КБ до ~ 780 ГБ. Как мы получили еще 450 ГБ? Я предполагаю, что это как-то связано с размером CHUNK - 19,5 КБ будут использовать 3 CHUNKs, таким образом, размер 24 КБ, что по-прежнему составляет всего 960 ГБ. LOB индекс составляет около 2 ГБ. У кого-нибудь есть идея? (извините за плохое объяснение) (P.S. работает ORACLE 11g)

Заранее спасибо!


oracle database-administration oracle11g clob lob
person Mike Nagy    schedule 02.08.2013    source источник
comment
Считайте эти дополнительные 28% налогами, уплаченными за использование Oracle. :-)   -  person Egor Skriptunoff    schedule 02.08.2013
comment
В какой-то момент в файле данных могло быть что-то еще. Каков размер согласно DBA_SEGMENTS?   -  person Jon Heller    schedule 02.08.2013
comment
Какой у вас размер блока? Если это 16 КБ, то числа будут выглядеть примерно правильно (два блока по 16 КБ в строке).   -  person Alex Poole    schedule 02.08.2013
comment
Привет, DBA_SEGMENTS показывает точно такой же размер. Размер блока 8 КБ.   -  person Mike Nagy    schedule 03.08.2013
comment
Возникает еще вопрос - посмотрел длину CLOB а она 15760 символов. База данных находится в UTF8, поэтому используется 2 байта на один символ. Таким образом, может ли быть так, что CLOB просто хранится как экстраполяция VARCHAR/CHAR? Номер подошёл бы таким образом. Я могу ошибаться здесь.   -  person Mike Nagy    schedule 05.08.2013

Ответы (1)


arrow_upward
1
arrow_downward

Ваш комментарий верен: "Данные в столбцах CLOB хранятся в формат, совместимый с UCS-2, когда набор символов базы данных является многобайтовым, например UTF8 или AL32UTF8". Хотя я бы не сказал, что это просто экстраполяция VARCHAR2. UTF8 представляет собой набор символов переменной ширины и не всегда требует 2 байта.

15760 символов — это 31520 байт, что может уместиться только в 4 блоках по 32768 байт. 32768 * 40000000/1024/1024/1024 = 1220 ГБ. Что не совсем соответствует вашему результату, но очень близко. Нам нужно увидеть более подробные цифры, чтобы найти идеальное совпадение.

person Jon Heller    schedule 05.08.2013
comment
Спасибо за ваш комментарий! Разница в 7 ГБ может быть связана с индексом PCTVERSION и LOB. Хотя есть кое-что, что меня беспокоит - наша БД - AL32UTF8, но спецификация этой кодировки говорит, что символы ASCII хранятся как 1 байт, любые европейские символы хранятся как 2 байта и т. д. (Кодировки набора символов и факторы размера хранилища). Но я предполагаю, что это не будет верно для столбцов LOB. - person Mike Nagy; 06.08.2013
comment
Да, это как-то странно. Одним из больших преимуществ UTF8 является то, что он занимает меньше места. Но это преимущество теряется, если большие текстовые значения хранятся внутри по-другому. Если пространство является огромной проблемой, вы можете рассмотреть возможность использования сжатия или BFILE. Хотя вы можете столкнуться с похожей проблемой с BFILE. - person Jon Heller; 06.08.2013