Плохая производительность с 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 была фиксатором производительности здесь.