Rich Niemiec 先生趁这次上海OOW的机会，在中国巡游。安排了到杭州我们公司做一堂课，选择了oracle internals at the block level ！ 可能是听说我们公司dba在国内算是领先的，所以选择了这个题材，这也是在国内唯一一处地方讲了这个内容。

其实内容基本上我还是比较清楚的，只可惜总是觉得要想和他深入沟通难度太大，也怪自己口语不行了。后来课完之后一起吃午饭，单独做了一些交流。

优秀数据库工程师评选，IT168 网络采访

1 我注意到您发在itpub论坛上的招聘广告了，您觉得目前在国内，招聘一个满足阿里巴巴这样的大型电子商务网站应用的数据库的DBA是否容易？为什么？

2 您心目中理想的DBA应该具备哪些技能？

3 您觉得造成目前中国合格数据库人才缺乏的原因有哪些？

4 您为何选择到专业论坛（itpub）发招聘帖子的方式来招揽人才？

5 据了解，目前中国从事数据库开发、管理的人才（包括开发人员）大约有20万，其中
专职的DBA，您估计目前中国有多少？

优秀数据库工程师评选，赛迪网络采访

1、你认为国内数据库应用水平与人才状况如何？

2、结合你的工作与项目经历，请谈谈数据库工程师在应用上面对的难点。

3、要解决这些应用难点，工程师的个人经验能起到哪些作用？数据库技术发展能起到
什么作用？

4、您认为“2006年中国首届杰出数据库工程师评选”活动的意义？

结论：肥胖。 建议：吃低脂肪食物。

这一切就因为我把体重自己写上去了，你看donny没写上去，就没事，他要写了，跟我也差不多。 不就密度大点嘛，至于吗？不吃肉，那还让不让人活了。

要说这身体，咱也不算差啊。拿到体检结果，和donny / jacky就探讨起来，后来为了证明身体不差，就在公司比立定跳远。好家伙，穿着鞋太滑，查点摔倒，干脆把鞋脱了，赤脚上阵，结果是我们都差不多。donny觉得冤，认为比我们远几厘米 :)。

就跳了两下，jacky据说第二天起床差点没起来，donny说腰疼，就我感觉还成。 周六下午打羽毛球，7个人，偶跟谁配对好象都赢耶（大家都是菜鸟，嘘），所以偶总在场上，一开始那个累啊，后来就好多了。打完和donny去中田大厦的外婆家吃饭，环境挺好，就是我俩汗流浃背的，有点辱没气氛。

吃饭回家，donny洗澡就睡觉了。到了22点半了，老魏电话给我，说去piner家斗地主。我靠，这家伙刚和mm吃饭喝酒完毕回来就邀人打牌。我说好，就打车前往。到了piner家，他在和一同时在玩sc，惊讶的问：你怎么来了。我倒，敢情老魏没通知piner啊。 正好他们玩sc结束，据说这局玩了2小时。piner赢了，非拉我们一起看完这个录象（16:1的速度）。我倒，sc能玩2小时，这两人水平真是旗鼓相当啊（据说即使高手对招也就半小时左右，一般人也就10分钟 :) ）。看完，玩sc的哥们就走了。

我们仨斗地主，某人这晚发挥超常，能把赢牌打输。哈哈。不过偶也够郁闷的，好几把把抓了两个炸弹在手里直到结束也没能出去。 奋战到3点多，偶困了，就回家了。战果，赢了3个伟人头，还好没垫路费。

今天早上9点被家人电话吵醒，问我干吗呢，我说睡觉。我爸说：这么晚了，还睡觉啊。他们哪里知道我辛苦到凌晨4点才睡觉啊。然后就没办法睡觉了，起来一看donny还在睡觉，我晕，一直到12点才起来，他这简直就是睡神。

天太热，不想出门，就煮点白米饭吃，就着老干妈，真美味啊。晚上donny请吃饭，主要是jacky老婆来了，我蹭了一顿。明天，就又吃食堂啦。

