2009-07-04 Sat
2009-07-03 Fri
作者：Fenng 发布在 dbanotes.net. 
在我看来，如果要评选一个IM 工具的功能"更影响沟通的有效性、更能浪费生产力" 的话，恐怕非"群"莫属。
昨天在 Twitter 上发了一句对"群"这个玩意儿的牢骚，引来了不少朋友的回复，大部分朋友对"群"还是深恶痛绝的，云风随后写了一篇《关于"群"的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。
经常看到有讨论技术的人会开很多 QQ 群，然后一大堆人加入，我最不屑这样的讨论技术的方式，我不相信有谁通过 IM 群学会了很多东西，当然，他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说：
"喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群，认为那东西理所当然的是"好"的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。"
这样的说法如果也在内部会议上提出的话，估计也要像 Tim Yang 那样遭受一片嘘声。（我不排除有人把"群"用的出神入化，比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例，但这只是个例）。Twitter 上就有不少人不同意我的说法：
"吾之蜜糖彼之砒霜，QQ 群用的人那么多，凭什么说人家烂？不适合罢了"
也有朋友给出了建议:
现在的群，如果非要继续沿用的话，改进的余地还有很大。产品经理请注意，下面是可以给你带来业绩的地方：学习 Twitter 风格的对话模式，针对每一条信息有上下文，便于群内的参与者能够知道信息的指向(这是非常关键的一点，否则就是乱七八糟胡乱抢话筒的会议而已)。第二，设计一个可以将"会议"记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?
欣喜的看到网易已经用不许员工上班时间用群了，这是个伟大的决定。
--EOF--
（注：众多推友对此文亦有贡献)
相关文章|Related Articles
- 即时通信软件的互联互通 - Jul 13, 2006
- 卓越(Joyo)与 Amazon 接轨后的'智能' - Oct 8, 2006
- 阿里旺旺推出正式版 - Mar 1, 2007
- 修改 Windows Live Messenger 英文版的字体 - Mar 28, 2007
评论数(6)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/techmemo/im_groups.html
DBA Notes 理念: 用简约的技术取得最大的收益...
11G standby提供了real time query的功能，通过这个功能，我们可以结合lgwr+async来做到实时standby查询，
给我们做读写分离提供了遐想空间，最近和老郑测试了下这个功能的实时性，希望对大家有所帮助
测试环境：
redhat linux as 4.7(64bit)
11.1.0.7.0 lgwr + async 20480 + real time query
主库：10组512M的联机日志
备库：11组512M的standby logfile
测试方法：
循环插入记录，为了增大日志量，起了6个进程，插入test1-test6
declare v_counter pls_integer := 0;
begin
for i in 1..100000000 loop
insert into $1 (id,mdate,mm) values(i,sysdate,’wo shi ni ba’);
v_counter := v_counter + 1;
if v_counter = 10 then
commit;
v_counter := 0;
end if;
end loop;
end;
/
以表test1为参考，每隔1秒查询主库和备库的最大ID，还有插入的时间，如果是完全实时，这两个数值应该相等，
通过两边的max(id)和maxid对应的时间，可以看出real time query的延迟，采样结果保存于rquery_time表
测试的日志量大家可以自己加压设置，本次测试日志量是37M/S,让我有点吃惊，但多次statspack统计的结果和日志切换的频率计算，
就是如此
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ —————— —————– ———– ———–
DB time(s): 3.1 0.0 0.00 6.78
DB CPU(s): 3.0 0.0 0.00 6.65
Redo size: 37,575,874.7 5,286.1
Logical reads: 312,674.9 44.0
Block changes: 303,749.8 42.7
Physical reads: 8.4 0.0
Physical writes: 2,256.8 0.3
User calls: 0.5 0.0
Parses: 4.1 0.0
Hard parses: 0.5 0.0
W/A MB processed: 0.0 0.0
Logons: 0.0 0.0
Executes: 71,089.5 10.0
Rollbacks: 0.0 0.0
Transactions: 7,108.4
declare v_max_stb pls_integer := 0;
v_max_pri pls_integer := 0;
v_date_stb date;
v_date_pri date;
begin
for x in 1..1000000 loop
–获取主库最大ID，最大时间
select max(id) into v_max_pri from test1;
select mdate into v_date_pri from test1 where id = v_max_pri;
–获取备库最大ID，最大时间
select max(id) into v_max_stb from test1@ctrdmsb;
select mdate into v_date_stb from test1@ctrdmsb where id = v_max_stb;
–保存结果
insert into rquery_time
(primary_max_id,standby_max_id,primary_time,standby_time)
values
(v_max_pri,v_max_stb,v_date_pri,v_date_stb);
commit;
–get sleep
dbms_lock.sleep(1);
end loop;
end;
/
–查询结果
select PRIMARY_MAX_ID - STANDBY_MAX_ID as max_deff,(PRIMARY_Time - standby_Time) * 24 * 3600 as time_deff
from rquery_time
order by PRIMARY_MAX_ID;
MAX_DEFF TIME_DEFF
———- ———-
8460 0
4720 0
5360 1
4770 1
4950 0
4240 0
5240 0
6300 1
5040 0
4680 1
两边相差大概5000笔记录，时间延迟在1秒不到的样子，对于37M/S的日志量来说，这个实时性是相当高了
当然备库是否应用跟得上主库，还要看IO的类型和存储的能力，网络传输量，具体环境具体测试
不过使用lgwr+standby logfile传输日志，对于数据的保护理论上只会丢一个async buffer的日志，但实际测试起来，结果会大跌眼镜，
特别是standby机器性能不是很好的情况下很容易发生丢几组日志
我们在32位的AS 4.4上测试出了这个情况，并且可以多次重现
备库跟不上主库的节奏，当前standby logfile 541中的日志还没有全部应用到数据文件，主库已经切换了多次日志
这些日志会以archive log的方式传到备库（如果备库的standby logfile足够的话，会直接使用standby logfile），
如果此时主库突然crash,备库的情况就是
541 standby logfile
542 archive log
543 archive log
理论上可以recover standby database until cancel;然后依次指定上面的文件，但在应用541 standby logfile时，
会遇到非常扯淡的错误(经过旺旺同学解释，数据库是最大性能模式，主库不能保证日志的完全写入，所以是corrupt)：
SQL> recover standby database until cancel;
ORA-00279: change 25661117 generated at 07/02/2009 23:38:00 needed for thread 1
ORA-00289: suggestion : /data/oradata/arch/ctrdmsb/ctrdm_1_541_690507562.arc
ORA-00280: change 25661117 for thread 1 is in sequence #541
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DG1/ctrdmsb/redosb_3_1.log
ORA-00283: recovery session canceled due to errors
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 421143 change 25661598 time 07/02/2009 23:38:01
ORA-00334: archived log: ‘+DG1/ctrdmsb/redosb_3_1.log’
ORA-01112: media recovery not started
主库意外终止后，oracle会认为当前standby logfile是不可用的，这样会导致后面的两个归档根本没法应用，损失是非常大的
最近又热播了一出战争题材的连续据，我的兄弟叫顺溜，风格和”我的团长我的团”类似，嬉笑怒骂型的战争戏剧。王宝强在里面主演神枪手陈二雷。演得还不错，王宝强在战争片里面是大有突破，游刃有余。推荐每晚追看。
最近国内再次上调石油价格，这样可以或多或少的减少石油消费，从而减少排气量，对气温和环境有好处。我是大大支持的。持续的高温实在让人憋闷。我没有车，不骂娘。
传统中国有崇拜乡贤的习惯，特别是明朝以后。原因比较复杂，但其中有一点是明确的，就是借乡贤来证明本乡之“人杰地灵”。而到了近代，纯粹的文化和精神崇拜虽然淡化了，但因旅游开发之需要，对乡贤的挖掘和宣传却更加重视了，有的甚至到了你抢我夺的程度，背后则是地方利益的赤裸之争。比如说朱熹，他到底算哪里人呢？
首先是福建人说朱熹是福建人，理由很简单，似乎也很硬气，朱熹生于斯，长于斯，死于斯，而且在福建境内还有他的遗迹，所以认定朱熹是福建人还真不是瞎说，于是，他们便在武夷山修建了一个朱熹纪念馆，不知道的还以为是朱熹故居。
可传统中国对籍贯的理解，却不是根据出生地原则，而是依据祖籍来定的。朱熹的父亲和爷爷是都是婺源人，朱熹的父亲去福建当官，他妈妈也跟着去了，于是就在福建生下了朱熹。因此，怎么可以说朱熹是福建人呢？司徒雷登的出生地是杭州，难道能说这个美国大使是杭州人？朱熹当然也不会认为自己是福建人，否则岂不是忘祖了？著书写文章的时候，他一直喜欢用“新安朱熹”来署名，新安，即北宋时候的婺源。婺源县今属江西，所以，江西人自然认为朱熹是江西人了，而从文化的角度去解释，似乎也能通，朱熹的学术和所谓的江西理学有着密切的关系，庐山的白鹿洞书院就是因为朱熹而久负盛名。
可是，说朱熹是江西人，第一个反对的，并不是福建人，而是安徽人。因为既然说到朱熹是婺源人，那么他就应该是安徽人。因为历史上的婺源，一直是安徽徽州下面的一个县，历史上的徽州“一府六县”，婺源就是其中之一，这一行政建制延续了近千年，它是徽文化不可分割的一个重要组成部分。民国时期，蒋介石为了“剿共”曾把婺源划拨给江西，却遭到了包括婺源人在内的广大安徽人的极力反对，结果抗议了十多年，最后又不得不把婺源归还给了安徽，这就是历史上著名的“婺人返皖”运动。为此，同样是安徽人的胡适曾说，婺源之于安徽犹如曲阜之于山东，盖因婺源有朱熹，曲阜有孔子。没有了朱熹，也就无所谓徽文化了。但没有想到，新中国成立后，同样因为军事的需要，政府再次把婺源划给了江西，虽然徽人还是觉得很伤心，仿佛手足失离，可再也没了声音，因为作为整体的徽文化确实不如以前了，更因为当初像胡适那样的人已经说不上话了，而到了今天，即便出了国家领导人，也不好再说什么了。但对于朱熹，他们还是认为他是安徽人。
然而，就像前面说的，徽文化早已经衰落，甚至作为地名的徽州也已经不再存在，原先的徽州地区硬是被一帮没有文化的安徽人改名为“黄山市”，所以，再说朱熹是安徽人，徽州人，多少有点尴尬。于是，一些江苏人跳了出来，就像当年朱元璋说自己是江苏人一样，经过他们的考证，朱熹爷爷的祖籍居然是苏州人，而朱熹也曾把自己叫做“吴徽朱熹”。
宋朝的时候，中国还没有省的建制，今人所说的江苏，安徽，江西，福建，都是清朝以后才有的行政概念。所以，即便是朱熹还活着，估计他也不知道自己是哪个省的人。所以，若是有人问起朱熹是哪里人？答，你们那边人！
当年声势浩大的“婺人回皖”运动的图片
凡是8知道谁干滴，
都素熊总干滴。
比如床单脏鸟，
比如鞋鞋8见鸟，
比如上海楼倒，
比如倪萍当贵报副主编……
...
2009-07-02 Thu
作者：Fenng 发布在 dbanotes.net.
去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。
在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。
随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。
根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。
这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。
--EOF--
相关文章|Related Articles
- Oracle 10g XE 的字符集问题 - Jan 23, 2006
- Oracle XE 自带的数据库如何创建的? - Jan 24, 2006
- 重要图书: MySQL Stored Procedure Programming - Apr 10, 2006
- 代寻《Database In Depth》的技术审校 - Oct 12, 2006
评论数(5)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/arch/five-minute_rule.html
DBA Notes 理念: 用简约的技术取得最大的收益...
而实际上大家也发现，从Oracle10g开始，Redo Log Buffer缺省的已经是大大超过了原来的想象。
从Oracle 9i引入了Granule的概念后，在Oracle10g中，Oracle的内存分配会为'Fixed SGA Size'和'Redo Buffers'共享整数倍个Granule。
看看不同SGA设置下的内存分配情况：
SQL> select * from v$version;在另外的系统中，供分配了2个Granule，每个4M：
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1267212 No
Redo Buffers 15507456 No
Granule Size 16777216 No
SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');
SUM(BYTES)/1024/1024
--------------------
15.99757
SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');摘录一部分Oracle文档中关于Granule的描述供参考：
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1263320 No
Redo Buffers 7122944 No
Granule Size 4194304 No
SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');
SUM(BYTES)/1024/1024
--------------------
7.99776459
With dynamic SGA, the unit of allocation is called a granule. Components, such as the buffer cache, the shared pool, the java pool, and the large pool, allocate and free SGA space in units of granules. Oracle tracks SGA memory use in integral numbers of granules, by SGA component. All information about a granule is stored in a corresponding granule entry. Oracle maintains the state of each granule in the granule entry and the granule type.
Granule size is determined by total SGA size. On most platforms, the size of a granule is 4 MB if the total SGA size is less than 128 MB, and it is 16 MB for larger SGAs. There may be some platform dependency, for example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 128 MB.
The granule size that is currently being used for SGA can be viewed in the view
V$SGA_DYNAMIC_COMPONENTS. The same granule size is used for all dynamic components in the SGA.Oracle keeps information about the components and their granules in a scoreboard. For each component that owns granules, the scoreboard contains the number of granules allocated to the component, any pending operations against this component, the target size in granules, and the progress made toward the target size. The start time of the operation is also logged. Oracle maintains the initial number of granules and the maximum number of granules for each component.
For operations that modify the number of granules, Oracle logs the operation, the target size, and the start time to the appropriate SGA component in the scoreboard. Oracle updates the progress field until the operation is complete. When the operation is complete, Oracle replaces the current size with the target size and clears the target size field and the progress field. At the end of the operation, a database administrator can see how the number of granules was changed. Oracle updates the initialization parameter values to reflect the updated amount of SGA in use.
Oracle maintains a circular buffer of the last 100 operations made to the scoreboard. Fixed views show the state of the scoreboard and the current contents of last 100 operations to the scoreboard.
Allocating Granules at Startup
At startup, Oracle reads the values in the initialization parameter file, queries the operating system memory limits, and allocates virtual address space for the SGA. The initialization parameter
SGA_MAX_SIZEspecifies the maximum size of the SGA for the life of the instance in bytes. Its value is rounded up to the next granule size.Adding Granules to Components
A database administrator grows a component's SGA use with
ALTERSYSTEMstatements to modify the initialization parameter values. Oracle takes the new size, rounds it up to the nearest multiple of 16MB, and adds or takes away granules to meet the target size. Oracle must have enough free granules to satisfy the request. If the current amount of SGA memory is less thanSGA_MAX_SIZE, then Oracle can allocate more granules until the SGA size reachesSGA_MAX_SIZE.
相关文章|Related Articles
- 关于Oracle归档进程的运行机制
- 关于Oracle归档进程的运行机制
- 关于《深入浅出Oracle》中granule的补充
- 设置ARCHIVE_LAG_TARGET 强制日志切换
- 磁盘IO故障 导致Redo损坏一例
评论数量(0)|Add Comments
本文网址：http://www.eygle.com/archives/2009/07/granule_log_buffer.html
