Question

I need to assign value to FetchSize. rowsize can be received from datareader using refelection.

But I need row count, can I harcode as rowsize * 100000 (instead of rowcount).

executedataReader will be used for multiple stored procedures, cant get rowcount.

            OracleDataReader dr = command.ExecuteReader();

            Int32 rowCount = 100000; //in this case actual result will be just 20k only. will it have any issue?

            FieldInfo fi = dr.GetType().GetField("m_rowSize", BindingFlags.Instance | BindingFlags.NonPublic);

            Int32 rowSize = Convert.ToInt32(fi.GetValue(dr));

            dr.FetchSize = rowCount * rowSize;

            while (dr.Read())
            {
                string myField = (string)dr[0];
                Console.WriteLine(myField);
            }

will there be any cons by fixing this?

Answer 1

The FetchSize property here limits the amount of memory that is allocated for a single “fetch” back to the database. Smaller fetch sizes mean more round trips to get data, but also means less memory in use on the client at any given time.

Setting the fetch size to something like RowSize * n will tell the reader to always fetch at most n rows at one time. If you set n equal to RowCount you are saying “fetch the entire result set at once”. If you set n equal to a fixed number, you are saying “fetch me 1000 (or 10000 or 25000 or whatever) rows at once”. When you call DataReader.Read(), the data reader will try to return rows that it has already fetched and cached. If you asked it to fetch 100,000 rows at a time, it will only need to talk to Oracle once every 100,000 Read() calls.

A higher fetch size will mean more efficient network traffic, fewer trips to the database, and thus will generally be “faster” under most circumstances. However, it will mean comparatively more memory used on the client, so if the fetch size gets really big you can run into garbage collection and/or paging issues. That’s up to you.

Note that it’s perfectly legal to assign FetchSize a value that’s not a multiple of the row size, it will just result in some leftover memory being unused on each fetch. If you’re using the same Command object for multiple stored procedures with different row sizes, you may be better off just setting a large FetchSize value — in actual bytes — up front and using that for everything.