2008-09-03 Wed

01:39 记一次Oracle数据库无响应（hang住）的故障处理 (13939 Bytes) » 老熊的三分地

先说说这个数据库的环境：
Oracle 9.2.0.4 RAC，只不过这个RAC只运行了一个节点，另一节点没有开启。
AIX 5.3 TL04
主机为p550，4CPU，16G内存
应用为部署在Weblogic下的WEB应用。

故障现象：
首先是客户端的操作没有响应，从weblogic上看连接数非常高，其日志里面不停报超出连接池的最大连接数。在主机上用sqlplus “/ as sysdba”，在显示sqlplus的banner后，停止响应。

从故障现象来看，是数据库hang住了。

由于sqlplus不能操作，那么这个时候没办法通过oracle来dump system state。先看看操作系统里面，用topas命令观察，发现一个oracle进程占用了26%左右的CPU资源，IO等待几乎为0，可用的物理内存还比较多。根据那个占用CPU的进程号用ps命令查看，是一个普通的Server Process。

看来起这个进程陷入死循环了，26%的CPU资源正好是1个CPU（因为系统共4个CPU）。如果一个oracle进程拿到比较重要的资源，比如shared pool latch、library cache latch等，然后陷入了死循环（SPIN）后，其他进程没法解析SQL等，也就只有挂起了。

用kill命令杀掉那个进程，系统恢复正常，看来前面对故障的推断是正确的，不过没过几分钟，又出现了此故障现象。

只有找到oracle当时正在干什么，也能进行处理。用dbx来dump system state：

# dbx -a 446910
Waiting to attach to process 446910 …
Successfully attached to oracle.
Type ‘help’ for help.
reading symbolic information …
stopped in iosl.select at 0×9000000000c94d8 ($t2)
0×9000000000c94d8 (select+0xfffffffffff06318) e8410028 ld r2,0×28(r1)
(dbx) print ksudss(10)

Segmentation fault in slrac at 0×100083aa0 ($t2)
0×100083aa0 (slrac+0xe4) 88030000 lbz r0,0×0(r3)
(dbx) detach

分析trace文件：

Starting Systemstate 1
……………………………………………………………………
………………….
Ass.Awk Version 1.0.9 - Processing oa2_ora_446910.trc

System State 1
~~~~~~~~~~~~~~~~
1:
2: waiting for ‘pmon timer’ seq=16329
3:
4: waiting for ‘rdbms ipc message’ seq=33158
5: waiting for ‘ges remote message’ seq=30917
6: waiting for ‘gcs remote message’ seq=52339
7: waiting for ‘gcs remote message’ seq=52407
8: waiting for ‘rdbms ipc message’ seq=32661
9: waiting for ‘rdbms ipc message’ seq=32504
10: waiting for ‘rdbms ipc message’ seq=19573
11: waiting for ‘rdbms ipc message’ seq=52125
12: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=16415
13: waiting for ‘rdbms ipc message’ seq=270
14: waiting for ‘rdbms ipc message’ seq=3494
15: waiting for ‘rdbms ipc message’ seq=29593
16: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=54430
17: waiting for ‘rdbms ipc message’ seq=52224
18: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=23413
19: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=49796
20: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=20730
21: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=12464
Cmd: Select
22: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=34653
Cmd: Select
23: waiting for ‘latch free’ [Latch 7000001491d2850] seq=58618
24: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=36619
25: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=56192
26: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=60361
27: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=19963
28: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=10464
29: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=29548
30: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=15077
31: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=32472
32: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=17466
33: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=34712
34: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=27146
35: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=2911
36: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=16634
Cmd: Select
37: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=43400
38: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=8435
39: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=39939
40: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=59619
41: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=16259
42: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=21150

43: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=35843
44: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=27141
45: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=29400
46: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=51444
47: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=19142
48: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=1031
49: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=31852
50: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=46957
51: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=41609
52: waiting for ‘latch free’ [Latch 7000001491d2850] seq=57255
53: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=34982
54: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=26060
55: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=16070
56: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=63913
57: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=2724
58: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=42177
59: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=19973
60: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=47446
61: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=42112
Cmd: Select
62: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=927
63: waiting for ‘latch free’ [Latch 7000001491d2850] seq=3182
64: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=2347
65: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=18928
66: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=1512
67: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=53568
68: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=20420
69: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=30353
70: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=36936
71: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=50852
72: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=8533
73: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=31009
74: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=15406
75: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=4375
Cmd: Select
76: waiting for ‘library cache load lock’ seq=207
78: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=6165
79: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=22977
80: last wait for ‘SQL*Net message from client’
81: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=20226
82: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=17323
Cmd: Select
83: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=19680
84: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=5997
85: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=54166
Cmd: Select
86: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=61874
87: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=33285
88: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=16784
89: last wait for ‘latch free’
Cmd: Select
90: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=63834
91: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=42945
92: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=3676
93: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=59730
94: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=42691
Cmd: Update
95: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=41076
96: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=23230
97: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=64835
98: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=45314
99: waiting for ‘latch free’ [Latch 7000001491d2a40] seq=65301
100:waiting for ‘latch free’ [Latch 7000001491d2a40] seq=51423
101:waiting for ‘latch free’ [Latch 7000001491d2a40] seq=25171
Blockers
~~~~~~~~

Above is a list of all the processes. If they are waiting for a resource
then it will be given in square brackets. Below is a summary of the
waited upon resources, together with the holder of that resource.
Notes:
~~~~~
o A process id of ‘???’ implies that the holder was not found in the
systemstate.

