行在路上

今天介绍下香港四大著名的远足径,排在第一位的肯定非麦理浩径莫属:

麥理浩徑英文MacLehose Trail)是香港最早啟用的一條長途遠足徑,於1979年10月26日啟用,以時任香港總督麥理浩命名、並且由其本人主持剪綵開幕。麥理浩徑是香港最長的遠足徑,全長100公里,共分10段。麥理浩徑共有200支標距柱,約每500米一支。它貫穿了西貢東西貢西馬鞍山獅子山金山城門大帽山大欖郊野公園,以屯門為終點。大部分的麥理浩徑都是依山勢而建。

 

各段路程

路段 路線 距離(公里) 需時(小時) 難度 可補給點
1 北潭涌浪茄 10.6 3 北潭涌停車場茶水亭/近起點的士多
2 浪茄北潭凹 13.5 5 ** 西灣士多/鹹田灣士多/大浪士多/赤徑士多
3 北潭凹企嶺下 10.2 4 *** 嶂上許林士多
4 企嶺下大老山 12.7 5 *** N/A
5 大老山大埔公路 10.6 3 ** 沙田坳獅子亭士多
6 大埔公路城門 4.6 1.5 N/A
7 城門鉛礦坳 6.2 2.5 ** N/A
8 鉛礦坳荃錦公路 9.7 4 ** 大帽山扶輪公園茶水亭
9 荃錦公路田夫仔 6.3 2.5 N/A
10 田夫仔屯門 15.5 5 田夫仔士多
  1. 北潭涌開始,沿著西貢萬宜路繞過萬宜水庫南邊,經過萬宜水庫的西壩和東壩,最後到達浪茄沙灘。
  2. 西貢東郊野公園的北半部,沿郊野公園的邊界而行,跨過高314公尺的西灣山,下吹筒坳西灣,經鹹田灣,過大浪村西走,經赤徑北潭凹為終點。
  3. 此段從北潭凹開始,上300公尺的嶂上,然後向西南走,經過雞公山雷打石,下抵企嶺下通往西貢的公路。
  4. 此段跨過馬鞍山郊野公園:穿過黃竹洋村,向北攀上,至馬鞍山群山,抵昂平高地,西行至位於飛鵝山道的基維爾童軍營
  5. 此段是麥理浩徑最近市區的部分,比大部分段落的海拔為低。由大老山起,西行山脊至沙田坳,再到達495米的獅子山的北面,經458米的畢架山大埔公路
  6. 這是麥理浩徑中最短的一段,僅4.6公里,沿路為本地獮猴最密集聚居地。
  7. 這是麥理浩徑的次短段落。由城門水塘針山草山,再下行至鉛礦凹
  8. 這段跨越香港最高的大帽山。由鉛礦凹向西攀登山脊,伸至大帽山。經過大帽山山頂的石路, 下達到荃錦公路
  9. 荃錦坳起步,一直緩緩下降,以距離大欖涌水塘2公里的田夫仔為終點。
  10. 這是麥理浩徑最長段落。沿大欖涌水塘北面行至西面引水道,沿此向下步至屯門目的地。由2009年10月1日起,部份路段將作永久改道。過了M174及大欖涌水塘紀念碑後,將不再經大欖涌水塘塘畔的小路,而改為繼續沿馬路前行,於一岔口左轉,經過伯公坳後,進入山路大約向西南方走,然後接上通往黃泥墩水塘的車路,下行至M186左右,接回舊路。

難度:

  • * – 易行之路程
  • ** – 難行之路程
  • *** – 極費力及難行之路程

详细地图参考:

麦理浩径全程地图

Posted in hiking | 2 Comments

Oracle Database 11gR2性能调整与优化

终于,在2013年的最后一天拿到了清华出版社寄来的这本耗费了我们三人一年多时间的新书–《Oracle Database 11gR2性能调整与优化》!IMG_20131231_124510

第一次抚着印着自己名字的新书,心情还是十分激动滴!过去500多天的日日夜夜,基本上所有的课余时间都花费在上面了。从初稿开始,审阅,翻译团队内部讨论,出版社初审,复审,终审,每个章节都凝结了无数个不眠之夜。

