GGP_DWS专栏

1\
曾经有个小国到中国来，进贡了三个一模一样的金人，金壁辉煌，把皇帝高兴坏了。可是这小国不厚道，同时出一道题目：这三个金人哪个最有价值？
皇帝想了许多的办法，请来珠宝匠检查，称重量，看做工，都是一模一样的。怎么办？使者还等着回去汇报呢。泱泱大国，不会连这个小事都不懂吧？
最后，有一位退位的老大臣说他有办法。
皇帝将使者请到大殿，老臣胸有成足地拿着三根稻草，插入第一个金人的耳朵里，这稻草从另一边耳朵出来了。第二个金人的稻草从嘴巴里直接掉出来，而
第三个金人，稻草进去后掉进了肚子，什么响动也没有。老臣说：第三个金人最有价值！使者默默无语，答案正确。
这个故事告诉我们，最有价值的人，不一定是最能说的人的人。老天给我们两只耳朵一个嘴巴，本来就是让我们多听少说的。善于倾听，才是成熟的人最基
本的素质。

2\　
陈阿土是台湾的农民，从来没有出过远门。攒了半辈子的钱，终于参加一个旅游团出了国。
国外的一切都是非常新鲜的，关键是，陈阿土参加的是豪华团，一个人住一个标准间。这让他新奇不已。
早晨，服务生来敲门送早餐时大声说道：“GOODMORNING SIR！”
陈阿土愣住了。这是什么意思呢？在自己的家乡，一般陌生的人见面都会问：“您贵姓？”
于是陈阿土大声叫道：“我叫陈阿土！”
如是这般，连着三天，都是那个服务生来敲门，每天都大声说：“GOODMORNING SIR！”而陈阿土亦大声回道：“我叫陈阿土！”
但他非常的生气。这个服务生也太笨了，天天问自己叫什么，告诉他又记不住，很烦的。终于他忍不住去问导游，“GOODMORNING SIR！”是什么意思，
导游告诉了他，天啊！！真是丢脸死了。
陈阿土反复练习“GOODMORNING SIR！”这个词，以便能体面地应对服务生。
又一天的早晨，服务生照常来敲门，门一开陈阿土就大声叫道：“GOODMORNING SIR！”
与此同时，服务生叫的是：“我是陈阿土！”
这个故事告诉我们，人与人交往，常常是意志力与意志力的较量。不是你影响他，就是他影响你，而我们要想成功，一定要培养自己的影响力，只有影响力
大的人才可以成为最强者。

现代心理学研究表明，及时激励有效率为80%，迟延激励的有效率仅为7%^[4]，若最后根本不给予激励，还会产生负作用。我们以此构造如图1所示的博弈模型

图1 迟延激励博弈模型

在该模型中，管理人员有两种激励方式即适时激励和迟延激励，员工有两种工作态度即努力工作和不努力工作。如果管理人员答应员工在其完成某一工作后给予奖励（适时激励），员工努力工作，则双方得益各为5，即员工因努力工作而获得适时奖励，收益为5个效用单位，员工的工作给组织带来收益可以看成管理人员的得益也为5个效用单位；如果管理人员说话不算数，员工努力工作了但却没有及时得到奖励甚至根本就没得到奖励，员工感到不公平，此时得益为1个效用单位，而管理人员却获得了6个单位的得益；若员工没有努力工作反而被适时奖励，则员工得益为6个单位，管理人员得益为1个单位；若管理人员迟延激励，员工不努力工作，则这种情况与不进行激励的情况相似，双方得益均为2。表1得益矩阵中每个元素都由两个数字组成，前一个数字代表管理人员的得益，后一个数字代表员工的得益。

