比如，在节点添加之前，goldengate map log threads顺序如下(数据库log thread在后，下同)：

         1—>1 (假设是sequence 100，rba 1001)

         2—>2(假设是sequence 88，rba 3009）

        当添加节点后，map log threads的顺序会变成：

        1—->3(sequence 88，rba 3009）

        2—->1(sequence 100，rba 1001)

        3—->2(new)

        当ogg重新工作的时候，因为此时map的顺序发生了变化，因此会造成抽取进度出现问题。

        如果有足够的处理时间，简单而又安全的做法是停止源端应用，删除extract进程后，重新配置新的extract进程并从当前开始抽取。但在这段时间内，所有的操作需确保在应用已经停止服务的前提下，否则数据将造成丢失或者不一致，需要手工处理或者重新初始化。

        如果应用无法停机呢？我们可以将新建的extract进度修改成停止之前的进度状态，从而避免操作过程中应用的停机行为。

        需要我们特别记录的checkpoint有：Current Checkpoint、Recovery Checkpoint以及Write Checkpoint

1.正常停止extract(略)

2.获得extract的checkpoint记录

  GGSCI (node1) 21> info ext_r1 showch

EXTRACT    EXT_R1    Last Started 2011-08-16 22:35   Status STOPPED
Checkpoint Lag       00:00:00 (updated 00:06:21 ago)
Log Read Checkpoint  Oracle Redo Logs
                     2011-08-17 03:32:48  Thread 1, Seqno 62, RBA 29890576
Log Read Checkpoint  Oracle Redo Logs
                     2011-08-17 03:32:34  Thread 2, Seqno 42, RBA 18674704

Current Checkpoint Detail:

Read Checkpoint #1

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source):
    Thread #: 1
    Sequence #: 61
    RBA: 32112656
    Timestamp: 2011-08-16 22:34:53.000000
    SCN: 0.3743980 (3743980)
    Redo File: +DATA1/my/onlinelog/group_1.261.758327805

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Thread #: 1
    Sequence #: 62
    RBA: 29890576
    Timestamp: 2011-08-17 03:32:48.000000
    SCN: 0.3811675 (3811675)
    Redo File: +DATA1/my/onlinelog/group_2.262.758327805

  Current Checkpoint (position of last record read in the data source):
    Thread #: 1
    Sequence #: 62
    RBA: 29890576
    Timestamp: 2011-08-17 03:32:48.000000
    SCN: 0.3811675 (3811675)
    Redo File: +DATA1/my/onlinelog/group_2.262.758327805

  BR Previous Recovery Checkpoint:
    Thread #: 1
    Sequence #: 0
    RBA: 0
    Timestamp: 2011-08-16 22:35:09.416136
    SCN: Not available
    Redo File:

  BR Begin Recovery Checkpoint:
    Thread #: 1
    Sequence #: 62
    RBA: 22437392
    Timestamp: 2011-08-17 02:35:11.000000
    SCN: 0.3798208 (3798208)
    Redo File:

  BR End Recovery Checkpoint:
    Thread #: 1
    Sequence #: 62
    RBA: 24120320
    Timestamp: 2011-08-17 02:35:16.000000
    SCN: 0.3801192 (3801192)
    Redo File:

Read Checkpoint #2

  Oracle RAC Redo Log

  Startup Checkpoint (starting position in the data source):
    Thread #: 2
    Sequence #: 41
    RBA: 25323024
    Timestamp: 2011-08-16 22:34:40.000000
    SCN: 0.3743980 (3743980)
    Redo File: +DATA1/my/onlinelog/group_3.266.758328125

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Thread #: 2
    Sequence #: 42
    RBA: 18674704
    Timestamp: 2011-08-17 03:32:34.000000
    SCN: 0.3811674 (3811674)
    Redo File: +DATA1/my/onlinelog/group_4.267.758328125

  Current Checkpoint (position of last record read in the data source):
    Thread #: 2
    Sequence #: 42
    RBA: 18674704
    Timestamp: 2011-08-17 03:32:34.000000
    SCN: 0.3811674 (3811674)
    Redo File: +DATA1/my/onlinelog/group_4.267.758328125

  BR Previous Recovery Checkpoint:
    Thread #: 2
    Sequence #: 0
    RBA: 0
    Timestamp: 2011-08-16 22:35:09.416136
    SCN: Not available
    Redo File:

  BR Begin Recovery Checkpoint:
    Thread #: 2
    Sequence #: 42
    RBA: 15242240
    Timestamp: 2011-08-17 02:35:02.000000
    SCN: 0.3800455 (3800455)
    Redo File:

  BR End Recovery Checkpoint:
    Thread #: 2
    Sequence #: 42
    RBA: 15242240
    Timestamp: 2011-08-17 02:35:02.000000
    SCN: 0.3800455 (3800455)
    Redo File:

Write Checkpoint #1

  GGS Log Trail

  Current Checkpoint (current write position):
    Sequence #: 3
    RBA: 51132
    Timestamp: 2011-08-17 03:32:48.695373
    Extract Trail: /opt/ggs/dirdat/r1/ex

Header:
  Version = 2
  Record Source = A
  Type = 6
  # Input Checkpoints = 2
  # Output Checkpoints = 1

File Information:
  Block Size = 2048
  Max Blocks = 100
  Record Length = 4096
  Current Offset = 0

Configuration:
  Data Source = 3
  Transaction Integrity = 1
  Task Type = 0

Status:
  Start Time = 2011-08-16 22:35:10
  Last Update Time = 2011-08-17 03:32:48
  Stop Status = G
  Last Result = 402

3.新建extract进程。

GGSCI (node1) 34> ADD EXT ext_r1, BEGIN NOW, TRANLOG, THREADS 3

2011-08-17 03:52:26  INFO    OGG-01749  Successfully registered EXTRACT EXT_R1 to start managing log retention at SCN 3826107.
EXTRACT added.

4.修改current checkpoint (注意每个thread都要修改)

GGSCI (node1) 35> alter EXTRACT ext_r1, TRANLOG, EXTSEQNO 62, EXTRBA 29890576,thread 1
EXTRACT altered.

GGSCI (node1) 36> alter EXTRACT ext_r1, TRANLOG, EXTSEQNO 42, EXTRBA 18674704,thread 2

EXTRACT altered.

5. 修改recovery checkpoint (注意每个thread都要修改)

GGSCI (node1) 42> ALTER EXTRACT ext_r1, IOEXTSEQNO 62, IOEXTRBA 29890576,thread 1

GGSCI (node1) 42> ALTER EXTRACT ext_r1, IOEXTSEQNO 42, IOEXTRBA 18674704,thread 2

6. 修改exttrail或者rmttrail的write checkpoint

GGSCI (node1) 47> ADD EXTTRAIL /opt/ggs/dirdat/r1/ex,SEQNO 3, RBA 51132, EXTRACT ext_r1
EXTTRAIL added.

7. 验证checkpoint是否修改成功(使用showch,略)

8.重新启动extract(略)

• goldengate培训提纲<一>

        处理的办法还是不少的，下面给出一个在replicat端过滤SCN事务的办法，来实现数据的一致同步。

        处理的思路就是首先在target上获得该表上某个特定SCN版本上的数据(比如使用导入导出或者数据泵)，然后通过filter功能来筛选出该表上大于该commit scn的事务，从而确保事务的一致性。在goldengate v10之后，可以通过@GETENV函数直接获得事务的CSN。 

         简单看一下处理步骤，假设目前gg环境中hr.translog表需要重新初始化，由source端hr用户同步到target端hr2用户下。

         1.停止target上的replicat进程

GGSCI (sh) 44> stop rep_hr2

Sending STOP request to REPLICAT REP_HR2 …
Request processed.

        2.获得source上hr.translog表的特定SCN一致性版本

SQL> select dbms_flashback.get_system_change_number from dual;

9543774

        使用exp进行一致性版本导出

[oracle@gz ~]$ exp hr/hr tables=translog file=translog.dmp flashback_scn=9543774

Export: Release 10.2.0.1.0 – Production on Tue Aug 9 00:27:42 2011

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)

