杨俊

云和恩墨西区技术专家

本文整理自上周四晚云和恩墨大讲堂分享的关于主题：炎炎夏日 - 恩墨小王子带你玩转“数据卫士”Data Guard.

在数据库的世界里有一个被称为数据卫士的守护者，它曾力挽狂澜成为纽约飓风中 JP Morgan（摩根大通集团）的救星，它以最低的成本实现最高的数据保护。今天让我带领大家从 Oracle 最高可用性体系结构 (MAA) 中推荐的有关 Data Guard 容灾配置最佳实践中走进 Oracle Data Guard 的世界，在这个炎炎夏日轻松玩转 DG。

主 题 简 介

随着企业信息化的发展，数据中心需要更高效地支持业务和信息共享需求，且提供不间断的服务，这对数据中心的资源整合、全面安全、高效管理和业务连续性提出更高的要求。而数据库管理着企业最核心的资产—数据。那么建设数据库系统的灾难备份系统，实现数据在灾难发生时的最大化保护和业务系统的持续服务能力成为一个摆在众多互联网企业信息化建设中的一道命题。

正式开始之前，先配上一张图,让小伙伴们心里先有个概念。

话说看到这张霸气十足跨越了2000多公里的 DG 示意图，小伙伴们有木有觉得很屌的样子呢？

而在我们的主题中关于纽约飓风又跟我们数据库 data guard 力挽狂澜拯救 JP Morgan（摩根大通集团）有什么关系呢？

2012年飓风桑迪袭击纽约

在此次飓风中 JP Morgan 在纽约的数据中心北水淹，数据通过部署的 ACTIVE DATA GUARD 切换到1400公里以外的备份中心，拯救了数据的损失。

现在咱们就言归正传，开始今天的主题。

首先，关于我！我是云和恩墨西南区的技术人员，base 美丽的云南昆明，目前还单身，这是重点，呵呵！曾全程参与过世界500强大型企业容灾数据中心的实施建设，目前负责某金融行业两地三中心的数据库级容灾项目，任项目经理。

下面我将结合实际工作，从以下几个方面和大家一起探讨。

1DG 的概念介绍

关于 DG，是 Oracle 自9i以来自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用性方案。

它通过建立一个 PRIMARY 和 STANDBY 组来确立其参照关系，如下图：

primary 数据库即被大部分应用访问的生产数据库，该库既可以是 单实例数据库，也可以是 RAC；

Standby 数据库是 primary 数据库基于事物一致的复制库。Data Guard 通过应用 primary 数据库的 redo 自动维护 standby 数据库。Standby 数据库同样即可以是单实例数据库，也可以是 RAC 结构。

而 Standby 数据库又分为物理 Standby 和逻辑 Standby 两种，两者的同步方式不一样，逻辑 standby 是通过接收 primary 数据库的 redo log 并转换成sql语句，然后在 standby 数据库上执行 SQL 语句 (SQL Apply) 实现同步，而物理 standby 是通过接收并应用 primary 数据库的 redo log 以介质恢复的方式 (Redo Apply) 实现同步。

而针对数据的保护模式，可以在 V$DATABASE 中查看到 Data Guard 的保护模式：

下面通过一个表格简单的列出不同版本的 data guard 新特性：

注：新的备用数据库类型 “Far Sync Standby Database”

这是一个本地 ARCHIVELOG 仓库（靠近主（Primary）数据库），它可以将 Redo 信息发送到远端（很远距离）备用数据库。Far Sync Standby Database 是通过 Far Sync Standby 级联到主数据库的一个备用数据库。因此，它可以使用更高的保护模式来服务于远程备用数据库，即使网络没有完全表现其能力。所有到远程物理备用数据库的 Redo 传输是通过 Far Sync Standby Instance 完成。

说了那么多 data guard 的概念性的东西，那么 DG 有什么优势呢?

而我们搭建 DG 的时候又有那些安装条件呢？

1. 主备库数据库版本相同

2. 主库开启归档模式

3. 主备库不能跨平台，不过可以跨操作系统版本

4. 主备库字节序一致

