① 风险与可控性

      风险与可控不单单指的是迁移升级过程中，更指迁移完毕后的新环境的运行情况(稳定性、性能等)以及对业务系统的支撑情况。

       一个良好的迁移工程，需要强有力的迁移控制过程，完善的模拟验证机制以及快速有效的回退方案。

②停机维护窗口

      大部分迁移都需要在指定的停机时间内完成，以避免对业务造成更多的中断和影响。对于高可用环境，需要有良好的迁移方案来尽可能压缩停机时间。

       本文重点讨论各种常见场景下利用Oracle自身特征的迁移升级手法，不涉及跨字符集转换，不涉及成熟的第三方迁移工具。

       先简单列举一下各种迁移手段及其特点。

(1). EXP/IMP

      逻辑导入导出工具，优点是可以跨平台跨版本，可以实现数据重组，但是对大规模的DB不适合，停机时间长且不可控。

(2). EXPDP/IMPDP

      10g以上版本可用；优点是可以跨平台跨版本，可以实现数据重组，虽然处理速度上较exp/imp有了大幅提升，但仍然不适合短时间的海量数据迁移。

(3).Transport Tablespace 表空间搬移

       9i以上版本可用, 可跨版本。9i上不能进行跨平台迁移，10g以上可以实现跨平台迁移，处理办法因字节高低位顺序有所不同。停机窗口一般。

(4).高级复制

      该方案可以跨平台跨版本，可大大缩短停机时间，但操作复杂，可控性差，且迁移过程对源环境有影响，非必要不建议使用。

(5).物理Dataguard/备份恢复

      物理Dataguard就是一个自动化的异库恢复过程，与手工的异库recover archivelog并无异样，二者实际是一体的。优点是可控性强，停机时间短，一般不应该超过半小时。但是不支持异构平台，10g以上版本可以支持一定的异构环境，可参考metalink id 413484.1

(6).Streams

        Streams灵活多变，可以作为我们迁移升级的一个强力工具，尤其是跨平台升级或者迁移。缺点是配置略显繁杂，注意点比较多，还需要一些逻辑对象的支持和数据支持，9i以上适用。

       以上是常见的一些Oracle自身迁移升级手段，实际的案例中，可能并不单单局限于其中某种，交叉使用是必要的。

        下面就同平台和异构平台两种大情况，列举一些常见的高可用迁移方案，当然，实际迁移过程中情况不尽相同，方案无所谓最优，做到灵活处理，满足需求为佳。

<1> 同平台下的迁移/升级

(1) 版本升级

常见案例情况： 9i/10g/11g之间的小版本升级、大版本升级。（以9.2.0.8升级10.2.0.4为例）

可采用方案:

Dataguard + 升级数据字典

       实际过程中如果条件允许，应该尽量避免在原始库上做升级操作以避免升级失败带来一系列问题。

简单步骤：

①备机装2套db软件，一套9.2.0.8用来与原始库做物理dataguard，另外一套10.2.0.4用来做升级数据库版本。

② 同步dataguard，业务不受影响

③ 停止业务，Standby库failover成主库

④ dbua或者脚本方式进行库版本升级

评点：停机时间比较短，顺利2小时之内可完成操作，检查点比较少，失败后可重新启用原始库。

Dataguard + Transport tablespace

简单步骤：

①备机建2套db软件，一套9.2.0.8用来与原始库做物理dataguard，利用另外一套10.2.0.4创建一个新库以便进行空间搬移

② 同步dataguard，业务不受影响

③停止业务，Standby库failover成主库

④利用Transport tablespace技术将9208库表空间搬移到10204库

⑤处理表空间搬移无法操作的逻辑对象等

评点：停机时间很短，30分钟内可以完成，需要注意检查一些逻辑对象的状态和同步情况，失败后可重新启用原始库。

（2）位数升级

常见案例情况：DB版本位数转换(以linux 32bit 10.2.0.1转换到linux 64bit 10.2.0.1为例)

可采用方案：

Dataguard + 位数转换脚本

简单步骤：

①备机安装1套64bit的Oracle 10.2.0.1，与原始库形成物理Dataguard .

②同步dataguard。

③停止业务，Standby库failover成主库

④利用Oracle提供的32bit<->64bit转换脚本utlirp进行位数转换(双向)。

评点：停机时间很短，30分钟内可以完成，失败后可重新启用原始库。

     可能实际碰到的情况看起来更复杂一些，比如位数和版本都需要同时升级，这就是个如何打组合拳的问题，本质处理方法都是类似的。可以参考一个实际案例：
记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit

       大多数的同平台数据库迁移，Dataguard/备份恢复是个优选工具，结合其他的一些手段，停机时间都不需要太长，而无需过度关心数据库的数据量问题。

Oracle高可用迁移升级场景与实战(二)

• ASM下的存储更换迁移方案
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除

       在linux中,默认的内存页面是4096字节,而现行物理设备中,内存动辄几十G，当系统运行内存较大的应用程序(比如数据库)时，过小的内存页面会产生大量的TLB miss和缺页中断，将大大降低程序性能。Hugepages提供了2M到256M的大内存页面(大小取决于内核版本和物理架构)来代替默认的页面大小.

       使用Hugepages可以得到更好的性能，因为Hugepages不可交换,可以避免内存的换入换出，对一个Oracle database，可以将使用的SGA作为Hugepages钉住，会整体上提升db的性能。Oracle推荐在64bit Linux上对大内存数据库使用Hugepages.

      
       以RHEL4 64bit为例,配置Hugepages过程如下:

1 更改os参数,配置Hugepages大小

      Hugepages需设置为比SGA略大一点,过大的设置会造成内存浪费，过小则会造成无法使用。

