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 是否已经补丁到最新
ORA-01650:unable to extend rollback segment NAME by NUM intablespace NAME 产生原因：上述ORACLE错误为回滚段表空间不足引起的，这也是ORACLE数据管理员最常见的ORACLE错误信息。当用户
在做一个非常庞大的数据操作导致现有回滚段的不足，使可分配用的回滚段表空间已满，无法再进行分配，就会出现上述
的错误。
解决方式：使用“ALTER TABLESPACE tablespace_name ADD DATAFILE filename SIZE size_of_file”命令向指定的
数据增加表空间，根据具体的情况可以增加一个或多个表空间。当然这与还与你主机上的裸盘设备有关，如果你主机的裸
盘设备已经没有多余的使用空间，建议你不要轻意的增加回滚段表空间的大小，可使用下列的语句先查询一下剩余的
tablespace空间有多少：
Select user_name,sql_text from V$open_cursor where user_name=’’;
如果多余的空间比较多，就可以适当追加一个大的回滚段给表空间使用，从而避免上述的错误。你也可以用以下语句
来检测一下rollback segment的竞争状况：
Select class,count from V$waitstat where calss in(‘system undo header’,’system undo block’,’undo
header’,’undo block’);和
Select sum(value) from V$sysstat where name in (‘db_block_gets’,’consistents gets’);
如果任何一个class in count/sum(value)大于1%，就应该考虑增加rollback segment。
相应的英文如下：
Cause:Failed to allocate extent from the rollback segment in tablespace
Action:Use the ALTER TABLESPACE ADD DATAFILE statement to add one or more files to the specified
tablespace.
ORA-01652:unable to extend temp segment by num in tablespace name
产生原因：ORACLE临时段表空间不足，因为ORACLE总是尽量分配连续空间，一但没有足够的可分配空间或者分配不连
续就会出现上述的现象。
解决方法：我们知道由于ORACLE将表空间作为逻辑结构-单元，而表空间的物理结构是数据文件，数据文件在磁盘上物
理地创建，表空间的所有对象也存在于磁盘上，为了给表空间增加空间，就必须增加数据文件。先查看一下指定表空间的
可用空间，使用视图SYS.DBA_FREE_SPACE，视图中每条记录代表可用空间的碎片大小：
SQL>Select file_id,block_id,blocks,bytes from sys.dba_free_space where tablespace_name=’’;
返回的信息可初步确定可用空间的最大块，看一下它是否小于错误信息中提到的尺寸，再查看一下缺省的表空间参
数：
SQL>SELECT INITIAL_EXTENT,NEXT_EXTENT,MIN_EXTENTS,PCT_INCREASE FROM SYS.DBA_TABLESPACES WHERE
TABLESPACE_NAME=name;
通过下面的SQL命令修改临时段表空间的缺省存储值：
SQL>ALTER TABLESPACE name DEFAULT STORAGE (INITIAL XXX NEXT YYY);
适当增大缺省值的大小有可能解决出现的错误问题，也可以通过修改用户的临时表空间大小来解决这个问题：
SQL>ALTER USER username TEMPORARY TABLESPACE new_tablespace_name;
使用ALTER TABLESPACE命令，一但完成，所增加的空间就可使用，无需退出数据库或使表空间脱机，但要注意，一旦添加
了数据文件，就不能再删除它，若要删除，就要删除表空间。
一个报错例子如下：
ORA-1652:unable to extend temp segment by 207381 in tablespace TEMPSPACE
相应的英文如下：
Cause: Failed to allocate extent for temp segment in tablespace
Action:Use the ALTER TABLESPACE ADD DATAFILE statement to add one or more files to the specified
tablespace or create the object in another tablespace.
ORA-01578:Oracle data block corrupted(file # num,block # num)
产生原因：当ORACLE访问一个数据块时，由于1、硬件的I/O错误；2、操作系统的I/O错误或缓冲问题；3、内存或paging问
题；4、ORACLE试图访问一个未被格式化的系统块失败；5、数据文件部分溢出等上述几种情况的一种引起了逻辑坏块或者
物理坏块，这时就会报ORA-01578的错误。
解决方式：由于ORACLE只有在访问到有问题的数据文件时才会报错，所以报错的时间有可能会比实际出错的时间要晚，如
果ORA-01578出错信息提示数据坏块指向的是用户自己的数据文件，则用以下方法来解决：
如果通过下面的SQL语句查出的坏块出现有索引上，则只需重建索引即可
SQL>Select owner,segment_name,segment_type from dba_extents where file_id= and between block_id and
block_id+blocks-1;(和分别是ORA-01578报出的坏块出现的文件号和块号)
如果坏块出现在表上，先用以下语句分析是否为永久性坏块（建议多执行一两次，有助于鉴别数据坏块是永久性的（硬盘
上的物理坏块）还是随机性的（内存或硬件错误引起））：
SQL>Analyze table
validate structure cascade;执行该命令后，可能会出现以下的结果：
ORA-01578：与原先错误信息有相同的参数，为永久性的物理或逻辑坏块；与原先错误信息有不同的参数，可能与内存，
page space和I/O设备有关。
如果用户有此表的最新备份，那么最好是用此备份来恢复此表，或者使用event 10231来取出坏块以外的数据：
<1>.先关闭数据库
<2>.编辑init.ora文件，加入：
event=”10231 trace name context forever,level 10”
<3>.startup restrict
<4>.创建一个临时表：SQL>create table errortemp as select * from error;(error是坏表的表名)
<5>.把event从init.ora文件中删掉并重起数据库
<6>.rename坏表，把临时表rename成坏表的表名
<7>.创建表上的INDEX等
如果ORA-01578出错信息提示数据坏块指向的是数据字典或者是回滚段的话，你应该立即与ORACLE公司联系，共同商量一个
好的解决办法。
这里所讲的解决方法只是比较常见的一种，一些更为具体的解决办法可以查看一下ORACLE的故障解决手册，那里面有浞及
使用ROWID方法来取出坏块以外的数据的方法，这里就不介绍了。
相应的英文如下：
Cause:The given data block was corrupted,probably due to program errors
Action:Try to restore the segment containing the given data block,This may involve dropping the segment
and recreating it,If there is a trace file,report the messages recorded in it to customer support.
ORA-01628:max # of extents num reached for rollback segment num
产生原因：这种错误通常为一个回滚段和一个表空间已经达到MAXEXTENTS参数设置的极限。要注意的是这个MAXEXTENTS不
是该回滚段或表空间的硬件极限，硬件极限取决于数据库创建时在init.ora文件中指定的DB_BLOCK_SIZE参数的值。
解决方法：使用SQL命令ALTER TABLESPACE…STORAGE（MAXEXTENTS XXXX）来增加 MAXEXTENTS，其中“XXXX”值必须大于
错误信息中所指的数值，但不能大于LARGEST MAXEXTENT的值，如果已经达到了LARGEST MAXEXTENT VALUE，解决的办法就
是重新创建较大的范围尺寸，使用带有选项COMPRESS=Y的Export工具导出表，如果表空间有可用空间，先给表做一个备
份，用alter tablespace tablespace_name更改其名字，然后再装载表回数据库。
查看其错误出现的地方，如果出现在回滚段或索引上，那么必须将其删除并重建，如果出现在临时表空间，修改临时表空
间的存储字段，便可解决这个问题。
一个报错例子如下：
ORA-1628:max # extents 50 reached for rollback segment RBS_1
相应的英文如下：
Cause: An attempt was made to extend a rollback segment that already has reached its maximum size or space
could not be allocated in the data dictionary to contain the definition of the object.
Action:If possible,increase the value of either the MAXEXTENTS or PCTINCREASE initialization parameters or
find the data dictionary table lacking space and alter the storage parameters,as described in the Oracle8
Server Administrator’s Guide.
ORA-00600:internal error code,arguments:[num],[?],[?],[?],[?]
产生原因：这种错误通常为ORACLE的内部错误，只对OSS和ORACLE开发有用。ORA-600的错误经常伴随跟踪文件的状态转储
（系统状态和进程状态），系统状态存储将包括ORACLE RDBMS持有的当前对象的信息，进程状态转储则将显示特殊进程持
有的对象，当进程符合了某错误条件时，经常是由于一些信息取自它持有的一个块，如果我们知道这些错误进程持有的
块，就容易跟踪问题的来源。
解决方法：一般来说出现这个错误我们本身是无法解决的，只有从提高系统本身各方面来解决这个内部问题，如增加硬件
设备，调整系统性能，使用OPS（当然OPS从某种意义上说并不是一种好的解决方式）等。ORA-600错误的第一个变量用于标
记代码中错误的位置（代码中的每个部分的第一变量都不一样），从第二个到第五个变量显示附加信息，告诉OSS代码在哪
里出现了错误。
一个报错例子如下：
ORA-00600: internal error code, arguments: [1237], [], [], [], [], [], [], []
相应的英文如下：
Cause:This is a catchall internal error message for Oracle program exceptions.It indicates that a process
has met a low-level,unexpected condition.Various causes of this message include:
Time-outs（超时）
File corruption(文件太老)
Failed data checks in memory（内存检索失败）
Hardware,memory,or I/O errors（硬件、内存或者磁盘错误）
Incorrectly restored files（错误的重建文件）
ORA-03113：end-of-file on communication channel
产生原因：通讯不正常结束，从而导致通讯通道终止
解决方法：1>.检查是否有服进程不正常死机，可从alert.log得知
2>.检查sql*Net Driver是否连接到ORACLE可执行程序
3>.检查服务器网络是否正常，如网络不通或不稳定等
4>.检查同一个网上是否有两个同样名字的节点
5>.检查同一个网上是否有重复的IP地址
相应的英文如下：
Cause:An unexpected end-of-file was processed on the communication channel.The problem could not be
handled by the Net8,two task,software.This message could occur if the shadow two-task process associated
with a Net8 connect has terminated abnormally,or if there is a physical failure of the interprocess
communication vehicle,that is,the network or server machine went down.
Action:If this message occurs during a commection attempt,check the setup files for the appropriate Net8
driver and confirm Net8 software is correctly installed on the server.If the message occurs after a
connection is well established,and the error is not due to a physical failure,check if a trace file was
generated on the server at failure time.Existence of a trace file may suggest an Oracle internal error
that requires the assistance of customer support.
ORA-00942:table or view does not exist
产生原因：这是由于装载的表或视图不存在，多半是CATEXP.SQL还没有运行，无法执行Export视图,如果CATEXP.SQL已经运
行，则可能是版本错误。
解决方法：因为Import和Export共享的一些视图是通过运行CATEXP.SQL来装载的（它们具有相同的视图），并不生成单独
的CATEXP.SQL，因而造成视图与Export代码不同步，较难保持彼此之间的兼容，用户就必须建立自己的Export应用，从而
避免ORA-00942的错误。
相应的英文如下：
Cause:The table or view entered does not exist,a synonym that is jnot allowed here was used,or a view was
referenced where a table is required.Existing user tables and views can be listed by querying the data
dictionary.Certain privileges may required to access the table.If an application returned this message,the
table the application tried to access does not exist in the database,or the application does not have
access to it.
Action:Check each of the following:
The spelling of the table or view name.
That a view is not specified where a table is required
That an existing table or view name exists.
Contact the database administrator if the table needs to be created or if user or application priviledes
are required to access the table.
Also, if attempting to access a table or view in another schema,make certain thecorrect schema is
referenced and that access to the object is granted.
ORA-01598:rollback segment “name” is not online
Cause:The rollback segment was taken offline either manually or by SMON.
Action:Check the status of the rollback segment in DBA_ROLLBACK_SEGS.
ORA-1636: rollback segment “name” is already online
Cause:A rollback segment can only be used by one instance and an instance is trying to bring a rollback
segment online that is already in use.
Action:Check that the values set in the initialization parameter file for parameters
ROLLBACK_SEGMENTS,ROLLBACK_SEGMENT_INITIAL,and ROLLBACK_SEGMENT_COUNT are correctly set for the instance
whiththe problem,Also check that the instance is using the correct initialization parameter file.Make sure
you are not confused about the difference between private and public rollback segments.See the Oracle8
Server Administrator’s Guide for more information about using rollback segments in paraller mode.
上述错误均为我们在使用回滚段时比较常见的问题，ORA-01598指明当前使用的回滚段的状态为“not online”，不能使
用，将它改为“online”状态即可使用；ORA-01636指明当前回滚段已经为“online”状态，可以直接使用，不用再集合
它。
ORA-1636 signalled during: alter rollback segment rb00 online
我们在做统计时还可能遇到下述问题：一个rollback segment的状态为”Needs Recovery”的现象，这是由于ORACLE回退
一个事物表中的没有提交的事物时失败所造成的。通常原因为一个datafile或者tablespace是在offline的状态或者一个
undo的目标被破坏或者rollback segment被破坏。解决的办法是将所有的tablespace和datafile都置为online状态，如果
不能解决则做下面的工作：1>.在initsid.ora中加入event=”10015 trace name context forever lever
10”;2>.shutdown数据库然后重启；3>.在$ORACLE_HOME/rdbms/log下，找到startup时生成的trace file;4>.在trace文件
中，找到下列信息“error recovery tx(#,#) object #”;5>.根据object#(与sys.dba_objects表中的object_id相同)在
sys.dba_objects表中查出该object的名字；6>.将该object drop掉;7>.在init.ora文件中将该rollback segment放回
rollback_segments参数中，删除event;8>.shutdown数据库然后重启。此时”Needs Recovery”的问题应该是完全解决
了，否则就是rollback segment被破坏了。
ORA-01688:unable to extend table name.name partition NAME by NUM in tablespace NAME
产生原因：指定的tablespace空间已经被占用满，无法扩展。
解决方法：使用“ALTER TABLESPACE ADD DATAFILE”命令增加文件系统文件和原始分区，或者增加INITIAL的大小（如：
alter tablespace CDRS101 default storage(next 500M pctincrease 1)）应该能够解决，否则就是有人使用你的表空间
上创建了一个比较大的数据文件导致你的表空间不够用。
一个报错例子如下：
ORA-1688: unable to extend table RMMCDR.LOCAL_CDR partition LOCAL_CDR101 by 460800 in tablespace CDRS101
相应的英文如下：
Cause:An extent could not be allocated for a table segment in tablespace
Action:Use the ALTER TABLESPACE ADD DATAFILE statement to add one or more files to the specified tablespace