About to export specified tables via Conventional Path …
. . exporting table                       TRANSLOG      5062409 rows exported
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.

        3. target上导入一致性版本

[oracle@gz ~]$ imp hr2/hr2@sh tables=translog file=translog.dmp ignore=y

Import: Release 10.2.0.1.0 – Production on Tue Aug 9 00:28:36 2011

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options

Export file created by EXPORT:V10.02.01 via conventional path

Warning: the objects were exported by HR, not by you

import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
. importing HR’s objects into HR2
. importing HR’s objects into HR2
. . importing table                     "TRANSLOG"      50624 rows imported
IMP-00017: following statement failed with ORACLE error 30567:
"ALTER TABLE "TRANSLOG" ADD SUPPLEMENTAL LOG GROUP "GGS_TRANSLOG_56459" ("OB"
"JECT_ID") ALWAYS"
IMP-00003: ORACLE error 30567 encountered
ORA-30567: name already used by an existing log group
Import terminated successfully with warnings.

        4. 修改replicat参数，过滤hr.translog上小于SCN 9543774上的事务。

GGSCI (sh) 43> view param rep_hr2

replicat rep_hr2
USERID gg, PASSWORD AACAAAAAAAAAAACANJPHHDSJCIYCFCZB,ENCRYPTKEY DEFAULT
assumetargetdefs
map hr.translog, target hr2.translog, filter (@GETENV ("transaction", "csn") > 9
543774);
map hr.org, target hr2.org;

map hr.unp_file, target hr.unp_file;

       5. 启动replicat进程

GGSCI (sh) 2> start rep_hr2

Sending START request to MANAGER …
REPLICAT REP_HR2 starting

      采用这种办法，即使source上hr.translog表不断被DML，因为SCN过滤的存在，保证了复制过程中的数据一致性。对source上的应用来讲，也无须额外的停机时间。在初始化过程中，因为target上复制进程的暂停，会影响到复制的实时性， 为减少target上replicat的暂停时间，可以采用分割datapump和replicate group的方法，也可实现特定对象的在线初始化，具体参考goldengate–split replicat group在线重新初始化指定的table

• No Related Post

      如果事务不间断进行，如何保证初始化过程中事务的完整性和数据的准确性呢(静态的初始化环境无需多讲)？实现方法还是多样的，从工作机制上来讲，归纳起来主要有2种。

     1. 利用 Keys + Handlecollisions

     2.利用 commit SCN/CSN

        Handlecollisions参数依赖于表上的Key(Primary key/Unique key)来对数据进行重复行和缺失行的处理，常在数据初始化过程中保证数据的一致性，gg文档上的初始化办法，比如initial load，都是用的这种办法。但是这种办法在实际的工程实施中是有相当大的限制。

        首先，该初始化办法性能比较糟糕，对于大型数据库来讲，并不合适。更严重的是，它有很大的缺陷性。(引自metalink doc)：

1. When there is primary key update (PKUpdate), the HANDLECOLLISIONS method may lose data. The solution in the case of a primary key update is for Extract to fetch whole row by making a flashback query. However, this is not efficient and may not be possible in certain environments.

2. When a table does not have any type of key, HANDLECOLLISIONS may introduce duplicate rows in the table. One workaround is to add a primary or unique key to the target table.

3. The exact timestamp when the initial load was started may not be known (and different tables may have different start times), so it is almost inevitable that HANDLECOLLISIONS will be used for certain records un-necessarily. This could mask a real data integrity problem.

         在实际的工程实施中，个人不推荐使用基于Keys + Handlecollisions模式的初始化办法。

         那么基于commit SCN的初始化办法是否可靠呢？如果你用过逻辑备库，Stream等东西，退一步讲，抑或是做过一致性的导入导出，应该很清楚SCN在版本一致性方面的重要作用。

         问题简单化，goldengate初始化的的核心问题就变成了如何联机进行基于SCN一致性的同步。实现的工具和方法还是不少的。

1. 一致性的exp和imp

2. 一致性的expdp和impdp

         通过exp和expdp的一致性参数(例如flashback_scn)，导出特定SCN点上的一致性版本，使用这种方法初始化存在一个问题，就是构造一致性数据过程中会对undo造成比较大的压力，尤其对大型数据库来讲，可以通过分割的datapump来实现数据的分组同步，分散undo的压力，然后合适时间将分组的datapump合并即可。

       该方法的优点就是可以跨平台和跨版本初始化。

3. 基于备份的表空间搬移（Transportable Tablespace from Backup with RMAN）

         为何是基于备份的表空间搬移呢? 单纯的表空间搬移需要数据库或者表空间read only，copy数据文件的这段时间应用是需要停止的，因此表空间搬移并不适合7*24小时的初始化环境。

         基于备份的表空间搬移的一个最大的优势就是零停机，而且支持异构平台和跨版本（对于不同字节顺序的source-target平台初始化，需要进行convert），但是需要10g以上版本才支持，同样受到表空间搬移的那些限制条件。

4. Dataguard

           Dataguard适合同平台同版本的系统环境初始化。

         当然，在实际工程中，还会有别的一些处理办法，或者各种办法之间有交融，作为方案制定者和实施者，你所能驾驭的，就是对你来说合适的。

• No Related Post

     一连实施了好几个goldengate的项目,关注ogg也有好些时日了。这是前不久应客户要求做的goldengate的培训，share一下。因为用户只是应急容灾的应用，因此ogg上的很多功能当时并没有提及。接下来的blog会持续整理goldengate的一些问题和技巧。

第一篇 Oracle Goldengate基础技巧

第一节 Goldengate体系介绍

1. Goldengate架构

2. Goldengate工作原理

3. Goldengate使用场景

第二节 安装配置Goldengate

1. 安装Goldengate软件

2. 配置和管理进程

3. Goldengate的安全加固手段

第三节 Goldengate数据初始化

1. 基于keys+HANDLECOLLISIONS初始化

(1) keys+HANDLECOLLISIONS的工作原理和缺点

(2) direct load的局限性和操作步骤

2. 基于SCN consistent初始化

(1) 基于SCN初始化的工作原理和特点

(2) 基于Exp/imp和expdp/impdp一致性初始化使用场景和步骤

(3) 基于transport tablespace with backupset初始化使用场景和步骤

(4) 基于Dataguard模式的初始化使用场景和步骤

第四节 DML常规复制

1. DML复制的工作原理

(1) Keys对rows复制处理的影响

(2) 追加Column日志对rows复制处理的影响

(3) DML复制的支持类型

2.DML错误处理

(1) Extract端参数的使用

(2) REPERROR的高级用法

(3) exceptions table的使用

第五节 DDL复制的高级技巧

1. DDL复制的工作原理

(1) DDL复制工作机制

(2) DDL复制的支持类型

(3) DDL复制对现有复制环境的影响和冲突

2. DDL复制处理技巧

(1) DDL scopes的使用

(2) DDL过滤技巧

(3) DDL 字符替换的技巧

(4) DDL复制中delivery object/password等行为说明

3. DDL错误处理

(1) Extract 端的参数控制

(2) DDLEEOR的高级用法

第六节 数据操纵

1. 数据操纵对现有复制环境的限制和影响

2. 行数据过滤

