如何理解Oracle中的incarnation概念?

如何理解Oracle中的incarnation概念?

 

小明 活到了90岁 这是incarnation A , 这个matrix 矩阵世界里的 root (or oracle)管理员 将 小明世界的时间节点回退到了小明20岁时(同时resetlogs),由于神的能力还不足以让这个宇宙里的一切量子变化都保证和之前的那一次完全一样,所以这次回退节点里的小明 是incarnation B,最后incarnation B的小明也会活到90岁。

虽然最后2个小明都90岁了,但这2个小明并不是一样的 ,他们都叫小明,但需要区别他们 所以一个叫incarnation A 另一个叫incarnation B。 在其他平行世界里可能还有其他 incarnation的小明,这取决于 root (or oracle)管理员的需求。

Oracle亚太用户组社区领导人峰会(APOUC)圆满落幕

亚太甲骨文用户组社区进入新阶段

 

北京,20141017 ——

近日,第十届甲骨文亚太用户组社区领导人峰会(Asia Pacific Oracle User Group Community (APOUC) Leaders’ meeting)在香港顺利闭幕,来自中国,日本,泰国,印度等国家的21个用户组25个领军人物齐聚一堂,共同探讨Oracle独立用户组社区的发展状况,同时针对包括JAVA,Database,Application等技术分享相关的最佳实践、创意和经典案例。

会议背景及亮点

  • 凭借在全球范围内拥有超过900个用户组的庞大基数,Oracle用户组社区为所有客户提供了一个包含联络网、信息和最佳实践分享的环境。同时,作为收集信息反馈的关键来源,该社区也帮助甲骨文公司为现有客户提高产品质量、服务水平和综合体验。
  • APOUC的宗旨是为亚太地区Oracle用户组领导人和Oracle之间搭建面对面的沟通桥梁,为用户组社区领导人提供 甲骨文产品和服务的最新资讯,并促进亚太Oracle用户组之间的相互了解和合作。
  • 甲骨文以不同的方式支持其独立用户组社区的发展,甲骨文用户组社区领导人峰会就是其中一种方式。作为一年一次的年度盛会,甲骨文亚太用户组社区领导人峰会同步在亚洲、美洲、欧洲等地区举行,与全球用户大会不同的是,甲骨文亚太用户组社区领导人峰会讨论的内容更加因地制宜,让不同区域的用户对自身所在地区的产品应用更有的放矢,同时能够向其它地区的开发者们学习先进或独特的技术经验。
  • 本次峰会是APOUC阔别香港四年后再次于港举办,会上来自甲骨文香港的市场总监Sylvia Lee向与会嘉宾致欢迎辞。
  • 活动期间,与会者重点探讨了SaaS、移动、物联网、大数据等行业热点话题。同时,甲骨文全球客户计划全球副总裁Tony Banham和iTech 亚太区的Peter Yu分别针对大家关心的Oracle Reference项目和Oracle技术网的ACE项目做了详细讲解。
  • 来自Oracle的用户组团队就用户组和Oracle合作的方式和途径、全球其他地区Oracle用户组的概况和成功实践、未来相关Oracle用户组社区的计划和安排等话题进行了详细介绍。
  • 下午与会者就“Java”以及“Oracle Tech&Apps”两个核心话题进行深入探讨和案例分享。颇受欢迎的“四分钟演讲”环节中有十六位与会者分享其用���组的最佳实践、创新想法和社区故事。
  • 在Java专场中,来自印度、中国大陆、台湾、澳大利亚等Java用户组领导人还介绍了近期围绕Java 8发布而举行的全球Java巡讲活动。该活动于5月来到中国,并于4月30日-10日,分别在北京、广州、上海、南京、杭州举行了7场共创Java未来的活动。来自广东,上海,南京及GreenTea JUG的Java 用户组还于各自城市成功举办了 Java 8的分享和庆祝活动。