读懂一本英文原著不难,把它译出来并让人看的懂,看的明白就不是那么简单一回事了。通过翻译这本书,我更加深深的体会到了这一点。况且这还是一本技术专著,在翻译的过程中,本身我也是读者,也对很多内容是一些再学习的过程。所以书中难免有一些错漏,也欢迎大家通过这个反馈页面反馈给我们,谢谢!

在翻译的过程中,我得到了老板Steven的无数帮助和支持,很多技术的细节和文字都是他帮忙润色(其实他本人也是译者之一)。翻译团队的另外一位Steven也是一位技术专家,他来自Oracle Real World Performance团队。感谢两位团队成员的支持和帮助!清华出版社的王军编辑在本书的出版过程中也付出了辛勤的汗水和努力,我们的合作很愉快,谢谢!

本书的原作者Rich也是一位非常nice的人,虽然是世界级的大师,但是人完全没有架子。在上海OOW期间,与他的三天近距离接触更让我感受到了大师的风范。

许多朋友也在翻译过程中提供了他们的专业的并富有建设性的意见:我的大学同学高洪霞,同事小荷和Jarod,伟林,南哥,菲哥等等,恕我不能一一罗列他们的姓名……

这一年多的时间里,还有在背后默默支持我的家庭。我的任劳任怨的妻子,七岁的儿子,还有我慈爱的父母,感谢你们!!没有你们的理解和支持,就不会有这本书的出版。

 

Posted in 数据库 | Tagged , | Leave a comment

Exadata 备份恢复最佳实践

Exadata的备份恢复跟普通单机或者RAC数据库的备份恢复基本面是一样的,但是针对多节点还是有一些优化的最佳实践。今天就简单谈谈针对Exadata的备份和恢复。

为充分利用Exadata的I/O能力和多节点的优势,建议先在每个DB节点上分配2个通道进行测试。另外,为了让所有的DB节点都能参与到备份任务中,可以在每个节点建立一个failover类型的service。下面是一个实际的测试配置和脚本,仅供参考。

srvctl add service –d df –s bkup1 –r df1 –a df2 ,df3 ,df4
srvctl add service –d df –s bkup2 –r df2 –a df1 ,df3 ,df4
srvctl add service –d df –s bkup3 –r df3 –a df1 ,df2 ,df4
srvctl add service –d df –s bkup4 –r df4 –a df1 ,df2 ,df3

srvctl start service -d df

export ORACLE_HOME
export NLS_DATE_FORMAT=”YYYY/MM/DD HH24:MI:SS”
begin_time_sec=`date +%s`

set echo on
run
{
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 8;

allocate channel ch01 device type disk connect ‘sys/welcome1@x3-scan/bkup1’;
allocate channel ch02 device type disk connect ‘sys/welcome1@x3-scan/bkup2’;
allocate channel ch03 device type disk connect ‘sys/welcome1@x3-scan/bkup3’;
allocate channel ch04 device type disk connect ‘sys/welcome1@x3-scan/bkup4’;
allocate channel ch05 device type disk connect ‘sys/welcome1@x3-scan/bkup1’;
allocate channel ch06 device type disk connect ‘sys/welcome1@x3-scan/bkup2’;
allocate channel ch07 device type disk connect ‘sys/welcome1@x3-scan/bkup3’;
allocate channel ch08 device type disk connect ‘sys/welcome1@x3-scan/bkup4’;
backup
as backupset
incremental level 0
section size 128g
database;
}
end_time_sec=`date +%s`

total_execution_time_sec=`expr ${end_time_sec} – ${begin_time_sec}`

echo “Script execution time is $total_execution_time_secseconds”

下图是一个官方数据的截图,原文可以参考白皮书

exadatabackup

从上图可以看到,在11203的版本下,满配的X2-2(X3-2),磁盘的备份速度可以达到每小时20-25TB。在11202版本下,可以达到每小时17-18TB。

针对恢复,同理,下面是一段参考脚本:
此示例是在1/8配置的环境下进行的测试,使用了16个channel,针对每个node建了一个service。注意此处是针对表空间而非全库的恢复,稍加修改可以进行全库的恢复。

