分类目录归档：Internal

DUL第二篇——使用DUL抽取dmp文件内容

发表于 2014 年 6 月 8 日 由 Lunar

dul常用命令： DUL> unload database ; DUL> unload user ; DUL> unload table ; DUL> scan database; DUL> scan tables; 记录一下测试表的记录数目： 其余的配置参数，参考第一篇DUL 第一篇 —— DUL是什么？ 启动DUL，然后直接执行unpump header，之后就可以抽取了： 这里我们看到17634 行记录全部抽取出来了，如果你想测试的更好玩，可以dd掉其中的一部分数据，然后测试看dul怎么工作。 然后直接导入数据，就这么简单，O(∩_∩)O哈哈~ 这里我们看到全部的17634 行数据都导入表中了。

发表在 DUL ODU | 标签为 , | 2 条评论

DUL 第一篇 —— DUL是什么？

发表于 2014 年 6 月 8 日 由 Lunar

最近打算陆续研究一些DUL的东西，这个在互联网上已经有太多了，我本人用的不多，主要是确实很多时候用不上（运维做得好，这些其实都几乎用不上……） 不过这些东西涉及了很多对于Oracle的运行机制和原理的理解，玩玩还是很有意思的 ：） DUL是Oracle Internal工具，专供Oracle Support使用，请勿自行在工作环境操作，否则后果自负！！ 第一篇 DUL是什么？

发表在 DUL ODU | 标签为 | 留下评论

bbed会产生cr块么？

发表于 2014 年 5 月 11 日 由 Lunar

