Bad performances avec OracleDataReader

Question

Je rencontre quelques performances terribles avec les données de lecture sur l'objet OracleDataReader par rapport à MS SQL Server. Il est presque 10 fois plus lent, ce qui est inacceptable.

est Ci-dessous un code de test d'échantillon que les deux tests utilisent. Quelle est la plus optimale façon de lire les données à partir OracleDataReader, est-il une meilleure façon que ci-dessous?

Je vais avoir du mal à croire que ODP.Net ne peut même comparer à SqlClient.

Mise à jour: J'ai PRECISEE le problème à aller chercher des champs de texte. Pour une raison ODP.Net est terrible à ce sujet. Des idées comment résoudre ce problème?

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();
 }

Note (s):

• J'ai essayé d'expérimenter avec FetchSize, n'a pas connu une grande différence

• temps d'exécution de la requête ne sont pas la question ici, seule la récupération des données.

• Les structures de données sur les deux bases de données sont identiques.

• Essayé DataAdapter / combo DataSet avec des résultats similaires.

Answer 1

Nous avons en fait tracé cette question jusqu'à l'utilisation des colonnes CLOB pour stocker nvarchar (MAX) type de données de chaîne.

Oracle a admis que leur logiciel OCI a des problèmes traitant de CLOBs. Par défaut, ils tentent de récupérer le CLOB de la même façon qu'ils avaient extraient un blob très grand. Ils pointeurs de configuration, essayez de faire la pagination, etc Bien sûr, ce comportement par défaut tue la performance en ce qui concerne un champ de texte normal ~ 200 char. Vous tournez effectivement ce comportement en mettant hors LOBFetchSize à -1. De cette façon, il va saisir le contenu des CLOBs en un aller-retour. Ensuite, les choses commencent à voler et vous obtenez une très bonne performance.

Même avec ce que nous avons continué à avoir des problèmes. Nous avons confirmé les fuites de mémoire et les erreurs de référence de la mémoire dans le logiciel OCI avant la version 11.2. Mais 11.2 semble fonctionner très bien dans les deux scénarios 32 et 64 bits.

Ainsi, la mise en LOBFetchSize à -1 était le fixeur de performance ici.