PRM-DUL在Linux/Unix VNC下的显示问题

PRM-DUL在Linux/Unix  VNC下的显示问题,PRM-DUL在Linux VNC远程图形化下若出现无法显示菜单栏的问题,那么可以使用快捷键AlT+F7后来拖动窗口,显示出 PRM-DUL的图形化界面。

注意当使用PRM-DUL在恢复大数据量的数据库时优先考虑启用VNC,否则若Xmanager之类的工具出现中断,那么可能需要从头再。

基于12c in-memory新特性的SQL优化比拼

在本次中#2014年Orcl-Con甲骨文控活动#引入了一个利用12c in-memory特性优化查询语句的workshop ,在不考虑索引等特性的前提下,仅仅使用12c IMCC特性,崔胄同学利用inmemory和并行特性将原本需要1分钟运行的SQL,优化到1.37秒,提升数十倍,成功赢得ipad!

该次SQL优化比拼的 原帖地址http://t.cn/RzURLTJ

 

 


OKAY 我们来优化一下, 既然索引,物化视图等传统技术无法使用,我们只能使用使用一些oracle的大数据处理技术来提高性能
首先创建表 scripts 可以查看 xxxxxxxx 
这里提一下, 在创建表的时候使用pctfree 0 来适当的降低了逻辑读。

创建完毕

COUNT(*)||'TIME_ROWS'
58432 time_rows
29402976 sales_rows
1776000 customers_rows
160 channles_rows

创建完后 跑了一下 

no tuning
172706 consistent gets
Elapsed: 00:00:22.11

oooooopss~ 22秒 看来需要优化
开始使用 in-memory 组件 来优化

SQL> select * from v$version;
BANNER 
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

SQL> show parameter inmemory

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
inmemory_clause_default string
inmemory_force string DEFAULT
inmemory_max_populate_servers integer 7
inmemory_query string ENABLE
inmemory_size big integer 16G
inmemory_trickle_repopulate_servers_ integer 1
percent
optimizer_inmemory_aware boolean TRUE

如果内存有限 可以适当的只存放 需要的 列来降低使用memory

alter table SHOUG.times inmemory;
alter table SHOUG.sales inmemory;
alter table shoug.sales no inmemory(PROD_ID,PROMO_ID,QUANTITY_SOLD);
alter table shoug.customers inmemory;
alter table SHOUG.channels inmemory;

Statistics
41 recursive calls
17 db block gets
54 consistent gets
2 physical reads
1188 redo size
1584 bytes sent via SQLNet to client
562 bytes received via SQLNet from client
3 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
24 rows processed

Elapsed: 00:00:19.70

可以看到 物理读几乎已经很弱了, 但是速度还是不快 
优化CPU使用, 可以看到 inmemory 使用后 cpu 使用率达到了100% 但是, 可以看到等待全落在了 单颗 cpu上

所以根据数据量的大小, 来设置并行度
conn shoug/oracle
alter table shoug.sales parallel 8;
alter table shoug.times parallel 1;
alter table shoug.customers parallel 8;
alter table shoug.channel parallel 4;

select table_name,degree from user_tables;

set timing on
SELECT /* use inmemory / /+parallel (shoug.customers 8)*/ c.cust_city,
t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM SHOUG.sales s, SHOUG.times t, SHOUG.customers c
WHERE s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND c.cust_state_province = 'FL'
AND t.calendar_quarter_desc IN ('2000-01', '2000-02', '1999-12')
AND s.time_id IN
(SELECT time_id
FROM SHOUG.times
WHERE calendar_quarter_desc IN ('2000-01', '2000-02', '1999-12'))
AND s.cust_id IN
(SELECT cust_id FROM SHOUG.customers WHERE cust_state_province = 'FL')
AND s.channel_id IN
(SELECT channel_id
FROM SHOUG.channels
WHERE channel_desc = 'Direct Sales')
GROUP BY c.cust_city, t.calendar_quarter_desc;

24 rows selected.

Elapsed: 00:00:01.37

