dbthink2

hellowiki

浏览: 34525 次
性别:
来自: 南京

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

Oracle Cache 设计模式云计算 Linux

Amazon关于切换到云计算的5条建议

Amazon gives us 5 things to consider when making the cloud switch

摘自 http://mor.ph/blogs/5-lessons-when-switching-switching-to-cloud-Amazon-IT

1. Moving to cloud computing is a business decision, not political or marketing mandate. Target the project as a multi-year effort.
2. Server consolidation and virtualization are important initial steps.
3. Start with simple applications; with financials as the last to move.
4. Do homework. Execute risk assessment and take steps to evaluate cloud vendor.
5. Think hard and implement security at the application level, not just at operations.

1. 迁移到云集算平台上是一个商业决策,不能只是政治或市场指令. 此项目可能需要多年的努力.
2. 服务器的整合与虚拟化对于迁移成功很重要.
3. 先迁移简单的应用,将财务类的应用放到最后再做.
4. 做大量的准备. 做好风险评估并花费资源评估各云提供商的产品.
5. 在应用层对安全做深入的考虑以及实现,而不只是考虑运维层面的安全性.

Feed提供商更换

由于Feedsky无法刷新我的blog的Feed(估计可能是国内的域名登记问题),已经在Feedsky登记删除此feed,并将新的链接指向feedburner的feed..Feedsky的链接会保留一个月的时间,一个月以后Feedsky的链接将不再可用.

新相关同学点击此链接重新订阅.

订阅本Blog

Index Rebuild Online 过程(9i)完整版

昨天晚上洗澡时新想到一个可以有效测试index rebuild online的方式, 也就是同时使用10046与10704 的trace event再配合lock阻塞的机制来测试index rebuild online的过程.

测试的过程如下.

01
--1. 构造一个500w条记录的表. 并创建需要rebuild online的索引. 

02
--表的数量设置到这么大,,主要是为了给后续的操作留出手工运行的时间. 

03

create table james_t as

04

select rownum id,dbms_random.string('l',20) user_name 

05

from dual 

06

connect by level <= 5e6; 

07

08

create index james_t_pk on james_t (id); 

09

10
--2. 在Session 2 (故意设置阻塞的进程)运行一个针对表james_t 的单条记录的更新. 

11

update james_t set user_name = 'test 1' where rownum <= 1; 

12

13
--3. 在Session 3中观察,当观察到session 1被堵塞在Table Share Lock的Request模式时进行下一步. 

14

select /*+ rule*/a.* from v$lock a,v$session b where a.sid = b.sid and b.username = 'JAMES'; 

15

16
--4. 在Session 1 (运行index rebuild online的进程)运行如下语句. 

17

alter session set events '10704 trace name context forever,level 10'; 

18

alter session set events '10046 trace name context forever,level 12'; 

19

alter index james_t_pk rebuild online; 

20

21
--5. 在Session 2 提交前一个事务,使得rebuild online 过程继续,并运行一个需要大量index字段的更新操作. 

22
--构造需要rebuild online在获取下一次Table Share lock之前需要Merge的数据. 

23

commit; 

24

update james_t set id = 5000000 + id where rownum <= 3e5; 

25

commit; 

26

27
--6. 在Session 2上运行一个类似于第二步的简单更新,意在阻塞Rebuild Online获取Table Share Lock. 

28

update james_t set user_name = 'test 1' where rownum <= 1; 

29

30
--7.  在Session 3中观察,当观察到session 1被堵塞在Table Share Lock的Request模式时,执行下面的语句后进行下一步. 

31
--清空Buffer Cache以观察Session 1在获取Table Share Lock后执行的操作.(可供下载的Trace文件没有做这一步) 

32

alter session set events = 'immediate trace name flush_cache'; 

33

34
--8. 提交Session 2的事务, 等待Rebuild Online结束.. 

35

36
--9. 从Session 3中提取出Session 1对应的Trace文件,,以及下面的v$session_longops 的结果. 

