本站推荐: DBA警世录:备份重于一切
Today | 02/06 | 02/05 | 02/04 | 02/03 | 02/02 | 02/01 | 01/31 | 01/30 | 01/29 | 01/28
 123
 123

  2010-02-07 Sun

21:56 backupset和backuppiece的区别 (38998 Bytes) » Focus on Oracle

朋友itpub上问backupsetbackuppiece的区别,我很能理解这位朋友为什么会有这样的疑问,因为我在六年前看9i OCP的培训教材的时候也不明白这两者之间的区别是什么。

 

我们只需要做如下这样一些测试并配合list backup就可以知道backupsetbackuppiece的区别了:

1、多个channel并且指定filesperset

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database

filesperset 3;

}

 

2、单个channel且不指定filesperset

configure device type disk parallelism 1;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

}

 

3、单个channel且指定maxsetsize

configure device type disk parallelism 1;

configure maxsetsize to 450M;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

}

 

4、单个channel且指定maxpiecesize

configure device type disk parallelism 1;

configure maxsetsize to unlimited;

run{

allocate channel c1 device type disk maxpiecesize 300M;

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

release channel c1;

}

 

5、多个channel且指定filesperset,但请注意filesperset的位置:

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database

plus archivelog

format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'

delete all input

filesperset 2;

}

 

6:多个channel且指定filesperset,但请注意filesperset的位置:

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database filesperset 2

plus archivelog

format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'

delete all input;

}

 

从结果里我们可以得到如下结论:

1、  backupsetbackuppiece组成,每一个backuppiece就是一个单个的物理文件;

2、  如果你在分配channel的时候不指定maxpiecesize,则每个backupset只会包含一个backuppiece;反之一个backupset里会有多个backuppiece(即物理文件);

3、  一次备份中backupset的数量跟分配channel的个数、是否指定filespersetfilesperset的位置、是否指定maxsetsize有关。

 

filesperset的位置很关键,比如我这里有10datafile需要备份,那么上述测试5对这10datafile(不含archivelog)会产生多少个backupset?测试6呢?

 

答案是测试5产生了3backupset,测试6产生了6backupset这里请正确理解filesperset 的含义)。

 

10:21 “思考方式”带来的变革 (5707 Bytes) » 人生就是如此

一直以来隐约感觉到其实人和人先天差距对后来成长到什么程度影响没那么大,大多数人都是可以通过后天来成长的。但如果没有外在很好的推力(环境的逼迫、良师诱导等),要靠自身来实现的话,那我们该怎么办?

今天早上躺床上再次回顾我以前曾经想过的的思维方式与技术成长的问题,决定将思维方式更改为思考方式,在技术与人两方面尝试解释这件事情。

 

关于技术

        其实我自己在成长过程中可以说是没有良师的,几乎都是靠自己摸索,对于我自己来说,最大的收获是来自于对问题的思考方式。比如我学习数据库、操作系统、存储知识这些东西的时候,拿oracle数据库举例,第一步是先搞清楚当前数据库的基本的东西,然后思考为什么会是当前这个样子,我们感觉不爽希望改变的功能为什么没实现?是因为什么使得oracle公司开发设计人员没这么做?是技术问题还是客户需求不那么多的? 假如我自己来设计该如何平衡? 不断地琢磨这些问题之后,当新的版本出来,看见一堆new feature ,我就能感受到 oracle 这个数据库为什么能实现这些feature,实现这些feature背后的技术基础是什么,有些功能实现的不够理想,障碍是什么,这些自己就能感受到。 所以 将一个产品背后庞大的逻辑在两三年时间里面能理的比较清楚,这样我就不需要花费大量的时间去阅读文档,只需要在我拿捏不准的地方认真咀嚼文档,做实验来对我的推测的关键部分 证实或者证伪。 所以事实上我是没看过多少oracle 的文档或者书籍的,都是有针对性的看了其中部分。 我这种方式跟很多人成体系的去阅读书籍是不一样的,因为我们没到那个高度的时候去阅读,要消化难度是非常之大的。 而我这种方式所获得的知识,是可以通过逻辑推理建立起来的,脉络很清楚,所以到现在7年前我做的实验和所获得的知识,在我多年没接触之后我依然可以很清楚的表达出来。 因为在这种思考方式的背后我逐渐建立了自己的体系,所有的文档、书籍,别人的经验,都是被我这个体系所吸收。

        我的这种学习方式,或者思考方式,我相信在我跟张瑞几年共同工作中是对他产生了很大的影响的,所以他来公司的时候基础几乎是最薄弱的。但经过3年左右的锻炼之后,他已经有了自己的思考方式去学习,最近2年更是突飞猛进。不熟悉的人看看他的个人blog 的技术文章就知道了(www.hellodba.net) 。 当然我也希望张瑞能对我这个关于思考方式的探索给予回应,我们共同来探讨成长过程中走过的路,给他人与参考。更重要的是我们在学习和工作中,将这种方式能感同身受的传递给身边的人。

 

