大数据量数据库配置部署方案思考

MSSQL2005以上版本才有真正的表分区，2000以下的就没的了~


MSSQL 确实容易死锁的说

先搞个jwebap来看看问题出在哪里吧，换上连接池试下

不知道楼主对 Amoeba:分布式数据库Proxy解决方案 是否感兴趣？
http://amoeba.sf.net/amoeba.pdf

换os和db就是工作量和成本比较大的做法。
我的建议是
1.读写分离
2.使用中间件
3.使用集群或分布式

sql server没有你们说的那么差吧！

    有人建议用oracle，好像一用oracle问题就全部解决了，8个月才300万的记录，也没有必要用到oracle的表分区。很多公司用只是把数据库当成一个简单的存放数据的地方，写的sql也不讲究，索引也不好好做，我只想说，如果sqlserver都没用好，用oracle只是徒劳，oracle的索引类型比sqlserver多多了，还有其他很多的优化途径，有更多的特性和细节可以让用户调控，以达到性能进一步优化的目的。
    其实8个月产生300万条记录，这样的数据量不算很大，绝对不会是数据库的问题呢，在确定系统结构合理的情况下，应检查数据库设计是否合理，我说的这个合理并不是说要遵循理论上的范式，而是因地制宜，比如适当的加一些多余的字段，sql的写法是否有比较高的效率，是否用查询分析器反复调试过sql的效率，数据文件的分配是否合理，索引的建立是否合理，数据库的一些全局参数是否合理，只有在确定数据库是瓶颈的情况下，你换成oracle，可能你的系统会进一步的健壮，如果你根本驾驭不了数据库深层的管理，优化策略，换oracle也是没用的。

问题都没定位好问题，就开始张罗着换数据库。
这样做对客户很不负责任。

看看http://dev.csdn.net/author/griefforyou/082b9b29299e4584b78bf6f7ccb57c0b.html

8个月才300w条记录，现在主流的什么数据库都没问题的。
微软也是出来混饭的，这点都不至于搞不定。原来我们用SQL Server，千万级的数据跑的很好。
前面的应用搞不好，什么数据库都是死。没有数据库能直接承受前端压力，测试玩具除外。

谢谢各位的回复

澄清几点：
1、oracle 是客户长远考虑到结果，以后很可能数据不会这么点了 流量会很大用户也会有很多增加 这是在可预期的几年的考虑

2、我早就讲过oracle 不能解决根本问题，不过可以缓解问题。对开发人员来讲也会轻松些，作为架构及开发人员自由度也会大些。

3、问题已经了解到很清楚了，客户的c/s系统打开个每个界面 都要查询20 几次操作，完成一个业务基本上要上百的操作，不满才怪，查询报表等sql 写的奇垃圾，没有任何索引优化措施 所以主要原因还是该系统设计问题。

4、我们用sqlserver 可以用但是用的好就不轻松了，考虑到目前项目组情况，oracle 确实可以给我省不少力气。说实话站在用户角度长远点考虑 oracle 还是ok的

链接打不开