37
SID SERIAL# OPNAME  TARGET  TARGET_DESC SOFAR   TOTALWORK   UNITS   START_TIME  LAST_UPDATE_TIME 

38

10  19  Sort Output         14759   14759   Blocks  07/28/2010 09:14:26 07/28/2010 09:14:41

1. 取得表上的Sub Share锁. 索引的object_id = 6399.
*** 2010-07-27 23:07:16.000
ksqcmi: TM,18fe,0 mode=2 timeout=21474836
ksqcmi: returns 0

2. 创建日志表.
"JAMES"."SYS_JOURNAL_6399"

create table "JAMES"."SYS_JOURNAL_6399" (C0 NUMBER, opcode char(1), partno number, rid rowid, primary key( C0 , rid ))
organization index TABLESPACE "USERS"

CREATE UNIQUE INDEX "JAMES"."SYS_IOT_TOP_6406" on "JAMES"."SYS_JOURNAL_6399"("C0","RID") INDEX ONLY TOPLEVEL TABLESPACE "USERS" NOPARALLEL

3. 请求表上的Share锁.
*** 2010-07-27 23:07:16.000
ksqcmi: TM,18fe,0 mode=4 timeout=21474836
WAIT #1: nam='enqueue' ela= 3072242 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072273 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072430 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3071962 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072350 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072367 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072086 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072453 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 387366 p1=1414332420 p2=6398 p3=0
ksqcmi: returns 0

2010-07-27 23:07:16.000 + 24.965529 = 2010-07-27 23:07:40.966
--此时间与下面获取Table Sub Share Lock的时间仅相差20ms左右. 中间的时间主要为统计误差,,因为Trace中的输出是连续的.

4. 取得完毕之后,,立即获取表上的Sub Share锁.
*** 2010-07-27 23:07:41.000
ksqcmi: TM,18fe,0 mode=2 timeout=21474836
ksqcmi: returns 0

5. 读取基础表,,创建索引.
WAIT #1: nam='db file scattered read' ela= 42228 p1=5 p2=4709 p3=4
WAIT #1: nam='db file scattered read' ela= 326 p1=5 p2=4710 p3=3
WAIT #1: nam='db file scattered read' ela= 236 p1=5 p2=4711 p3=2
.................
WAIT #1: nam='db file scattered read' ela= 549 p1=5 p2=36357 p3=4
WAIT #1: nam='db file scattered read' ela= 481 p1=5 p2=36358 p3=3

6. 开始Sort并输出索引. (写入临时文件)
WAIT #1: nam='direct path write' ela= 6 p1=201 p2=19942 p3=31
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19973 p3=4
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19721 p3=31
WAIT #1: nam='direct path write' ela= 395 p1=201 p2=19752 p3=12

--继续从表上读取内容.
WAIT #1: nam='db file scattered read' ela= 476 p1=5 p2=36359 p3=2
WAIT #1: nam='db file sequential read' ela= 417 p1=5 p2=36360 p3=1

WAIT #1: nam='direct path write' ela= 6 p1=201 p2=19942 p3=31
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19973 p3=4
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19721 p3=31
WAIT #1: nam='direct path write' ela= 395 p1=201 p2=19752 p3=12

--从临时文件读出排好序的结果.
WAIT #1: nam='direct path read' ela= 211 p1=201 p2=19763 p3=1
WAIT #1: nam='direct path read' ela= 57865 p1=201 p2=27472 p3=31
WAIT #1: nam='direct path read' ela= 14829 p1=201 p2=34281 p3=31
..........
WAIT #1: nam='direct path read' ela= 14853 p1=201 p2=20342 p3=19
WAIT #1: nam='direct path read' ela= 16932 p1=201 p2=26315 p3=31
WAIT #1: nam='direct path read' ela= 12710 p1=201 p2=21154 p3=31
WAIT #1: nam='direct path read' ela= 16599 p1=201 p2=32412 p3=31

写索引文件,扩展segment信息.

