"Rozengurtel, Daniel" <[EMAIL PROTECTED]> writes: > With no RowCacheSize set up the extract took 34 secs, using about > 5mb RAM > With RowCacheSize =>0 (automatically select what's best), the > extract took 33 secs, with 5mb RAM > With RowCacheSize =>100, the extract took 8 secs, using about 6mb > RAM (THE BEST RESULTS EVER)
> 7. The database is on the same physical Unix machine that my extractions > run. So I am not sure if there is network delay of of some sort. No, probably no network delay, but the machine has to switch between the client and server process + handle the communication overhead. So it could easily spend more time on that than on fetching rows if the number of rows sent in each batch is small. > So, ladies and gets, everything comes down to using RowCacheSize attribute. > I don't have any experience with it. I know if you have a huge number set up > to it, your other processes might end up with no Memory for them, or > something like that. How dangerous is it to use? How do you know what I certainly wouldn't consider RowCacheSize dangerous. 100 rows should really not be an issue unless your rows were _really_ huge (like CLOBs or something). You can also set RowCacheSize to eg. -1000000 to set the memory size to use explicitly. The only real 'danger' I can imagine from RowCacheSize is for a long-running SELECT that fetches only a few rows. A large RowCacheSize would delay the fetch of the first (but not the last) row. > problem is? Low cache size Database, Unix???? If I use RowCacheSize=>0, does > it mean Oracle/Unix has to find a safest and not necessarily best way of > dealing with data being extracted?? Why then SQL SPOOL command works faster > than that? Well DBD::Oracle tried to guess a good RowCacheSize value, but it guessed wrong. - Kristian.
