Re: Oracle 11g placement of the alert log
From: <hjr.pythian_at_gmail.com>
Date: Sun, 13 Jan 2008 13:33:24 -0800 (PST)
Message-ID: <20450f5f-94ba-46c8-ac75-9a6bc18a95d0@s12g2000prg.googlegroups.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
Date: Sun, 13 Jan 2008 13:33:24 -0800 (PST)
Message-ID: <20450f5f-94ba-46c8-ac75-9a6bc18a95d0@s12g2000prg.googlegroups.com>
On Jan 14, 2:06 am, Mladen Gogala <mgog..._at_yahoo.com> wrote:
> 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
Bzzzt! That's a use of an underscore parameter. And therefore falls at the first hurdle: unsupported. Received on Sun Jan 13 2008 - 15:33:24 CST