NinGoo's blog

shell 编程之2>&1

经常可以在一些脚本，尤其是在crontab调用时发现如下形式的命令调用

/tmp/test.sh > /tmp/test.log 2>&1

前半部分/tmp/test.sh > /tmp/test.log很容易理解，那么后面的2>&1是怎么回事呢？

要解释这个问题，还是得提到文件重定向。我们知道>和<是文件重定向符。那么1和2是什么？在shell中，每个进程都和三个系统文件相关联：标准输入stdin，标准输出stdout和标准错误stderr，三个系统文件的文件描述符分别为0，1和2。所以这里2>&1的意思就是将标准错误也输出到标准输出当中。

下面通过一个例子来展示2>&1有什么作用：

$ cat test.sh
t
date

test.sh中包含两个命令，其中t是一个不存在的命令，执行会报错，默认情况下，错误会输出到stderr。date则能正确执行，并且输出时间信息，默认输出到stdout

./test.sh > test1.log
./test.sh: line 1: t: command not found

$ cat test1.log
Tue Oct 9 20:51:50 CST 2007

可以看到，date的执行结果被重定向到log文件中了，而t无法执行的错误则只打印在屏幕上。

$ ./test.sh > test2.log 2>&1

$ cat test2.log
./test.sh: line 1: t: command not found
Tue Oct 9 20:53:44 CST 2007

这次，stderr和stdout的内容都被重定向到log文件中了。

实际上， > 就相当于 1> 也就是重定向标准输出，不包括标准错误。通过2>&1，就将标准错误重定向到标准输出了，那么再使用>重定向就会将标准输出和标准错误信息一同重定向了。如果只想重定向标准错误到文件中，则可以使用2> file。

SAP收购BO?

SAP宣布将以68亿美元收购BusinessObjects，又一家BI领域内的大公司被IT巨鳄吞下，想起半年前Oracle以33亿美元收购海波龙(Hyperion)，加上更早之前IBM吃掉DataStage，BI市场大鱼吃小鱼的演进，看来已经进入到最后关头。还剩下有谁？Informatica，Cognos，Microstrategy？一年半载之内，估计都要难逃被消灭的命运了。

DataStage和Hyperion被收购之后，都未见有大的发展，不知道这次BO的命运如何。不过SAP不像Oracle，一般不太搞收购这一套，很多东西都是自己另起炉灶，这次的收购应该是SAP有史以来最大的手笔了。BusinessObjects本身在收购Cytstal Report后的整合工作还没有完成，虽然BO XI在新的SOA架构上已经开始可以支持水晶报表的发布，但是水晶报表的开发还是需要单独的客户端，而且desktop intelligence，web intelligence和OLAP intelligence等几个产品之间相对保持独立，都有自己的一套服务端，也使得整个BO的架构过于庞大复杂，另外，由于没有自己的OLAP引擎，BO的OLAP报表能力也是不咋的。或许凭借SAP强大的开发能力和客户基础，BO在被收购后能被整合出一片新天地，从此把Cognos抛在身后也未可知。

台风，又见台风

来杭州的那天，正遇上台风韦帕，号称十年来最大台风，幸好只是虚晃一枪，没给我造成多大麻烦。这才20天不到，美丽的罗莎(Krosa)又姗姗来到，这次可让我领略台风的威力了。

早上出门的时候已经特意比平常提早十几分钟，走路去公司看来是不行了，想着坐车不过三站，正常几分钟就到了，留足四十分钟应该完全足够。那想到，走到小区门口的车站，裤子已经湿到膝盖以上，再看平时空空的车站挤满了人，而过来的公交车则基本上已经处于满员状态，taxi就更别提了。

如此风雨中张望了半个多小时，上班的时间已过，还是没能挤上车，倒是裤子越来越湿，鞋子也开始进水，加上瑟瑟寒风，实在受不了了，只好请个假，灰溜溜的赶回家换衣服。要不感冒了还得请病假，更麻烦。

已到深秋，又见台风。

如何识别最耗资源的SQL

一般来说，调优的第一手资料，很可能就是典型业务期的一个statspack报告，那么如何根据statspack报告来判断是哪些SQL消耗了最多的系统资源？哪些SQL是最需要调整的呢？这里给出了一个大致的优化思路。当然，思路是死的，人是活的，优化也需要随需应变。

一般来说，需要关注下面四种Top SQL

• 消耗最多CPU的（逻辑IO过多）
• 导致过多物理I/O的
• 执行次数较频繁的
• 执行时间较长的

我们知道，一个语句的响应时间有个很著名的公式：

响应时间=服务时间+等待时间

其中服务时间就是CPU为执行该语句花费的时间。

服务时间=分析时间+递归时间+执行时间

分析时间是CPU用于分析语句的时间，递归时间是CPU用于语句的递归SQL的时间，剩下的则就是CPU用于执行语句的真正时间了。

[继续阅读全文]

常用标签： oracle MySQL Oracle11g dba blog 新特性 oow oow2009 wordpress ASM

最新评论 | Recent comments

最近文章 | Recent posts

站点信息 | Statistics