Oracle数据库的故障解决
1. ORA-00257
sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on 星期二 7月 25 10:44:18 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> connect / as sysdba
已连接。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- --------------------------------------- --------------
1 1 101 52428800 1 NO CURRENT 3621973 24-7月 -06
2 1 99 52428800 1 NO INACTIVE 3600145 24-7月 -06
3 1 100 52428800 1 NO INACTIVE 3611932 24-7月 -06
发现ARC状态为NO，表示系统没法自动做归档
SQL> select * from v$recovery_file_dest;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------------------------------------------------------------------------------------------
/oracle/flash_recovery_area 2147483648 2134212608 0 35
SQL> select * from v$flash_recovery_area_usage;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------- -------------- -------------- -------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 69.97 0 40
BACKUPPIECE 30.01 0 2
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
已选择6行。
发现ARCHIVELOG占近70％，BACKUPPIRCR占了30％，这样FLASH_RECOVERY_AREA空间的空间已经被完全占据了
根据数据库目前可用存储空间为200GB、FLASH_RECOVERY_AREA空间为2GB的实际情况，把FLASH_RECOVERY_AREA的空间修改为20GB。
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g;
系统已更改。
SQL> select * from v$recovery_file_dest;
------------------------------------------------------- ---------- -----------------------------------
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ------------- -------------- ---------- ---------- ------------
/oracle/flash_recovery_area 2.1475E+10 2264587776 0 38
这时再查看日志的状态，发现REDO LOG处于正常的归档状态。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- -------------------------------------------- --------------
1 1 101 52428800 1 YES ACTIVE 3621973 24-7月 -06
2 1 102 52428800 1 NO CURRENT 3650399 25-7月 -06
3 1 100 52428800 1 YES INACTIVE 3611932 24-7月 -06
SQL> select * from v$flash_recovery_area_usage;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 7.6 0 43
BACKUPPIECE 4.21 0 2
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
已选择6行。
SQL>
2. ORA-600
日志文件中错误信息：
Mon Apr 16 14:37:52 2007
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.1.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 50331648
large_pool_size = 8388608
java_pool_size = 33554432
control_files = f:\ora\oradata\gzsb\control01.ctl, f:\ora\oradata\gzsb\control02.ctl, f:\ora\oradata\gzsb\control03.ctl
db_block_size = 8192
db_cache_size = 25165824
compatible = 9.2.0.0.0
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = xxxxxx
dispatchers = (PROTOCOL=TCP) (SERVICE=gzsbXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
background_dump_dest = c:\oracle\admin\gzsb\bdump
user_dump_dest = c:\oracle\admin\gzsb\udump
core_dump_dest = c:\oracle\admin\gzsb\cdump
sort_area_size = 524288
db_name = xxxxx
open_cursors = 300
star_transformation_enabled= FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 25165824
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
QMN0 started with pid=9
Mon Apr 16 14:37:54 2007
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Mon Apr 16 14:37:55 2007
ALTER DATABASE MOUNT
Mon Apr 16 14:38:00 2007
Successful mount of redo thread 1, with mount id 1403199684.
Mon Apr 16 14:38:00 2007
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Mon Apr 16 14:38:00 2007
ALTER DATABASE OPEN
Mon Apr 16 14:38:00 2007
Beginning crash recovery of 1 threads
Mon Apr 16 14:38:00 2007
Started first pass scan
Mon Apr 16 14:38:00 2007
Completed first pass scan
62 redo blocks read, 4 data blocks need recovery
Mon Apr 16 14:38:00 2007
Started recovery at
Thread 1: logseq 43, block 3, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 1 Seq 43 Reading mem 0
Mem# 0 errs 0: F:\ORA\ORADATA\GZSB\REDO01.LOG
Mon Apr 16 14:38:00 2007
Ended recovery at
Thread 1: logseq 43, block 65, scn 0.2970218
4 data blocks read, 4 data blocks written, 62 redo blocks read
Crash recovery completed successfully
Mon Apr 16 14:38:00 2007
Thread 1 advanced to log sequence 44
Thread 1 opened at log sequence 44
Current log# 2 seq# 44 mem# 0: F:\ORA\ORADATA\GZSB\REDO02.LOG
Successful open of redo thread 1.
Mon Apr 16 14:38:00 2007
SMON: enabling cache recovery
Mon Apr 16 14:38:00 2007
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Mon Apr 16 14:38:00 2007
SMON: enabling tx recovery
Mon Apr 16 14:38:00 2007
Database Characterset is ZHS16GBK
Mon Apr 16 14:38:00 2007
Errors in file c:\oracle\admin\gzsb\bdump\gzsb_smon_5196.trc:
ORA-00600: internal error code, arguments: [4194], [98], [75], [], [], [], [], []
Mon Apr 16 14:38:01 2007
Errors in file c:\oracle\admin\gzsb\udump\gzsb_ora_3648.trc:
ORA-00600: 内部错误代码，参数: [4194], [92], [84], [], [], [], [], []
Mon Apr 16 14:39:02 2007
Recovery of Online Redo Log: Thread 1 Group 2 Seq 44 Reading mem 0
Mem# 0 errs 0: F:\ORA\ORADATA\GZSB\REDO02.LOG
Recovery of Online Redo Log: Thread 1 Group 2 Seq 44 Reading mem 0
Mem# 0 errs 0: F:\ORA\ORADATA\GZSB\REDO02.LOG
Mon Apr 16 14:39:02 2007
Errors in file c:\oracle\admin\gzsb\udump\gzsb_ora_3648.trc:
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码，参数: [4194], [92], [84], [], [], [], [], []
Error 607 happened during db open, shutting down database
USER: terminating instance due to error 607
Instance terminated by USER, pid = 3648
ORA-1092 signalled during: ALTER DATABASE OPEN...
查看资料得到：
Would seem that the error is:
ORA-600 [4194] "Undo Record Number Mismatch While Adding Undo Record".
Refer to Metalink note 39283.1.
In future use Metalink note 153788.1 (Subject: Troubleshoot an ORA-600
Error Using the ORA-600 Argument Lookup Tool).
由于数据库只能在MOUNT状态所以
select * from v$rollname;
select * from undo$;
select * from v$tablespace;都不能使用
1、通过错误信息可以确定当前回滚段是1-10，所以修改PFILE文件将下面这个隐含参数加到文件中去：
._corrupted_rollback_segments='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$','_SYSSMU4$','_SYSSMU5$','_SYSSMU6$','_SYSSMU7$','_SYSSMU8$','_SYSSMU9$','_SYSSMU10$'
STARTUP PFILE='XXXX'
可以看到数据库已经正常启动
2、create undo tablespace undotbs2 datafile 'F:\ORA\ORADATA\GZSB\undotbs2.dbf';
alter system set undo_tablespace=undotbs2;
drop tablespace undotbs2;
3、修改参数文件，变更undo表空间，并取消_corrupted_rollback_segments设置:
*.undo_tablespace='UNDOTBS2'
4、startup pfile='xxxxx'
create spfile from pfile;
shutdown immediate
statup
故障解决，进行全库备份
3. 10201上一个严重的BUG
环境 10201，AIX53
但据ORACLE解释，在任何操作系统版本都有此问题。
现象：监听器启动后，隔一段时间（长短不定），就会出现无法连接： 若是用10201版本的SQLPLUS，则会出现 NO LISTENER。
9207 版本的SQLPLUS，则会出现：没反应，HANG住。
原因：10201 版本上的一个BUG：4518443。其会自动创建一个子监听器，当出现此情况时，监听器将会挂起。
/opt/oracle/product/10g/network/log/listener.log有如下语句:
WARNING: Subscription for node down event still pending
检查是否真因为此BUG造成此现象：
$ ps -ef | grep tnslsnr
ora10g 8909 1 0 Sep 15 ? 902:44 /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit
ora10g 22685 8909 0 14:19:23 ? 0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales –inherit
正常情况只有一个监听器，而此BUG则会出现两个监听器。
解决方法：打补丁4518443 或者在listener.ora 文件里加入：
SUBSCRIBE_FOR_NODE_DOWN_EVENT_=OFF
其中， 是数据库的监听器的名称。如：默认情况下，监听器名为：LISTENER 。则语句就是：
SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF
重启监听程序:
lsnrctl stop
lncrctl start
4. ORA-01031: insufficient privileges的解决方法
1。检查sqlnet.ora 文件.
sqlnet.ora 文件损坏或格式不对可以导致出现该问题。
sqlnet.ora 文件可能存放路径为
$TNS_ADMIN/sqlnet.ora
如果没有设置$TNS_ADMIN默认在$ORACLE_HOME/network/admin/sqlnet.ora
或
$HOME/sqlnet.ora
(1). 可以从别的机器拷贝一个文件过来，注意备份原来的sqlnet.ora。
---检查sqlnet.ora 文件内容
(2). 检查SQLNET.AUTHENTICATION_SERVICES
如果没有使用dblink.检查该行并设置
SQLNET.AUTHENTICATION_SERVICES = (BEQ,NONE)
(3). SQLNET.CRYPTO_SEED
在unix 下不需要该参数。如果存在该行，注释掉或删掉
(4).AUTOMATIC_IPC
如果该参数为 ON，将强制使用"TWO_TASK" 连接
最好设置为OFF
AUTOMATIC_IPC = OFF
2.检查相关文件的权限配置。
找到$TNS_ADMIN/*
$ cd $TNS_ADMIN
$ chmod 644 sqlnet.ora tnsnames.ora listener.ora
$ ls -l sqlnet.ora tnsnames.ora listener.ora
-rw-r--r-- 1 oracle dba 1628 Jul 12 15:25 listener.ora
-rw-r--r-- 1 oracle dba 586 Jun 1 12:07 sqlnet.ora
-rw-r--r-- 1 oracle dba 82274 Jul 12 15:23 tnsnames.ora
3.检查操作系统相关设置。
(1). $ORACLE_HOME环境变量是否设置正确
% cd $ORACLE_HOME
% pwd
如果错误，请重新设置：
sh or ksh: ----------
$ ORACLE_HOME=
$ export ORACLE_HOME
Example:
$ ORACLE_HOME=/u01/app/oracle/product/7.3.3
$ export ORACLE_HOME
csh: ----
% setenv ORACLE_HOME Example:
% setenv ORACLE_HOME /u01/app/oracle/product/7.3.3
另外$ORACLE_HOME路径应为实际路径，不应是目录连接（ln -s)
(2) $ORACLE_SID是否设置正确；
% echo $ORACLE_SID
(3).确信没有设置$TWO_TASK
检查 "TWO_TASK" 是否设置：
sh, ksh or on HP/UX only csh:
-----------------------------------
env |grep -i two
- or -
echo $TWO_TASK
csh:
----
setenv |grep -i two
如果有返回行比如:
TWO_TASK=
- or -
TWO_TASK=PROD
就需要取消着这些环境变量设置 ：
sh or ksh:
----------
unset TWO_TASK
csh:
----
unsetenv TWO_TASK
(4) 检查oracle 文件的权限:
% cd $ORACLE_HOME/bin
% ls -l oracle
权限应为：rwsr-s--x, or 6751.
如果不是：
% chmod 6751 oracle
(5). 检查当前所连接的操作系统用户是否是"osdba" 并且已经定义在：
"$ORACLE_HOME/rdbms/lib/config.s"
or
"$ORACLE_HOME/rdbms/lib/config.c".
通常应为dba
% id uid=1030(oracle) gid=1030(dba)
可以如果"gid" 是 "dba" ， "config.s" or "config.c"
里面应该有: /* 0x0008 15 */ .ascii "dba\0"
如果没有添加目前的操作系统用户到dba 组，或则手工编辑更改config.c并且:%relink oracle
(6).所需要的文件系统是否正确mount
%mount
(7) 目前身份是否是"root" 并且操作系统环境变量 "USER", "USERNAME", and "LOGNAME" 没有设置成"root".
root用户是特例,除非当前组是dba 组,否则不能connect internal.
把root用户当前组改为dba组：
# newgrp dba
-----最好不要以root管理数据库;
(8).检查"/etc/group" :
是否存在重复行
% grep dba /etc/group
dba::1010:
dba::1100:
如果有，删掉没有用的。
(9).确信停掉的instance没有占用内存资源
比如：ipcs -b
T ID KEY MODE OWNER GROUP SEGSZ
Shared Memory:
m 0 0x50000ffe --rw-r--r-- root root 68
m 1601 0x0eedcdb8 --rw-r----- oracle dba 4530176
可以看到1601 被oracle 使用，删掉.
-------注意是否启动了多个instance
% ipcrm -m 1601
(10).如果同时还有ora-12705 错误检查一下环境变量：
"ORA_NLS", "ORA_NLS32", "ORA_NLS33" ，"NLS_LANG".
(11).检查 "ORACLE_HOME" and "LD_LIBRARY_PATH 环境变量：
$ LD_LIBRARY_PATH=$ORACLE_HOME/lib
$ export LD_LIBRARY_PATH
$ ORACLE_HOME=/u01/app/oracle/product/8.0.4
$ export ORACLE_HOME
(12).当前的instance 所再的磁盘是否有足够的磁盘空间
df -k
(13).用户对/etc/passwd 是否有读权限。
(14).如果使用mts 方式，确信你的连接使用dedicade server 方式。
(15).安装ORACLE所需操作系统补丁是否打全。ORACLE 是否已经补丁到最新
