使用该参数需要注意参数INBOUND_CONNECT_TIMEOUT的设置，以避免发生过多的“ORA-12170: TNS:Connect timeout occurred”错误.

Connection Rate Limiter Parameters

The connection rate limiter feature in the Oracle Net Listener enables a DBA to limit the number of new connections handled by the listener. When this feature is enabled, Oracle Net Listener imposes a user-specified maximum limit on the number of new connections handled by the listener every second.

Depending on the configuration, the rate can be applied to a collection of endpoints, or to a specific endpoint.

This feature is controlled through the following two listener.ora configuration parameters:

• CONNECTION_RATE_listener name

• RATE_LIMIT

CONNECTION_RATE_listener name

Purpose

To specify a global rate that is enforced across all listening endpoints that are rate-limited. When this parameter is specified, it overrides any endpoint-level numeric rate values that might be specified.

Syntax

CONNECTION_RATE_listener_name=number_of_connections_per_second

RATE_LIMIT

Purpose

To indicate that a particular listening endpoint is rate limited. The parameter is specified in the ADDRESS section of the listener endpoint configuration.

Syntax

LISTENER= (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))
)

• When the RATE_LIMIT parameter is set to yes, the end-point is included in the enforcement of a listener-wide connection rate. This is used with the CONNECTION_RATE_listener_name parameter.
• When the RATE_LIMIT parameter is set to a value greater than 0, the rate limit is enforced at that endpoint level.

Examples

The following examples use the CONNECTION_RATE_listener name and RATE_LIMIT parameters.

Example 1

CONNECTION_RATE_LISTENER=10
LISTENER=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523))
)

In the preceding example, the total number of new connections through ports 1521 and 1522 is limited at 10 every second. Connections through port 1523 are not limited and do not count towards the overall rate of 10 connections every second.

Example 2

LISTENER= (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=5))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=10))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523))
)

In the preceding example, the connection rates are enforced at the endpoint level. A maximum of 5 connections are processed through port 1521 every second. The limit for connections through port 1522 is 10 every second. Connections through port 1523 are not limited.

我在11gr2中测试，如上example 1的设置reload listener后能够起作用；example 2的设置reload & restart listener后不起作用。

按照数据库的思想来说，DNS可以说是分布式的，层次结构的，KEY-VALUE的，高可用的系统。

分布式和层次结构

网址www.yumianfeilong.com，其实就是www.yumianfeilong.com. (末尾有个”.”，表示root). “.”就是Root, “.com”就是TLD DNS， ”.com.yumianfeilong“是次级DNS. “www”可以说是该次级DNS内的一台server。

每个层次的DNS存储下一级DNS的地址。这样当要查找一个DNS对应的IP时候，可以查找root dns得到下一级DNS，再去下一级DNS递归查找。

分布式查询

DNS查询最常见的2种方式:Recursive queries:和Iterative (or nonrecursive) queries。如上为Recursive模式，表示为客户端的DNS解析完全由DNS resolve代劳，具体步骤如下：

1. A user types the URL http://www.example.com into a browser.
2. The browser sends a request for the IP address of www.example.com to its local
resolver (stub-resolver).
3. The stub-resolver queries the locally configured DNS Resolver for the IP
address of www.example.com.
4. The DNS Resolver looks up www.example.com in local tables (its cache), but it
isn’t found.
5. The DNS Resolver sends a query to a root-server for the IP (the A RR) of
www.example.com.
6. The root-server only supports iterative (nonrecursive) queries (see the
upcoming section “Iterative (Nonrecursive) Queries”) and answers with a list of
name servers that are authoritative for the next level in the domain name
hierarchy, which in this case is the gTLD .com (this is called a referral).
7. The DNS Resolver selects one of the authoritative gTLD servers received in the
previous referral and sends it a query for the IP of www.example.com.
8. The gTLD name server only supports iterative queries and answers with the
authoritative name servers for the Second-Level Domain (SLD) example.com (a
referral).
9. The DNS Resolver selects one of the authoritative DNS servers for example.com
from the previous referral and sends it a query for the IP (the A RR) of
www.example.com.
10. The zone file for example.com defines www.example.com as a CNAME record (an
alias) for joe.example.com. The authoritative name server answers with the
www.example.com CNAME RR and, in this case, the A RR for joe.example.com,
which we will assume is 192.168.254.2.
11. The DNS Resolver sends the response joe.example.com=192.168.254.2
(together with the CNAME RR www=joe) to the original client stub-resolver.
12. The stub-resolver sends www.example.com=192.168.254.2 to the user’s browser.
13. The browser sends a request to 192.168.254.2 for the web page.

KEY-VALUE

显而易见，查询域名，返回IP，也可以查询IP，返回域名（Reverse Mapping）。nslookup和dig都是常用的命令。

nslookup yumianfeilong.com.

Non-authoritative answer:
Name:   yumianfeilong.com
Address: 69.163.181.118

nslookup 69.163.181.118

Non-authoritative answer:
118.181.163.69.in-addr.arpa     name = apache2-bongo.yerevan.dreamhost.com.

Authoritative answers can be found from:
181.163.69.in-addr.arpa nameserver = ns1.dreamhost.com.
181.163.69.in-addr.arpa nameserver = ns3.dreamhost.com.
181.163.69.in-addr.arpa nameserver = ns2.dreamhost.com.
ns1.dreamhost.com       internet address = 66.33.206.206
ns2.dreamhost.com       internet address = 208.96.10.221
ns3.dreamhost.com       internet address = 66.33.216.216

其中DNS Reverse Mapping通过保留域名“IN-ADDR.ARPA.” (IPV4)实现。实现方式和查询某个域名的IP地址类似，也有Recursive 和non-Recursive 方式。

如下为Recursive方式查询IP地址192.168.250.15对应的域名。

reverse mappting的设计思路在某些应用设计中或许有借鉴意义。

高可用性

自然是复制，Master-Slave模式。 这也部分导致了难于实现实时一致性。在master上做了DNS改动后，需要一些时间Push到slave上和其他有cache过期DNS记录的DNS上。

内容参考Pro DNS and BIND

你为什么总是原地踏步——内卷化效应

以前看过介绍日本一家专门做10分钟快速平价理发公司的文章，那个文章说凡是在该公司工作超过5年的理发师一律领N+3辞退(可以出去开分店但不让在原店面理发了)，以保证理发的质量，用学术语言来描述，就是为了避免内卷化的一种手段。

‘内卷化‛意指一个社会既无突变式的发展，也无渐进式的增长，长期以来，只是在一个层面上自我消耗和自我重复。大到一个社会，小至一个自我，一旦陷入内卷化状态，即似身陷泥沼，无力前进。

人们常说，信念决定命运。如果一个人认为自己这一生只能如此，那么命运基本上也就不会再有改变，生活就此充满自怨自艾；如果相信自己还能有一番作为，并付诸行动，那么便可能大有斩获。正像运动员所说的，‚拼搏不一定会得到，不拼搏一定会得不到。

走出职场的内卷化，要靠自身力量。这种力量来自于强烈的求知欲望和顽强的上进精神。只有充分发挥自身力量，才能突破自我、表现自我、超越自我，从而使得职业生涯呈现出一片勃勃生机。

税赋到底由谁承担——税赋归宿