select file# from file$ where ts#=:1
select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists,65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$ where ts#=:1 and file#=:2 and block#=:3
insert into seg$ (file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,lists,groups,cachehint,bitmapranges,scanhint, hwmincr, spare1) values (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,0,0,:16,DECODE(:17,0,NULL,:17))
中间再夹杂部分
WAIT #1: nam='direct path read' ela= 20442 p1=201 p2=31559 p3=1

--结束Sort Output并使用Direct path write写入新索引.
WAIT #1: nam='direct path read' ela= 8504 p1=201 p2=19849 p3=1
WAIT #1: nam='direct path read' ela= 263 p1=201 p2=19974 p3=1
WAIT #1: nam='direct path read' ela= 46962 p1=201 p2=19721 p3=1
WAIT #1: nam='direct path write' ela= 359 p1=5 p2=48351 p3=7
WAIT #1: nam='direct path write' ela= 5 p1=5 p2=48358 p3=7

---在此时间点结束新索引的创建工作.
SID SERIAL# OPNAME TARGET TARGET_DESC SOFAR TOTALWORK UNITS START_TIME LAST_UPDATE_TIME
10 19 Sort Output 14759 14759 Blocks 07/28/2010 09:14:26 07/28/2010 09:14:41

7. 读取Journal表上的变更,,将变更Merge到新的索引上.
--从10046 的traced Event的角度看,,新的索引文件写完成,开始读取Journal表的内容,以merge新索引.

WAIT #1: nam='direct path read' ela= 23577 p1=201 p2=31718 p3=1
WAIT #1: nam='direct path read' ela= 60459 p1=201 p2=31877 p3=1
WAIT #1: nam='direct path write' ela= 5622 p1=5 p2=52496 p3=7
WAIT #1: nam='direct path write' ela= 3 p1=5 p2=52503 p3=2
WAIT #1: nam='db file sequential read' ela= 32390 p1=5 p2=397 p3=1
WAIT #1: nam='db file sequential read' ela= 34345 p1=5 p2=397 p3=1
WAIT #1: nam='db file sequential read' ela= 100004 p1=5 p2=52005 p3=1

--结束新索引的Merge工作.
WAIT #1: nam='db file sequential read' ela= 1521 p1=5 p2=32192 p3=1
WAIT #1: nam='db file sequential read' ela= 205 p1=5 p2=32192 p3=1
WAIT #1: nam='db file sequential read' ela= 252 p1=5 p2=32200 p3=1
WAIT #1: nam='db file sequential read' ela= 375 p1=5 p2=32200 p3=1

8. 请求表上的Share所.
--请求表上的Share 锁,,以准备结束索引重建..
*** 2010-07-28 09:15:17.000
ksqcmi: TM,18fe,0 mode=4 timeout=21474836
WAIT #1: nam='enqueue' ela= 3071546 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072536 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072024 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072293 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072416 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072140 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072175 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072294 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072249 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072318 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072184 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072216 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072247 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 1244788 p1=1414332420 p2=6398 p3=0
ksqcmi: returns 0

9. 读取刚刚阻塞Index Rebuild获取Share 锁所产生的Journal日志并将变更merge到索引上.

--说明,,由于Index Rebuild Online进程是做Enqueue Conversion,所以只可能有一个Session会阻塞此进程.
--此次需要Merge的变更量只是阻塞进程产生的变更量,因此一般情况下,,持有Share锁的时间比较短.
--但是会比第一次持有要稍长一点. 需要等后续清理对象的操作结束才能释放.

10. 删除Journal表
drop table "JAMES"."SYS_JOURNAL_6399"

9. 申请Journal表上的Exclusive 锁.
*** 2010-07-27 23:11:03.000
ksqcmi: TM,1906,0 mode=6 timeout=0
ksqcmi: returns 0
=====================

