shutdown immediate20分钟没响应重启服务器导致的【问题】

[快乐的流浪]

过完年回来，登录提示 ORA-00257：可能是归档日志满了导致，因为之前也出现过该问题，都解决了。所以手动删除归档日志，然后执行SHUTDOWN IMMEDIATE命令，20分钟没反应。等不及了，把整个服务器REBOOT了后。出现下面的问题，请高手指点一二：

表现：客户端连接提示：ora-12514
客户端TNSPING能通


服务器端提示：

服务器端监听能正常启动，实例不能正常启动

SQL> shutdown immediate;
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory
SQL> startup;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 2042241024 bytes
Fixed Size 1337548 bytes
Variable Size 1275070260 bytes
Database Buffers 754974720 bytes
Redo Buffers 10858496 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 7213
Session ID: 292 Serial number: 5

[vc555]

环境变量不对。也会出错。但是报ORA-32004应该是数据库参数设置问题。
现在就是进告警日志看看哪些参数有问题。
你先startup mount
再show parameter background_dump_dest
或者直接用os命令find / -name "..."查找告警日志位置。

[快乐的流浪]

Errors in file /u01/diag/rdbms/wap/wap/trace/wap_arc2_8859.trc:
ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 8388608000 字节) 已使用 100.00%, 尚有 0 字节可用。
************************************************************************
************************************************************************
Errors in file /u01/diag/rdbms/wap/wap/trace/wap_ora_8839.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 35963904 bytes disk space from 8388608000 limit
You have following choices to free up space from recovery area:
ARCH: Error 19809 Creating archive log file to '/u01/flash_recovery_area/WAP/archivelog/2010_02_21/o1_mf_1_296_%u_.arc'
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Errors in file /u01/diag/rdbms/wap/wap/trace/wap_arc2_8859.trc:
ORA-19809: 超出了恢复文件数的限制
ORA-19804: 无法回收 36759552 字节磁盘空间 (从 8388608000 限制中)
ARC2: Error 19809 Creating archive log file to '/u01/flash_recovery_area/WAP/archivelog/2010_02_21/o1_mf_1_297_%u_.arc'
Errors in file /u01/diag/rdbms/wap/wap/trace/wap_ora_8839.trc:
ORA-16038: log 2 sequence# 296 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 2 thread 1: '/u01/oradata/wap/redo02.log'
USER (ospid: 8839): terminating the instance due to error 16038
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance wap - Archival Error
ORA-16038: 日志 3 sequence# 297 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 3 线程 1: '/u01/oradata/wap/redo03.log'
Errors in file /u01/diag/rdbms/wap/wap/trace/wap_arc2_8859.trc:
ORA-16038: 日志 3 sequence# 297 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 3 线程 1: '/u01/oradata/wap/redo03.log'
Instance terminated by USER, pid = 8839
Sun Feb 21 13:22:00 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =85
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Using parameter settings in server-side spfile /u01/oracle/dbs/spfilewap.ora
System parameters with non-default values:
processes = 500
sessions = 776
nls_language = "SIMPLIFIED CHINESE"
nls_territory = "CHINA"
memory_target = 3248M
control_files = "/u01/oradata/wap/control01.ctl"
control_files = "/u01/flash_recovery_area/wap/control02.ctl"
db_block_size = 8192
compatible = "11.2.0.0.0"
log_archive_format = "%t_%s_%r.dbf"
db_recovery_file_dest = "/u01/flash_recovery_area"
db_recovery_file_dest_size= 8000M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=wapXDB)"
audit_file_dest = "/u01/admin/wap/adump"
audit_trail = "DB"
db_name = "wap"
open_cursors = 300
sql_trace = FALSE
diagnostic_dest = "/u01"
Deprecated system parameters with specified values:
sql_trace
End of deprecated system parameter listing
Sun Feb 21 13:22:02 2010
PMON started with pid=2, OS id=9146
Sun Feb 21 13:22:02 2010
VKTM started with pid=3, OS id=9148
VKTM running at (100ms) precision
Sun Feb 21 13:22:02 2010
GEN0 started with pid=4, OS id=9152
Sun Feb 21 13:22:02 2010
DIAG started with pid=5, OS id=9154
Sun Feb 21 13:22:02 2010
DBRM started with pid=6, OS id=9156
Sun Feb 21 13:22:02 2010
PSP0 started with pid=7, OS id=9158
Sun Feb 21 13:22:02 2010
DIA0 started with pid=8, OS id=9160
Sun Feb 21 13:22:02 2010
MMAN started with pid=9, OS id=9162
Sun Feb 21 13:22:02 2010
DBW0 started with pid=10, OS id=9164
Sun Feb 21 13:22:02 2010
LGWR started with pid=11, OS id=9166
Sun Feb 21 13:22:02 2010
CKPT started with pid=12, OS id=9168
Sun Feb 21 13:22:02 2010
SMON started with pid=13, OS id=9170
Sun Feb 21 13:22:02 2010
RECO started with pid=14, OS id=9172
Sun Feb 21 13:22:02 2010
MMON started with pid=15, OS id=9174
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Sun Feb 21 13:22:02 2010
MMNL started with pid=16, OS id=9176
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01
Sun Feb 21 13:23:54 2010
Starting ORACLE instance (normal)
Sun Feb 21 13:26:03 2010
Starting ORACLE instance (normal)
Sun Feb 21 13:32:44 2010
Starting ORACLE instance (normal)
Sun Feb 21 13:33:18 2010
Starting ORACLE instance (normal)
Sun Feb 21 13:33:44 2010
Starting ORACLE instance (normal)

[tangren]

oracle10g在默认情况下，归档日志是保存在闪回恢复区的，如果你建库的时候用的默认设置，
闪回恢复区应该是2G，空间被占满了以后就无法再归档了
执行下面的语句，可以看到闪回恢复区的使用情况
select reason,object_type,suggested_action from dba_outstanding_alerts;

解决方法：
1.将归档设置到其他目录，修改alter system set log_archive_dest = 其他路径
2.转移或者删除闪回恢复区里的归档日志。
3.增大闪回恢复区。
ALTER SYSTEM SET db_recovery_file_dest_size=4g scope=both;

[快乐的流浪]

谢谢vc555的热心帮忙，以及tangren提供的解决办法。

下面是前人的经验，大家可参考下

http://www.itpub.net/thread-646510-1-1.html

http://www.eygle.com/archives/2005/03/oracle10gecieif.html

[suiziguo]

32004, 00000, "obsolete and/or deprecated parameter(s) specified"
// *Cause: One or more obsolete and/or parameters were specified in
// the SPFILE or the PFILE on the server side.
// *Action: See alert log for a list of parameters that are obsolete.
// or deprecated. Remove them from the SPFILE or the server
// side PFILE.

[vc555]

1.看告警日志。贴出你的os和db版本。

你改过参数吗？怎么报ORA-32004

[suiziguo]

直接编辑SPFILE有风险，建议检查服务器端PFILE，删除过期参数，然后

startup pfile=

启动，再
create spfile from pfile;
shutdown immediate
startup

[快乐的流浪]

补充信息：

操作系统CENTOS5.2

ORACLE版本是ORACLE11G

[vc555]

告警日志信息呢？把里面错误信息贴出来。应该是参数问题。

[快乐的流浪]

告警日志，我在下面的路径没有找到BDUMP文件夹

$oracle_home\admin\SID\bdump\alert.log

我的
$oracle_home\admin\SID\下只有三个 adump dpdump pfile 文件夹

[快乐的流浪]

是不是有些环境变量没有设置，也可能导致该问题？