run
{

allocate channel ch01 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch02 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch03 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch04 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch05 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch06 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch07 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch08 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch09 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch010 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch011 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch012 device type disk connect ‘sys/oracle@bg1’;
allocate channel ch013 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch014 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch015 device type disk connect ‘sys/oracle@bg2’;
allocate channel ch016 device type disk connect ‘sys/oracle@bg2’;

sql ‘ALTER TABLESPACE eighth OFFLINE IMMEDIATE’;
restore tablespace eighth;
recover tablespace eighth;
sql ‘ALTER TABLESPACE eighth ONLINE’;

}

Posted in 数据库 | Tagged , | Leave a comment

Cache Fusion 剖析(一)

本系列文章翻译自网站:DataDisk.co.uk (原文链接

Cache Fusion 是RAC的核心,本系列文章意在帮助大家理解RAC的内部和运作机理,有些名词和概念在新版本的RAC中改变了名称或者很少提及,但是本质保持不变。
译文开始

我之前在GRD那一节提到过Cache Fusion, 这里我会介绍更多实现的细节。我也会给出一些我自己的RAC系统上的具体例子。

Cache Fusion尽可能使用最有效的通信方法以降低私有网络上的通信流量,现在管理RAC环境您已经不需要关心这么底层的细节了,当然了解这些有助于理解RAC的工作原理和调试问题。RAC看起来只有一个大的buffer但事实并非如此,每个节点上的buffer cache依然保持独立,数据块通过分布式锁和消息操作实现共享。RAC通过私有网络把数据块复制到别的实例,因为这比从磁盘读取要有效的多,没错,内存和网络协同工作比磁盘I/O更快。

数据块从一个实例的buffer cache传输到另外一个实例的buffer cache被称之为ping。正如较早前提到的那样,当一个实例需要一个数据块,它会发送请求到锁的master实例要求以希望的锁方式访问此块,这个过程叫做BAST。当实例收到BAST消息之后,它就会尽快的把持有的锁降级,但此时实例或许要将对应的数据块写回磁盘,这个操作叫做Disk ping或者hard ping。在最近的RAC版本中,Disk Ping已经被大大降低,然后总还是有少量的Disk Ping发生,因而更加依赖于实例间的数据块传输。在最新版本的RAC中,当实例收到BAST后,发出数据块或者把锁降级可能被延迟几十毫秒,这点额外的时间使得持有锁的实例可以完成当前活动的事务并妥善标记数据块的头。这样接受的实例就不用在接受/读取数据块之后立刻去检查事务的状态。检查事务状态是一个耗时的操作,因为可能需要访问(或者ping)相应的回滚段头和回滚段数据块。参数_gc_defer_time用来定义实例延迟降级锁的时长。

在GRD那一节我提到了PI(过去映像),简单来说他们就是存在于实例本地buffer cache中的数据块的副本。当一个实例需要发送一个刚刚修改过的数据块给别的实例时,它就会保留那个数据块的一个副本,标记为PI。PI一直被保留直到那个数据块被当前的所有者写回磁盘。当一个数据块被写回磁盘且此数据块有一个全局角色,也就是说此数据块有PI存在于其他实例的buffer cache。GCS就会通知持有这些PI的实例丢弃这些PI。当需要做检查点时,就会通知GCS要做写的动作,GCS负责找到最新的数据块映像并通知持有这些映像的实例执行数据块写操作。GCS然后通知所有全局资源的持有者他们可以释放包含PI副本数据块的缓存,从而允许释放全局资源。可以通过表X$BH查看过去映像的数据块。

select state, count(state) from X$BH group by state;

Note: the state column with 8 is the past images.

< 未完待续>

Posted in 数据库 | Tagged , | Leave a comment

Oracle Database 11.2.0.4 GA

继Oracle Database 12cR1 之后的又一个大的版本 Oracle Database 11.2.0.4.0 也就是11gR2的最后一个Patchset近日GA了。
其中当然包括了很多12cR1中的一些新特性,比如:

  • Backport of Oracle Data Redaction
  • Trace File Analyzer and Collector
  • RACcheck – The Oracle RAC Configuration Audit Tool
  • Database Replay Support for Database

等。详细的新特性可以去Note查看,另外这个Patchset的补丁号码是:
Patch 13390677: 11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER

文档页面也已经更新到了最新的版本。

详细的下载页面如下:
11204

目前可用的平台包括Linux64和Linux32,其他平台也会相继推出。

Posted in 生活点滴 | Tagged | Leave a comment

AIX PVID能不能用作ASM磁盘

好几次遇到这个问题,这次又遇到,就在这里总结一下,供大家参考。

在AIX系统中,给磁盘分配PVID以后,如果这些磁盘被用作Oracle ASM Diskgroup,那么当系统重启后可能导致ASM磁盘被破坏,数据丢失。导致这个问题的原因很简单:

When the PVID is set to a disk in a volume group, the PVID is stored in two locations. In Physical disk header ( within first 4K )and in AIX’s system object database, called ODM ( Object Data Manager ).

When the diskgroup is created, the disk header information of PVID is overwritten. However, with reboot the OS, from ODM, AIX might try to restore the PVID information onto the disk header,
there by destroying the ASM metadata.

解释过来就是:
磁盘组被创建的时候,磁盘中的PVID信息会被Oracle ASM作为磁盘头,也就是metadata重写掉。这对于Oracle ASM来说,是一贯的动作,对于所有加入磁盘组的磁盘都是同等对待的。问题出在重启以后,AIX的ODM会试图去检测并恢复磁盘头上的PVID信息。这样就导致磁盘头上重要的ASM metadata信息丢失,ASM中的数据丢失。

问题的解决方法在Oracle Notes750016.1中有详细描述。
Corrective Action for ASM Diskgroup with Disks Having PVIDs on AIX (Doc ID 750016.1)

If the ASM disk header Metadata has not been over written by PVID from ODM ( before a reboot ), then you can follow the following steps to update the ODM not to have PVID for the disks:

1] Do not reboot any node.

