支付宝在培养工程师方面也有自己的特色，尤其是在技术部，设立了一个培训项目“黄埔军校”，通过该军校已经为中国的电子支付产业培养了不少的技术中坚力量，也正是这个“军校”保证了支付宝在快速发展中的技术优势。

“黄埔军校”是面向P5以上的技术人员推出系列课程，而讲师则来自P7及以上的员工包括高级主管以及外部的讲师等，例如支付宝首席架构师–程立，支付宝的“大师”–冯春培等人，都是军校的讲师。

主要通过“黄埔夜话”（每月一期）和“黄埔进阶”（两周一期）的形式进行技术沟通交流，员工可以根据自己不同的层级选择适合自己学习的套餐，自主制定每年的学习计划。
学习内容：
1、黄埔技术进阶培训（专业技术类）：SOA基础, 领域建模, 非功能设计, 分布式系统设计, 性能分析, 项目进度/变更/风险管理……
2、黄埔夜话（通用技能类）：影响力，沟通技巧，时间管理，网络时代的持续学习……

我们希望有更多的工程师能一起参与我们的“黄埔军校”，不管是作为讲授者还是学习者。具体可以参见2010年支付宝春季招聘之工程师篇，或者支付宝招聘。

No related posts.

Upgrading to 11g Release Grid Infrastructure? You probably want to read on…

Oracle 11g Release 2 Grid Infrastructure has been dramatically redesigned compare to 10g and 11gR1 Clusterware. Coming with impressive set of new features, Grid Infrastructure also uses much more memory. While RAM is rather inexpensive these days, it does pose an inconvenience in some scenarios. Particularly, for sand-box type installations that I use all the time for my own tests and demonstrations. For production upgrades, you need to be aware of and plan for increased memory usage.

I’ve been able to easily run a 2 node 10g RAC cluster on my MacBook with 4 GB of RAM allocating less than 1 GB of RAM to each virtual machine. That was even enough for a mini database instance with a very small memory footprint. Oracle 11g Release 1 was pretty much the same except maybe the database instance itself required a bit more memory but one node could still fit within 1 GB of RAM.

In 11gR2, bare-bone Grid Infrastructure processes alone consume 10+ times more memory (11.2.0.1 on 32 bit Linux to be precise):

[gorby@cheese1 ~]$ ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e grid -e ohasd | grep -v grep
  PID %MEM   RSS USER     CMD
 3614  0.0  1080 root     /bin/sh /etc/init.d/init.ohasd run
 4322  0.2  3368 oracle   /nfs/11.2.0/grid/opmn/bin/ons -d
 4323  0.4  5164 oracle   /nfs/11.2.0/grid/opmn/bin/ons -d
 4117  0.6  7860 root     /nfs/11.2.0/grid/bin/oclskd.bin
 3830  0.6  8788 oracle   /nfs/11.2.0/grid/bin/gipcd.bin
 5048  0.7  8992 oracle   /nfs/11.2.0/grid/bin/tnslsnr LISTENER -inherit
 4167  0.7 10052 oracle   /nfs/11.2.0/grid/bin/evmlogger.bin -o /nfs/11.2.0/grid/evm/log/evmlogger.i
 3969  0.9 12412 oracle   /nfs/11.2.0/grid/bin/diskmon.bin -d -f
 3860  0.9 12736 oracle   /nfs/11.2.0/grid/bin/mdnsd.bin
 4067  1.1 14648 root     /nfs/11.2.0/grid/bin/octssd.bin reboot
 5016  1.2 15860 root     /nfs/11.2.0/grid/bin/orarootagent.bin
 3956  1.3 16964 root     /nfs/11.2.0/grid/bin/orarootagent.bin
 4292  1.4 17984 oracle   /nfs/11.2.0/grid/bin/oraagent.bin
 3874  1.5 20112 oracle   /nfs/11.2.0/grid/bin/gpnpd.bin
 3817  1.5 20300 oracle   /nfs/11.2.0/grid/bin/oraagent.bin
 4083  1.8 23700 oracle   /nfs/11.2.0/grid/bin/evmd.bin
 4372  2.4 31548 oracle   /nfs/11.2.0/grid/jdk/jre//bin/java -Doracle.supercluster.cluster.server=eo
 3564  3.2 41532 root     /nfs/11.2.0/grid/bin/ohasd.bin reboot
 4081  3.5 44932 root     /nfs/11.2.0/grid/bin/crsd.bin reboot
 3906 18.6 239428 root    /nfs/11.2.0/grid/bin/cssdagent
 3887 18.6 239444 root    /nfs/11.2.0/grid/bin/cssdmonitor
 3924 20.1 258564 oracle  /nfs/11.2.0/grid/bin/ocssd.bin