10. 结束索引重建,,修改相关数据字典表
--更新索引上的data_object_id.
update ind$ set ts#=:2,file#=:3,block#=:4,intcols=:5,type#=:6,flags=:7,property=:8,pctfree$=:9,initrans=:10,maxtrans=:11,blevel=:12,leafcnt=:13,distkey=:14,lblkkey=:15,dblkkey=:16,clufac=:17,cols=:18,analyzetime=:19,samplesize=:20,dataobj#=:21,degree=decode(:22,1,null,:22),instances=decode(:23,1,null,:23),rowcnt=:24,pctthres$=:31*256+:25, indmethod#=:26, trunccnt=:27,spare1=:28,spare4=:29,spare2=:30,spare6=:32where obj#=:1
bind 19: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=08 oacfl2=1 size=24 offset=0
bfp=032cc81c bln=24 avl=03 flg=05
value=6405
bind 33: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=08 oacfl2=1 size=24 offset=0
bfp=032cd8dc bln=22 avl=03 flg=05
value=6399

更新对象的data_object_id
update obj$ set obj#=:6,type#=:7,ctime=:8,mtime=:9,stime=:10,status=:11,dataobj#=:13,flags=:14,oid$=:15,spare1=:16, spare2=:17 where owner#=:1 and name=:2 and namespace=:3 and(remoteowner=:4 or remoteowner is null and :4 is null)and(linkname=:5 or linkname is null and :5 is null)and(subname=:12 or subname is null and :12 is null)

设置对象新关联的seg实体.通过ts#,header_file#,header_block#
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535, NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2 and block#=:3

执行Ojbect Checkpoint.
WAIT #1: nam='rdbms ipc reply' ela= 54 p1=5 p2=21474836 p3=0
WAIT #1: nam='rdbms ipc reply' ela= 44 p1=5 p2=21474836 p3=0

11. 到此索引Rebuild完成.

完整的Trace文件文件下载. james_ora_4268.trc.gz

碎片(Fragmentation)--介绍

这份笔记最初只是个便条,直到我认识到它的意义不仅与此,从而决定将此便条拓展成一份完整的说明,我计划在接下来的2个星期发表完下面四个部分.

1. 介绍 — 此文
2. 磁盘与表空间碎片
3. 表碎片
4. 索引碎片

介绍
By Jonathan Lewis Translated By Jametong

单词“fragmentation”（碎片）的涵义是某些东西被分成多个片段,不过,有时也隐含表示被拆成了大量的小片段.在Oracle的语境下,需要仔细考虑你所说的“片段”,片段的粒度大小,以及其对性能产生的可能影响.由于可以在(逻辑)磁盘层面、文件层面、表空间(tablespace)层面、段(segment)层面、区间(extent)层面以及块(block)层面来讨论碎片,当你在评论种说出类似于“我的表空间有碎片”或“我的索引有碎片”时,需要仔细想清楚你到底想要说明什么.

让我从一个例子开始:我创建了一个新的表空间,并移入了一张表.当我检查dba_extents视图,将发现此表空间有100个区间.很明显,从这个单词的基本涵义看,它被“分成多片”了,它有100个不同的片段组成.另一方面,因为此表是我在此表空间内创建的第一个对象,我可以发现所有的区间都相邻,你可以说此表“逻辑上分成多片”但是“物理上连续”.

这个碎片的例子会不会影响你的系统的性能呢？由于大部分Oracle IO都是在块级别上完成(我们将数据块读入到数据库高速缓冲区,我们将数据块写入到数据文件),任何特定区间内的数据块的位置都是无关的,答案或许是no.但有些时候,当我们在一个单一读请求(全表扫描 (TableScan)或者索引快速全扫描(Index Fast Full Scan))中尝试读取多个相邻的数据块时;如果我们的“物理上连续”的表却是“逻辑上被拆分”到了很多个区间,这会不会有问题呢?

假如说,每个区间都只能是64K,这会限制我们将发起的“db file multiblock read”请求的大小吗或者这些请求可以跨越区间边界读取吗?如果这个表空间是有两个(或多个)数据文件组成,而这些区间又是以“轮流”在两个文件之间分配的,这会影响读操作的方式吗?如果我们尝试进行并行表扫描,这些限制在“direct path read”上会不会有所不同呢?如果你的运行系统是一个数据仓库,需要花费大量的时间运行这种操作,那么这些就是你需要回答的问题.(例如,参见我3年前写的关于运行并行查询时的部分IO异常的记录,以及Christian Antognini在大约几年后描述的Oracle 11g中的一个相关改进.)