1.1] Drop one disk at a time from the diskgroup.

1.2] Clear the PVID of the dropped disk

# chdev -l hdisk5 -a pv=clear

Run this on ALL the nodes in case of RAC.

1.3] Check the disk does not have the PVID from ALL the nodes

# lspv

1.4] Add the disk back to the diskgroup

1.5] Do this for all the disks having PVID in the diskgroup, one by one. Take care that the rebalance is complete from the drop/add disk command before going for the next disk.

OR

2] This needs downtime:

2.1] Take ‘dd’ backup of the disk headers

# dd if=/dev/hdisk5 of=/tmp/d5.txt bs=1024 count=1024

2.2] Shutdown ASM instance ( on ALL the nodes in RAC setup ).

2.3] Clear the PVID

# chdev -l hdisk5 -a pv=clear

Run this on ALL the nodes in case of RAC.

2.4] Check the disk does not have the PVID from ALL the nodes

# lspv

2.5] Start the ASM Instance(s) and mount the diskgroup on ALL the nodes

WARNING:
Point-2 commands overrides the content of the disk header and so could be destructive if not correctly used. If you have any doubt, raise an SR with Oracle Support before any action.

Posted in 数据库 | Tagged | Leave a comment

Oracle RDBMS Database patchset summary

Oracle 12c昨天终于GA了,随着今年10.2,明年11.1的支持周期告一段落,我们也将经迎来一个升级的高发期,方便找到合适的版本,转贴一个MOS note,全面介绍了Oracle RDBMS Database Patchset number:

 

<code>
Patchset/PSU	Patch Number	 	Description