The second column above gives you amount of resident memory in KB for processes related to Grid Infrastructure. As you can cleanly see, processes of CSS components consume well above 700MB! In total we can account for 1 GB. (those calculations are flawed — see below)

Compare that with 10g (10.2.0.3 on 32 bit Linux) — bare-bone Clusterware processes consume only 60MB:

[oracle@lh1 ~]$ ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e nfs -e crs -e css -e evm | grep -v grep
  PID %MEM  RSS USER     CMD
 6524  0.0  348 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/opmn/bin/ons -d
 4892  0.1  992 oracle   /bin/sh -c cd /nfs1/oracle/oracle/product/10.2.0/crs/log/lh1/cssd/oclsomon;
 3262  0.1 1072 root     /bin/sh /etc/init.d/init.evmd run
 3506  0.1 1100 root     /bin/sh /etc/init.d/init.crsd run
 4575  0.1 1116 root     /bin/su -l oracle -c sh -c 'ulimit -c unlimited; cd /nfs1/oracle/oracle/pro
 4890  0.1 1120 root     /bin/su -l oracle -c /bin/sh -c 'cd /nfs1/oracle/oracle/product/10.2.0/crs/
 4664  0.1 1180 root     /bin/sh /etc/init.d/init.cssd oclsomon
 3263  0.1 1188 root     /bin/sh /etc/init.d/init.cssd fatal
 4677  0.1 1188 root     /bin/sh /etc/init.d/init.cssd daemon
 6525  0.5 4792 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/opmn/bin/ons -d
 4922  0.6 5224 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/oclsomon.bin
 5915  0.7 6280 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/evmlogger.bin -o /nfs1/oracle/or
 4576  1.1 9312 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/evmd.bin
 5018  1.1 9428 oracle   /nfs1/oracle/oracle/product/10.2.0/crs/bin/ocssd.bin
 4606  2.0 16712 root    /nfs1/oracle/oracle/product/10.2.0/crs/bin/crsd.bin reboot

The memory usage above is a bit overstated. There are some shared memory accounted multiple times. I could use Smaps interface to get better per process statistics. For example, you could see that 3 of the “top offenders” (CSS binaries) have about 40MB of shared libraries each:

[root@cheese1 ~]# ./smaps.pl 3924 | head
VMSIZE:     258576 kb
RSS:       258564 kb total
            39164 kb shared
             5180 kb private clean
           214220 kb private dirty
PRIVATE MAPPINGS
     vmsize   rss clean   rss dirty  file
   15052 kb        0 kb    15052 kb
   12016 kb        0 kb    12016 kb
   11184 kb        0 kb    11184 kb
[root@cheese1 ~]# ./smaps.pl 3887 | head
VMSIZE:     239456 kb
RSS:       239444 kb total
            40096 kb shared
             6200 kb private clean
           193148 kb private dirty
PRIVATE MAPPINGS
     vmsize   rss clean   rss dirty  file
   14624 kb        0 kb    14624 kb
   10240 kb        0 kb    10240 kb
   10240 kb        0 kb    10240 kb
