oracle错误及解决方案
1、listener does not currently know of service requested in connect descriptor TNS:listener does not currently know of service requested in connect descriptor
解决方法如下
打开C:\oracle\product\10.1.0\Db_1\NETWORK\ADMIN 文件夹下的listener.ora文件里面代码如下，把红色(/**/中间的代码)部分代码加上
重启Listener服务。即可。
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\oracle\product\10.1.0\Db_1)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = orcl)
(ORACLE_HOME = c:\oracle\product\10.1.0\Db_1)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
)
)
)
另外一种方式
先启动数据库，然后你在CMD命令行中输入：sqlplus / as sysdba
进去后执行：alter system register;
然后再用pl/sql登录试试。
当遇到ORACLE出现下面提示时：
ora-01034:oracle not available
ora-27101:shared mermory realm does not exist
可以这样解决；
方法1：
1.输入：connect/as sysdba;
2.重起计算机就OK了；
方法2：
在命令行中输入
C:\>svrmgrl
Oracle Server Manager Release 3.1.7.0.0 - Production
Copyright (c) 2000, Oracle Corporation. All Rights Reserved.
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production
SVRMGR> connect internal/oracle
连接成功。
SVRMGR> startup
startup后再连接数据库应该没有问题了。
3、TNS-12500 TNS:listener failed to start a dedicated server process 方法(自己的解决方案)：
点击 net manager，添加服务器时选择Oracle8i或更高版本服务器名时需要填ORCL
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空间有多少：
如果多余的空间比较多，就可以适当追加一个大的回滚段给表空间使用，从而避免上述的错误。你也可以用以下语句来检测一下rollback segment的竞争状况：
和
如果任何一个class in count/sum(value)大于1%，就应该考虑增加rollback segment。
ORA-01652:unable to extend temp segment by num in tablespace name
产生原因：ORACLE临时段表空间不足，因为ORACLE总是尽量分配连续空间，一但没有足够的可分配空间或者分配不连续就会出现上述的现象。
解决方法：我们知道由于ORACLE将表空间作为逻辑结构-单元，而表空间的物理结构是数据文件，数据文件在磁盘上物理地创建，表空间的所有对象也存在于磁盘上，为了给表空间增加空间，就必须增加数据文件。先查看一下指定表空间的可用空间，使用视图SYS.DBA_FREE_SPACE，视图中每条记录代表可用空间的碎片大小：
返回的信息可初步确定可用空间的最大块，看一下它是否小于错误信息中提到的尺寸，再查看一下缺省的表空间参数：
通过下面的SQL命令修改临时段表空间的缺省存储值：
SQL>ALTER TABLESPACE name DEFAULT STORAGE (INITIAL XXX NEXT YYY);
适当增大缺省值的大小有可能解决出现的错误问题，也可以通过修改用户的临时表空间大小来解决这个问题：
SQL>ALTER USER username TEMPORARY TABLESPACE
new_tablespace_name;
使用ALTER 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>Analyze table validate structure cascade;
执行该命令后，可能会出现以下的结果：
ORA-01578：与原先错误信息有相同的参数，为永久性的物理或逻辑坏块；与原先错误信息有不同的参数，可能与内存，page space和I/O设备有关。
如果用户有此表的最新备份，那么最好是用此备份来恢复此表，或者使用event 10231来取出坏块以外的数据：
<1>.先关闭数据库
<2>.编辑init.ora文件，加入：
<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方法来取出坏块以外的数据的方法，这里就不介绍了。
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-00600:internal error code,arguments:[num],[?],[?],[?],[?]
产生原因：这种错误通常为ORACLE的内部错误，只对OSS和ORACLE开发有用。ORA-600的错误经常伴随跟踪文件的状态转储（系统状态和进程状态），系统状态存储将包括ORACLE RDBMS持有的当前对象的信息，进程状态转储则将显示特殊进程持有的对象，当进程符合了某错误条件时，经常是由于一些信息取自它持有的一个块，如果我们知道这些错误进程持有的块，就容易跟踪问题的来源。
解决方法：一般来说出现这个错误我们本身是无法解决的，只有从提高系统本身各方面来解决这个内部问题，如增加硬件设备，调整系统性能，使用OPS（当然OPS从某种意义上说并不是一种好的解决方式）等。ORA-600错误的第一个变量用于标记代码中错误的位置（代码中的每个部分的第一变量都不一样），从第二个到第五个变量显示附加信息，告诉OSS代码在哪里出现了错误。
一个报错例子如下：
ORA-03113：end-of-file on communication channel
产生原因：通讯不正常结束，从而导致通讯通道终止
解决方法：
1>.检查是否有服进程不正常死机，可从alert.log得知
2>.检查sql*Net Driver是否连接到ORACLE可执行程序
3>.检查服务器网络是否正常，如网络不通或不稳定等
4>.检查同一个网上是否有两个同样名字的节点
5>.检查同一个网上是否有重复的IP地址
ORA-00942:table or view does not exist
产生原因：这是由于装载的表或视图不存在，多半是CATEXP.SQL还没有运行，无法执行Export视图,如果CATEXP.SQL已经运行，则可能是版本错误。
解决方法：因为Import和Export共享的一些视图是通过运行CATEXP.SQL来装载的（它们具有相同的视图），并不生成单独的CATEXP.SQL，因而造成视图与Export代码不同步，较难保持彼此之间的兼容，用户就必须建立自己的Export应用，从而避免ORA-00942的错误。
上述错误均为我们在使用回滚段时比较常见的问题，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 https://www.sodocs.net/doc/0c4563393.html, partition NAME by NUM in tablespace NAME
产生原因：指定的tablespace空间已经被占用满，无法扩展。
解决方法：使用“ALTER TABLESPACE ADD DATAFILE”命令增加文件系统文件和原始分区，或者增加INITIAL的大小（如：alter tablespace CDRS101 default storage(next 500M pctincrease 1)）应该能够解决，否则就是有人使用你的表空间上创建了一个比较大的数据文件导致你的表空间不够用。
一个报错例子如下：
1、ORA-12541：TNS：没有监听器
原因：没有启动监听器或者监听器损坏。如果是前者，使用命令net start OracleOraHome81TNSListener（名字可能有出入）即可；如果是后者，则使用“Net8 Configuration Assistant”工具向导之“监听程序配置”增加一个监听器即可（基本不用写任何信息，一路OK.在添加之前可能需要把所有的监听器先删除！）
2、ORA-12500：TNS：监听程序无法启动专用服务器进程或ORA-12560：TNS：协议适配器错误
原因：Oracle的数据库服务没有启动。使用命令net start ORACLESERVICEORADB （ORADB为数据库名字）即可。
3、数据库服务启动失败，则很有可能是其注册表项值损坏，最好的做法是以下两步：
1）ORADIM -DELETE -SID oradb 删除数据库服务项
2）ORADIM -NEW -SID oradb 新增数据库服务项
注：这个过程中如果出错，就重启计算机！
4、ORA-12154：TNS：能解析服务名
原因：ORACLE的网络服务名没有正确配置。请使用“Net8 Configuration Assistant”工具向导之“本地网络服务名配置”配置TNS即可。如果仍没有解决，请继续向下看。
5、ORA-1034 ：TNS：Oracle不可用
原因：Oracle的数据库服务正确启动，但是数据库没有打开！
解决：
使用命令：
1）svrmgrl 启动服务管理器
2）connect internal 以internal身份登陆
3）startup 打开数据库
6、ORA-12560：TNS：协议适配器错误（顽固性的）
原因：未知。
解决：必杀技——打开“Windows任务管理器”，杀死Oracle.exe及ORADIM.exe进程，书写自己的ora_startup.bat，执行之！
PS：
1、我的ora_startup.bat：
net start OracleOraHome81TNSListener
net start ORACLESERVICEORADB
svrmgrl 一般情况下不用，不过有时少不了它的，具体步骤见第5步。
2、我的ora_shutdown.bat：
net stop OracleOraHome81TNSListener
net stop ORACLESERVICEORADB
3、ORACLE相关服务名请参见“管理工具”之“服务”中以ORACLE开头的服务名。
以下是删除服务项的一些办法做参考，从中不难发现你看不到相关服务项的原因。
方法一：
1. 运行regedit。
2. 选择HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices。
3. 选中需要删除的SERVICE，将其删除重新启动后就可以了该文章转载自[编程助理站]：
https://www.sodocs.net/doc/0c4563393.html,/bbs/bbs_msg.asp?id=271
方法二：
1、开始－＞设置－＞控制面板－＞管理工具－＞服务停止所有Oracle服务。
2、开始－＞程序－＞Oracle - OraHome81－＞Oracle Installation Products－＞Universal Installer 卸装所有Oracle产品，但Universal Installer本身不能被删除。
3、运行regedit，选择HKEY_LOCAL_MACHINESOFTWAREORACLE，按del键删除这个入口。
4、运行regedit，选择HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices，滚动这个列表，删除所有Oracle入口。
5、运行regedit，
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogApplication，删除所有Oracle入口。
6、开始－＞设置－＞控制面板－＞系统－＞高级－＞环境变量删除环境变量CLASSPATH和PATH中有关Oracle的设定。
7、从桌面上、STARTUP（启动）组、程序菜单中，删除所有有关Oracle的组和图标。
8、删除Program FilesOracle目录。
9、重新启动计算机，重起后才能完全删除Oracle所在目录。
10、删除与Oracle有关的文件，选择Oracle所在的缺省目录C:Oracle，删除这个入口目录及所有子目录，并从Windows 2000目录（一般为C:WINNT）下删除以下文件ORACLE.INI、oradim73.INI、oradim80.INI、oraodbc.ini等等。
11、WIN.INI文件中若有[ORACLE]的标记段，删除该段。
12、如有必要，删除所有Oracle相关的ODBC的DSN。
13、到事件查看器中，删除Oracle相关的日志。
说明：到现在为止，你还是可以发现在服务里面还有oracle的服务存在，必须把他删除，否则你再安装oracle时就会出现什么服务已经存在的错误提示了！！而这些服务是在HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumRoot下以
LEGACY_ORACLE打头的，而且你选种按delete删除时系统会提示你一个错误！！不让你删除！现提供具体删除方法，win2000的如下：
运行regedt32注意了，不是regedit！在HKEY_LOCAL_MACHINE那页找到
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumRoot先选中ROOT然后点菜单上的安全-权限把自己添加到里面，并且权限设置为完全控制，确定后再删除ROOT下所有LEGACY_ORACLE打头的键，同样的方法也可以把
HKEY_LOCAL_MACHINESYSTEMControlSet001和
HKEY_LOCAL_MACHINESYSTEMControlSet002两个下面EnumRoot下所有
LEGACY_ORACLE打头的键删除，重新启动计算机可以发现，服务里面的那些都没有了！！在winXP中就比较简单了，还是运行regedit，找到LEGACY_ORACLE打头的键后右击，选择权限，同样将everyone设置为完全控制就可以删除了！删除后重新启动一下就可以了！！如果有个别DLL文件无法删除的情况，则不用理会，重新启动，开始新的安装，安装时，选择一个新的目录，则，安装完毕并重新启动后，老的目录及文件就可以删除掉了。
「编辑推荐」
在Oracle的连接视图上进行数据更新操作
给Oracle进行健康体检
使用环境变量配置Oracle运行环境
7．ORA-00911:无效字符
原因：多一个分号；
今天在开发中遇到了一个问题，被困扰了好找时间。事情是这样的，
因为我们现在做的系统数据库是用oracle,而我又喜欢凡是和数据库
有关的语句先在pl/sql developer里面测试好了，再往程序里面写。而今天做的代码里
面涉及到查询库里面现在有没有用户输入的表所对应的同义词。所以我便写了这样的一条语句：
string.format(select * from user_synonyms where
upper(synonym_name)='{0}' and upper(table_name)='{0}';", this.txtSourceTableName.Text.ToUpper());谁知在调试的时候走到这个地方就报“ORA-00911: 无效字符”的错误。
可是我明明在pl/sql developer里面测试好了的。困惑了好一会，才发现是最后面的那个“；”号惹的祸。
把它删除掉就行了。
Oracle数据库接口对书写格式要求非常严格，有时候即使多加一个空格，多加一个逗号，分号，回车等都不行，这就需要你来试着调整书写了！
ORA-00261错误及解决方法
在DataGuard环境中如果我们在做failover的时候，可能会碰到ORA-00261错误，下面是该错误的产生原因和解决方法。
如果是由于网络问题而导致需要切换，那么通常standby端的RFS进程并不会意识到primary已经不可访问，所以RFS进程也不会释放当前的standby redo log文件。
如果是primary端的数据库实例由于故障中断，那么一般情况下standby端的RFS进程会立刻意识到primary已经不可访问，也就会立刻释放当前的standby redo log文件。
只要RFS进程没有释放standby redo log文件，那么执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH命令就会在alertlog文件中发现如下的报错信息
Warning: log 4 of thread 1 is being archived or modified
Recovery interrupted.
Media Recovery failed with error 261
如果在报上述错误的时候，执行SWITCH，那么将会出现下面的错误：
ORA-16139: media recovery required
所以必须检查alertlog文件，直到发现如下信息才表示RFS进程已经释放了standby redo log文件，这时候才可以作FINISH：
RFS: Possible network disconnect with primary database
促使RFS进程释放standby redo log 文件有两种方法：
1．等待RFS进程的network timeout，通常需要等待8分钟左右
2．关闭standby数据库，再重新开启，这样会强制RFS进程释放standby redo log
我们可以通过v$managed_standby视图来监控RFS进程何时释放
实行Failover：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
alertlog中将显示如下信息，表示finish成功：
Terminal Incomplete Recovery: UNTIL CHANGE 3738452
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 8772 TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0 Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 8772 redo required
Terminal Incomplete Recovery: End-Of-Redo log
/global/oradata/ctsdb/stdby_redo04.log
Identified end-of-REDO for thread 1 sequence 8772
Terminal Incomplete Recovery: end checkpoint SCN 3738453
Media Recovery Complete
Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Wed Sep 1 13:42:28 2004
ARC1: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC1: Beginning to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Unable to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
Creating archive destination LOG_ARCHIVE_DEST_1:
'/global/oradata/ctsdb/archive/arch1_8772.log'
Wed Sep 1 13:42:28 2004
Log actively being archived by another process
Wed Sep 1 13:42:28 2004
ARC1: Completed archiving log 4 thread 1 sequence 8772
Wed Sep 1 13:42:43 2004
End: All standby logfiles have been archived
Resetting standby activation ID 4038461969 (0xf0b60a11)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
FINSH成功之后再执行SWITCH：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SWITCH成功之后，重新启动数据库：
SHUTDOWN IMMEDIATE;
START UP;
ora-04031错误解决方法及详细分析
当我们在共享池中试图分配大片的连续内存失败的时候，Oracle首先刷新池中当前没使用的所有对象，使空闲内存块合并。如果仍然没有足够大单个的大块内存满足请求,就会产生ORA-04031 错误。
每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-xxxx)。有些错误由于频繁出现、原因复杂而被DBA们戏称之为"经典的错误"。其中ORA-3113 "end of fileon communication channel" 就是这样的一个.
我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断。不过，导致这个错误的原因实际上有很多种,对数据库设置不当、任何能导致数据库后台进程崩溃的行为都可能产生这个错误.这个错误的出现还经常伴随着其它错误,比如说：
ORA-1034 ORACLE not available。ora-01034错误解决方法及详细分析
此外,该错误出现的场景复杂,可能出现在：
启动的Oracle的时侯;
试图创建数据库的时侯;
试图对数据库进行连接的时侯;
在客户端正在运行SQL/PL/SQL的时侯;
备份/恢复数据库的时侯;
其它一些情况下．．．．．．
在论坛上也时常可以看到初级DBA对这个问题的求救. 在这里简单的对该问题进行一下整理.不当之处,请多指教！
错误原因种种
根据网络上大家反映的情况来看,错误原因大约有这些：
Unix核心参数设置不当
Oracle执行文件权限不正确／环境变量问题
客户端通信不能正确处理
数据库服务器崩溃/操作系统崩溃/进程被kill
Oracle 内部错误
特定SQL、PL/SQL引起的错误
空间不够
防火墙的问题
其它原因
在开始解决问题之前,作如下几件事情：
回忆一下在出现错误之前你都做了什么操作,越详细越好;查看background_dump_dest目录中的alertSID.log文件也是你要做的事情;Google一下,在互联网上有很多信息等着你去发现,不要什么都问别人.当然, 如果你找到了一些对你更有帮助的东西――这篇文档就不用看了:)
Unix核心参数设置不当/ init参数设置不当
如果数据库在安装过程中没有设定正确的操作系统核心变量,可能在安装数据库文件的时侯没甚么问题,在创建数据库的时侯常常会出现03113错误.和此有关的另一个原因是init.ora参数文件中的processes参数指定了不合理的值,启动数据库导致错误出现(当然这个
归根到底也是核心参数的问题).
这个错误信息一般如下：
ORA-03113: end-of-file on communication channel
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
解决办法有两个：
1修改核心参数,加大相应核心参数的值(推荐);
2减小init.ora参数的Processes的值.
需要注意的是：
SEMMSL必须设定为至少要10 +进程数的最大值.
SEMMNS 也依赖于每个数据库上的进程参数值.
-------------------------------------------------------------------------------
注：
这个错误类型只在Unix平台上出现.在Windows上如果processes的值过大,则会出现：
ORA-00068: invalid value 24200001 for parameter max_rollback_segments, must be
between 2 and 65535
/* 此时指定的参数值超过了65535 */
或者
ORA-27102: out of memory
/* 小于65535的一个大参数值*/
我的软件环境：
Windows 2000 Version 5.0 Service Pack 3, CPU type 586
ORACLE RDBMS Version: 8.1.7.0.0.
-------------------------------------------------------------------------------
在特定平台上更改核心参数可能会有差别,请参考Oracle Technet(https://www.sodocs.net/doc/0c4563393.html,)上的安装文档.对特定Unix平台的安装文档也有对核心参数意义的解释.
Init.ora中的参数如果设置不当,会产生该错误.有经验表明：shared_pool_size设置过小会出现错误,此外timed_statistics=true的设置也会带来问题.
Oracle执行文件权限不正确/环境变量问题
这个问题只出现在Unix平台上.常见情况是有的时侯管理员为了方便而使用Unix的tar 命令处理过的压缩包进行的安装,或者是系统管理员指定了额外的OS用户也可以管理数据库却没有指定正确的环境变量.
Oracle执行文件在$ORACLE_HOME/bin目录下,如果出现问题,应该用如下Unix类似命令来纠正：
chmod 7755 $ORACLE_HOME/bin/oracle
有的时侯要对Oracle进行relink操作.
在Unix上通过cp拷贝安装的时候,常常会出现环境变量的问题,和个别执行程序连接问题.LD_LIBRARY_PA TH如果设置的不正确会导致问题,在这种情况下,需要对Oracle进行relink.如果可执行文件oralcle被破坏,也要对其relink.
如果安装了并行服务器选项而Distributed Lock Manager没有安装或正确运行也会导致