5. 主备库目录可以不同、硬件资源配置可以不同

6. 主备网络无延迟

7. 备库存储空间建议大于主库

2如何搭建 DG

前面我简单的介绍了 DG 的一些概念，下面我们就来动手搭建一套简单的 DG 吧！

第一步：资源准备

1. 准备同主库相同操作系统平台的备机服务器，容量不能低于主库

2. 主库生成 standby controlfile

alter database create standby controlfile as '/***/control01.ctl';

第二歩：环境安装

1. 根据原库的 Oracle 版本和补丁号，对 DG 备机进行 Oracle 软件的安装和补丁升级，并配置好环境变量

2. 同步主库的 spfile、standby controlfile、orapw 文件放到备机相应位置 注意 onctrolfile 的名字和路径需要和 spfile 中标记的一致

3. 启动主库到 mount 阶段

第三歩：主库设置检查、配置 DG 参数

-- 检查 force logging 是否开启为 YES

select force_logging from v$database;

-- 检查归档模式是否开启 ARCHIVELOG

select log_mode from v$database;

-- 配置 DG 参数

alter system set log_archive_dest_2='service=<sid>_sec LGWR SYNC NOAFFIRM NET_TIMEOUT=30';

-- 配置此归档路径先设置为 defer，等 standby 配置完后再设为 enablealter system set log_archive_dest_state_2=defer;

-- FAL 指获取归档日志的 server 端

alter system set fal_server='<sid>_sec';

-- FAL 指获取归档日志的 client 端

alter system set fal_client='<sid>';

注：这两个参数只需在 standby 库设置，但也可以在 primary 库设置这两个参数，以方便 switchover 或 failover 时 primary 库转变为 standby 角色

-- 打开数据文件自动添加

alter system set standby_file_management=auto;

-- 主库1800秒内自动切换 redo log

alter system set archive_lag_target=1800;

第四歩：配置 TNS

#主库

<sid> =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = *))

)

(CONNECT_DATA =

(SERVICE_NAME = <sid>)

)

)

#备库

<sid>_sec =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))

)

(CONNECT_DATA =

(SERVICE_NAME = <sid>)

)

)

第五歩：备库参数配置

--#根据备机实际路径修改

alter system set log_archive_dest_1='location=/<sid>/db_dg_arc ';

alter system set fal_server='<sid>';

alter system set fal_client='<sid>_sec';

第六歩：备份主库

run{

allocate channel ch1 type disk;

allocate channel ch2 type disk;

backup database

format 'd:\oraclebackup\data_%T_%u_%c.bak';

backup archivelog all

format 'd:\oraclebackup\data_%T_%u_%c.arc';

backup current controlfile

format 'd:\oraclebackup\data_%T_%u_%c.ctl';

release channel ch1;

release channel ch2;

}

第七步：恢复备库

-- 可使用最新的 standby control file 作为控制文件恢复数据文件

alter database mount;

restore database;

restore archivelog all;

select max(sequence#) from v$archived_log;

recover databaese;

第八步：配置 listener.ora 和 tnsnames.ora 并启动监听

# listener.ora

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = <sid>)

(ORACLE_HOME = /u01/oracle/product/db11gr2)

(SID_NAME = <sid>)

)

)

LISTENER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))

)

ADR_BASE_LISTENER = /u01/oracle

#TNS

#主库

<sid> =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = *))

)

(CONNECT_DATA =

(SERVICE_NAME = <sid>)

)

)

#备库

<sid>_sec =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))

)

(CONNECT_DATA =

(SERVICE_NAME = <sid>)

)

)

第九歩：备机启动到 standby  mount 阶段

Shutdown immediate

startup nomount;

alter database mount standby database;

第十步：备机上创建 standby logfile

ALTER DATABASE ADD STANDBY LOGFILE group 4 ('/*/stdredo01.log') SIZE **;

ALTER DATABASE ADD STANDBY LOGFILE group 5 ('/*/stdredo02.log') SIZE **;

ALTER DATABASE ADD STANDBY LOGFILE group 6 ('/*/stdredo03.log') SIZE **;