新系统IBM P590,AIX5.3,8 cpus /16G 内存，为了同时兼顾IO压力，我特地把 buffer cache 只给了1G大小。模拟应用的sql调用，用5台2 cpus的linux机器并发16*5 个线程同时循环跑一个client无IO的模拟应用的随机用户登陆流程(这个期间会运行一系列的sql)。linux机器上开16个线程同时跑的时候load 已经在2左右。而IBM服务器上cpu  idle 2%,IO 为 read  40MB/S,write  8MB/S ，网络 IN  12MB/S  ,  out  6MB/S。run queue (load)为 50。

在statspack采样数据load  profile 为

STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
OCNDB 3701801852 ocndb 1 9.2.0.6.0 NO ocndb1

Snap Id Snap Time Sessions Curs/Sess Comment
--------- ------------------ -------- --------- -------------------
Begin Snap: 104 19-May-05 17:27:53 91 27.3
End Snap: 105 19-May-05 17:57:54 91 27.8
Elapsed: 30.02 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,024M Std Block Size: 8K
Shared Pool Size: 512M Log Buffer: 2,048K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 344,880.30 555.47
Logical reads: 198,459.35 319.64
Block changes: 2,494.51 4.02
Physical reads: 5,105.48 8.22
Physical writes: 48.74 0.08
User calls: 84,336.12 135.83
Parses: 6,208.79 10.00
Hard parses: 0.03 0.00
Sorts: 1,242.01 2.00
Logons: 0.00 0.00
Executes: 19,867.03 32.00
Transactions: 620.88

% Blocks changed per Read: 1.26 Recursive Call %: 26.51
Rollback per transaction %: 0.00 Rows per Sort: 23.61

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.30 Redo NoWait %: 100.00
Buffer Hit %: 97.43 In-memory Sort %: 100.00
Library Hit %: 100.02 Soft Parse %: 100.00
Execute to Parse %: 68.75 Latch Hit %: 99.32
Parse CPU to Parse Elapsd %: 34.12 % Non-Parse CPU: 96.74

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 20.97 21.15
% SQL with executions>1: 83.85 83.54
% Memory for SQL w/exec>1: 88.18 85.88

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 8,558 52.19
db file sequential read 9,194,762 4,730 28.84
buffer busy waits 2,500,799 1,639 10.00
log file sync 1,076,173 771 4.70
latch free 174,822 588 3.58
-------------------------------------------------------------

看起来系统还是蛮强的，executions 为 19867次/S ,620个事务/S……

我们通常希望把oracle sga锁定在内存中，并且使文件系统缓存比例控制到一定范围，在AIX5.3之前版本，一般是使用vmtune -p 5 -P 20 -S 1

而在AIX5.3中则使用

 vmo   -r -o v_pinshm=1
 vmo -o minperm%=5
 vmo -o maxclient%=20
 vmo -o  maxperm%=20

重新启动生效的参数记录在 /etc/tunables/nextboot 文件中，通过 vmo -L 可以查看相关系列参数。

吃饭真成了一个大问题，这几天去了玉麒麟、沸腾鱼乡、外婆家、越之间，吃饭人多的时候还好一些，只有我们两个人吃饭的时候，真是比较麻烦，关于菜到底点几个就是永远争论的焦点，我总倾向于点四个，她总嫌多。我想两荤一素一汤的结构还是很合理的吧。

其实杭州吃饭的地方也不算很少，但是很多饭馆人实在太多太吵，两个人吃饭一般都是在大堂，说话都困难。环境幽雅一些的地方，往往菜本身味道不合我口味，真是难以调和。

前天换了瓶煤气，昨天买了些厨房用品，有心情的话，自己随便做点凑合吧。

rootvg 中原来mirror的是 hdisk0 和 hdisk1，由于这两块磁盘是同一个BUS上的，我想换另外一个BUS上的磁盘，用hdisk4替换掉hdisk1

