IT牛人博客聚合

by Fenng@dbanotes.net

知乎上有人说起「科班出身」这个话题，我大致写了一个回复。其实也是前几天我和前同事们分享提到的观点。很多人认为「科班出身」更加专业，而有些野路子半路出家也能做差不多的事情来，于是大家都疑惑，真的是这些人天赋异禀？

以计算机技术来说，大学本科学习的时间，不过四年而已，如果投入工作后，不能持续学习不能持续实践不能开拓思维的话，那么他的专业背景很可能停留在大学毕业那一刻而不再增长。而有些非科班的人，尽管起步阶段的积累不如科班的多，但他可能持续数年依然在学习实践、不停的开拓智域，那么你说，学了四年的人能和学了十年的人相比么？

如果读过《异类》这本书中，应该会对其中提到的「一万小时定律」，要成

查看全文: http://www.udpwork.com/item/7320.html

十多年前刚走入社会工作的时候，那时的中国软件开发根本没有什么版本管理，也没有什么编程规范，软件开发相比起今天来说非常地混乱，那时仅凭自己的一些学习总结了一些C语言编程中的好的小笔记，后来，这些笔记写成了一篇叫《编程修养》的文章。今天，又有些感触，想把这个话题扩大一下，从“个人修养”扩大到“环境保护”，所谓，穷则独善其身，富则达济天下，今天的技术人员比十多年前在技术和环境上都富有了许多，所以，也应该或多或少地担负起“达济天下”的责任了。

环境保护说白了就是保护一个良好的环境，为好的环境添砖加瓦，与破坏环境的人和事做斗争。其实，从技术人员来说，我们可以做一些力所能及的事。因为我们身边的技术环境还有很大的改善的空间，而一些来之不易的东西

查看全文: http://www.udpwork.com/item/7187.html

今天在转移博客到另一个vps时遇到这个问题，提示的是“Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by 。。。”，对php不熟悉，谷歌得到解决方法：

关于session的问题集锦解决方案

1.

错误提示

Warning: Cannot send session cookie – headers already sent

Warning: Cannot send session cache limiter

查看全文: http://www.udpwork.com/item/7163.html

前些日子，IBM推出了PureSystem的一体机，作为公司的一员，我也收到邮件得知了这个“值得全公司庆贺”的事情。

同时，作为一个Oracle DBA，我知道oracle在3年前就推出了Exadata，此一体机的推广在oracle各个部门都下大了力气，目前远洋、华为、移动等多家巨型企业早就已经用上了Exadata；而Exadata的技术，OU也早在几年前就培训oracle的售后工程师，更让人感到高兴的是，国内的DBA同行Kamusis，Jacky和Kaya已经翻译了Exadata的著作《Expert oracle Exadata》，相信该书很快将会和大家见面。

而PureSystem，据称IBM斥资了20亿美金研发的，在今年

查看全文: http://www.udpwork.com/item/7161.html

在oracle11g中，有个autotask的新特性，可以用来自动的收集优化信息，收集段信息等等。在EM中，我们看进菜单server-Oracle Scheduler-Automated Maintenance Tasks来看到他们：

问题的起源是在一个纯命令行的环境，收到一个change，需要disable autotask中的auto optimizer stats collection，于是按照原定的计划，先检查原来的状态，再执行package对其进行disable，最后再坚持一次是否已经更改成功：

SQL> select CLIENT_NAME, TASK_NAME, STATUS from DBA_AUTOTAS

查看全文: http://www.udpwork.com/item/7109.html

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang节点互联失败原因分析以及解决方案

今天和项仲在部署新系统的时候发现节点间ping不成功的情况，类似

1> net_adm:ping(‘xx@ip1′).

pang

由于这个问题比较普遍，我就记录下一步步的排除步骤.

首先从原理上分析下!由于erlang节点间通讯是透过tcp来进行的，所以我们确保以下几点：

1. 确保网络连接是通的，可以透过ping来查看。

2. 确保网络连接上tcp是可以通的，可以透过netcat在二个节点所在的机器上分别开个服务器端和客户端进行验证。

3. 确保端口是防火墙友好的。erlan

查看全文: http://www.udpwork.com/item/7046.html

今天同事在review change的时候看到有个给表空间加数据文件的，发现加的数据文件竟然超过了32G，按照原来的思维，在9i中，非bigfile的单个数据文件单个大小不能超过32G。这个加32G数据文件的change是不是有误？查了一下原来的表空间情况，发现已经存在127.99G的数据文件了。该数据库不是9i，且该表空间下含多个数据文件。

