Re: Oracle 11g placement of the alert log

From: Mladen Gogala <mgogala_at_yahoo.com>
Date: 13 Jan 2008 15:06:51 GMT
Message-ID: <478a290b$0$1345$834e42db@reader.greatnowhere.com>

On Sat, 12 Jan 2008 22:19:57 -0800, hjr.pythian wrote:

> On Jan 13, 12:20 pm, DA Morgan <damor..._at_psoug.org> wrote:

>> Mladen Gogala wrote:
>> > On Sat, 12 Jan 2008 15:47:02 +0000, Mladen Gogala wrote:
>>
>> >> This is untrue. One can simply change background_dump_dest and the
>> >> alert log will go back to where it was.
>>
>> > Those parametes are, of course, deprecated in favor of
>> > DIAGNOSTIC_DEST but are still fully functional.
>>
>> If they are now that would be news to me because in Beta 4, 5, and 6
>> they were ignored.
>> --
>> Daniel A. Morgan
>> Oracle Ace Director & Instructor
>> University of Washington
>> damor..._at_x.washington.edu (replace x with u to respond) Puget Sound
>> Oracle Users Groupwww.psoug.org

>
>
> I hate this sort of silly guesswork and innuendo. You leave anyone who
> happens to be passing without any firm foundation of actual *fact*.
>
> The facts of the matter are evident in the official documentation:
>
> "This parameter is ignored by the new diagnosability infrastructure
> introduced in Oracle Database 11g Release 1, which places trace and core
> files in a location controlled by the DIAGNOSTIC_DEST initialization
> parameter."
>
> (http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/
> initparams019.htm#REFRN10008)
>
> Or anyone could have done this simple test:
>
> SQL> show parameter background_dump_dest
>
> NAME TYPE VALUE
> ------------------------------------ ----------- ------------
> background_dump_dest string c:\app\hjr
>
> SQL> alter system set background_dump_dest='C:\app';
>
> SQL> alter system switch logfile;
>
> System altered.
>
> SQL> host dir c:\app\
> Volume in drive C has no label.
> Volume Serial Number is D070-3646
>
> Directory of c:\app
>
> 13/01/2008 01:23 PM <DIR> . 13/01/2008 01:23 PM <DIR>
> .. 13/01/2008 01:36 PM <DIR> hjr
> 0 File(s) 0 bytes
> 3 Dir(s) 34,271,100,928 bytes free
>
>
> ...and the lack of any alert log in the c:\app directory would
> definitely indicate that a background_dump_dest setting of c:\app is
> being ignored.
>
> A test always beats guesswork based on betas any day. A citation form
> the official doco helps, too.

I did test, but my description was a bit inaccurate. Here is the test:

SQL> alter system set "_diag_adr_enabled"=false scope=spfile;

System altered.

SQL> alter system set background_dump_dest='/tmp' scope=spfile;

System altered.

SQL> startup force
ORA-32004: obsolete and/or deprecated parameter(s) specified ORACLE instance started.

Total System Global Area 1623748608 bytes

Fixed Size                  1300240 bytes
Variable Size            1174407408 bytes
Database Buffers          436207616 bytes
Redo Buffers               11833344 bytes

Database mounted.
Database opened.
SQL> [oracle_at_oracle12 ~]$ cd /tmp
[oracle_at_oracle12 tmp]$ ls

11g_dbrm_30022.trc  11g_p001_30056.trc  cgO19258           keyring-u5rbaN
11g_mman_30030.trc  11g_vktm_30016.trc  hsperfdata_oracle  mapping-oracle
11g_p000_30054.trc  alert_11G.log       keyring-2qzqsN     orbit-oracle

[oracle_at_oracle12 tmp]$

Therefore, you can restore the old behavior, without loss of support. The trick is in the parameter. Personally, I don't see any reason for doing that, but I tested it. I only forgot about another parameter that I used to set it up. BTW, in conjunction with that, there is an interesting bug:

SQL> select distinct isspecified from v$obsolete_parameter;

ISSPE

---

FALSE During the startup, obsolete parameter is reported but not flagged as such in the v$obsolete_parameter table. Also, I noted that, with ADR enabled, the "traditional" alert log file is updated in less then timely manner.

-- 
http://mgogala.freehostia.com

Received on Sun Jan 13 2008 - 09:06:51 CST