eygle.com   eygle.com
eygle.com  
 
本站推荐: 传说中的彼岸花-彼岸花..开彼岸...
Today | 07/03 | 07/02 | 07/01 | 06/30 | 06/29 | 06/28 | 06/27 | 06/26 | 06/25 | 06/24
 123
 123

  2009-07-04 Sat

03:07 以实际行动支持山寨 (245 Bytes) » 我呸
8知道谁做滴milkdog
那砣
可怜的迈克尔 杰克逊 就这样走鸟。
留下好多财产~~~”
又很鬼牛逼啵~~
...

  2009-07-03 Fri

13:10 关于 IM 工具的"群" (5239 Bytes) » DBA notes

作者:Fenng 发布在 dbanotes.net. BLOG 墙外订阅数量,点击则可进行订阅

在我看来,如果要评选一个IM 工具的功能"更影响沟通的有效性、更能浪费生产力" 的话,恐怕非"群"莫属。

昨天在 Twitter 上发了一句对"群"这个玩意儿的牢骚,引来了不少朋友的回复,大部分朋友对"群"还是深恶痛绝的,云风随后写了一篇《关于"群"的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。

经常看到有讨论技术的人会开很多 QQ 群,然后一大堆人加入,我最不屑这样的讨论技术的方式,我不相信有谁通过 IM 群学会了很多东西,当然,他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说:

"喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群,认为那东西理所当然的是"好"的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。"

这样的说法如果也在内部会议上提出的话,估计也要像 Tim Yang 那样遭受一片嘘声。(我不排除有人把"群"用的出神入化,比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例,但这只是个例)。Twitter 上就有不少人不同意我的说法:

"吾之蜜糖彼之砒霜,QQ 群用的人那么多,凭什么说人家烂?不适合罢了"

也有朋友给出了建议:

  • 建议用临时会话,说完正事就退出。(refer)
  • 群的成员不应该是固定的。(refer)
  • 做个Twitter进化的桌面IM...

现在的群,如果非要继续沿用的话,改进的余地还有很大。产品经理请注意,下面是可以给你带来业绩的地方:学习 Twitter 风格的对话模式,针对每一条信息有上下文,便于群内的参与者能够知道信息的指向(这是非常关键的一点,否则就是乱七八糟胡乱抢话筒的会议而已)。第二,设计一个可以将"会议"记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?

欣喜的看到网易已经用不许员工上班时间用群了,这是个伟大的决定。

--EOF--

(注:众多推友对此文亦有贡献)


相关文章|Related Articles

评论数(6)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:

DBA Notes 理念: 用简约的技术取得最大的收益...

11:51 11G real time query (7603 Bytes) » Alibaba DBA Team

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是不可用的,这样会导致后面的两个归档根本没法应用,损失是非常大的

11:25 陈二雷 (570 Bytes) » 玉面飞龙的BLOG

最近又热播了一出战争题材的连续据,我的兄弟叫顺溜,风格和”我的团长我的团”类似,嬉笑怒骂型的战争戏剧。王宝强在里面主演神枪手陈二雷。演得还不错,王宝强在战争片里面是大有突破,游刃有余。推荐每晚追看。

最近国内再次上调石油价格,这样可以或多或少的减少石油消费,从而减少排气量,对气温和环境有好处。我是大大支持的。持续的高温实在让人憋闷。我没有车,不骂娘。

08:57 松了一口气 (340 Bytes) » Julia----瞬间与记忆在此过渡。。。。。。
 
晚了整整一个月,还以为小妹妹出现了,害怕却隐隐约约有点愉悦。
 
曾经问盖小咪:你想要一个小妹妹吗?
 
盖小咪很小声地说:不想,不要,不要小妹妹......
 
 
 
 
03:33 据说朱熹是你们那边人 (4267 Bytes) » 木木:木有书读

传统中国有崇拜乡贤的习惯,特别是明朝以后。原因比较复杂,但其中有一点是明确的,就是借乡贤来证明本乡之“人杰地灵”。而到了近代,纯粹的文化和精神崇拜虽然淡化了,但因旅游开发之需要,对乡贤的挖掘和宣传却更加重视了,有的甚至到了你抢我夺的程度,背后则是地方利益的赤裸之争。比如说朱熹,他到底算哪里人呢?

首先是福建人说朱熹是福建人,理由很简单,似乎也很硬气,朱熹生于斯,长于斯,死于斯,而且在福建境内还有他的遗迹,所以认定朱熹是福建人还真不是瞎说,于是,他们便在武夷山修建了一个朱熹纪念馆,不知道的还以为是朱熹故居。

可传统中国对籍贯的理解,却不是根据出生地原则,而是依据祖籍来定的。朱熹的父亲和爷爷是都是婺源人,朱熹的父亲去福建当官,他妈妈也跟着去了,于是就在福建生下了朱熹。因此,怎么可以说朱熹是福建人呢?司徒雷登的出生地是杭州,难道能说这个美国大使是杭州人?朱熹当然也不会认为自己是福建人,否则岂不是忘祖了?著书写文章的时候,他一直喜欢用“新安朱熹”来署名,新安,即北宋时候的婺源。婺源县今属江西,所以,江西人自然认为朱熹是江西人了,而从文化的角度去解释,似乎也能通,朱熹的学术和所谓的江西理学有着密切的关系,庐山的白鹿洞书院就是因为朱熹而久负盛名。

