月归档：2014 年十二月

根据块号查看块内数据和修改时间的例子（普通表和压缩表）

发表于 2014 年 12 月 18 日 由 Lunar

今天微信群里有个朋友问起一个问题，顺手做了个测试。 问题是这样的： 1，怎么根据file# block#来判断这个block中有多少数据？ 2，启用了高级压缩后，如何查看？ 3，怎么判断这些数据插入的时间？ 4，不适用dump block的形式，可以怎么观察？ 最后一个问题不用测试了，不用dump的话，可以使用类似bbed等一堆工具，还可以使用event 10046跟踪来观察。 本次始终压缩相关的脚本可以参考blog： Exadata上的HCC测试（EHCC）——1 Exadata上的HCC测试（EHCC）—2—：DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试（EHCC）—3—分区表的压缩 关于HCC压缩的块结构参见： Exadata上HCC表的数据块结构—1-非压缩数据块结构 Exadata上HCC表的数据块结构—2-BASIC Compress和OLTP Compress Exadata上HCC表的数据块结构—3-HCC块（compress for query low） 前三个问题，一次测试如下： 因为朋友问到ASM的情况，这个需求实际上跟是否使用ASM无关，是ORACLE DB的原理，测试环境如下： 随便找一个block，或者指定一个block都可以： 查看这个block中有多少条数据： 这里看到，目前这个block中存储了88行记录。 查看这88行数据是什么时间插入的，以及他们的ROWID： 这里看到有88行，跟前面的结果是一致的。 看看这个表中有多少个block，以及他们的块号： 因为要测试压缩，那么先看看现在该表的压缩状态，这里我的LUNAR表是没有压缩的： 这里的查询方法，参考： 现在启用压缩（HCC只能在exadata上，否则会报错）： 再次查询，可以看到，已经是高级压缩了： 这里可以看到，rowid已经改变了，这是因为块的存储格式已经变化了： 看下现在这个LUNAR表使用了哪些block： 这里看到比刚才已经减少了17-12=5个block。 查询每个block中的记录数： … 继续阅读 →

发表在 Internal, 内部机制 | 标签为 , | 一条评论

通过修改控制文件来修改SCN

发表于 2014 年 12 月 14 日 由 Lunar

之前有一些简单介绍SCN的文章： 浅谈SCN_1–从oracle7至今，如何获取scn 浅谈SCN_2–_kcmgas_函数 使用ORACDEBUG 修改 数据库SCN 这个测试是接着上次的使用oradebug修改SCN的，这里使用修改控制文件SCN和相关标示位的方法： 这个测试，我们把SCN增加100万，即从 2726293 修改为 3726293。 查看当前控制文件的位置： 将控制文件拿到本地，进行修改，修改过程如下： 首先找到数据库SCN： 修改SCN和相关标示位： 讲数据库shutdown，然后将修改后的控制文件copy到ASM中，并使用这个控制文件启动数据库： Mount数据库，并查看数据库SCN： 这里我们看到，数据库的SCN已经修改为我们指定的 3726296了。

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

使用ORACDEBUG 修改 数据库SCN

发表于 2014 年 12 月 14 日 由 Lunar

之前有一些简单介绍SCN的文章： 浅谈SCN_1–从oracle7至今，如何获取scn 浅谈SCN_2–_kcmgas_函数 通过修改控制文件来修改SCN 1988年Oracle发布了Oracle V6，这一版本中Oracle引入了热备的操作，同时SCN使用48位存储的算法写死在代码中，一直沿用至12c以前（12c开始使用8个bytes存储SCN）。由于ORACLE的SCN是由48位来表示的，因此最大值不能超过2的48次方 Oracle为了确保48位的SCN能够用足够长的时间（500年），于是对SCN做出了一个限制，就是每秒钟SCN最大增长不能超过16K，Oracle从1988年1月1日0点0分0秒为基准时间，到当前的秒钟数乘以16K，就是当前SCN的最大允许值这就是SCN HEADROOM。 因此SCN天花板 的计算公式就类似于： (当前时间-19880101 000000)*16384–(current_scn)，其中 16384是SCN的内部增长速度16k，这是代码中的硬限制。 这个限制在11.2.0.2版本之前，scn 的最大增长频率是16k,在11.2.0.2版本开始，为32k。 此行为是受到下面参数_max_reasonable_scn_rate控制的： 在11.2中，Oracle除了将SCN 每秒最大的增长量从16K加大为32K，还引入了一个阀值，用于阻断有SCN HEADROOM问题的系统将故障传播到其他系统。 这些修复包含在下列补丁中： 如果SCN发生突增的情况，alert中就会出现类似下面的告警： 因此，打了这上面这些补丁后，就不能使用以前的参数直接修改SCN了。 然后，有时候数据库遇到一些异常错误，还是需要将SCN推进的到一个合适的值，例如，常见一些错误造成数据库的部分block跟数据库SCN不一致，或者一些有undo$数据库启动时引导失败： ORA-600 [2256] ORA-600 [2662] ORA-600 [4000] ORA-600 [kcsadjn1] 在以前我们使用参数来修改SCN，例如： event=”10015 trace name adjust_scn level x” 或者使用 _minimum_giga_scn … 继续阅读 →

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