提倡理性消费，别被商家促销广告打折女友所洗脑。争做理性人并且争取探索透明的信息。

在这里需要指出的一个原则是，只要消费，就会纳税，我们每一个消费者都是纳税人。到目前为止，我国共有22种税（包括增值税、消费税、营业税、企业所得税、个人所得税、资源税、房产税、城市维护建设税、城市房地产税、城镇土地使用税、土地增值税、耕地占用税、车辆购置税、车船税、契税、印花税、烟叶税、关税、船舶吨税等）。在这些名目繁多的税当中，有些是由个人上缴的，有些是由企业上缴的。

曾有一份研究报告指出，在我国，假如1袋1公斤的盐价格为2元，其中就包含大约0.29元的增值税和大约0.03元的城建税。而每瓶3元的啤酒包含大约0.44元的增值税、0.12元的消费税和0.06元的城建税。如果你花100元买了一件衣服，其中包含14.53元的增值税和1.45元的城建税。如果花l00元买一瓶化妆品，其中除14.53元的增值税外，还包含25.64元的消费税和4.02元的城建税。如果你吸烟，每包烟8元，其中大约4.70元是消费税、增值税和城建税。如果去餐馆吃饭，最后结账时不论多少，餐费的5.5%是营业税及城建税。你如果使用一次性木筷，还会包括些许消费税。你去理发店理发，同样，费用的5.5%是营业税及城建税……总之，一个人只要生活在社会中，只要有购买行为，就免不了交税。

少数服从多数‛的危险——阿罗不可能性定理

很多公司在招聘的时候，面试者往往会被群面。如果一个面试官否定了，就算其他所有的面试官都OK，这个应聘者也会被Pass。

阿罗不可能性定理的基本内容是：如果众多的社会成员有着不同的偏向，同时又要在多种方案之间作出选择，那么仅仅依靠民主制度，将不会得到让所有人都满意的结果。

在企业管理中，有时却会遇到一些特殊的情况，会发现‚投票决定‛并不适用。比如，五个年轻人合伙投资开了一家鲜花礼品店，各自的投资金额也大体相当。那么，他们对礼品店是如何管理的呢？由于他们当中没有‚大股东‛，按照股份比例决定话语权是不可能的。那么，在作出某项决策时，实行‚少数服从多数‛的原则举手来表决，可不可以呢？表面看来，这种方法是可行的，因为不会出现支持方和反对方人数相等的局面，最多也就是三比二。然而，这几个股东的实际做法却并非如此，恰恰相反，他们采取的是：‚所有决策，只要有一人反对，便不能通过‛。原来，在这时实行的是‚多数服从少数‛的原则——我们应该承认，他们的做法是一种智慧的体现。

作为企业，管理者的决策将直接影响企业的发展，如果此时采用投票办法，少数服从多数，将很可能使企业陷入巨大的风险。企业运作，关键是每一个环节都能顺利完成，这样才能达到最终的目的。试想，假设在其中至少有一个投资人不同意的情况下执行决策，这个反对者就成了鲜花店最危险的环节。不难想象，一个认为决策不可能成功的人，一个投反对票的人，在执行时的干劲、结果将会怎样。

以上3个概念和企业管理，个人职业发展，理财靠的更紧密先。

概况“每天学点经济学” 中一些有意思的理论。

收入的差距是如何形成的——二八定律 — 这本书就符合该理论

二八定律‛存在于生活的方方面面，体现的是不平衡，差异化的问题。‚二八定律‛提醒我们去思索，怎样付出更少，既能获得个人成功，又能获得事业成功；怎样做得更少，既能享受幸福生活，又能实现生命价值。

在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的

富人总是占少数，穷人总是占多数。他们两者的比例一般会保持在20：80左右。

20%的人占有80%的财富

两个人投入同样的8个小时，而产出的成果是绝对不一样的。员工工作了8小时获得的报酬是100元，而老板工作了8小时获得的报酬是1万元。

对一个企业来说，顾客中的约20%占有营业额的80%左右，而他们就是所谓的‚贵客‛。如果公司发现约20%的产品带来了约80%的利润，那么这家公司就应该集中精力予这些利润高的产品。

一本书约80%的价值，已经在约20%的页数中就已经阐明了，所以只要看完整部书的20%左右就可以了。当然这种看法不能适用于阅读所有的书籍，对有些书还是要从头到尾细细阅读的。

股市中有80%的投资者只想着怎么赚钱，仅有20%的投资者考虑到赔钱时的应变策略。但结果是只有那20%的投资者能长期赢利，而80%的投资者却常常赔钱。对于投资者来说，如果能吃透‚二八定律‛的精髓，把它应用于股市，赚钱就会变得很轻松。

你买，我也跟着买——示范效应

facebook?微博控？广告？买了kindle后悔了？物联网？大众点评网？

在日常生活中，我们常常会发现这种现象：当你的同事或者邻居买了某种商品，引得其他人羡慕的时候，你也会跟着购买这种商品。

由此可见，人们的消费行为不但受收入水平的影响，而且受其他人——主要是那些收入与其相近的人——消费行为的影响。这就是示范效应在起作用。

示范效应往往是双向的，这就是所谓‚坏‛榜样和‚好‛榜样所起的影响。从动态上看，示范效应最终会使少数成为主流。

消费者在认识和处理自己的收入与消费及其相互关系时，会和其他消费者相比较。例如，单位组织向贫困地区捐款，这对捐款的人来说当然是消费支出。有些人在这时不一定是看自己收入的高低，而是会先看看周围的人捐了多少。他们会根据自己的判断，觉得自己应该跟哪些人捐一样多。即使他的收入高点，他也不会多捐，他担心有出风头的嫌疑。即使他的收入较低，他也要向某一部分人看齐，甚至会‚打肿脸充胖子‛，他不愿意别人说他小气。从理论上讲，这里所表现的就是消费的示范效应。这就使我们看到消费者分成了许多群体，有许多消费者自觉不自觉地把自己算在一定的群体内，他的消费向这个群体内的其他人看齐。

在市场环境下，特别是在商品供应比较丰富的情况下，消费的示范效应表现得越来越明显，对市场供求关系起着比较大的影响，比如说有人看到别人的衣服漂亮，不管自己穿着好不好看，也要千方百计买一套穿在自己身上。‚名牌效应‛也是示范效应的典型现象，这完全可以解释为什么各种商家要不惜重金聘请‚明星‛做商品广告的缘故了。

在现代社会中，示范效应随时都左右着人们的经济生活，以及消费习惯。当消费者看到有些人因收入水平或消费习惯的变化而购买高档消费品时，尽管自己的收入没有变化，也可能仿效他人扩大自己的消费开支，或者在收入下降时也不愿减少自己的消费支出。示范效应甚至可以跨越国界，当某国居民接触到别国居民购买高档消费品时，他们可能会仿效别国居民从而改变自己的消费习惯。于是，消费的示范效应会造成低收入水平国家居民的消费需求远远超出他们正常的水平，从而导致储蓄不足和国际收支严重逆差等问题。

经济学研究的基石——经济学假设

假设永远不会成为现实的

理性经济人、资源稀缺、完全信息这三个基本的假设，为经济学的分析力、决策力提供了现实的前提条件和基础，因而我们在学习经济学的时候就必须了解这些假设

7年之痒 — 扩展的边际效用

