Блог

Мы используем Oracle 19C и вызываем веб-сервис, который в основном возвращает файл PDF в кодировке base 64. На одном из сайтов наших клиентов мы получаем первый ответ размером около 32 тыс. байт, как и должно быть, и после этого результат поврежден.

Нам удалось значительно устранить проблему:

• Проблему можно воспроизвести, просто загрузив любой файл с веб-сервера. Для этой цели я создал файл с именем «test.txt » который имеет размер примерно 300 тысяч байт и содержит только букву «А» снова и снова.
• Проблема не зависит от веб-сервера, не имеет значения, где размещен файл.
• Проблема по-прежнему возникает, когда сервер Oracle и веб-сервер находятся в одной подсети (между ними нет брандмауэра)
• Проблема НЕ возникает, когда этот файл загружается из браузера на сервере базы данных Oracle
• Манипулирование различными размерами буфера приводит к различному поведению. Но не позднее 40 Тыс. байт файл становится полностью поврежденным.
• UTL_HTTP.SET_PERSISTENT_CONN_SUPPORT не имеет значения
• Проблема НЕ возникает при использовании http вместо https
• При загрузке одного и того же файла с одним и тем же кодом несколько раз подряд результирующий файл никогда не бывает одинаковым
• Проблема может быть воспроизведена только на определенном сервере / клиенте. Наш сервер разработки под управлением Oracle 19.8 (та же ОС, тот же пакет исправлений) не показывает такого поведения.
• Файл имеет правильный размер. Скремблируется только содержимое.

Я совершенно уверен, что это не брандмауэр клиентов, потому что это все еще происходит, когда веб-сервер и сервер БД находятся в одной подсети. Я совершенно уверен, что на сервере нет никакого программного обеспечения безопасности, потому что оно работает в SoapUI и браузере. Я уверен, что это не Oracle 19.8 как таковой, потому что он работает для нас.

Мы выделили код, который считывает веб-ответ по частям и собирает большой двоичный объект, но затем я также заметил, что на самом деле вы можете загружать файлы еще проще, вызывая httpurityp.createuri(url).getblob() . Я попытался использовать этот код, и проблема все еще сохраняется, так что это не наш код (который в любом случае проверен и протестирован).

Вот код:

 declare
 l_blob           BLOB;
  url_v             VARCHAR2(250) := 'http://www.infosystem.ch/files/test.txt';
BEGIN
  l_blob := HTTPURITYPE.createuri(url_v).getblob();

  INSERT INTO test_file_download
    ( download_at    
    , content)
  VALUES
    ( SYSDATE
    , l_blob
    );            

END;
/ 
 

Это должно привести к файлу http://www.infosystem.ch/files/test.txt , который содержит только букву «А» снова и снова.

Этого не происходит, результирующий файл поврежден: https://www.infosystem.ch/files/test_corrupted.txt

Бок о бок:

Поврежденный образ 1

Затем есть еще несколько, и на каком-то этапе (обычно около 32 КБ) остальная часть файла становится беспорядочной:

Начало остальной части файла

Кто-нибудь имеет представление о том, что это может быть? Я уже регистрировал SR в Oracle, но в прошлый раз, когда у нас была аналогичная проблема (еще в 12.2), им потребовалось 6 месяцев, чтобы воспроизвести и подтвердить, что это ошибка, а 5 лет спустя «разработка все еще работает над исправлением». Излишне говорить, что это совершенно бесполезно.

Спасибо!

«ОСНОВНОЙ патч для исправления ошибки # 32327201 для платформ 19.0.0.0.0 Windows-x86-64 Этот патч можно установить без RAC. Выпущено: Чт, 10 июня, 11:24:26 2021

В этом документе описывается, как вы можете установить исправление CORE DST для исправления ошибки # 32327201 в вашей базе данных Oracle Database 19 выпуска 19.0.0.0.0 »

Это тот, который решил нашу проблему сегодня, который был выпущен 3 дня назад 🙂

Я думаю, что у нас была та же проблема, что и у вас 🙂

Я считаю, что это фактически решается исправлением 32738356

32738356 — KBHSHTRECEIVE ПОЛУЧЕНИЕ ПОВРЕЖДЕННЫХ ДАННЫХ В WINDOWS