2010-09-03 Fri
之所以迫不及待地去看 Inception，是因为老婆以前跟我说，她曾经做过三层的梦。至今仍能记得第二层的场景，那是从第三层跌出来的。当在第二层奔跑，又不慎跌落醒来时，看到的还是梦境，第一层梦。这种体验实在离奇，居然有一部电影描述的也是这种结构，不得不一睹为快。
好莱坞专业造梦工厂生产的电影，比自娱自乐的无情节三层动作片肯定要好看不少。盗梦者未盗得文件机密，反被利诱去植梦，要在目标潜意识里植入一个想法。招兵买马构建梦之队，投资人为了简化操作甚至买下了目标乘坐飞机的航空公司，按计划顺利登机、药倒，共同进入预先制造的幻境迷宫。
梦境里的人和事物都是意识自由创造的，在梦境里，人就是上帝，境由心造。可麻烦的是，梦里人人都是上帝，宇宙在手，万化由心。大街上突如其来的一列火车、四面八方不断袭来的防御者、波诡云谲的天气、违反定律的物象，都是梦境共享者内心意识相互冲突、矛盾的反映。梦中有梦，意外套着意外，幸好关键时刻理智战胜了迷思，最终大家平安脱梦而出。
真的出来了吗？未必。陀螺旋转，但没有停，至此戛然而止。这究竟是现实还是梦境？
人生如梦，电影是梦里做梦，看着电影里层层嵌套的梦，不知身在第几层。
** 本文含有部分剧透，请尚未观影者慎读，或者狠狠掐一把大腿。
我在 "10.2.0.4.0里请慎用压缩表"这篇文章里提到了oracle关于压缩表的一个bug----Bug 7123643 UPDATE TO A COLUMN IN A COMPRESSED TABLE RESULTS IN DATA LOSS。
我在那篇文章里提到说----"10.2.0.4.0上请慎用压缩表，很有可能会丢数据的"。这个观点本质上来源于MOS上对上述bug的描述，但这种说法是不确切的，或者说至少是不准确的！我当时对压缩块的格式还不熟悉，现在已经不一样了。
我们来看看真相是什么，首先让我们来重现上述问题。
SQL> create table t1 as select * from saldat where rownum<120001;
Table created
SQL> select count(*) from t1;
COUNT(*)
----------
120000
SQL> create table t2 compress as select * from t1;
Table created
SQL> select count(*) from t2;
COUNT(*)
----------
120000
SQL> select count(*) from (select * from t1 minus select * from t2);
COUNT(*)
----------
0
我定位到t2表中的一行记录，注意到此时我在只select SDAFCR和SDAFAR的情况下，它们的值均为null：
SQL> select sdafcr,sdafar,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location from t2 t where sdaprf='999' and sdafrm='172' and sdatkt='5732417';
SDAFCR SDAFAR LOCATION
------ ----------------- --------------------------------------------------------------------------------
9_186026
当我在除了select SDAFCR和SDAFAR，还select *的情况下，它们的值还是维持null不变：
SQL> select sdafcr,sdafar,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location,t.* from t2 t where sdaprf='999' and sdafrm='172' and sdatkt='5732417';
SDAFCR SDAFAR LOCATION
SDAPRF SDAFRM SDATKT SDACHK SDASEQ SDABTH
......省略显示部分内容 SDAUID SDAUDT SDAPRS SDAVOD SDAADF SDAPER SDABTN SDAGPN SDA
------ ----------------- -------------------------------------------------------------------------------- ------ ------
9_186026 999 172 5732417 2 546947 BDUB20081231EUR01 00001 BSP ......省略显示部分内容 20090809100850 M FFVV N
我们现在看一下9_186026这个块中的上述行：
tab 1, row 19, @0xbcf
tl: 70 fb: --H-FL-- lb: 0x0 cc: 225
col 0: [ 3] 39 39 39
......省略显示部分内容
col 197: [ 3] 31 37 32
col 198: [ 7] 35 37 33 32 34 31 37
......省略显示部分内容
col 205: *NULL*
col 206: *NULL*
col 207: *NULL*
col 208: *NULL*
col 209: *NULL*
col 210: *NULL*
col 211: *NULL*
col 212: *NULL*
col 213: *NULL*
col 214: *NULL*
col 215: *NULL*
col 216: *NULL*
col 217: *NULL*
col 218: *NULL*
col 219: *NULL*
col 220: *NULL*
col 221: *NULL*
col 222: *NULL*
col 223: *NULL*
col 224: *NULL*
bindmp: 2c 00 32 a0 0b 29 1b ff 2b ff 48 ff ff ff ff 50 4e 66 ff ff 54 51 ff 2b ff ff 4e cf 35 37 33 32 34 31 37 cc c3 37 46 30 4f 67 48 65 cd c4 03 04 0b 2e ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SQL> desc t2;
Name Type Nullable Default Comments
------ ------------- -------- ------- --------
SDAPRF VARCHAR2(4) ――第0列
SDAFRM VARCHAR2(3) ――第1列
SDATKT VARCHAR2(8) ――第2列
SDACHK NUMBER(1) Y
......省略显示部分内容
SDAFCC VARCHAR2(400) Y
SDAFCR VARCHAR2(3) Y ----第51列
SDAFAR NUMBER(15,4) Y ――第52列
SDAEFA NUMBER(15,4) Y
......省略显示部分内容
SDACAE VARCHAR2(11) Y
而上述块中的perm_9ir2数组为：
perm_9ir2[225]={ 0 197 198 194 199 191 1 2 150 3 175 4 200 5 6 7 176 205 8 195 206 9 152 153 196 207 193 208 190 209 10 11 154 210 155 156 211 12 212 157 213 214 215 13 158 216 159 14 160 183 217 218 219 220 15 16 17 18 19 20 21 161 22 23 24 25 178 221 26
182 162 180 27 163 28 29 30 31 32 33 34 35 222 36 201 164 223 165 184 37 38 39 40 185 166 41 42 167 187 188 179 168 43 44 45 46 202 181 151 47 48 49 50 169 51 52 53 54 55 192 56 57 58 186 59 60 61 62 189 170 63 171 172 64 65 224 66 67 68 69 70 71 72 73 74
75 76 77 78 79 80 81 82 203 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 177 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 173 134 135 136 137 138 174 139 140 141
142 143 204 144 145 146 147 148 149 }
从结果里我们可以看出，上述行至少有0xa0列被压缩了。
现在我们来执行产生不一致的修改操作：
18:37:31 SQL> update t1 set sdapgc=0.5;
120000 rows updated
18:37:42 SQL> update t2 set sdapgc=0.5;
120000 rows updated
18:38:54 SQL> commit;
Commit complete
从上述结果里可以看出，同样都是更新12万条记录，非压缩表只用了11秒，而压缩表则用了1分12秒，为什么会有这么大的差异，我下一篇文章会专门阐述这个问题。
不一致已经产生，也就是MOS上提到的所谓的丢了数据：
SQL> select count(*) from (select * from t1 minus select * from t2);
COUNT(*)
----------
917
我们之前看的那条记录，即sdaprf='999' and sdafrm='172' and sdatkt='5732417'的那条记录，刚好是处于不一致的区域：
SQL> select sdaprf,sdafrm,sdatkt from (select * from t1 minus select * from t2) where rownum<2;
SDAPRF SDAFRM SDATKT
------ ------ --------
999 172 5732417
注意仔细看我如下的查询：
SQL> select sdafcr,sdafar,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location from t2 t where sdaprf='999' and sdafrm='172' and sdatkt='5732417';
SDAFCR SDAFAR LOCATION
------ ----------------- --------------------------------------------------------------------------------
9_186026
SQL> select sdafcr,sdafar,dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location,t.* from t2 t where sdaprf='999' and sdafrm='172' and sdatkt='5732417';
SDAFCR SDAFAR LOCATION
SDAPRF SDAFRM SDATKT SDACHK SDASEQ SDABTH
......省略显示部分内容 SDAUID SDAUDT SDAPRS SDAVOD SDAADF SDAPER SDABTN SDAGPN SDA
------ ----------------- -------------------------------------------------------------------------------- ------ ------
AED 2630.0000 9_186026
999 172 5732417 2 546947 BDUB20081231EUR01 00001 BSP ......省略显示部分内容 20090809100850 M FFVV N
从结果我们可以看到，现在已经出现了自相矛盾，不合情理的不一致。
我们的问题是：
SDAFCR的值到底是null还是AED?
SDAFAR的值到底是null还是2630.0000?
我们来看一下修改后的块9_186026：
现在的perm_9ir2数组依然为：
perm_9ir2[225]={ 0 197 198 194 199 191 1 2 150 3 175 4 200 5 6 7 176 205 8 195 206 9 152 153 196 207 193 208 190 209 10 11 154 210 155 156 211 12 212 157 213 214 215 13 158 216 159 14 160 183 217 218 219 220 15 16 17 18 19 20 21 161 22 23 24 25 178 221 26
182 162 180 27 163 28 29 30 31 32 33 34 35 222 36 201 164 223 165 184 37 38 39 40 185 166 41 42 167 187 188 179 168 43 44 45 46 202 181 151 47 48 49 50 169 51 52 53 54 55 192 56 57 58 186 59 60 61 62 189 170 63 171 172 64 65 224 66 67 68 69 70 71 72 73 74
75 76 77 78 79 80 81 82 203 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 177 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 173 134 135 136 137 138 174 139 140 141
142 143 204 144 145 146 147 148 149 }
修改后的那一行现在的内容为：
tab 1, row 19, @0x10d9
tl: 377 fb: --H-FL-- lb: 0x0 cc: 205
col 0: [ 3] 39 39 39
......省略显示部分内容
col 197: [ 3] 31 37 32
col 198: [ 7] 35 37 33 32 34 31 37
col 199: [ 4] c3 37 46 30
col 200: [ 8] 33 36 32 30 33 30 35 33
col 201: [ 9] 56 38 31 53 54 49 2f 31 47
col 202: [ 5] c4 15 09 0d 20
col 203: [ 6] 44 4c 43 44 4c 43
col 204: [ 5] c4 03 04 0b 2e
bindmp: 2c 00 cd 00 cb 39 39 39 cd 30 30 30 30 31 cb 42 53 50 c9 50 ff c9 42 c9 49 cc 54 4b 54 54 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cd c4 15 0b 02 20 ff ff ff ff ff ff cc 74 65 73 74 ff ff c9 4d c9 4e ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cd c4 15 0b 07 1e d0 c7 15 0b 07 1e 0c 07 10 ff ff ff ff ff ff ff ff ff ff ca c1 02 ff ff cc c3 15 0a 09 ff ff ff ff ff ff c9 59 cd c4 15 0b 08 16 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c9 4e cd c4 15 09 0d 20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c9 59 ca c1 03 c9 59 ff ff ff ff ff cc 47 44 53 4c cb 45 55 52 ca 54 55 ff ca c1 03 ff cd c4 15 09 0d 20 ff ff ff ff cc 46 46 56 56 cb 31 37 32 cf 35 37 33 32 34 31 36 ff ff d9 42 44 55 42 32 30 30 38 31 32 33 31 45 55 52 30 31 d0 c7 15 0a 09 0a 0b 09 33 ff ca c1 03 ff ff cb 31 37 32 cf 35 37 33 32 34 31 37 cc c3 37 46 30 d0 33 36 32 30 33 30 35 33 d1 56 38 31 53 54 49 2f 31 47 cd c4 15 09 0d 20 ce 44 4c 43 44 4c 43 cd c4 03 04 0b 2e
可以看到现在这一行已经被oracle解压缩了（注意到行头的第4个byte已经由0xa0变成了0x00），这里列序号只到204就终止了，这是正常的，因为对于非压缩块而言，如果从某一列之后的值全为null，则oracle并不会在行里存储这些null值，就好像没有这些列一样。
也就是说SDAFCR、SDAFAR的值确实是null。
那么为什么oracle会显示SDAFCR的值是AED？
tab 1, row 20, @0x10d0
tl: 9 fb: --H----- lb: 0x0 cc: 0
nrid: 0x02c2cda6.5
bindmp: 20 00 00 02 c2 cd a6 00 05
tab 1, row 21, @0xe98
tl: 568 fb: --H-FL-- lb: 0x0 cc: 225
col 0: [ 3] 39 39 39
col 1: [ 5] 30 30 30 30 31
......省略显示部分内容
col 176: [ 3] 41 45 44
col 177: [ 2] 54 55
col 178: [ 2] 43 41
本应该是读第19行，但是oracle这里似乎读到第21行去了。
所以我们的结论就是：
对于上述bug，压缩块内的数据其实并没有丢失，只是oracle在select的时候出了问题。我这里测试的结果是对单列select的时候是没问题的，但是如果是select *，则结果就不对了。
南迦巴瓦峰是中国西藏林芝地区最高的山，海拔7782米，高度排在世界最高峰行列的第15位，但它前面的14座高山全是海拔8000米以上山峰，因此南迦巴瓦是7000米级山峰中的最高峰。它还有另一个名字"木卓巴尔山"，其巨大的三角形峰体终年积雪，云雾缭绕，从不轻易露出真面目，所以它也被称为"羞女峰"。南迦巴瓦在藏浯中有多种解释，一为"雷电如火燃烧"，一为"直刺天空的长矛'，还有一为"天山掉下来的石头"。后一个名字来源于《格萨尔王传》中的"门岭一战"，在这段中将南迦巴瓦峰描绘成状若"长矛直刺苍穹"。
我们凌晨5点从住处出发，前往雅鲁藏布大峡谷，其间有绝好的地点可以一睹南迦巴瓦的芳容。那是天还未名，车行路上，仿佛可以听见自然的耳语，间或司机刹车等待淡定的小猪慢慢悠悠的走过公路，在林芝，一切都是自由的。
在途中Z字型的山路上，你就可以一睹南迦巴瓦的芳容，带着点小心的惊呼，怕惊起云雾，遮掩了不轻易见人的山峰：
看，藏在云雾中若隐若现的美丽容颜，你这一生可能只有那一瞬的机会瞬间瞥见，凛冽的积雪，隽秀的山峰，洁白的面纱，凝成不动的圣洁与永恒，如果有机会，你一定要去看南迦巴瓦：
在南迦巴瓦的观景台上，我们还巧遇一位中央电视台的摄影记者，架起摄像机数个小时，拍摄峰前的云起云落，我们相约回北京去欣赏他拍摄的美景：
林芝这段旅程是最为闲适的，没有高反，有无穷的美景，每一处都值得信息品味，期待重逢：
相关文章|Related Articles
评论数量(1)|Add Comments
本文网址：http://www.eygle.com/archives/2010/09/tibet_namchabarwa.html
By：Fenng posted @ dbanotes.net. RSS | Ad.Adobe Flash Builder 4 简体中文正式版下载
这两天看到消息，Dell 在对 3PAR 争夺战中退出，HP 宣布获胜。当然，代价也是不菲，总收购价格大约 20 亿美元。
3PAR 这家公司刚进入国内我就有所接触，因为该公司在美国有很多证券、金融行业的客户，加之我上一家雇主就是做这个方面的，所以我非常想了解并引入 3PAR 的一些成功的经验，并且研究了一下高端的几款产品特性（refer: 3PAR 存储架构解析 )，最后还吃了一下螃蟹，在 3PAR 上实现了一套 Oracle 11g RAC 集群。所以，我算得上国内少数真正用过 3PAR 的了吧。考虑到以后再也不会接触这些所谓高端存储，还是有必要写点东西做个纪念。
应该说，3PAR 这产品的确有独到之处。首先是性能上看，通过特定硬件架构，充分利用了机械硬盘的特点，进而保证 I/O 响应时间，这是硬指标，真是非常贴近金融类的用户需求。 Thin Provisioning 技术也是实实在在的可在产品环境使用的，不像个别存储厂商只是一些功能的包装，跟风炒作概念，忽悠客户。让人感慨的是，3PAR 最近有有些生不逢时或是走向末路，上市时也恰好是金融危机来临之际，核心业务一下子受到非常大的影响，这是商业层面上的；另一方面，3PAR 的技术在机械硬盘时代几乎独步存储武林，但到了 SSD 的时代，则有武功被废的可能。尽管也宣称支持 SSD，但毕竟在机械硬盘时代的优势将不复存在了。追求高 IOPS ，更小 I/O 响应时间的用户用 PC 服务器 ＋ SSD 就能很好的满足要求了。
HP 收购 3PAR 的意图其实比较明显，那就是弥补自己在高端产品上的缺陷。最近几年，IBM 在推收购来的 XIV ，HP 也有 EVA 系列的存储，和 3PAR 的一些设计理念都是很相近的，不过都只能算是中端存储，算不得高端产品。据我所知，EVA 似乎市场表现一般。收购 3PAR 后，估计 EVA 产品线将最终消亡。业内其实都知道，HP 自己一直没有高端存储产品，一直是 OEM Hitachi Data Systems(HDS) 的高端产品，后来和 Oracle 合作 Exadata ，Oracle 收购 Sun 之后也不再和 HP 合作，对 HP 来说，如果在未来几年，要在存储领域有所作为，收购是最为便捷的办法--也是高层最不用动脑筋就能使用的办法。
尽管 HP 有收购 3PAR 的足够理由，但我觉得这笔收购未必能对 HP 带来多大价值。如果给 Dell 可能会更好一些，Dell 可能将 3PAR 用来主打中高端存储市场。
据说 3PAR 的 CEO 获益比三位联合创始人的都要高，这就是商业运作的力量。3PAR 发展到现在，历史已经有 10 年了，在看到一些有创造力的公司成功之前，也要想到创业的艰辛，成功只是少数，失败是多数。（3PAR 的命名是这样的：3 表示三个人，P 代表Jeffrey Price；A 代表Ashok Singhal；R 则为 Robert Rogers，已于 2001 年离开. 所以，这家公司的名字应该都用大写字母才是）
从技术发展和业界的需求来看，这些 SAN 中高端存储已经临近黄昏。也不可能在云存储方面有什么进一步的想象力，有的话，也是空想。当然，这是另外的话题了。
--EOF--
最近文章|Recent Articles
本站赞助商：豆瓣网
评论数(0)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/review/3par_acquired_by_HP.html
DBA Notes 理念: 用简约的技术取得最大的收益...
InfiniBand architecture has the following communication characteristics:
- User-level access to message passing
- Remote Direct Memory Access (RDMA) in read/write mode
- Up to a maximum of 2-Gb message in a single transfe
zt from ” Oracle 10g RAC Grid,Services & Clustering ”
The demands of the Internet and distributed computing are challenging the
scalability, reliability, availability, and performance of servers. InfiniBand
architecture represents a new approach to I/O technology and is based on
the collective research, knowledge, and experience of the industry’s leaders
and computer vendors.
InfiniBand architecture specifies channels that are created by attaching
host channel adapters (HCAs) within a server chassis to host channel adapters
in other server chassis. This is done for high-performance IPC and to
target channel adapters connecting Infiniband-enabled servers to remote
storage and communication networks through InfiniBand switches. Infini-
Band links transfer data at 2.5 Gbps, utilizing both copper wire and fiber
optics for transmission. It can carry any combination of I/O, network, and
IPC messages.
InfiniBand architecture has the following communication characteristics:
- User-level access to message passing
- Remote Direct Memory Access (RDMA) in read/write mode
- Up to a maximum of 2-Gb message in a single transfer
The memory protection mechanism defined by the InfiniBand architecture
allows an InfiniBand HCA to transfer data directly into or out of an
application buffer. To protect these buffers from unauthorized access, a process
called memory registration is employed. Memory registration allows
data transfers to be initiated directly from user mode, eliminating costly
context switches to the kernel. Another benefit of allowing the InfiniBand
HCA to transfer data directly into or out of application buffers is that it can
remove the need for system buffering. This eliminates the context switches
to the kernel and the need to copy data to or from system buffers on a send
or receive operation, respectively.
InfiniBand architecture also has another unique feature called a memory
window. The memory window provides a way for the application to grant
28 2.1 RAC components
remote read and/or write access to a specified buffer at byte-level granularity
to another application. Memory windows are used in conjunction with
RDMA read or RDMA write to control remote access to the application
buffers. Data could be transferred by either the push or pull method (i.e.,
either the sending node would send [push] the data over to the requester, or
the requester could get to the holder and get [pull] the data).
While InfiniBand is a fairly new technology, it promises tremendous
potential and benefits in a clustered configuration where high-speed data
transfer is required via the cluster interconnect. While RAC has been
tested to work under InfiniBand, as the popularity of this technology
evolves, more and more implementations using this technology will
become commonplace.
2010-09-01 Wed
By：Fenng posted @ dbanotes.net. RSS | Ad.Adobe Flash Builder 4 简体中文正式版下载
看过之后才会相信，电影《盗梦空间》（Inception） 如潮的好评名副其实，个人强烈推荐。即使有人介绍过剧情，自己观看的时候仍然是不一样的。这就是经典的魅力吧。
整部电影还是给人颇有些"庄生晓梦"的感觉。我和 Laura 开玩笑，是不是现在就在梦里？毕竟都凌晨三点钟了。情节繁复，循环，仿佛博尔赫斯的小说，但影片倒是并没有故弄玄虚，虽然开头部分信息量较大，一旦进入情节，后面的节奏控制得非常好。对于情节的设定，计算机同行不妨把把梦当作虚拟机好了，只是下一层的虚拟机会更慢而已。或许你会为电影中的爱情故事感慨，关于父子亲情难道就不感人么？
有一处场景明显是借鉴了荷兰艺术家埃舍尔（M.C. Escher）的作品，"不可能"的图形：
杭州万象城的 IMAX 厅，九月一号凌晨看的首映，买票的时候有些犹豫，午夜场，第二天还要上班，熬夜值不值？回家睡了一觉又杀去，整个放映厅差不多都坐满了，杭州影迷精神头可谓十足。将近三个小时的电影，看完后毫无困意。
--EOF--
最近文章|Recent Articles
本站赞助商：豆瓣网
评论数(5)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/mylife/inception.html
DBA Notes 理念: 用简约的技术取得最大的收益...
Oracle 11g中增加了一个新的视图DBA_USERS_WITH_DEFPWD用于显示那些具有缺省口令的用户：
SQL> desc DBA_USERS_WITH_DEFPWD
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
USERNAME NOT NULL VARCHAR2(30)
SQL> select * from dba_users_with_defpwd;
USERNAME
------------------------------
DIP
MDSYS
XS$NULL
SPATIAL_WFS_ADMIN_USR
OUTLN
OLAPSYS
SPATIAL_CSW_ADMIN_USR
OWBSYS
ORACLE_OCM
EXFSYS
SCOTT
DBSNMP
ORDSYS
ORDPLUGINS
MDDATA
APPQOSSYS
ORDDATA
XDB
WMSYS
SI_INFORMTN_SCHEMA
已选择20行。
这里显示的20个用户，其账户都是锁定的，所以大可不必担心。
如果进一步的研究一下，这个视图的底层表是DEFAULT_PWD$：
SQL> set autotrace trace explain
SQL> select * from dba_users_with_defpwd;
执行计划
----------------------------------------------------------
Plan hash value: 180429094
---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 6 | 102 | 10 (10)| 00:00:01 |
| 1 | VIEW | DBA_USERS_WITH_DEFPWD | 6 | 102 | 10 (10)| 00:00:01 |
| 2 | HASH UNIQUE | | 6 | 312 | 10 (10)| 00:00:01 |
| 3 | CONCATENATION | | | | | |
| 4 | NESTED LOOPS | | | | | |
| 5 | NESTED LOOPS | | 2 | 104 | 4 (0)| 00:00:01 |
|* 6 | TABLE ACCESS FULL | USER$ | 2 | 54 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | I_DEFAULT_PWD | 1 | | 0 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| DEFAULT_PWD$ | 1 | 25 | 1 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 50 | 2600 | 5 (0)| 00:00:01 |
|* 10 | TABLE ACCESS FULL | USER$ | 1 | 27 | 2 (0)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | DEFAULT_PWD$ | 775 | 19375 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - filter("U"."PASSWORD" IS NOT NULL AND "U"."TYPE#"=1)
7 - access("U"."NAME"="DP"."USER_NAME" AND "U"."PASSWORD"="DP"."PWD_VERIFIER")
8 - filter("DP"."PV_TYPE"=0)
10 - filter("U"."TYPE#"=1 AND BITAND("U"."ASTATUS",16)=16)
11 - filter(LNNVL("U"."PASSWORD"="DP"."PWD_VERIFIER") OR LNNVL("U"."NAME"="DP"."USER_NAME") OR
LNNVL("DP"."PV_TYPE"=0) OR LNNVL("U"."PASSWORD" IS NOT NULL))
这个新的底层表记录了缺省用户的缺省口令：
SQL> desc default_pwd$
名称 是否为空? 类型
----------------------------------------- -------- ----------------
USER_NAME VARCHAR2(128)
PWD_VERIFIER VARCHAR2(512)
PV_TYPE NUMBER
SQL> select * from default_pwd$ where user_name='SCOTT';
USER_NAME PWD_VERIFIER PV_TYPE
---------- ------------------------------ ----------
SCOTT F894844C34402B67 0
有了这个表之后，视图通过 u.password = dp.pwd_verifier比对就可以发现那些缺省口令了：
SQL> select text from dba_views where view_name='DBA_USERS_WITH_DEFPWD';这个关于缺省口令的改进告知我们：缺省口令是极其危险的！
TEXT
-----------------------------------------------------------------------------
SELECT DISTINCT u.name
FROM SYS.user$ u, SYS.default_pwd$ dp
WHERE
(u.type# = 1
AND bitand(u.astatus, 16) = 16
) OR
(u.type# = 1
AND u.password = dp.pwd_verifier
AND u.name = dp.user_name
AND dp.pv_type = 0)
-The End-
相关文章|Related Articles
- Oracle Database 11g Release 2 HP/AIX
- Oracle 11gR2 Solaris x86-64 发布
- Oracle 11gR2 Solaris (SPARC) (64-bit) 发布
- 11gR2新特性之- 并行DBMS_PARALLEL_EXECUTE
- Oracle 11gR2 安装初体验 - OEL + Oracle
评论数量(0)|Add Comments
本文网址：http://www.eygle.com/archives/2010/09/oracle_11g_default_pwd.html
花了点时间，终于把博客恢复得差不多了，升级WP到了最新版本。
原先被黑掉后，首页的FLAH插件不能用了，搞了一会，没成。算了，用着也不方便，一定要先在文章中添加媒体才能在首页显示。
换了另一个模版中的FLASH功能，只需要在文章中，添加自定义域：Thumbnail ，再链个图片地址就可以了，相当方便。
不过不是插件，又是从别的模版中找出来的附加上去，修改还是花了点时间。
二是，wp-postviews插件失效了，不能计数了，首页的热点文章也不能显示了。
重新下载了最新的wp-postviews，又折腾了一翻，才搞定。
参考：CosHtmlCacheXPostViews完美解决方法
首页显示也做了点修改，不再显示文章列表了。
OK了，接下来就是做好定期备份工作了，哈哈
— The End —
Amoeba for Mysql 1.3.1-BETA 版本发布：
Bug Fix：
1、主要解决 1.3.0 -BETA 版本的amoeba进程的native memory（非JVM heap）使用逐步增长(内存增加速度取决于请求量)，并且最终会导致amoeba本身无法响应、或者崩溃
请大家停止使用1.3.0-BETA版本
2010-08-31 Tue
还没有收到样书，先看一下封面吧。
另外，到今天，《Oracle DBA手记 II》也基本完成了审稿工作，基本内容确定了下来。
而且，我们开始收到越来越多的作者投稿，《Oracle DBA手记 III》也已经开始编辑，这些工作离我最初的期望越来越近，我希望能够通过不断的努力，将更多的知识、智慧汇集分享出来。
感谢朋友们，感谢分享知识的作者们！
相关文章|Related Articles
- [活动信息]-让Oracle跑得更快 读者交流会
- 从武汉到宜昌 百里长江波澜阔
- 韩国书籍《海量数据库解决方案I》校定交稿
- 关于韩国书籍《海量数据库解决方案I》的校定
- 《Oracle DBA手记》第二部启动募集中
评论数量(9)|Add Comments
本文网址：http://www.eygle.com/archives/2010/08/dbanotebook_ii.html
2010-08-30 Mon
这两天仔细阅读了Oracle Administrator Guide中关于Resource Manager的部分，基本上理清了之前我认为繁杂的概念和多个概念互相之间的关系。
在阅读的过程中，将自己认为重要的部分做了一份PPT，希望可以在下个月的ACOUG活动中跟大家分享。
在Database Consolidation时，Resource Manager可以解决我们心中的疑问，如果我将多个应用都放在同一个硬件服务器的同一个数据库中，那么如何防范互相之间的影响？另外一个更加实用且有需求的场景是在Oracle EBS中如果有大量的Report，如果设置Resource Manager来防止单个报表占用启用并行进程，占用过多CPU？
虽然在国内目前真正应用Resource Manager的客户几乎没有见到，但是我期望能够为今后我们的客户部署该项功能，资源管理在整个世界趋向虚拟化的过程中很有意义并且十分必要。
Oracle各个版本的变动还是挺大的，不管大版本和小版本每次都能够引入很多新的功能，和新的bug。这说明Oracle还在积极的invovation和customer focus.
从obsoleted和deprecated的参数就可以看到，新的来，旧的去。不变的是升级再升级。
当Instance设置了过期或旧的参数的时候，日志文件会由提示。
workarea_size_policy = “manual”
optimizer_dynamic_sampling= 2
statistics_level = “BASIC”
diagnostic_dest = “/dump/oracle”
max_dump_file_size = “4000000″
Obsolete system parameters with specified values:
mts_servers
End of obsolete system parameter listing
Deprecated system parameters with specified values:
standby_archive_dest
remote_os_authent
End of deprecated system parameter listing
Mon Aug 30 21:48:08 2010
上百个参数。
11.2.0.1.0@SQL> SELECT name FROM v$parameter WHERE isdeprecated = ‘TRUE’;
NAME
——————————————————————————–
lock_name_space
instance_groups
resource_manager_cpu_allocation
active_instance_count
buffer_pool_keep
buffer_pool_recycle
log_archive_start
standby_archive_dest
log_archive_local_first
parallel_server
parallel_server_instances
fast_start_io_target
serial_reuse
max_enabled_roles
remote_os_authent
global_context_pool_size
cursor_space_for_time
plsql_v2_compatibility
plsql_debug
background_dump_dest
user_dump_dest
commit_write
sql_trace
parallel_automatic_tuning
parallel_io_cap_enabled25 rows selected.
ORACLE@ADGLG1: SQL> select * from V$OBSOLETE_PARAMETER;
NAME ISSPE
—————————————————————- —–
spin_count FALSE
use_ism FALSE
lock_sga_areas FALSE
instance_nodeset FALSE
large_pool_min_alloc FALSE
shared_pool_reserved_min_alloc FALSE
_kspptbl_mem_usage FALSE
enqueue_resources FALSE
lgwr_io_slaves FALSE
arch_io_slaves FALSE
backup_disk_io_slaves FALSE
ops_interconnects FALSE
lm_procs FALSE
ogms_home FALSE
parallel_transaction_resource_timeout FALSE
_lm_statistics FALSE
lm_locks FALSE
lm_ress FALSE
lm_procs FALSE
_lm_multiple_receivers FALSE
_lm_direct_sends FALSE
_lm_rcv_buffer_size FALSE
_dlm_send_timeout FALSE
db_block_max_dirty_target FALSE
db_block_lru_latches FALSE
db_block_checkpoint_batch FALSE
db_block_lru_statistics FALSE
db_block_lru_extended_statistics FALSE
max_commit_propagation_delay FALSE
_compatible_no_recovery FALSE
remote_archive_enable FALSE
_log_archive_buffer_size FALSE
_average_dirties_half_life FALSE
log_block_checksum FALSE
log_small_entry_max_size FALSE
log_simultaneous_copies FALSE
log_parallelism FALSE
db_file_simultaneous_writes FALSE
log_files FALSE
_db_no_mount_lock FALSE
standby_preserves_names FALSE
gc_lck_procs FALSE
gc_releasable_locks FALSE
gc_files_to_locks FALSE
gc_latches FALSE
gc_rollback_locks FALSE
gc_defer_time FALSE
_fast_start_instance_recovery_target FALSE
freeze_DB_for_fast_instance_recovery FALSE
logmnr_max_persistent_sessions FALSE
temporary_table_locks FALSE
ddl_wait_for_locks FALSE
row_locking FALSE
serializable FALSE
delayed_logging_block_cleanouts FALSE
max_rollback_segments FALSE
transaction_auditing FALSE
cleanup_rollback_entries FALSE
undo_suppress_errors FALSE
discrete_transactions_enabled FALSE
sequence_cache_entries FALSE
sequence_cache_hash_buckets FALSE
_seq_process_cache_const FALSE
row_cache_cursors FALSE
_kgl_latch_count FALSE
text_enable FALSE
dblink_encrypt_login FALSE
distributed_transactions FALSE
max_transaction_branches FALSE
distributed_recovery_connection_hold_time FALSE
mts_dispatchers FALSE
mts_servers TRUE
mts_max_servers FALSE
mts_max_dispatchers FALSE
mts_circuits FALSE
mts_sessions FALSE
mts_service FALSE
mts_listener_address FALSE
mts_multiple_listeners FALSE
plsql_compiler_flags FALSE
plsql_native_c_compiler FALSE
plsql_native_linker FALSE
plsql_native_library_dir FALSE
plsql_native_make_utility FALSE
plsql_native_make_file_name FALSE
plsql_native_library_subdir_count FALSE
_plsql_conditional_compilation FALSE
job_queue_interval FALSE
job_queue_keep_connections FALSE
snapshot_refresh_processes FALSE
snapshot_refresh_interval FALSE
snapshot_refresh_keep_connections FALSE
parallel_default_max_instances FALSE
cache_size_threshold FALSE
parallel_server_idle_time FALSE
allow_partial_sn_results FALSE
ops_admin_group FALSE
parallel_min_message_pool FALSE
hash_join_enabled FALSE
hash_multiblock_io_count FALSE
oracle_trace_enable FALSE
oracle_trace_facility_path FALSE
oracle_trace_collection_path FALSE
oracle_trace_facility_name FALSE
oracle_trace_collection_name FALSE
oracle_trace_collection_size FALSE
_oracle_trace_events FALSE
_oracle_trace_facility_version FALSE
close_cached_open_cursors FALSE
sort_direct_writes FALSE
sort_write_buffers FALSE
sort_write_buffer_size FALSE
sort_spacemap_size FALSE
sort_read_fac FALSE
sort_multiblock_read_count FALSE
always_anti_join FALSE
partition_view_enabled FALSE
b_tree_bitmap_plans FALSE
complex_view_merging FALSE
push_join_predicate FALSE
fast_full_scan_enabled FALSE
parallel_broadcast_enabled FALSE
always_semi_join FALSE
optimizer_max_permutations FALSE
sql_version FALSE
_optimizer_choose_permutation FALSE
optimizer_percent_parallel FALSE
optimizer_search_limit FALSE
_aw_row_source_enabled FALSE
drs_start FALSE130 rows selected.
这次西藏之行，最惊心动魄的是珠峰之旅，原本没有计划去珠峰，可是在青年旅舍里，殷雨露大侠纵谈珠峰，大家的七嘴八舌成就了我们的珠峰之行。本来担心珠峰的海拔，所以先去了一趟纳木措，结果在纳木措圣湖面前，高反的一塌糊涂，基本上是慢慢踱步在湖畔。而到珠峰时，反而没有什么高原反应，只不过是晚上辗转难眠，然而为珠峰失眠，怎样都是值得的。人的一生会有几次走到这最接近天堂的距离呢？
渐渐地开始钦佩和羡慕王石。
珠峰的路途极远，往返需要4天的行程，第一天住日喀则，那里的扎什伦布寺是班禅著名的庙宇。第二天才到达定日，在经过边防检查站之后，还要走102公里的山路，没有公路，只有曲折连环的盘山道，号称102公里上有75道弯。
一路上沿着这样的盘山路蜿蜒而上：
到达珠峰大本营时雨停，天晚，漫天云雾涌起，慢慢踱步在世界屋脊，感受强劲的心跳，艰难的呼吸，辗转反侧的难以入眠，一切是那么的让人难以忘怀。
在珠峰每个人看到的景致都可能不同，惊鸿一瞥可能就是前世的因缘。不是每个朝拜者都能看到珠峰的真容，而在天宇之中，绽放可能只是转瞬。我们有幸在哪样风起云涌、高天流云之间瞥见绝世的容颜。
这不是珠峰，但是有水墨一样的风情：
在层层面纱之后，就有珠峰的倩影：
珠峰的积雪融水奔腾流淌，冰冷清冽，这来自天上之水可以睥睨天下，奔腾天下：
再看那苍茫背后隐藏着怎样的十万大山，云卷云舒之间牵动了多少攀登者的视线：
此行更大的收获是，结识了一群真挚的团友，一路之上的点滴记忆，凝成永恒，我没法描述出来，但是永记心底。
右侧的蓝衣大汉是老于，我们在定日县城捡到的团友。本来车上是满座的，结果有个小女孩在日喀则掉队，于是我们就有了一个空座。在定日吃饭时，老于闯进来搭讪问，车上还有空座不，能不能捎上我？
司机乐于添点外快，我们也不计较多一个旅伴，于是老于就加入了，豪爽的东北汉子。
掉队是珠峰形成中非常非常常见的现象，我们在饭馆里还遇到几个彪形大汉，声称高反掉队，吃在饭馆、住在饭馆楼上的客房，每天就是吃饭睡觉。任我们谁都看不出他们有任何问题。
我开玩笑说：看到他们，我开始怀疑自己正不正常。
左下角的老杨，37岁，已经从西藏退休，准备回内地老家，当后来我们从林芝深夜返回东措时，我见到老杨屹立门口，忍不住上前拥抱，有泪意湿润眼角。旅程、旅伴，别人的生活，我们的朋友，辗转之间成就的朋友友情，至此不忘。
在珠峰的帐篷里，围炉夜话，喝着酥油茶谈论前世今生，这浓浓的高原情：
想起《阿甘正传》中的一首歌，送给那一同跋涉的战友们：
How many roads must a man walk down
一个男人要走过多少条路
Before you can call him a man
你才可以称他为男人
How many seas must a white dove sail
一只白鸽要飞过多少个海面
Before she sleep in the sand
她才能在沙丘安眠
How many times must the cannonballs fly
炮弹要掠过天空多少回
Before they're forever banned
它们才被永远禁用
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
**************
How many years can a mountain exist
一座山要存在多少年
Before it is washed to the sea
它才会被冲刷到大海
How many years can some people exist
一些人要生存多少年
Before they're allowed to be free
他们才会获得自由
How many times can a man turn his head
一个人要转过多少次头
Pretend that he just doesn't see
来假装他正好没看到
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
****************
How many times must a man look up
一个人要仰望多少次
Before he can see the sky
他才可以看得见天空
How many ears must one man have
一个人要有多少只耳朵
Before he can hear people cry
他才能听到人们的哭泣
And how many deaths will it take till he knows
要有多少死亡他才会知道
Too many people are dyin'
太多的人正濒临死亡
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
How many roads must a man walk down
一个男人要走过多少条路
Before you can call him a man
你才可以称他为男人
How many seas must a white dove sail
一只白鸽要飞过多少个海面
Before she sleep in the sand
她才能在沙丘安眠
How many times must the cannonballs fly
炮弹要掠过天空多少回
Before they're forever banned
它们才被永远禁用
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
**************
How many years can a mountain exist
一座山要存在多少年
Before it is washed to the sea
它才会被冲刷到大海
How many years can some people exist
一些人要生存多少年
Before they're allowed to be free
他们才会获得自由
How many times can a man turn his head
一个人要转过多少次头
Pretend that he just doesn't see
来假装他正好没看到
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
****************
How many times must a man look up
一个人要仰望多少次
Before he can see the sky
他才可以看得见天空
How many ears must one man have
一个人要有多少只耳朵
Before he can hear people cry
他才能听到人们的哭泣
And how many deaths will it take till he knows
要有多少死亡他才会知道
Too many people are dyin'
太多的人正濒临死亡
The answer my friend is blowin' in the wind
答案啊我的朋友在风中飘摇
The answer is blowin' in the wind
答案在风中飘摇
珠峰介绍：
珠穆朗玛峰(Qomolangma)，简称珠峰，又意译作圣母峰，尼泊尔称为萨加马塔峰，也叫"埃非勒斯峰"（Everest），位于中华人民共和国和尼泊尔交界的喜马拉雅山脉之上，终年积雪。高度8844.43米，为世界第一高峰，中国最美的、令人震撼的十大名山之一。
珠峰不仅巍峨宏大，而且气势磅礴。在它周围20公里的范围内，群峰林立，山峦叠障。仅海拔7000米以上的高峰就有40多座，较著名的有南面3公里处的"洛子峰"（海拔8463米，世界第四高峰）和海拔7589米的卓穷峰，东南面是马卡鲁峰（海拔8463米，世界第五高峰） ，北面3公里是海拔7543米的章子峰 ，西面是努子峰（7855米）和普莫里峰（7145米）。在这些巨峰的外围 ，还有一些世界一流的高峰遥遥相望：东南方向有世界第三高峰干城嘉峰（海拔8585米，尼泊尔和锡金的界峰）；西面有海拔7998米的格重康峰、8201米的卓奥友峰和 8012米的希夏邦马峰。形成了群峰来朝，峰头汹涌的波澜壮阔的场面。
相关文章|Related Articles
评论数量(6)|Add Comments
本文网址：http://www.eygle.com/archives/2010/08/qomolangma_everest.html
讲座主题：让Oracle跑得更快
时间：2010年9月5日下午14:00~16:00
地点：西单图书大厦4层大向艺术馆
主讲人：谭怀远
主讲内容：
1、主要内容:
为什么要进行数据库性能优化
性能优化在软件开发中的地位-贯穿于开发的各个阶段
性能优化和开发人员及DBA的关系
Oracle数据库性能优化的误区
Oracle性能优化的主要内容
性能优化的手段--工具
如何学好Oracle
2、读者自由提问及交流互动
3、抽奖
4、签售《让Oracle跑得更快----Oracle 10g性能分析与优化思路》
链接：http://www.broadview.com.cn/dajiangtang/second-/36/djt36.html
相关文章|Related Articles
- 《Oracle DBA手记》的之I 与之 II
- 从武汉到宜昌 百里长江波澜阔
- 韩国书籍《海量数据库解决方案I》校定交稿
- 关于韩国书籍《海量数据库解决方案I》的校定
- 《Oracle DBA手记》第二部启动募集中
评论数量(1)|Add Comments
本文网址：http://www.eygle.com/archives/2010/08/runing_faster.html
2010-08-29 Sun
墨墨很乖，老师拉着他的手走进教室，他头也不回的走过去，高高兴兴的上学去了，只是不知道这一天他会过得如何？会不会想家哭泣呢？
妈妈记录的墨墨趣事：
墨墨说：我长大了，你还能抱动我不？
我说：能，你长的得和我一样大，爸爸也抱得动你。
墨墨说：我长大了，咱们买个车开吧。
我说：买什么车？
墨墨说：买个大巴车吧。
我：-_-'''
愿儿子能健康茁壮的在幼儿园成长。
相关文章|Related Articles
评论数量(2)|Add Comments
2010-08-28 Sat
参加工作的人, 都会对学习与成长有一定的困惑, 在某个特定的时期还可能困于其中, 这些都是正常的. 昨天和一个工作一年的DBA同事去聊天, 刚好他有这个疑问, 于时就和他说了一下我的感觉.
成长中最大的困惑来自于取舍不定, 8月25日技术部的半年会和8月26日公司的半年会中, 我看着年轻人在舞台上表演, 非常地有才, 心里很有冲动, 要去学一学, 找他们比一比. 不过等节目过后没有多久, 我突然明白过来, 本质上我是想和他们比年轻, 而这个是比不过的, 比他们大了一轮, 是铁定的事实, 所以我没有为此感到烦恼, 在心中将这个目标轻轻地放下了. 看见有的DBA很历害, 做得非常好, 就要去学习, 会因为一年内没有跟上而伤神; 看见有的SA对底层很了解, 就要去学习, 会因为一年内没有跟上而忧郁. 世间美好的事或者人实在太多了, 更何况要在一年就与他们端平呢? 拿我自已来讲, 在工作了十年后, 才对Oracle有些感觉, 也只是不管遇到什么问题, 都可以找到思路的感觉, 但他只工作了一年, 就要得到这么多, 非得和其他比, 精神可嘉, 陷于其中就不好了.
昨天我故意选择了在爬山时去讨论这个问题, 从西湖边上的老和山出发, 一开始没有定目标. 在刚上山时, 大一轮的我直喘气, 而他却闲庭信步一样. 到北高峰时, 我注意到他也开始有些喘气了, 我选择了继续走. 大部份人只走到北高峰, 很少人再向前走的, 从山上向下看, 向杭州城的西看, 很美, 除了空气不够通透. 在那一段路上, 同事感觉是走得比较累的, 走过了最困难的一段下坡后, 我让他回头看看, 并问他从老和山要来到这里, 有什么好方法？ 从山上过来, 只有一步一个脚印地过来, 好象没有其他方法, 我们也就两个小时多一点, 就到了这里, 一步一个脚印好象也不慢啊, 而且一路上的感觉很好. 在学习与工作上又何曾不是如此呢？在爬山时一步一步走, 我们领略了很多风景, 但学习上你正在一步一步走时, 却产生了很多疑惑.
看书是学习的重要手段, 但工作后经常觉得没有时间看书, 或者是看书能起的作用越来越少. 对于前一点, 我们知道在学校时, 经常是考试前几天突击的, 这样也能过了考试, 但工作中这种方式看书对工作是没有什么帮助的, 现在来讲考试中的题目是比较固定的, 而工作中遇到的问题是不固定的, 因此看书应当象上面那样一步一步地看, 但要不停地去看去慢慢理解. 其实我问同事, 你一本书看多少次? 他告诉我只看了一篇, 如果说看一篇就想全部用出书中的, 那每个人读完高中读完大学后就已经足够他用一生了, 工作中就不要再看书了. 其实第一次看时, 实在搞不明白的就先跳过去吧, 象恋爱, 没有人能肯定第一次失败后, 第二次一定能成功, 也就是光学习一次是不够的. 才看了一两次书, 就为无所得而烦恼, 实在不需要.
年轻人的事情, 应当多找找年轻人去聊聊, 在一个公司大家既是朋友也是战友, 既然是战友, 肯定要谈战, 因此在外面活动时谈谈工作也很正常, 而且一定要谈, 同战友一起谈大家一起进步.
Relative Posts:
- 【喷嚏】人民和人民公仆今晚一群亲戚再次动员我入党考公务员，我说我不干我不想作为人民公仆骑在人民的头上。然后妈妈在回家的路上幽怨叹息：“你个中文专业的，除了当公务员就是当高素质小蜜吧，你不是骑在人民的头上就是被人民公仆骑在身上～孩子啊。”打喷嚏链接：http://www.dapenti.com..
- 看别人相亲一定要淡定今天中午在公司旁边吃饭，旁边桌好像是在相亲，据言论猜测，女方人员两位，相亲女和其娃娃脸叔叔，男方人员三人，相亲男，相亲男哥哥协同夫人。背景就这些。 相亲女长得不错，很傲气，对相亲男要求颇多，什么有车有房，什么不许抽烟喝酒，什么不习惯和老人相处……总..
- 学习与成长的困惑Shared by orczhou 人生也如登山，方向认定了，剩下的就是朝前走 参加工作的人, 都会对学习与成长有一定的困惑, 在某个特定的时期还可能困于其中, 这些都是正常的. 昨天和一个工作一年的DBA同事去聊天, 刚好他有这个疑问, 于时就和他说了一下我的感觉. ..
- 百度的分布式数据库"中间代理控制层"其实和Amoeba的当年的原理，构想非常类似，只可惜没有多少人对Amoeba这个开源产品投入多少贡献。 #
- 腾讯的运维自动化确实做的挺不错了，只是早上听了他们的分享后，很迷糊他们运维和运营的关系 #
- 这位兄弟NB RT @hutuworm 我们这里最多是对着服务器尿尿。 RT @songma: RT @solidot: 喝醉的雇员朝服务器开火: 美国盐湖城一家抵押公司的一位雇员在喝醉酒后，莫名其妙的掏出一把.45口径自动枪，朝着该公司价值10万美元的服务器开火 #
- 准备试一下新浪微博，看看用着怎么样，常用的sky000居然已经被人抢注了，那就用中文名玩玩吧: @简朝阳 #
- 偶也计划找时间去玩一玩 @eygle 西藏之行，拉萨印象 http://www.eygle.com/archives/2010/08/first_day_lhasa.html #
- @sdh5724 哈哈，应该很有戏 in reply to sdh5724 #
Powered by Twitter Tools
作者： Sky.Jian 发布在：www.jianzhaoyang.com 欢迎 订阅本站Feed
Copyright © 2004-2008， 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接：http://isky000.com/sky-on-twitter/twitter-%e4%b8%80%e5%91%a8-for-2010-08-29 )
No related posts.