同样，边际效用递减的原理广泛地存在于日常生活中

边际效用是一个经济学概念。物品都有用，人们消费物品后获得效用。每多消费一个单位量的物品，都能多获得一些额外效用，这些额外效用就叫做边际效用。边际效用在应用的过程中，有一个递减的作用，叫做边际效用递减。

比如说工作，为什么新人的干劲很大，而过几年大家都意志消沉、尽显沧桑了？这就是因为如果一个人在一段时间以内一直做同样的工作，那么工作带给他的新鲜感和满足度是一直边际递减的

还有在婚姻中，之所以会有喜新厌旧的说法，就是由于边际效用递减的缘故。。那么对于生性喜欢追求刺激的人来说这样的生活太没有挑战意义，那么婚姻中的他很有可能通过外在异性的获得来填充这种需求。所以，保持婚姻持久的最好方法就是保持婚姻的新鲜度，让感情常新。

从高处看外包

外包的方式在企业中应用最为广泛。外包将企业解放出来以更专注于核心业务。外包合作伙伴为企业带来知识，增加后备管理时间。在执行者专注于其特长业务时，为其改善产品的整体质量。

但是，在现实应用中，有些企业或人对外包产生了错误的认识。他们认为‚把不懂的业务全部包出去已经成为企业管理新思潮‛。这是一个非常普遍又危险的误区。对于企业，自身对包出去的业务，可以‚不专‛，但不能‚不懂‛。‚不专‛与，‚不懂‛是有很大区别的。。如果企业对外包出去的业务‚不懂‛，很容易就会丧失对业务的监控、管理和对结果的考核能力，最终所得到的结果就会与初衷背道而驰。‚不懂业务‛从另一个层面来说是指不具备和服务供应商的议价能力，如此一来又如何达成降低成本的目的呢？

众多的研究表明，服务发包商与服务供应商之间最为良好的关系，并不是简单的买卖关系，而是一种合作伙伴关系。一旦外包服务合同关系成立，随之就要确立外包项目的管理模式，要建立诸如项目管理的组织结构、职责界定、交流机制和交流渠道等一系列的内容。如果是长期项目，还要有不断总结改进的机制。这一系列的复杂情况决定了简单的买卖关系很难产生成功的服务外包结果

破窗效应

有点类似示范效应；不过这个是不好的示范效应。

有一家理发店的窗户玻璃破了一个角，由于生意非常红火，老板没有时间去修理它。有一天夜里，一个小男孩路过理发店，看见破了一个角的窗户，就拿起一块石头砸过去，大半截玻璃稀里哗啦地掉了下来。等老板追出来的时候，小男孩已经跑远了。老板想换掉玻璃，可由于马上要过节了，理发的人很多，他非常忙，根本没时间。那扇掉了大半截玻璃的窗户依旧破裂着。过了几天，老板正在里边忙碌着，突然听见‚啪‛的一声，那扇半截玻璃被完全打碎了。等老板追出来的时候，只看见了两个跑远了的孩子的背影。

不得已老板抽出时间装了一块新的玻璃。为了防止玻璃再被打碎，老板只要有时间就站在窗户后面，企图逮住打碎玻璃的小孩。可令他奇怪的是，此后再也没有小孩来打碎他的窗户玻璃了。

这个小故事反映了这样一个道理：如果有人打坏了一栋建筑上的一块玻璃，又没有及时修复，别人就可能受到某些暗示性的纵容，去打碎更多的玻璃。久而久之，这些窗户就给人造成一种无序的感觉，在这种麻木不仁的氛围中，就会出现更多破坏性的行为。这就是政治学家威尔逊和犯罪学家凯琳提出的‚破窗效应‛

对于违反公司程序或廉政规定的行为，有关组织没有进行严肃处理，没有引起员工的重视，从而使类似行为再次甚至多次重复发生

而在一个很干净的地方，人们会很不好意思扔垃圾，但是一旦地上有垃圾出现，人们就会毫不犹豫地随地乱扔垃圾，丝毫不觉得羞愧

在公交车站，如果大家都井然有序地排队上车，又有多少人会不顾众人的文明举动和鄙夷眼光而贸然插队？与这相反，车辆尚未停稳，猴急的人们你推我拥，争先恐后，后来的人如果想排队上车，恐怕也没有耐心了。这些都是‚破窗效应‛的表现。

在管理实践中，管理者必须高度警觉那些看起来是个别的、轻微的‚小过错‛，并坚持严格依法管理。‚千里之堤，溃于蚁穴。‛不及时修好第一扇被打碎玻璃的窗户，就可能会带来无法弥补的损失。而如果能及时修复，则效果会非常明显

消费PK节俭——节俭悖论

现在明显是内需不足，产能过剩

18世纪，荷兰的曼德维尔博士在《蜜蜂的寓言》一书中讲过一个有趣的故事。一群蜜蜂为了追求豪华的生活，大肆挥霍，结果这个蜂群很快兴旺发达起来。而后来，由于这群蜜蜂改变了习惯，放弃了奢侈的生活，崇尚节俭，结果却导致了整个蜜蜂群体的衰败。

蜜蜂的故事说的就是‚节俭的逻辑‛，在经济学上叫‚节俭悖论‛。在西方经济学说史上，经济学家凯恩斯从故事中却看到了刺激消费和增加总需求对经济发展的积极作用，受此启发，他进一步论证了节俭悖论。

根据凯恩斯的总需求决定国民收入的理论，节俭对于经济增长并没有什么好处。实际上，这里蕴涵着一个矛盾：公众越节俭，降低消费，增加储蓄，往往会导致社会收入的减少。因为，人们的收入通常有两种用途——消费和储蓄，而消费与储蓄成反方向变动，即消费增加储蓄就会减少，消费减少储蓄就会增加。所以，储蓄与国民收入呈现反方向变动，储蓄增加国民收入就减少，储蓄减少国民收入就增加。根据这种看法，增加消费减少储蓄会通过增加总需求而引起国民收入增加，就会促进经济繁荣；反之，就会导致经济萧条。由此可以得出一个蕴涵逻辑矛盾的推论：节制消费增加储蓄会增加个人财富，对个人是件好事，但由于会减少国民收入引起萧条，对整个国民经济发展却是件坏事。

节俭悖论告诉我们：节俭减少了支出，迫使厂家削减产量，解雇工人，从而减少了收入，最终减少了储蓄。储蓄为个人致富铺平了道路，然而如果整个国家加大储蓄，将使整个社会陷入萧条和贫困。也就是说，在资源没有得到充分运用、经济没有达到潜在产出的情况下，只有社会每个成员都尽可能多地消费，整个经济才能走出低谷，迈向更加充分就业、经济繁荣的阶段。

总之，我们要辩证地看待节俭和消费的问题。像本书开头案例中王先生的父亲和儿子，他们的观点都对，但又都不全对。这里关键是一个度的把握问题。节俭是中华民族的传统美德，但并不是不去消费；而
消费也不是奢侈地去浪费。我们要大力提倡理性消费，也要理直气壮地反对盲目消费。

书作者都有大型互联网公司工作的经验，在最后章节对所有的50个rule按照重要级别和实施成本作了分类；如下我摘录一些比较常见的rule按照类型进行一下分类，如属于设计范畴或运维范畴等。

设计原则

• Rule 1—Don’t Over-engineer the Solution — 适合的是最好的
  