(1)修改/etc/sysctl.conf参数,增加vm.nr_hugepages=”<total_size>/<Hugepagesize>”，并使之生效

      注意vm.nr_hugepages的单位,其值为需要设置成Hugepages的总内存大小/Hugepages的页面大小.

      HugePages的页面大小可以这样获得：

[root@jss01 ~]# grep Hugepagesize/proc/meminfo

Hugepagesize: 2048 kB

(2) 修改/etc/security/limits.conf，增加locked memory的最大限制，设置成大于等于sga大小。

* soft memlock <total_size>

* hard memlock <total_size>

2.重新启动db,检查是否生效

[root@jss01 ~]# grep Huge /proc/meminfo

HugePages_Total: 4000

HugePages_Free: 0

Hugepagesize: 2048 kB

      HugePages_Free表示剩余的大内存页面数，应该是接近为0的数字。

     在32bit OS中，使用Hugepages是为了配合大内存扩展，由于32bit OS的寻址空间限制,使用的SGA有限。尽管可以通过降低Oracle软件的mapped_base(挂载地址)来实现sga的扩展，但无法突破4G制约。而通过VLM (Very Large Memory)技术,hugemem内核的OS可以将SGA最大内存扩展到62Gb(smp内核最大支持14Gb SGA).在kernel 2.6之后，实现VLM可以借助hugepages+in-memory filesystem (ramfs)。

     需注意的是，使用VLM,将不能使用SGA自动动态调整功能。

      以RHEL4 32bit为例，具体步骤如下：

1.创建ramfs

[root@jss01 ~]umount /dev/shm

[root@jss01 ~]mount -t ramfs ramfs /dev/shm

[root@jss01 ~]chown oracle:oinstall /dev/shm

2.配置os参数和Hugepages大小(步骤略,同上)

3.配置db parameter

      32bit扩展大内存需要牺牲掉一些特性，参数文件里面，需要做如下改动：

(1) 移除DB_CACHE_SIZE/DB_xK_CACHE_SIZE等参数，用以老参数DB_BLOCK_BUFFERS代替。

(2) 设置 USE_INDIRECT_DATA_BUFFERS=TRUE

(3) 移除sga_target(11g memory_target/memory_max_target)等参数