甲骨文高管及相关引言

  • 甲骨文公司高级副总裁及首席客户官Jeb Dasteel表示:“Oracle 一直致力于在全球范围建立强大独立的用户组,随着亚太地区近年来经济的迅速发展,亚太地区的用户组社区领导人峰会也日益重要。基于此次大会的分享和领导人们的建议,未来甲骨文会继续积极开发,加大资源共享力度,为开发者带来更多与时俱进并且紧跟当地市场的产品。同时,我们也对甲骨文用户组领导层的辛勤努力表示感谢,并期待更多的用户可以加入我们的社区。”
  • SHOUG主席刘相兵表示,能与亚太地区包括泰国、日本、斯里兰卡、印度的Oracle用户组管理者齐聚一堂,共同探讨Oracle 用户组OUG组织的发展前景与Oracle公司的技术发展则不枉此行。

支持性资源

 

PRM-DUL ORACLE 数据恢复软件总贴

PRM-DUL ORACLE 数据恢复软件总贴PRM-DUL 是一个基于JAVA语言编写的DUL类软件,其引入了图形化界面GUI和DataBridge特性。 全程GUI使得用户无需大量时间去学习命令行操作,直接可操作PRM-DUL从受损的ORACLE数据库中抽取数据。 DataBridge特性让抽取到的受损数据库的数据可以直接导入到目标库中,像DBLINK一样简单,而不需要使用sqlldr 或者 exp/imp来操作。PRM-DUL目前有2个版本:
社区版:
在完全免费的社区版中,数据抽取和数据搭桥的行数限制是一万行。ASM文件克隆功能在社区版中全面可用。企业版:
购买企业版意味在一套数据库(一个license对应一套数据库)内完全使用PRM的所有功能,没有任何限制

购买PRM-DUL,请联系我们:

国内热线号码: 400-690-3643      备用电话:18501767907
ORACLE技术专家服务邮箱: service@parnassusdata.com

PRM-DUL 最新版本 3206下载地址:
http://parnassusdata.com/sites/d … MForOracle_3206.zip

PRM-DUL 中文版用户手册:
http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database用户手册%20v0.3.pdf

PRM-DUL For Oracle Database中文介绍:

http://www.parnassusdata.com/sites/default/files/PRM%20–%20PARNASSUSDATA%20RECOVERY%20MANAGER%20For%20Oracle%20Database介绍手册.pdf

PRM-DUL FOr Oracle Database 英文版使用手册:
http://www.askmaclean.com/archiv … ser-guide-v0-3.html

PRM-DUL成功案例:

 

PRM ORACLE数据恢复视频教学:

 

PRM拯救损坏的oracle asm diskgroup数据恢复 http://v.youku.com/v_show/id_XNzgwMzY5OTIw.html
prm DUL for oracle恢复被truncate截断掉的表 http://v.youku.com/v_show/id_XNzU0NTQ1ODE2.html
Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复 http://v.youku.com/v_show/id_XNzMwMTc2Njg4.html
如何在Oracle中恢复被truncate截断掉而无备份的数据表   http://v.youku.com/v_show/id_XNzIzMzU4OTgw.html
PRM网络发布会    http://v.youku.com/v_show/id_XNjkzMDc3MDQ4.html

w58w4-prm-dul-for-oracle

ORACLE数据字典受损导致数据库无法打开的恢复 PRM-DUL

D 公司的DBA由于误操作删除了TS$数据字典基表导致数据库无法启动

 

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

 

 

INSTANCE_NAME

—————-

ASMME

 

SQL>

SQL>

SQL> select count(*) from sys.ts$;

 

COUNT(*)

———-

5

 

SQL> delete ts$;

 

5 rows deleted.

 

SQL> commit;

 

Commit complete.

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

 

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-01405: fetched column value is NULL

Process ID: 5270

Session ID: 10 Serial number: 3

 

Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds)

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Error 1405 happened during db open, shutting down database

USER (ospid: 5270): terminating the instance due to error 1405

Instance terminated by USER, pid = 5270

ORA-1092 signalled during: ALTER DATABASE OPEN…

