关于数据传输和进行写库的非常紧急的问题请教大家！：报错

更换服务器~100个是单服务器最大的负荷了你用的是镶嵌式的，要选择服务器机组的那种~刀片式服务器~然后oracl数据库支持分开安装。同步处理~ 你肯定买的是架式服务器~######装ORACLE服务器是刀片式的，6核至强 24G的内存 应该不是服务器瓶颈######oracl装在独立的一台服务器上的话，只支持小形企业和地、市级企业运行 你说的情况，可以理解你的数据量非常庞大，，有可能是省、国家级的数据量了~~ 让你单位给你单独开个服务器房间，更换服务器机柜然后购买刀片式服务器做服务器阵列机组~######数据量倒不会太大，一天1G不到，问题是很多存储过程的逻辑很复杂，一条线程调用存储过程，要等待很久才会返回，直接导致工作线程速度很慢，数据进入速度太快，工作异常状态频繁出现。######必须要实时的存入数据库吗？不能先缓存到服务器，然后让服务器慢慢去处理吗？或者直接将数据记入日志，然后sqlload？######回复 @xinzaibing : 我想到一个蛋疼的方式：数据写文件，文件内容定期入库，程序定期读取数据库计算的结果缓存到内存中。不知道你具体需求，瞎琢磨一个。######回复 @asdfsx : 公司领导一致认为内存不可靠，断电、程序异常什么的...存在内存的数据就没了...真是蛋疼啊######回复 @xinzaibing : 如果数据量不大的话，还有一个方案就是都保存在内存里，然后定时把内存里的结果同步到数据库里。数据库的逻辑挪到程序里..........这个方案比较累啊。另外就是缓存可以加个优先级高低的判断。######目前要求是必须要实时入库，采取写日志文件的方法也可以。 这些数据有一个特点，在某一个时刻会有一个突然出现的峰值，然后又慢慢变少，但是这个时间是不固定的，由于只实用了一条双缓冲队列，所有需要紧急处理的数据和非紧急处理的数据都在队列里，而如果遇到非紧急数据，处理了很长的时间，就直接导致后面的紧急数据失效了...或者导致嵌入式程序判断服务端未收到数据，进而采取重发，导致一条队列里有非常多重复的数据。######我可能会使用数据写入日志文件，然后定时将日志入库的办法操作######大概意思可能是多线程对数据库表的操作导致数据表锁定，性能损失在内耗上了。。那数据表采用行级锁呢？（这样会增大系统开销）我是菜鸟，求教  ######回复 @xinzaibing : 这个应该是属于最初的设计问题，hohoho######回复 @asdfsx : 目前我也在往这方面考虑，如果数据分类处理。那就得大改结构了...唉######回复 @xinzaibing : 建议根据上传的不同数据进行不同的处理，不要一股脑的都放在缓存中，如果是心跳的话，应该立即响应，如果是要处理的数据的话，才需要进行缓存等待处理######ORACLE默认就是行级锁的应该.. 主要是数据的写入速度远远小于数据上传的速度，导致了缓存溢出，紧急数据不能得到及时处理，大量数据出现超时失效，无法对嵌入式的采集器程序作出及时的心跳相应和其他回复（因为都在队列中，无法处理，无心跳的话嵌入式采集器会误认为服务器断线）。最终导致单台服务器接入数据的嵌入式设备的数量太少，不满足需求。######去年刚毕业，由于公司小，一个人搞后台，压力太大啊...大家指指招呗～ @中山野鬼######今天到图书馆看了一本书《让Orcale跑的更快点》，上面说可以从如下几个方面优化： 数据库方面：建适当的索引，固定长度；查询条件比较尽量简化；不同的表放在不同的磁盘里…… 服务层：增大缓存，（有没有数据库连接池不知道你能用上不） 软件层：对Java使用PaperStatement 囫囵吞枣就记得这么多了。。。哭~~######非常感谢...我去看看这本书 ：)######我不清楚你的数据采集的内容是什么。不过看的出，对实时性要求高。换我，基本上就一个思路。 1、做个前段服务器，什么事情都不干，只进行数据的压缩。然后所有数据库和计算操作，放到后端。 至于并发，你这种 1W=100台服务器的方式治标不治本。######@中山野鬼 是说对数据进行预处理，提取有效内容？还是就是zip？######回复 @asdfsx : 不一样的。而是数据压缩。采样数据中间，信息密度不会太大的。######老鬼的思路有点像我说的那个数据写日志文件，或者内存缓存定时入库...........都被否定了啊######@xinzaibing 还有一个建议，上传的数据加一个验证，如果上传的数据已经插入缓存，就不要再次插入了。无脑插入插到崩也不是什么好主意啊######回复 @asdfsx : 要回复的，要处理成功后才回复，存库失败或者某些异常导致服务端崩溃重启，就不进行回复，客户端会持续地进行重发，重发到一定次数后，存本地，等恢复正常后发送存本地的数据