(1) Filter行过滤的使用场景和用法

(2) Where行过滤的使用场景和用法

3. 列处理

(1) colmap的使用技巧

(2)colmatch的使用技巧

(3) data-definition的使用技巧

(4) 列转换函数介绍

4. DML类型处理

(1) DML类型过滤

(2) DML类型转换

5. 事务信息提取

(1) 事务信息抽取的意义和使用场景

(2) 相关的function以及用法(token/getenv)

6. SQLEXEC的使用

第二篇 Oracle Goldengate工程与运维技巧

第一节 实施与规划

1. 应急/实时同步场景的规划

(1) 如何选择初始化办法

(2) 复制对象的特别处理(Sequence/Trigger/FK)

(3) 应急切换处理办法

2. 数据分发/数据稽核场景的规划

3. 双向同步的规划和数据冲突处理

4. RAC场景中的注意点

5. ALO模式的限制和使用

6. Goldengate升级要点

第二节 日常运维

1. 日常监控的设计

2. Process abort的一般诊断步骤

3. 重新初始化指定object的方法

4. Logdump排查异常transaction的使用

5. 提高复制性能的参数使用

• RAC环境中threads变更后如何确保goldengate继续正常复制

       成长会让理性变成习惯，但感性亦不会荡然无存。

      恋上了随遇而安，却总爱奢华的瞻望。当踮起脚尖的时候，已然望不到尽头，剩下了就是不安与惶恐。这种惶恐近来愈发强烈，却着实不得不面对。岔路口上，或左或右需要是睿智；而坡路上，迎面总好过退缩。瓶颈虽不会无处不在，但却很难让它无处遁形。惶恐之由，想罢是生性中最脆弱的一面又蠢蠢欲动，夹杂着诸多不尽人意，难免碰触到最敏感的神经。

      漂泊了4个半年头后，在广州算是有了个尚未交付的栖息之所。心情沉重了很多，决非释然。想来这是一种微妙的感觉，诸如我们这般琐居的外乡人，独自飘零，兀自找寻。即便有了归属，心又归于何处。

      好好对待身边的人，朋友，亲人。谢谢陪伴自己一路走过的人。

      责任当是种爱的感知和传递。花自漂零，怡然前行。

                                                                                                                                             ——2011.3.22 广州

• No Related Post

1. Primary Database > Physical Standby Database with cascaded destination > Physical Standby Database
2. Primary Database > Physical Standby Database with cascaded destination > Logical Standby Database

     Cascaded Destinations的用处还是比较多的，例如使用dataguard做远程容灾的场景，使用Cascaded Destinations就远比local primary和romote standby直接做dataguard可靠。基于WAN上的dataguard的一个致命问题就是主备端的网络质量问题，这将对主端产生严重的影响，尽管可以通过async的方式来进行redo或者archive的传送，但在一个繁忙的系统中，这仍然是个极大的性能和稳定性隐患。通过Cascaded Destinations，redo/archive log的同步放到了local physical standby端上进行，主库产生的日志先传送到local standby，然后由local standby负责传送日志到remote standby。

       对于10g版本以上的该模型，通过日志传输参数VALID_FOR的功能，通过角色控制priamry/standby向remote database的日志传送，这样日常中local dataguard的switchover并不影响remote standby的同步且操作上更加平滑，另外，remote standby端配合Flashback Database，这样也避免了因为WAN上带宽有限，local database的Failover造成的remote standby的重建带来的数据传输问题。

       需要特别提出的是cascaded standby databases中的FAL的配置问题，正常情况下最后一级standby的日志是从上级standby上取得，并非直接从primary上传输，但特别情况下可直接由Primary向最后一级standby传送。如果最后一级standby的fal_server配置对应primary database和上级standby database，那么可能出现这么一种情况需要注意：上级standby database的对应的归档日志已经apply但已经不存在(比如被删除)，因为下级 standby database存在一系列问题，恢复进度并没有赶上日志的传送速度，当正好需要上级standby上这部分log的时候，发现从上级standby上已经无法获得，这时候通过fal_server的配置可直接从primary向最后一级standby上传输，而不需要中转。

      Metalink doc上也相关记录如下：

If primary receives a FAL request from the remote standby in the above case then It ships the archive logs directly to the remote standby without going via cascaded standby.