root用户执行：

extend rootvg hdisk4
migratepv -l  hd5  hdisk1 hdisk4
bosboot -ad  /dev/hdisk4
chpv -c  hdisk1
bootlist -m  nornal  hdisk0 hdisk4

sysdumpdev -p /dev/sysdumpnull
migratepv hdisk1 hdisk4
sysdumpdev -p /dev/hd6

reducevg rootvg hdisk1

shutdown -Fr

参考

http://www.cnoug.org/viewthread.php?tid=52545

有人问：

看ixora 中的文件。

上面說 在控制文件中除第一個 section 外﹐每個 邏輯塊都是兩個物理塊來表示.一個是當前的信息﹐另一個是舊的 copy 版本或未提交的信息.

因為 發生 controlfile transactions 時﹐這個 session 會有一個exclusive lock on the CF enqueue ﹐所以這個時候是不會允許任何操作﹐即使讀也不允許。

所以我有疑惑﹐因為一旦發生 Controlfile Transactions ﹐整個 contrfolfike 就會被 lock ﹐即對 全部 session 來說﹐要么能訪問﹐要么不能用.那么 用兩個 物理塊來作 recovery 的功能是不是就沒有必要了﹐隊非在 Controlfile Transactions 期間發生 system /instance 錯誤﹐或 hot backup。才有可能用到。不過文檔中又有說到當一個session 來讀 controlfile 時﹐它會首先去訪問 block version bitmap 以取得正確的塊版本﹐這說明應有其它情況存在.....

另有一個問題﹐因為在發生改變邏輯塊時﹐它會先更新一個物理的塊﹐那么這個邏輯塊所對應另一個物理塊什么時候更新﹐在這個 Controlfile Transactions 提交的時候嗎﹖好像不像﹐﹔因為它允許其中一個塊包括以前舊的拷貝。

今天有人在论坛上问起，顺便也说说我的看法。

一方面技术类的书籍，时效性比较高，生命中期不太长。通常出版的书册数不会太多。如果一个工薪族技术类高手要出一本书，出版商所出的价格，可能还不如其月薪，而写一本书，却是需要长达几个月的心血。首先在这个环节上，就降低了技术类高手出书的可能性，倾心血觉得不值得，不倾心血呢觉得没意思，技术类书籍出书目前只是一个短期效益而不是长期效益。因为工薪族，长期潜心技术的人相对是比较少的，国内环境下技术人才得到重视的不多，都琢磨着做别的呢。

以oracle技术方面的书籍为例，欧洲和美国出的非常经典书籍相对数量比较多一些，但是绝对数量恐怕也就在10来本左右。而这些书的作者，几乎都是早年在oracle工作了多年，潜心研究过oracle，不少人离开oracle公司之后，就是靠这方面的技能开公司做服务或者做个人服务。他们一直关注着相关的技术，并且把自己的经验很好的整理了下来，通过几年甚至十多年的积累，才出了一本书。这些人在internet上往往也非常活跃，出书既是他们经验的总结，也能给他们带来不错的经济和名声收益，为此同时还给他们带来更多的做服务的机会。

我想国内IT可能还需要进一步发展，等到IT类的服务更专业更成熟以后，使得潜心研究技术的人能通过长期的研究获得更多的回报，出书只是他们多年经验的汇集，他们不需要为月薪所累，可以通过出书、培训、服务等等方式挣钱，这个时候，应该就可以看到好书了。

上个周末去学车，由于前一天加班到凌晨，晕的很，学的一塌糊涂。今天去就有点担心。

三个人学，师傅计划学到下午四点，结果直到快11点了才腾出场地给我们，大家居然都学的很快，3点就结束了，还把下次的都给学了。有进步啊。

恩，偶左右方向入库每把都成功的还完成的算不错，找回了自信的说 :)