让服务器爆炸的一个问题！(100分)

O

onyliu

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-25

• #21

完全肯定是软件问题，66万的数据就是在PC上跑也不该有问题

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-25

• #22

听大家分析，我们的服务器配置相当高啊。  100%是软件设计有问题啊？ 现在都已经把服务器拖死了。

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-25

• #23

CPU ：  38953  这里这个CPU时间是怎么回事啊。会不会搞死服务器

 

Q

qnaqbgss

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-25

• #24

不会,这个主要是你SQL语句没有带条件全部SELECT肯定时间要长一点,它的单位是毫秒.<br>所以你的程序当中,用SQL语句最好是带上条件同时需要那些字段就SELECT那些字段,不要动不动就SELECT * .<br>其实你的才几十万数据,算是很少的.注意SQL语句的使用和数据表的关系.

 

B

ball_cao

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-26

• #25

很显然不是硬件的问题 <br>用语法分析器分析一下你的各类语句 <br>66万记录对单表来说不大 但如果里面的无索引字段和其他表的无索引字段关联就会很慢<br>假设你另一个表1w记录 无索引情况下的关联就变成了在660000*10000条记录中检索 当然会很慢

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #26

我这里是11个表关联。其中最大的表有66万数量，其他表也有10万+。 假如建立了索引。这样的一个视图，查询的时候，会不会把服务器资源都占了，影响到其他用户使用。

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #27

我想知道 CPU ： &nbsp;38953 &nbsp;这个CPU时间是很大，比较大，大的恐怖，甚至大的能让服务器瘫痪。 &nbsp; 这只是 select * from 视图， 程序里还有GROUP BY 等等，CPU时间是 10几万的。

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #28

现在的情况是，服务器已经瘫痪了，非常非常慢。 所以，是软件设计的问题，还是硬件问题。ERP开发商说是我们硬件不够，升级要花6W多

 

R

roadexplorer

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #29

换台更深的蓝应该够了，66万条的大型数据库

 

S

sonicer

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #30

简单的说，你问开发商：啥样的硬件是够的？列个标准出来，我达到这个标准你就能保证没问题？如果我按照你的要求升级了，但问题依然没解决，你们开发商要不要负责任？

 

沉

沉香屑

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #31

11个表关联，做这种设计的人可以直接fire了<br>即使不谈效率问题，如此高的耦合度难道不会给后续开发带来麻烦么？

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #32

没法沟通的，这就是大名鼎鼎的金蝶公司开发的程序。

 

沉

沉香屑

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #33

金蝶又怎么样，拿合同和他们说话就是了

 

我

我爱PASCAL

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #34

过度迷信SQL,三四范式,会把问题反而搞复杂,不要迷信权威

 

我

我爱PASCAL

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-27

• #35

有时用传统的方法比完全用SQL来计算更简单

 

H

houwanghao

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-28

• #36

呵呵，看來配置是到位了，關鍵是軟件，遇到很多的erp沒有您那個那么夸張的！！那么好的配置，卻！！如果可以的話，應該叫您的erp供應商來查看并解決，才那么多的數據就死了...

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-28

• #37

这是著名的金蝶公司开发的啊！！！ 我们公司老总就是慕名才找金蝶做，最后服务器瘫痪了，用户都要疯了。 我们点一下存档，需要等半个小时，查一下库存，可以去泡上茶叶，等凉的差不多了喝一口，数据就出来了。 大家都是认为软件的问题，那我就心里有点底了。

 

Z

zhuzhi129

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-28

• #38

应该是软件问题

 

L

luoyanqing119

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-28

• #39

来自：qumingfei, 时间：2008-8-28 8:15:30, ID：3917249<br>这是著名的金蝶公司开发的啊！！！ 我们公司老总就是慕名才找金蝶做，最后服务器瘫痪了，用户都要疯了。 我们点一下存档，需要等半个小时，查一下库存，可以去泡上茶叶，等凉的差不多了喝一口，数据就出来了。 大家都是认为软件的问题，那我就心里有点底了。 &nbsp; &nbsp;<br><br>-----------------------------------------你用的是金蝶K3吧,对于用户来说.这个软件功能很强大.但对于从技术上来说,用了那么多的视图和过程,还有触发器.这是满垃圾的.你数据库配置有多大,他都会给你拖得很慢.我不知道现在的软件公司怎么了.一味为了方便而把业务逻辑写在后台.完全背离了面向对象对象的基本原则.持久层是不允许加入业务逻辑的.看SAP后台根本没有业务逻辑的.-------(04年在金蝶呆了一年,我敢保证那些鸟毛不懂模式.到处做广告,到处HUYOU,老是说技术不重要,重要的是功能,其它国内软件公司差不多这样,大家同行自醒.如果连模式那些东西你没用到软件里边去的话,那么你们的软件也好不到那里去.),还有,对于大数据量处理的的用户,少用MSSQL,用ORACLE,最好用三层,用二层的话,后台会有大量的死进程,保证一天杀一次搞得你心烦,不得不当机

 

Q

qumingfei

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2008-08-28

• #40

金蝶K3，哦也