先说下结论，bbed不会产生cr块，具体请看测试结果： 这个结论我的测试不知道是不是科学或者完整，因此，有不同结论的测试，欢迎交流，O(∩_∩)O哈哈~ 在没有flush buffer cache的情况下，我们看看： 上面这段信息基本跟X$BH的内容对应。 这里，表示file 4 block 131是object_id为18222的对象的一个块（st: XCURRENT，即当前块），该块作为class 1 block被prefetch（class 1表示数据块，比如如果这是是class 8，就表示1st level bmb ，如果是3就表示3级位图块等等……） 这个块是脏块（buffer_dirty）。同时，在LRU链表的末端有一个该块的CR块，在辅助链表还有一个该块的副本（FREE状态，表示跟数据文件上该块的是一致的）。 其中LRU_FLAG的解释如下： KCBBHLDF 0x01 8.1 LRU Dump Flag used in debug print routine KCBBHLMT 0x02 8.1 moved to tail of lru (for … 继续阅读 →

发表在 Internal | 留下评论

浅谈Oracle非常规恢复

发表于 2014 年 4 月 27 日 由 Lunar

一直以来，类似非归档无备份的数据库损坏，或者备份不可用，或者用备份恢复因为时间太长或者空间限制等等原因制约，非常规恢复一直是我们不能扔掉的救命稻草，在这个方面我并不擅长，但是一直都很喜欢。 记得2001年前后，我第一次有兴趣想要认真学习一下Oracle（以前做开发相关比较多，菜鸟dba），在还没有了解Oracle备份恢复的机制时，忘记为什么首先接触了Oracle 817的Standby，一周内完整的读了一遍文档，动手搭建了两个，并记录在ITPUB和我自己的blog上，很有成就感，而那时，我还没有意识到，其实Standby 的本质就是数据库的备份和恢复的完美结合。 后来有机会作为dba参加一个公司（在当时没觉得公司小，但是只有我一个菜鸟dba，O(∩_∩)O哈哈~）的一个海外项目，是做一个3节点Oracle 817 OPS 克隆数据库的事情，当时我还不熟悉RMAN，使用dd裸设备的方式完成了任务。这个项目之后，我开始迷上Oracle的备份和恢复，并且开始玩rman了。 迄今为止，我还是认为数据库备份恢复是学习Oracle的最佳入口，因为很多时候你可以方便的模拟场景，并研究恢复，在一个个案例中，学习和了解更多internal的原理。当然，任何时候官方文档都是第一步，没有这个基础，很多都如同空中楼阁。 还有一点，一个好的架构设计、备份恢复策略和灾备设计都是最好的选择，这个是毋庸置疑的。 但是中国大量D版客户，尤其是小客户中太多情况下是没有专业的设计，出了问题，非常规恢复的手段就是救命稻草了。 下面的ppt就是去年一个客户在备份不可用的情况下，花“巨资”请人做了非常规恢复后，找我们去做的一次交流，客户要求的主题就是“非常规恢复”： 浅谈Oracle非常规恢复-lunar

发表在 backup&recovery, Internal | 标签为 , , , , , , | 留下评论

Exadata上HCC表的数据块结构—3-HCC块（compress for query low）

发表于 2014 年 3 月 23 日 由 Lunar

关于EHCC表的测试参见： Exadata上的HCC测试（EHCC）——1 Exadata上的HCC测试（EHCC）—2—：DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试（EHCC）—3—分区表的压缩 HCC（Hybrid Columnar Compression ）是数据以CU（compression units ）的方式存储，一个CU是由一组连续的block组成的，比如常见的是32k（即，4个连续的8k的block）。每个CU内部都是按列存储的数据，每一列都分别进行压缩，但是每一行数据都可以在一个CU内完全找到。 下面以”compress for query low”为例的数据块为例： 这次测试只dump了一个数据块，因此，不是一个很理想的说明，下次测试我会每个表多dump一些block，再加上表数据的内容，进行对比分析，这样才清晰。O(∩_∩)O哈哈~

发表在 Internal, 内部机制 | 标签为 , , | 留下评论

Exadata上HCC表的数据块结构—2-BASIC Compress和OLTP Compress

发表于 2014 年 3 月 23 日 由 Lunar

OLTP 和 BASIC的压缩是符号表（a symbol table）的方式，老熊的blog已经讲的很清晰了，我怎么也不可能比老熊讲的清晰，不赘述了，看图：

发表在 Internal, 内部机制 | 标签为 , , | 留下评论

Exadata上HCC表的数据块结构—1-非压缩数据块结构

发表于 2014 年 3 月 23 日 由 Lunar

普通表的数据块结构网上已经铺天盖地了，我就不赘述了，看图：

发表在 Internal, 内部机制 | 标签为 , , | 留下评论

研究数据字典和基表，发现处理手工删除fs$或者file$等问题的新思路

发表于 2014 年 3 月 10 日 由 Lunar

在测试环境玩什么东西忘记了，反正是忽然发现有个没用的表空间“UNDOTBS1”删除不掉，以前写过一篇，如何查找某个对象的定义（V$_X$_DBA）， 这里重温一下数据字典和动态性能视图： UNDOTBS1在v$tablespace中可见，但是不能drop，在dba_tablespaces中不可见，说明数据字典和动态性能视图不匹配了（手工删除了基表导致的，忘记是删除了ts$还是file$内容了）： 不得不说Oracle 11.2.0.3以后的版本，对于数据库的一致性校验进行了很人性化的改动，以前这种情况是crash的，现在还open着，带病工作，O(∩_∩)O哈哈~ 类似的带病工作的情况，还涉及到很多数据字典的不一致情况，比如以前的i_dependency1, i_dependency2等等。 从这个研究，也证实了如下结论: V$TABLESPACE的信息是来源于GV$TABLESPACE，GV$TABLESPACE来源于基表 X$KCCTS 而DBA_TABLESPACES是来源于 SYS.TS$ TS 和 SYS.X$KCFISTSA。也就是说，V$TABLESPACE的信息来源于控制文件，而DBA_TABLESPACES的信息是来源于其他基表，手工删除基表信息时，其信息不和控制文件信息同步。 下面有具体看看： 看下创建动态性能视图的语句： 通过上面建库脚本也可以清晰的看到，得到授权的普通用户仍然只能访问V$开头的视图，而不能直接访问V_$开头的视图，因为实际上V$视图是V_$视图的公有同义词（PUBLIC SYNONYM）要想访问V_$必须带上SYS.V_$，例如 而查看普通的DBA_ ALL_ USER_ 等视图，可以查看数据字典 dba_views（这个视图从8i开始引入的） 例如： X$ 是 Oracle 数据库 的核心部分，这些表用于跟踪内部数据库信息，维护数据库的正常运行。 X$ 表是加密的（除了MOS和直接看源代码以外，我不知道还有什么方法可以查看X$视图） Oracle 通过 X$和一些基表（TS$, OBJ$, SEG$等）建立起其他大量视图，提供用户查询和管理数据库。 在9i以前 另外，还可以通过X$KQFTA来查看X$表的相关信息： 类似，就是11.2中新引入的X$表： … 继续阅读 →

发表在 FAQ, Internal | 标签为 , , , , | 留下评论

艰难的修复数据库过程，却发现Oracle 11.2果然强大

发表于 2014 年 1 月 5 日 由 Lunar

具体参见: http://t.askmaclean.com/thread-3790-1-1.html http://www.itpub.net/thread-1839128-1-1.html 纯属自娱自乐，没有实际意义的，顺便说下我的发现和测试中的发现（虽然到现在为止数据库还没有open，我还会继续鼓捣他，毕竟还有些方法还没用上，O(∩_∩)O哈哈~。。。）; 首先就是11.2太强大了，很多时候以往的错误都可以fixed，数据库可以open后，做很多跟损坏先关的check 1， 从11.2开始，控制文件自动备份完成的信息由m000完成，且他还完成很多其余工作，当然，只在别的进程触发的时候，他才会去工作 2，DBA_TABLESPACE和V$TABLESPACE的来源不同，一个来源于控制文件，一个来源于基表ts$ 3，ts$和file$不能跳号 4，DBMS_HM很强大（Health Manager），他会定期检查数据库的很多东西，然后让m000进程写trace 。。。 主要的测试步骤已经不太都记得了，但是主要模拟步骤如下： 我的环境： db 11.2.0.3 OEL 5.8 1，创建2个表空间（其实1个也可以，几个都行，为了看得更加清晰），然后切换日志，然后在OS上讲包括UNDOTBS在内的这些数据文件（普通的数据文件和undo的数据文件就可以） 2，启动数据库的时候，你会发现，报错说文件丢失或者损坏，这时你offline drop掉这个报错的文件，数据库应该就可以打开，当然后台有m000生成的trace，HealthManager会不断的触发m000把所有其余随坏的信息都写入trace 3，想办法清理undo$中的问题回滚段 4，创建新的普通数据的表空间，例如“UNDTBS333”，但是设置UNDO_TABLESPACE=这个普通的表空间（scope=spfile），然后启动数据库————–这时我当时的第一个误操作 5，数据库报错，具体忘记了，怎么解决的也忘记了，印象中无非就是undo的隐含参数等等，然后创建正确的undo表空间（create undo tablespace …）给数据库使用 6，解决后，数据库可以正常open，delete from fs$ where name=‘你曾经误操作的那个普通数据表空间 UNDTBS333’，这么做是因为当时我没有仔细考虑风险，因此，手工清理了 其实如果全部都是手工做的话，也可以的，后面发现了需要手工清理什么，但是当时确实么有想太多，误操作了。。。 7，其实这样数据库也还是可以open的，没有太大问题，我用DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)检查，其实这时数据库只有undo$, ts$ 和file$数据不一致，没有影响其他数据对象（因为测试过程没有添加用户测试数据） … 继续阅读 →

发表在 backup&recovery, Internal, Oracle 11.1 & Oracle11.2 | 标签为 , | 留下评论

浅谈SCN_2–_kcmgas_函数

发表于 2013 年 8 月 22 日 由 Lunar

从oracle10g开始，我们可以通过查询v$database.current_scn来获取当前数据库的scn，这个是通过调用”kcmgas”函数来完成的，这是一个oracle intance的永久内存结构体，我们可以查询 v$syssta来观察该函数的调用情况： 先看对v$database.current_scn的查询来获取scn的方式： 详细描述请见：浅谈SCN_2-_kcmgas_函数 姊妹篇见:浅谈SCN_1–从oracle7至今，如何获取scn

发表在 Internal | 标签为 , | 留下评论