在AnySQL.net中搜索标签(Tags) 'Log' 的结果:
HVR, 欧州的Shareplex?
除了Shareplex和GoldenGate外, 及中途夭折的MyLOG(开玩笑)外, 还有一个基于日志文件分析作Oracle逻辑备份的产品, 来自欧州的HVR(High Volume Replicator). 前几天发的一篇关于Zizzy开源项目的文章, 引起了他们的注意, 从而找到我, 原来Zizzy就是这家公司贡献出代码来的, HVR的核心就是Zizzy这个项目的代码了, 它相当于是Unix的Kernel了, 而HVR则相当于很漂亮的一个Unix Shell. 现在主要维护它的居然是一个中国籍人, 实在是意料之外了. 在与他们的谈话中了解到, 这个项目是从99年就开始研究开发它的, 我想Shareplex也差不多就是那时侯开始的吧, 不知道主要开发这个代码的Sean Young是什么背景出生, 居然这么历害. 这下我的牛皮又吹破了, 说是要注入MyLOG的代码, 看来没有必要了, 比我现有的完善多了, 到是可以仔细研究一下他们的代码, 看看可不可以贡献一点点. 看来握着MyLOG的源代码不放, 的确是做错了. 还问了一下他们产品的应用情况, TNT就是他们的客户之一, 在欧州那边有相当多的客户, 据说有一次开会,...
向Zizzy项目注入MyLOG
开源项目网(SourceForge)上出现了一个名为Zizzy的项目, 指在挑战Quest公司的拳头产品Shareplex或GoldenGate, 打造免费的基于日志的Oracle复制软件, 我开始研究Oracle日志格式时, 也定的这个目标, 可惜失败了. 是从Jonah Harris主管的Oracle Internals网站得到这个项目信息的. 现在这个项目中还没有任何代码或文档可以看, 而本人的MyLOG则已经可以解出SQL语句了, 只是凭着我一个人, 无法再研究下去了而已, 而我也很难找到志同道合者并有空余时间和精力继续下去, 早就有开源的想法了. 只要有人真的愿意好好做下去, 我还是愿意贡献我的代码的, 毕竟我的研究结果放着也就放着, 何不让出去呢? 不为利, 博个名吧. 目前还没有贡献出去, 还需要对这个项目的发起人, 及现在的人员作个调查再说. 交给别人去管, 自已有空时做个研究者, 也是一种乐趣....
Oracle 11g新特性 -- DG压缩传送日志
用DataGuard做远距离的容灾时, 日志的传送也会成关键的问题. 面对这个问题, 首先会想到将Archive Log先缩压一下, 再进行传送, 或者用rsync(现在用得越来越广了)加上压缩选项来处理, 可以说Oracle的这个功能来得太晚了, 应当在9i时就加上. 通过LOG_ARCHIVE_DEST_n中的一个参数可以控制是否启用压缩功能, 默认值是禁用的. 如下所示: LOG_ARCHIVE_DEST_n='SERVICE=... COMPRESSION={ENABLE|DISABLE}' Oracle自身带的这个功能可以大大简化DBA的编程工作. 需要注意的是, 压缩数据是很耗CPU的一件事情, 需要考虑源端的CPU的使用情况, 尤其是你用LGWR传送日志时, 更要慎重考虑. 你可以在本地建一个中转节结点, 然后利用这个压缩功能将日志传送到远距离的DataGuard节点. DBA又可以多花点时间喝茶看报了!...
Oracle Log格式研究未完成的主要任务
虽然已经能从Oracle 10g和Oracle 11g中解出Redo SQL了, 但这个只适合于记录没有Row Chain和Row Migration的情况. 然而在真实的环境中无法全部避免这些, 也不能丢下这样的记录不管啊! 因此需要继续做的两个研究是: 1, 对于Row Chain和Row Migration的研究, 要处理这两种情况肯定要懂Oracle的数据块格式, 这方面已经有基础了; 2, 研究Supplemental Log Data的格式及如何发挥它的作用, Oracle的这个功能就是为Stream加上去的, 基于Log捕捉的所有程序都可以从这些设置中得到好处, 在Shareplex中验证了这一点. 虽然只有两件事情, 不过任务可不轻松的. 有时还需要大家的帮忙, 如果有兴趣可以一起研究这两点. 最近国内不少的公司都在项目中遇到了如何捕捉增量数据的问题, 最后不约而同地想到从Log中去获取, 而因此展开了一些对于Oracle Log的研究, 并想快速应用到项目中, 不容易啊, 研究这个的前途未见光明啊!...
Oracle 11g系列测试 -- MyLOG
象Log文件格式这样的研究, 是非常怕新版本的发布的. Oracle 11g的发布给我有点压力, 因为Oracle肯定会或多或少地对它作一些修改, 而象我这样没有官方支持的研究, 就比较难办了, 只能多作些测试了. 下午稍稍测试了一下MyLOG对Oracle 11g版本日志文件支持性. 原来以为什么都不用改的想法是落空了, 不过从目前看来, 我所关心的部份改动不会很大, 因为我稍稍修改了一下程序后, 已经可以解出SQL了, 基本上应当达到了对10g的研究水平. LOG> extract table t_11glog start 2 Start extract redo SQL ... RBA=0x000006.00017662.0010, XID=0x0001.01c.000000a7 RID=AAAC7bAAEAAAAPQAAA INSERT INTO T_11GLOG ( COL1...
半年内Log研究可以达到的中间产品
过去两年中断断续续地研究了一些Oracle日志文件的格式, 只是为了研究而开发了一个工具, 不具有任何实用的意义. 也比较清楚Quest Shareplex或DSG Realsync这样的软件的强大功能, 要做出这样的一个工具, 是非常难的, 也是非常耗时间的, 这是日志格式研究的终极目标. Oracle 11g的新Standby模式是很好, 不过那是在11g刚推出来的, 估计要到12X才能真正地广泛使用吧, 而且这么好的功能, Oracle不会不收许可证的值, 而且是相当地贵的. Standby还是有缺限的, 不支持异构, 比如源结点是比较贵的小型机系统, 而目标结构想选择比较便宜的x86系统时, 就不可能了. 相反地, 基于日志文件分析的逻辑复制软件则要灵活得多, 不仅可以异构, 还可以灵活地折分数据. 在过去的一段时间中, 有钱的公司用Shareplex, 没有钱的公司则用了实体化视图日志或自已写触发器的方式, 来捕捉增量数据, 然后自已写角本来实现两边数据同步. 这种方式遇到的最大的题是维护复杂, 并且对源端的数据库影响较大. 对于Log格式的研究也有一段时间了,...
丢失Redo, 如何不用resetlogs打开数据库?
今收到一个控制文件和一堆数据文件, 要在我的笔记本上打开这个库, 我是很不愿意用open resetlogs选项的, 因为控制文件和数据文件是一致的, 是在关闭数据库的情况下备份出来的. 结果发现日志文件原来是在E盘, 而我的笔记本上只有C盘, 直接Clear是不行的, 直接重命名也是不行的, 通过添加新日志组和删除旧日志组也不行, 因为其中有一组是当前Active的, 因此根本就不让删除. SQL> SELECT MEMBER FROM V$LOGFILE; MEMBER --------------------------------------------- E:\ORACLE\PRODUCT\ORADATA\PROD\REDO01.LOG E:\ORACLE\PRODUCT\ORADATA\PROD\REDO02.LOG E:\ORACLE\PRODUCT\ORADATA\PROD\REDO03.LOG 没办法了? 当然是有办法的了, 我们可以简单地骗过Oracle, 方法是我在C盘的相应目录中建了三个空文本文件, 大小全是0, 只是名字和日志文件的一样, 然后就启动到Mount方式, 进行重命名日志文件, 然后再清除每一个日志文件组, 最后就直接打开了数据库, 没有使用open resetlogs选项. ...
LOG_ARCHIVE_FORMAT中%r值从哪儿来的?
当数据库从9i或8i升级到10g时, 如果compatible参数也设成了10以上, 则LOG_ARCHIVE_FORMAT参数中必须包含%s, %t, %r参数. 其中%s是Log Seuqence; %t是Thread ID, RAC的节点中设有THREAD参数, 就是这个值了; %r指的是Resetlog ID了, 比较新, 得从Oracle 10g中增加的跨Resetlogs恢复功能说起. 为了支持这个功能, Oracle 10g在控制文件中新增了一部份内容, 就是历次Open Resetlogs的经过, 每经历一次Open Restlogs就生成了一个新的Incarnation(不知道如何翻译这个单词了), 反应到数据库中则是V$DATABASE_INCARNATION视图(基表x$kccic, 说明是存放在控制文件中的). 我这儿没有经过多次open resetlogs的数据库, 等一下验证一下. 查一个从来没有Open Resetlogs的库吧, 如下所示: ASQL> SELECT * FROM v$DATABASE_INCARNATION/G;...
问题解答 -- 如何得知一张表的纪录有变化?
网上有一个问题, 要想知道那些表记录发生了变化? 对于一些更新不是很多(一秒种有几百条上下的)的表, 我会建议用实体化视图日志(Materialize View Log/Snapshot Log)去实现. 其基本原理是能过一个内部(Internal)的内核(Kernal)一级的行级触发器(Row Level Trigger), 将变化过的记录的ROWID或主键值保存到另一个表中去. 实体化视图的增量刷新(Fast Refresh)正是基于这个技术. 假设我们需要监控的表名为T_OBJECTS, 主键为OBJECT_ID, 如果没有主键则用ROWID, 则可以用如下语句来创建实体化视图日志. -- Using Primary Key CREATE MATERIALIZED VIEW LOG ON T_OBJECTS TABLESPACE users WITH PRIMARY KEY, SEQUENCE; -- Using ROWID...
MyLOG搞成开源项目能造福于大家吗?
我想你基本上不知道MyLOG是什么样的东西, 不过下面的一些网上常见到的话题你可能会懂一些. 如何实时同步两边的数据? 如何将数据实时地同步到远程的数据库? 如何做远程冗灾? 比较低级的解决的方案有实体化视图, 或自已写程序来实现自动导出导入, 如果两边的网络很好, 还可以用触发器来实现. 中级一些的方案有Oracle的Stream和Replication, 说他们中级是因为他们还不够成熟. 高级一些的方案是用目前市面上的专用软件, 如很有名气的Quest Shareplex, 不是很有名气的DSG Realsync(缺少宣传)和基本上没有听说过的GoldenGate. 这些高级的专业软件在911事件后, 被国际上的大公司大量采用, 用于制作数据冗灾. 不过11g传闻中的一些功能很值得关注. 这些中高级的解决方案中, 都有一个共同的技术特点, 就是分析源数据库上产生的日志, 然后从日志中分解生成SQL语句, 最后在目标数据库端执行. 因为是从日志中去获得数据, 所以基本上对源数据库没有什么压力, 并且目标数据库不是源数据库的物理拷贝, 是在打开的情况下运行的, 因此还可以用来分担部份读操作. 当源数据库不可用时, 可以迅速将目标数据库转换为新的源数据库. 可以看到分析日志的Log Miner是一个关键,...
用MyLOG解出对COL$系统表进行的操作
在LOGTAB.TXT中加入如下行: 10000,21,COL$, 在LOGCOL.TXT中加入如下行, 不过由于COL$是Cluster表, 因此这里列出来的比真实的表列数少一列, 刚好少Cluster的那列: 10000,1,COL#,NUMBER 10000,2,SEGCOL#,NUMBER 10000,3,SEGCOLLENGTH,NUMBER 10000,4,OFFSET,NUMBER 10000,5,NAME,VARCHAR2 10000,6,TYPE#,NUMBER 10000,7,LENGTH,NUMBER 10000,8,FIXEDSTORAGE,NUMBER 10000,9,PRECISION#,NUMBER 10000,10,SCALE,NUMBER 10000,11,NULL$,NUMBER 10000,12,DEFLENGTH,NUMBER 10000,13,SPARE6,DATE 10000,14,INTCOL#,NUMBER 10000,15,PROPERTY,NUMBER 10000,16,CHARSETID,NUMBER 10000,17,CHARSETFORM,NUMBER 10000,18,SPARE1,NUMBER 10000,19,SPARE2,NUMBER 10000,20,SPARE3,NUMBER 10000,21,SPARE4,VARCHAR2 10000,22,SPARE5,VARCHAR2 10000,23,DEFAULT$,LONG 没有办法知道这个操作是对那个对象进行的, 因为OBJ#列的变更不记录在这儿. 终于明白为什么Shareplex不支持Cluster表了, 不过Single Hash...
MyLOG程序对于Drop类误操作恢复的作用
接到过几次由于Drop误操作引起的恢复请求, 在那种情况下, 最主要的问题是没有办法定位被Drop的表的Data Object ID的值. 由于Oracle在执行Drop操作时并不真正地对数据文件清行清理(这是我们能恢复的前提), 从儿当你的应用中有很多的临时表, 并经常Drop来Drop去的话, 在恢复时进行整个数据文件扫描, 会发现很多的Data Object ID, 而你不知道那个是包括了有用的数据. 事实上这种情况下, 恢复的主要式作是去验证这些Data Object ID是不是包含了真正的数据. 现在我们有了MyLOG, 到可以用来做这件事, 当前要求你能提供执行Drop误操作时所用的联机日志或归档日志文件. 在LOGTAB.TXT文件中加入下面一行: 9999,18,OBJ$, 在LOGCOL.TXT文件中加入下面几行: 9999,1,OBJ#,NUMBER 9999,2,DATAOBJ#,NUMBER 9999,3,OWNER#,NUMBER 9999,4,NAME,VARCHAR2 9999,5,NAMESPACE,NUMBER 9999,6,SUBNAME,VARCHAR2 9999,7,TYPE#,NUMBER 9999,8,CTIME,DATE 9999,9,MTIME,DATE...
解出Oracle日志文件中的Redo SQL语句之十
已花了两周时间搞日志格式研究, 应当收尾了, 这东西长期搞下去没有出路. 没想到仅花了两周时间, 就可以给大家做个演示了. 我在Oracle中运行了以下角本: SQL> insert into mylog values ('My Log 10g',-1,sysdate); SQL> insert into mylog select object_name, object_id, created 2 from user_objects where rownum < 4; SQL> update mylog set created = created +...
解出Oracle日志文件中的Redo SQL语句之九
初步完成了对Quick Multi-Insert操作的解释, 虽然在Oracle中是用一句话来进行Insert的, 但解出来时还是折分成一个一个的Insert语句了. 来看一下解出来的结果: RBA=0x000069.0000008d.0010, XID=0x0005.006.00000093 RID=AAAClAAAEAAAAJ2AAA INSERT INTO EMP ( EMPNO , ENAME , JOB , MGR , HIREDATE , SAL , COMM , DEPTNO ) VALUES (7369,'SMITH','CLERK',7902,'1980-12-17 00:00:00',800, NULL ,20); RID=AAAClAAAEAAAAJ2AAB INSERT...
解出Oracle日志文件中的Redo SQL语句之八
我在Oracle中运行了以下语句: SQL> CREATE TABLE MYLOG10G (COL1 NUMBER, COL2 VARCHAR2(20), COL3 DATE); SQL> insert into mylog10g values (100, 'Fangxin', sysdate); SQL> update mylog10g set col2='FANGXIN' where col1=100; SQL> delete mylog10g where col1=100; SQL> select object_id from dba_objects where object_name='MYLOG10G';...
解出Oracle日志文件中的Redo SQL语句之七
对于Delete操作, 取得相应的RowID. SQL> SELECT ROWID,EMPNO FROM EMP WHERE EMPNO=7934; ROWID EMPNO ------------------ ---------- AAAClAAAEAAAAJ3AAb 7934 SQL> DELETE EMP WHERE EMPNO=7934; 1 row deleted. Start extract redo SQL ... RBA=0x000062.00000002.0084, XID=0x0009.01d.00000090, RID=AAAClAAAEAAAAJ3AAb DELETE OBJ_10560 WHERE ROWID = ?; ...
解出Oracle日志文件中的Redo SQL语句之六
终于找到以前的代码为什么不能处理10g日志的原因了, 在10g中, 不知道为什么DML(Layer 11 Opcode 5)跑到了Undo信息(Layer 5 Opcode 1)的前面去了, 而在9i和8i中, 在DML之前绝对是Undo的信息. 下面是在Oracle中DUMP LOGFILE命令生成的一条日志记录: REDO RECORD - Thread:1 RBA: 0x000059.0000003d.0010 LEN: 0x0270 VLD: 0x0d SCN: 0x0000.0010ca12 SUBSCN: 1 05/08/2007 13:10:34 CHANGE #1 TYP:2 CLS: 1 AFN:1 DBA:0x0040166a OBJ:732 SCN:0x0000.0010ca0f SEQ: 1...
解出Oracle日志文件中的Redo SQL语句之五
Oracle 10g的日志文件格式和8i/9i有很大的不同, 这是早就知道的. 一直没有对10g版本的日志格式没有深入研究, 即然最近更深入地研究了日志格式, 不如将10g的也解决了吧. 昨晚大约花了2个多小时, 终于可以将10g日志文件中的Log Record一个一个地分开来了, 9i中区分Change的那部份代码不能直接用在10g上, 还是花点时间研究一下, 估计也就是保留字节变多了或变少了, 应当不难. 下面是用Oracle 10g的DUMP LOGFILE命令生成Trace文件, 然后用grep "RBA:"命令整出来的最前五行和最后五行: REDO RECORD - Thread:1 RBA: 0x000059.00000002.0010 LEN: 0x0070 VLD: 0x05 REDO RECORD - Thread:1 RBA: 0x000059.00000003.0010 LEN: 0x0290...
解出Oracle日志文件中的Redo SQL语句之四
要想得到更直观的SQL语句, 就得引入数据字典, 这里面主要需要以下三个方面的信息: Table (Object ID, Table Name, Partition Name) Column (Segment Column ID, Column Name, Column type) Key (The columns of primary key or unique index, for updating and deleting) 在MyLOG中引入了前两个: Table (LOGTAB.TXT)和Column (LOGCOL.TXT) $...
解出Oracle日志文件中的Redo SQL语句之三
初步解决了事务的划分问题. 这得感谢biti_rainy的帮助, 从另一个角度来看, 如果我们的DBA可以一起研究, 估计速度要快得多. 已经可以用XID这一条线来划分Redo SQL的事务关系了, 来看一下MyLOG的输出例子吧! LOG> extract start 2 end 6 Start extract redo SQL ... RBA=0x005e30.00000002.0010, SCN=0x031f.05c00824, XID=0x0012.049.000dc2bb, UBA=0x62c263c4.498b.08 INSERT INTO OBJ_1044190 (COL1,COL2,COL3,COL4,COL5) VALUES (?,?,?,?,?); RBA=0x005e30.00000002.0188, SCN=0x031f.05c00824, XID=0x000e.018.000daa6f, UBA=0x3b41c2dd.3bce.2d UPDATE OBJ_28267 SET COL84 =...
解出Oracle日志文件中的Redo SQL语句之二
到目前为止, 形成Redo的SQL语句(先不考虑Row Chain, Row Migration及LOB等情况)是没有问题了. 留下的一个很艰难的任务是如何区分事务. 即解出来的那一些语句是属于一个事务(Transaction)的? 因为Redo SQL解出来已经按照先后顺序了, 只要找出属于同一个事务的Redo记录中的共同点就可以了. 先不考虑日志中的内容, 则会话的SID和SERIAL#值到是很可以用来作为这一样的一根线的, 可惜的是在日志中并没有记录这两个值, 因此这是不行的. 为了找出这一条线, 我们先来看一下标记一个事务为提交的Redo记录(Layer=5, OP=4) : REDO RECORD - Thread:1 RBA: 0x005e30.00000006.0028 LEN: 0x0050 VLD: 0x01 SCN: 0x031f.05c00827 SUBSCN: 1 08/23/2006 19:08:22 CHANGE #1 TYP:0...
解出Oracle日志文件中的Redo SQL语句之一
由于精力所限, 一年半之间开始研究Oracle日志文件格式, 到现在都没有突破的成就, 一方面是因为工作越来越忙了, 另一方面是因为个人的精力实在有限, 因此在这一年半内, 基本上没有投入多一点点的时间去研究. 经过这么长的时间, 是应当继续向前走一步了, 今天就改造了一下我的MyLOG小工具, 以如何解出Redo SQL和搞清楚事务控制为中心. 现在不区分事务, 已经可以解出SQL语句了, 不过还需要进行很多的验证, 才能确定其准确性. 现在我是在Windows上打开了一个Solaris下的Oracle的日志文件: LOG> set byte_order big BYTE_ORDER = BIG LOG> open c:\mydul\utility\gbcust1_24112.arc DBID = 0x9d671cf9 = 2640780537 GROUP = 8, SEQUENCE =...
ociuldr小工具的新选项, 指定log文件
ociuldr工具(文档)越来越被人接受, 还有一位外国人特意发邮件来告诉我说, 他成功地将这个工具用于一个项目中. 即使是小工具, 也需要花不少时间去完善和维护的. 今天为这个工具新增了一个小选项: log = log file name, prefix with + to append mode 用法如下: ociuldr user=ansyql/anysql@s8i query="select * from tab" log=tab.log ociuldr user=ansyql/anysql@s8i query="select * from tab" log=+tab.log 指定log选项后, 运行ociuldr后将不会在屏幕上打印出log信息....
MySQL中的LogMiner工具 -- mysqlbinlog
在MySQL中binlog的作用和Oracle中的归档日志类似, Oracle中提供了DBMS_LOGMNR来对日志文件进行分析, 来解出Redo SQL和Undo SQL, MySQL中也提供了一个名为mysqlbinlog的工具, 用来解释或取出存放在binlog中的SQL语句, 有没有Undo SQL我到是没有研究过. 最基本的使用语法如下: mysqlbinlog [options] log_file ... 在选项中, 可以指定一些过滤条件, 来解出你所想用的东西, 这样的选项有: --database=db_name, -d db_name --offset=N, -o N --[start|stop]-datetime=datetime --[start|stop]-position=N 解出来的就是一条一条SQL语句了, 将这些语句执行一下, 就等于增量恢复了, 估计不是用绑定变量的, 可能在MySQL中是不是绑定变量不是很重要了. 当然重要的一点是不要运行多个进程去跑, 因为这样的话, 顺序就得不到保证了....
MySQL的binlog, InnoDB的日志和Oracle的日志
MySQL中有一个binlog的概念, 用于保存对数据库所作的修改, 这点上和Oracle的归档日志很接近, 但在原理上是很不一样的. 以InnoDB为例, InnoDB本身就有log文件, 和Oracle的联机日志一样, 用完了就重用, 但binlog并不是InnoDB的日志在重用前的拷贝, 而是另外写了一个文件. 因为binlog并不是专门为InnoDB设计的, 其他的存贮引挚如MyISAM也支持binlog, 它是MySQL备份及复制支持的重要基础, 因此不同于InnoDB的日志文件. 如果MySQL用于很重要的系统, 需要事务支持, 并且要支持联机备份, 要保证没有数据丢失, 目前来说, 一般会用InnoDB存贮引挚, 并启用binlog, 为了保证事务的数据不丢失, 就得: 1, 在每次Commit时, 将修改写入InnoDB的日志文件 2, 在每次Commit时, 将修改写入binlog文件 而在Oracle中只是保证写入到Oracle的联机日志就够了, 因此在性能测试中, 如果启用了binlog, 性能基本上下降了一半, 因为这中间要做两次写操作....
学习MySQL, 需要大家帮一点忙之一
开始学习MySQL已经有一周多时间了, 在学习的过程中, 没有一个有一定负荷的数据库在面前, 是很抽象的, 比如我最近正在研究的MySQL中的状态变量(Status Variables), 就需要从真实的库中去取一些数据出来, 以加深一下这些状态变量的印象. 为此我写了一小段Perl的代码(下载), 用来每隔十秒种输出一些我认为比较重要的状态变量的变化值, 不知道有谁能帮我去运行一下这个角本, 返回一二百行记录给我? 我在这儿先说声谢谢了. 这个小工具中只是十秒钟执行一下"SHOW GLOBAL STATUS"命令, 除此之外不运行任何SQL语句, 因此不会引起什么问题, 可以放心大胆地运行. 现在输出的结构是直接打印到屏幕的, 你可以将输出重定向到一个文件, 要退出程序的运行, 请按Control+C或者向程序发送一个INT信号(kill -INT pid). 程序以MySQL的root用户本地连接, 在程序中没有指定口令, 因为我假定root用户只能本地登录, 并且不需要密码. 对于这个程序, 我还会改进的, 如果觉得有用,...
加强MyLOG软件, 以进行Log格式研究之五
周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了按Layer和Opcode进行查找的功能, 周一晚上继续改进, 居然给我加成了按对对象号(Object ID)来查找的功能, 但目前还仅限于对表或索引进行维护的类型, 不过这已以是一个很大的进步了. 另外在上篇中写的TAIL命令也集成了这个查找功能. SEARCH option value [option value] TAIL option value [option value] DUMP option value [option value] OPTION OP layer SUBOP opcode START start redo...
加强MyLOG软件, 以进行Log格式研究之四
周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了一个TAIL命令, 用于将日志文件中的所有操作列出来, 当时想写一个Linux/Unix下"tail -f"这样的工具(tailredo), 可是发现这样显示出来的信息没什么用, 因此停写那个工具. 但这条命令本身在研究时还是有用的. TAIL START start_block END end_block TO output_file TAIL BLOCK block_id TO output_file 这个命令主要是将日志操作的类型列举出来: LOG> TAIL BLOCK 2 Start tailing redo operation ... 0x00005e30.00000002.0010...
加强MyLOG软件, 以进行Log格式研究之三
周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了一个OSDUMP命令, 用于将日志文件中的块以十六进制的形式打印出来, 有点象Linux/Unix下的od命令, 但这个更有专业性. OSDUMP START start_block END end_block TO output_file OSDUMP BLOCK block_id TO output_file 这个功能是一切文件格式研究的第一步, 使用例子: LOG> osdump block 1 Start osdump redo block ... 0x : -0-1...
加强MyLOG软件, 以进行Log格式研究之二
周日闲来无事, 因为周五忙到比较晚, 所以干脆不回南京了, 一个人的周末能做什么呢? 洗了一大堆衣服和床单, 留下了一点时间来改进一下MyLOG软件, 增加了一个OPEN命令, 正式将一个命令行的外壳和以前研究Log格式时写的程序挂上钩了. 这个OPEN命令的输出和以前写的lslog工具一样. 下面我在Windows上打开了一个Solaris Sparc上生成的归档日志文件: LOG> set byte_order big BYTE_ORDER = BIG LOG> open c:\mydul\utility\ARCH_24112.arc DBID = 0x9d671cf9 = 2640780537 GROUP = 8, SEQUENCE = 24112 File Type = 2, Next Block = 16059...
加强MyLOG软件, 以进行Log格式研究之一
对于Log格式的研究, 我是持犹豫态度的, 第一研究很费力, 第二研究出来了也没用. 随着Oracle推出逻辑Standby及更新进的流(Stream)复制解决方案后, 随着新版本的推出, 这方面的功能会越来越强, 同样基于Log格式的备份或实时同步软件(如: SharePlex和DSG), 都会受到一定的影响. 而Log格式的研究, 要想出成果, 也只有在这一方面, 要是在上世纪90年代中或末期开始研究, 则情况就大不相同了. 但是我还是一直想研究的, 在这样的研究中, 关键是可以找到一些乐趣. 但研究Log这事不能过急, 从上次决定要继续研究, 到现在已经有快一个月了, 没有花什么时间. 只是在昨天晚上花了一个小时, 改进了一下MyLOG工具, 这个工具现在还和Log挂不上一点边, 因为现在仅支持以下几个命令. 1, HELP. 显示帮助信息 LOG> help SET -- change the...
Oracle的实体化视图(MVIEW)的深入研究之四
现在对第一篇中基表进行移动(Move)操作, 会发现不能进行快速刷新, 必须进行全部(Complete)刷新才行. 如下所示: SQL> ALTER TABLE T_MVLOG MOVE; Table altered. SQL> EXEC DBMS_MVIEW.REFRESH('MV_T_MVLOG','FAST'); BEGIN DBMS_MVIEW.REFRESH('MV_T_MVLOG','FAST'); END; * ERROR at line 1: ORA-12034: materialized view log on "ANYSQL"."T_MVLOG" younger than last refresh ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803 ORA-06512:...
Oracle的实体化视图(MVIEW)的深入研究之三
在Oracle中创建视图时, 如果我们用了"*"符号, 会被自动地根据当时表的定义扩展成字段列表, 在后面再加列时, 新的列不会自动出现在视图的定义中, 直到你重建视图为止. 那么在MVIEW中呢, 通过一个不经意的操作, 发现一个有趣的问题. 总之, 不要随便地在实体视图的定义中使用"*"号. 下面我们在一个表上建两个实体化视图, 角本如下: CREATE TABLE T_MVTEST AS SELECT * FROM TAB; CREATE MATERIALIZED VIEW LOG ON T_MVTEST WITH ROWID,SEQUENCE; CREATE MATERIALIZED VIEW MV_TEST_STAR REFRESH FAST WITH...
Oracle的实体化视图(MVIEW)的深入研究之二
当在一个表上建了物化视图的日志(Materialized View Log)后, 所有的DML操作都会被相应地记录到物化视图日志表(MLOG$_)中, 如果想对这个表进行操作, 但不想这些操作被记录到日志(MVIEW LOG)中, 应当怎么办呢? 在DBMS_MVIEW包中有两个过程可以用来完成这个要求. 这里我们需要打开两个会话, 其中一个会话以DBA的身份登陆(Session DBA), 另一个会话随便了(Session USER), 按如下次序来进行操作: 在Session USER中先运行以下语句去看一下MVIEW LOG表中有多少条记录: SQL> SELECT count(*) FROM MLOG$_T_REORG; COUNT(*) ---------- 0 在Session DBA中运行BEGIN_TABLE_REORGANIZATION过程开始维护, 记得执行完后要运行COMMIT命令, 否则会阻塞(Block)别的进程: SQL> exec dbms_mview.begin_table_reorganization('ANYSQL','T_REORG');...
将继续进行对Oracle Log文件的研究
两前以前的这个时间, 我刚刚完成了AUL/MyDUL的第二版本, 到现在已经很成熟了, 那么接下来要研究什么呢? 我想来想去只有继续进行对Oracle日志文件的研究了. 过去的一年半时间中, 我断断续续地进行过一些研究, 但没有什么成果. 早期曾经设想过开发一个Log有关的免费工具, 用于对Log文件的格式进行分析, 2007年是时侯向这个方面入手了. 在数据文件研究的过程中, 发现开发一个工具来研究Log格式是有必要的, 边开发边研究, 循环地进步. 今天晚上做出了一个原型, 还是一个命令行的工具, 界面如下所示: MyLOG : AnySQL Log Analyzer for Oracle 8i/9i, release 1.0.0 (C) Copyright Lou Fangxin 2007 (AnySQL.net), all rights...