Re: Oracle 11g placement of the alert log
Date: 13 Jan 2008 15:06:51 GMT
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
> 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;
SQL> alter system set background_dump_dest='/tmp' scope=spfile;
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 bytesDatabase mounted.
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;
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. Received on Sun Jan 13 2008 - 09:06:51 CST