Плохая производительность с OracleDataReader

Question

У меня ужасная производительность при чтении данных с объекта OracleDataReader по сравнению с MS SQL Server. Это почти в 10 раз медленнее, что недопустимо.

Ниже приведен пример тестового кода, который используют оба теста. Какой самый оптимальный способ чтения данных из OracleDataReader, есть ли лучший способ, чем показано ниже?

Мне трудно поверить, что ODP.Net не может даже сравниться с SqlClient.

ОБНОВЛЕНИЕ: я сузил проблему до выборки текстовых полей. По какой-то причине ODP.Net ужасна в этом. Есть идеи как это исправить?

void ReadData(System.Data.IDataReader dr, int maxRows)
 {
     ArrayList rows = new ArrayList(maxRows > 0 ? maxRows : 1000);

     object[] row;

     int rowsRead = 0;
     while (dr.Read() && ((maxRows == -1) || (rowsRead++ < maxRows)))
     {
         row = new object[dr.FieldCount];
         dr.GetValues(row);

         rows.Add(row);
     }
     rows.Clear();
 }

Примечание (ы):

• Пробовал экспериментировать с FetchSize, без большой разницы

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

• Структуры данных в обеих базах данных идентичны.

• Пробовал комбинированный DataAdapter / DataSet с похожими результатами.

Answer 1

Мы фактически проследили эту проблему до использования столбцов CLOB для хранения строковых данных типа nvarchar (MAX).

Oracle признала, что в их программном обеспечении OCI есть проблемы, связанные с объектами CLOB. По умолчанию они пытаются получить CLOB таким же образом, как и очень большой BLOB. Они устанавливают указатели, пытаются выполнять разбиение на страницы и т. Д. Конечно, это поведение по умолчанию снижает производительность, когда дело доходит до обычного текстового поля ~ 200 символов. Вы фактически отключаете это поведение, устанавливая LOBFetchSize в -1. Таким образом, он будет захватывать содержимое CLOB за один раз. Тогда все начинает летать, и вы получаете очень хорошие результаты.

Даже с этим, хотя у нас продолжали возникать проблемы. Мы подтвердили утечки памяти и ошибки ссылки на память в программном обеспечении OCI до версии 11.2. Но 11.2 работает нормально как в 32, так и в 64-битных сценариях.

Таким образом, установка LOBFetchSize в -1 была здесь для определения производительности.