[root@cheese1 ~]# ./smaps.pl 3906 | head
VMSIZE:     239440 kb
RSS:       239428 kb total
            40096 kb shared
             6200 kb private clean
           193132 kb private dirty
PRIVATE MAPPINGS
     vmsize   rss clean   rss dirty  file
   14624 kb        0 kb    14624 kb
   10240 kb        0 kb    10240 kb
   10240 kb        0 kb    10240 kb
[root@cheese1 ~]#

One way to get a practical number is to check system memory usage with and without Grid Infrastructure running — the difference is about 750MB (see the “free” column of the second row).

[root@cheese1 ~]# free
             total       used       free     shared    buffers     cached
Mem:       1283040    1131584     151456          0      18504     295668
-/+ buffers/cache:     817412     465628
Swap:       655328         76     655252
[root@cheese1 ~]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'cheese1'
...
...
CRS-4133: Oracle High Availability Services has been stopped.
[root@cheese1 ~]# free
             total       used       free     shared    buffers     cached
Mem:       1283040     397144     885896          0      18640     316632
-/+ buffers/cache:      61872    1221168
Swap:       655328         76     655252
[root@cheese1 ~]# ps -eo pid,%mem,rss,user,cmd --sort=rsz --cols 100 | grep -e '^ *PID' -e grid -e ohasd | grep -v grep
  PID %MEM   RSS USER     CMD
 3614  0.0  1084 root     /bin/sh /etc/init.d/init.ohasd run

I don’t have 11gR1 test cluster handy so I can’t check 100% but Oracle 11g Release 1 Clusterware is not much different from 10g so memory usage must be similar.

The lesson is that if you are upgrading your Oracle RAC Cluster to 11gR2 from 10g or 11gR1, then you have to account for additional 700MB memory for Grid Infrastructure alone on each node. Note that, this doesn’t take into account higher memory usage of the database instances themselves.

作者：eygle 发布在 eygle.com

很长一段时间以来，我一直有一个单纯的梦想，就是为喜欢Oracle的技术爱好者们做一点点公益的事情。
在过去的6年间，我在北京做过不少公开的活动，将我有限的经验与知识分享出去，这些活动每次都有很多新的面孔出现，有些成为我的朋友，有些真的就踏上了DBA之路，这些积极的促进是我一直乐于去做这样活动的主要原因。

可是做一点"公益"的事情并不容易，直到最近，当我觉得可以解决这其中的所有问题之后，这一切成为可能。

ACOUG 正是基于这样一件事情我们发起的一个站点，ACOUG的含义是All China Oracle User Group，这个名字太过大了，存粹是为了定义这样一个域名而得来的，所以请不要计较我们最终能够涉及到多少产品与内容，我们只是想尽力去做一件想了很久而一直没有做的事情。

所以要做一个用户组，是因为在几次去美国期间，在OOW上见到各个国家或地区的Oracle用户组组织了非常多的活动，而国内最活跃的是论坛，ITPUB.NET是首屈一指的，但是国内没有类似国外的用户组的组织。CNOUG也是一个非常不错的地方，但是CNOUG实际上是另外一个ITPUB，以论坛为主的社区，而社区也正是一个中国的特色。

ACOUG，其实开始我想也许成为BJOUG可能会更为确切，因为我们的初始活动可能只能在北京开始尝试。只是后来借鉴了一个印度的新闻组域名，得来了ACOUG的名字。

ACOUG，首先我们并不会做论坛，ITPUB在Oracle技术方面，在国内已经无可超越，技术问题的探讨那里仍然是最为合适的地方，我们想做的是一些地面活动，一直以来，我想搭建一个平台，那些热爱技术的、有一技之长的朋友，可以到这个平台上来演讲、分享、交流，我们通过这个平台提供一个分享和展现的机会，如果你乐于分享，并且享受过程，那这里就是你的舞台；而对于那些刚刚开始学习Oracle技术，又想接触和深入了解一下这个圈子的朋友，在这个平台下，我们为你准备好了位置，你可以来聆听和探讨。

