Подозреваю, вы путаете SQL и PL/SQL datatypes. Они, вообще говоря, разные.

Elic, я-то в теме.

Но при первичном знакомстве с Oracle я споткнулся именно на этом, поэтому поделился опытом, поскольку похоже, что ТС тоже только знакомится.

1. Ограничение длины текстового поля не в символах, а в байтах. Поэтому количество символов, которые поместятся в 4000 байтов (или 32767 байтов) зависит от используемого CHARSET и от самих символов (если чарсет с переменной длиной символов).
2. Перечисленные функции работают с разными типами данных: string can be any of the data types CHAR, VARCHAR2, NCHAR, NVARCHAR2, CLOB, or NCLOB. Подробности и ограничения - в справке по конкретной функции.

Насчёт альтернативы и целостности прикладного функционала.
Не знаю, почему появилась идея расширения полей. Но для полей такой длины обычно характерна внутренняя неструктурированность (типа большого примечания) или же наоборот - жесткая структура (откуда и применение упомянутых выше функций).
Поэтому рекомендую для начала разобраться, действительно ли нужно расширять поле. Если внутренней структуры нет, лучше добавить ещё N полей типа "примечание2", "примечание3", чем всё тулить в одно поле.
Если есть структура и она просто выросла, до имеет смысл преобразовать поле в CLOB. Такие поля (со структурой) обычно пользователю на прямое редактирование не даются, а исправить функционал в коде выгоднее, чем пытаться обойтись "малой кровью". Такие попытки обычно в перспективе обходятся дороже.

Самый бредовыйтяжёлый вариант - структурированные и неструктурированные данные в одном поле.
Настоятельно рекомендую их разнести. Пользовательское описание (это что вообще такое? - отчёт пользователя о проделанной работе?) спокойно можно в CLOB. А триггерные порождения (если почему-то нет возможности использовать вместо них встроенный аудит) - в отдельную таблицу, можно тоже в CLOB. Лучше в отдельный TABLESPACE на отдельный диск, ибо быстро пухнет.