………………

注：standby logfile 需要比 redologfile 多一组，每组只能创建一个成员，group 编号不能重复

第十一歩：主库开启 log_archive_dest_state_2参数

alter system set log_archive_dest_state_2=enable;

#启动日志传输

第十二歩：DG 备库上启动同步

#开启应用

alter database recover managed standby database  disconnect from session;

#并行开启应用

alter database recover managed standby database  parallel  4 disconnect from session;

这样一套简单的 DG 库就搭建完毕了。

那么问题来了，咱们如何知道咱们的 DG 库日志同步正常、redo日志应用没问题呢？

3如何监控 DG 

一般 DG 安装完之后，或者在运行中，我们都会通过一个重要的视图 v$managed_standby 监控各进程的状态，以及归档应用情况：

注：进程 process 对应的几种不同名称表示不同的 data guard 进程，其中 RFS 进程表示接收日志进程、MRP0 进程表示恢复进程、ARCH 表示 Archiver 进程，后面跟着的 STATUS 表示每个进程的状态，THREAD# 表示实例的进程号，每个状态的说明如下：

ALLOCATED: 正在准备但还未连接主库

ATTACHED: 正在连接到主库

CONNECTED: 已经连接到主库

IDLE: 空闲

ERROR: 失败的进程，需要关注

RECEIVING: 归档日志接收中

OPENING: 归档日志处理中

CLOSING: 归档日志处理完，正在收尾中

WRITING: 进程在将 REDO 数据写向归档文件中

WAIT_FOR_LOG: 等待新的 REDO 归档数据中

WAIT_FOR_GAP: 归档有中断，正在等待中断的那部分 REDO 数据.

APPLYING_LOG: 正在应用 REDO 归档数据到备库

那么从上图可以看出，我们的 DG 库正在应用实例进程为2的日志8850，通过 RFS 日志传输进程看出日志传输到了实例1的日志13413.

我们通过备库获取到的这些信息，可拿到主库去比对当前数据库的最大日志号是多少，就能知道当前 DG 库的日志应用、传输情况是否正常了。

当然查询的方法很多，例如也可以通过备库、主库的 ALERT 日志进行比对，或看备库日志是否有报错等都能对 DG 库进行监控。

在此，我们来抛出一个问题：假如您是对100套主备库进行 DG 日常管理，那么您该如何监控这100多套主备库的实时应用状态呢？

以上为我们自己在运维大量 DG 主从库中的实际监控经验分享，方法还多种多样，各位小伙伴可以集思广益，也分享给大家。

在运维过程中，DG 库的监控是不容忽视的一部分，因为这关乎着我们的数据是否跟生产保持正常的同步状态，那么假如遇到主库故障了，我们又该如何使用 data guard 库保证业务连续性呢？下面我们用图来说明一下主从 DG 的切换方式。

4DG 的切换方式

在 DataGuard 模式下，有两种切换模式，Switchover 和 Failover ，这两种切换都需要手工执行完成（通过执行 sql 命令或用 Data Guard broker interface 工具完成）。

Failover 方式的切换是在主数据库宕掉（一般是硬件严重故障导致）后，物理备用数据库切换成 primary role 如图：

Switchover 方式是 primary 和 standby 互换角色，一般都是人为的有计划的切换，不会造成数据丢失。如图：

Data Guard broker interface 属于故障自动切换，因涉及生产数据的一致性，不建议配置。

接下来，我为大家分享一下 DG 的日常运维。

5DG 日常运维

1. 停止 Standby

-- 查看备库是否在应用日志进行恢复

select process, status from v$managed_standby;

alter database recover managed standby database cancel;

shutdown immediate;

2. 切换到只读模式

-- 由 shutdown 模式切换到只读模式

startup nomount;

alter database mount standby database;

alter database open read only;

-- 由应用日志模式切换到只读模式

-- 取消日志应用

alter database recover managed standby database cancel;

alter database open read only;

-- 物理 Standby 取消延迟应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

3. 切换回管理恢复模式

-- 启动日志应用

startup nomount;

