Maclean’s Oracle Database Tech Blog Archives

Not all data is created equal. As data ages it is not utilized as often and so it makes pure financial sense to offload less accessed data to cheaper storage media and it can improve performance of the overall system when your primary systems are not weighted down by stale data. The alignment of different…

My customer has an application which using a lots of “temporary” table. They create so many tables but only operate once.And they are using automatic SGA management,all this cause large memory usage in shared pool, especially the “obj stat memo”. Recently they encountered  the error 4031 , there are still 1G space available in shared…

题目叙述十分网络化也很人性，大多数题目我都不懂，恐怕也来不及学了………….. 腾讯公司是网民公认的山寨软件之王，这个形容有些贬义；但其山寨的软件往往“青出于蓝而胜于蓝”，由此可见其本身技术实力还是非常power的。

中午在chinaunix看到这条新闻《“打假名人”王海：金山毒霸谎称全球第一》： 晨报讯(记者 叶青)  在AV-C国际评测中病毒检测率本是倒数第一，却在产品宣传中谎称“全球第一”？昨日，“打假名人”王海向众媒体指称金山毒霸虚假宣传，欺骗广大消费者， 并表示其已向海淀法院递交诉状。对于这一指控，金山毒霸则给予了坚决否认。王海称，2010年5月17日其因电脑出现问题在北京连邦软件股份有限公司杭州旗舰店花费220元购买了一套金山毒霸(金山互联网安全组合 装，3年2台电脑用户版)。但在使用过程中，发现金山毒霸并非如其宣传得那么管用。经查证，其发现自己被彻底欺骗了。“它对外号称‘100%可信与病毒查 杀率’，‘在AV-C认证中，病毒检测率全球第一’，但我后来一查满不是那么回事。”王海说，其在AV-C国际认证官方网站查询到的结果却是：最新的 2010年2月的测试报告中，金山毒霸的病毒检测率仅为81.8%。这个数据在所有参与检测的20款产品中病毒检测率最低，是倒数第一，但漏报率第一、误 报率第二，“它又怎么可能做到其号称的‘100%可信与病毒文件识别率’？！” 王海还指出，金山毒霸宣传的扫描速度世界第一也只是去年的一个成绩，在最新的关于扫描速度测试中，其仅排在第七名。据此，王海指认金山毒霸虚假 宣传，并以此为由将北京金山软件有限公司和金山毒霸的经销商北京连邦软件股份有限公司一并诉至法院，要求返还购货款220元及支付一倍赔偿金220元，并 要求二被告共同向消费者赔礼道歉。 记者随后致电了金山毒霸公关经理李小光，其坚决否认了王海的指控。李经理表示，“在病毒检测率上AV-C有明确的报告，我们在产品宣传上绝对是 依据报告进行的，不可能有虚假宣传的情况。” 抽空翻了一下AV-C的主页：www.av-comparatives.org， AV-C是一家独立的反病毒软件测试组织(Independent TEST of Anti-Virus  Software)。在他们2010年2月的总第25期杀毒软件评测报告中(是中文版的:) , Kingsoft Anti-Virus 的检测率为81.8%,居于末位： 遗漏样本图示： 误报测试结果： 病毒扫描速度： 以上测试结果可见端倪。 国产软件需要国人的大力支持，毕竟起步要比国外晚上几十年；然而国产软件更因该务实求真练好内功，而非追求这些“第一”的名号。 金玉其外，败絮其中，其可厌乎！

as this bug note claimed that: PROBLEM: ——– Customer frequently receives the following errors while rollback of a transcation using Portal application: ORA-603: ORACLE server session terminated by fatal error ORA-600: internal error code, arguments: [6856], [0], [0], [], [], [], [], [] ORA-600: internal error code, arguments: [25012], [3], [15], [], [], [], [],…

一位客户的Oracle告警日志中出现了ORA-600 [kddummy_blkchk] [18038]故障，alert中的具体信息： Errors in file /u01/app/oracle/admin/prdw014a/udump/prdw014a_ora_4377.trc: ORA-00600: internal error code, arguments: [kddummy_blkchk], [222], [5792], [18038], [], [], [], [] Mon May 17 15:27:53 2010 Trace dumping is performing id=[cdmp_20100517152753] Mon May 17 15:27:53 2010 Doing block recovery for file 2 block 504365 Block recovery from logseq 159276, block 166357 to scn 10934615778284 Mon May…

