Критерии выбора типа для данных большого объема
Перед тем как использовать новые возможности, связанные с большими объектами, вам потребуется принять ряд важных решений.
BFILE или LOB
Какой тип данных выбрать проектировщику для хранения неструктурированных данных большого объема — LOB или BFILE? Ответ, как вы, вероятно, догадываетесь, звучит так: "Это зависит от конкретной ситуации". Если такие данные должны участвовать в транзакциях базы данных, применяйте LOB. Когда участие в транзакциях не предполагается и данные принимаются из внешнего источника, например из файла, следует использовать BF1LE.
Тип BFILE привлекателен тем, что загрузка таких данных не влечет за собой дополнительных затрат. Следует, однако, отметить несколько моментов, о которых нужно помнить при использовании BFILE.
1. Oracle не пытается контролировать, что делают пользователи операционной системы с внешними файлами. Кто-нибудь может удалить внешний файл или заменить его содержимое, что, возможно, приведет к нарушению ссылочной целостности данных и всегда сопряжено с риском.
2.   При удалении BFILE из базы данных фактически убирается ссылка, а файл остается нетронутым. Когда используется BFILE нужно периодически удалять "повисшие" BFILE-файлы, т.е. файлы, ссылки на которые удалены, или файлы, созданные в рамках незафиксированной транзакции. Конечно, если данные содержатся в базе, Oracle обладает большими возможностями контроля за тем, кто обращается к этим данным и обновляет их, а также управляет такими административными задачами, как очистка удаленных данных (и тем, как такие операции выполняются).
3.   Если вы используете многопоточный сервер, сеанс должен быть привязан к одному серверу, пока открыт BFILE. Этот серверный процесс держит файл открытым, и дескриптор файла не может свободно передаваться из одного сеанса в другой.
Наш главный принцип — использовать не BFILE, a LOB, за исключением случаев, когда имеются веские доводы в пользу первых. Вот некоторые из них: данные уже существуют во внешних файлах, достигающих сотен мегабайтов каждый, и вам не очень или совсем не нужно обновлять данные или проверять их средствами PL/SQL.
Способность к восстановлению и согласованность
По умолчанию LOB (как и любые данные в Oracle) должны обладать свойством согласованности по чтению (read consistency). Это означает, что видимые запросу данные имеют точку согласованности по чтению (как правило, момент, в который инициировано выполнение предложения). Если после точки согласованности по чтению данные изменились, Oracle обеспечивает согласованное чтение, реконструируя исходное состояние данных из
4.  "Большие" особенности OracleS	75