关于人

        这是一个比技术更困难的问题,拿我前几天写的一段文字 关于"我"的固见(http://bitirainy.spaces.live.com/blog/cns!6AECD20E2E08EE3A!1658.entry)来举例(接下来用 “固见” 代表这篇文章),尝试摸索我自己是如何的思考方式。 其实在工作中,关于 固见 一文描述的现象我们感受是蛮多的,但大多时候,我们可能只是感觉到与人打交道的困难,时间长了可能会气馁。 在最近一次的支付宝内部我和几位同事探讨一个技术方案的时候,我决定把这个现象总结下来。 我自己对这类问题的方式或者套路是这样的: 当我觉得很困难的时候,先换位思考,对方的困难到底在哪里? 想透这个问题,再来看我的坚持是否合理? 然后从情绪上,我自己换位之后会是什么表现? 由此推及在其他场合,我会做什么表现?  这背后的根源是什么? 我能否归纳起来。 最后我把这个问题归结为我们每个人的 固见 ,要突破必须从对自我的认识入手,再去改变。 这样通过一些现象,能主动由己及人的逐步思考,最后归纳出一些共性,再锤炼下自己结论,最后与大家分享出来,反过来指导自己的行为,达成言行的一致。

 

    这就是我自己在技术和人方面的一些学习的套路,自己不断地演练这些套路,最后成为一种自然的不需要刻意去引导的过程。通过自身的思考方式的改变给自己带来变革。把这个整理出来,与大家共同交流。也有不少人反馈给我说,我讲的很多东西其实在哪本书上有。但事实上是,这些书的确我没看过。那这引发我思考另一个问题,其实人类不同时代所处环境虽然不同,但对自己的体验和感受不断的思考,背后的认知方面其实是相同的。如果我们抛开体验过程中的具体事实而高度抽象为一句话,发现不是佛家讲过就是道家讲过。 越是有人给我讲在哪里看到过这个话,越是坚定了我对自己独立思考的信心,因为我在以自己的方式学习和成长,并且是不受时空和条件的限制。 当然,这是我个人的体验而已,每个人都应该寻找到适合自己的成长方式,但在思考方式上,我以为大家是可以用共同的套路去做的。

 

09:36 周六购物,下雪 (1042 Bytes) » Julia----瞬间与记忆在此过渡。。。。。。

周六下午盖老咪拉我去买衣服,逛了三小时,我们收获了十件衣服、五双鞋子,和两顶帽子。

很开心啊,今天买的所有东西我都很喜欢,觉得很幸福。

不过担心,其实黄咪已经有很多的鞋子和衣服,但穿的只有一对,就是那对黑色的耐克和羽绒。

我的不修边幅似乎已经无药可救,可是我又如此享受这种简单和慵懒。

我跟盖老咪说,你记得提醒我穿啊。盖老咪说,想起就穿好了。

和盖老咪一起,就有这种轻松自在,能不能说,我们就是天生一对?

我们满手拿着购物的袋子,出门才发现,地下已经铺好了雪,抬头凝望天空,夜色中白色的雪纷纷扬扬地落下。盖小菊在家已经下好饺子等我们回去过小年。天气很寒冷,开始咳嗽,可是,心里是温暖的。。。

盖老咪说,好像过圣诞啊。。。






02:02 熟人分类 (218 Bytes) » 我呸
“饭局通知”8周年纪念晚饭,
密密麻麻来鸟一吴藤斋滴人。

偶欣喜滴发现
一种
素偶8认识滴;
另一种
素偶8认识鸟。...
01:02 逻辑 (607 Bytes) » 我呸
贵家总电闸冒火
呼唤管理处

管理处:你家里的总电闸被烧了,需要更换一个。
偶:赶紧换啊。
管理处:一个要160元。
偶:换吧。
管理处:但我们现在没这种电闸。
偶:那就去买啊。
管理处:但我们电闸都是总公司统一批发购买的,但目前只有你一家被烧毁,我们无法进行批发。
偶:那现在我家没电怎么办?
管理处:你可以写申请,我们会交给总公司,14个工作日内可以答复你是否能购买。...
01:02 偶们工人有力量 (102 Bytes) » 我呸


 ...

  2010-02-06 Sat

21:16 关于“我”的固见 (2035 Bytes) » 人生就是如此
一种情况下,比如我现在有个项目经过充分考虑已经设计的差不多了,自己也论证了N次,比较满意。结果这个时候有人提出了新的要求,咋一看对现有方案甚至可能冲击比较大,于是我就会从各个角度“论证”新要求的不合理性以及不可完成性。但若我换了个态度,先不顾及自己已有的方案,由于已经经过多次分析,可以迅速在增加需求的基础上,重新设计一套方案,最后发现,重新设计出来的完整的方案跟原方案一对比,居然没有什么本质的差异,只需要一点点改动,或者一点点折中就能达成双赢。但通常情况我可能是在跟提出新需求的吵了半天要么以被强奸者的态度去改变,要么以胜利者的姿态坚持了自己的意见。 但这个时候“我”是赢了,公司却未必赢。
        说这个问题,不代表所有需求我们都要满足,也可能我重新“设计”了方案之后发现不可行,那也没关系,我想提需求的人也应该是能理性看待问题的,只要我们内心真的认真去“拥抱”了这个变化,大家最终能达成理解的。这也是加深我们之间信任的一种方式。
        那上面是一件比较具体的工作,还有一些思维方式或者行为方式的差异,“我”的固见会使得我在态度上就无法平静下来,更不会换位思考或者尝试一理解和包容的态度去思考双方的差异。这是我们人与人之间难以快速有效沟通和达成信任的巨大障碍
16:36 详解MyISAM Key Cache(后篇) (1584 Bytes) » DBA@Taobao
p { text-indent:28px; } 在前两篇(前篇、中篇)中,分别介绍了Key Cache的基本原理(LRU和Midpoint Insertion Strategy)。最后,将介绍一些相关的参数、状态参数和命令。 Key Cache的配置很灵活,可以针对全局配置,还可以针对某个单独数据表分配Key Cache的大小;如果一个数据表某部分的索引块被访问的非常频繁(较之其他索引块),那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。 1. 如何配置Key Cache的大小 #配置文件my.cnf key_buffer_size=50*1024*1024 另外,Key Cache的大小可以动态的改变 2. 给数据表划分单独的Key Cache 例如:划分一块128K的Key buffer空间,指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。 SET GLOBAL hot_cache.key_buffer_size=128*1024; CACHE INDEX t1 IN hot_cache; SET GLOBAL hot_cache.key_buffer_size=0; 3. 预先载入某些数据表的索引 LOAD INDEX INTO CACHE t1, t2 4. 关于Key Cache的使用情况观察 Flush现象 mysql> show status like "key%"; +------------------------+----------+ | Variable_name ...

16:36 详解MyISAM Key Cache(前篇) (2762 Bytes) » DBA@Taobao
p { text-indent:28px; } 本文将分为前、中、后三篇,分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。 “Cache为王”,无所不在。为了最小化磁盘I/O,MyISAM将最频繁访问的索引块(“index block”)都放在内存中,这样的内存缓冲区我们称之为Key Cache,它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中(MYI),连续的单元(contiguous unit)组成一个Block,Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。 1. MyISAM如何使用Key Cache 当MySQL请求(读或写)MyISAM索引文件中某个Index Block时,首先会看Key Cache队列中是否已经缓存了对应block。如果有,就直接在Key Cache队列中进行读写了,不再需要请求磁盘。如果是写请求,那么Key Cache中的对应Block就会被标记为Dirty(和磁盘不一致)。在MyISAM在Key Cache成功请求(读写)某个Block后,会将该Block放到Key Cache队列的头部。 如果Key Cache中没有待请求(读或写)的Block,MyISAM会向磁盘请求对应的Block,并将其放到Key Cache的队列头部。队列如果满了,会将队列尾部的Block删除,该Block如果是Dirty的,会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU(Least Recently Used)的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。 2. 图解 下图展示了访问Index Block的过程:(黑色部分为磁盘中的Index文件) 3. 并发访问 Key Cache中的index Block是可以被并发访问的(Shared access ),下面是一些规则: 多个没有更新操作的session可以并发同一个block buffer 多个session同时访问某一个block buffer,如果某个session是update操作,则优先访问 多个session如果都需要进行block replacement,是可以并发操作。(从index file中读取block更新到key cache,但是key cache已满,需要删除一些block buffer的操作叫做block replacement)   4. 补充说明 Key cache中的Block大小可能和索引文件中的Index Block大小不同,可能是大于、小于、等于中的任何一种,但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。 (未完待续)

16:36 详解MyISAM Key Cache(中篇) (2656 Bytes) » DBA@Taobao
p { text-indent:28px; } 在前篇中介绍了Key Cache的基本机制,并且介绍了Key Cache的LRU算法。作为对LRU算法的改进,MyISAM还提供了另一个缓存算法:“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。 1. 相关参数 该策略涉及的参数有:key_cache_division_limit、key_cache_age_threshold 2. 原理介绍 (1) 该策略将前面的LRU队列(LRU Chain)分成两部分,hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分,总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100,所以默认时候只有warm sub-chain,即LRU Chain。 (注:Multiple Key cache情况,每个key cache都有对应的key_cache_division_limit值) (2) 在warm sub-chain中的某个block如果被访问(Access)次数超过某个值时候,就将该block放到hot sub-chain的底部。 (3) 在hot sub-chain中的block会随着每一次的hit调整位置,hit越多,越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中,而且是warm sub-chain的顶部(很可能很快就会被移出key cache)。 (4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是:设N为key cache中的block个数,如果在最近的(N*key_cache_age_threshold/100)次访问中,key cache顶部的block仍然没有被访问到,那么就会被移到warm sub-chain的顶部。 (5) 默认情况key_cache_division_limit = 100,这时只有只有一个Chain,所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。 3. 如何使用Midpoint Insertion Strategy 我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比,如果你的Index Block中明显有30%是非常Hot(较之其他的Block更加被常常访问),那么你可以设置你的warm sub-chain长度为70%,剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制(参照前文介绍)。 (未完待续)

16:36 分布式之后的变化 » DBA@Taobao
16:36 Oracle索引abc » DBA@Taobao
16:36 MySQL Timeout解析 » DBA@Taobao
16:36 LVS & MySQL NDB Cluster » DBA@Taobao
16:36 InnoDB Double write » DBA@Taobao
11:09 推荐周有光的《朝闻道集》 » 木木:木有书读
00:10 大家虎年吉祥 » eagle's home

  2010-02-05 Fri

19:58 What makes a challenger? » Julia----瞬间与记忆在此过渡。。。。。。
17:08 中医中医 » OracleDBA Blog---三少个人涂鸦地!

  2010-02-04 Thu

22:41 小Sam » Julia----瞬间与记忆在此过渡。。。。。。