运用划线法或箭头法可求得此博弈模型的均衡的解为（迟延，不努力），即管理人员迟延激励，员工不努力工作为一个稳定的纳什均衡。很显然，这个结果是低效率的，管理人员和员工的总体得益（4个效用单位）低于其他任一组合的总体得益（最低为7个效用单位），因而，由于管理人员的迟延激励，使员工积极为组织工作的热情丧失，导致了组织的总体效益达到最低。若管理人员的行为反复则更是如此，这有时比不进行激励的结果更糟：不进行激励，员工有可能积极、主动地为组织工作，但管理人员一再践约，经常说话不算数，却会使员工向消极、被动的态度转化，我们称这种情况下博弈双方都陷入了“囚徒的困境”^[5]。如果该博弈重复进行，则必然每次都得出“管理人员不适时奖励，员工不努力工作”的均衡解，这最终只能导致员工消极怠工、管理人员威信丧失、组织效率低下、发展速度减慢的严重后果。

    一个组织要在激烈的市场竞争环境中立于不败之地，就应充分调动员工的积极性和创造性，促进组织活力，提高组织的效率与效益。而管理人员调动员工积极性和创造性的一个强有力的手段就是激励。激励，是指人们朝向某一特定目标行动的倾向，它将影响员工们怎样适应一个组织，员工们在特定地点和岗位上怀有的特定动机，会影响生产率^[1]。资料表明，正常人在未受到任何激励的情况下，能力仅能发挥出20%—30%，而在激励之下能发挥出60%—80%，这还未包括潜力的激励，这一事实说明了激励的重要性^[2]。奖金的使用（支付给产量超过预定标准的员工的现金报酬）是由弗雷德里克.泰勒（Frederick Taylor）在19世纪晚期推广使用的^[3]。一个有趣的事实是有些工人在每天工作12小时后，还有精力跑回家在他们的阁楼上工作。这使得泰勒认为，应找到一种办法在工作中利用工人的这种潜在的精力，必能大大提高生产率。由此，各类旨在挖掘工人劳动潜能的激励措施受到企业家们的青睐。我国各级组织的管理人员也注意到运用各种激励手段如物质激励与精神激励、长期激励与短期激励、外在激励与内在激励等来激发员工更为有效地为实现组织目标而努力工作，这在大多数情况下起到了积极的激励效果。

然而，激励应当适时，这不仅有利于让员工重复所希望的行为，也说明了制度和管理人员是值得信赖的。但是，现实生活中经常发生迟延激励的情况，即管理人员答应员工在其做完某件工作后给其一定量的奖励，可是员工圆满完成任务后，管理人员却借口其他原因推迟对员工的奖励，有的甚至一拖再拖，最终不了了之，根本不予奖励，极大地挫伤了员工的积极性和创造性，同时也损害了管理人员的威严，这就会产生激励的迟延效应问题。迟延激励在现实生活中很普遍，后果也比较严重，但笔者查阅了许多资料，并未发现国内外对于迟延激励的深入研究特别是深入的经济学研究。本文就试图运用经济学的分析方法，通过建立一种迟延激励博弈模型和运用边际分析来阐述迟延激励的危害，并分析迟延激励产生的原因，最后针对原因给出对策。

然而，激励应当适时，这不仅有利于让员工重复所希望的行为，也说明了制度和管理人员是值得信赖的。但是，现实生活中经常发生迟延激励的情况，即管理人员答应员工在其做完某件工作后给其一定量的奖励，可是员工圆满完成任务后，管理人员却借口其他原因推迟对员工的奖励，有的甚至一拖再拖，最终不了了之，根本不予奖励，极大地挫伤了员工的积极性和创造性，同时也损害了管理人员的威严，这就会产生激励的迟延效应问题。迟延激励在现实生活中很普遍，后果也比较严重，但笔者查阅了许多资料，并未发现国内外对于迟延激励的深入研究特别是深入的经济学研究。本文就试图运用经济学的分析方法，通过建立一种迟延激励博弈模型和运用边际分析来阐述迟延激励的危害，并分析迟延激励产生的原因，最后针对原因给出对策。

经常有人问temp表空间暴涨的问题,以及如何回收临时表空间,由于版本的不同,
方法显然也多种多样,但这些方法显示是治标不治本的办法,只有深刻理解temp
表空间快速增加的原因,才能从根本上解决temp ts的问题。