• No Related Post

       集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如MYSQL)，由于大部分是典型的读多写少的请求，因此为MYSQL及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，比如电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如DB2、Oracle等。

       就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle读写分离式的架构相对MYSQL来讲，相对会少。

       前段时间一直在规划公司新的数据库架构，考虑到我们的业务特点，采用Oracle读写分离的思路，Writer DB和Reader  DB采用日志复制软件实现实时同步； Writer DB负责交易相关的实时查询和事务处理，Reader DB负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如Writer DB采用HA或者RAC的架构模式，Reader DB可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。

       对于Shared-nothing的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然Reader  DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader  DB在功能上仍然需要可写。

       下面谈一下数据同步的技术选型问题：

       能实现数据实时同步的技术很多，基于OS层(例如VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的DB整库同步，会涉及到业务数据选择以及多源整合等问题，因此OS复制和存储复制多数情况并不适合做读写分离的技术首选。

       基于日志的Oracle复制技术，Oracle自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是Oracle自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

      采用Oracle自身组件功能，无外乎Logical Standby、Stream以及11g的Physical Standby(Active Data Guard)，对比来说，Stream最灵活，但最不稳定，11g Physical Standby支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用Oracle自身的组件完全可行。

     选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的Oracle复制软件也无外乎几种，无论是老牌的Shareplex，还是本土DSG公司的RealSync和九桥公司的DDS，或是Oracle新贵Goldengate，都是可供选择的目标。随着GoldenGate被Oracle收购和推广，个人认为GoldenGate在容灾、数据分发和同步方面将大行其道。

      当然，架构好一个可靠的分布式读写分离的系统，还需要应用上做大量设计，不在本文讨论范围内。

• Undocumented Way–通过手工创建sql profiles固定执行计划进行SQL调优
• 完全手工重构ASM Disk Header <二>
• 完全手工重构ASM Disk Header <一>
• Dataguard的两种Log Gap检测和处理机制
• Physical Dataguard同步状态Shell巡检监控一则
• Dataguard高级调整之一—–网络调整

         前几天在查阅新书<Pro Oracle SQL>介绍的时候，看到作者blog上有提出了undocmented way手工构造SQL profile的例子，确实能像outline一样，强制固定住执行计划，这顿时让我觉得柳暗花明，因为我之前一直对SQL profiles的稳定性大伤脑筋。结合最近的几次项目调优，使用这种办法固定SQL计划，效果相当不错。

        手工构造SQL Profiles，可以使用oracle提供的dbms_sqltune.import_sql_profile过程。

SQL> desc dbms_sqltune.import_sql_profile
Parameter   Type             Mode Default?
———– —————- —- ——–
SQL_TEXT    CLOB             IN             —-sql文本
PROFILE     SYS.SQLPROF_ATTR IN      —-profile info
NAME        VARCHAR2         IN   Y     —profile名称
DESCRIPTION VARCHAR2         IN   Y
CATEGORY    VARCHAR2         IN   Y   —类别
VALIDATE    BOOLEAN          IN   Y
REPLACE     BOOLEAN          IN   Y
FORCE_MATCH BOOLEAN          IN   Y     –是否对sql语句进行匹配，游标共享。

         其中Profile参数，我们可以按照既定格式手工填充，因为一般要调优的SQL语句相对比较长，如果手工填充，不是很现实，可以用已生成的执行计划，从v$sql_plan中提取(当然也可以从awr的dba_hist_sql_plan中提取，提取方法可参见后面脚本)

          从v$sql_plan中提取sql profiles信息: create_sql_cursor_profiles.sql(该脚本基于Kerry Osborne完善而成，增加了SQL Profile信息调换功能，更方便的为我们选择想要的执行计划)

          以下是一个调优案例：

          项目中有个模块需要进行日结报表统计，没有使用绑定变量,应用返回超时，涉及语句和生产执行计划如下：

select a.*
b.ofr_create_time as FILE_CREATETIME,
b.ofr_file_name as FILE_name,
b.ofr_completetime as FILE_RECRONTIME,
b.ofr_deal_type as DEAL_TYPE,
c.ubr_last_send as UBR_LAST_SEND,
c.ubr_completetime as UBR_COMPLETETIME,
c.ubr_state as UBR_STATE,
d.ofc_reckonaccount as ofc_reckonaccount,
d.ofc_province as ofc_province
from UNP_PAYRECORD a, unp_orafile b, unp_paybatch c, unp_orarecord d
where a.ubc_ofc_id = d.ofc_id
and a.ubc_ofc_sn = d.ofc_sn
and a.ubc_id = c.ubr_id
and a.ubc_ofc_id = b.ofr_id
and b.ofr_deal_type = ’101003′
and c.ubr_last_send between to_date(’2010-11-12′, ‘yyyy-mm-dd’) and
to_date(’2010-11-12′, ‘yyyy-mm-dd’) + 1
and b.OFR_COMPLETETIME is not null
and a.UBC_OFC_PAY_CHANNEL = ’010501′
order by a.ubc_id desc, a.ubc_sn asc
——————————————————————————–
| Id  | Operation                       | Name          | Rows  | Bytes |TempSpc
——————————————————————————–
|   0 | SELECT STATEMENT                |               |       |       |
|   1 |  SORT ORDER BY                  |               | 93172 |    27M|    58M
|*  2 |   HASH JOIN                     |               | 93172 |    27M|    23M
|*  3 |    HASH JOIN                    |               | 92549 |    21M|    21M
|*  4 |     HASH JOIN                   |               | 93486 |    20M|  3656K
|   5 |      TABLE ACCESS BY INDEX ROWID| UNP_PAYBATCH  | 87005 |  2633K|
|*  6 |       INDEX RANGE SCAN          | IDX_LAST_SEND | 87005 |       |
|*  7 |      TABLE ACCESS FULL          | UNP_PAYRECORD |  5468K|  1053M|
|   8 |     TABLE ACCESS FULL           | UNP_ORARECORD |    21M|   322M|
|*  9 |    TABLE ACCESS FULL            | UNP_ORAFILE   |   451K|    23M|
——————————————————————————–

           通过添加Hints，我们认为如下优化后的语句和执行计划可以被接受：

select /*+  ordered use_nl(a,b,c,d) */ a.*,
b.ofr_create_time as FILE_CREATETIME,
b.ofr_file_name as FILE_NAME,
b.ofr_completetime as FILE_RECRONTIME,
b.ofr_deal_type as DEAL_TYPE,
c.ubr_last_send as UBR_LAST_SEND,
c.ubr_completetime as UBR_COMPLETETIME,
c.ubr_state as UBR_STATE,
d.ofc_reckonaccount as ofc_reckonaccount,
d.ofc_province as ofc_province
from   unp_paybatch c,UNP_PAYRECORD a ,unp_orafile b,unp_orarecord d
where a.ubc_ofc_id = d.ofc_id
and a.ubc_ofc_sn = d.ofc_sn
and a.ubc_id = c.ubr_id
and a.ubc_ofc_id = b.ofr_id
and b.ofr_deal_type = ’101003′
and c.ubr_last_send between to_date(’2010-11-12′, ‘yyyy-mm-dd’) and
to_date(’2010-11-12′, ‘yyyy-mm-dd’) + 1
and b.OFR_COMPLETETIME is not null
and a.UBC_OFC_PAY_CHANNEL = ’010501′
order by a.ubc_id desc, a.ubc_sn asc

——————————————————————————–
| Id  | Operation                       | Name          | Rows  | Bytes |TempSpc
——————————————————————————–
|   0 | SELECT STATEMENT                |               |       |       |
|   1 |  SORT ORDER BY                  |               | 93172 |    27M|    58M
|   2 |   NESTED LOOPS                  |               | 93172 |    27M|
|   3 |    NESTED LOOPS                 |               | 94116 |    25M|
|   4 |     NESTED LOOPS                |               | 93486 |    20M|
|   5 |      TABLE ACCESS BY INDEX ROWID| UNP_PAYBATCH  | 87005 |  2633K|
|*  6 |       INDEX RANGE SCAN          | IDX_LAST_SEND | 87005 |       |
|*  7 |      TABLE ACCESS BY INDEX ROWID| UNP_PAYRECORD |     1 |   202 |
|*  8 |       INDEX RANGE SCAN          | SYS_C003463   |     1 |       |
|*  9 |     TABLE ACCESS BY INDEX ROWID | UNP_ORAFILE   |     1 |    55 |
|* 10 |      INDEX UNIQUE SCAN          | SYS_C003412   |     1 |       |
|  11 |    TABLE ACCESS BY INDEX ROWID  | UNP_ORARECORD |     1 |    16 |
|* 12 |     INDEX UNIQUE SCAN           | SYS_C003427   |     1 |       |
——————————————————————————–

          因为该语句有3个传入参数，没有使用绑定变量，因此不能通过outline的方式进行SQL语句固定，而且，由于亚运期间运维保证封网，无法进行前台应用程序的修改。因此只能寻找别的数据库层上的途径。

         尝试去手工去构造SQL Profile。用的就是偷梁换柱的思想，将原始的SQL语句的profiles和优化后的SQL语句的profiles信息调换(这种办法,也常常用在outline的构造中)

         查询到原始的SQL语句，其sql_id为’ar6qss94q5m9b’,child_number为0

         加过Hints优化后的SQL语句，其sql_id为’4brxrmxzhavtr’,child_number为0

         生成SQL profile，其sql文本对应为ar6qss94q5m9b的sqltext(原始文本)，而执行计划信息对应为4brxrmxzhavtr的执行计划(调优后的计划)。

SQL> @create_sql_cursor_profiles.sql
Enter value for sql_id1(used to generate sql_text): ar6qss94q5m9b
Enter value for child_no1 (used to generate sql_text) (0): 0
Enter value for sql_id2(used to generate sql_hints): 4brxrmxzhavtr
Enter value for child_no2(used to generate sql_hints) (0):
Enter value for profile_name (PROF_sqlid_planhash): PROF_1
Enter value for category (DEFAULT):
Enter value for force_matching (FALSE): true
old   9: decode(‘&&profile_name’,'X0X0X0X0′,’PROF_&&sql_id1′||’_'||plan_hash_value,’&&profile_name’)
new   9: decode(‘X0X0X0X0′,’X0X0X0X0′,’PROF_ar6qss94q5m9b’||’_'||plan_hash_value,’X0X0X0X0′)
old  15: sql_id = ‘&&sql_id1′
new  15: sql_id = ‘ar6qss94q5m9b’
old  16: and child_number = &&child_no1;
new  16: and child_number = 0;
old  31: sql_id = ‘&&sql_id2′
new  31: sql_id = ’4brxrmxzhavtr’
old  32: and child_number = &&child_no2
new  32: and child_number = 0
old  40: category => ‘&&category’,
new  40: category => ‘DEFAULT’,
old  42: force_match => &&force_matching
new  42: force_match => true
old  53:   dbms_output.put_line(‘ERROR: sql_id: ‘||’&&sql_id1′||’ Child: ‘||’&&child_no1′||’ not found in v$sql.’);
new  53:   dbms_output.put_line(‘ERROR: sql_id: ‘||’ar6qss94q5m9b’||’ Child: ‘||’0′||’ not found in v$sql.’);

PL/SQL procedure successfully completed.

          查看是否有SQL profile生成.

SQL> select name,category,signature,sql_text,created,status,force_matching from dba_sql_profiles;
NAME       CATEGORY                        SIGNATURE SQL_TEXT                     CREATED     STATUS   FORCE_MATCHING
—————————— —————————— ———- —————————————————————–
PROF_1       DEFAULT                        8.70867244        (略)                        2010/12/20  ENABLED                       YES

         查看该PROF_1的outline hints

SQL> select attr_val  from dba_sql_profiles p, sys.sqlprof$attr h where p.signature = h.signature  and p.category = h.category and a.name=’PROF_1′;

IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE(’10.2.0.4′)
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_RS_ASC(@"SEL$1" "C"@"SEL$1" ("UNP_PAYBATCH"."UBR_LAST_SEND"))
INDEX_RS_ASC(@"SEL$1" "A"@"SEL$1" ("UNP_PAYRECORD"."UBC_ID" "UNP_PAYRECORD"."UBC_SN"))
INDEX_RS_ASC(@"SEL$1" "B"@"SEL$1" ("UNP_ORAFILE"."OFR_ID"))
INDEX_RS_ASC(@"SEL$1" "D"@"SEL$1" ("UNP_ORARECORD"."OFC_ID" "UNP_ORARECORD"."OFC_SN"))
LEADING(@"SEL$1" "C"@"SEL$1" "A"@"SEL$1" "B"@"SEL$1" "D"@"SEL$1")
USE_NL(@"SEL$1" "A"@"SEL$1")
USE_NL(@"SEL$1" "B"@"SEL$1")
USE_NL(@"SEL$1" "D"@"SEL$1")

           可见，该语句的SQL Profile已经生成，来验证一下这个语句现在使用的执行计划。

SQL> select * from table(dbms_xplan.display_cursor(‘ar6qss94q5m9b’));
PLAN_TABLE_OUTPUT
——————————————————————————–
SQL_ID  ar6qss94q5m9b, child number 0
————————————-
select a.*,        b.ofr_create_time as FILE_CREATETIME,        b.ofr_file_name
b.ofr_completetime as FILE_RECRONTIME,        b.ofr_deal_type as DEAL_TYPE,
c.ubr_last_send as UBR_LAST_SEND,        c.ubr_completetime as UBR_COMPLETETIME,
c.ubr_state as UBR_STATE,        d.ofc_reckonaccount as ofc_reckonaccount,
as ofc_province   from UNP_PAYRECORD a, unp_orafile b, unp_paybatch c, unp_orare
a.ubc_ofc_id = d.ofc_id    and a.ubc_ofc_sn = d.ofc_sn    and a.ubc_id = c.ubr_i
a.ubc_ofc_id = b.ofr_id    and b.ofr_deal_type = ’101003′    and c.ubr_last_send
to_date(’2010-11-12′, ‘yyyy-mm-dd’) and        to_date(’2010-11-12′, ‘yyyy-mm-dd
b.OFR_COMPLETETIME is not null    and a.UBC_OFC_PAY_CHANNEL = ’010501′  order by
a.ubc_sn asc
Plan hash value: 724325605
——————————————————————————–
| Id  | Operation                       | Name          | Rows  | Bytes |TempSpc
——————————————————————————–
|   0 | SELECT STATEMENT                |               |       |       |
|   1 |  SORT ORDER BY                   |               | 93172 |    27M|    58M
|   2 |   NESTED LOOPS                  |               | 93172 |    27M|
|   3 |    NESTED LOOPS                 |               | 94116 |    25M|
|   4 |     NESTED LOOPS                |               | 93486 |    20M|
|   5 |      TABLE ACCESS BY INDEX ROWID| UNP_PAYBATCH  | 87005 |  2633K|
|*  6 |       INDEX RANGE SCAN          | IDX_LAST_SEND | 87005 |       |
|*  7 |      TABLE ACCESS BY INDEX ROWID| UNP_PAYRECORD |     1 |   202 |
|*  8 |       INDEX RANGE SCAN          | SYS_C003463   |     1 |       |
|*  9 |     TABLE ACCESS BY INDEX ROWID | UNP_ORAFILE   |     1 |    55 |
|* 10 |      INDEX UNIQUE SCAN          | SYS_C003412   |     1 |       |
|  11 |    TABLE ACCESS BY INDEX ROWID  | UNP_ORARECORD |     1 |    16 |
|* 12 |     INDEX UNIQUE SCAN           | SYS_C003427   |     1 |       |
——————————————————————————–
Predicate Information (identified by operation id):
—————————————————
6 – access("C"."UBR_LAST_SEND">=TIMESTAMP’ 2010-11-12 00:00:00′ AND
"C"."UBR_LAST_SEND"<=TIMESTAMP’ 2010-11-13 00:00:00′)
7 – filter("A"."UBC_OFC_PAY_CHANNEL"=’010501′)
8 – access("A"."UBC_ID"="C"."UBR_ID")
9 – filter(("B"."OFR_DEAL_TYPE"=’101003′ AND "B"."OFR_COMPLETETIME" IS NOT NU
PLAN_TABLE_OUTPUT
——————————————————————————–
10 – access("A"."UBC_OFC_ID"="B"."OFR_ID")
12 – access("A"."UBC_OFC_ID"="D"."OFC_ID" AND "A"."UBC_OFC_SN"="D"."OFC_SN")
Note
—–
- SQL profile "PROF_1" used for this statement

        执行计划与我们预期的一致，由于SQL Profile的设置了force match，因此，可以替入其他参数值，验证执行计划依然是完美保持的，对执行计划的固定原理上，同outline也就没有太大区别了。

• Oracle读写分离架构
• 完全手工重构ASM Disk Header <二>
• 完全手工重构ASM Disk Header <一>
• Dataguard的两种Log Gap检测和处理机制
• Physical Dataguard同步状态Shell巡检监控一则
• Dataguard高级调整之一—–网络调整

          以下是一个ASM diskgroup中disk文件头全部损坏重构的例子。

          启动asm实例，diskgroup TEST无法挂载。

          以下是alert.log错误信息：

———————- 
NOTE: cache registered group TEST number=2 incarn=0xc868c69a
Sun Dec 19 14:44:38 2010
ERROR: no PST quorum in group 2: required 2, found 0
Sun Dec 19 14:44:38 2010
NOTE: cache dismounting group 2/0xC868C69A (TEST)
NOTE: dbwr not being msg’d to dismount
ERROR: diskgroup TEST was not mounted

         Diskgroup TEST无法mount，需要2块asm disk，但都已经丢失。

         接下来判断TEST diskgroup所使用的磁盘。 先获取OS上可用的asm disk.

[oracle@node1 ~]$ kfod disk=all
——————————————————————————–
Disk          Size Path     
=============================================================
   1:        1000 Mb /dev/raw/raw1
   2:        1000 Mb /dev/raw/raw101
   3:        1000 Mb /dev/raw/raw102
   4:        1000 Mb /dev/raw/raw103
   5:        1000 Mb /dev/raw/raw104
   6:      10240 Mb /dev/raw/raw11

            结合asm实例的v$asm_disk和操作系统上设备的使用情况，对asm磁盘信息进行筛除，定位到 TEST使用的磁盘为/dev/raw/raw101 和/dev/raw/raw102.
          利用shell脚本对这两个asm disk进行扫描，首先找到disk directory.

[oracle@node1 ~]$ ./echo_asm_info.sh –scan  10 3 /dev/raw/raw101 KFBTYP_DISKDIR

[oracle@node1 ~]$ sh echo.sh –scan  10 3 /dev/raw/raw102 KFBTYP_DISKDIR
aunum=2 blknum=0 : kfbh.type:                            6 ; 0×002: KFBTYP_DISKDIR
aunum=2 blknum=1 : kfbh.type:                            6 ; 0×002: KFBTYP_DISKDIR
aunum=2 blknum=2 : kfbh.type:                            6 ; 0×002: KFBTYP_DISKDIR

           可知disk directory位于设备raw102上的AU2 blknum0 上。 
          对raw102 AU2 blknum0做kfed read，获得我们需要的相关信息：

kfddde[0].dsknum:                     0 ; 0×034: 0×0000
kfddde[0].state:                      2 ; 0×036: KFDSTA_NORMAL
kfddde[0].ub1spare:                   0 ; 0×037: 0×00
kfddde[0].dskname:            TEST_0000 ; 0×038: length=9
kfddde[0].fgname:             TEST_0000 ; 0×058: length=9
kfddde[0].crestmp.hi:          32944750 ; 0×078: HOUR=0xe DAYS=0×13 MNTH=0xc YEAR=0x7da
kfddde[0].crestmp.lo:           4442112 ; 0x07c: USEC=0×0 MSEC=0xf2 SECS=0×4 MINS=0×0
kfddde[0].size:                     100 ; 0x08c: 0×00000064
TEST_0000
<———— 略 ———–>
kfddde[1].dsknum:                     1 ; 0x1f4: 0×0001
kfddde[1].state:                      2 ; 0x1f6: KFDSTA_NORMAL
kfddde[1].ub1spare:                   0 ; 0x1f7: 0×00
kfddde[1].dskname:            TEST_0001 ; 0x1f8: length=9
kfddde[1].fgname:             TEST_0001 ; 0×218: length=9
kfddde[1].crestmp.hi:          32944750 ; 0×238: HOUR=0xe DAYS=0×13 MNTH=0xc YEAR=0x7da
kfddde[1].crestmp.lo:           4442112 ; 0x23c: USEC=0×0 MSEC=0xf2 SECS=0×4 MINS=0×0
kfddde[1].size:                     100 ; 0x08c: 0×00000064
TEST_0000的dsknum为0 ；TEST_0001的dsknum为1。
[oracle@node1 ~]$ kfed read /dev/raw/raw102 aunum=0 blknum=1|grep obj
kfbh.block.obj:              2147483649 ; 0×008: TYPE=0×8 NUMB=0×1
[oracle@node1 ~]$ kfed read /dev/raw/raw101 aunum=0 blknum=1|grep obj
kfbh.block.obj:              2147483648 ; 0×008: TYPE=0×8 NUMB=0×0

            可知raw101 对应TEST_0000 raw102对应TEST_0001
     ASM header上的如下信息可获得(以下不说明，指raw101信息，raw102信息略)：
     /dev/raw/raw101:

kfdhdb.dsknum:                        0
kfdhdb.dskname:                TEST_0000 ;
kfdhdb.grpname:                     TEST ;
kfdhdb.fgname:                 TEST_0000 ;
kfdhdb.dsksize:                       100;  
kfdhdb.crestmp.hi:             32944750  ;
kfdhdb.crestmp.lo:            3943035904 ; 

      对同一磁盘组内asm disk上的kfdhdb.grpstmp.hi和kfdhdb.grpstmp.lo，取相同值，时间上早于dsknum=0的disk上kfdhdb.crestmp.hi和kfdhdb.crestmp.lo值。
       kfdhdb.mntstmp时间上取值晚于kfdhdb.crestmp

kfdhdb.mntstmp.hi:             32944750  ;
kfdhdb.mntstmp.lo:            4943035900 ;                                                                                         kfdhdb.grpstmp.hi:             32944750  ;
kfdhdb.grpstmp.lo:            2043035901 ;  

        接下来获取kfdhdb.fstlocn/kfdhdb.altlocn/kfdhdb.f1b1locn值

[oracle@nagios kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw1 KFBTYP_FREESPC

———aunum=0 blknum=1 ————-
kfbh.type:                            2 ; 0×002: KFBTYP_FREESPC

kfdhdb.fstlocn: 1

[oracle@nagios kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw1 KFBTYP_ALLOCTBL
———aunum=0 blknum=2 ————-
kfbh.type:                            3 ; 0×002: KFBTYP_ALLOCTBL

kfdhdb.altlocn：2

[oracle@node1 ~]$  ./echo_asm_info.sh –scan 5 2 /dev/raw/raw101 kfffde[0].xptr.au
——–aunum=2 blknum=1 ————–
kfffde[0].xptr.au:                    2 ; 0x4a0: 0×00000002

kfdhdb.f1b1locn=2

kfdhdb.grptyp,从PST中获得。

[oracle@node1 ~]$  kfed /dev/raw/raw1 aunum=0 blknum=1|grep copyCnt
kfdpHdrB.copyCnt:                     1 ; 0×010: 0×01

kfdhdb.grptyp=0
        取一个asm disk header的模版，将定值和我们获取的信息修改进去，利用kfed merge。

kfed merge /dev/raw/raw101 text=raw101
kfed merge /dev/raw/raw102 text=raw101

        接下来尝试对Diskgroup TEST做mount

  SQL>alter diskgroup test mount ;

  done

        验证过程，略。

• 完全手工重构ASM Disk Header <一>
• ASM下的存储更换迁移方案
• Oracle读写分离架构
• Undocumented Way–通过手工创建sql profiles固定执行计划进行SQL调优
• Dataguard的两种Log Gap检测和处理机制
• Physical Dataguard同步状态Shell巡检监控一则

       如果问题再延伸一下，假设一个diskgroup的上所有的disk header信息全部丢失，重新构造一个全新的header的工作量就大了不少，相关数值又是如何获得呢？经过几天的研究，一个asm disk header上的核心信息完全可以从disk上其他AU中获取或计算出来，通过这些信息，ASM disk header可以完全重构。当然，作为一个甲方dba，这种需要借助非常规处理的极端故障情况，几乎在我们的环境中不可能出现，绝大部分隐患故障理所应当通过技术、管理和其他手段规避。

       重构asm disk header，比较方便的方法就是使用kfed，另外，很多信息需要根据disk上的其他au和block位置上的结构体来定位，如果对这部分结构不熟悉，要提高效率快速定位，在unix下，比较方便的办法就是利用shell脚本，对disk根据AU和block遍历查找，从而获得我们想要的信息。11g下某些信息和属性有别，以下信息仅供10g参考。

       比如，我重构ASM Disk Header,常用的两样东西：kfed 和自己写的一个简单的shell脚本(以下称之为echo_asm_status.sh，作用就是根据指定关键字获取AU和block,脚本很简单，就不列出来了，弄个循环跑，grep我们想要的关键字就行了)

      先拿一个asm disk header做例子，来解读一下它的结构和核心数据如何计算。

kfbh.endian:                          1 ; 0×000: 0×01           /* endianness of writer    Little endian = 1|Big endian = 0  1 高字节为0*/
kfbh.hard:                          130 ; 0×001: 0×82               /* H.A.R.D. magic # and block size */
kfbh.type:                            1 ; 0×002: KFBTYP_DISKHEAD  /* metadata block type 此处取值为1.对于我们重构需要的类型有 1.KFBTYP_DISKHEAD  2.KFBTYP_FREESPC 3.KFBTYP_ALLOCTBL 4.KFBTYP_FILEDIR 5.KFBTYP_LISTHEAD 6.KFBTYP_DISKDIR   17.KFBTYP_PST_META 等 */
kfbh.datfmt:                          1 ; 0×003: 0×01              /* metadata block data format 取值为1,表示已经格式化*/
kfbh.block.blk:                       0 ; 0×004: T=0 NUMB=0×0      /* block location of this block*  Disk header should have T=0 and NUMB=0×0 取值为0 */
kfbh.block.obj:              2147483648 ; 0×008: TYPE=0×8 NUMB=0×0  /* block object id     Disk header 的type为8 ，num表示asm disk在group中的编号,即kfdhdb.dsknum，TYPE=0×8 NUMB=0×0表示为8000000，十进制也就是2147483648 */
kfbh.check:                  3359966064 ; 0x00c: 0xc8450370        /* check value to verify consistency *  通过kfed可自动计算/
kfbh.fcn.base:                      108 ; 0×010: 0x0000006c           /* change number of last change*/
kfbh.fcn.wrap:                        0 ; 0×014: 0×00000000
kfbh.spare1:                          0 ; 0×018: 0×00000000
kfbh.spare2:                          0 ; 0x01c: 0×00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0×000: length=8          /* ASMLIB driver reserved block  If no driver is defined "ORCLDISK" is used. 如果没使用ASMlib，默认为 ORCLDISK，否则为ORCLDISK+Name*/
kfdhdb.driver.reserved[0]:            0 ; 0×008: 0×00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0×00000000
kfdhdb.driver.reserved[2]:            0 ; 0×010: 0×00000000
kfdhdb.driver.reserved[3]:            0 ; 0×014: 0×00000000
kfdhdb.driver.reserved[4]:            0 ; 0×018: 0×00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0×00000000
kfdhdb.compat:                168820736 ; 0×020: 0x0a100000       /* Comaptible software version   0x0a100000:10.1.0.0.0 */
kfdhdb.dsknum:                        0 ; 0×024: 0×0000                     /* This is the disk number.   可以通过kfbh.block.obj获得编号，也可以通过disk directory获得 */
kfdhdb.grptyp:                        1 ; 0×026: KFDGTP_EXTERNAL    /* Disk group type 通过PST获得  0:KFDGTP_INVALID 1:KFDGTP_EXTERNAL 2:KFDGTP_NORMAL 3:KFDGTP_HIGH  */
kfdhdb.hdrsts:                        3 ; 0×027: KFDHDR_MEMBER     /* Disk header status */
KFDHDR_INVALID           –  Illegal value
KFDHDR_UNKNOWN     –  Disk header block unreadable
KFDHDR_CANDIDATE     –  No OSM or OS disk header found
KFDHDR_MEMBER        –  Normal member of the group

KFDHDR_FORMER         –  Disk dropped cleanly from group
KFDHDR_CONFLICT       –  Header conflicts
KFDHDR_INCOMPAT      –  Written by incompatible software
KFDHDR_PROVISIONED  –  Disk was prepared beforehand     */
kfdhdb.dskname:                KAO_0000 ; 0×028: length=8           /* ASM disk name */
kfdhdb.grpname:                     KAO ; 0×048: length=3              /* ASM diskgroup name，通过disk directory 获得 */
kfdhdb.fgname:                 KAO_0000 ; 0×068: length=8           /* ASM failgroup name ，通过disk directory 获得*/
kfdhdb.capname:                         ; 0×088: length=0                /* Capacity group name, unused*/
kfdhdb.crestmp.hi:             32944719 ; 0x0a8: HOUR=0xf DAYS=0×12 MNTH=0xc YEAR=0x7da   /* Creation timestamp 通过disk directory 获得*/
kfdhdb.crestmp.lo:           3943035904 ; 0x0ac: USEC=0×0 MSEC=0x17d SECS=0×30 MINS=0x3a /* Creation timestamp 通过disk directory 获得*/
kfdhdb.mntstmp.hi:             32944743 ; 0x0b0: HOUR=0×7 DAYS=0×13 MNTH=0xc YEAR=0x7da  /* mount timestamp*  非定值，可根据规则自定值*/
kfdhdb.mntstmp.lo:           1611210752 ; 0x0b4: USEC=0×0 MSEC=0×248 SECS=0×0 MINS=0×18   /* mount timestamp* 非定值，可根据规则自定值*/
kfdhdb.secsize:                     512 ; 0x0b8: 0×0200             /* Disk sector size (bytes)  默认取值512*/
kfdhdb.blksize:                    4096 ; 0x0ba: 0×1000              /* Metadata block (bytes)  默认取值4096*/
kfdhdb.ausize:                  1048576 ; 0x0bc: 0×00100000          /* Allocation Unit (bytes)  默认取值1M*/
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80         /* Stride between phys addr AUs  默认取值113792 */
kfdhdb.dsksize:                     200 ; 0x0c4: 0x000000c8          /* Disk size  可通过KFBTYP_FREESPC获得，也可通过disk directory获得*/
kfdhdb.pmcnt:                         2 ; 0x0c8: 0×00000002          /* Number of physically addressed allocation units */
kfdhdb.fstlocn:                       1 ; 0x0cc: 0×00000001          /* First FreeSpace table blk num  用于记录freespace信息的首个block,通过KFBTYP_FREESPC 获得 */
kfdhdb.altlocn:                       2 ; 0x0d0: 0×00000002          /* First Alocation table blk num  用于记录allocation信息的首个block ,通过KFBTYP_ALLOCTBL 获得*/
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0×00000002         /* File Directory blk 1 AU num  File Directory起始地址 */
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0×0000
kfdhdb.redomirrors[1]:            65535 ; 0x0da: 0xffff
kfdhdb.redomirrors[2]:            65535 ; 0x0dc: 0xffff
kfdhdb.redomirrors[3]:            65535 ; 0x0de: 0xffff
kfdhdb.dbcompat:              168820736 ; 0x0e0: 0x0a100000       /*Comaptible database version   0x0a100000:10.1.0.0.0 */
kfdhdb.grpstmp.hi:             32944719 ; 0x0e4: HOUR=0xf DAYS=0×12 MNTH=0xc YEAR=0x7da   /* diskgroup create time  可根据规则重新定义 */
kfdhdb.grpstmp.lo:           3943035904 ; 0x0e8: USEC=0×0 MSEC=0x17d SECS=0×30 MINS=0x3a  /* diskgroup create time  可根据规则重新定义 */
kfdhdb.ub4spare[0]:                   0 ; 0x0ec: 0×00000000
kfdhdb.ub4spare[1]:                   0 ; 0x0f0: 0×00000000
<<———————– 略 ——————————>
kfdhdb.ub4spare[56]:                  0 ; 0x1cc: 0×00000000
kfdhdb.ub4spare[57]:                  0 ; 0x1d0: 0×00000000
kfdhdb.acdb.aba.seq:                  0 ; 0x1d4: 0×00000000
kfdhdb.acdb.aba.blk:                  0 ; 0x1d8: 0×00000000
kfdhdb.acdb.ents:                     0 ; 0x1dc: 0×0000
kfdhdb.acdb.ub2spare:                 0 ; 0x1de: 0×0000

1) 如何获得disk directory
       判断diskgroup中由哪几个asm disk组成，核心就是要找到asm disk directory。disk directory的类型为KFBTYP_DISKDIR。该类型block记录了一个diskgroup中所有的asm disk信息，包括disk的编号、名称、创建时间和容量等。可以利用脚本扫描获得。

[oracle@node1 kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw2 KFBTYP_DISKDIR
———aunum=2 blknum=0 ————-
kfbh.type:                            6 ; 0×002: KFBTYP_DISKDIR
———aunum=2 blknum=1 ————-
kfbh.type:                            6 ; 0×002: KFBTYP_DISKDIR

       可知KFBTYP_DISKDIR从 AU2 block 0上起始。查看这部分信息：

kfed read /dev/raw/raw2 aunum=2 blknum=0

kfddde[0].entry.incarn:               1 ; 0×024: A=1 NUMM=0×0
kfddde[0].entry.hash:                 0 ; 0×028: 0×00000000
kfddde[0].entry.refer.number:4294967295 ; 0x02c: 0xffffffff
kfddde[0].entry.refer.incarn:         0 ; 0×030: A=0 NUMM=0×0
kfddde[0].dsknum:                     0 ; 0×034: 0×0000
kfddde[0].state:                      2 ; 0×036: KFDSTA_NORMAL
kfddde[0].ub1spare:                   0 ; 0×037: 0×00
kfddde[0].dskname:             KAO_0000 ; 0×038: length=8
kfddde[0].fgname:              KAO_0000 ; 0×058: length=8
kfddde[0].crestmp.hi:          32944719 ; 0×078: HOUR=0xf DAYS=0×12 MNTH=0xc YEAR=0x7da
kfddde[0].crestmp.lo:        3943035904 ; 0x07c: USEC=0×0 MSEC=0x17d SECS=0×30 MINS=0x3a
kfddde[0].failstmp.hi:                0 ; 0×080: HOUR=0×0 DAYS=0×0 MNTH=0×0 YEAR=0×0
kfddde[0].failstmp.lo:                0 ; 0×084: USEC=0×0 MSEC=0×0 SECS=0×0 MINS=0×0
kfddde[0].timer:                      0 ; 0×088: 0×00000000
kfddde[0].size:                     200 ; 0x08c: 0x000000c8
<————————— 略 ——————————————>
kfddde[1].entry.incarn:               3 ; 0x1e4: A=1 NUMM=0×1
kfddde[1].entry.hash:                 1 ; 0x1e8: 0×00000001
kfddde[1].entry.refer.number:4294967295 ; 0x1ec: 0xffffffff
kfddde[1].entry.refer.incarn:         0 ; 0x1f0: A=0 NUMM=0×0
kfddde[1].dsknum:                     1 ; 0x1f4: 0×0001
kfddde[1].state:                      2 ; 0x1f6: KFDSTA_NORMAL
kfddde[1].ub1spare:                   0 ; 0x1f7: 0×00
kfddde[1].dskname:             KAO_0001 ; 0x1f8: length=8
kfddde[1].fgname:              KAO_0001 ; 0×218: length=8
kfddde[1].crestmp.hi:          32944751 ; 0×238: HOUR=0xf DAYS=0×13 MNTH=0xc YEAR=0x7da
kfddde[1].crestmp.lo:        1955419136 ; 0x23c: USEC=0×0 MSEC=0×355 SECS=0×8 MINS=0x1d
kfddde[1].failstmp.hi:                0 ; 0×240: HOUR=0×0 DAYS=0×0 MNTH=0×0 YEAR=0×0
kfddde[1].failstmp.lo:                0 ; 0×244: USEC=0×0 MSEC=0×0 SECS=0×0 MINS=0×0
kfddde[1].timer:                      0 ; 0×248: 0×00000000
kfddde[1].size:                     200 ; 0x24c: 0x000000c8

       从这部分信息可知，该diskgroup包含2个asm disk(KAO_0000和KAO_0001),并且我们可以获知各自对应的disknum,createtimestamp，size等。
那如何将asm diskname与相应的设备对应起来呢。关联关系便为dsknum与kfbh.block.obj。
       查询相关的设备的kfbh.block.obj(由于AU0 Block0已经损坏，可从AU0上非block 0上获得)

[oracle@node1 kfed]$ kfed read /dev/raw/raw2 aunum=0 blknum=1|grep obj
kfbh.block.obj:              2147483649 ; 0×008: TYPE=0×8 NUMB=0×1
[oracle@node1 kfed]$ kfed read /dev/raw/raw1 aunum=0 blknum=1|grep obj
kfbh.block.obj:              2147483648 ; 0×008: TYPE=0×8 NUMB=0×0

       可知，raw1对应的obj为NUMB=0×0，表明raw1对应为KAO_00000,而raw2的obj为NUMB=0×1，其对应的asm diskname便是KAO_00001.

从而我们可以至少获得如下重构的信息：

kfbh.block.obj
kfdhdb.dsknum
kfdhdb.dskname
kfdhdb.fgname
kfdhdb.crestmp.hi
kfdhdb.crestmp.lo
kfdhdb.blksize

2) kfbh.endian/kfbh.hard

       可从disk上其他AU block上获得.

[oracle@node1 ~]$ kfed read /dev/raw/raw1 aunum=0 blknum=1|grep -E "endian|hard"
kfbh.endian:                          1 ; 0×000: 0×01
kfbh.hard:                          130 ; 0×001: 0×82

3) kfdhdb.grptyp：
       通过PST可以获得diskgroup的冗余模式。PST位于asm disk的 AU1 Block 0上，可以通过扫描获得，其类型为KFBTYP_PST_META。

[oracle@node1 ~]$ kfed read /dev/raw/raw1 aunum=1 blknum=0|grep copyCnt
kfdpHdrB.copyCnt:                     1 ; 0×010: 0×01

       如果copyCnt的数值为1，则为extenal类型，如果copyCnt为2，为normal类型。
4) fdhdb.fstlocn
       查找类型为KFBTYP_FREESPC的block
5)kfdhdb.altlocn
       查找类型为KFBTYP_ALLOCTBL的block
       通常fstlocn为AU0/block 1 ;altlocn为AU0/block 2

[oracle@node1 kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw1 KFBTYP_FREESPC
———aunum=0 blknum=1 ————- 位于AU0 block 1
kfbh.type:                            2 ; 0×002: KFBTYP_FREESPC

[oracle@node1 kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw1 KFBTYP_ALLOCTBL
———aunum=0 blknum=2 ————-位于AU0 block 2
kfbh.type:                            3 ; 0×002: KFBTYP_ALLOCTBL

6)kfdhdb.dsksize
       上面提过，该数值可以通过disk directory中的记录获得。另外，还可以通过查找类型为KFBTYP_FREESPC的block中相关记录计算得出。

7) kfdhdb.f1b1locn:
       查找kfffde[0].xptr.au的AU地址，即为f1b1locn的值，如不存在，取值为0.

[oracle@node1 kfed]$ ./echo_asm_info.sh –scan 5 2 /dev/raw/raw1 kfffde[0].xptr.au

———aunum=2 blknum=1 ————-

8)kfdhdb.grpstmp/kfdhdb.mntstmp：

       kfdhdb.grpstmp/kfdhdb.mntstmp非确定值,可以自指定。同groupdisk内各asm disk上kfdhdb.crestmp取值需要对应一致；在时间序列上，kfdhdb.grpstmp要早于kfdhdb.crestmp，而kfdhdb.mntstmp要晚于kfdhdb.crestmp。

       这样用于重构ASM disk header的信息已经全部获取到，利用kfed merge功能，便可将头部损坏的asm disk修复并成功mount起来。

       接下来给出一个完全重构ASM disk header的案例—完全手工重构ASM Disk Header <二>

• 完全手工重构ASM Disk Header <二>
• ASM下的存储更换迁移方案
• Oracle读写分离架构
• Undocumented Way–通过手工创建sql profiles固定执行计划进行SQL调优
• Dataguard的两种Log Gap检测和处理机制
• Physical Dataguard同步状态Shell巡检监控一则