高并发Oracle数据库系统的架构与设计经验谈，欢迎参与！

xuexiaogang

回复 7# aluocp


    专家，写的好！

ylky_2000

回复 19# aluocp


    谢谢回复。
明白了，死锁是程序逻辑问题引起，需要优化程序。
第一次听到了数据库森林的概念，值得期待拜读。
去O和不去O更多是从投入角度来看吧。看楼主关于这点的回复，感觉是做过关于去O很深入的研究的。
另请教，数据库方面的架构师，是否也需要从财务方面考虑选型？经常听到很多大牛和资深人士，在遇到授权和价格方面的问题的时候都说要问销售。所以一直不解为何，还是我对架构师这个岗位的职能理解有误？

aluocp

回复 23# wang290


遗憾的是，我现在也在推动这种“去IOE”的大跃进。

aluocp

回复 27# ylky_2000


如果是资深的架构师的话，就要全面的考虑了，包括财务方面的。

用现在的话来说，你就是数据库的产品经理。

jackson198574

顶起来~~~哈哈

jiangxiaoyu

回复 1# send_linux


哈哈，偶终于回来啦。针对管理员提出的三大问题偶胡乱说说吧。

Question (2) :
  俗话说要想马儿跑的快就要马儿吃的饱，饿着肚子不用说马了路虎都跑不了。如果把饿和饱当作数据库的两种根本特性，那么想马儿吃的少又跑的快的想法更本是天方夜谭。高并发的数据库架构设计，得有个限制。在多少压力范围内，偶的这个系统最高并发量能达到多少，产生的IOPS和output是多少等等。。
那么如果您满意咱们的数据库的DNA就按照这个模型做，然后人工建库,tablespace,users...
  从偶上面一段话可以看出采用什么样的方法去建造在不久的将来会不会被程序自动取代呢,那么咱们目前大部分DBA是不是就在做这样的事情呢？设计这样一个数学模型的人在任何时代都不会被取代。写到这里偶不禁对偶的未来开始担忧了。
  说正事，由于冯大爷的一个决定让数据只能是先被存储才能被运算，也就是说同一个object在同一个时刻不能被两个进程或者线程完全占有。基于这样困境，那么读写分离是目前比较容易实现的一种方法啦。欢迎大家拍砖。

Question (3) :
  偶最近在研究Timeten，感觉这个玩意很有意思它可以作为读写分离系统得力的好帮手。可总感觉其最多只充当护航机或者僚机这样的角色。

Question (1) :
  最后来聊聊Oracle本身。术业有专攻，面对其它列式数据库恶毒的嘲笑咱们作为行式数据库的扛把子没有低头的必要。Oracle行式数据库的特点完全适合做高并发的数据库来使用。只是又要读又要写使得它太累了，但是客户错误的认为SQL语句可以实现任何功能使得其在功能的修改上随心所欲。如此再 强悍的软硬件结合也经不起这样的折腾，结果受伤的总是DBA。。。



   

thinkeasy

回复 22# miniuinx


    开源是很火，去ＩＯＥ也很火，但人才的缺少是非常大的，这才是开源很难普及的源因。
ＩＴ行业还没有那么明显，在传统行业有问题找厂家还是很普遍的现像，如果全是自己维护，那是不可能的。

tangye

Oracle已经很高深了，这个话题就更上档次。学习

lanyuflying

再回下：
    oracle的两大强项：一个是事务高并发度的支持，它的并发控制机制很优秀，所以，并发的管理上，应该是目前的数据库中最优秀的；
                    第二个应该算是CBO，就是基于耗费的优化器，相比较而言，大部分数据库使用的是RBO，也就是基于规则的优化器。

    其他的如flashback，也是非常的好。