4.重启instance/验证

       对于不存在Hugepages功能的更早的一些内核版本(比如RHAS 2,可以通过bigpages+in-memory filesystem(shmfs)来实现大内存扩展.

      注意,与在32bit下VLM使用Hugepages不同的是,在64bit Linux下使用Hugepages并不需要修改数据库参数。当然，在物理设备飞速发展的今天，还是尽快升级到你手头的32bit OS到64bit OS上来吧，何必在去为一些内存扩展苦苦折腾.

      具体可参考Metalink Note 261889.1 317141.1 361468.1 361323.1等

• Oracle高可用迁移升级场景与实战(一)
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除
• Oracle性能优化下的时间模型

     通过进程捕获了几条耗资源的SQL语句，发现大部分都是类似同一条语句造成的。手工执行一下，需要2分多钟才能出结果。

    捕获到的SQL语句如下：

SELECT *
FROM (SELECT DISTINCT e.n_event_id,
e.n_parent_id,
e.v_event_num,
em.n_req_type_1,
em.n_req_type_2,
em.v_title,
em.v_description,
e.n_priority,
cb.n_time_limit,
cb.n_status,
e.n_process_way,
e.n_maintaince_event_id,
e.v_maintaince_flag,
e.v_replacedevice_flag,
et.d_acbept_date,
et.d_finish_date,
et.v_exempt_status,
et.n_callback_status,
et.n_delay_time,
erpl.n_creator,
erpl.d_creation_date,
e.n_req_id,
el.v_res_notice_msg,
el.v_res_notice_email,
el.v_res_notice_im,
vd.v_valid_status,
vd.v_related_org_id,
e.n_dev_process_way,
e.v_over_time_reason,
e.v_confirm_person,
e.v_new_device_num
FROM tb_event e,
tb_event_related_person erpl,
vorg_department vd,
tb_callback cb,
tb_event_log el,
tb_event_marker em,
tb_event_track et
WHERE e.n_event_id = et.n_event_id(+)
AND e.n_event_id = em.n_event_id(+)
AND e.n_event_id = el.n_event_id(+)
AND e.n_event_id = cb.n_event_id(+)
AND erpl.n_dept_id = vd.recid(+)
AND e.n_event_id = erpl.n_event_id(+)
ORDER BY e.d_creation_date DESC)
WHERE rownum <= 40;

vorg_department为一个view，具体定义如下：

create or replace view vorg_department as
select d.recid,
r.v_valid_status,
d.v_related_org_id,
r.org_parent,
r.tree_no,
d.dept_kind,
d.dept_type,
d.dept_name,
d.status,
d.dept_code,
d.area_code,
d.dept_prof,
d.sort_num,
d.link_addr,
r.layer
from ORG_DEPARTMENT d, ORG_DEPRELATION r
where d.recid = r.org_child
and r.relation_type = 1

    该语句的执行计划如下：

PLAN_TABLE_OUTPUT

———————————————————————————————————–

| Id  | Operation                     |  Name                 | Rows  | Bytes|TempSpc|Cost|

———————————————————————————————————–

|   0 | SELECT STATEMENT              |                       |     40| 15404|    |  23M|

|*  1 |  COUNT STOPKEY                |                       |       |      |    |     |

|   2 |   VIEW                        |                       |   110M|  395G|    |  23M|

|*  3 |    SORT UNIQUE STOPKEY        |                       |   110M|   27G| 58G|  11M|

|   4 |     NESTED LOOPS OUTER        |                       |   110M|   27G|    | 2797|

|*  5 |      HASH JOIN OUTER          |                       |  1255K|  308M| 39M| 2797|

|*  6 |       HASH JOIN OUTER         |                       |   153K|   37M| 28M| 1873|

|*  7 |        HASH JOIN OUTER        |                       |   115K|   27M| 24M| 1384|

|*  8 |         HASH JOIN OUTER       |                       |   101K|   23M| 23M|  990|

|*  9 |          HASH JOIN OUTER      |                       |   100K|   22M| 17M|  571|

|  10 |           TABLE ACCESS FULL   | TB_EVENT              |  77044|   16M|    |  256|

|  11 |           INDEX FAST FULL SCAN| IDX_EVENT_TRACK_N_E_ID|   100K|  491K|    |    4|

|  12 |          INDEX FAST FULL SCAN |IDX_TB_CALLBAK_E_ID    |  75959|  296K|    |   21|

|  13 |         TABLE ACCESS FULL     | TB_EVENT_MARKER       |   3686| 18430|    |    3|

|* 14 |        INDEX FAST FULL SCAN   | IDX_TB_EVENT_RP_DUP1  |   101K|  895K|    |    4|

|  15 |       INDEX FAST FULL SCAN    |IDX_TB_EVENT_LOG_N_E_ID|   628K| 2455K|    |  149|

|  16 |      VIEW PUSHED PREDICATE    | VORG_DEPARTMENT       |     88| 1144 |    |     |

|  17 |       NESTED LOOPS            |                       |     1 |   15 |    |    2|

|* 18 |        INDEX UNIQUE SCAN    | PK_DEPARTMENT           |     1 |     6|    |    1|

|* 19 |        INDEX RANGE SCAN     | ASSOCIATION8_FK         |     1 |     9|    |    1|

———————————————————————————————————–

     首先了解了一下各表的统计信息情况和表的数据情况，统计信息都是最新的，除了tb_event_log表略微大点，有60多万数据外，其余表均10万左右或更小，执行计划里面的小表table full sacn和一些索引的access情况也并无严重问题。接下来关注表与表之间的关联顺序和方式。

    继续分析这个执行计划，第四行评估出了一个超级大的结果集，找到这个结果集的产生方式，第16行引起了我的注意。VIEW PUSHED PREDICATE,在存在out join和view的情况下，CBO自动选择了谓词推进到了视图VORG_DEPARTMENT中以过滤更多的数据，也算无可厚非。但继续往上找，找到这个谓词的基数，第5行，发现评估出来的基数竟然有100多万行之多，而视图本身的结果集，只有不到3000行！

   看来这是一个“愚蠢的”执行计划，CBO先选择视图之外的表做关联,tb_event虽然本身很小，但由于与其他表做多次外连接，因此最终得到一个庞大的基数，而拿着这个结果集推进到视图中，想想是多么恐怖的事情！

    一般来说，大集合的结果集合并不适合进行PUSHED PREDICATE。如果只是少量，会起到比较好的效果。

    既然知道了原因，那就尝试着去改变这个执行计划。Oracle提供了no_push_pred和push_pred来改变pushed predication行为，在上述语句中添加no_push_pred提示：

SELECT *
FROM (SELECT /*+ no_push_pred(vd) */ DISTINCT e.n_event_id,
e.n_parent_id,
e.v_event_num,
….
FROM tb_event e,
tb_event_related_person erpl,
vorg_department vd,
tb_callback cb,
tb_event_log el,
tb_event_marker em,
tb_event_track et
WHERE e.n_event_id = et.n_event_id(+)
AND e.n_event_id = em.n_event_id(+)
AND e.n_event_id = el.n_event_id(+)
AND e.n_event_id = cb.n_event_id(+)
AND erpl.n_dept_id = vd.recid(+)
AND e.n_event_id = erpl.n_event_id(+)
ORDER BY e.d_creation_date DESC)
WHERE rownum <= 40;

修改后的执行计划如下：

———————————————————————————————————–

| Id  |                     Operation |                   Name | Rows | Bytes|TempSpc|Cost|

———————————————————————————————————–

|   0 | SELECT STATEMENT              |                        |   40 | 11553|     |  181K|

|*  1 |  COUNT STOPKEY                |                        |      |      |     |      |

|   2 |   VIEW                        |                        | 1470K| 5398M|     |  181K|

|*  3 |    SORT UNIQUE STOPKEY        |                        | 1470K|  370M| 765M| 92546|

|*  4 |     HASH JOIN OUTER           |                        | 1470K|  370M|  46M|  3546|

|*  5 |      HASH JOIN OUTER          |                        |  180K|   44M|  39M|  2499|

|*  6 |       HASH JOIN OUTER         |                        |  153K|   37M|  28M|  1873|

|*  7 |        HASH JOIN OUTER        |                        |  115K|   27M|  24M|  1384|

|*  8 |         HASH JOIN OUTER       |                        |  101K|   23M|  23M|   990|

|*  9 |          HASH JOIN OUTER      |                        |  100K|   22M|  17M|   571|

|  10 |           TABLE ACCESS FULL   | TB_EVENT               | 77044|   16M|     |   256|

|  11 |           INDEX FAST FULL SCAN| IDX_EVENT_TRACK_N_E_ID |  100K|  491K|     |     4|

|  12 |          INDEX FAST FULL SCAN | IDX_TB_CALLBAK_E_ID    | 75959|  296K|     |    21|

|  13 |         TABLE ACCESS FULL     | TB_EVENT_MARKER        |  3686| 18430|     |     3|

|* 14 |        INDEX FAST FULL SCAN   | IDX_TB_EVENT_RP_DUP1   |  101K|  895K|     |     4|

|  15 |       VIEW                    | VORG_DEPARTMENT        |  3355| 20130|     |     3|

|  16 |        NESTED LOOPS           |                        |  3355| 50325|     |     3|

|* 17 |         INDEX FAST FULL SCAN  | ASSOCIATION8_FK        |  3356| 30204|     |     3|

|* 18 |         INDEX UNIQUE SCAN     | PK_DEPARTMENT          |     1|     6|     |      |

|  19 |      INDEX FAST FULL SCAN     | IDX_TB_EVENT_LOG_N_E_ID|  628K| 2455K|     |   149|

———————————————————————————————————

     调整后整个执行速度有了明显提升，15秒之内可以返回结果，可以看到view结果集与第六步产生的结果集进行hash join outer，然后得到的结果集合与最大的表tb_event_log再次进行hash join outer。当然这个执行计划可能还有完善的余地，需进一步根据数据情况调整表的关联顺序.

• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除
• Oracle性能优化下的时间模型

    情况大致如此

    由于涉及的业务数据库容量动辄几百G，且停机时间有限(不超过4小时),因此迁移方案的核心在于如何用最短的时间和最安全可控的步骤来完成这次迁移。

    在高可用迁移案例中，最糟糕的情况莫过于跨OS的数据库迁移(非异构,排除字符集不同的情况,比如Linux->UNiX,Windows->Unix),除了可借助一些oracle AQ和Streams来完成高可用同步和迁移外，并没有更好的处理办法(Dataguard无从发挥作用,诸如transport tablespace等手段对一个跨os的大容量的迁移项目也几乎鸡肋,实际中根本无法承受转换数据文件类型所带来的时间损耗)。但Streams等方案太过于繁琐,需要有审慎周密的迁移步骤和考虑。当然，借助于三方工具可以完成诸多海量迁移(如DSG/SharePlex等),但出于成本和其他因素,并不是每个迁移用户都有选择的余地.

    话题转到开篇的迁移情况，由于只是OS位数和Oracle版本/位数的转换，所以情况并非那么悲观。Oracle本身也提供了脚本,用来支持在32位和64位之间做互相转换(rdbms/admin/utlirp.sql,这种转换是双向的).那么重点问题在于如何在停机之前将32位os上的32位db与64位os上的64位db做同步,因为不可能停库以后才去将32bit os上datafile文件copy到64bit os上，如此数据量,光copy文件的时间就无法接受。能想到的最简单的同步办法，莫过于dataguard了.

    因此整个迁移方案雏形形成,新增一台设备，安装linux 64bit的os，部署2套Oracle版本，一套Oracle 9i(版本对应待升级源库版本,作为待升级源库的standby端做日志同步),另一套Oracle 64bit 10.2.0.4(用来做最终的升级版本).

    如此一来,整个迁移步骤就比较明了了。停库升级之前,做好主备的dataguard同步.待升级时刻，停主库，备库做failove切换，然后在新主库上做一系列数据字典升级和位数转换工作.跨版本的升级和位数转换过程，可以参考Metalink ID 62290.1(该文档并没有提及跨大版本升级的位数转换，但实际测试中9i 32bit 升级到10g 64bit依然可行)

    特别提出：Metalink ID 62290.1提出32bit与64bit区别仅仅在于PL/SQL的编译格式不同，而且，一般的版本升级/降级过程会自动进行位数的转换。

The on-disk format for database data, redo, and undo is identical for the 32-bit and 64-bit installations of Oracle. The only internal structural differences between the 32-bit and 64-bit Oracle installations are the following:
The compiled format of PL/SQL is different. The instructions for how and when to recompile PL/SQL are provided in the appropriate chapters of the Migration book. The storage format of user-defined types is based on the release of Oracle that created the database. The existing storage format will be converted to the correct format transparently when necessary. User-defined types include object types, REFs, varrays, and nested tables.

If you are changing word-size during a migration, upgrade, or downgrade operation then no additional action is required. The word-size is changed automatically during any of these operations

    问题到此为止远没有结束,当我提出这个方案的时候，同事持有诸多疑虑。在Linux 64bit的OS上，用来做standby同步的9i版本,装的是32bit的还是64bit的呢，且是否能够与32bit OS上的32bit db形成dataguard体系呢?

    早前我曾做过测试案例，无论位数32还是64,dataguard体系都不存在任何问题.但要害在于,无论装32bit和64bit，看似Oracle官方都有不支持的地方且有明确的文档说明。

1.linux 64bit OS上安装oracle 32bit 9iR2

    按照常规办法，这种组合根本就无法正常安装成功。Oracle不支持在linux 64bit OS上安装oracle 32bit 9iR2,见metalink ID 416530.1

     实际中从主库上tar一个安装好的Oracle 32bit 9iR2放到linux 64bit的OS上，数据库依然能够正常运行并与主库形成dataguard体系.

    Dataguard failover后，利用10gR2的软件，直接进行数据字典升级(或者用dbua).

2.linux 64bit OS上安装oracle 64bit 9iR2

    这种办法等同于64bit的db与32bit的db做dataguard，metalink ID 413484.1 给出了异构平台下的dataguard组合列表，只有在10g以后，Oracle才支持linux 64bit与 Linux 32bit之间做dataguard.

    但实际测试说明，这种dataguard组合模式在9iR2下依然成立.

     Dataguard failover后，利用9iR2 64bit的软件，执行utlirp脚本将32bit 9iR2转换成64bit .接下来利用10g R2 64bit的软件，做常规的9i->10g数据库升级(手工升级数据字典或者使用dbua).

    两种方案在测试中皆可行，个人倾向于后者。

    实际测试中按照Dataguard+升级数据字典和转换位数的方法测试，整个升级过程没有任何问题,检查数据库各组件状态，均正常(注意OLAP组件，如果库使用了该组件，32bit->64bit的转换会造成该组件的不可用，需要单独处理。另外，升级到10204需要注意Time Zone Definitions的问题)。升级过程在3小时之内可以完成.回顾整个迁移方案，唯一没有文档有力支撑的方便是Dataguard的组合模式,实际standby端也无非是做了block级别的recover，既然dataguard能启用且日志能够被Recover，那就不存在由于该步骤引发其他的bug的可能。

• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除
• 构建SQL Server高可用

Logical Standby日常维护与性能优化(一)—日常维护与故障排除

    Logical Standby较physical standby容易出现性能上的问题。对于一个DML繁重，尤其是大事务比较多的库，SQL APPLY往往会出现性能上的瓶颈。因此导致备库‘hang’住或者无法跟上主库同步速度的情况也并不少见。
    下面描述一下逻辑备库在性能排查和诊断方面的一些切入点和方法：

1.诊断并调整LCR Cache

    LCR Cache由shared pool 中的一部分来分配，用于缓存LCRs。过小的cache会引起page out，严重减缓LCR BUILDER过程。如果时常存在大量而且频繁的page out,意味着当前设置的LCR cache过小或者数据库中存在较大的事务。
    查询v$v$logstdby_process视图，如果BUILDER进程经常出现ORA-16243: paging out *** bytes of memory to disk 之类的事件，说明LCR cache可能存在问题。
    同样，通过计算某段时间的pageout activity(%)，可了解LCR Cache的设置是否合适，通常该指标被认为低于5%
    A时间点：

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ‘%page%’ or NAME LIKE ‘%uptime’ or name like ‘%idle%’;
NAME VALUE
——————————————————
coordinator uptime in secs 68752
bytes paged out 12521
secs spent in pageout 21
system idle time in secs 1301

    B时间点：

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ‘%page%’ or NAME LIKE ‘%uptime’ or name like ‘%idle%’;
NAME VALUE
——————————————————
coordinator uptime in secs 69058
bytes paged out 225872
secs spent in pageout 56
system idle time in secs 1309

    Pageout activity计算如下：

Change in coordinator uptime (C) = (69058 – 68752) = 298 secs
Amount of additional idle time (I) = (1309 – 1301) = 8 secs
Change in time spent in pageout (P) = (56 – 21) = 35 secs
Pageout activity(%) = P/(C-I) = 35/(298-8) ~ 12.06%

    如果诊断LCR cache设置不合理，使用dbms_logstdby.appply_set包进行设置。

SQL> exec dbms_logstdby.appply_set(’MAX_SGA’, 2048);

2.诊断并调整SQL apply process

    在SQL Apply各进程中，可以调整的进程为PREPARER和APPLIER进程。所有的进程数目之和受MAX_SERVERS控制,而MAX_SERVERS最大值受初始化参数PARALLEL_MAX_SERVERS控制。
    Oracle推荐MAX_SERVERS数目设置为 (3*CPU) + 3
    Oracle会根据MAX_SERVERS的设置自动调整PREPARER和APPLIER的进程数目,手工指定PREPARER和APPLIER进程数目在10gR2版本上不是必须的。
    查询如下视图

SQL> select available_committed_txn from v$logmnr_session;
AVAILABLE_COMMITTED_TXN
———————–
50

或者

select a.value-b.value from v$logstdby_stats a ,v$logstdby_stats b where a.name=’transactions ready’ and b.name=’transactions applied’;
a.value-b.value
———————–
52

    如果得到的结果经常远大于appler进程的数目,则意味着需要调整appler的进程数量。

SQL> execute dbms_logstdby.apply_set(’MAX_SERVERS’,30);

3.诊断并调整long transaction

    实际环境中往往存在一些异常缓慢的apply事务，例如Apllier进程出现如下状态：ORA-16124: transaction * ** *** is waiting on another transaction
    这类情况会成为备库无法跟上主库同步进度的罪魁祸首。在apply进程数目和lcr cache设置得当的情况下，如果存在这类情况，需要根据情况逐步考虑。

(1).缺失高效索引造成的sql apply效率低下

    如果一次事务只是操纵了少量行数据，依旧造成了备库SQL Apply的异常运行缓慢，往往是由于索引缺失或者低效的问题。因为主库上的一个DML语句，到备库上会根据操纵的行数解析成多个语句执行。假设primary端一次事务对A表删除了10条数据，进行了一次table scan，而在logical standby，如果依旧没有可用索引,会进行10次table scan来应用此事务
    可以根据v$logstdby_process得到活动的applier进程的当前sid，关联v$session,v$sql,v$sql_plan,v$session_wait等一系列视图，根据得到的SQL执行计划或者session等待情况进行判断。
    如必要,可以在备库上适当增加索引。

(2).Eager Transaction

    Eager Transaction是指那些操纵了大量行数据或能产生大量LCRs的事务,引入Eager Transaction的目的是为了提高对大事务的apply速度和减少对LCR cache的压力。在在10gR2里,区分Eager Transaction的默认临界点是201 LCRs,该参数可以通过隐含参数_eager_size来控制，在大部分情况下,并不推荐更改该参数的设置。而且,鉴于SQL Apply的原理和特点,增加该参数的设置对提升一些大批量操作的事务应用的性能提升非常有限。而且，过大的_eager_size会造成LCRs Cache的过度使用。
    对于一些大批量操作的事务,可以通过skip的方式跳过被操纵的表上的这段大事务处理后,恢复unskip。然后通过dbms_logstdby.instantiate_table或者手工方式初始化数据。

(3).其他争用

    同一般的库一样，高并发的环境同样在logical standby上出现一些资源上的争用,比如itl上,buffer上的争用等.具体可以关联v$session_wait/v$segment_statistics等查询判断并做处理。

4.调整TRANSACTION CONSISTENCY

    logical standby端,10gR2下有2种事务一致性模式:事务的提交顺序可以和主库上完全一致,也可以不一致。后者可以提高SQL APPLY的性能,只保证相关事务的一致性,但会得到不一致的数据版本。某些情况下，为了提高应用的进度,可以临时设置成后者，然后待需要时恢复。

SQL>exec dbms_logstdby.apply_set(’PRESERVE_COMMIT_ORDER’,'FALSE’);
SQL>exec dbms_logstdby.apply_set(’PRESERVE_COMMIT_ORDER’,'TRUE’);

• Logical Standby日常维护与性能优化(一)—日常维护与故障排除
• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Oracle性能优化下的时间模型

Logical Standby日常维护与性能优化(二)—性能诊断与优化

     10gR2大大简化了logical standby的创建步骤，从physical到logical的转换步骤异常简单，不再对搭建过程过多描述。

     因为Logical standby是SQL语句的逻辑运用，而standby是block级别的recover，从故障角度上将，Logical standby比standby standby有更多的故障机会出现。
     常用的用于维护和排查logical standby的视图几乎都是已”dba_logstdby_*”和“v$logstdby_*”开头，常用的包以”dbms_logstdby.*”开头，具体含义根据字面意思也不难理解,不赘述(下文有部分提及)。当然，用于physical standby的部分视图，对排查逻辑备库也同样适用。

1. APPLY状态的检查和诊断

     Apply进程是逻辑SQL运用的核心。Apply进程遇到错误会自动终止，需要处理后手工重新启动。因此，监控apply进度和状态是监控逻辑备库同步与否的关键，如同物理DG监控日志同步。

(1) 监控备库上各个进程的状态

     可以查询v$logstdby_process视图，用于得到与SQL APPLY相关的各进程的状态情况.
     如果没有返回值，表示APPLY进程没有启动或者已停止。如果是后者，可以从alert.log文件或者dba_logstdby_events中得到更多的错误信息用于后续处理。

(2) Apply 进度

     监控Apply进度可以得到备库的恢复进展以及同步状态。关联查询v$logstdby_progress 和dba_logstdby_log，得出目前SQL APPLY的apply scn/time以及log sequence。如果apply进程正常而主备之间同步有很大差异，需要做进一步排查。

2. SQL Apply的异常事务处理

     SQL 　Apply的异常事务会记录到dba_logstdby_events视图中，对于能够进行手工fix的异常，可以处理后重新运行apply进程。对于某些无法处理或者修复后需要忽略的异常，通过dbms_logstdby.skip*一系列包做标记以便让apply进程跳过。比如，我们可以对特定的错误事务进行标记，通过dbms_logstdby.skip_transaction标记指定的事务而忽略该事务的运用。
     在10G中，oracle提供了带skip failed transaction子句的 SQL apply启动语句，可以方便的对当前记录的错误事务全部跳过。

SQL>alter database start logical standby apply skip failed transaction;

3.SKIP策略

Logical standby提供skip的策略，可根据实际情况跳过不想被apply的对象或者跳过特定对象上的所有错误事务。
dbms_logstdby.skip: 用于指定对象的DML DDL skip
dbms_logstdby.skip_error: 用于指定对象上的错误事务 skip
dbms_logstdby.skip_transaction: 用于指定事务 skip

4. UNSKIP与初始化

     Unskip是与skip相反的操作，用于已skip操作的撤销。对于unskip的对象，需要进行手工构造或者初始化。
     Oracle提供dbms_logstdby.instantiate_table包来对指定的table初始化。我们也可以手工来构造一个当前apply scn时刻的闪回查询版本来初始化数据。

5. DDL handle

     Logical standby中提供DDL handle的功能，用于自定义的一些DDL语句处理，比如一些表对象的重命名。
     需要注意的是,在逻辑备库中，db_file_name_convert/ log_file_name_convert参数并不生效。对于路径不同的主备体系，添加数据文件和表空间会引起逻辑备库的apply错误,可以通过DDL handle可以实现文件路径的重命名。
     ORACLE联机文档上的一个例子：

CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (
OLD_STMT IN VARCHAR2,
STMT_TYP IN VARCHAR2,
SCHEMA IN VARCHAR2,
NAME IN VARCHAR2,
XIDUSN IN NUMBER,
XIDSLT IN NUMBER,
XIDSQN IN NUMBER,
ACTION OUT NUMBER,
NEW_STMT OUT VARCHAR2
) AS
BEGIN
– All primary file specification that contains a directory
– /usr/orcl/primary/dbs
– should go to /usr/orcl/stdby directory specification
NEW_STMT := REPLACE(OLD_STMT,
‘/usr/orcl/primary/dbs’,
‘/usr/orcl/stdby’);
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;
EXCEPTION
WHEN OTHERS THEN
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
NEW_STMT := NULL;
END HANDLE_TBS_DDL;

然后指向这个ddl handle

SQL>exec dbms_logstdby.skip(stmt => ‘TABLESPACE’, proc_name => ‘SYS.HANDLE_TBS_DDL’);

6.参数设置

     通过查看v$logstdby_stats观察现有的一些参数设置和状态。设置/恢复参数使用dbms_logstdby.apply_set/dbms_logstdby. apply_unset包进行。

7. Role Transitions

     逻辑switchover的过程要比physical standby复杂一些，需要有一步prepare的过程，注意留意期间主备库角色的当值状态。

8.Flashback database

     如果开启了flashback database，对于一个做过failover的原主库，可以通过flashback database的功能将数据库闪回到某个scn上，然后转换成备库，从而无需重新重新搭建环境。
     (1). 在新主库上，执行如下查询获得这个转换时刻的SCN

SQL>SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS WHERE NAME = ‘STANDBY_BECAME_PRIMARY_SCN’;

     (2). 旧库上，执行flashback，并resetlogs

SQL>FLASHBACK DATABASE TO SCN became_primary_scn;

     (3).角色切换

SQL>ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;

9.Guard 模式

    默认状态下的逻辑备库提供查询功能和sys用户下的DDL/DML操作,即standby模式.
    Oracle提供database级别的3种模式,即none/standby/all模式,通过查询v$database.guard_status列获得当前状态，可以通过以下SQL在备库上重新定义:

SQL>alter databsae guard none(standby/all);

NONE模式:

逻辑备库可以以任意数据库用户进行任意数据库动作(查询/DML/DDL/DCL等).置于该模式下的逻辑备库,除了还需要运用SQL APPLY外,可读写,同一般的实例无区别.

STANDBY模式:

阻止除SYS用户外的所有用户对受SQL apply保护的所有对象的DDL和DDL操作.比如:通过SQL APPLY生成的表,普通用户不允许对其进行DML/DDL操作,但普通用户可以创建/操作主库上不存在的表(对象).

ALL模式:

阻止除SYS用户外的所有数据库用户进行任意更改操作,数据库只读.

    同时逻辑备库还支持session级别的guard保护开关,有时候需要进行维护操作,可以临时将guard关闭掉以支持该session下的DDL/DML操作.

SQL>alter session disable/enable guard;

etc,ect,ect…

• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Oracle性能优化下的时间模型

1.Failover Cluster(HA集群)

    Failover Cluster是依赖于集群软件的一种故障转移方案，物理架构上需要2台以上的主机+一套共享存储。几乎所有的主流数据库都有相应成熟的集群HA解决方案，可以避免因单台服务器硬件以及操作系统环境的故障而带来的单点隐患。HA方案的核心在于，通过集群软件判断集群中资源的状态，故障时刻能够将服务资源自动切换。在Sql Server中，借助于Windows平台上的MSCS，SQL server也提供了一套failover解决方案。该方案成本较高，但有较高的故障转移能力和较低的停机时间，能提供非存储故障引起的故障保护。

2.Database mirroring(数据库镜像)

    镜像技术是SQL Server 2005引入的一套软件层的高可用方案。直观的讲，它能够实现类似Oracle Standby的功能。SQL server 镜像提供database级别的保护，需要数据库运行在FULL恢复模式下，最小化的物理架构只需要2台主机即可。它通过同步或异步提交主库上的事务更改到备库，来实现主备库的数据同步，支持快速的平滑角色切换和故障切换。个人认为，镜像功能在企业高可用运用中是有极高的可用度。投入低，维护也相对简单。需要注意的是，由于SQL server架构上的特点，镜像功能并不能提供用户和作业等数据库角色和对象的转移，需要做一定的预处理。对于使用发布/订阅等复制的环境，也需要做一些单独的处理。

3.Log shipping(日志传送)

    日志传送能够提供异步的数据保护功能，它通过主库日志的定时传送，然后在辅助库自动进行日志还原。因此，根据企业数据库的应用性质和负载程度，合理的规划日志备份和传送的时间跨度，如何在性能与数据保护中间寻找一个平衡点，是运用日志传送的一个重点所在。个人认为，日志传送已不适合做高可用的数据同步保护，但是可以利用日志传送主库和辅助库有时间差的这个特性，作为数据保护的一种补充，比如：用于快速的处理数据的误操作和基于时间点的不完全恢复。

4.发布与订阅

    发布与订阅作为一种复制技术，严格说并不能算是一种高可用的解决方案。发布与订阅的强项在于多源数据的互交与共享，并支持一定的事务处理。但我们依然利用发布与订阅做一些数据的同步和保护。

• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• [HA]利于heartbeat构建Oracle高可用

关键词: 谨慎，周全的考虑.

     昨晚系统调整，将一套CRM数据库的几个用户迁移到另外一台性能较强的服务器数据库上去。

源库： oracle 9208
目标库： oracle 9206
字符集相同. 操作系统都是linux

     这样的环境太好了，几乎一下子就想到了传输表空间，不用忍受exp/imp大量数据带来的痛苦的煎熬与等待。由于之前使用传输表空间做了一些迁移案例，所以驾轻就熟，也没多想，简单列了checklist，然后待停机时间开始做这次迁移。

     迁移过程比较顺利，出现的问题都在想象中(dblink和job无法用imp进新环境，对于dblink，使用dbms_metadata.get_ddl提取对应脚本/对于job,使用自己写的一个procedure从旧库提取生成).表空间传输从技术角度讲比较简单，但实施中一定要细心，对存储过程/序列/授权/JOB/DBLINK等一系列object要有一个合理的迁移方法和后续检查。
     善后，配置/重启应用，发现应用能正常登陆，于是收工回家。
     早上醒来，数据库巡检告警短信不期而至，表空间搬移到新库的standby报警，提示主备不同步。这下才想到昨晚马虎了一下，忘记了这是个DG环境。因为表空间搬移后，元信息被导入数据字典中，但数据文件是追加进来的，standby端通过apply归档日志只能得到表空间的相关信息，数据文件在备库端并不存在，所以无法继续做日志恢复。
     查看备库alert.log，确有这样的报警:

——————————–
Thu Aug 19 02:59:02 2009
Errors in file /opt/oracle/admin/orc1/bdump/orc1_dbw0_25859.trc:
ORA-01157: cannot identify/lock data file 27 - see DBWR trace file
ORA-01110: data file 27: ‘/data/orc1/crm04.dbf’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
———————————

     利用空闲时间，在primary端将搬移过来的表空间做了一次RMAN热备并生成一个standby controlfile，将备份传输到standby端，在备库上restore这个standby cf，然后restore tablespace，做recover后，DG再次同步，运行正常。
     看来做事还是马虎不得，还好这次只是个dg问题，即使有问题也不至于对生产产生大的影响。O(∩_∩)O

• 闲扯Dataguard的维护与运用
• 下午部署DG,顺手写了几个DG维护脚本
• 10G Dataguard影响日志传输服务参数
• Data Guard 之表误操作恢复
• Data Guard 之 MAXIMIZE PROTECTION

Report Summary

Cache Sizes

Load Profile

Instance Efficiency Percentages (Target 100%)

Shared Pool Statistics

Top 5 Timed Events

1.cpu time

    Oracle引入CPU time是在9iR2版本，cpu time是衡量一个数据库负载的重要指标，可以将它看成是“CPU used by this session”的收集汇总。
    9iR2之前，top 5部分称之为“Top 5 Wait Events”，其中cpu time并不包含在top 5内，该部分是纯粹的等待事件的汇总。而在9iR2之后，Top 5称之为“top 5 timed events”，从字面上也可以发现二者的区别。oracle将cpu time作为一个事件纳入top 5中，新的top 5包含cpu time和waited time 2部分，也就是db time。
    我们可以通过cpu time与waited time的比值，来了解库的负载和运行情况，通常较高的比例代表较好的性能；而通过平均每颗CPU耗费的cpu time和Elapsed time的比例，可以评估整个系统在CPU方面是否存在瓶颈.

2.db time

    db time是指oracle花费在cpu上和等待事件上的时间,上面已经说过，db_time=cpu_time+waited time。
    db time已经做为10g awr的一个采样指标，在9iR2上，我们同样可以通过top 5部分计算出来。在本例中，
db time=15958【db file sequential read】/51.8【%】/60=513.5min。这与awr db time一栏的采样数值是一致的.

3.response time

    基于transaction或者user call的平均响应时间，可以看做是我们做性能优化效果的一个交付和证据.个人觉得没必要太注重这个数值。
    response time=service time(cpu time) + waited time。放到我们前面的这个awr中，平均事务响应时间也就可以近似这样计算：
    avg trans response time =15958【db file sequential read】/51.8【%】/60/59.28【Elapsed】/2.30【transactions per second】=3.77s
    对于9iR2之前，需要通过”CPU used by this session“来计算cpu时间，通过“Top 5 Wait Events”计算等待事件时间，同样可以得出DB time和response time.

4.elapsed time

    elapsed time是指物理的流逝时间，这是一个采样的时间跨度基数。

• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除

1.利用ASM的热添加和删除磁盘的方式完成存储迁移.

   该方案充分发挥了asm管理磁盘数据的能力.
   简要步骤:
(1).划分raw或者asm disk，并检查或更改asm参数,例如asm_disktring，使得新存储的asm disk对ASM实例可识别
(2).将新存储disk添加到现有的asm diskgroup中.

(3).删除旧存储对应的asm disk

   注意:以上2步，通过观察v$asm_operation视图来判断数据重组的进度，注意删除disk的时候，确保整个diskgroup有足够的空间。如果asm disk比较多，可以一个一个的分步执行减缓系统压力.有点可惜的是，在10g版本中，oracle不支持asm diskgroup冗余类型的转换, 也没有直接提供删除failgroup的方法，否则以添加镜像failgroup的方式来完成这次数据迁移，个人觉得有更强的可控性和更低的风险.
   优缺点:
   该方案可以实现迁移过程中系统的零停机，但整个操作进度不可控，数据重组过程中我们无法把握进度和风险，如果你对ASM产品足够信任，该方案不失一用

2.利用Switch copy的方式完成存储迁移

   Switch copy并不是只能在ASM下才能用，但asm对数据文件的管理使得switch copy变得异常简单，免去了手工输入大量脚本的工作。

   简要步骤:
(1).在新存储上创建新的diskgroup

(2).整库在线backup copy到新diskgroup上

(3).修改参数文件control_files,停db并启动到nomount状态,迁移controlfile到新diskgroup,mount做switch copy

(4).迁移temp和logfile
   在新diskgoup上创建新的temp表空间;添加新logfile到新diskgroup,删除旧的temp、logfile.
(5).其他善后
   修改db_create_file_dest、db_create_online_log_dest_*、archive_log_dest_*等参数/卸载旧diskgroup等
   注意:需要注意保留日志的完整性，从backup copy开始到switch copy这段时间的归档日志/在线日志不能丢失，recover需要这部分日志，recover的时间决定了整个迁移的停机时间.
   优缺点:
   该方案风险可控，但需要评估从backup copy开始到switch copy这段时间的日志生成量，如果这段时间窗产生了大量的日志(有可能backup过程比较久而且db一直很忙,有很多事务和日志产生，或者backup之后并不是马上做switch，这期间也产生了很多日志)，那势必会增加迁移过程的停机时间.如果这段时间日志生成量有限，整个停机时间也会相当短.

3.一般方法：

   利用物理datagurd等.
   该方案风险最小，失败最容易回退.操作上整个停机时间一般不会超过10分钟.

• Oracle高可用迁移升级场景与实战(一)
• Hugepages On Linux
• 一次改变PUSHED PREDICATE方式进行SQL调优的案例
• 记一次高可用迁移方案的规划— Oracle 9i 32 bit升级至Oracle 10g 64 bit
• Logical Standby日常维护与性能优化(二)—性能诊断与优化
• Logical Standby日常维护与性能优化(一)—日常维护与故障排除