admin 管理员组文章数量: 887021
2024年2月26日发(作者:数组长度为变量)
第一楼 目 录
故障分类一 数据库挂起故障
1 由于ARCHIVE挂起导致数据库挂死
2 NIT文件中SGA区设置太大,导致内存不够用,数据库和系统都挂死
3 由于临时表空间无法扩展导致数据库被挂起
4由于未打补丁导致RMAN备份时将数据库挂起
故障分类二 数据库功能/性能异常
5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差
6由于未对特大表(达到或超过100万条记录)定期做表分析导致数据库操作特别慢
7由于空间不够导致插入数据时扩展索引失败
8由于REDOLOG破坏导致数据库异常
9由于控制文件被破坏导致数据库无法正常启动
10由于数据文件丢失或破坏导致数据库无法正常启动
11由于空间参数设置不合理导致扩展表空间、索引等失败
12由于时间格式的环境变量设置问题导致话单无法入库
13由于大事务未使用大回滚段导致事务挂起
14由于数据库连接数太多导致服务器进程数多或内存耗尽
15由于使用了MTS方式,导致数据库操作特别慢(包括备份)
16由于存在一个大事务操作,导致数据库性能特别差或产生频繁日志切换
17由于没有COMMIT,导致数据库表被锁住
18索引创建不合理,导致数据库查询特别慢
19 由于BUFFER参数设置不合理导致EXP失败
20由于EXP不向上兼容,语言不兼容,导致不同版本、不同字符集的数据库无法导入
21 由于创建表空间时误将其创建在以‘本地管理’,导致在表空间上的所有对象无法修改其存储参数
22 错误地在系统表空间上建无关的数据文件
23 ORACLE客户端在P4上安装不成功
24由于或配置问题导致网络问题
25由于环境变量设置问题导致VERSOIN版本启动问题
26用户数据、表破坏下的数据恢复
27 由于OS层问题导致数据库ORA-600错误
故障分类三 将导致数据库安装失败或打补丁失败的情况
28 由于环境变量或没有安装MAKE文件导致数据库安装失败
29 由于/TMP等文件系统设置太小导致数据库无法正常安装
30 HPUX上由于核心参数设置不对导致数据库无法正常启动
31 在64位的ORACLE817上打32的补丁失败
32由于安装备机数据库时是使用的拷贝方式,所以导致在备机上安装补丁失败
33由于安装ORACLE时错误地在$ORACLE_HOME目录下创建LINK,导致将打过补丁后的版本拷贝到备机失败
34 ORACLE下的字符集问题
第二楼
第一种 数据库挂起故障
1 由于archive挂起导致数据库挂死
故障现象:
数据库挂起,sqlplus无法登录,alert_中有如下信息报出:
Sat Jul 13 21:48:01 2002
ARC0: Beginning to archive log# 1 seq# 61
Current log# 2 seq# 62 mem# 0: /zxindata/oracle/redolog/redo0log
ARC0: Error 19504 creating archivelog file '/zxindata/zxinbak/arch/1_'
ARC0: Archiving not possible: error count exceeded
ARC0: Failed to archive log# 1 seq# 61
ARCH: Archival stopped, error occurred. Will continue retrying
Sat Jul 13 21:48:01 2002
ORACLE Instance zxin - Archival Error
ARCH: Connecting to
Sat Jul 13 21:48:01 2002
ORA-16014: log 1 sequence# 61 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/'
ARCH: Connecting to
ARCH:
ORA-16014: log 1 sequence# 61 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/'
Sat Jul 13 21:50:37 2002
ARC0: Beginning to archive log# 1 seq# 61
ARC0: Archiving not possible: No primary destinations
ARC0: Failed to archive log# 1 seq# 61
故障原因:
一般是archive所在的文件系统满或无操作权限引起的。
故障解决:
检查/zxindata/zxinbak文件系统,是否已经达到或接近100%,另外确定其对oracle 用户有可写权限。
如果文件系统已经满,请执行
手工删除/zxindata/zxinbak/arch下的arch文件
使用sqlplus /nolog登录,执行:
SQL> alter system archive log start;
进一步检查/zxindata/zxinbak文件系统为什么满:
查zxin10用户下的 oracle任务有没有执行:crontab –l |grep checkpsfs,看是否有... 的返回,如没有,表示定期检查空间是否满的任务没有执行,需要启动该任务
查zxin10用户对/zxindata/zxinbak/arch目录下文件有没有删除权限:ls –l /zxindata/zxinbak/arch
对dba组需要有可读可写权限
查数据库备份任务有没有正常执行:crontab –l如果不存在rman或exp方式的数据库备份,则表示没有执行数据库备份任务,需要加上
是否是/zxindata/zxinbak文件系统太小,不符合备份和呼叫模型下的最小大小配置。
如果文件系统大小不能满足每天产生的arch日志和两个全备份的总空间,则需要扩展/zxindata/zxinbak文件系统,aix下可以直接扩,hpux下则需要将该文件系统umount以后再扩
2 init文件中SGA区设置太大,导致内存不够用,数据库和系统都挂死
故障现象:
操作系统无法使用telnet或ftp登录,数据库挂起,sqlplus无法登录
故障原因:
只能通过维护台登录到主机(很有可能维护台也无法登录),如果可以登录,则在aix上使用lsps
–a 检查paging space是否使用超过50%,hpux下可使用vmstat 看内存是否已经很少。
故障解决:
如不可以登录,则强制关电重起机器以触发主备双机倒换;如果可以登录,则手工以shutdown
abort方式停止数据库引发双机倒换。
然后调整文件中SGA区大小,主要是减少db_block_buffers的配置,如果物理内存小于1G,建议该值配置为:1024*1024/4/4
注意同时调整主备机配置,然后做双机倒换是配置生效。
3 由于临时表空间无法扩展导致数据库被挂起
故障现象:
数据库挂起,sqlplus无法登录,alert_中看:先是zxin_temp临时表空间扩
展失败,数据库异常退出
故障原因:
这是ORACLE817的一个bug,当一个统计任务操作一个大表时,其临时数据使用了zxin_temp临时表空间,而该临时表空间太小自动扩展,扩展受文件系统大小限制和pctincrease参数限制而失败时,将引发数据库挂起。
故障解决:
将oracle817的补丁打到8.1.7.4
手工扩充zxin_temp表空间并增加其所在文件系统大小
检查zxin¬_temp临时表空间的pctincrease的值,需要配置为0
4由于未打补丁导致RMAN备份时将数据库挂起
故障现象:
数据库挂起,sqlplus无法登录。由于原来使用rman备份方式,当这种故障发生时,数据库备份日志:中将有以下信息:
RMAN-03022: compiling command: backup
RMAN-03026: error recovery releasing channel resources
RMAN-08031: released channel: ch1
RMAN-00571: ======================================================
RMAN-00569:========= ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571:====================================================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: backup
RMAN-06003: ORACLE error from target database: RMAN-20242: specification does not match any
archivelog in the recovery catalog
故障原因:
是ORACLE817的一个bug
故障解决:
将补丁打到oracle8.1.7.4就可以了。 另外建议将数据库备份改为exp方式
第三楼
第二种 数据库功能/性能异常
5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差
故障现象:
操作系统CPU占有率很高,数据库操作响应很慢。
故障原因:
这种故障发生时,数据库能登录也能操作,但响应时间很长,从日志中也看不出什么异常。所以只能使用我们定制的oratool工具,先找出CPU占有率高的语句,再进一步分析,当时的情况是,发现version对一个有blob类型的表写很频繁,耗去了大量CPU资源,导致数据库总体性能下降。
故障解决:
a.不建议使用blob类型的表
b.如果非要使用blob类型,则要定期进行数据备份和清理,记录数不能太多
c.对blob类型的表的操作,在记录数多的情况下不能写的太频繁,会占用大量的系统资源
6由于未对特大表(达到或超过100万条记录)定期做表分析导致数据库操作特别慢
故障现象:
执行某个存储过程或执行某个表的数据库操作时,操作系统CPU占有率明显升高,数据库操作响应很慢。
故障原因:
对一个数据量比较大的表(达到或超过100万),经过长期的读写操作后,其索引和数据分布没有及时更新给数据库,导致读时性能下降。
故障解决:
对这种类型的表,需要写任务定期对表做分析,由于分析比较耗时和耗资源,建议在系统闲时做,频率不能太高,如每月执行一次,分析可以使用5%或10%的抽样进行,如:
analyze table table1 sample estimate statistics 5 percent;
7由于空间不够导致插入数据时扩展索引失败
故障现象:
alert_日志将报扩展表空间失败的日志,中有扩展索引失败的记录。
故障原因:
一般是表所在的表空间不够,空间扩展失败的情况造成的。
故障解决:
手工扩展表空间所在的文件系统,扩展表空间
如果是表空间的pctincrease设置的不是0,则将其改为0
必要的时候需要rebuild一下扩展索引失败的索引
8由于redolog破坏导致数据库异常
故障现象:
如果是数据库启动情况下redolog被破坏,则alert_中会报如下错误:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/zxindata/oracle/zxin/redo0log'
ORA-27037: unable to obtain file status
将导致数据库操作异常。sqlplus可以登录
如果是启动时候redolog损坏,将报:
ORA-00313: 无法打开日志组 1 (线程 1) 的成员
ORA-00312: 联机日志 1 线程 1: '/zxindata/oracle/zxin/'
故障原因:
redolog破坏,一般是由于:
人为误删或物理损坏
发生了主备倒换,备机的共享VG信息不全
故障解决:
人为误删或物理损坏
如果未启动数据库,则启动到mount状态,重建日志: (如第1组日志有问题)
alter database drop logfile group 1;
alter database add logfile group 1 '/zxindata/oracle/redolog/' size 250M ;
alter database open;
如果数据库启动着,则查看一下损坏文件是否是活动(active)的日志:
select * from v$log;
如果是激活的,则进行日志切换:alter system switch logfile;
如果不是激活的,则执行重建:
alter database drop logfile group 1;
alter database add logfile group 1 '/zxindata/oracle/redolog/' size 250M ;
发生了主备倒换,备机的共享VG信息不全
将共享VG信息导入到备机,并修改共享文件系统和裸设备属性,使其对oracle用户具有读写权限
9由于控制文件被破坏导致数据库无法正常启动
故障现象:
数据库操作将异常,sqlplus可以登录。
故障原因:
control文件被物理损坏或人为损坏。一般会报:ORA-00210/ ORA-00202/ORA-27041/ORA-27037等错误,所以数据库事务将挂起
故障解决:
a.只要CONTROL_FILE中还有好的control文件,则只要
将其拷贝多份就可以了
b.如果以前做过备份,不能再使用该备份控制文件,因为control
文件和数据文件会不一致。启动时报:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS
选项
SQL> alter database open resetlogs;
ORA-01152: 文件 1 没有从完备的旧备份中恢复
ORA-01110: 数据文件 1: '/zxindata/oracle/zxin/'
c.只要丢失了所有的备份或修改maxlogfiles或修改数据库名等情况则要重新
创建一个control file,方式如下:
startup mount
alter database backup controlfile to trace;
alter database open;
到$udump目录下查看最新的文件中包含两份重建controlfile 的语句,
其一是online logs都完好的情况下进行数据库完全恢复的情况
其二是online logs损坏,则所有的在线日志都将丢失,所有的备份
都将失效。
10由于数据文件丢失或破坏导致数据库无法正常启动
故障现象:
一般会导致操作到与该文件有关的数据都将失败,一般报:ORA-01110/ ORA-01116/ ORA-27041等错误,严重一点的报ORA-03113后数据库异常退出
故障原因:
故障解决:
如果只是将数据文件挪了位置,则只要将其mv到原来的位置即可
如果确实损坏了,建议使用数据库备份进行恢复。具体恢复时,可以尝试使用:手工创建数据文件->自动恢复模式,如果不行,只能使用表空间全部恢复方式了。
11由于空间参数设置不合理导致扩展表空间、索引等失败
故障现象:
数据库表空间或索引扩展失败。
故障原因:
可能是表空间的storage参数设置的不合理引起的。
故障解决:
我们一般要求使用如下storage参数:
STORAGE ( INITIAL 20K NEXT 20K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 )
12由于时间格式的环境变量设置问题导致话单无法入库
故障现象:
在报时间格式问题导致话单插入失败。导致话单既要到bill文件中
故障原因:
跟zxin10用户的NLS_DATE_FORMAT参数设置不正确有关
故障解决:
需要将zxin10用户下.profile文件中NLS_DATE_FORMAT设置为:
NLS_DATE_FORMAT=" HH24:MI:SS"
13由于大事务未使用大回滚段导致事务挂起
故障现象:
大事务运行失败,表现为表空间用满(ORA-01560错误),回滚段扩展到达参数MAXEXTENTS的值(ORA-01628)。
故障原因:
回滚段设置的太小
故障解决:
由于一个事务只能使用一个回滚段来存放它的回滚信息,所以建议给大事务创建专用会滚段
创建时将回滚段表空间设置的大一点;增加MAXEXTENTS的值。
14由于数据库连接数太多导致服务器进程数多或内存耗尽
故障现象:
使用ps –ef检查时有很多oracle进程(包含local关键字),使用内存检查命令看可用内存已经很少。
故障原因:
使用DEDICATED方式连接到数据库的客户端一般在服务器端都对应一个进程,该进程将消耗3~4M的内存空间。 如果客户端连接数比较多,则内存将耗尽,进程数也将达到系统极限或数据库极限。
故障解决:
增加系统的硬件配置,如增加CPU或扩内存
增加系统最大进程数限制,aix和hpux下都有方法设置
增加oracle进程数,在init文件中的processes参数项
15由于使用了MTS方式,导致数据库操作特别慢(包括备份)
故障现象:
使用MTS连接方式的数据库操作将比较慢,尤其是系统资源吃紧的情况下。
故障原因:
智能网前期对smap等客户端的策略是使用MTS(共享进程)解决方案,后发现该方案不可行,主要是该连接方式下的数据库操作性能太差。
故障解决:
共享进程只能支持更多的并发用户访问数据库,但不能提高执行速度, 所以我们商用局中已经取消了这种方式。具体可通过检查中的配置确认。应该不包含任何含mts关键字的配置
16由于存在一个大事务操作,导致数据库性能特别差或产生频繁日志切换
故障现象:
数据库性能下降,观察alert_发现切换日志很频繁
故障原因:
肯定存在一个与呼叫无关的大事务在不停的运行,导致产生大量日志,引起日志切换。
故障解决:
使用oratool工具中的sp_who找出活动sql语句
通过命令找出消耗cpu、IO资源最大的10条语句
查出该语句操作的表的数据量和读写频率,检查是否有应用类逻辑性异常并给予纠正。
17由于没有commit,导致数据库表被锁住
故障现象:
操作某个表的记录时长时间无响应,通过sdf进行的数据库操作则表现为超时,导致sdf进程run
too too long
故障原因:
一般跟该表被锁住有关
故障解决:
使用oratool工具中的sp_lock命令查看该表是否有锁
检查是否在某个SQL语句中对该表进行事务类操作时,没有使用commit,这种情况一般发生在手工通过sqlplus修改数据的场合,sdf不会出现
及时进行commit或rollback,解除表锁,如果不能解除的话,则将与该锁有关的进程强制杀掉。
18索引创建不合理,导致数据库查询特别慢
故障现象:
表现为查询特别慢,如果是通过sdf操作,返回超时或触发:sdf run too too long
故障原因:
有可能是在表的数据量比较大的情况下,该表的索引设置不合理造成的。
故障解决:
请使用explain plan查看其查询计划,看是否使用了全表扫描或不适合的索引,据此调整索引或查询语句。
19 由于buffer参数设置不合理导致exp失败
故障现象:
使用exp导出某个表不成功
故障原因:
跟buffer设置有关
故障解决:
一般要求设置比较大的buffer进行exp备份,但当物理内存不够的情况下,buffer设置要合理,这种情况下,可尝试不设置buffer进行备份
20由于exp不向上兼容,语言不兼容,导致不同版本、不同字符集的数据库无法导入
故障现象:
进行imp导入时报数据格式不正确,数据导入失败
故障原因:
目前了解816/817数据库导出的格式不兼容,但oracle9i可以向下兼容,导出和导入环境的字符集不一致,也不能完成导入,但字符集一致、版本一致的数据库在不同的OS平台上可以互导。
故障解决:
保证数据库版本的一致性,保证字符集的一致。或使用其他工具。
21 由于创建表空间时误将其创建在以‘本地管理’,导致在表空间上的所有对象无法修改其存储参数
故障现象:
无法修改该表空间及在该表空间上创建的所有对象的storage参数。
故障原因:
只有在‘字典中管理’的表空间才可以设置手工设置STORAGE参数
故障解决:
编辑,修改参数compatible=”8.1.0” 修改成compatible=”8.1.6”,
执行:$sqlplus sys/change_on_install
sql>exec dbms_space_pace_Migrate_FROM_Local(‘ZXIN_BILL’);
sql>commit;
sql>exit
c.这样,表空间就从‘本地管理’修改成DMT数据字典管理方式了,然后再手工修改表空间存储参数和对象存储参数即可
22 错误地在系统表空间上建无关的数据文件
故障现象:
系统表空间上存在着无关的数据文件
故障原因:
错误地在系统表空间上建了无关的数据文件
故障解决:
如果是创建在OEM_REPOSITORY表空间上,则可以将该表空间删除后重建,注意不要再包含错建的数据文件
如果是其他系统表空间,可以使用:
alter database datafile ‘.....’ resize to 1M;
命令尽量减少空间浪费。
23 oracle客户端在p4上安装不成功
故障现象:
奔四的机器无法安装oracle8i客户端
故障原因:
oracle8i的一个bug
故障解决:
1、将ORACLE软件拷贝到硬盘。
2、将 硬盘目录文件1.1.7.30/1
的文件改名为
3.从installwin32 目录下运行 文件进行安装。
24由于或配置问题导致网络问题
故障现象:
lsnrctl start启动数据库网络服务不成功;使用tnsping无法ping通数据库服务器;sdf无法登录数据库
故障原因:
或配置不正确
故障解决:
请按如下模板配置:
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522))
(address= (protocol=ipc) (key=extproc))
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = zxin)
(ORACLE_HOME = /home/oracle/oracle81)
(SID_NAME = zxin)
)
(SID_DESC =
(SID_NAME = extzxin)
(ORACLE_HOME = /home/oracle/oracle81)
(PROGRAM = extproc)
)
)
请按如下模板配置:
ZXIN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522))
)
(CONNECT_DATA =
(SERVICE_NAME = zxin)
)
)
zx10_40_57_163=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522))
)
(CONNECT_DATA =
(SERVICE_NAME = zxin)
(SERVER = DEDICATED)
)
)
extproc_connection_data=
(description=
(address=(protocol=ipc)(key=extproc))
(connect_data=
(sid=extzxin)))
25由于环境变量设置问题导致VERSOIN版本启动问题
故障现象:
如果没有正确配置ORACLE环境变量,将导致version启动时sdf进程无法正常启动或无法正常连接数据库
故障原因:
请按要求配置zxin10用户与ORACLE相关的环境变量
故障解决:
请检查$ORACLE_HOME、$ORACLE_BASE、$LIBPATH、$SHLIB_PATH、$LD_LIBRARY_PATH等环境变量是否正确。
26用户数据、表破坏下的数据恢复
故障现象:
某一个用户的所有数据或单个表的数据全部丢失,无法读取相关数据
故障原因:
由于人为误操作或硬件问题导致用户数据或单个表的数据全部丢失
故障解决:
使用imp命令将备份出的数据恢复(注意,只能恢复到备份时间点)
对于单表恢复的命令为:
imp system/manager fromuser=zxin touser= zxin tables=oper_dbuser file=
对于整个用户数据丢失恢复的情况
将该用户删除重建:
drop user zxin CASCADE;
create user zxin defaule tablespace ... temporary tablespace;
然后使用imp导入:
imp system/manager fromuser=zxin touser= zxin file=
27 由于os层问题导致数据库ORA-600错误
故障现象:
启动数据库时报: ORA-600
故障原因:
ORA-600错误一般跟os层的错误有关,比如文件、内存、I/O问题、硬件故障
故障解决:
碰到此类错误,请检查:
所做的操作
目前os层有没有各类报错
解决os层问题后再重试
如果还是不行,只能重装系统,重装数据库
将导致数据库安装失败或打补丁失败的情况
第四楼
第三种 将导致数据库安装失败或打补丁失败的情况
28 由于环境变量或没有安装make文件导致数据库安装失败
故障现象:
安装oracle时进行到link阶段时报:找不到make文件
故障原因:
没有安装包含make文件的软件包
故障解决:
安装包含make文件的软件包后重试。(aix下的软件包为:)
29 由于/tmp等文件系统设置太小导致数据库无法正常安装
:故障现象:
安装oracle时进行到link阶段时,在进行某个模块的make时报错,查看文件系统大小,发现/tmp文件系统已满
故障原因:
/tmp文件系统已满
故障解决:
请安装前保证/tmp文件系统有500M剩余空间
30 HPUX上由于核心参数设置不对导致数据库无法正常启动
故障现象:
oracle安装到Link阶段时报错
故障原因:
hpux上安装oracle数据库时,一定要先调整好核心参数再安装,否则将无法成功安装
故障解决:
按照安装手册调整hpux的核心参数(一般是通过setup脚本做的,无需手工配置,请检查setup是否成功执行并成功修改了核心参数)
31 在64位的oracle817上打32的补丁失败
故障现象:
安装补丁时,在Link阶段报错,通过安装日志检查,发现连接的动态库是32位的
故障原因:
补丁也分oracle817(64位)和oracle817(32位)的,请下载和打补丁时注意一一匹配。
故障解决:
将打补丁前的oracle817备份文件恢复,选择匹配的补丁重新安装。
故障现象:
在备机上使用oracle正常打补丁方式时报版本不对,无法正常打补丁。
故障原因:
由于外面大部分机器备机oracle的安装是通过从主机拷贝的方式完成的,而部分如/etc目录下的文件没有同步到备机,所以导致oracle补丁安装程序读不到相关版本信息,无法完成补丁安装。
故障解决:
可以采取将主机打完补丁后将$ORACLE_HOME目录拷贝到备机的方式
可以将/etc下的oratab和拷贝到备机,再重试补丁安装
33由于安装oracle时错误地在$ORACLE_HOME目录下创建link,导致将打过补丁后的版本拷贝到备机失败
故障现象:
主机打完oracle补丁后,将主机$ORACLE_HOME文件同步到备机时间非常长!
故障原因:
使用rcp命令同步时,将导致ln下的东西拷双份
故障解决:
请检查主机上是否有不适合的ln连接,连接目标是一个目录(该目录下有大量文件),检查连接的方法是:
find . -type l -exec ls -l {} ;
34 oracle下的字符集问题
故障现象:
一般中文、英文环境都可以将oracle服务器字符集安装成ZHS16GBK。如果不小心装成英文字符,则会无法输入中文字符
故障原因:
一般是手工建库的情况导致的,通过执行建库的,不存在这个问题。
故障解决:
首先安装oracle的时候必须选择安装中文字符集的支持
由于中文字符集是英文字符集的超集,所以如果已经安装英文数据库字符集的话,可以用如下方式转换:
SQL> SHUTDOWN IMMEDIATE; -- or NORMAL
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE CHARACTER SET ZHS16GBK;
SQL> SHUTDOWN IMMEDIATE; -- or NORMAL
SQL> STARTUP;
版权声明:本文标题:Oracle日常维护故障定位故障排除 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.freenas.com.cn/jishu/1708909051h534211.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论