ACOUG，这个站点的存在意义，最终我们设计将这个站点做成一个"技术博客"，我们希望邀请那些国内数据库领域的爱好者们加入，会有一些简单的规则，大家可以定期提供一些自己深入研究的技术文章，将这个站点作为一个统一的展现平台聚合起来，这个作用和国外的很多站点类似。这样的一个想法，没有什么新奇之处，我们只是希望，能够在朋友们的支持下，做一点新的事情、做一点有益的事情，基于爱好，基于那一直存在的理想主义。

这个想法，在年初和Kamus提起时，两个人达成了惊人的一致，就连想到的ACOUG的名字都是同样的，然后Kamus尝试用不同的程序搭建了网站的后台，最后或者说暂时我们选择了WP。Kamus在这件事情上投入了很多精力，感谢他！

搭建这个平台，我想，其实北京有众多的技术高手，如果每个人都能够分享一个主题，那么每两个月搞一次活动，我想应该是不难的，而以前一直存在的场地、费用问题，现在有我的恩墨科技做一点支持，靠朋友们的一点赞助，以及来自Oracle官方的一些支持，这些问题不再存在。

有时候我们不去做一件事情的借口是忙，事实上不是，我想即便我自己每个月抽出一两天，花费1~2小时去分享一个技术主题是非常容易的，唯一的借口是我们的懒惰。另外一个问题是，很多人不愿意为没有收益的事情付出，而我的观点是，有付出一定是有回报的，虽然这个回报可能在很久之后。而我愿意做这件事，更主要的是如前所述，在赤裸裸的为了追逐金钱而努力之外，我们还一直保有一点理想主义，我相信大家都有。如果缺少一个组织者，那我们愿意来试试看。

在我们这个消息传出去之后，我在美国认识的一位ACE Director - Ameed Taylor 已经发来邮件说愿意到现场来支持我们的活动，我说给点时间我们尝试一下，如果ACOUG能够发展下去，我希望有机会请更多的人来北京，或者在外地开展活动。

最后，我想，也许会有人质疑我们关于"公益"的动机，那么是的，我心里面窃窃的以为，如果我们搞的成功，那么也许我们这个舞台可以让一些具有真正技术的人凸显出来，所以乐于分享的人，也许会有些意想不到的收获，当然这些活动的组织者，也许有机会在更广泛的领域为业者所知，我说的有付出就一定有回报，某种程度上与此有关。而如果组织有价值，活动有价值，其他的交给时间吧。

在我的设想里，以后，我不是主要的演讲者了，越来越多的年轻人、技术专家涌现出来，如果你们愿意，这里有你的位置，当然我们目前还无法给出报酬。

第一次活动我们定在了3月20日，时间有点紧张，我的意思是，给我们一点压力，让这件事情尽快动起来，有开始才有未来，我跟Kamus说，行动有时候比思想更重要。

好了，这个活动，对于参与者，也许唯一的要求是一个详尽的注册流程，我们希望，我们的每一次活动所抵达的地方和人群都能够被记录下来，这是对我们这些尝试的鼓励和纪念。

关于ACOUG的网站，由于我们都不是专业的人士，如果有朋友碰巧懂得PHP或WP运用得好，我们诚挚的邀请志愿者加入这个站点的维护工作，谢谢。

就写这么多，让我们动起来吧！

-The End-

相关文章|Related Articles

• 2009 北京 - 继续暂住在我自己的房子里
  
• 我的个人Eygle新闻组 - 欢迎读者、朋友加入
  
• 结束《深入解析Oracle》技术访谈交流会
  
• 北飞的候鸟-Kamus北京庭审现场
  
• 一场即将到来的费解官司-声援Kamus
  