1. What: Guard against complex solutions during design.
2. How to use: Resist the urge to over-engineer solutions by testing ease of understanding with fellow engineers.
3. Why: Complex solutions are costly to implement and have excessive long-term costs.
4. Key takeaways: Systems that are overly complex limit your ability to scale. Simple systems are more easily and cost effectively maintained and scaled.

• Rule 2—Design Scale into the Solution (D-I-D Process) — 在设计阶段就考虑scale成本最低并最有效率
  

How to use:
+Design for 20x capacity.
+Implement for 3x capacity.
+Deploy for ~1.5x capacity.

架构设计

• Rule 43—Communicate Asynchronously As Much As Possible — 使用可信赖的消息队列
  

1. What: Use asynchronous instead of synchronous communication as often as possible.
2. When to use: Consider for all calls between services and tiers.
3. Why: Synchronous calls stop the entire program’s execution waiting for a response, which ties all the services and tiers together resulting in cascading failures.
4. Key takeaways: Use asynchronous communication techniques to ensure that each service and tier is as independent as possible. This allows the system to scale much farther than if all components are closely coupled together.

• Rule 29—Failing to Design for Rollback Is Designing for Failure — 减少失败就是提高可用性
  

1. What: Always have the ability to roll back code.
2. Key takeaways: Don’t accept that the application is too complex or that you release code too often as excuses that you can’t roll back. No sane pilot would take off in an airplane without the ability to land, and no sane engineer would roll code that they could not pull back off in an emergency.

• Rule 37—Never Trust Single Points of Failure  — 增加可用性，还可以提高用户网络体验
  

1. What: Never implement and always eliminate single points of failure.
2. When to use: During architecture reviews and new designs.
3. How to use: Identify single instances on architectural diagrams. Strive for active/active configurations.
4. Why: Maximize availability through multiple instances.
5. Key takeaways: Strive for active/active rather than active/ passive solutions. Use load balancers to balance traffic across instances of a service. Use control services with active/passive instances for patterns that require singletons.

Web开发设计

• Rule 21—Use Expires Headers  — cache in client

1. What: Use Expires headers to reduce requests and improve the scalability and performance of your system.

• Rule 22—Cache Ajax Calls       — cache is king； cache in multiple ties
  
• Rule 23—Leverage Page Caches
• Rule 24—Utilize Application Caches
• Rule 25—Make Use of Object Caches
• Rule 26—Put Object Caches on Their Own “Tier”  — don’t abuse cache
  
• Rule 4—Reduce DNS Lookups  — volecity大会中介绍过很多类似的方法，提高web页面相应速度
  

1. What: Reduce the number of DNS lookups from a user perspective.
2. When to use: On all Web pages where performance matters.
3. How to use: Minimize the number of DNS lookups required to download pages, but balance this with the browser’s limitation for simultaneous connections.
4. Why: DNS lookups take a great deal of time, and large numbers of them can amount to a large portion of your user experience.

• Rule 39—Ensure You Can Wire On and Off Functions — 通过文件或者数据库配置，可以针对用户打开或者关闭某个服务，类似oracle 11g中的invsisiable index
  

1. What: Create a framework to disable and enable features of your product.
2. When to use: Risky, very high use, or shared services that might otherwise cause site failures when slow to respond or unavailable.
3. How to use: Develop shared libraries to allow automatic or on-demand enabling and disabling of services.
4. Why: Graceful failure (or handling failures) of transactions can keep you in business while you recover from the incident and problem that caused it.
5. Key takeaways: Implement Wire On/Wire Off frameworks whenever the cost of implementation is less than the risk and associated cost of failure.Work to develop shared libraries that can be reused to lower the cost of future implementation.

• Rule 40—Strive for Statelessness  — 无状态web应用；不大懂web开发；可能是将session信息存储在应用服务器端的成本太高
  

1. What: Design and implement stateless systems.
2. When to use: During design of new systems and redesign of existing systems.
3. How to use: Choose stateless implementations whenever possible. If stateful implementations are warranted for business reasons, refer to Rules 41 and 42.
4. Why: The implementation of state limits scalability and increases cost.

• Rule 41—Maintain Sessions in the Browser When Possible

1. What: Try to avoid session data completely, but when needed, consider putting the data in users’ browsers.
2. When to use: Anytime that you need session data for the best user experience.
3. How to use: Use cookies to store session data on the users’ browsers.
4. Why: Keeping session data on the users’ browsers allows the user request to be served by any Web server in the pool and takes the storage requirement away from your system.
5. Key takeaways: Using cookies to store session data is a common approach and has advantages in terms of ease of scale but also has some drawbacks. One of the most critical cons is that unsecured cookies

• Rule 42—Make Use of a Distributed Cache for States –可以将session信息持久化到数据库中，同时在应用服务器和数据库之前提供一层高可用的cache；
  

1. What: Use a distributed cache when storing session data in your system.
2. When to use: Anytime you need to store session data and cannot do so in users’ browsers.
3. How to use: Watch for some common mistakes such as a session management system that requires affinity of a user to a Web server.
4. Why: Careful consideration of how to store session data can help ensure your system will continue to scale.
5. Key takeaways: Many Web servers or languages offer simple server-based session management, but these are often fraught with problems such as user affiliation with specific servers. Implementing a distributed cache will allow you to store session data in your system and continue to scale.

网络实施

• Rule 20—Leverage CDNs  — 收益和成本的balance
  

1. What: Use CDNs to offload traffic from your site.
2. When to use: Ensure it is cost justified and then choose which content is most suitable.
3. How to use: Most CDNs leverage DNS to serve content on your site’s behalf.
4. Why: CDNs help offload traffic spikes and are often economical ways to scale parts of a site’s traffic.
5. Key takeaways: CDNs are a fast and simple way to offset spikiness of traffic as well as traffic growth in general. Ensure you perform a cost-benefit analysis and monitor the CDN usage.

• Rule 6—Use Homogenous Networks

1. What: Don’t mix the vendor networking gear.
2. When to use: When designing or expanding your network.
3. How to use:
   + Do not mix different vendors’ networking gear (switches and routers).
   + Buy best of breed for other networking gear (firewalls, load balancers, and so on).
4. Why: Intermittent interoperability and availability issues simply aren’t worth the potential cost savings.
5. Key takeaways: Heterogeneous networking gear tends to cause availability and scalability problems. Choose a single provider.

数据库相关

• Rule 31—Be Aware of Costly Relationships  — FK约束会对数据库的分库分表等行为有一定限制

1. What: Be aware of relationships in the data model.
2. When to use: When designing the data model, adding tables/columns, or writing queries consider how the relationships between entities will affect performance and scalability in the long run.
3. How to use: Think about database splits and possible future data needs as you design the data model.
4. Why: The cost of fixing a broken data model after it has been implemented is likely 100x as much as fixing it during the design phase.
5. Key takeaways: Think ahead and plan the data model carefully. Consider normalized forms, how you will likely split the database in the future, and possible data needs of the application.

• Rule 14—Use Databases Appropriately   — 选择传统关系数据库？
  

1. What: Use relational databases when you need ACID properties to maintain relationships between your data. For other data storage needs consider more appropriate tools.
2. How to use: Consider the data volume, amount of storage, response time requirements, relationships, and other factors to choose the most appropriate storage tool.
   Why: RDBMSs provide great transactional integrity but are more difficult to scale, cost more, and have lower availability than many other storage options.