11.2.0.3.6	16056266	 	DATABASE PATCH SET UPDATE 11.2.0.3.6 (INCLUDES CPUAPR2013) 
11.2.0.3.5	14727310	 	DATABASE PATCH SET UPDATE 11.2.0.3.5 (INCLUDES CPUJAN2013):
11.2.0.3.4	14275605	 	DATABASE PATCH SET UPDATE 11.2.0.3.4 (INCLUDES CPUOCT2012)
11.2.0.3.3	13923374	 	DATABASE PATCH SET UPDATE 11.2.0.3.3 (INCLUDES CPU JUL2012):
11.2.0.3.2	13696216	 	DATABASE PATCH SET UPDATE 11.2.0.3.2 (INCLUDES CPU APR2012)
11.2.0.3.1	13343438	 	DATABASE PATCH SET UPDATE 11.2.0.3.1 (INCLUDES CPU JAN2012)
11.2.0.3	10404530	 	11.2.0.3.0 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
11.2.0.2.10	16056267	 	DATABASE PATCH SET UPDATE 11.2.0.2.10 (INCLUDES CPUAPR2013) 
11.2.0.2.9	14727315	 	DATABASE PATCH SET UPDATE 11.2.0.2.9 (INCLUDES CPUJAN2013):
11.2.0.2.8	14275621	 	DATABASE PATCH SET UPDATE 11.2.0.2.8 (INCLUDES CPUOCT2012)
11.2.0.2.7	13923804	 	DATABASE PATCH SET UPDATE 11.2.0.2.7 (INCLUDES CPU JUL2012)
11.2.0.2.6	13696224	 	DATABASE PATCH SET UPDATE 11.2.0.2.6 (INCLUDES CPU APR2012)
11.2.0.2.5	13343424	 	DATABASE PATCH SET UPDATE 11.2.0.2.5 (INCLUDES CPU JAN2012)
11.2.0.2.4	12827726	 	DATABASE PSU 11.2.0.2.4 (INCLUDES CPUOCT2011)
11.2.0.2.3	12419331	 	DATABASE PSU 11.2.0.2.3 (INCLUDES CPUJUL2011)
11.2.0.2.2	11724916	 	DATABASE PSU 11.2.0.2.2 (INCLUDES CPUAPR2011)
11.2.0.2.1	10248523	 	DATABASE PSU 11.2.0.2.1
11.2.0.2	10098816	 	11.2.0.2.0 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
11.2.0.1.6	12419378	 	 DATABASE PSU 11.2.0.1.6 (INCLUDES CPUJUL2011)
11.2.0.1.5	11724930	 	DATABASE PSU 11.2.0.1.5 (INCLUDES CPUAPR2011)
11.2.0.1.4	10248516	 	DATABASE PSU 11.2.0.1.4 (INCLUDES CPUJAN2011)
11.2.0.1.3	9952216	 	DATABASE PSU 11.2.0.1.3 (INCLUDES CPUOCT2010)
11.2.0.1.2	9654983	 	DATABASE PSU 11.2.0.1.2 (INCLUDES CPUJUL2010)
11.2.0.1.1	9352237	 	DATABASE PSU 11.2.0.1.1
 	 	 	 