Resource Holder State
Latch 7000001491d2a40 80: last wait for ‘SQL*Net message from client’
Latch 7000001491d2a40 89: last wait for ‘latch free’
Latch 7000001491d2850 26: 26: is waiting for 80: 89:

Object Names
~~~~~~~~~~~~
Latch 7000001491d2a40 Child library cache
Latch 7000001491d2850 Child library cache

很多进程都在等待library cache latch，而持有library cache latch的进程出现了异常，因而导致了数据库被hang住。对出现异常的进程进行分析，发现异常进程执行的SQL都是应用中的普通的SQL（并且后来出现异常的多个进程执行的SQL都不相同）。由于急需恢复应用，所以不得已先重启了数据库，再继续查找原因。

然而数据库重启只能使用1天，就会再次出现此类问题。
针对此故障，首先怀疑可能是BUG引起。但在确认BUG之前，需要收集足够多的证据。随后发现，这个数据库存在下面几个问题：

1、这个库的shared pool 设置很大，达到了4G。
2、应用没有使用绑定变量，全部都是拼接的SQL，并且没有使用任何存储过程，也就是应用的全部SQL都是硬解析。4G的shared pool可以在1天之内全部填满。
3、从alert日志文件里面看到，这个库经常因为ORA-04031错误崩溃。

看来这个库的问题比较严重。数据库hang住和ORA-04031应该都与硬解析过多有关。但目前改变应用是十分困难的事情。只好通过将cursor_sharing设置为similar，强制使用绑定变量。

将cursor_sharing设置为similiar之后，经过一段时间的观察，数据库运行正常，不再出现hang住的现象，hard parse从以前每秒数十次减少为每秒不到1次。shared pool的内存使用非常少，并且减少了shared_pool_size的设置。

不过cursor_sharing设置为similar有比较多的BUG，最常见的就是statspack的BUG和会有大量高version count的SQL。

对于OLTP系统来说，使用绑定变量，怎么强调都不过分。

  2008-09-02 Tue

22:55 因为信任，所以简单 --专访支付宝架构师团队 (2) (11122 Bytes) » DBA notes 
这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第二部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。

书接前文

支付宝每时每刻都要应对海量的数据和交易，是否使用了类似于"云计算"的方式进行后台处理？对于业界现在热炒的"云计算"概念，你们团队有什么想法？

的确，支付宝的数据堪称海量，但相比之下，主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算，但相对规模不算特别大，当前的计算能力足以支撑，当然，我们也尽量会想办法用更小的成本提供更强的计算能力。

对于云计算，我们目前还没找到很合适的应用场景，但整个架构组目前对云计算保持密切的关注，并会投入适当的力量进行一些前瞻性研究。我们实际上更为关注一些解决方案，比如 Hadoop ，并准备在 DW/BI 方面进行一些尝试。

冯大辉曾经在一个访谈中提到：技术架构与产品设计这两者的优劣，会对 Web 应用的发展起到至关重要的作用，那么这二者应该如何平衡？在支付宝进行架构设计和产品设计时，是怎么样进行权衡的？

通常情况下我们的技术架构是可支撑产品设计的多样性需求的,但仍有部分产品设计因市场的差异化需求非常特殊,造成我们的技术架构要支撑这部分产品产生了一定的挑战,这也是因为我们的所处的行业是一个迅速发展的行业有关,一方面我们加强技术架构的灵活性和前瞻性研究，另一方面我们也同时加强对产品设计的规范指导,使其两者达到平衡。

我们在技术架构的发展上做了很多课题性研究,如遇到新产品的设计技术架构无法支撑的情况下我们对产品所带来的收益与需扩展技术架构的投入成本上做出分析权衡.

高性能设计中缓存技术是最常用到的，您们在架构设计中通常怎样考虑缓存问题？

现代大型系统中，Cache 是个非产关键的组件，在具体实践中，我们会依据支付宝自身的数据特点对数据部署缓存策略，支付宝对数据实时性的要求造成Cache的准确性要求极高，而数据的私有性造成提高Cache命中率难度较大。客观地说，目前对于 Cache 的利用应该说还不是很充分，这有待于我们进行更深入的研究。

简单的说几点经验，一个是要合理的选择 Cache 所在的位置. 简单的说，Cache 的位置有几个地方:

Web服务器层 -> 应用服务器层 -> 数据库层

具体使用哪个 Cache 以及在哪个位置来做 Cache，要依据缓存什么、性能要求、数据量、可伸缩性、事务要求、过期特性、一致性要求、可复制性、硬件投资、开发投资多个维度来考虑。如果 Cache 的位置选择不合适，那么系统伸缩性会受到严重影响，每次 Cache 系统实施之前，需要架构师进行充分的论证和评估。

第二点，在Cache 存储的资源粒度，需依据 Cache 资源的特点，比如登录者基本信息，就完全可以一次性缓存起来，对于聚合关系结构的业务对象，在缓存的时候需要考虑业务特点，如果业务上对聚合对象内部的对象访问就很频繁，那么就考虑选择小对象力度缓存，否则考虑大粒度对象。第二点是Cache自身的特点，本地JVM Cache，可以考虑存储大对象，因为此时没有网络访问、数据流量的考虑，那么即使业务上小对象访问比较多，也可以考虑完全缓存整个对象关系；如果是远程 cache，那么就要依据大粒度和小粒度对象访问的频率，然后决定。

Cache 是个非常庞大的话题，如有必要，可以选择另外的时间进行探讨。

分布式是架构设计中最有挑战的任务，您们在分布式设计中主要从什么角度出发？怎样选择按用户拆分和功能拆分？