我们先来看一下该表空间的信息：

SQL> l
  1* select file_name,BYTES,RELATIVE_FNO,MAXBYTES,AUTOEXTENSIBLE from dba_data_files where tablespace_name='TS_OLB

查看全文: http://www.udpwork.com/item/6790.html

我：我们有两台机，都是一样的 xeon E5620 2.4G 的CPU，但是，跑算Pi的程序，5000个迭代，一个机器跑48秒，另一个只需要32秒

coly：CPU核数一样吗？

我：一样的。不一样应该没关系，我这是单进程。

coly：内存速度不一样？

我：就一个算Pi，总共就占8MB内存，还没有CPU的L3 cache大呢

coly：要不这样，你写个死循环加法，我们看看两边的速度是不是一样

（公司的盒饭送来了，晚饭时间）

coly：你先吃，我来写吧....一个死循环我应该还是能写出来的....你要review我的代码哟～
我：....

（coly把代码写出来了

int main(void)
{
  &nb

查看全文: http://www.udpwork.com/item/6710.html

环境大了，情况复杂，需要考虑的事情就多了。前几天遇到个5节点rac做parmary+3节点rac做pyhsical dataguard的环境，在primary的某个节点，由于突然的宕机，当我们把它启动重新加入cluster后，就出来了很多问题。这次故障不是我处理的，是我的几位同事一起处理的，从12月14号开始就一直追这个case，期间跑analyze table validate structure cascade online，从14日开始跑一直跑了十多天还跑不完，期间和oracle support也多次打交道。等处理完毕后，同事发邮件和大家共享了这个case。我也觉得这个case挺有意思，在这里按照我的理解，再次整理了一遍这个c

查看全文: http://www.udpwork.com/item/6704.html

上一篇 优化屏障（Optimization barrier）第二讲

1. 大胆猜想

上一篇提到了”memory”这个关键字，为什么它能够防止-fschedule-insns优化时做代码重排呢？为什么非得给它取名为屏障呢？

其实我们可以先考究一下asm语句的用法以及Optimization barrier的原型：

// template
asm ( assembler template
: output operands /* optional */
: input operands /* optional */
: li

查看全文: http://www.udpwork.com/item/6696.html

上一篇 优化屏障（Optimization barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Optimization barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __volatile

查看全文: http://www.udpwork.com/item/6683.html

上一篇 编译内存屏障（Compiler Memory Barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Compiler Memory Barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __

查看全文: http://www.udpwork.com/item/6679.html

1. 编译优化导致编译器指令重排

要想理解Optimization barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Optimization barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Optimization barrier，我们只需要关注

查看全文: http://www.udpwork.com/item/6684.html

1. 编译优化导致编译器指令重排

要想理解Compiler Memory Barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Compiler Memory Barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Compiler Memory Barrie

查看全文: http://www.udpwork.com/item/6680.html

上个星期终于把 Ghost in the Wires 看完了，现在就抽时间来写写书评吧。尽管我一向懒得写书评，不过这本书真的是超级推荐！
最初我是在 Audible 上面买了这本书的有声读物，然后发现朗读得超级好，尤其是 Kevin 知道危险逼近时心中的独白——「Fuuuuuuuck!」朗读的语气掌握得非常好。后来我决定买 Kindle 版来仔细读一下，因为有声读物不会专心听，只能把我到大意。随后我边听边读把整本书看完了。
这本书整体上分为 4 大部分。第 1 部分讲述 Kevin Mitnick 是如何入行的——他父亲和叔叔都是商人，这使得他很小的时候就意识到通过言语可以驱使他人做一些对自己有利的事情。同时他又是个超级 geek，

查看全文: http://www.udpwork.com/item/6663.html

by Fenng@dbanotes.net

本年度的最后一天，个人惯例，度过元旦的方式是做一下过去一年的个人总结。翻看了一下去年的总结和计划，完成度还过得去，这一年虽有遗憾，但没有虚度。

2011 年中在工作上多少做出了一点成绩，回顾了一下，上半年经历了从业以来几乎是最为严峻的考验，有段时间头发都急白了不少；下半年则相对顺利，团队效率提升很多，项目和产品上到了收获期，我甚至还能有时间顺路做做公关宣传。这是最有效率的一年。如果用一句话总结，那就是：丁香园全站过去一年中从传统的 1.0 模式升级到了 2.0 版本，打通了任督二脉，甚至还有一点延伸 --比如丁香园用药助手。作为第一款试水性的移动应用，一定程度上获得了用户的认可并且在

查看全文: http://www.udpwork.com/item/6626.html