Oracle 11. Поле Updating BLOB. Файл дб последовательное чтение неуместно замедляется?
mod_evasive является одной из лучших серверных мер мятежника, которые можно принять при выполнении веб-сервера Apache - http://www.think-security.com/protect-your-apache-web-server-with-mod_evasive/
В Oracle LOB (включая BLOB) хранится как:
- в таблице LOB - если LOB меньше 3900 байт, он может храниться внутри строки таблицы; по умолчанию это включено, если вы не укажете DISABLE STORAGE IN ROW
- обычный LOB - хранящийся в отдельном сегменте, вне таблицы, вы даже можете поместить его в другое табличное пространство; для этих:
- как минимум байт CHUNK выделяется и полностью повторяется (даже если LOB имеет только 1 байт)
- за столбцом LOB находится внутренний промежуточный индекс, который вызывает споры при обновлениях и может практически сериализовать их
- ] доступ является многоуровневым и, следовательно, относительно медленнее
- с опцией NOCACHE, ожидающие - "чтение по прямому пути" - по умолчанию
- с опцией CACHE, ожидающие - "последовательное чтение файла db"
- где CACHE_SIZE_THRESHOLD не учитывается, поэтому большой LOB может напрасно расходовать ваш кеш
Следовательно, если ваши LOB больше 4 КБ, они будут относительно медленными, и это может быть просто вашим случаем. Я бы изучил размеры.
Я бы исследовал USER_LOBS (или DBA_LOBS), чтобы увидеть, чем "хорошие" и "медленные" столбцы LOB различаются по своим определениям.
Это описывается в заметке Metalink с идентификатором 66431.1 и может представлять интерес
ОБНОВЛЕНИЕ : Очарованный, казалось бы, необъяснимым диким объемом "последовательного чтения файла базы данных", я немного поискал и обнаружил, что странные вещи могут происходят с индексом lob после массовых DELETE . Просто предположение, но очень похоже на ваш случай. Если это так, Я бы полностью перестроил столбец lob . (Перемещение столбца lob может также привести к перестроению индекса lob - я не уверен).