10 数据库服务器字符集更改步骤
问题描述:
在客户端插入字符“咪咪”,从数据库中查询显示时出现乱码
处理步骤:
10.1 对数据库做全库导出,备份全库数据,以防故障发生
首先设定客户端的字符集,必须以ZHS16GBK的字符集导出,然后才能在更改失败后顺利倒入新建的库。
#setenv NLS_LANG “SIMPLIFIED CHINESE_CHINA.ZHS16GBK”;
#stty -istrip -parity cs8;
#setenv LANG zh
拟在/sybdata(磁盘阵列)下建立一个目录orabak,用于存放dmp文件。
#mkdir /sybdata/orabak
#chown oracle:oinstall /sybdata/orabak
#su – oracle
#cd /sybdata/orabak
%exp system/manager@hnsdh file=hnsdh_2005-8-17 log=hnsdh_exp_2005-8-17 full=y
(此处命名为示例,以实施当日日期为准)
察看日志结尾,以判定导出是否成功。
#cat hnsdh_2005-8-17.dmp | od -x | head
看第二和第三个字节组成的十六进制数是多少可判断导出文件的字符集。
示例如下
#cat example.dmp | od -x | head 0000000 0303 5445 5850 4f52 543a 5630 392e 3032 。。。 0000220 646d 7000 0000 0000 0000 0000 0000 0000 十六进制的0354化为十进制为852,参造下表 NLS_charSET_ID NLS_charSET_NAME HEX_ID ————– —————————— ————- 1 US7ASCII 1 2 WE8DEC 2 3 WE8HP 3 4 US8PC437 4 5 WE8EBCDIC37 5 6 WE8EBCDIC500 6 7 WE8EBCDIC1140 7 8 WE8EBCDIC285 8 ………………. 850 ZHS16CGB231280 352 851 ZHS16MACCGB231280 353 852 ZHS16GBK 354 853 ZHS16DBCS 355 860 ZHT32EUC 35c 861 ZHT32SOPS 35d 862 ZHT16DBT 35e 863 ZHT32TRIS 35f 864 ZHT16DBCS 360 865 ZHT16BIG5 361 866 ZHT16CCDC 362 867 ZHT16MSWIN950 363 868 ZHT16HKSCS 364 870 AL24UTFFSS 366 871 UTF8 367 872 UTFE 368 即可得出这个dmp文件的字符集为ZHS16GBK。 |
10.2 在数据库中直接更改字符集参数
操作步骤如下:
SQL> shutdown immediate SQL> startup mount SQL> alter SYSTEM ENABLE RESTRICTED SESSION; SQL> alter SYSTEM SET JOB_QUEUE_PROCESSES=0; SQL> alter SYSTEM SET AQ_TM_PROCESSES=0; SQL> alter DATABASE OPEN; SQL> alter session set events ’10046 trace name context forever,level 12’; SQL> alter database character set INTERNAL_USE ZHS16GBK; SQL> shutdown immediate SQL> startup 察看系统字符集 SQL> select * FROM NLS_DATABASE_PARAMETERS; |
看NLS_charACTERSET的值为多少,如果为ZHS16GBK则说明改动成功。
如果执行正常,则按照下一节进行测试操作。
10.3 更改成功后的测试
测试1,在数据库服务器端下测试
%setenv NLS_LANG “SIMPLIFIED CHINESE_CHINA.ZHS16GBK”; %stty -istrip -parity cs8; %setenv LANG zh %sqlplus /nolog SQL〉conn / as sysdba SQL〉create table test_tq (a char(20)); SQL〉insert into test_tq 1>(a) 2>values (’洣洣’); SQL〉select * from test_tq; |
如显示为
A
——————–
洣洣
则成功。
测试2,Windows客户端环境下测试
运行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE, 第三步选择 ORACLE, 第四步选择 NLS_LANG, 键 入 与服 务 器 端 相 同 的 字 符 集(本例为: AMERICAN_AMERICAN.US7ASCII)。
右击我的电脑,然后点击属性,“高级”页面下,点击“环境变量”,在系统变量中添加:
变量名:NLS_LANG
变量值:SIMPLIFIED CHINESE_CHINA.ZHS16GBK
运行cmd,输入echo %NLS_LANG%,查看系统变量设置时否成功
然后运行:
$sqlplus system/manager@hnsdh SQL〉conn / as sysdba SQL〉create table test_tq (a char(20)); SQL〉insert into test_tq 1>(a) 2>values (’洣洣’); SQL〉select * from test_tq; |
如显示为
A
——————–
洣洣
则成功。
10.4 更改不成功时的措施
新建数据库,设定字符集为ZHS16GBK,其他参数先照搬原来的,并倒入数据。建库时所需的具体参数在重建之前要搜集。注意在配置控制文件时设定最大数据文件数。
建好数据库以后,执行以下命令即可恢复数据库
%cd /sybdata/orabak
%imp system/manager@hnsdh full=y ignore=y file=hnsdh_2005-8-17 log=hnsdh_imp_2005 -8-17
11 Oracle数据库归档目录usr5满的解决办法
故障现象:
C网数据库的逻辑日志增长很快,有时候每分钟就产生150M的日志文件,导致归档目录不到一天的时间就满了。我们的备份策略是每天的晚上0点执行,也就是说还没来得及备份归档目录就满了。
导致的结果:
数据库挂起不能工作。
问题分析及解决办法:
解决办法有3种:
1,增加归档目录的空间 2,增加备份频度 3,删除归档日志文件
每一种办法都会存在一些问题或产生一些负面影响:
1,增加归档目录的空间,这个已经不可行,因为已经没有可用空间
2,增加备份频度,会影响部分系统性能,后来观察影响不大,远远排在了oracle进程后面。
3,删除归档日志文件,这只是权宜之计,会带来控制文件和日志文件的不同步从而影响下一次的数据库备份失败,以及万一数据文件损坏从而因影响恢复的问题。
经过分析和权衡,初步采用了每天办法2次的办法。除了原来夜里零点备份的1次之外,又安排在白天2点备份一次,至于为什么定到2点,主要是想均衡一下业务量,考虑到凌晨业务量较小可能产生较少的日志(相对白天而言)。结果很见效。后来讨论,又发现了一下新的问题。 问题是: 万一备份失败或者在12小时之内usr5空间满怎么办?于是又添加了一个执行脚本fs_monitor.sh,每小时执行一次,若发现usr5空间达到80% 就自动删除归档日志文件然后自动数据库同步
以下是自动自动清楚自动同步的脚本(由左亮撰写)
#!/bin/sh #Please change the ARCHIVE_FS to your actual filesystem that your archive log storaged ARCHIVE_FS=/usr5 #Please change the ARCHIVE_DIR to your actual directory that your archive log storaged ARCHIVE_DIR=/usr5/oracle/bjdb/arch_2 #Defined the location of log file LOG=/usr5/oracle/bjdb/${0}.`date +%m%d`.log #Obtain the usage of filesystem at that time DFK=`df -k|grep $ARCHIVE_FS|awk ’{USAGE=substr($5,1,length($5) – 1) print USAGE}’` START_RMAN=” setenv ORACLE_SID rman sqlplus /nolog << EOF connect /as sysdba startup exit EOF” STOP_RMAN=” setenv ORACLE_SID rman sqlplus /nolog << EOF connect /as sysdba shutdown immediate exit EOF ” #Defined the command of archivelog crosscheck CMD_STR=” setenv ORACLE_SID bjdb rman target sys/sys catalog rman/rman@rman<<EOF crosscheck archivelog all; exit EOF ” #Check the usage of ARCHIVE_FS if [ $DFK -gt 80 ] then TIME=`date` echo “At the time: “$TIME”, Usage of ” $ARCHIVE_FS “filesystem is beyond 80%. The used rate is :”$DFK”% now”>>$LOG cd $ARCHIVE_DIR #Obtain file list that need to be remove FILE_LIST=`ls -lt|tail -600|awk ’{print $9}’` for FILE in $FILE_LIST do rm $FILE 2>>$LOG done #Start rman database su – oracle -c “$START_RMAN”>>$LOG #Run the crosscheck operation su – oracle -c “$CMD_STR”>>$LOG #Stop rman database su – oracle -c “$STOP_RMAN”>>$LOG echo “……”>>$LOG else exit 0 fi |
12 判断oracle版本位数的方法
有2种方法,详情如下:
1) file $ORACLE_HOME/bin/oracle /oracle92/app/oracle/product/9.2.0.1/bin/oracle: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped 2)SQL> select * from v$version; BANNER ——————————————————————————– Oracle9i Enterprise Edition Release 9.2.0.6.0 – 64bit Production PL/SQL Release 9.2.0.6.0 – Production CORE 9.2.0.6.0 Production TNS for Solaris: Version 9.2.0.6.0 – Production NLSRTL Version 9.2.0.6.0 – Production |
13 XX网有非正常数据文件的情况下的数据库rman恢复
背景:
XX网数据库在阿联重建控制文件的时候出现问题,决定使用rman的备份进行恢复,但是XX网数据库以前由于我们部门员工的误操作产生了一些非正常的数据文件,主要有以下情况:
1. 数据文件被非正常添加,然后被在操作系统内删除
2. 数据文件被非正常添加,然后由于影响双机应用被强制离线
这样在备份的时候会把这些文件跳过,而且rman也明确提示,会影响到他们相关表空间的恢复。
操作办法:
正常的控制文件和redolog还在,所以此时如果正常使用rman的restore database,系统会提示找不到备份的时候跳过的数据文件的备份,因此采用逐个恢复数据文件的方式:
restore datafile XXX; |
这样恢复所有的可用数据文件。
然后使用rman进行recover database时,系统会提示需要对跳过的数据文件进行恢复,此时无法恢复,因此使用如下办法解决:
1. 切换到sqlplus,进行recover database
2. 查看提示需要的归档日志文件
3. 使用rman把需要的归档日志恢复出来,由于空间的问题,所以采用每次恢复只恢复出来100个
restore archivelog from sequence 1_xxxxx.dbf to sequence 1_xxxxx.dbf; |
4. 然后在sqlplus中recover database,观察到快要需要下一个100个归档日志的时候,再使用rman恢复下100个
5. 一直恢复到最后一个归档日志,recover会退出,但是此时还未恢复完毕,可以查看一下现有的redolog中未归档的组
6. 在sqlplus里使用以下命令,并指定未归档的redolog的文件位置来恢复:
recover database using backup controlfile until cancel |
7. 此时恢复完成,可以使用alter database open resetlogs打开数据库。
8. 打开之后需要做的事情包括:1)建立恢复临时表空间的数据文件;2)连接到rman的catalog数据库,并reset database重置当前数据库;
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列,而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库(O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢?TechTarget数据库网站将与您分享12月份的榜单排名情况,让我们拭目以待。
-
2017年11月数据库流行度排行榜 半数以上数据库积分减少
数据库知识网站DB-engines更新了2016年11月份的数据库流行度排行榜。TechTarget数据库网站将与您一同关注11月份的榜单排名情况。
-
控制合约 不再畏惧Oracle
许多公司都与Oracle有无限制授权协议,他们害怕离开这个协议,所以就证明他们在使用Oracle的软件,即使因为需求单独购买部分授权许可也可能总体是省钱的。