3. Key takeaways: Use the right storage tool for your data. Don’t get lured into sticking everything in a relational database just because you are comfortable accessing data in a database.

• Rule 7—Design to Clone Things (X Axis)   –（复制:一写N读）

1. What: Typically called horizontal scale, this is the duplication of services or databases to spread transaction load.
2. How to use:
   + Simply clone services and implement a load balancer.
   + For databases, ensure the accessing code understands the difference between a read and a write.

• Rule 8—Design to Split Different Things (Y Axis) — 按照function或者service分库
• Rule 9—Design to Split Similar Things (Z Axis) — 分表

1. What: This is often a split by some unique aspect of the customer such as customer ID, name, geography, and so on.
2. When to use:Very large, similar data sets such as large and rapidly growing customer bases.
3. How to use: Identify something you know about the customer, such as customer ID, last name, geography, or device and split or partition both data and services based on that attribute.
4. Why: Rapid customer growth exceeds other forms of data growth or you have the need to perform “fault isolation” between certain customer groups as you scale.

• Rule 35—Don’t Select Everything

1. What: Don’t use Select * in queries.
2. When to use: Never select everything (unless of course you are going to use everything).
3. How to use: Always declare what columns of data you are selecting or inserting in a query.
4. Why: Selecting everything in a query is prone to break things when the table structure changes and it transfers unneeded data.
5. Key takeaways: Don’t use wildcards when selecting or inserting data.

Datacenter实施

• Rule 12—Scale Out Your Data Centers

1. What: Design your systems to have three or more live data centers to reduce overall cost, increase availability, and implement disaster recovery.
2. When to use: Any rapidly growing business that is considering adding a disaster recovery (cold site) data center.
3. How to use: Split up your data to spread across data centers and spread transaction load across those data centers in a “multiple live” configuration. Use spare capacity for peak periods of the year.

运维

• Rule 30—Discuss and Learn from Failures

1. What: Leverage every failure to learn and teach important lessons.
2. How to use: Employ a postmortem process and hypothesize failures in low failure environments.
3. Why:We learn best from our mistakes—not our successes.
   Key takeaways: Never let a good failure go to waste. Learn from every one and identify the technology, people, and process issues that need to be corrected.

• Rule 27—Learn Aggressively  — 27&30 2个rules都是为了避免incident成为mistake
  

1. When to use: Be constantly learning from your mistakes as well as successes.
2. How to use: Watch your customers or use A/B testing to determine what works. Use postmortems to learn from incidents and problems in production.
3. Why: Doing something without measuring the results or having an incident without learning from it are wasted opportunities that your competitors are taking advantage of.

• Rule 16—Actively Use Log Files  — for DW or troubleshooting
  

1. What: Use your application’s log files to diagnose and prevent problems.
   When to use: Put a process in place that monitors log files and forces people to take action on issues identified.
2. How to use: Use any number of monitoring tools from custom scripts to Splunk to watch your application logs for errors. Export these and assign resources for identifying and solving the issue.
3. Why: The log files are excellent sources of information about how your application is performing for your users; don’t throw this resource away without using it.
4. Key takeaways: Make good use of your log files and you will have fewer production issues with your system.

• Rule 29—Failing to Design for Rollback Is Designing for Failure — 减少失败就是提高可用性
• Rule 49—Design Your Application to Be Monitored

1. What: Think about how you will need to monitor your application as you are designing it.
2. When to use: Anytime you are adding or changing modules of your code base.
3. How to use: Build hooks into your system to record transaction times.
4. Why: Having insight into how your application is performing will help answer many questions when there is a problem.
5. Key takeaways: Adopt as an architectural principle that your application must be monitored. Additionally, look at your overall monitoring strategy to make sure you are first answering the question of “Is there a problem?” and then the “Where” and “What.”

• Rule 47—Purge, Archive, and Cost-Justify Storage  — 真对OLTP数据库，归档数据可以保证cache命中率
  

1. What: Match storage cost to data value, including removing data of value lower than the costs to store it.
2. Why: Not all data is created equal (that is, of the same value) and in fact it often changes in value over time.Why then should we have a single storage solution with equivalent cost for that data?
3. Key takeaways: It is important to understand and calculate the value of your data and to match storage costs to that value. Don’t pay for data that doesn’t have a stakeholder return.

标记下，5个半月第一次摔地上。

以下是阅读MongoDB.in.Action一些读书笔记，都是”点”：主要是MongoDB模式设计和维护相关。包括

1. Embed versus reference 例如blog中如何实现post和comments
2. One-to-many:
3. Many-to-many: Products and categories之间多对多的relation展现（一个product属于很多category，一个category可以有很多product）
4. Tree: 如论坛留言
5. Dynamic attributes 是否引入嵌入式文档
6. namespaces文件的限制
7. mmap– MongoDB如何使用内存
8. 内存是如何影响性能的，推荐是index都被缓存在内存中
9. Limits on document size
10. Custom types，例如存储带有时区的时间
11. a single global reader-writer lock 如何影响并行
12. 因为单一global RW lock对创建/重建索引的影响
13. WHEN TO SHARD
14. indexes in shard
15. Sharding an existing collection
16. MANUAL PARTITIONING

Embed versus reference 例如blog中如何实现post和comments

Suppose you’re building a simple application in MongoDB that stores blog posts and comments. How do you represent this data? Do you embed the comments in their respective blog post documents? Or is it better to create two collections, one for posts and the other for comments, and then relate the comments to the posts with an object id reference?
This is the problem of embedding versus referencing, and it’s a common source of confusion for new users of MongoDB. Fortunately, there’s a simple rule of thumb that works for most schema design scenarios: Embed when the child objects always appear in the context of their parent. Otherwise, store the child objects in a separate collection.
What does this mean for blog posts and comments? It depends on the application. If the comments always appear within a blog post, and if they don’t need to be ordered in arbitrary ways (by post date, comment rank, and so on), then embedding is fine. But if, say, you want to be able to display the most recent comments, regardless of which post they appear on, then you’ll want to reference. Embedding may provide a slight performance advantage, but referencing is far more flexible.

但要注意MongoDB对单一文档有大小限制，不同版本可能不一样。如果将post和comments都存储在一个文档中，需要注意大小。

One-to-many : embedding or referencing.

As stated in the previous section, you can represent a one-to-many relationship by either embedding or referencing. You should embed when the many object intrinsically belongs with its parent and rarely changes.

embedding example: step and sub-steps

{ title: “How to soft-boil an egg”,
steps: [
250 APPENDIX B Design patterns
{ desc: “Bring a pot of water to boil.”,
materials: [”water”, “eggs”] },
{ desc: “Gently add the eggs a cook for four minutes.”,
materials: [”egg timer”]},
{ desc: “Cool the eggs under running water.” },
]
}

referencing example: post and comments

a sample of post document = { _id: ObjectId(”4d650d4cf32639266022018d”),
title: “Cultivating herbs”,
text: “Herbs require occasional watering…”
}

A sample of comment document = { _id: ObjectId(”4d650d4cf32639266022ac01″),
post_id: ObjectId(”4d650d4cf32639266022018d”),
username: “zjones”,
text: “Indeed, basil is a hearty herb!”
}

