Hi,

to clarify further,

NOLOGGING will only avoid the generation of redo entries during the
creation of the index or the altering of an index.

Look at pages 482-484 in Oracle 9i Release 2 SQL Reference Manual. Part
No. A96540-02.

as far as the unsupported and hidden parameter method goes, even that
hidden parameter *will not* stop redologging.

DML is *always* logged, irrespective of the hidden parameter setting.
except for Direct Path Inserts (which can anyway be worked around using
NOLOGGING)

so, this hidden param only minimises the amount of redo by not logging
some other operations.

the best test is by dumping the redo before using the parameter and
after using the parameter. see how much difference is there in the redo
size.

if you are testing it, kindly post the results of the redo dump.

cheers
anand

Jeremy wrote:
> In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
>
> > Why do you need to worry about redo?
> >
> >
> Perhaps I don't - see other responses.
>
> --
>
> jeremy

In article <1158570618.200279.39050@k70g2000cwa.googlegroups. com>,
Martin T. says...
> Jeremy wrote:
> >
> > Not when using apache/mod_plsql - a new session is started on every
> > interaction.
> >
>
> I had the impression (may be wrong here) that you are in an early-ish
> phase of the project/implementation.

This is actually version6 of an established commercial application -
it's a rewrite of the front-end but using the same technologies as the
current live version and on the same DB structure - meaining that we
will support v5 and v6 users concurrently.

> Let me just repeat that it may well be worthwhile to look at expanding
> the technologies used if that means you're application could be
> implemented better. (And if you tell "them" that if you are allowed to
> use X we can do THIS(!) ... "they" are often more flexible as one had
> initially thought.)

That's fine, I do understand this. But we don't find that we are limited
(in general terms) by the existing architecture and, of course, are
exploring ways to do things "better" (from the POV of the users).


--

jeremy

In article <1158570767.995705.47900@e3g2000cwe.googlegroups.c om>, Anand
Rao says...

> so, this hidden param only minimises the amount of redo by not logging
> soif you are testing it, kindly post the results of the redo dump.
>

Thanks for your response, but we will not be taking this any further.

--

jeremy

Jeremy schreef:
> In article <eegn2k$io8$1@news6.zwoll1.ov.home.nl>, Frank van Bortel
> says...
>> 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.

Ah - and the DAD, using basic authentication, sends the userid
(and password!) with every request made. But is there a session
identifier?
--
Regards,
Frank van Bortel

Top-posting is one way to shut me up...

Jeremy schreef:
> In article <eegn2k$io8$1@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 re-
> executing the query, you simply select rows 21-40 from the table based
> on the current 'order by' - results returned almost instantly.
>

Just realized pressed send too early:
the query will be cached by the instance - just take a short
test and you'll notice the first query will be slower than
the subsequent ones.

If you would like to use something better than the ugly
logon box basic authentication provides, check my blog

--
Regards,
Frank van Bortel

Top-posting is one way to shut me up...

In article <eemo4a$abv$1@news1.zwoll1.ov.home.nl>, Frank van Bortel
says...
> If you would like to use something better than the ugly
> logon box basic authentication provides, check my blog
>
>
Hi Frank, where do I find your blog?

--

jeremy

In article <eemnqp$5gu$2@news1.zwoll1.ov.home.nl>, Frank van Bortel
says...
> Jeremy schreef:
> > In article <eegn2k$io8$1@news6.zwoll1.ov.home.nl>, Frank van Bortel
> > says...
> >> 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.
>
> Ah - and the DAD, using basic authentication, sends the userid
> (and password!) with every request made. But is there a session
> identifier?
>
Sure this will all be handled with cookies tied to a DB session record

--

jeremy

On Mon, 18 Sep 2006, jeremy0505@gmail.com wrote:
> In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
>
>> Why do you need to worry about redo?
>>
>>
> Perhaps I don't - see other responses.

I would look at materialized views myself, because, that is really what
you are describing (ie, I want to have a query not have to execute
everytime, but instead, have it stored so I can get the results quicker)
An MV helps solve that in a most impressive fashion.

But, If you really needed to use a global temp to get away from the redo,
then you could do something like the following pseudo-code:

IF (p_clientpackage.count_global(client_id) < 1)
BEGIN
p_clientpackage.insert_global;
END

p_clientpackage.get_from_global;


This would mean you execute the operation for each client, at most, the
number of connections you have in the pool. It would also need some
boundary questions asked, like, what if the query could return 0
rows...

Of course, your global temp would need to be "ON COMMIT PRESERVE ROWS".

--
Galen Boyer

In article <ulkog4a9w.fsf@rcn.com>, Galen Boyer says...
> On Mon, 18 Sep 2006, jeremy0505@gmail.com wrote:
> > In article <uejua5rr0.fsf@rcn.com>, Galen Boyer says...
> >
> >> Why do you need to worry about redo?
> >>
> >>
> > Perhaps I don't - see other responses.
>
> I would look at materialized views myself, because, that is really what
> you are describing (ie, I want to have a query not have to execute
> everytime, but instead, have it stored so I can get the results quicker)
> An MV helps solve that in a most impressive fashion.
>
This may help actually, yes - however when the user requests the data to
be refreshed, it needs to be up-to-date rather than based on the latest
snapshot (am I right that MVs are periodically refreshed rather than
instantaneously with each transaction that may affect the content?).

> But, If you really needed to use a global temp to get away from the redo,
> then you could do something like the following pseudo-code:
>
> IF (p_clientpackage.count_global(client_id) < 1)
> BEGIN
> p_clientpackage.insert_global;
> END
>
> p_clientpackage.get_from_global;
>
>
> This would mean you execute the operation for each client, at most, the
> number of connections you have in the pool. It would also need some
> boundary questions asked, like, what if the query could return 0
> rows...

No problem, thanks for the pointer.

>
> Of course, your global temp would need to be "ON COMMIT PRESERVE ROWS".
>
>
As I understand it, this allows the rows to be preserved across
transactions NOT across sessions - and as mentioned, a new session is
necessarily created for each user-interaction (apache/mod_plsql).

cheers

--

jeremy

> Hi Frank, where do I find your blog?
>

Really!
http://www.google.com/search?client=...=Google+zoeken