Monthly Archives: August 2011

内存数据库缓存用户手册总结

最近准备拣拣TIMESTEN的东西。 第一次看TIMESTEN相关文档是在06年的时候,那时似乎Oracle刚收购TIMESTEN时间不长,而整好TIMESTEN还推出了一个新的版本,于是当时研究了一下。由于主要的精力还是在Oracle上面,于是主要关注的是利用TIMESTEN来提高查询和数据处理的速度,而TIMESTEN本身的语法和功能到并没有过多关注。 研究一段时间后发现,无论是TIMESTEN到ORACLE的数据同步功能还是TIMESTEN本身提供的功能,都与我的预期存在较大差异,因此TIMESTEN的研究就一直放下了。 过了5年的时间,TIMESTEN和Oracle的技术融合工作应该已经比较成熟了,而且似乎前不久的新版本中TIMESTEN也开始支持PL/SQL了,所以开始陆续重读TIMESTEN的文档。 至于这本内存数据库缓存用户手册,更像是数据库缓存的管理员手册,记录了数据库缓存环境的建立、管理、删除等的操作。

Posted in BOOKS | Leave a comment

AL32UTF8和UTF8字符集

客户的环境需要使用UTF8字符集,那么是使用AL32UTF8还是直接使用UTF8,这是一个问题。 Oracle的UTF8字符集由来已久,至少在8的时候就已经存在了,而对应的是UNICODE 3.0。而AL32UTF8字符集是9i才出现的,其对应的是UNICODE 5.0。 这两种字符集的区别在于,UNICODE 5.0与3.0相比,又增加了一些新的补充字符。但是在实际当中,使用到这些新增字符的可能性非常小,因此绝大部分情况下,选择UTF8也是足够的。 而对于数据库的访问而言,二者还是存在一定差异的。前面提到了AL32UTF8字符集是9i才出现的,那么对于9i以后的版本访问没有任何问题,但是对于8i及以前的版本,则不认识这个字符集。这就使得8i及更低版本的客户端在访问9i以上AL32UTF8的数据库时,会碰到各种各样的问题。因此,Oracle建议在选择AL32UTF8和UTF8字符集时,最关键的一点就是是否有8i及以下版本的客户端会登录到数据库中,如果没有则可以选择AL32UTF8,如果存在这种客户端,那么需要选择UTF8字符集。 随着现在版本11g逐渐开始称为主流版本,8i客户端的情况已经越来越少见了,因此在11.2的DBCA中,UTF8已经不是推荐字符集列表中的一员了。

Posted in ORACLE | Tagged , , | Leave a comment

10g以后Oracle不支持ZHS32GB18030

在9i中Oracle存在字符集ZHS32GB18030,而10g以后,这个字符集在安装数据库的时候已经不可选了。 由于客户的环境需要输入大量的生僻字,要求客户端采用GB18030编码,这使得数据库无法使用ZHS16GBK字符集。 查询了一下字符编码方面的资料,最早推出的GB2312-80编码,包含了大约6000多个汉字,而对应的Oracle字符集编码为ZHS16CGB231280。这6000多个汉字对应日常应用足够,但是稍微生僻一些的汉字就无法在系统中显示。 此后推出了GBK编码,所支持的汉字超过了20000,这对于大部分情况来说足够使用了,其对应的Oracle数据库字符集就是中文中最常用的ZHS16GBK。GBK包含的所有GB2312编码中的汉字,但是二者并非严格意义上的超集关系。 在2000年的时候,出现了GB18030编码,它使用4位字符编码,因此覆盖的汉字达到了60000以上,这时GB18030中编码符合UNICODE 3.0。到2005年的时候,GB18030-2005又收录了一些新的汉字或图形,这时符合UNICODE 4.0编码。在Oracle9i中,存在字符集ZHS32GB18030,对于GB18030编码,但是从10g开始,数据库字符集不再支持ZHS32GB18030字符集了。虽然包括metalink在内介绍了先创建US7ASCII字符集在通过修改数据库字符集的方法将数据库字符集转化为ZHS32GB18030,但是这种方法毕竟不是官方推荐的方法,如果说10g的数据库安装过程中不能选择ZHS32GB18030字符集,是Oracle漏掉了这个字符集,那么在11.2中,同样无法选择这个字符集,就明确说明了Oracle的态度了。事实上,从10g开始,ZHS32GB18030变为客户端字符集,而数据库中之所以还可以创建这个字符集,是Oracle为了后向兼容性,确保9i中ZHS32GB18030字符集的数据库可以顺利的升级。 10g中不再支持ZHS32GB18030字符集,因此Oracle建议用户更改字符集为AL32UTF8或UTF8字符集,详细文档可以参考ID 1144903.1。不过在11.2中UTF8同样是不推荐的字符集之一,那么如果需要在客户端使用GB18030编码,那么推荐使用AL32UTF8字符集。如果客户端使用GB18030-2000编码,那么可以在数据库中选择AL32UTF8字符集,而客户端字符集选择ZHS32GB18030,所有的客户端字符都可以顺利的保存到服务器端或从服务器端读取。如果客户端选择GB18030-2005编码,那么没有专门的客户端字符集与之对应,因此客户端应该与数据库保持一致,都选择AL32UTF8字符集。

Posted in ORACLE | Tagged , , | 1 Comment

ORA-600(krvxdds: duplicated session not)错误

在客户的告警日志中发现这个错误信息。 这个错误信息是第一次看到,而且在metalink中也没有找到任何相关的描述,详细的错误信息如下: Fri Nov 19 11:47:47 2010 <krvrd.c:krvrdqgov>: Invalid dictionary process cntxt. Fri Nov 19 11:47:47 2010 Errors IN file /oracle/db/admin/B1MODDB/udump/b1moddb1_ora_4488.trc: ORA-00600: internal error code, arguments: [krvxdds: duplicated SESSION NOT ], [], [], [], [], [], [], [] ORA-01334: invalid … Continue reading

