Re: LOG_ARCHIVE_DEST_n

I understand why Buck should be puzzled, it looks odd to me as well.

If I issue:

alter session set sort_area_size = 10485760;

it doesn't affect any other session, so why should:

alter session set log_archive_dest_3 = 'something'

make the archive process decide that it should be affected by something set in my session.

I don't think either of us would disagree with your argument for being able to issue

alter SYSTEM set log_archive_dest_3 = 'yyyy'

--
Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

Practical Oracle 8i:  Building Efficient Databases
Publishers:  Addison-Wesley

Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html



Howard J. Rogers wrote in message <3a90d8b7$1_at_news.iprimus.com.au>...


>You can defer or enable archiving to a destination at the session

 level -and


>it makes sense to do so.  For example, log_archive_dest_3 is mandatory, and

>becomes full.... that means the entire system will hang when ARCH can't

>successfully archive there, and the online logs loop round.

>

>Hence, the DBA fires up a session, defers archiving to that destination,

 and


>the database springs back into life.  DBA then fixes up the underlying

>problem, and re-enables archiving there.

>

>Regards

>HJR

>

>

>"Buck Turgidson" <remove-me_jc_va_at_hotmail.com> wrote in message

>news:bkWj6.4171$TD1.318685_at_bgtnsc05-news.ops.worldnet.att.net...

>> I am reading up on 8i recovery.  It says that the aforementioned

 parameter
 is


>> session-modifiable.  A query against V$PARAMETER confirms this.  Maybe I

 don't have


>> the whole context, but this doesn't make sense to me.  I could understand

 being


>> system-modifiable, but in what context is it session-modifiable?

>>

>> Thanks to anyone who could clear up my confusion.

>>

>>

>

>