11.1.0.7.15	16056268  [*]	 	DATABASE PATCH SET UPDATE 11.1.0.7.15 (INCLUDES CPUAPR2013) 
11.1.0.7.14	14739378 [*]	 	DATABASE PATCH SET UPDATE 11.1.0.7.14 (INCLUDES CPUJAN2013)
11.1.0.7.13	14275623 [*]	 	DATABASE PATCH SET UPDATE 11.1.0.7.13 (INCLUDES CPUOCT2012)
11.1.0.7.12	13923474	 	DATABASE PATCH SET UPDATE 11.1.0.7.12 (INCLUDES CPU JUL2012)
11.1.0.7.11	13621679	 	DATABASE PATCH SET UPDATE 11.1.0.7.11 (INCLUDES CPU APR2012)
11.1.0.7.10	13343461	 	DATABASE PATCH SET UPDATE 11.1.0.7.10 (INCLUDES CPU JAN2012)
11.1.0.7.9	12827740	 	DATABASE PSU 11.1.0.7.9 (INCLUDES CPUOCT2011)
11.1.0.7.8	12419384	 	DATABASE PSU 11.1.0.7.8 (INCLUDES CPUJUL2011)
11.1.0.7.7	11724936	 	DATABASE PSU 11.1.0.7.7 (INCLUDES CPUAPR2011)
11.1.0.7.6	10248531	 	DATABASE PSU 11.1.0.7.6 (INCLUDES CPUJAN2011)
11.1.0.7.5	9952228	 	DATABASE PSU 11.1.0.7.5 (INCLUDES CPUOCT2010)
11.1.0.7.4	9654987	 	DATABASE PSU 11.1.0.7.4 (INCLUDES CPUJUL2010)
11.1.0.7.3	9352179	 	DATABASE PSU 11.1.0.7.3 (INCLUDES CPUAPR2010)
11.1.0.7.2	9209238	 	DATABASE PSU 11.1.0.7.2 (INCLUDES CPUJAN2010)
11.1.0.7.1	8833297	 	DATABASE PSU 11.1.0.7.1 (INCLUDES CPUOCT2009)
11.1.0.7	6890831	 	11.1.0.7.0 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
10.2.0.5.11	16056270  [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.11 (INCLUDES CPUAPR2013)
10.2.0.5.10	14727319 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.10 (INCLUDES CPUJAN2013):
10.2.0.5.9	14275629 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.9 (INCLUDES CPUOCT2012)
10.2.0.5.8	13923855 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.8 (INCLUDES CPU JUL2012)
10.2.0.5.7	13632743 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.7 (INCLUDES CPU APR2012)
10.2.0.5.6	13343471 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.5.6 (INCLUDES CPU JAN2012)
10.2.0.5.5	12827745 [*]	 	DATABASE PSU 10.2.0.5.5 (INCLUDES CPUOCT2011)
10.2.0.5.4	12419392	 	DATABASE PSU 10.2.0.5.4 (INCLUDES CPUJUL2011)
10.2.0.5.3	11724962	 	DATABASE PSU 10.2.0.5.3 (INCLUDES CPUAPR2011)
10.2.0.5.2	10248542	 	DATABASE PSU 10.2.0.5.2 (INCLUDES CPUJAN2011)
10.2.0.5.1	9952230	 	DATABASE PSU 10.2.0.5.1 (INCLUDES CPUOCT2010)
10.2.0.5	8202632	 	10.2.0.5.0 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
10.2.0.4.16	16056269 [*]	 	DATABASE PSU 10.2.0.4.16 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUAPR2013)
10.2.0.4.15	14736542 [*]	 	DATABASE PSU 10.2.0.4.15 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUJAN2013):
10.2.0.4.14	14275630 [**]	 	DATABASE PSU 10.2.0.4.14 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUOCT2012)
0.2.0.4.13	13923851 [*]	 	DATABASE PSU 10.2.0.4.13 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUJUL2012)
10.2.0.4.12	12879933 [*]	 	
DATABASE PSU 10.2.0.4.12 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUAPR2012)
10.2.0.4.11	12879929 [*]	 	DATABASE PATCH SET UPDATE 10.2.0.4.11 (PRE-REQ 10.2.0.4.4 | INCLUDES CPUJAN2012)
10.2.0.4.10	12827778	 	DATABASE PSU 10.2.0.4.10 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUOCT2011)
10.2.0.4.9	12419397	 	DATABASE PSU 10.2.0.4.9 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUJUL2011)
10.2.0.4.8	11724977	 	DATABASE PSU 10.2.0.4.8 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUAPR2011)
10.2.0.4.7	10248636	 	DATABASE PSU 10.2.0.4.7 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUJAN2011)
10.2.0.4.6	9952234	 	DATABASE PSU 10.2.0.4.6 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUOCT2010) 
10.2.0.4.5	9654991	 	DATABASE PSU 10.2.0.4.5 (REQUIRES PRE-REQUISITE 10.2.0.4.4 | INCLUDES CPUJUL2010)    [overlay PSU]
10.2.0.4.4	9352164	 	DATABASE PSU 10.2.0.4.4 (INCLUDES CPUAPR2010)
10.2.0.4.3	9119284	 	DATABASE PSU 10.2.0.4.3 (INCLUDES CPUJAN2010)
10.2.0.4.2	8833280	 	DATABASE PSU 10.2.0.4.2 (INCLUDES CPUOCT2009)
10.2.0.4.1	8576156	 	DATABASE PSU 10.2.0.4.1 (INCLUDES CPUJUL2009)
10.2.0.4	6810189	 	10.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER
10.2.0.3	5337014	 	10.2.0.3 PATCH SET FOR ORACLE DATABASE SERVER
10.2.0.2	4547817	 	10.2.0.2 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
10.1.0.5	4505133	 	10.1.0.5 PATCH SET FOR ORACLE DATABASE SERVER
10.1.0.4	4163362	 	10.1.0.4 PATCH SET FOR ORACLE DATABASE SERVER
10.1.0.3	3761843	 	10.1.0.3 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
9.2.0.8	4547809	 	9.2.0.8 PATCH SET FOR ORACLE DATABASE SERVER
9.2.0.7	4163445	 	9.2.0.7 PATCH SET FOR ORACLE DATABASE SERVER
9.2.0.6	3948480	 	9.2.0.6 PATCH SET FOR ORACLE DATABASE SERVER
9.2.0.5	3501955	 	ORACLE 9I DATABASE SERVER RELEASE 2 - PATCH SET 4 VERSION 9.2.0.5.0
9.2.0.4	3095277	 	9.2.0.4 PATCH SET FOR ORACLE DATABASE SERVER
9.2.0.3	2761332	 	9.2.0.3 PATCH SET FOR ORACLE DATABASE SERVER
9.2.0.2	2632931	 	9.2.0.2 PATCH SET FOR ORACLE DATABASE SERVER
 	 	 	 