Statistics
203 recursive calls
0 db block gets
254 consistent gets
0 physical reads
0 redo size
1574 bytes sent via SQLNet to client
562 bytes received via SQLNet from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)

[root@db ~]# top
top - 23:51:34 up 6 days, 18:18, 6 users, load average: 0.65, 0.17, 0.15
Tasks: 391 total, 3 running, 387 sleeping, 0 stopped, 1 zombie
Cpu0 : 23.3%us, 0.0%sy, 0.0%ni, 76.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 22.6%us, 0.3%sy, 0.0%ni, 77.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 23.7%us, 0.3%sy, 0.0%ni, 76.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 22.3%us, 0.0%sy, 0.0%ni, 77.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 54.8%us, 0.7%sy, 0.0%ni, 44.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 22.1%us, 0.0%sy, 0.0%ni, 77.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 24.3%us, 0.0%sy, 0.0%ni, 75.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 22.6%us, 0.3%sy, 0.0%ni, 77.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32882416k total, 32061328k used, 821088k free, 13416k buffers
Swap: 8388600k total, 52k used, 8388548k free, 30221056k cached

可以看到cpu使用率达到了30% 以上, 并且, 已经没有内存排序

PS: 恭喜 oracle 在12.1.0.2 版本内 以inmemory 列存储的方式 推出了 vector计算方式, 打破了actian vector db 在大数据市场独领风骚的格局。

 

SHOUG User Group Young Expert Program

SHOUG User Group Young Expert Program, 用户组年轻专家计划, 如果你有oracle技术相关的博客或者最近在微博/微信上发表具有代表性的文章,那么可以得到SHOUG的年轻专家提名, 提名由Oracle审核后,获得提名者 可以获得免费的Oracle考试券 以及 其文章将被发表到OTN CHINA

以下达成一个即可:

1、 Publish a blog post or article about Oracle Database technology (subject and link are required).
2、 Have a posting on Weibo or Wechat that has been forwarded or referenced by Oracle China Weibo or Wechat (screen shot or links are required).
3、 Lead an Oracle database session at a conference or event (subject and link of the slide deck are required).

考试券数量有限,先到先得! 若您觉得自己达成以上条件,那么请将自己的文章/博客地址 发送到shoug.drive@gmail.com

 

2014年Orcl-Con甲骨文技术控活动精彩瞬间

2014年Orcl-Con甲骨文技术控活动精彩瞬间

 

2014年甲骨文技术控活动精彩瞬间

本次大会文档下载

《MySQL Replication的条条大路 》 from Giuseppe Maxia

《Oracle数据库的保护之手》 from SHOUG 刘相兵

《PL/SQL : 请避免造成同样的性能错误》from Tim hall

《RAC manageing planned downtime with RAC》 from Björn Rost

《Oracle 12c in-memory特性在中国的实践》 沈宏
 《Oracle信息化发展趋势与Oracle IT战略 》   刘冰冰

Oracle公司移动应用产品经理 Joe Huang 演讲主题:《使用Oracle Mobile Application Framework加速企业应用移动化》

Oracle公司高级技术咨询经理 刘冰冰在分享《Oracle信息化发展趋势与Oracle IT战略》

SHOUG 上海Oracle用户组发起人、诗檀软件创始人 刘相兵在介绍SHOUG宗旨以及 活动当天的现场Workshop:利用12c in-memory特性优化一个大型查询语句,优化后效果最好的同学获得了当天的大奖IPAD。

具体可以参见论坛上的workshop记录:http://f.shoug.info/?/question/13

Oracle-Base.com Oracle技术著名网站管理者,ACE Director- Tim Hall 演讲主题:《避免在PL/SQL中犯同样的性能错误》

Tim Hall现场演示了几个常犯的Pl/SQL性能错误

Continuent公司高级MySQL顾问,Oracle ACE Director – Giuseppe Maxia 演讲主题: 《MYSQL复制的条条大路》

SHOUG 上海Oracle用户组发起人、诗檀软件创始人 刘相兵 分享主题 《Oracle数据库的保护之手》

