Re: Oracle 11g placement of the alert log
From: DA Morgan <damorgan_at_psoug.org>
Date: Sun, 13 Jan 2008 07:47:32 -0800
Message-ID: <1200239234.276643@bubbleator.drizzle.com>
>
> 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.
Date: Sun, 13 Jan 2008 07:47:32 -0800
Message-ID: <1200239234.276643@bubbleator.drizzle.com>
Mladen Gogala 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.
I didn't think it appropriate to advertise what you posted but you are correct. Unfortunately dinosaurs will now try to also create dictionary managed tablespaces, rollback segments, and find the source code for svrmgrl. <g>
The entire ADR infrastructure is based on the log files being at a specific location, under ADR_BASE and ADR_HOME. If you move one piece of it your break the stack. I can't say from trying it but I would now expect some of the RMAN and DBMS_IR functionality to not work.
-- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan_at_x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.orgReceived on Sun Jan 13 2008 - 09:47:32 CST