opiodr aborting process unknown ospid (5270) as a result of ORA-1092

 

 

 

此场景中由于数据字典已经损坏,所以想要正常打开数据库是十分困难的。

 

此时则可以使用PRM来抽取数据库中的数据。具体步骤与场景1中的相似,用户仅仅需要输入该数据库的所有数据文件即可,其简要步骤如下:

 

 

  1. Recovery Wizard
  2. 选择字典模式 Dictionary Mode
  3. 合理选择Big或者Little Endian
  4. 加入数据文件并点击Load
  5. 根据实际需求恢复表中的数据

 

 

prm-dul-corrupted-dictionary-systemdbf

 

 

误删除/丢失/损坏的SYSTEM表空间且无备份情况下的Oracle数据恢复 PRM-DUL

D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件,这导致数据库完全无法打开,数据无法取出。 在没有备份的情况下,可以使用PRM恢复接近100%的数据。

 

此场景中启动PRM后,进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:

 

prm-dul-non-system01-dbf-1 prm-dul-non-system01-dbf-2

 

 

No-dictionary模式下需要用户指定 字符集和国家字符集,这是因为丢失了SYSTEM表空间后,数据库的字符集信息无法正常获得,所以需要用户的输入。 只有输入正确的字符集设置以及安装了必要的语言包才能保证No-Dictionary模式下正常抽取多国语言。

 

 

与场景演示1类似,输入用户目前可得的所有数据文件(不包括临时文件),并设置正确的Block Size和OFFSET:

 

prm-dul-non-system01-dbf-3

 

之后点击SCAN,SCAN的作用是扫描所有数据文件上的Segment Header,并记录到SEG$.DAT和EXT$.DAT中;在ORACLE中一个非分区表或者一个分区表的分区都对应着一个SEGMENT HEADER数据段头,只要能找到SEGMENT HEADER就可以获得整个表数据段的盘区EXTENT MAP 信息,通过EXTENT MAP可以获得该表上的全部记录。

 

通常存在这样一种情况,例如一张非分区的单表存放在某个由2个数据文件组成的表空间上,其SEGMENT HEADER以及一半的数据存放在A数据文件上,另一半数据存放在B数据文件上。但是由于某些原因,SYSTEM表空间和存放有SEGMENT HEADER的A数据文件均丢失了,只剩下B数据文件了,此时若希望仅仅恢复B数据文件上该表的数据,则不能依赖于SEGMENT HEADER,而只能依赖于从B数据文件上扫描盘区图EXTENT MAP信息了。

 

为了同时满足 基于SEGMENT HEADER和EXTENT MAP数据的NO-Dictionary模式恢复需要,所以SCAN操作在这里会填充SEG$.DAT和EXT$.DAT2个文件(文本文件仅仅为了便于诊断,所有程序实际依赖于PRM自带嵌入数据库DERBY的数据),并记录到DERBY数据库中。

 

prm-dul-non-system01-dbf-4 prm-dul-non-system01-dbf-5

 

完成SCAN 后,主界面左侧出现数据库图标。

 

此时可以选择2种模式:

 

  • Scan Tables From Segments,此模式适用于
    • 丢失了SYSTEM表空间,但是所有的应用数据表空间均存在
  • Scan Tables From Extents
    • 不适用于Dictionary模式的Truncate表数据恢复
    • 丢失了SYSTEM表空间,而且丢失了SEGMENT HEADER所在数据文件

 

通俗地说 除非你无法使用场景2中的方式来恢复已经TRUNCATE掉的数据,否则总是优先使用Scan Tables From Segments模式,如果发现Scan Tables From Segments下找不到你要的数据,再考虑使用Scan Tables From Extents模式。

 

 

我们优先采用Scan Tables From Segments模式

 

prm-dul-non-system01-dbf-6

 

 

Scan Tables From Segments完成后可以点开主界面左边的树形图:

 

prm-dul-non-system01-dbf-7

 

 

 