alter database mount standby database;

alter database recover managed standby database disconnect from session;

alter database recover managed standby database using current logfile disconnect from session;

-- 备库延迟120分钟应用主库日志

alter database recover managed standby database delay 120 disconnect from session;

4. 主库和备库之间角色切换

-- 主库切换为备库

alter database commit to switchover to physical standby;

-- 主库有会话连接的时候

alter database commit to switchover to physical standby with session shutdown;

shutdown immediate

startup nomount;

alter database mount standby database;

alter database recover managed standby database disconnect from session;

-- 从库切换为主库

alter database commit to switchover to primary;

shutdown immediate;

startup

alter system switch logfile;

5. 备库自动使用主库传过来的日志进行恢复

alter database recover automatic standby database;

6. 更改保护模式

alter database set standby database to maximize protection;

alter database set standby database to maximize availability;

alter database set standby database to maximize performancen;

7. 取消自动恢复模式

alter database recover managed standby database cancel;

alter database recover managed standby database finish;

alter database recover managed standby database finish force;

8. 查看主备库保护模式

-- 查看主库保护模式：

SQL> select protection_mode,database_role,protection_level,open_mode from v$database;

PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE

-------------------- ---------------- -------------------- --------------------

MAXIMUM PERFORMANCE  PRIMARY          MAXIMUM PERFORMANCE  READ WRITE

-- 查看备库保护模式：

SQL> select protection_mode,database_role,protection_level,open_mode from v$database;

PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE

-------------------- ---------------- -------------------- --------------------

MAXIMUM PERFORMANCE  PHYSICAL STANDBY MAXIMUM PERFORMANCE  MOUNTED

9. 查看备库进程状态  

SQL>select process,client_process,sequence#,status from v$managed_standby

PROCESS   CLIENT_P  SEQUENCE#    STATUS

---------       --------     ----------

ARCH      ARCH            153          CLOSING

ARCH      ARCH            154          CLOSING

MRP0      N/A             158          WAIT_FOR_LOG

RFS       UNKNOWN         0             IDLE

RFS       LGWR            158           IDLE

RFS       ARCH            0             IDLE

10. 主库建立备库的 standby 控制文件

SQL> alter database create standby controlfile as '/u01/standby.ctl' reuse;

11. 查询 GAP

select * from V$ARCHIVE_GAP;

12. 注册日志

ALTER DATABASE REGISTER LOGFILE '日志';

6DG 的实用技巧

在 DG 的日常应用中，我们能从中得到很多便利，今天最后给大家分享一二，抛砖引玉。

1. 在 Oracle 11g 之前，物理备库（physical Standby）在应用 redo 的时候，是不可以打开的，只可以 mount。从 11g 开始，在应用 redo 的时候，物理备库可以处于 read-only 模式，这就称为 Active Data Guard 。通过 Active Data Guard，可以在物理备库进行查询或者导出数据，从而减少对主库的访问和压力, Active Data Guard 适用于一些只读性的应用，比如，有的应用程序只是查询数据，进行一些报表业务，不会产生 redo 数据，这些应用可以转移到备库上，避免对主库资源的争用，一些实时性要求不高的查询应用也可以部署数据源指向 ACTIVE DG 达到读写分离的效果。

如下图读写分离的典型架构 -Reader Farm 对网站应用。

2. Oracle10G 引入闪回，启用 flashback database 后数据库可以在备库闪回某些误删除操作，且每次闪回开启不用重新搭建备库、且可以把有些生产变更的风险操作在 DG 备可以上提前当做预生产执行，验证生产变更的可靠性。

3. 备份、迁移、生产数据导出均可以在 DG 备库上执行

4. 定期进行容灾演练保障容灾系统的可用性

总 结

当然还有很多 DG 的妙用等待各位小伙伴们来我们恩墨大讲坛进行分享，回过头来，各位亲是不是就对今天分享一开始上的那张霸气十足的图有一个深入的认识了呢？其实那种跨越2000多公里距离的 DG 应用就是一个两地三中心的建设模型图，偶们现在是不是也可以轻松搞定了呢？

