oracle 11g for linux
SQL> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 895565824 bytes
Fixed Size 1340132 bytes
Variable Size 289410332 bytes
Database Buffers 595591168 bytes
Redo Buffers 9224192 bytes
Database mounted.
Database opened.
[color=red][size=large]obsolete or deprecated parameter(s) 已过时或不推荐使用参数[/size][/color]
[quote]
我觉得应该首先想到的是alert_sid.log文件，
这时候我们应该查看 alert_orcl.log !
[quote]
[oracle@hadoop bdump]$ cd /u01/app/oracle/admin/orcl/bdump
[oracle@hadoop bdump]$ vi alert_orcl.log
Fri Mar 4 19:37:17 2011
WARNING: The background_dump_dest init.ora parameter has been deprecated.
WARNING: Please remove the background_dump_dest parameter from the init.ora file.
WARNING: The diagnostic_dest init.ora parameter now determines the location of the diagnostic data
WARNING: The new location for the background logs and traces is /u01/app/oracle/diag/rdbms/orcl/orcl/trace
[/quote]
于是到 /u01/app/oracle/diag/rdbms/orcl/orcl/trace 这个目录
[quote]
[oracle@hadoop bdump]$ cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace
[oracle@hadoop trace]$ vi alert_orcl.log
Deprecated system parameters with specified values:
log_archive_start
background_dump_dest
user_dump_dest
End of deprecated system parameter listing
[/quote]
在这个日志文件中发现了上面的提示信息，有三个参数在11g中Deprecated不推荐使用。
先将$ORACLE_HOME/dbs/initSID.ora 中的 USER_DUMP_DEST、 log_archive_start、BACKGROUND_DUMP_DEST 三个参数删除掉，
(PS:如果没有pfile，则先创建一个pfile， SQL> create pfile from spfile;)
然后
SQl> shutdown immediate
SQL> create spfile form pfile
参数
1、 USER_DUMP_DEST 11g取消了
[quote]
USER_DUMP_DEST specifies the pathname for a directory where the server will write
debugging trace files on behalf of a user process.
[color=red]NOTE
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.[/color]
[/quote]
2、 BACKGROUND_DUMP_DEST
[quote]
BACKGROUND_DUMP_DEST specifies the pathname (directory or disc) where debugging trace files for the background processes (LGWR, DBWn, and so on) are written during Oracle operations.
An alert file in the directory specified by BACKGROUND_DUMP_DEST logs significant database events and messages. Anything that affects the database instance or global database is recorded here. The alert file is a normal text file. Its filename is operating system-dependent. For platforms that support multiple instances, it takes the form alert_sid.log, where sid is the system identifier. This file grows slowly, but without limit, so you might want to delete it periodically. You can delete the file even when the database is running.
N[color=red]OTE
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.[/color]
[/quote]
3、DIAGNOSTIC_DEST
[quote]
As of Oracle Database 11g Release 1, the diagnostics for each database instance are located in a dedicated directory, which can be specified through the DIAGNOSTIC_DEST initialization parameter. The structure of the directory specified by DIAGNOSTIC_DEST is as follows: <diagnostic_dest>/diag/rdbms/<dbname>/<instname>
This location is known as the Automatic Diagnostic Repository (ADR) Home.For example, if the database name is proddb and the instance name is proddb1, the ADR home directory would be diagnostic_dest>/diag/rdbms/proddb/proddb1.
The following files are located under the ADR home directory:
Trace files - located in subdirectory <adr-home>/trace
Alert logs - located in subdirectory <adr-home>/alert. In addition, the alert.log file is now in XML format, which conforms to the Oracle ARB logging standard.
Core files - located in the subdirectory <adr-home>/cdumd
Incident files - the occurrence of each serious error (for example, ORA-600, ORA-1578,ORA-7445) causes an incident to be created. Each incident is assigned an ID and dumping for each incident (error stack, call stack, block dumps, and so on) is stored in its own file, separated from process trace files. Incident dump files are located in <adr-home>/incident/<incdir#>. You can find the incident dump file location inside the process trace file.
[/quote]
