频繁写库后数据库就出问题

xihuluyou 2004-11-21 09:33:05

WIN2003系统下装的SQL

库建好以后以后只能正常运行几天,然后就不行了.表现为:打开表速度巨慢,另外远程连接不上

开始的时候以为是日志文件太大的缘故(因为流程的需要,平均5秒有一次查库写库的操作)

可把库日志增大以后无效果

有没有谁知道这种情况还有什么其他的可能引起啊~~!

...全文

127 3 打赏收藏转发到动态举报

写回复

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

huazf 2004-12-02

打赏
举报

回复

专业提供SQL SERVER 修复,SQL恢复,误删除表,SQL 数据恢复,SQL SERVER 数据库恢复修复,SQL 找回业务。
QQ:386999
TEL:0576-2454863

CSDN12345678SQL 2004-11-22

打赏
举报

回复

呵呵,病毒!

jasonpartley 2004-11-21

打赏
举报

回复

试试分文件组把数据分布到多个物理磁盘上试试

其中包括两个jar包，commons-dbcp.jar,commons-pool.jar

hibernate3.3.1的jar包！！hibernate3.3.1的jar包hibernate3.3.1的jar包hibernate3.3.1的jar包

看起来有点像大洲的那个，jsp中算不错的啦.值得下载回去研究研究

大部分数据库都支持多读，一般是使用行锁。写=插入（批量操作，id独立生成，不实用自增）、更新、删除读写分离之外，还有降级，还有缓存读写，延迟处理等。处理策略主要看用户场景，秒杀场景和普通场景又不一样。 CAP原则一只能满足两样，所以要根据实际场景选择合适的处理策略读在数据能力下是基本满足不了高并发场景的，所以一般会使用缓存，读频繁的可以考虑使用本地缓存，数据量稍大的可以使用...

在惯性思维的情况下消息早期的持久化逻辑我是这样实现的。在这里会出现性能的问题就是第3点，如果用户在极短暂的时间内发送大量的消息，那么每一条消息都会进行持久化的操作并且还会频繁的提交事务；之前提到过主要是解决用户“在极短暂的时间”内发送大量的消息，避免，这个大量的消息频繁持久化到数据中而降低数据库性能，所以，这里可以将持久化停顿的时间间隔设定为非常短的一个间隔，目的只为了解决将短时间之内频发持久化大量消息，只需要在短暂的时间内批量持久化这一范围的消息即可，并且这里引入了重试机制解决临近消息持久化问题；

27,580

社区成员

68,544

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章