Posted in BUG | Tagged , , | Leave a comment

物化视图快速刷新不支持标准外联接写法

发现对于REFRESH FAST ON COMMIT物化视图,并不支持标准外连接的写法,而Oracle特有的(+)方式则没有问题。 Oracle对于标准外联接的写法支持的并不好,类似的bug已经不是第一次碰到了。 SQL> CREATE TABLE T_P (ID NUMBER PRIMARY KEY, NAME VARCHAR2(30)); 表已创建。 SQL> CREATE TABLE T_F (ID NUMBER PRIMARY KEY, FID NUMBER); 表已创建。 SQL> CREATE MATERIALIZED VIEW LOG ON T_P 2 WITH ROWID (ID); 实体化视图日志已创建。 SQL> … Continue reading

Posted in ORACLE | Tagged , , , , | Leave a comment

EXP无法导出延迟段创建的表

对于11g中使用了延迟段创建方式创建的表,如果导出时刻表的段没有被创建,那么EXP不会导出这张表。 检查测试如下: SQL> CREATE TABLE t_defer (id NUMBER, name varchar2(30)); TABLE created. SQL> CREATE TABLE t_imme (id NUMBER, name varchar2(30)) segment creation immediate; TABLE created. SQL> SELECT TABLE_NAME, segment_created FROM user_tables; TABLE_NAME SEG —————————— — T_IMME YES T_DEFER NO 下面通过EXP进行导出: … Continue reading

Posted in ORACLE | Tagged , | Leave a comment

ROWNUM固化外部表结果集存在问题

在客户的11.2.0.2环境中碰到了这个问题,Oracle在处理包含ROWNUM固化的外部表加载数据时返回错误的结果。 外部表构造描述可以参考:利用外部表读取告警日志文件 客户环境中创建的外部表和上面链接中的例子几乎完全一致: SQL&gt; CREATE TABLE T_ALERT 2 (TEXT VARCHAR2(4000) 3 ) 4 ORGANIZATION EXTERNAL 5 (TYPE ORACLE_LOADER 6 DEFAULT DIRECTORY D_ALERT 7 ACCESS PARAMETERS 8 (RECORDS DELIMITED BY NEWLINE 9 FIELDS (TEXT (1:255) CHAR)) 10 LOCATION (’alert_xshdb1.log’)); TABLE created. … Continue reading

Posted in BUG | Tagged , , | 2 Comments

利用外部表读取告警日志文件

数据库的告警日志以文本的格式保存到文件系统中,虽然可以很方便的通过操作系统命令进行查看,而且11g中Oracle甚至还提供了专门的adrci工具,但是对于只能通过SQLPLUS或者其他查询工具连接到数据库的人而言,还是非常不方便。 不过其实这个问题可以很容易的通过外部表的方式解决。最简单的办法就是将alert文件中的每一行记录都当做表中一个VARCHAR2(4000)类型列的一行记录,这样就可以轻松的通过SQL的方式来访问告警日志了。 在创建外部表之前,需要创建一个DIRECTORY,这个目录的位置就是background_dump_dest初始化参数指定的位置。 SQL> SHOW parameter background_dump_dest NAME TYPE VALUE ———————————— ———– —————————— background_dump_dest string D:\ORACLE\PRODUCT\ADMIN\YTK102\BDUMP SQL> CREATE directory d_alert AS ‘D:\ORACLE\PRODUCT\ADMIN\YTK102\BDUMP’; 目录已创建。 一旦目录创建成功后,就可以创建外部表了: SQL> CREATE TABLE t_alert 2 (text varchar2(1000) 3 ) 4 organization external 5 (TYPE oracle_loader 6 … Continue reading

Posted in ORACLE | Tagged , , | 3 Comments

PSU补丁安装不全的问题

对于PSU补丁的安装,不是简单的opatch apply之后就完成了,还需要运行特定的sql。 在客户数据库中检查补丁情况,发现安装PSU只完成了第一步: fgms:/fgms/oracle/tru64_setupFile/OPatch > ./opatch lsinventory Invoking OPatch 10.2.0.5.0 Oracle Interim Patch Installer version 10.2.0.5.0 Copyright (c) 2010, Oracle Corporation. All rights reserved. Oracle Home : /fgms/oracle10g/db Central Inventory : /fgms/oracle/oraInventory from : /var/opt/oracle/oraInst.loc OPatch version : 10.2.0.5.0 OUI … Continue reading

Posted in ORACLE | Tagged , , , | Leave a comment

TRUNCATE模式SQLLDR导致SECUREFILE的LOB空间不断增长

测试LOB的SECUREFILE存储方式时发现,如果利用SQLLDR的TRUNCATE方式导入数据,随着测试次数的增加,LOB对象占用的空间也会逐步增加。 创建表的脚本很简单: CREATE TABLE t_load_4m_sf (id NUMBER, full_name varchar2(100), create_date DATE, contents BLOB, CONSTRAINT pk_t_load_4m_sf PRIMARY KEY(id)) lob (contents) store AS securefile; 用于加载LOB数据的控制文件如下: [oracle@dbserver1 sqlldr]$ more sqlldr_4M_sf.ctl LOAD DATA INFILE ‘filename.dat’ INTO TABLE T_LOAD_4M_SF TRUNCATE FIELDS TERMINATED BY ‘,’ (ID … Continue reading

Posted in ORACLE | Tagged , , , | 1 Comment