Oracle PL / SQL: производительность типа данных CLOB в PL / SQL - PullRequest
Новая
       31

Oracle PL / SQL: производительность типа данных CLOB в PL / SQL

3 голосов
/ 14 апреля 2010

Если я использую много переменных CLOB в хранимой процедуре PL / SQL для хранения большого количества длинных строк, есть ли проблемы с производительностью? Является ли длина CLOB также переменной? Есть ли какие-либо известные ограничения / недостатки для CLOB вместо использования varchar2 и long?

Ответы [ 3 ]

5 голосов
/ 15 апреля 2010

CLOBs имеют переменную длину, да. Верхний предел зависит от версии Oracle, в которой вы работаете, и размера блока вашей базы данных. Для 11G ограничение составляет «4G * значение параметра DB_BLOCK_SIZE» (из 11G PL / SQL Language Reference ). Значения VARCHAR2 ограничены 32767 байтами в PL / SQL.

У меня нет какой-либо определенной информации об относительной производительности CLOB по сравнению с VARCHAR2 в PL / SQL, и вкратце, Google также не дал ничего полезного. Однако я бы сильно подозревал, что VARCHAR2 работает лучше, чем CLOB в целом (для данных, которые могут быть сохранены в любом из них), поскольку это проще. Вы можете легко настроить тест, чтобы доказать это правильно или неправильно, написав одну и ту же простую программу один раз с VARCHAR2 и один раз с CLOB, и запуская каждую тысячу раз и сравнивая общее истекшее время. Утилита Tom Kyte Runstats очень полезна здесь и показывает другие различия между двумя подходами с точки зрения ресурсов Oracle.

Мой совет: если ваши данные превысят 32 КБ, вы должны использовать CLOB; если нет, то не используйте CLOB, используйте VARCHAR2.

NB. Если бы CLOB был лучше, чем VARCHAR2 для всех размеров символьных данных, Oracle, вероятно, исключил бы VARCHAR2, как это было с типом данных LONG - но это не так.

2 голосов
/ 30 мая 2010

CLOB значительно дороже (медленнее) и с ними сложнее работать, чем с VARCHAR2. Если вы без необходимости используете CLOB вместо VARCHAR2, вы получаете измеримое снижение производительности.

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

1) если вы храните 4000 байтов или меньше в базе данных, используйте VARCHAR2, в противном случае используйте CLOB.

2) если вы храните 32000 байт или меньше в PLSQL, используйте VARCHAR2, в противном случае используйте CLOB.

Это все о том, что вам нужно. Если ваши данные могут превысить предел VARCHAR2, используйте CLOB, в противном случае используйте VARCHAR2.

Что касается явных негативов, учтите, что при работе с типами данных LOB LOB может быть либо ВРЕМЕННЫМ (никогда не хранящимся в реальной строке таблицы), либо ПОСТОЯННЫМ (хранящимся в реальной строке таблицы). Если вы динамически создаете CLOB в PLSQL и передаете этот CLOB JAVA или другому внешнему клиенту, вы создали временный CLOB и вытолкнули его из-под контроля базы данных Oracle. Это означает, что ваш код, который принимает временный CLOB, теперь отвечает за освобождение CLOB, когда это будет сделано с ним. В вашем коде должен быть метод, встроенный в его среду, который вы можете использовать для этой цели. Если вы этого не сделаете, табличное пространство временного хранения в конечном итоге заполнится, и ваша база данных остановится (перестанет работать). Это не будет сбой, это просто не работает. Скорее всего, потребуется перезагрузка. Проблема в том, что многие инструменты разработки (например, многие версии Java) не имеют необходимого библиотечного вызова.

Удачи.

0 голосов
/ 30 августа 2010

Переменные CLOB в основном являются указателями, поэтому они не являются медленными по своей природе. Проблема заключается в доступе к содержимому CLOB. По моему опыту:

  • Опираясь на неявные преобразования Oracle в CLOB <-> VARCHAR2, как правило, медленно .
  • Работа с пакетом dbms_lob достаточно производительная. Просто сделайте это в цикле:
    1. Получить часть данных из вашего CLOB в буфер
    2. Используйте данные из вашего буфера. Может быть, преобразовать его в другой кусок данных.
    3. Возможно записать преобразованный кусок данных в целевой CLOB.
...