是什么操作在使用temp ts?
- 索引创建或重创建.
- ORDER BY or GROUP BY
- DISTINCT 操作.
- UNION & INTERSECT & MINUS
- Sort-Merge joins.
- Analyze 操作
- 有些异常将会引起temp暴涨

所以,在处理以上操作时,dba需要加倍关注temp的使用情况,v$sort_segment字典
可以记载temp的比较详细的使用情况,而v$sort_usage将会告诉我们是谁在做什么.

sql>select tablespace_name,current_users,total_blocks,used_blocks,free_blocks from v$sort_segment;
TABLESPACE_NAME CURRENT_USERS TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS

TEMP 1 63872 30464 33408
sql>
SQL>select username,session_addr,sqladdr,sqlhash from v$sort_usage
USERNAME SESSION_ADDR SQLADDR SQLHASH
------------------------------ ---------------- ---------------- ----------
CYBERCAFE C0000000D7EF99E8 C0000000E1BFE970 4053158416

然后通过多表联接,我们可以找出更详细的操作:
SQL>select se.username,se.sid,su.extents,su.blocks*to_number(rtrim(p.value)) as Space,tablespace,segtype,sql_text from v$sort_usage su,v$parameter p,v$session se,v$sql s
where p.name='db_block_size' and su.session_addr=se.saddr and s.hash_value=su.sqlhash and s.address=su.sqladdr order by se.username,se.sid;
USERNAME SID EXTENTS SPACE TABLESPACE SEGTYPE
------------------------------ ---------- ---------- ---------- ------------------------------- ---------
SQL_TEXT
-------------------------------------------------------------------------------------------------------------------------
CYBERCAFE 42 238 249561088 TEMP SORT
select 1 from sys.streams$_prepare_ddl p where ((p.global_flag=1 and :1 is null) or (p.global_flag=0 and p.usrid=:2)) and rownum=1

本例应该是由一些异常引起的,其实大多数情况下sort都会在几乎内结束,如果在sort操作的若干秒内刚好就捕获了该SQL,应该走狗屎运的事情,即你知道某个SQL将会发生sort操作,当你想捕抓它们时,发现它们已经sort完了,排序完毕后sort segment会被smon清除。但很多时间,我们则会遇到临时段没有被释放，temp表空间几乎满的状况,这时该如何处理呢？

metalink上推荐的方法收集整理如下
-- 重启实例
重启实例重启时，smon进程会完成临时段释放,不过很多的时侯我们的库是不允许down的,
所以这种方法缺应用机会不多,不过这种方法还是很好用的,如果你的实例在重启后sort段
没有被释放,这种情况就需要慎重对待。
-- 修改参数 (仅适用于8i及8i以下版本)
SQL>alter tablespace temp increase 1;
SQL>alter tablespace temp increase 0;
-- 合并碎片
SQL>alter tablespace temp coalesce;
-- 诊断事件
SQL>alter session set events 'immediate trace name DROP_SEGMENTS level 4'
说明：temp表空间的TS#为3,So TS#+1=4
-- 重建temp
SQL>alterdatabase temp tempfile '......'drop;
SQL>alter tablespace temp add tempfile '......';

可以说,以上的方法都是治标不治本的,因为temp增长过快显然是由于disk sort过多,造成disk
sort的原因也很多,比如sort area较小等原因,当然,sort area设置多大才合理？这个当然需
要满足In-memory Sort大于99%以上哦。

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 99.36 In-memory Sort %: 100.00
Library Hit %: 99.87 Soft Parse %: 99.84
Execute to Parse %: 1.17 Latch Hit %: 99.96
Parse CPU to Parse Elapsd %: 92.00 % Non-Parse CPU: 94.59

排序区域的分配
- 专用服务器分配sort area.
排序区域在PGA.
- 共享服务器分配sort area.
排序区域在UGA. (UGA在shared pool中分配).