如何加入云和恩墨大讲堂微信群

搜索盖国强（Eygle）微信号：eeygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。

往期大讲堂精彩主题回顾

  • 20160107期：李真旭 - 动手为王 - 整合迁移与数据恢复实践

  • 20160113期：敬勇 - 一条执行时间小于1秒的 SQL 引发的性能问题

  • 20160114期：郑保卫 - 索引优化策略及实战

  • 20160128期：黄廷忠 - 性能为王 - SQL标量子查询的优化案例分析http://dwz.cn/3xRiAT

  • 20160128期：黄廷忠 - SQL审核 - OR 展开与子查询优化案例详解http://dwz.cn/3xRjPL

  • 20160224期：黄廷忠 - 见微知著 - 一条SQL性能问题引发的核心系统悲剧http://dwz.cn/3xRp6d

  • 20160310期：李华 - 故障分析 | library cache latch 竞争案例分享

  • 20160317期：于远 - 一条让人欲罢不能的 SQL给我的启发

  • 20160324期：皇甫晓飞 - 日常运维经验分享 - 合理使用存储过程提高运维效率

  • 20160331期：戴明明 - 基于PCIE 闪存卡的 Oracle 数据库使用（一）

  • 20160331期：戴明明 - 基于PCIE 闪存卡的 Oracle 数据库使用（二）

  • 20160407期：怀晓明 - 细致入微 | 让 SQL 优化再多飞一会儿

  • 20160414期：李建国 - Oracle 远程 RAC 打造双活数据中心 | 从容灾迈向双活案例分享

  • 20160421期：盖国强 - Oracle 数据库的架构演进和我的学习之路

  • 20160428期：黄嵩 - 一次 truncate 核心表衍生的信息系统安全思考

  • 20160505期：陈龙 - 探究 Oracle 高水位对数据库性能影响

  • 20160519期：李轶楠 - 意料之外的 RAC 宕机罪犯 - 子游标

  • 20160526期：程昌明 - 通过 Oracle 日志文件了解 CRS 的启动过程

  • 20160602期：李真旭 - 数套 ASM RAC 的恢复案例

  • 20160616期：李翔宇 - 轻轻揭开 b*tree 索引结构的神秘面纱

  • 20160623期：黄宸宁 - 一次特殊的 ORA-04030 故障处理

  • 20160630期：钟时荣 - SQL性能突然降低引起的业务办理缓慢案例一则

  • 20160707期：易欣 - TX - row lock contention 的一些场景

  • 20160714期：巩飞 - Oracle 实用技巧之不知道密码情况下 dblink 的迁移

  • 20160721期：李磊 - 深入剖析 ORA-04031 的前世今生（图文二）