可是,说朱熹是江西人,第一个反对的,并不是福建人,而是安徽人。因为既然说到朱熹是婺源人,那么他就应该是安徽人。因为历史上的婺源,一直是安徽徽州下面的一个县,历史上的徽州“一府六县”,婺源就是其中之一,这一行政建制延续了近千年,它是徽文化不可分割的一个重要组成部分。民国时期,蒋介石为了“剿共”曾把婺源划拨给江西,却遭到了包括婺源人在内的广大安徽人的极力反对,结果抗议了十多年,最后又不得不把婺源归还给了安徽,这就是历史上著名的“婺人返皖”运动。为此,同样是安徽人的胡适曾说,婺源之于安徽犹如曲阜之于山东,盖因婺源有朱熹,曲阜有孔子。没有了朱熹,也就无所谓徽文化了。但没有想到,新中国成立后,同样因为军事的需要,政府再次把婺源划给了江西,虽然徽人还是觉得很伤心,仿佛手足失离,可再也没了声音,因为作为整体的徽文化确实不如以前了,更因为当初像胡适那样的人已经说不上话了,而到了今天,即便出了国家领导人,也不好再说什么了。但对于朱熹,他们还是认为他是安徽人。

然而,就像前面说的,徽文化早已经衰落,甚至作为地名的徽州也已经不再存在,原先的徽州地区硬是被一帮没有文化的安徽人改名为“黄山市”,所以,再说朱熹是安徽人,徽州人,多少有点尴尬。于是,一些江苏人跳了出来,就像当年朱元璋说自己是江苏人一样,经过他们的考证,朱熹爷爷的祖籍居然是苏州人,而朱熹也曾把自己叫做“吴徽朱熹”。

宋朝的时候,中国还没有省的建制,今人所说的江苏,安徽,江西,福建,都是清朝以后才有的行政概念。所以,即便是朱熹还活着,估计他也不知道自己是哪个省的人。所以,若是有人问起朱熹是哪里人?答,你们那边人!

当年声势浩大的“婺人回皖”运动的图片

 

02:07 “都素熊总干滴”小组 (344 Bytes) » 我呸
全家投票一致通过
凡是8知道谁干滴,
都素熊总干滴。

比如床单脏鸟,
比如鞋鞋8见鸟,
比如上海楼倒,
比如倪萍当贵报副主编……
 
 ...

  2009-07-02 Thu

19:49 关于 I/O 的五分钟法则(Five-Minute Rule) (5053 Bytes) » DBA notes

作者:Fenng 发布在 dbanotes.net. BLOG 墙外订阅数量,点击则可进行订阅

去年在对 SSD 做调查的时候就关注过这个五分钟法则,今天又发现了这篇文章的修订版(为了纪念 Jim Gray),这个话题倒是可以简单介绍一下,对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年,Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

graefe_table3.gif

随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。

根据数据结构和数据特点的不同,对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库,倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以,建议读一下原文),其中对于数据库一节的描述尤其有趣(针对 DB 也有个五分钟)。限于篇幅,就不罗嗦了。

--EOF--


相关文章|Related Articles

评论数(5)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:

DBA Notes 理念: 用简约的技术取得最大的收益...

17:21 《把时间当作朋友》海报 (775 Bytes) » 车东[Blog^2]

车东@FlickR posted a photo:

《把时间当作朋友》海报

粥粥专门为笑来新书做的海报,很有创意哟;
www.douban.com/subject/3609132/
利用心智 获得解放

11:49 Granule 与 Redo Log Buffer (log_buffer) 的关系 (10312 Bytes) » Oracle Life

©作者:eygle 发布在 eygle.com

不少朋友一直记得以前的优化推荐:Redo Log Buffer不要高于3M。

而实际上大家也发现,从Oracle10g开始,Redo Log Buffer缺省的已经是大大超过了原来的想象。
从Oracle 9i引入了Granule的概念后,在Oracle10g中,Oracle的内存分配会为'Fixed SGA Size'和'Redo Buffers'共享整数倍个Granule。

看看不同SGA设置下的内存分配情况:

SQL> select * from v$version;

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
在另外的系统中,供分配了2个Granule,每个4M:
SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');

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
摘录一部分Oracle文档中关于Granule的描述供参考:

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.


Note:

If you specify a size for a component that is not a multiple of granule size, then Oracle rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB.


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_SIZE specifies 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 ALTER SYSTEM statements 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 than SGA_MAX_SIZE, then Oracle can allocate more granules until the SGA size reaches SGA_MAX_SIZE.


相关文章|Related Articles

评论数量(0)|Add Comments

本文网址:

09:18 母亲的爱 » Julia----瞬间与记忆在此过渡。。。。。。

  2009-07-01 Wed

22:12 今天提车了 » 人生就是如此
12:31 涂指甲油 » Julia----瞬间与记忆在此过渡。。。。。。

  2009-06-30 Tue

08:52 大小咪的爱 » Julia----瞬间与记忆在此过渡。。。。。。
07:35 DataReport的数据共享改进 » AnySQL.net

  2009-06-29 Mon

21:06 初夏的午后 » 柔嘉维则@life.oracle.eng

  2009-06-28 Sun

22:46 周末Papa John » Julia----瞬间与记忆在此过渡。。。。。。