只有当你开始想清楚你理解“碎片”到底是什么,你才可以理解它可能导致的问题,以及为什么它会(或不会)对你的系统造成问题的理由. 在第二部分中,我将讨论你该如何考虑表级别以及表空间级别的碎片问题.

Buffer和Cache的区别

今天, 又在公司内听到大家争论 Buffer 与 Cache的差异了, 虽然差不多1个月前, 我们就已经在群组里面进行过激烈的争论, 我在网上搜索了下, buffer 与 Cache 区别, 找到下面这个链接, 给出的解释比较接近为维基百科上的说法, 抄录如下, 以为记.

什么是Cache？什么是Buffer？二者的区别是什么？

http://wenda.tianya.cn/wenda/thread?tid=595a1d68b3009fed

Buffer和Cache的区别
buffer与cache操作的对象就不一样。

buffer（缓冲）是为了提高内存和硬盘（或其他I/0设备）之间的数据交换的速度而设计的。

cache（缓存）是为了提高cpu和内存之间的数据交换速度而设计，也就是平常见到的一级缓存、二级缓存、三级缓存。

cpu在执行程序所用的指令和读数据都是针对内存的，也就是从内存中取得的。由于内存读写速度慢，为了提高cpu和内存之间数据交换的速度，在cpu和内存之间增加了cache，它的速度比内存快，但是造价高，又由于在cpu内不能集成太多集成电路，所以一般cache比较小，以后intel等公司为了进一步提高速度，又增加了二级cache，甚至三级cache，它是根据程序的局部性原理而设计的，就是cpu执行的指令和访问的数据往往在集中的某一块，所以把这块内容放入cache后，cpu就不用在访问内存了，这就提高了访问速度。当然若cache中没有cpu所需要的内容，还是要访问内存的。

缓冲（buffers）是根据磁盘的读写设计的，把分散的写操作集中进行，减少磁盘碎片和硬盘的反复寻道，从而提高系统性能。linux有一个守护进程定期清空缓冲内容（即写入磁盘），也可以通过sync命令手动清空缓冲。举个例子吧：我这里有一个ext2的U盘，我往里面cp一个3M的MP3，但U盘的灯没有跳动，过了一会儿（或者手动输入sync）U盘的灯就跳动起来了。卸载设备时会清空缓冲，所以有些时候卸载一个设备时要等上几秒钟。

修改/etc/sysctl.conf中的vm.swappiness右边的数字可以在下次开机时调节swap使用策略。该数字范围是0～100，数字越大越倾向于使用swap。默认为60，可以改一下试试。–两者都是RAM中的数据。

简单来说，buffer是即将要被写入磁盘的，而cache是被从磁盘中读出来的。

buffer是由各种进程分配的，被用在如输入队列等方面。一个简单的例子如某个进程要求有多个字段读入，在所有字段被读入完整之前，进程把先前读入的字段放在buffer中保存。

cache经常被用在磁盘的I/O请求上，如果有多个进程都要访问某个文件，于是该文件便被做成cache以方便下次被访问，这样可提高系统性能。

分享到：

何塞·穆里尼奥 | dbthink1

2011-03-31 23:14
浏览 1073
评论(0)
分类:数据库
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

dbthink2

Amazon关于切换到云计算的5条建议

Feed提供商更换

Index Rebuild Online 过程(9i)完整版

碎片(Fragmentation)--介绍

Buffer和Cache的区别

评论

发表评论

相关推荐

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

dbthink2

Amazon关于切换到云计算的5条建议

Feed提供商更换

Index Rebuild Online 过程(9i)完整版

碎片(Fragmentation)--介绍

Buffer和Cache的区别

评论

发表评论

相关推荐

最近访客更多访客>>