德国Oracle知名专家,Oracle ACE Director -Bjoern Rost 演讲主题: 《配备Oracle RAC以减少应用downtime》

Oracle公司数据库高级咨询顾问 沈宏 演讲主题: 《Oracle 12c in-memory在中国的实践》

Oracle公司移动应用产品经理 Joe Huang 演讲主题:《使用Oracle Mobile Application Framework加速企业应用移动化》

 

oracle database 11.2.0.1 AIX 7.1的认证

oracle database 11.2.0.1 AIX 7.1的认证:11.2.0.1是认证AIX 7.1操作系统的。

但要求AIX 7.1上安装以下三个APAR:

The customers must install the follow APARs (IBM OS Patches) on AIX7.1:

  • IZ87216
  • IZ87564
  • IZ89165

 

Screen Shot 2014-11-14 at 2.30.46 PM

 

 

Oracle Database 11.2.0.1.0 with IBM AIX on POWER Systems (64-bit) 7.1

Product: For general information relating to certification for the Oracle Database product, including virtualization, interoperability, binary compatibiliy, general release and patch set information, see Core Database Certification Information (Doc ID 1306539.1).

Platform: For details about certification of all Oracle Database releases on IBM AIX on Power, click here.

ACFS requires a minimum OS level of  AIX 6.1 TL4 SP2, AIX 7.1 is not supported at this time. For more details please review Oracle documentation

Oracle Database products are tested and certified on the AIX 5,  AIX 6  and AIX 7 operating systems. The customers must install the follow APARs (IBM OS Patches) on AIX7.1:

  • IZ87216
  • IZ87564
  • IZ89165

For further details on minimum software versions and patch requirements, refer to 282036.1

Certification: For details specific to the certification of Oracle Database Release 11.2 on IBM AIX on Power, click here.

The following notes apply to release 11.2.0.1.0 of Oracle Database:

ACFS: Oracle Cloud File System (ACFS) certification details are listed under the “Oracle Cloud File System” product

 

Oracle数据库打不开的解决

造成Oracle数据库打不开,无法打开的情况大致有几种:

  • 参数设置不当
  • 控制文件损坏
  • 日志文件损坏
  • 数据文件头损坏
  • 数据字典损坏
  • UNDO损坏
  • SMON回滚事务时遇到问题

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 400-690-3643   备用电话: 18501767907    邮箱:service@parnassusdata.com

 

针对不同的报错ORA-00600/ORA-07445等,可以有不同的应对方法:

 

在ORACLE中形成 数据块损坏/坏块诊断corruption多种多样,但其症状大致为如下几种:

  • ORA-01578错误
  • ORA-600[61xx]错误
  • ORA-600[3339]或者ORA-600[3398]
  • ORA-600[2130],ORA-600[2845],ORA-600[4147]错误等等
  • SELECT 查询出讹误的数据

 

应当该类ORACLE数据块损坏/坏块诊断的问题 有这么几个三板斧的步骤:

1、如果数据库仍然是打开状态,则需要判断该块损坏/坏块所在的 数据文件号、块号 并定位到具体的对象(可能是表或者索引)。 结合ORA-1578错误或者ORA-600报出的变量信息,采取如下SQL来定位

 

SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = &fileid
and &blockid between block_id AND block_id + blocks - 1;

 

2、取决于上一步获得的SEGMENT_TYPE, 如果是以下的SEGMENT_TYPE是可以重建的:

  • index
  • 数据可以重新获得的表,或者可以重建的表
  • 回滚段,除了SYSTEM这个回滚段
  • 排序段 , sort segment
  • 临时表

 

 

3、 如果不属于步骤2中支出的任何一种,那么需要注意以下的信息:

  • 数据库是否是归档模式
  • 有无表的备份数据,包括export /sqlldr
  • 是否该表上有基于 NOT NULL字段的索引?
  • 如果有这样的索引,那么是否是UNIUQE的?

 

4、是否这套库从前已经有块损坏/坏块的情况? 这一点有经验的DBA可以从alert.log大致了解情况的, 如果以往有过此类问题则可以参考下文的后续建议

 