9.0.1.5	3301544	 	9.0.1.5 PATCHSET
9.0.1.4	2517300	 	9.0.1.4 PATCH SET FOR ORACLE DATABASE SERVER
9.0.1.3	2271678	 	9.0.1.3. PATCH SET FOR ORACLE DATA SERVER
 	 	 	 
8.1.7.4	2376472	 	8.1.7.4 PATCH SET FOR ORACLE DATA SERVER
8.1.7.3	2189751	 	8.1.7.3 PATCH SET FOR ORACLE DATA SERVER
8.1.7.2	1909158	 	8.1.7.2.1 PATCH SET FOR ORACLE DATA SERVER

NOTE:

[*]   10.2.0.4 and 10.2.0.5 are now in extended support mode and PSU's released after Aug 01,2011 will need ES License to download them.

[**] Available only in limited platforms

Posted in 数据库 | Leave a comment

Flashback Database

在Flashback Database中创建基于guarantee的restore point,是可以进行快速备份和恢复的方法。这对于RAT中的播放之后的数据库恢复特别有用!

下面的notes详细描述了创建和恢复restore的过程:

Restore point: 

Restore point is nothing but a name associated with a timestamp or an SCN of the database. One can create either a normal restore point or a guaranteed restore point. The difference between the two is that guaranteed restore point allows you to flashback to the restore point regardless of the DB_FLASHBACK_RETENTION_TARGET initialization parameter i.e. it is always available (assuming you have enough space in the flash recovery area).

NOTE: In this article Flashback logging was not turned ON.

Guaranteed Restore point:

Prerequisites: Creating a guaranteed restore point requires the following prerequisites:

The user must have the SYSDBA system privileges
Must have created a flash recovery area
The database must be in ARCHIVELOG mode
Create a guaranteed restore point:
After you have created or migrated a fresh database, first thing to do is to create a guaranteed restore point so you can flashback to it each time before you start a new workload. The steps are as under:

$> su – oracle
$> sqlplus / as sysdba;

Find out if ARCHIVELOG is enabled

SQL> select log_mode from v$database;

If step 3 shows that ARCHIVELOG is not enabled then continue else skip to step 8 below.

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> create restore point CLEAN_DB guarantee flashback database;

where CLEAN_DB is the name given to the guaranteed restore point.
Viewing the guaranteed restore point

SQL> select * from v$restore_point;

Verify the information about the newly created restore point. Also, note down the SCN# for reference and we will refer to it as “reference SCN#”

Flashback to the guaranteed restore point
Now, in order to restore your database to the guaranteed restore point, follow the steps below:

$> su – oracle
$> sqlplus / as sysdba;
SQL> select current_scn from v$database;
SQL> shutdown immediate;
SQL> startup mount;
SQL> select * from v$restore_point;
SQL> flashback database to restore point CLEAN_DB;
SQL> alter database open resetlogs;
SQL> select current_scn from v$database;

Compare the SCN# from step 9 above to the reference SCN#.

NOTE: The SCN# from step 9 above may not necessarily be the exact SCN# as the reference SCN# but it will be close enough.

 

Posted in 生活点滴 | Tagged | Leave a comment