we need index on comments collection : db.comments.ensureIndex({post_id: 1})

Many-to-many: Products and categories之间多对多的relation展现（一个product属于很多category，一个category可以有很多product）

here’s a sample product from a gardening store.

a sample of product doc =
{ _id: new ObjectId(”4c4b1476238d3b4dd5003981″),
slug: “wheel-barrow-9092″,
sku: “9092″,
name: “Extra Large Wheel Barrow”,
description: “Heavy duty wheel barrow…”,
details: {
weight: 47,
weight_units: “lbs”,
model_num: 4039283402,
manufacturer: “Acme”,
color: “Green”
},
total_reviews: 4,
average_review: 4.5,pricing: {
retail: 589700,
sale: 489700,
},
price_history: [
{retail: 529700,
sale: 429700,
start: new Date(2010, 4, 1),
end: new Date(2010, 4,
},
{retail: 529700,
sale: 529700,
start: new Date(2010, 4, 9),
end: new Date(2010, 4, 16)
},
],
category_ids: [new ObjectId(”6a5b1476238d3b4dd5000048″),
new ObjectId(”6a5b1476238d3b4dd5000049″)],
main_cat_id: new ObjectId(”6a5b1476238d3b4dd5000048″),
tags: [”tools”, “gardening”, “soil”],
}

a sample of category doc =
{ _id: new ObjectId(”6a5b1476238d3b4dd5000048″),
slug: “gardening-tools”,
ancestors: [{ name: “Home”,
_id: new ObjectId(”8b87fb1476238d3b4dd500003″),
slug: “home”
},
{ name: “Outdoors”,
Listing 4.2 A category document
Designing an e-commerce data model 61
_id: new ObjectId(”9a9fb1476238d3b4dd5000001″),
slug: “outdoors”
}
],
parent_id: new ObjectId(”9a9fb1476238d3b4dd5000001″),
name: “Gardening Tools”,
description: “Gardening gadgets galore!”,
}

如果category的name并不经常变化，但经常要查询属于某个category下的product，则可以将category name也加入到product文档中。

Tree: 例如如下论坛留言的形式，每条记录需要级录其parent

each node in the tree contains a path field. This field stores the concatenation of each of the node’s ancestor’s IDs, and root-level nodes have a null path because they have no ancestors.

{ _id: ObjectId(”4d692b5d59e212384d95001″),
depth: 0,
path: null,
created: ISODate(”2011-02-26T17:18:01.251Z”),
username: “plotinus”,
body: “Who was Alexander the Great’s teacher?”,
thread_id: ObjectId(”4d692b5d59e212384d95223a”)
}

Examine the first of these, and note that path contains the _id of the immediate parent:

{ _id: ObjectId(”4d692b5d59e212384d951002″),
depth: 1,
path: “4d692b5d59e212384d95001″,
created: ISODate(”2011-02-26T17:21:01.251Z”),
username: “asophist”,
body: “It was definitely Socrates.”,
thread_id: ObjectId(”4d692b5d59e212384d95223a”)
}

The next deeper comment’s path contains both the IDs of the original and immediate parents, in that order and separated by a colon:

{ _id: ObjectId(”4d692b5d59e212384d95003″),
depth: 2,
path: “4d692b5d59e212384d95001:4d692b5d59e212384d951002″,
created: ISODate(”2011-02-26T17:21:01.251Z”),
username: “daletheia”,
body: “Oh you sophist…It was actually Aristotle!”,
thread_id: ObjectId(”4d692b5d59e212384d95223a”)
}

some indexes are needed.

db.comments.ensureIndex({thread_id: 1})
db.comments.ensureIndex({path: 1})

Dynamic attributes 是否引入嵌入式文档

In a single products collection, you can then store disparate product types. You might store a set of headphones

{ _id: ObjectId(”4d669c225d3a52568ce07646″)
sku: “ebd-123″
name: “Hi-Fi Earbuds”,
type: “Headphone”,
attrs: { color: “silver”,
freq_low: 20,
freq_hi: 22000,
weight: 0.5
}
}

and an SSD drive:

{ _id: ObjectId(”4d669c225d3a52568ce07646″)
sku: “ssd-456″
name: “Mini SSD Drive”,
type: “Hard Drive”,
attrs: { interface: “SATA”,
capacity: 1.2 * 1024 * 1024 * 1024,
rotation: 7200,
form_factor: 2.5
}
}

If you need to frequently query on these attributes, you can create sparse indexes for them. For example, you can optimize for range queries in headphone frequency response:

db.products.ensureIndex({”attrs.freq_low”: 1, “attrs.freq_hi”: 1},{sparse: true})

You can also efficiently search hard disks by rotation speed with the following index:

db.products.ensureIndex({”attrs.rotation”: 1}, {sparse: true})

If your attributes are completely unpredictable, then you can’t build a separate index for each one. You have to use a different strategy in this case as illustrated by the following sample document:

{ _id: ObjectId(”4d669c225d3a52568ce07646″)
sku: “ebd-123″
name: “Hi-Fi Earbuds”,
type: “Headphone”,
attrs: [ {n: “color”, v: “silver”},
{n: “freq_low”, v: 20},
{n: “freq_hi”, v: 22000},
{n: “weight”, v: 0.5}
]
}

Here attrs points to an array of sub-documents. Each of these documents has two values,n and v, corresponding to each dynamic attribute’s name and value. This normalized representation allows you to index these attributes using a single compound index:

db.products.ensureIndex({”attrs.n”: 1, “attrs.v”: 1})

You can then query using these attributes, but to do that, you must use the $elemMatch query operator:

db.products.find({attrs: {$elemMatch: {n: “color”, v: “silver”}}})

这个设计还是挺拧的；

namespaces文件的限制

The database files themselves are all named after the database they belong to. garden.ns is the first file to be generated. The file’s extension, ns, stands for namespaces. Every collection and index in a database gets its own namespace, and the metadata for each namespace is stored in this file. By default, the .ns file is fixed to 16 MB, which lets it store approximately 24,000 namespaces. This means that the sum of the number of indexes and collections in your database can’t exceed 24,000. You’re not likely to need anywhere close to this number of collections or indexes. But on the off chance that you need even more, you can makes the file larger by using the –nssize server option.

Limits on document size

BSON documents in MongoDB v2.0 are limited to 16 MB in size.

If you’re simply storing large binary objects, like images or videos, that’s a slightly different case — GridFS.

The number has varied by server version and is continually increasing. To see the limit for your server version,run db.ismaster from the shell, and examine the maxBsonObjectSize field. If you can’t find this field, then the limit is 4 MB (and you’re using a very old version of MongoDB).

mmap– MongoDB如何使用内存

MongoDB tells the operating system to map all data files to memory using the mmap() system call. From this point on, the data files,which include all documents, collections, and their indexes, are swapped in and out of RAM by the operating system in 4 KB chunks called pages.

Whenever data from a given page is requested, the operating system must ensure that the page is available in RAM. If it’s not, then a kind of exception known as a page fault is raised, and this tells the memory manager to load the page from disk into RAM.With sufficient RAM, all of the data files in use will eventually be loaded into memory.

Whenever that memory is altered, as in the case of a write, those changes will be flushed to disk asynchronously by the OS, but the write will be fast, occurring directly in RAM. When data fits into RAM, you have the ideal situation because the number of disk accesses is reduced to a minimum. But if the working data set can’t fit into RAM, then page faults will start to creep up. This means that the operating system will begoing to disk frequently, greatly slowing read and write operations. In the worst case, as data size becomes much larger than available RAM, a situation can occur where, for any read or write, data must be paged to and from disk. This is known as thrashing, and it causes performance to take a severe dive.

MongoDB中read block write，较长时间的磁盘访问会降低并行和吞吐量。

内存是如何影响性能的，推荐是index都被缓存在内存中

It’s important to keep an eye on total index size, as database performance will be best
when all utilized indexes can fit in RAM.

db.stats()
{
“collections” : 3,
“objects” : 10004,
“avgObjSize” : 36.005,
“dataSize” : 360192,
“storageSize” : 791296,
“numExtents” : 7,
“indexes” : 1,
“indexSize” : 425984,
“fileSize” : 201326592,
“ok” : 1
}

Custom types，例如存储带有时区的时间

But what if you must store your times with their time zones? Sometimes the basic BSON types don’t suffice. Though there’s no way to create a custom BSON type, you can compose the various primitive BSON values to create your own virtual type. For instance, if you wanted to store times with zone, you might use a document structure like this, in Ruby

{:time_with_zone =>
{:time => Time.utc.now,
:zone => “EST”
}
}

算是充分利用文档结构的数据类型

a single global reader-writer lock 如何影响并行

It’s important to understand how concurrency works in MongoDB.

As of MongoDB v2.0, the locking strategy is rather coarse; a single global reader-writer lock reigns over the entire mongod instance. What this means is that at any moment in time, the database permits either one writer or multiple readers (but not both). This sounds a lot worse than it is in practice because there exist quite a few concurrency optimizations around this lock.

One is that the database keeps an internal map of which document are in RAM. For requests to read or write documents not residing in RAM, the database yields to other operations until the document can be paged into memory.

A second optimization is the yielding of write locks. The issue is that if any one write takes a long time to complete, all other read and write operations will be blocked for the duration of the original write. All inserts, updates, and removes take a write lock. Inserts rarely take a long time to complete. But updates that affect, say, an entire collection, as well as deletes that affect a lot of documents, can run long. The current solution to this is to allow these long-running ops to yield periodically for other readers and writers. When an operation yields, it pauses itself, releases its lock, and resumes later. But when updating and removing documents, this yielding behavior can be amixed blessing. It’s easy to imagine situations where you’d want all documents updated or removed before any other operation takes place.

For these cases, you can use a special option called $atomic to keep the operation from yielding. You simply add the $atomic operator to the query selector like so:

db.reviews.remove({user_id: ObjectId(’4c4b1476238d3b4dd5000001′),{$atomic: true}})

The same can be applied to any multi-update. This forces the entire multi-update to complete in isolation:

db.reviews.update({$atomic: true}, {$set: {rating: 0}}, false, true)

This update sets each review’s rating to 0. Because the operation happens in isolation,the operation will never yield, ensuring a consistent view of the system at all times.

因为单一global RW lock对创建/重建索引的影响

you can check the index build progress by running the shell’s currentOp() method:10

> db.currentOp()
{”inprog” : [{”opid” : 58,
“active” : true,
“lockType” : “write”,
“waitingForLock” : false,
“secs_running” : 55,
“op” : “insert”,
“ns” : “stocks.system.indexes”,
“query” : {},
“client” : “127.0.0.1:53421″,
“desc” : “conn”,
“msg” : “index: (1/3) external sort 3999999/4308303 92%”}]}

The last field, msg, describes the build’s progress.

Note also the lockType, which indicates that the index build takes a write lock. This means that no other client can read or write from the database at this time. If you’re running in production, this is obviously a bad thing, and it’s the reason why long index builds can be so vexing. We’re going to look right now at two possible solutions to this problem.

Background indexingIf you’re running in production and can’t afford to halt access to the database, you can specify that an index be built in the background. Although the index build will still take a write lock, the job will yield to allow other readers and writers to access the database. If your application typically exerts a heavy load on MongoDB, then a background index build will degrade performance, but this may be acceptable under certain circumstances. For example, if you know that the index can be built within a time window where application traffic is at a minimum, then background indexing in this case might be a good choice.

To build an index in the background, specify {background: true} when you declare the index. The previous index can be built in the background like so:

db.values.ensureIndex({open: 1, close: 1}, {background: true})

Offline indexing

If your production data set is too large to be indexed within a few hours, then you’ll need to make alternate plans. This will usually involve taking a replica node offline, building the index on that node by itself, and then allowing the node to catch up with the master replica. Once it’s caught up, you can promote the node to primary and then take another secondary offline and build its version of the index. This tactic presumes that your replication oplog is large enough to prevent the offline node from becoming stale during the index build.

You can do this by dropping and recreating individual indexes or by running the reIndex command, which will rebuild all indexes for a given collection:

db.values.reIndex();

Be careful about reindexing: the command will take out a write lock for the duration of the rebuild, temporarily rendering your MongoDB instance unusable. Reindexing is best done offline, as described earlier for building indexes on a secondary. Note that the compact command,  will also rebuild indexes for the collection on which it’s run.

WHEN TO SHARD

The question of when to shard is more straightforward than you might expect. We’ve talked about the importance of keeping indexes and the working data set in RAM, and this is the primary reason to shard.

If an application’s data set continues to grow unbounded, then there will come a moment when that data no longer fits in RAM.

To be sure, there are some fudge factors here. For instance, if you have your own hardware and can store all your data on solid state drives (an increasingly affordable prospect), then you’ll likely be able to push the data-to-RAM ratio without negatively affecting performance.

Whatever the case, the decision to shard an existing system will always be based on regular analyses of disk activity, system load, and the ever-important ratio of working set size to available RAM.

indexes in shard

a few more points about indexes should bekept in mind when running a sharded cluster.

1 Each shard maintains its own indexes. This should be obvious, but to be clear,know that when you declare an index on a sharded collection, each shard builds a separate index for its portion of the collection. For example, when you issued the db.spreasheets.ensureIndex() command via mongos in the previous section, each individual shard processed the index creation command individually.

2 It follows that the sharded collections on each shard should have the same indexes. If this ever isn’t the case, you’ll see inconsistent query performance.

3 Sharded collections permit unique indexes on the _id field and on the shard key only. Unique indexes are prohibited elsewhere because enforcing them would require intershard communication, which is complicated and still deemed too slow to be worth implementing.

Sharding an existing collection

You can shard existing collections, but don’t be surprised if it takes some time to distribute the data across shards. Only one balancing round can happen at a time, and the migrations will move only around 100-200 MB of data per minute. Thus, sharding a 50 GB collection will take around eight hours, and this will likely involve some moderate disk activity.

In addition, when you initially shard a large collection like this, you may have to split manually to expedite the sharding process, since splitting is triggered by inserts.

最好还是从一开始就设计好sharding

MANUAL PARTITIONING

There are a couple of cases where you may want to manually split and migrate chunks on a live shard cluster. For example, as of MongoDB v2.0, the balancer doesn’t directly take into account the load on any one shard. Obviously, the more a shard is written to, the larger its chunks become, and the more likely they are to eventually migrate. Nevertheless, it’s not hard to imagine situations where you’d be able to alleviate load on a shard by migrating chunks. This is another situation where the movechunk command can be helpful.

> sh.splitAt( “cloud-docs.spreadsheets”,
{ “username” : “Chen”, “_id” : ObjectId(”4d6d59db1d41c8536f001453″) })

> sh.moveChunk(”cloud-docs.spreadsheets”, {username: “Chen”}, “shardB”)

比方说hot chunk,通过手工migration，可以将hot chunk分散到多个shards中。

宝宝目前只会主动的往右侧翻身，猜测如果是左撇子的话，小孩会不会往左侧翻身。

宝宝喜欢电视了，而且看电视的时候特别老实，不乱动。白天录制的DV，晚上关灯投影在墙上，宝宝看的一动不动的，也不翻身也不搓脚，对小孩非常具有吸引力。

最近开始给宝宝喂蛋黄，每天1/5个蛋黄混着水，宝宝也不拒绝；还用小勺子挖苹果沫沫喂宝宝，虽然拉过一次绿便，但宝宝精神头依然旺盛。

几棵大葱从13楼落下，成了这个模样。有的葱头摔没有了，有的葱肚子爆炸了，葱体都变的松软了。中午就把它们做成葱爆肉，应该很好吃。

谁的单位有鸭梨大想不开的，就多吃点大葱吧。

我无压力，最后表示，别担心我；大葱只是因为北风太大从阳台上吹落的。

可以同时使用以下解决方法:

1. 设置event让SMON不自动OFFLINE回滚段。

alter system set events ‘10511 trace name context forever, level 1′;

2. 设置参数_rollback_segment_count ：表示有多少rollback segment要处于online的状态；可以将该数值设置为数据库最繁忙的时候的回滚段数目。

alter system set “_rollback_segment_count”=;

3.  undo autotune bug多多。最好disable。

alter system set “_undo_autotune” = false;

4.  有一个patch: A fix to bug 7291739 is to set a new hidden parameter, _highthreshold_undoretention to set a high threshold for undo retention completely distinct from maxquerylen.

alter system set “_highthreshold_undoretention”=;

UNDO TABLESPACE是8i到9i最好的改进之一；可惜在10g中bug多多。

How to correct performance issues with enq: US - contention related to undo segments [ID 1332738.1]

Applies to:

Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 11.2.0.2 - Release: 9.2 to 11.2
Information in this document applies to any platform.
Purpose

Assist in correcting performance issues related to “enq: US Contention” on undo segments.

You have many offline undo segments and the workload starts to online many undo segments over a short period of time. This can lead to high ‘latch: row cache objects’ contention may be seen on dc_rollback_segments together with high ‘enq: US - contention’ waits when using system managed undo with an auto tuned undo retention period.

Sessions attempting to online undo segments should show ktusmous_online_undoseg() in their call stack.

Another aspect of the problem can be due to long running queries which can raise tuned_undoretention to very high values and exhausts the undo tablespace resulting in ORA-1628.

A real world case:
A query is being executed and some rows are fetched from the cursor and then the user stops working on that query (e.g. does not press the “next” button on the application screen) and works on something else (e.g. in a different window). After some time the user continues working on the query … auto-tune starts tracking the query from this point and the maxquerylen is quite large now, hence also the tuned_undoretention (that depends directly on the maxquerylen).

NOTE: The Seibel application can allow for this problem to happen.
Last Review Date

June 24, 2011
Instructions for the Reader
A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.
Troubleshooting Details

The wait event “enq: US Contention” is associated with contention on the latch in the row cache (dc_rollback_seg).  Enqueue US - Contention can become a bottle-neck for performance if workload dictates that a lot of offlined undo segments must be onlined over a short period of time. The latch on the row cache can be unable to keep up with the workload.

This can happen for a number of reasons and some scenarios are legitimate workload demands.

Solution:

Ensure that peaks in onlined undo segments do not happen (see workaround #2). That is not always feasible.

Workarounds:

1. Bounce the instance.

2. Setting _rollback_segment_count to a high number to keep undo segments online.

alter system set “_rollback_segment_count”=;

3. Set _undo_autotune to false

alter system set “_undo_autotune” = false;

NOTE: Simply using _smu_debug_mode=33554432 may not be enough to stop the problem, but valid fix for bug 5387030.

4. A fix to bug 7291739 is to set a new hidden parameter, _highthreshold_undoretention to set a high threshold for undo retention completely distinct from maxquerylen.

alter system set “_highthreshold_undoretention”=;

If problems persist, please file a Service Request with Oracle Support.

@ Diagnosis
@
@ Should the workarounds and/or configuration changes not help to alleviate the problems,
@ development would need the following diagnostics data:
@
@ a. Provide alert.log which shows the last instance startup parameters through the time of the
@ latest isssues.
@
@ b. AWR and/or ASH report of 30 or 60 minutes interval.
@
@ b. Following query output:
@
@ alter session set nls_date_format=’mm/dd/yy hh24:mi:ss’;
@ select begin_time, MAXQUERYID, MAXQUERYLEN from v$undostat;
@
@ c. While the error is ongoing:
@
@ On single instance:
@
@ sqlplus / as sysdba
@ oradebug setmypid
@ oradebug unlimit
@ oradebug hanganalyze 3
@ oradebug dump systemstate 266
@
@ wait for 5 seconds
@
@ oradebug dump systemstate 266
@
@ wait for 2 minutes
@
@ sqlplus / as sysdba
@ oradebug setmypid
@ oradebug unlimit
@ oradebug hanganalyze 3
@ oradebug dump systemstate 266
@
@ wait for 5 seconds
@
@ oradebug dump systemstate 266
@
@ On RAC get tracing on all nodes
@
@ sqlplus / as sysdba
@ oradebug setmypid
@ oradebug unlimit
@ oradebug -g all hanganalyze 3
@ oradebug -g all dump systemstate 266
@
@ wait for 5 seconds
@
@ oradebug -g all dump systemstate 266
@
@ wait for 2 minutes
@
@ sqlplus / as sysdba
@ oradebug setmypid
@ oradebug unlimit
@ oradebug -g all hanganalyze 3
@ oradebug -g all dump systemstate 266
@
@ wait for 5 seconds
@
@ oradebug -g all dump systemstate 266
References

BUG:12652689 - HIGH ENQ: US - CONTENTION AFTER UPGRADED TO 11.1.0.7.5
BUG:7279902 - US ENQUEUE CONTENTION OCCURS DUE TO WAITING FOR “GC CURRENT REQUEST”
BUG:7291739 - CONTENTION UNDER AUTO-TUNED UNDO RETENTION
BUG:9557199 - MASSIVE WAITS FOR ‘ENQ: US - CONTENTION’ AND ROW CACHE LOCK IN STRESS TEST
NOTE:5387030.8 - Bug 5387030 - Automatic tuning of undo_retention causes unusual extra space allocation
NOTE:7291739.8 - Bug 7291739 - Contention with auto-tuned undo retention or high TUNED_UNDORETENTION
NOTE:742035.1 - Contention Under Auto-Tuned Undo Retention

Article Rating Rate this document Excellent Good Poor Did this document help you? Yes No Just browsing How easy was it to find this document? Very easy Somewhat easy Not easy

Comments Provide feedback for this article. Please use ‘Contact Us’ for other feedback.