5、如果用户正使用归档模式,则应当建议保存一份归档redo和在线日志以便今后的后续诊断。如果不是,则要求用户备份所有的在线日志

 

6、在有条件的情况下做10210,10211和10212 event来捕捉错误源头。 如果现场工程师怀疑问题不是由于 ORACLE本身引起的,则建议dump 有问题的数据块并结合OS和存储、卷管理器的日志来分析。  如果怀疑是内存损坏则有必要考虑_db_block_cache_protect ,注意不是所有平台支持_db_block_cache_protect而且其损坏较多性能

 

7、在某些情况下,有必要要求用户启用归档模式来避免后续再次发生问题时无法有效恢复

 

必要收集的证据

 

1、 包括ORACLE TRACE和ALERT文件,这个是我们诊断此类问题的源头, 并分析这些报告中是否有其他数据块被报告存在损坏

2、从OS角度转储坏的数据块

Unix: dd if=badfile.dbf count=5 bs=2048 skip=75

 

 

后续建议

 

1、当我们在分析trace或redo日志转储时 有必要调整用户的预期,要表达给用户这些信息:

  • 我们在帮助判断原因,而不是判断如何修复这些坏块
  • 我们在研究这些证据,但这些证据未必能让我们下决定性的结论

 

 

2、有时候数据块是在内存中损坏了 例如ORA-600[3398],为了验证这些情况可以:

  • analyze table X validate structure cascade;
  • alter system flush buffer_cache;
  • 从OS角度转储该数据块并分析

 

 

后续措施

 

1、寻找本质, 例如:

  • 所有的损坏都只发生在某个裸设备或者设备或者控制器上
  • 每数4个块出现一个坏块
  • 数据块本身没问题,但是出现的位置不对
  • 数据块的部分是健康的,但其他地方不正确

 

2、 通过绕过存在 损坏/坏块的数据块来重建表:

使用10231 level 10事件来执行一个全表扫描的CTAS

通过构建ROWID来避免访问损坏的数据块 【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题

 

3、 启用10210、10211和10212并更新数据块来进一步定位坏块的细节,并考虑使用10231 event

 

其他工具

 

其他可选的工具包括dul、oranum、orapatch、bbed等,这些都是ORACLE内部工具。

Oracle Optimizer Hint优化器提示分类表

Oracle Optimizer Hint优化器提示分类表

 

 

 