考虑到支付宝的业务特点， 无论我们做什么应用，安全性、可靠性肯定是排在第一位的。然后我们会重点考虑性能和可扩展性。支付宝现在已经是最大的第三方支付工具，日益增长的交易量给架构师们带来了很大的挑战。我们在具体实践中也从BASE 策略中得到很大参考：

Basically Availble --基本可用
Soft-state --软状态(柔性状态)
Eventual Consistency --最终一致性

目前的拆分原则主要是遵循 SOA 的思路，面向服务进行拆分，这也是基本原则之一。 至于是否按照用户拆分，只要不违背 SOA 即可。

对于开放平台、开放 API、以及SaaS这些互联网的新风潮，支付宝架构团队有什么看法？

开放平台这个词最近确实非常火，好像一夜之间大家都开放了。开放确实是一种趋势，任何一个互联网公司都只是整个互联网生态圈中的一环，只有开放才能让自己更好的融入到整个生态圈中。这是大方向，大方向确定了，剩下的事情就是如何开放，开放什么的问题了，这也是每个互联网公司需要仔细考虑的问题。

我觉得随着公司业务的不断发展，开放是一个必然的结果，我们在支付宝创建初期就意识到整个支付市场是非常大的，在服务好淘宝的基础上应该大胆的走出去，去为更多的电子商务平台提供支付服务。所以，我们很早就推出了支付宝商户平台，在这个平台上我们提供了大量的交易、支付服务。通过这几年的运营，我们确实尝到了开放的好处（外部商户为我们的交易量做出了很大贡献），同时我们也积累了很多开放的经验。目前我们正在开发一套新的开放平台，我们希望通过这个平台，可以为我们的合作伙伴提供更多、更好的服务，同时也希望有更多的第三方公司能在我们提供的基础服务之上，创造出新的商业模式。

如果说"面向服务架构"使企业IT系统支持业务敏捷化的话，开放平台则是使互联网大系统支持整个行业生态圈的业务敏捷化。开放平台、是企业追求开放式成长的必然道路，也是SOA原则走出企业系统的狭小圈子、在广袤互联网上的自然延伸。以支付宝的实践来看，在2005年中，支付宝就针对互联网交易提供了API，为互联网上的电子商务提供安全交易与资金流解决方案。随着业务领域不断拓展，原来的从需求->解决方案->产品->API的方式，周期太长，已经难以快速满足大量合作伙伴的需求。因此，支付宝现在正在由产品式的开放转向平台式的开放，通过加强开放基础设施的建设，向合作伙伴提供更基础、更可重用、更体系化的服务，达到与合作伙伴充分协同，建设繁荣、共赢的电子商务生态圈的目标。

同时，开放的业务服务与开放的技术平台也正在推动支付宝的业务与技术架构向前发展，对构建更大规模的分布式系统、更大规模的并行研发模式都带来了积极而深远的影响。

对于有志于成为架构师的开发者，支付宝架构团队有何建议？

技术不是一蹴而就的事情，而是长时间积累的成果。此外，扎实的基本功是做好所有事情的开始！抽象的能力也是作为一名好的程序员必须具备的，我们在考虑问题的时候可能会遇到错综复杂的场景，从这些迷雾中找到一条明路是我们做好程序员的关键。实际抽象能力衍生出来的一点就是需要我们对已学过的知识定期的进行梳理，这样能让你稳固已有的知识，为以后学习的更多的知识做好准备。

实践也是非常重要的一个环节，不要有畏难心里，觉得这个东西非常的难，我无法完成！有时候你去完成一件事情，事情的结果可能会是糟糕的，但是解决这件事情的过程是非常宝贵的，你可以在这个过程中学习到很多东西！最后我还要说一点的是，业务知识非常重要，这个是你实践的关键！(by 胡喜)

架构师在设计系统架构，或者对重大问题进行决策时，必须在全面考虑各种因素、充分前瞻的基础上做出全局最优的选择。这种整体性与发展性的思考模式是一种能力，也是一种习惯，一种态度。作为有志于成为架构师的开发者，应该在日常开发中就养成站在整体、发展的角度去理解、分析、与解决问题的习惯。(by 程立)