在9i以前的版本,由sort_area_size决定sort area的分配,在9i及以后的版本,
当workarea_size_policy等auto时,由pga_aggregate_target参数决定sort
area的大于,这时的sort area应该是pga总内存的5%.当workarea_size_policy
等manual时,sort area的大小还是于sort_area_size决定.

无论是那个版本,如果sort area开得过小,In-memory Sort率较低,那temp表空间
肯定会增长得很快,如果开得较高,在C/S结构中将会导致内存消耗严重(长连接较多).

由于smon进程每隔5分钟都要对不再使用的sort segment进行回收,如果你不想让
smon回收sort segment的话,可以使用以下两个event写入初始化参数文件,然后
重启实例,这样如果你的磁盘排序较多,很快就会涨暴磁盘......

event="10061 trace name context forever, level 10" //禁止加收
event="10269 trace name context forever, level 10" //禁止合并碎片

通过合理地设置pga或sort_area_size,可以消除大部分的dist sort,那其它的disk
sort该如何处理呢？从sort引起的原因来看,索引/分析/异常引起的disk sort应该是
很少的一部分,其它的应该是select中的distinct/union/group by/order by以及
merge sort join啦,那我们如何捕获这些操作呢？
通常如何有磁盘排序的SQL,它的逻辑读/物理读/排序/执行时间等都是比较大的,所以我
们可以对v$sqlarea或v$sql字典进行过滤,经过长期地监控数据库,相信可以把这些害
群之马找出来.即然找出这些引起disk sort的SQL后怎么办呢？当然是对SQL进行分析,
尽而优化之。
[oracle@www1 sql]$ more show_sql.sh
#!/bin/bash
sqlplus -s aaa/bbbcol sql_text format a81
col disk_reads format 999999.99
col bgets_per format 99999999.99
col "ELAPSD_TIME(s)" format 9999.99
col "cpu_time(s)" format 9999.99
set long 99999999999
set pagesize 9999
select address,hash_value,disk_reads/executions disk_reads,elapsed_time/1000000/executions as "ELAPSD_TIME(s)",
buffer_gets/executions bgets_per,executions,first_load_time as first_time,sql_text
from v$sql
where executions > 0 and (disk_reads/executions > 500 or buffer_gets/executions > 20000) and command_type = 3
order by 3,4;

--select s.disk_reads,s.buffer_gets/s.executions bgets_per,first_load_time,st.sql_text
-- from v$sql s,v$sqltext_with_newlines st
--where s.address=st.address and s.hash_value=st.hash_value
-- and s.disk_reads > 1000 or (s.executions > 0 and s.buffer_gets/s.executions > 50000)
--order by st.piece;
exit
!

总结,如何从根本上降低temp表空间的膨胀呢？方法有2个：
1 设置合理的pga或sort_area_size
2 优化引起disk sort的sql

ORACLE实例有两种类型：单进程实例和多进程实例。

单进程ORACLE（又称单用户ORACLE）是一种数据库系统，一个进程执行全部ORACLE代码。由于ORACLE部分和客户应用程序不能分别以进程执行，所以ORACLE的代码和用户的数据库应用是单个进程执行。 在单进程环境下的ORACLE 实例，仅允许一个用户可存取。例如在MS-DOS上运行O RACLE 。

多进程ORACLE实例（又称多用户ORACLE）使用多个进程来执行ORACLE的不同部分，对于每一个连接的用户都有一个进程。 在多进程系统中，进程分为两类：用户进程和ORACLE进程。当一用户运行一应用 程序，如PRO*C程序或一个ORACLE工具（如SQL*PLUS），为用户运行的应用建立一 个用户进程。ORACLE进程又分为两类：服务器进程和后台进程。服务器进程用于处理连接到该实例的用户进程的请求。当应用和ORACELE是在同一台机器上运行，而不再通过网络，一般将用户进程和它相应的服务器进程组合成单个的进程，可降低系统开销。然而，当应用和ORACLE运行在不同的机器上时，用户进程经过一个分离服务器进程与ORACLE通信。