评论数量(18)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/acoug_starting.html

有感于国外Oracle用户组的发达，我跟eygle从今年开始尝试组建中国的Oracle用户组，All China Oracle User Group。我们的站点是acoug.org。

我们希望能够为全中国的Oracle技术爱好者提供一个交流与活动的平台，我们希望能够激发更多人对于Oracle技术以及相关知识的兴趣，我们希望沉浸在这些技术中的人员获得更多的乐趣。这是我跟eygle一直以来的一个理想，但愿我们能为此付出并且有所回报。

我们认识到中国目前掌握Oracle技术的人员广度和深度都跟美国、欧洲甚或是印度存在着较大差距，这需要我们更有热情的去付出，但愿在不久的将来ACOUG在全球Oracle用户组中占据一席之地。

ACOUG计划定期举行线下活动，而线下活动也将是ACOUG未来工作的重点，邀请著名的业内人士（不仅限于国内）来进行主题演讲，并围绕相关主题进行广泛的讨论从而使更多人获益。

eygle的文章有关于ACOUG更多的阐述，请猛击这里。

预计在这个月的3月20日（周六）开展ACOUG第一次线下活动，详细的地点、场地以及演讲主题还未确定，但是请有兴趣的朋友时刻关注ACOUG网站，欢迎参加。

    看到Kamus对SQLULDR2的留言后, 破有感触. 人们应当比较关注, 他们想要的功能用起来方便是否, 关键并不在于功能的多少. 而SQLULDR2的众多的命令行选项, 也确实有些让人发晕, 包括我自已.

    为了方便大多数人使用, 简化了SQLULDR2的命令行帮助, 简化到如下所示.

SQL*UnLoader: Fast Oracle Text Unloader (GZIP), Release 3.0.1
(@) Copyright Lou Fangxin (AnySQL.net) 2004 - 2010, all rights reserved.

Usage: SQLULDR2 keyword=value [,keyword=value,...]

Valid Keywords:
  user    = username/password@tnsname
  sql    = SQL file name
  query  = select statement
  field  = separator string between fields
  record  = separator string between records
  rows    = print progress for every given rows (default, 1000000)
  file    = output file name(default: uldrdata.txt)
  log    = log file name, prefix with + to append mode
  fast    = auto tuning the session level parameters(YES)
  text    = output type (MYSQL, CSV, MYSQLINS, ORACLEINS, FORM, SEARCH).
  parfile = read command option from parameter file

  for field and record, you can use '0x' to specify hex character code,
  \r=0x0d \n=0x0a |=0x7c ,=0x2c, \t=0x09, :=0x3a, #=0x23, "=0x22 '=0x27

    对于专家而言, 可以用如下方式得到以前全部的命令行选项.

sqluldr2 help=yes

    通过引入一个TEXT选项, 来针对不同格式的导出进行相关选项的设置, 不仅方便了大家使用, 也可以对SQLULDR2的功能有一个很直接的了解, 例如SQLULDR2可以导出数据给MySQL用, 或导出成Excel可以打开的标准CSV文件, 或是生成MySQL和ORACLE上的INSERT语句, 也可以按列显示记录, 或为一些特殊的搜索程序生成数据源.

    再次感谢Kamus的好建议, 今年是支付宝的用户体验年, 应当从用户角度进行反思.

Relative Posts:

• 2008/01/25 -- ociuldr更新(2008/01/25) (13)
• 2007/08/22 -- ociuldr的更新, 为了更好的long类型支持 (1)
• 2007/01/02 -- 在ociuldr的SQL中使用绑定变量 (4)
• 2010/02/08 -- SQLULDR2也可改善用户体验 (4)
• 2010/01/15 -- 两个用户的SQLULDR2需求 (1)
• 2009/12/25 -- SQLULDR2的按列文本输出 (0)
• 2009/12/25 -- SQLULDR2的自定义转义符处理 (2)
• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)