再补充三点:

  • 1、从程序员到架构师：是思维提升的一个过程、责任心升华的一个过程、是一楼向楼顶攀爬的一个过程，每一层楼，都要向下、向上、向远处看(注：这个楼顶有多高？没人知道 ：） ；
  • 2、读别人的代码、框架，看身边同事做事情，与同事一起讨论问题等，要始终尝试：交换思想的苹果，达到 1 + 1 > 2 ；
  • 3、找一个架构师老师，榨取他身上的每一点优点(别把坏的也给学去了) ；
(by 姚建东)

架构师在成长过程是个顿悟的过程，需要自己注意及时总结，尤其是不可能不犯错误，但是需要自己通过每次所犯的错误进行深刻的总结提升自己。提升的过程是个螺旋式上升的过程，自己以前也做失败过一个案例，至今记忆深刻，通过这次深刻的教训，对自己的成长是很有帮助的。遇到错误不要怕，要坦然面对，能做到:犯错误-->提升-->避免错误就可以了。(by 王学安)

1，架构师往往是领域专家，持续关注领域发展和创新、领域知识，了解领域需求，并将领域需求不断的融入到架构模型里，侧重领域功能布局。
2，架构师往往是技术专家，持续的关注技术知识，架构模式，设计模式以及技术规范等，技术架构关注点可以是，开发高效、复用、安全、可维护可管理、灵活等。
3，实践出真知，持续关注领域、技术，勇于实践。( by 刘明源)

附录：可能有的朋友已经知道支付宝的花名文化，这次接受采访的同事花名可以列一下：鲁肃、苗人凤、西毒、阿玺、邓芝、庞统、夫差、李磊、俊义。(猎头们就别盯着这里看了，做点有技术含量的事儿吧)

--EOF--

20:55 oracle 11g standby query error: ora-08103 and ora-01410 (13811 Bytes) » Alibaba DBA Team

范鑫做的测试，我转过来。看起来很简单的一件事情，由于具有偶然性，不能每次都重现，所以特地记录下来，一直报的 ORA-08103: object no longer exists 是由于 standby 上的查询进程导致 ，把standby 激活后查询就正常了

当然这里要交代一下前提，就是在主数据库上有一个job，每天晚上将一个表truncate再插入数据，第二天就发现standby上查询错误，在主数据库上move表之后恢复正常。 但是手工做 truncate却取法重现，重新做个job任务偶尔重现，也不是一定得到这个现象。目前正在进一步测试中，但至少发现了 11g的 standby提供适时查询功能是存在缺陷的。当然不truncate就没问题。

测试在一个已经存在问题的standby上进行，先以standby模式open，再open read only，最后激活open：

 

oracle@ctr_db1:/home/oracle>export ORACLE_SID=testctrdmsb2

oracle@ctr_db1:/home/oracle>sqlplus /nolog

 

SQL*Plus: Release 11.1.0.6.0 - Production on Wed Sep 3 10:28:45 2008

 

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

 

@>

@>sqlplus /nolog

SP2-0734: unknown command beginning “sqlplus /n…” - rest of line ignored.

@>conn / as sysdba

Connected.

sys@CTRDM_DB1>

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

                         *

ERROR at line 1:

ORA-01410: invalid ROWID

 

 

sys@CTRDM_DB1>select count(*) from mcc.testd2;

 

  COUNT(*)

———-

      1127

 

sys@CTRDM_DB1>

sys@CTRDM_DB1>

sys@CTRDM_DB1>

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

 

Total System Global Area 2004340736 bytes

Fixed Size                  2145744 bytes

Variable Size             402653744 bytes

Database Buffers         1593835520 bytes

Redo Buffers                5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open ;

 

Database altered.

 

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

                         *

ERROR at line 1:

ORA-08103: object no longer exists

 

 

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

 

Total System Global Area 2004340736 bytes

Fixed Size                  2145744 bytes

Variable Size             402653744 bytes

Database Buffers         1593835520 bytes

Redo Buffers                5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open read only;

 

Database altered.

 

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

select count(*) from mcc.sync_job_status

                         *

ERROR at line 1:

ORA-08103: object no longer exists

 

 

sys@CTRDM_DB1>

sys@CTRDM_DB1>shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

sys@CTRDM_DB1>

sys@CTRDM_DB1>

sys@CTRDM_DB1>

sys@CTRDM_DB1>startup mount;

ORA-32004: obsolete and/or deprecated parameter(s) specified

ORACLE instance started.

 

Total System Global Area 2004340736 bytes

Fixed Size                  2145744 bytes

Variable Size             402653744 bytes

Database Buffers         1593835520 bytes

Redo Buffers                5705728 bytes

Database mounted.

sys@CTRDM_DB1>alter database open;

 

Database altered.

 

sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;

 

  COUNT(*)

———-

        25

 

sys@CTRDM_DB1>

 

20:29 因为信任，所以简单 --专访支付宝架构师团队 (1) (10526 Bytes) » DBA notes 
这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第一部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。

Note：提问者：《程序员》杂志郑轲。回答者：支付宝架构师团队。

能否介绍下支付宝架构团队的构成以及各位的知识结构?

支付宝架构团队里的架构师角色可以划分为首席架构师、技术架构师、业务架构师、产品架构师等、数据库架构师等。

  • 首席架构师：制定公司的长期技术路线图。是公司技术方向和技术组合的重要决策者。
  • 技术架构师：关注整体网站系统架构。通过技术架构对业务架构提供支撑；（系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责）
  • 业务架构师：关注业务架构。对公司战略、客户需求、内部需求进行抽象、组织、规划。关注业务的敏捷性，能够随着战略的变化而变化。
  • 数据架构师：负责数据库相关的架构，数据相关的技术研究、规划、评估等。

此外，我们支付宝架构团队里面还有搜索引擎专家专门负责搜索相关的技术，有业务流程专家制定业务流程制定，流程架构开发指引等，可谓藏龙卧虎。

支付宝的架构师中，一部分是从支付宝与淘宝网的内部一线研发人员中成长起来的，在多年的实战中积累了丰富的大规模分布式互联网系统的设计与开发经验，有扎实的 Java 开发功底，熟悉各种开源系统、框架与工具，熟悉主流的企业中间件。支付宝架构团队也有一部分是来自著名 IT 企业的架构师，他们分别在数据库、高性能计算、企业服务总线、工作流、开发工具等专业领域有多年的积累。

支付宝架构师对电子支付行业知识有相当深入的了解，尤其我们的业务架构师，他同时也是会计与支付行业应用的专家。另外，值得强调的是，每个架构师也都会定期带一到两名徒弟，把经验直接传递下去，满师之后徒弟也会承担比较关键的角色，这也让开发团队的同事有更好的上升空间。

支付宝架构团队对自己的具体定位是什么？

支付宝架构团队的日常工作定位在支付宝系统高层架构的设计与优化，其职责是保障系统与公司的愿景与业务体系一致，达到关键的业务敏捷、可伸缩、高可用、性能与安全指标，具备内在的统一性、协调性与可持续发展性，支持支付宝技术团队高效率地研发高质量的产品。

为了达成这一目标，我们会创建并持续优化支付宝的业务架构与系统架构蓝图与发展路线图、参与各类外部与内部标准与规范的制定、评估与指导重大项目与重大的系统变更、主持设计并实现支付宝系统开发框架与工具、以及辅导与培训支付宝技术团队成员等。

支付宝架构团队同时是支付宝未来发展所需的关键技术的孵化器。我们会根据公司的业务方向与趋势，结合行业与技术的发展状况，产出并维护支付宝的技术愿景、技术研究整体规划与发展路线图，并主持开展前瞻性技术的研究。

支付宝架构团队也是公司决策层的智囊团之一。我们会参与公司的发展决策，站在整体业务与技术架构、技术可行性与最佳技术途径的角度，对公司重要项目的决策提供专业性的参考意见。

补充一下，支付宝架构团队一直在招贤纳士，欢迎更多技术牛人加入(Fenng 补充：另外近期在上海会有招聘会)。

架构团队与开发团队之间的沟通多么？主要集中在哪些方面?

沟通是比较多的，一方面是在项目期间会有比较频繁的沟通，主要集中在产品的系统设计是否合理、技术难点支持等方面，有的时候，架构师也会临时"下放"到项目组，与开发工程师并肩战斗；另一方面在非项目时间经常会针对开发模式、新技术走向、如何做好设计和编码等技术角度做分享与交流。

架构团队内部的小范围沟通也不少，大家经常会就一些难点进行思维碰撞、分享、交流。 我们架构组后面的白板好像很少有干净的时候 - 经常是在讨论中拓扑图画满了整个白板。

支付宝架构团队是否经常与阿里巴巴旗下其他公司的架构团队进行沟通和交流？从其他团队哪里学到的最有价值的东西是什么？

为了促进阿里巴巴旗下的各个子公司之间的技术交流，我们成立了一个集团架构委员会。集团架构委员会每个月会有一次线上交流，每个季度会有一次线下的会议交流，而且每个月末各个子公司都会在邮件列表中报告各个子公司技术研究方向和成果。

如果大家都在研究同一种技术，会成立专门的研究小组，进行针对具体技术场景的研究。通过集团架构委员会，我们可以了解各个子公司的技术方向和研究成果，做到互相促进，互相学习，技术共享。

你们认为支付宝架构最令你们自豪的是什么？为什么?

在过去的三、四年里，随着支付宝业务领域的拓展与业务规模的增长，支付宝系统也一直处于快速的增长与变化中，从最初的单一应用迅速发展成由数十个自主系统构成的高度分布又充分协同的大系统。与此同时，支付宝研发团队的规模也从最初的数人发展到现在超过百人的研发团队。在快速奔跑中保持稳定与平衡，对架构提出了很高的挑战。

因此，我们很早就将支付宝系统建立在了面向服务架构(SOA)之上，确立了面向服务的整体业务架构，围绕着公司的基础业务建设了几大核心服务系统，并且搭建了以 ESB 为骨干、以服务框架为基础的面向服务基础设施。这些核心服务以及基础设施是支付宝系统健壮的后腰，它们的高可靠与高可用性是支付宝系统的整体稳定性的基础，它们的灵活性与可重用性支持前端业务有条不紊地创新、整合与优化，它们的可伸缩性保证了系统能够支撑持续的快速业务增长。

面向服务架构不仅是支付宝的运行系统的基础，而且已经渗透到了支付宝的研发与治理体系中，当前，这个领域仍然是支付宝架构团队的一个研究与应用的重点。

能够介绍一下支付宝的架构中用到了哪些 SOA 的思想?

支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。

从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。

在采用SOA思想的过程中，我们从下面2个方面入手：

首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 -- 这也是SOA思想的核心。

业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。

接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：

A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。

B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。

C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。

D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。

E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。

--待续--

20:07 谨慎的使用shutdown abort (29033 Bytes) » OracleBlog.cn

今天在重启一个库的时候，由于等了超过半小时，仍然没有完成数据库的close，于是就用shutdown abort命令关闭数据库。但是在起来的时候，发现在alertlog中有大量的SMON的报错，而且还在持续不断的报错出来。

<--- 正常的启动信息 begin here --->
Mon Sep  1 16:32:02 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 1
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.6.0.
System parameters with non-default values:
  processes                = 1200
  timed_statistics         = TRUE
  shared_pool_size         = 419430400
  sga_max_size             = 2108652208
  large_pool_size          = 117440512
  java_pool_size           = 117440512
  spfile                   = /dev/vg_ora01/rspfile_128m_01
  control_files            = /dev/vg_ora01/rctrl_128m_01, /dev/vg_ora02/rctrl_128m_02
  db_block_size            = 8192
  db_cache_size            = 1258291200
  compatible               = 9.2.0.0.0
  log_archive_start        = TRUE
  log_archive_dest_1       = location=/arch
  log_archive_format       = arch_%t_%s.arc
  log_buffer               = 10485760
  db_files                 = 800
  db_file_multiblock_read_count= 16
  fast_start_mttr_target   = 300
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_suppress_errors     = TRUE
  undo_retention           = 10800
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  instance_name            = gdmocs
  job_queue_processes      = 6
  hash_join_enabled        = TRUE
  background_dump_dest     = /oracle/app/oracle/admin/gdmocs/bdump
  user_dump_dest           = /oracle/app/oracle/admin/gdmocs/udump
  core_dump_dest           = /oracle/app/oracle/admin/gdmocs/cdump
  sort_area_size           = 524288
  db_name                  = gdmocs
  open_cursors             = 500
  star_transformation_enabled= FALSE
  query_rewrite_enabled    = TRUE
  pga_aggregate_target     = 524288000
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
Mon Sep  1 16:32:03 2008
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=9
ARC0: Archival started
ARC1 started with pid=10
ARC1: Archival started
Mon Sep  1 16:32:03 2008
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon Sep  1 16:32:03 2008
ARC1: Thread not mounted
Mon Sep  1 16:32:03 2008
ARC0: Thread not mounted
Mon Sep  1 16:32:03 2008
ALTER DATABASE   MOUNT
Mon Sep  1 16:32:07 2008
Successful mount of redo thread 1, with mount id 2193310019
Mon Sep  1 16:32:07 2008
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE   MOUNT
Mon Sep  1 16:32:07 2008
<--- 正常的启动信息 end here --->
 
<--- 开始打开数据，发现需要做实例恢复 begin here --->
ALTER DATABASE OPEN
Mon Sep  1 16:32:08 2008
Beginning crash recovery of 1 threads
Mon Sep  1 16:32:08 2008
Started redo scan
Mon Sep  1 16:32:09 2008
Completed redo scan
 27274 redo blocks read, 46702 data blocks need recovery
Mon Sep  1 16:35:20 2008
<--- 开始打开数据，发现需要做实例恢复 end --->
 
<--- 开始实例恢复 --->
Started recovery at
 Thread 1: logseq 24462, block 231548, scn 0.0
Mon Sep  1 16:35:20 2008
Recovery of Online Redo Log: Thread 1 Group 1 Seq 24462 Reading mem 0
  Mem# 0 errs 0: /dev/vg_ora01/rredo_256m_01
  Mem# 1 errs 0: /dev/vg_ora02/rredo_256m_11
Mon Sep  1 16:35:22 2008
Completed redo application
Mon Sep  1 16:35:32 2008
Ended recovery at
 Thread 1: logseq 24462, block 258822, scn 13.3684259989
 46702 data blocks read, 46201 data blocks written, 27274 redo blocks read
Crash recovery completed successfully
Mon Sep  1 16:35:33 2008
LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 advanced to log sequence 24463
Thread 1 opened at log sequence 24463
  Current log# 3 seq# 24463 mem# 0: /dev/vg_ora01/rredo_256m_03
  Current log# 3 seq# 24463 mem# 1: /dev/vg_ora02/rredo_256m_13
Successful open of redo thread 1
Mon Sep  1 16:35:33 2008
<--- 开始前滚 --->
SMON: enabling cache recovery
Mon Sep  1 16:35:33 2008
ARC0: Evaluating archive   log 1 thread 1 sequence 24462
ARC0: Beginning to archive log 1 thread 1 sequence 24462
Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/arch_1_24462.arc'
Mon Sep  1 16:35:34 2008
Successfully onlined Undo Tablespace 1.
Mon Sep  1 16:35:34 2008
<--- 开始回滚 --->
SMON: enabling tx recovery
Mon Sep  1 16:35:34 2008
Database Characterset is ZHS16GBK
Mon Sep  1 16:35:34 2008
<--- 开始出现大量的SMON报错 --->
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
Mon Sep  1 16:35:35 2008
replication_dependency_tracking turned off (no async multimaster replication found)
Mon Sep  1 16:35:35 2008
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
<--- 实例恢复完成，数据库open --->
Mon Sep  1 16:35:35 2008
Completed: ALTER DATABASE OPEN
Mon Sep  1 16:35:35 2008
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available

此时，数据库已经open，但是在alertlog中有大量的这样的报错。查询metalink（Note:266159.1）：

Cause
These errors do not indicate rollback segment corruption.
 
Oracle 8i:
These messages indicate that there is a problem with the "rollback_segments" parameter in the init.ora.
 
Oracle 9i:
Automatic Undo management is being used. When the instance is shutdown, during the next startup instance recovery needs to take place.
In AUM we do not have any control over which undo segments will brought online after the instance startup.
In case we require any of the offline undo segments for the instance recovery, these messages will appear in alert log.
 
This is not a bug, this is the intended behavior.
When SMON finds such offline undo segments with transactions needing recovery ,then it does what is intended to do , ie: perform the transaction recovery in batches of 100 undo records.

看来并不是undo segment损坏块的问题。用metalink上的方法处理，告警不再出现。

目前数据库已经open，但是还是不敢用当前的undo了，新建unodtbs02到系统默认的undo。

Solution
 
Oracle 8i:
Check that the rollback segment is included in the "rollback_segments" parameter then adding the rollback segment to the parameter. If not, adding the rollback segment and restarting the database will clear up the problem.
 
Oracle 9i:
Solution 1:
---------------
To stop this messages from appearing you can do the following workaround :
 
sql> alter session set "_smu_debug_mode"=4;
sql> alter rollback segment "_SYSSMU11$" online;
 
Where 11 is the number that is appearing in the messages in the alert log.
 
Solution 2:
---------------
This is fixed in 10g. With the new feature "Fast Ramp-Up" AUM enhancement.
SQL> select SEGMENT_NAME,STATUS from dba_rollback_segs where SEGMENT_ID=60;
 
SEGMENT_NAME                   STATUS
------------------------------ ----------------
_SYSSMU60$                     PARTLY AVAILABLE
 
SQL> alter session set "_smu_debug_mode"=4;
 
Session altered.
 
SQL> alter rollback segment "_SYSSMU60$" online;
 
Rollback segment altered.

alterlog中不再报错：

$>tail -f alert_gdmocs.log
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
SMON: about to recover undo segment 60
SMON: mark undo segment 60 as available
Mon Sep  1 16:48:39 2008
alter rollback segment "_SYSSMU60$" online
Mon Sep  1 16:48:39 2008
Completed: alter rollback segment "_SYSSMU60$" online
Mon Sep  1 16:52:33 2008
Thread 1 advanced to log sequence 24466
  Current log# 1 seq# 24466 mem# 0: /dev/vg_ora01/rredo_256m_01
  Current log# 1 seq# 24466 mem# 1: /dev/vg_ora02/rredo_256m_11
Mon Sep  1 16:52:33 2008
ARC0: Evaluating archive   log 4 thread 1 sequence 24465
ARC0: Beginning to archive log 4 thread 1 sequence 24465
Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/arch_1_24465.arc'

（新建undotbs02到系统默认undo过程略）

检查undo segment的状况：

SQL> select TABLESPACE_NAME,SEGMENT_NAME,status from   dba_rollback_segs;
 
TABLESPACE_NAME                SEGMENT_NAME                   STATUS
------------------------------ ------------------------------ ----------------
SYSTEM                         SYSTEM                         ONLINE
UNDOTBS1                       _SYSSMU1$                      ONLINE
UNDOTBS1                       _SYSSMU2$                      OFFLINE
UNDOTBS1                       _SYSSMU3$                      OFFLINE
……
UNDOTBS1                       _SYSSMU11$                     OFFLINE
UNDOTBS1                       _SYSSMU12$                     ONLINE
UNDOTBS1                       _SYSSMU13$                     ONLINE
UNDOTBS1                       _SYSSMU14$                     OFFLINE
……
UNDOTBS1                       _SYSSMU59$                     OFFLINE
UNDOTBS1                       _SYSSMU60$                     ONLINE
UNDOTBS1                       _SYSSMU61$                     OFFLINE
……
UNDOTBS2                       _SYSSMU858$                    ONLINE
UNDOTBS2                       _SYSSMU859$                    ONLINE
UNDOTBS2                       _SYSSMU860$                    ONLINE
UNDOTBS2                       _SYSSMU861$                    ONLINE
UNDOTBS2                       _SYSSMU862$                    ONLINE
UNDOTBS2                       _SYSSMU863$                    ONLINE
UNDOTBS2                       _SYSSMU864$                    ONLINE
UNDOTBS2                       _SYSSMU865$                    ONLINE
UNDOTBS2                       _SYSSMU866$                    ONLINE
UNDOTBS2                       _SYSSMU867$                    ONLINE
 
868 rows selected.
Related Posts
18:56 MYSQL 编译优化参数 (1172 Bytes) » 架构研究室
CFLAGS="-O3 -mpentiumpro -mstack-align-double"
CXX=gcc
CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti"

 ./configure  --prefix=/usr/local/mysql5 \
              --with-charset=utf8 \
              --with-collation=utf8_general_ci \
              --enable-thread-safe-client  \
              --with-extra-charsets=gbk,latin1 \
              --with-client-ldflags=-all-static \
              --with-mysqld-ldflags=-all-static \
              --enable-assembler \
              --with-unix-socket-path=/usr/local/mysql5/var/mysql.sock \
              --sysconfdir=/usr/local/mysql5/etc  --disable-shared
18:49 有感于RAC与性能 (2722 Bytes) » 老熊的三分地

经常遇到客户和其他一些Oracle开发与维护人员，问我为啥使用了RAC，没有感受到业务系统有明显的性能提升，有时反而觉得性能有所下降。这种认为RAC一定能够提高性能的想法，有着广泛的“群众基础”。可以说，使用RAC来提高性能是一种存在于广大ORACLE数据库使用者之间的误解。

这里我不想过多于技术上去解答这个问题，而是从下面这个类比来说明这个问题：

这里我们要谈论的是大部分的业务系统类型，事务处理型，也就是OLTP。虽然很多OLTP类型的系统还兼有生成一些报表和统计数据的功能，但那只是一部分小的功能，主要还是事务处理。

大家都去过银行，假设一个银行营业厅有6个业务窗口，来这个营业厅办理业务的客户一般为3至5个人，最多6个人。由于每个人办理业务的时间，是跟他（她）的业务类型有关的，比如取款2分钟，存款2分钟，开户要5分钟等等，不会以窗口数的增多而减少时间。以这个例子来说，6个窗口已经足够了，因为6个窗口数大于同时办理业务的客户数，而一个客户只会在一个窗口办理业务，就算再多的业务处理窗口，也不会对每个客户办理业务有速度上的提升。

现在假设银行的业务有了很大的发呢，银行营业厅里面的客户比较多了，同时来办理业务的常常超过10人，这个时候就是银行营业厅的窗口不够了（资源不足），客户存在了排队，严重影响了客户办理业务的效率。而营业厅由于受面积的限制，不能增加窗口了（对于机器来说，不能扩容了），这个时候银行在附近又开了一个新的营业厅（增加了一个新的结点），那样部分客户分流到了新的营业厅，这样消除了客户的排队，客户又能够高效率地在银行办理业务了。

使用RAC类似于上面提到的银行，如果业务系统能够在单台机器上跑，这个时候由于资源足够，增加新的结点不会带来性能上的提升，而如果随着业务的发展，机器资源受限，不能为更多的用户服务，这个时候增加新的结点，能够使业务系统能够为更多的用户服务。

然而在现实生活中，很多业务系统并没有为RAC进行一些优化，同时RAC的结点之间由于数据同步的代价比较高，因而使用RAC后往往感受到业务系统并没有更快，有时感觉反而更慢。

RAC的作用更体现于高可用性、水平可扩展性，其次才是某些条件下的性能提升（比如针对于某些DSS系统）。

17:53 Solaris安装Oracle10g之 libCstd.so.1 问题解决 (3523 Bytes) » Oracle Life

©作者：eygle 发布在 eygle.com

在Solaris上安装Oracle10g时，遇到了如下一个错误：
Exception String: Error in invoking target 'all_no_orcl ihsodbc' of
makefile '/data1/oracle/product/rdbms/lib/ins_rdbms.mk'.

由于客户的Solaris是比较老的机器，也没时间打补丁
SunOS server 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-880

一看这个错误是和编译有关的，检查日志发现果然缺少了一个C的类库：
fatal: file /usr/lib/sparcv9/libCstd.so.1: cannot open file: No such file or directory

以下是完整日志摘录：
INFO:  - Linking liborasdkbase
INFO: /data1/oracle/product/bin/genorasdksh -base
INFO: $Id: genorasdksh.sh 02-mar-2005.16:22:46 mchengjr Exp $
INFO: Generating BASE ORASDK library...

INFO: Creating library liborasdkbase.so.10.2 and map file orasdkbase.map
in directory /data1/oracle/product/lib

INFO: ld: fatal: file /usr/lib/sparcv9/libCstd.so.1: cannot open file: No such file or directory
ld: fatal: File processing errors. No output written to /data1/oracle/product/lib/liborasdkbase.so.10.2

INFO: /data1/oracle/product/bin/genorasdksh: Failed to link liborasdkbase.so.10.2

INFO: *** Error code 1

INFO: make: Fatal error: Command failed for target `liborasdkbase'

INFO: End output from spawned process.
INFO: ----------------------------------
INFO: Exception thrown from action: make
Exception Name: MakefileException
Exception String: Error in invoking target 'all_no_orcl ihsodbc' of
makefile '/data1/oracle/product/rdbms/lib/ins_rdbms.mk'.
Exception Severity: 1

缺少的类库包含在SUN的 SUNWlibC 包中，不过找这个包可困难了，没有光盘，SUNFREEWARE上也没找到。
还好，在SUN的另外一个站点有一个binary的：
http://dlc.sun.com/osol/devpro/downloads/current/

装上之后，Retry通过，好不容易搞定一个10g，升级到10.2.0.4了事。

-The End-

相关文章|Related Articles

评论数量(1)|Add Comments

本文网址：

09:29 我如何在豆瓣寻找兴趣相似的人？ » 淘宝数据仓库团队
04:25 samba 服务无法访问 » 架构研究室
03:53 青海行 - 偷懒的理由 » Chanel [K]

  2008-09-01 Mon

23:57 postgresql中的分区表 » ORATEA
23:37 postgresql常用命令(4) » ORATEA
23:37 postgresql常用命令(3) » ORATEA
23:36 postgresql常用命令(2) » ORATEA
23:35 postgresql常用命令(1) » ORATEA
22:19 如何恢复被删除的表空间？ » Alibaba DBA Team
06:55 在 AIX 中运行 Oracle » developerWorks 中国 : 技术文章 , 教程 AIX
01:11 入手Canon 450D » Ricky's Blog on Testing and RAC
00:26 不要删除你所有的归档日志 » OracleBlog.cn

2008-08-31 Sun

22:00 HP中无法使用@符号 » OracleBlog.cn
18:56 RAC备份 » 梦想有多远
05:25 创新，京剧，中秋，嫦娥 » 玉面飞龙的BLOG
00:17 学习latch笔记 » Alibaba DBA Team

  2008-08-30 Sat

21:14 世界真的是平的 » Free2way@Net
21:11 Wish » Chanel [K]
21:00 入手Canon 450D » NinGoo.net
19:38 球迷 » NinGoo.net
11:07 浅析网购模式（3） » 淘宝数据仓库团队
11:01 浅析网购模式（2） » 淘宝数据仓库团队
10:55 浅析网购模式（1） » 淘宝数据仓库团队
10:38 数据挖掘与知识发现（2） » 淘宝数据仓库团队
05:33 EM » 梦想有多远

  2008-08-29 Fri

19:05 杀蟑螂 » 玉面飞龙的BLOG
10:30 小议compress表 » OracleBlog.cn
08:23 漫长的出差 » 老熊的三分地
07:30 问题拾遗 » Chanel [K]
06:25 北飞的候鸟 » Chanel [K]

  2008-08-28 Thu

08:08 既成事实还是将成事实？ » 淘宝数据仓库团队
06:05 Perl监控AIX的网卡流量 » AnySQL.net
04:36 在 IBM Network Authentication Service for AIX 中增强密码强度 » developerWorks 中国 : 技术文章 , 教程 AIX
01:47 memcached 入门到理解 » 架构研究室
01:20 继续上面的话题(分区表) » stronghearted life
00:14 Perl AIX-Perfstat-0.03编程 » AnySQL.net

  2008-08-27 Wed

22:52 安装Perl AIX-Perfstat-0.03 » AnySQL.net
22:31 普通表改分区表遇到的问题 » stronghearted life
06:44 Unix高手的另外十个习惯 » Ricky's Blog on Testing and RAC
 123
 123