Scan Tables操作基于SEG$中的SEGMENT HEADER信息来构建数据表信息,树形图上每一个节点表示一个数据表段,其名字为obj+ 数据段上记录的DATA OBJECT ID 。

 

点中一个节点 并观察主界面右侧边栏:

 

prm-dul-non-system01-dbf-8

 

 

 

智能字段型解析

 

 

由于丢失了SYSTEM表空间,故NO-Dictionary模式下缺乏数据表的结构信息,这些结构信息包括表上的字段名字和字段类型,而且在ORACLE中这些信息均只保存为字典信息,不会在数据表上存放。当用户只有应用表空间时,需要基于数据段上的ROW行数据来猜测每一个字段的类型,PRM采用先进JAVA类型预判技术,可以解析多达10来种主流数据类型;、

 

智能解析准确度超过90%,可以自动解决大部分场景。

 

 

右侧边栏 上部各字段的含义:

 

  • Col1 no 字段号
  • Seen Count: 取到的行数
  • MAX SIZE: 最大长度,单位为字节
  • PCT NULL: 采样到的NULL的比例
  • String Nice: 将该字段解析为字符串,并成功的比例
  • Number Nice: 将该字段解析为数字,并成功的比例
  • Date Nice: 将该字段解析为Date,并成功的比例
  • Timestamp Nice: 将该字段解析为Timestamp,并成功的比例
  • Timestamp with timezone Nice: 将该字段解析为Timestamp with timezone Nice,并成功的比例

 

 

示例数据分析Sample Data Analysis:

 

 

prm-dul-non-system01-dbf-9

 

 

 

该部分依据智能字段类型解析的结果来解析10条数据,并显示解析结果。通过示例数据可以帮助用户了解实际该数据段中存放数据的情况。

 

如果数据段上记录条数不足10条,则显示所有记录。

 

 

TRY TO ANALYZE UNKNOWN column type:

 

prm-dul-non-system01-dbf-10

 

 

该部分是对于智能字段类型分析不能100%确认的字段,尝试用各种字段类型来解析,并呈现给用户,以便用户自行判断其究竟是什么类型。

 

目前PRM还不支持的类型包括:

XDB.XDB$RAW_LIST_T、XMLTYPE、用户自定义类型等

 

 

Unload Statement:

 

这部分是PRM生成的UNLOAD语句,此生成的UNLOAD语句仅作为系统内部使用和PRM开发团队以及ParnassusData原厂支持工程师使用。

 

prm-dul-non-system01-dbf-11

 

在此《Non-Dictionary Mode》非字典模式下同样可以采用常规和数据搭桥模式,与字典模式相比,主要的区别在于在非字典模式下数据搭桥时用户可以自行执行字段的类型,如下图中中部分字段类型为UNKNOWN,即未知的。这些字段可能是PRM目前还不支持的例如XML字段,也可能是PRM的智能解析没有顺利分析器类型。

 

如果用户知道这张表设计时的结构(也可以来源于应用开发商的文档),那么可以自行去填选正确的Column Type类型,以便PRM顺利将该表数据搭桥到目标数据库。

 

prm-dul-non-system01-dbf-12

误删除了SYSTEM表空间和部分应用表空间数据文件的Oracle数据恢复 PRM-DUL

D公司的SA由于误操作将在线业务数据库的SYSTEM表空间上的数据文件,以及部分应用表空间数据文件意外删除了。

 

此场景中由于部分应用表空间数据文件被删除了,这其中可能包括含有数据表的SEGMENT HEADER的数据文件,所以使用Scan Tables From Segment Header可能不如使用Scan Tables From Extents来的合适。

 

其简要步骤如下:

 

  1. 进入Recovery Wizard ,选择No-Dictionary模,加入所有可用的数据文件,执行Scan Database
  2. 选中数据库,并右键Scan Tables From Extents
  3. 对于PRM主界面上生成的对象树形图中的数据进行分析和导出/数据搭桥
  4. 其余操作与恢复场景4中一样

 

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 在大数据市场独领风骚的格局。