炎炎夏日-恩墨小王子带你玩转“数据卫士”Data Guard相关推荐

  1. 【数据服务校招专场】云和恩墨2022届春季校招「数据服务岗位」持续招聘中！...

    数据驱动,成就未来,云和恩墨,不负所托! 云和恩墨创立于2011年,以"数据驱动,成就未来"为使命,是智能的数据技术提供商.我们致力于将数据技术带给每个行业.每个组织,构建数据驱动 ...

  2. 【云和恩墨大讲堂】杨俊 | 迁移神技XTTS-恩墨小王子再战32TB跨平台U2L

    "云和恩墨大讲堂" 线上课程周四晚继续开讲.本期我们邀请的嘉宾是云和恩墨西区技术专家 - 杨俊,跟大家分享XTTS 基于32TB 数据的跨平台U2L实现.课程以图文形式在微信课堂群 ...

  3. 如何在不改SQL的情况下优化数据库- 云和恩墨优化专家罗海雄

    罗海雄 云和恩墨优化专家 ITPUB论坛数据库管理版版主,2012 ITPUB全国SQL大赛冠军得主,他还是资深的架构师和性能优化专家,对 SQL 优化和理解尤其深入:作为业内知名的技术传播者之一,经 ...

  4. 云和恩墨大讲堂－Thinking in SQL，这是一次烧脑的课程

    "云和恩墨大讲堂" 阳春三月倾情奉献!本期我们邀请的嘉宾是日立咨询(中国)有限公司的Oracle数据库专家牛超.课程以图文形式在微信课堂群全程同步直播,请准时守候. 1 课程介绍 ...

  5. 【云和恩墨大讲堂】高凯 | Oracle 12c 新特性-多租户的维护管理

    "云和恩墨大讲堂" 线上课程周四晚继续开讲.本期我们邀请的嘉宾是云和恩墨西北区技术专家 - 高凯,在这里跟大家分享一下 Oracle 12c 新特性方面的主题.课程以图文形式在微信 ...

  6. 【云和恩墨大讲堂】罗海雄 | 如何在不改SQL的情况下优化数据库

    "云和恩墨大讲堂" 线上课程周四晚继续开讲.本期我们邀请的嘉宾是云和恩墨北区技术专家 - 罗海雄,跟大家分享如何在不改SQL的情况下优化数据库.课程以图文形式在微信课堂群全程同步直 ...

  7. 云和恩墨大讲堂新春第一讲－Oracle安全特性之加密登陆

    "云和恩墨大讲堂" 新春第一讲开讲啦!本期我们邀请的嘉宾是太极计算机股份有限公司数据库专家赵全文.课程以图文形式在微信课堂群全程同步直播,请准时守候. 1 课程介绍 名称:云和恩墨 ...

  8. 【云和恩墨大讲堂】彭文元 - 中间件BES连接池的配置和问题诊断方法

    "云和恩墨大讲堂" 线上课程周四晚继续开讲.本期我们邀请的嘉宾是云和恩墨西区技术专家 - 彭文元,为大家带来宝兰德 BES 中间件 JDBC 连接池配置和问题诊断的一些方法,供大家 ...

  9. 【云和恩墨大讲堂】尹涛 - 由DRM引起的ORA-00481错误

    "云和恩墨大讲堂" 线上课程周四晚继续开讲.本期我们邀请的嘉宾是云和恩墨西北区技术专家 - 尹涛,将带来大家都很熟悉的 ORA-00481 错误相关主题.课程以图文形式在微信课堂群 ...

最新文章

  1. 互联网大脑进化简史，华为云EI智能体加入-2018年7月新版
  2. OC语言大总结（上）
  3. 开源的那些事儿之如何看待开源
  4. 用python画皮卡丘源代码-利用Python绘制萌萌哒的皮卡丘
  5. Nginx面试中最常见的18道题及答案
  6. 在GIS中运用坐标系统
  7. 以下关于c语言中static和const,c语言中static const作用
  8. JavaScript基本数据类型和引用数据类型
  9. Expression Studio简体中文正式版+序列号.
  10. JS中浅拷贝和深拷贝的使用，深拷贝实现方法总结
  11. Revit Family API 添加几何实体
  12. 微信公众号weui的使用
  13. Document/View/Frame三口组深入探讨
  14. Java如何创建参数个数不限的函数
  15. 十种做Flash游戏赚钱的方法
  16. 计算机关机桌面就还原,电脑重启后桌面还原怎么办
  17. Mqtt ----心跳机制 长链接 ping
  18. egret php交互,微信小游戏API调用Egret
  19. IDEA如何从本地文件导入jar包
  20. 原生JAVASCRIPT实现地球模型MAP效果 交互式WORLD INTERACTIVE

热门文章

  1. 个人小程序跳转公众号文章
  2. [源码和文档分享]基于JAVA实现的幼儿园信息管理系统
  3. e-人事管理系统-人事档案-角色定义
  4. Docker中搭建RTMP直播流服务器
  5. linux下ga-g31m-es2c v2.3 主板网卡atheros ar8132 驱动安装
  6. fmc接口定义_FMC接口标准
  7. python+selenium 浏览器驱动下载
  8. 西门子200SMART加显控触摸屏水处理程序案例控制系统程序，30吨双级反渗透加EDI工艺
  9. iOS9-by-Tutorials-学习笔记五：Multitasking
  10. extremecomponents学习总结（转）