分类 9i R1 9i R2 10g R1 10g R2 11g R1 11g R2
优化器模式 ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS
FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n)
CHOOSE CHOOSE
RULE RULE RULE ※askmaclean.com
Hints OPTIMIZER_FEATURES_ENABLE
针对访问路径 FULL FULL FULL FULL FULL FULL
access path的HINT ROWID ROWID
CLUSTER CLUSTER CLUSTER CLUSTER CLUSTER CLUSTER
HASH HASH HASH HASH HASH HASH
INDEX INDEX INDEX INDEX INDEX INDEX
NO_INDEX NO_INDEX NO_INDEX NO_INDEX NO_INDEX NO_INDEX
INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC
INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE
INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN
INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC
INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS
AND_EQUAL AND_EQUAL NO_INDEX_FFS NO_INDEX_FFS NO_INDEX_FFS NO_INDEX_FFS
INDEX_SS INDEX_SS INDEX_SS INDEX_SS
NO_INDEX_SS NO_INDEX_SS NO_INDEX_SS NO_INDEX_SS
INDEX_SS_ASC INDEX_SS_ASC INDEX_SS_ASC INDEX_SS_ASC
INDEX_SS_DESC INDEX_SS_DESC INDEX_SS_DESC INDEX_SS_DESC
关于转换的HINT NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION
USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT
NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND
REWRITE REWRITE REWRITE REWRITE REWRITE REWRITE
EXPAND_GSET_TO_UNION
NOREWRITE NOREWRITE NO_REWRITE NO_REWRITE NO_REWRITE NO_REWRITE
MERGE MERGE MERGE MERGE MERGE MERGE
NO_MERGE NO_MERGE NO_MERGE NO_MERGE NO_MERGE NO_MERGE
STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION
NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION
FACT FACT FACT FACT FACT FACT
NO_FACT NO_FACT NO_FACT NO_FACT NO_FACT NO_FACT
UNNEST UNNEST UNNEST UNNEST
NO_UNNEST NO_UNNEST NO_UNNEST NO_UNNEST
JOIN order HINT LEADING LEADING LEADING LEADING
ORDERED ORDERED ORDERED ORDERED ORDERED ORDERED
STAR STAR
JOIN操作HINT USE_NL USE_NL USE_NL USE_NL USE_NL USE_NL
NO_USE_NL NO_USE_NL NO_USE_NL NO_USE_NL
USE_NL_WITH_INDEX USE_NL_WITH_INDEX USE_NL_WITH_INDEX USE_NL_WITH_INDEX
USE_MERGE USE_MERGE USE_MERGE USE_MERGE USE_MERGE USE_MERGE
NO_USE_MERGE NO_USE_MERGE NO_USE_MERGE NO_USE_MERGE
USE_HASH USE_HASH USE_HASH USE_HASH USE_HASH USE_HASH
NO_USE_HASH NO_USE_HASH NO_USE_HASH NO_USE_HASH
DRIVING_SITE DRIVING_SITE (参见其他HINT) (参见其他HINT) (参见其他HINT) (参见其他HINT)
LEADING LEADING
HASH_AJ、MERGE_AJ、NL_AJ HASH_AJ、MERGE_AJ、NL_AJ
HASH_SJ、MERGE_SJ、NL_SJ HASH_SJ、MERGE_SJ、NL_SJ
特殊 CHANGE_DUPKEY_ERROR_INDEX
IGNORE_ROW_ON_DUPKEY_INDEX
RETRY_ON_ROW_CHANGE
并行执行HINT PARALLEL PARALLEL PARALLEL PARALLEL PARALLEL PARALLEL
NOPARALLEL NOPARALLEL NO_PARALLEL NO_PARALLEL
PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE
PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX
NOPARALLEL_INDEX NOPARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX
其他HINT APPEND APPEND APPEND APPEND APPEND APPEND
NOAPPEND NOAPPEND NOAPPEND NOAPPEND NOAPPEND NOAPPEND
APPEND_VALUES
CACHE CACHE CACHE 诗檀软件 CACHE CACHE CACHE
NOCACHE NOCACHE NOCACHE NOCACHE NOCACHE NOCACHE
UNNEST UNNEST
NO_UNNEST NO_UNNEST
PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED
NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED
PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ
NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ
QB_NAME QB_NAME QB_NAME QB_NAME
ORDERED_PREDICATES ORDERED_PREDICATES
CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT
DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING
SPREAD_MIN_ANALYSIS
MODEL_MIN_ANALYSIS MODEL_MIN_ANALYSIS MODEL_MIN_ANALYSIS
DRIVING_SITE DRIVING_SITE DRIVING_SITE DRIVING_SITE

PRM-DUL成功案例:帮助北京某政府机构恢复硬盘损坏的Windows服务器上的oracle数据库

PRM-DUL成功案例:帮助北京某政府机构恢复硬盘损坏的Windows服务器上的oracle数据库。

 

该数据库版本为11.2.0.1,由于硬盘机械故障 存在较多的坏道,导致ORACLE实例无法正常启动 打开数据库,OPEN会因为ORA-01115、ORA-01110、ORA-27070、OSD-04006、O/S-Error:等错误而终止:

 

ORA-01115: IO error reading block from file  (block # )
ORA-01110: data file 3: 'ORCL\UNDOTBS01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

 

通过PRM-DUL直接使用字典模式加载所有数据文件后,直接绕过了无法读取的坏道数据块数据,成功加载数据字典,并恢复了用户Schema下的数据:

 

QQ截图20141128154838

 

 

QQ截图20141128155026

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 400-690-3643   备用电话: 18501767907    邮箱:service@parnassusdata.com

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件,其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。 下载地址:http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf