数据工人

很早就想弄个代步车了，一方面是小孩大了，应该多带出去转转，另一方面是最近打车总是很难打。

选择的过程很简单，就是靠身边有车的朋友的建议。

最后选择了DPCA（神龙汽车）的世嘉。世嘉这个车呢，车标是雪铁龙的，跟国产307算是一个母亲身上的不同儿女吧，外形还比较流畅。

本来是8月6号订的1.6AT 时尚型波尔多红，可是到8月20号的时候，SSSS店（Sale,Sparepart,Service,Survey)打电话说神龙汽车要推11款了，我订的车不生产了。什么德性嘛，说不生就不生了！

8月26号，再去SSSS改合同，将1.6AT时尚改为1.6AT舒适，价格上加了9000块。考虑的是从目前知道的信息，11款舒适版标配天窗，而11款时尚版减了防夹手功能和玻璃一键升降功能。可恶的是，到我改合同的时候，SSSS都没有一份11款的配置清单，说是神龙没有给出。最糟糕的是，神龙的400客服里，居然有人还不知道要出11款，而09款已经不接受订单了！

等吧，希望不要减配太多！

现在的竞争真的是越来越激烈，我们靠什么来发展，我们靠什么生存，我们的核心竞争力是什么？这个问题，我相信很多人都扪心自问过。一句话，没有客户，企业就没有存在的根据，没有企业，员工就只能另攀高枝。

作为oracle第三服务公司里的翘楚，我们的客户数量越来越多，形形色色都有，以前有离职的同事跟我说，我们的客户是我见过的最难弄的客户！毫无疑问，他是对的。软柿子谁都可以捏，还轮得到我们？我承认，我们的用户中，有个别人确实胡搅蛮缠（其实若完全站到他的角度来考虑问题，却未必一定如此），但99%以上的我认为其实相当不错了。

这中间的问题在哪里呢？

工程师认为客户有问题，那么反过来说，客户也一定会认为工程师（或者公司）有问题，这就是爱因斯坦的相对论吧？

那么这个时候，客户的满意度就应该不高。

满意度（ Satisfaction）是个啥玩意？它就是我们的服务质量（Qulity）减去客户期望(Expectation)！

这是一个恒等式，也就是说，要提高S,要么E不变的情况下提高Q，要么Q不变的情况下降低E，再者，Q和E同时提高，但Q的分量要大一些。这样就变成了一道数学题。

这真的是一道数学题么？我认为没那么简单，因为在服务过程中的主角，交付与接受双方都是人。所以E和Q的高低完全是由人来判断。

也就是说，满意度的高低，完全由用户的体验来决定！你可能会说，这太不公平了，都TMD人家主观来决定了，又没有给ABC的打分列表，我努力提高服务质量也是白努力了。其实未必，大部分客户的眼睛是雪亮的。

这就是有的工程师总受欢迎，有的工程师却只受到部分欢迎的缘故，这应该在各行各业的有，不足为怪。

那现场工程师如何提高客户的体验快感呢？我认为以下几个方面是必须的：

1. 提高专业技能。在80%的客户服务中，专业技能占体验快感的比重在20%以下，但是，作为服务方，这是我们义不容辞的方向。
2. 分享服务经验。这一条是最简单，最省力，却也最容易被工程师忽视的一点。客户相对于我们来说，接触的广度和深度都可能会略有欠缺，他们会很乐于接受同行业其他公司或者是其他行业的与他们系统有一定相关度的案例分享。分享可以拉近服务双方的距离，自然体验会好些，不是么？
3. 压低客户期望。人的欲望是无止境的，客户也是人。事先降低客户期望，给自己和客户都留一些buffer，当结果出来时才会皆大欢喜。这里有IBM运营战略首席顾问白立新的一篇博文中举了一个电梯的例子，我觉得很形象，可以移步到这里看看：http://club.ebusinessreview.cn/blogArticle-blogId-5265-userId-135320.html。
4. 自信守信坦诚。昂首挺胸，话语有力，本身就是传达体验的一个过程。但我们不可能事事搞定，对一些一时没有研究过，或者解决不了的问题，可以告诉客户，过几天再回复，但必须要记得回复，并最后结束这个问题。坦诚，是你可以不说，但不能说瞎话。
5. 要注意说“不”。这个很难把握，但要学习。一味“好的，好的”会让客户误以为你都答应了，事实上你可能是接下来想说很难做到或者说只是研究一下，而客户听到“好的”之后，后面的话就自动过滤了。但是，不能直接说“不”。《架构师应该知道的97件事》里，也提到这个问题。
6. 注意文档细节。其实本来想说注意细节，但既然是“细节”就事无巨细，怕说不清了。比如文档日期是否有误，是否有其他客户字样，字体行文是否一致等。这对没见过你人的用好来说，也许是你唯一表现服务质量的机会了。

也许，有人会说，我的客户都没有，谈不上这点事。

其实未必，提高了客户体验，客户会把自己的这份欣喜分享给朋友（其他客户）,这就是客户为企业服务的时候了，这时你还愁客户不够多么？

20个月的momo思维变得更加活跃了，所以作为父母的言行也就更应该谨慎，因为随便的一个不良习惯都可能遭遇模仿。

之前她刚学走路的时候，不小心摔倒了，我总是让她自己起来，实在起不来我才伸手过去，然后会随嘴说“up，up，来，起来咯..”。
这天中午，她醒来了，看到旁边的巧虎在躺在，她就说，“巧虎，upup，醒来啦！”
然后她妈妈说，“你让巧虎在睡一会吧？”
她答到“巧虎没听见”
然后边喊“up”边把巧虎扶了起来

有个习惯不知道是好不好，晚上睡觉前会喋喋不休，自己重复白天大人跟她的问答。

在RDBMS系统中，发生enqueue等待特别是enqueue TX-contention是再正常不过的了，原因很简单，为了满足ACID原则。但如果是enqueue HW-contention,你遇到的机会就要稍微少一些了，因为这一般只发生在大量数据装载或者是OLTP业务非常繁忙的系统中。

这不，我们的一个银行用好，恰巧就发生了这么一个问题，当大批量数据装载时，系统CPU使用率接近100%（这可是128CPU的HP superdome），而这其中的90%以上，是在等待enqueue HW 。当然，这个系统的架构有其特殊性，每个表只有两个字段，一个number，一个LOB（这个时候，你可能就会发现架构师对性能的影响有多么巨大了）。

HW=HighWatermark，所谓的高水位竞争。就是当数据插入的session过多，对最后一个可用块的竞争，以得到下一个空闲块（或者extent)。

这种情况，如果是普通表，使用alter table <TABNAME> allocate extent 提前多分配extent即可解决。

但是含有LOB（clob）字段的表，据客户反应，用这个方法在loading装载开始后的2分钟之内是有效的，但之后就不灵了，原因和在？ 原因处在lob方式。

解决方式分两种，在ASSM表空间之内的：

 a) As temporary workaround, manually add extra space to the LOB segment
      ALTER TABLE <lob_table>
      MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
   b) It may related Bug 6376915. 
   Refer to Note 6376915.8 “Bug 6376915 HW enqueue contention for ASSM LOB segments”
   In 10.2.0.4 or above, this fix has been included, and can be enabled by setting event 44951 to a value
   between 1 and 1024.  A higher value would be more beneficial in reducing contention.
   EVENT=”44951 TRACE NAME CONTEXT FOREVER, LEVEL < 1 – 1024 >”
OR
  c) Consider partitioning the LOB  in a manner that will evenly distribute concurrent DML across multiple 
      partitions  

使用MSSM的：

a) As temporary workaround, manually add extra space to the LOB segment
    ALTER TABLE <lob_table>    
    MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
     b) Consider partitioning the LOB in a manner that will evenly distribute concurrent DML across multiple
      partitions

 如我先去提到的，由于表的字段只有两个，lob字段中包含的内容实在太复杂，所以partition方式无法处理这个问题。只能是每次装载前，使用批处理的方式，预先分配200G左右的lob extent。