介绍完了EnterpriseDB复制软件基本原理和注意事项，我们接下来进行Oracle数据复制到EntepriseDB advanced Server的实际演练。 先在Oracle实例中创建复制测试所用到的数据： SQL> drop user source cascade; User dropped. SQL> create user source identified by source; User created. SQL> grant dba to source; Grant succeeded. SQL> grant create any trigger to source; Grant succeeded. SQL> conn source/source Connected. SQL> create table EMP 2 ( 3 EMPNO NUMBER(4) not null, 4 ENAME VARCHAR2(10), 5…

EntepriseDB 复制软件目前支持多种数据库到postgre的复制，其基本结构由发布者(Publication)与订阅者(Subscriptions)组成,Replication软件可针对来自不同类型数据库的多个发布者，将其数据复制到多个订阅者(Subscriptions)数据库中。 其可能的几种拓扑结构，如以下图： 同Oracle中普通的物化视图一样，不支持对订阅者(Subscriptions)数据的修改–Changes must not be made to the data or the definitions of the subscription tables. EnterpriseDB Replication软件的具体工作模式分成2种：即快照模式(snapshot)与同步模式(synchronization)；在第一次启用同步前，需要进行一次快照操作,之后便可以进行较为轻量级同步操作了。若要使用同步模式(synchronization)则要求发布者所包含的表必须具有主键,而在仅使用快照模式的情景中则不需要。(Each table used in a publication must have a primary key with the exception of tables in snapshot-only publications, which do not require a primary key.) 以上模式均支持过滤器(fliter),即可以指定需要复制的具体数据子集。 EnterpriseDB Replication软件其同步(synchronization)模式复制的基本原理是基于trigger的，而非如Quest公司的shareplex或golden gate般抽取重做日志生成SQL的方式。trigger方式会在数据库源端产生一定的性能影响，若在mission critical的生产数据库中实施EDB replication 复制则需要考虑到这一点(这种情况下推荐使用Snapshot模式)。这可能是EDB复制软件比较不成熟的一点，就目前仅对Oracle日志文件的研究认识，挖掘重做日志进而实现数据复制的途径已经没有技术上的难点了。 以下发布者所包含的数据对象或表属性，将在订阅者成功建立时被复制到订阅者所在的数据库： Tables Views…

下面我们来测试EnterpriseDB Migration 工具对于Oracle 大对象(LOB)的迁移情况； 首先在在Oracle实例Scott模式下创建具有LOB对象的表,如： SQL> create table tlob (t1 int primary key,t2 clob,t3 blob); Table created. — 并填充数据 SQL> begin 2 for i in 1..100 loop 3 insert into tlob values(i,rpad(‘A’,9999,’Z’),hextoraw(i) ); 4 end loop; 5 commit; 6 end; 7 / PL/SQL procedure successfully completed. 打开EnterpriseDB Migration 工具界面，从树形图中找到需要迁移的表TLOB,选择进行在线迁移： 导出日志： [Starting Migration] 源数据库连接信息… 连接 =jdbc:oracle:thin:@rh2.home:1521:G10R21…

EntperpriseDB 目前作为Postgre开源数据库的企业发行版，在原开源社区的基础上对postgre进行了扩展(contribute),值得关注的技术有infiniteCache,以及其强大的迁移工具Migration tools;下面我们来简单测试该迁移工具. 通过安装postgreplus-advanced-server软件包，其中将默认包括DBA management Server,DBA monitor Console,Migrate Studio,Replication Tools等一系列管理工具。我们需要用到的是Migrate Studio. 打开Migrate Studio首先定义迁移目标端的Enterprisedb实例，事先已经在主机rh2.home上安装了EnterpriseDB 8.3R2版本，同时创建了名为maclean的数据库(database),使用默认端口5444，新建EDB服务器： 该工具同大多数Oracle管理工具一样使用java驱动,但速度较快显得十分轻量级。 接着我们需要创建源端的Oracle服务器，同样在远程主机rh2.home上建立了Version 10.2.0.1的Oracle EE版数据库实例名为g10r21,Listener监听在端口1521上，尝试创建该服务器时将被要求Oracle JDBC包，该包可以到oracle官方网站下载，之后将该包放置到$EDBHOME/jre/lib/ext目录下;新建Oracle服务器: 之后我们可以尝试将Oracle实例中Scott模式下的对象迁移到enterprisedb中,在此之前我们在该模式下建立简单的存储过程，协同测试。 SQL> create or replace procedure scott.count_emp as 2  c int; 3  begin 4  select count(*) into c from scott.emp; 5  dbms_output.put_line(’emp count is ‘||c); 6  end; 7  / Procedure created. SQL> set serveroutput on ;…