Re: Avoiding generating redo logs

In article <eegn2k$io8$1_at_news6.zwoll1.ov.home.nl>, Frank van Bortel says...
> As I understand the thread until now, you are worried
> about logging - why?

It was just a thought - if the option existed to reduce server activity then it was perhaps something to take advantage of. It is not a prerequisite by any means.

> Also, you want to retain data over web sessions. Beats me
> as to why, but it's *your* requirement. So, you
> need a table.

Well think of it like this - a query takes 5 seconds to execute (for example - i.e. it's a a wait). Results are say 200 rows. You display this in a browser window, perhaps 20 at a time. You want the user to be able to click a 'next' button to see the next 20 rows. Instead of reexecuting  the query, you simply select rows 21-40 from the table based on the current 'order by' - results returned almost instantly.

> And you need some identifier over the
> web sessions in order to distinguish one returning
> user from the other.

Yes sure - the DAD is defined so the user has to login using a username nad password - after that we always know the user who is accessing the application.

>
> Again: what's wrong with logging?

Absolutely nothing, just exploring/wishing to understand.

> Why not create a table with the nologging option? Be
> advised, it will not be recoverable in case of mishap.
>
> It seems to me, you worry about potential overhead, where
> you should actually be worried about the efficiency of
> your code.
> Did you put up a test, with your code accessing a session
> table, created with nologging vs. one created with logging?
>

No - not at that stage - just exploring all possibilities.

> Do (because you did not!), and come back with the differences,
> if you are able to measure these consistently. I bet the
> differences are not noticeable (though measurable)
>

Thanks.

-- 

jeremy