1. ORA-00257sqlplus /nologSQL*Plus: Release 10.2.0.1.0 – Production on 星期二 7月 25 10:44:18 2006Copyright (c) 1982, 20
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\GZS本文来源gaodaima#com搞(代@码$网6B\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 start4. 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 tablespaceAction: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 tablespaceAction: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
