关于Java线程安全

[iLooch]

Hi,all:

我现在接了个任务,由于原来系统跑日终报表的时候等候时间过久,严重影响第二天的正常业务.上头要求我们把系统报表部分改成多线程的,查看了相关的一些资料.
但是具体的方案还没有出来,现阶段只是统计系统中静态变量并评估其安全.不知道一般这种工作是怎么着手进行的,有什么比较成熟的方案.

Regards,
iLooch

Feb 22, 2006

[cao bao gang]

建议做增量数据备份,建立单独的库,进行日终统计,这样就在性能上就不用影响业务了.还有就是分析数据结构,如果不是实时的统计,建议,保存中间结果,没必要每天统计吧.

--- iLooch <ilo...@gmail.com>写道:

就这样早出晚归,就这样都市放牛

___________________________________________________________
雅虎1G免费邮箱百分百防垃圾信
http://cn.mail.yahoo.com/

[iLooch]

我说的影响在性能上是其次的

客户那边每天都要跑日终结算,生成报表等操作并会在结算完之后修改系统中的一些设置.这些工作要在当天系统结束运行(现在是24:00)之后进行,而次日8:00系统重新运行之前必须要结束结算.

现在的瓶颈就是在报表这块,占去了2个多小时,因为单线程跑报表等待时间过久,如果遇上异常那第二天的工作就无法按时进行了

 

--
Regards,
iLooch Teen
E-mail:ilo...@gmail.com

[MMv.maX]

[求]PowerDesigner 12的crack

[Corlin]

iLooch，您好！

报表是通过SQL查询/存储过程/应用程序 生成 。是访问表数据还是数据文件。

看下面应该是访问数据库。

1。表优化，索引优化，数据分区，生成临时日终结算表

2. 日终结算程序优化, 记录每次批量查询/插入 所耗时间,找到最耗时的查询和插入语句,优化.

3. 感觉并不是线程问题, 是程序/表/索引优化问题. 

mailto:cor...@cybercorlin.net

[shanzb]

不应该在生产数据库上面跑报表的任务，可以使用ETL工具进行数据抽取，

抽取你做报表需要的数据放在你的报表数据库服务器上面（ETL工具可以

咨询一下sagent，informatic等，都比较出名），因为抽取的内容只是你需

要进行报表呈现的数据，性能和效率都能够接收。BO也有一个自己的ETL

工具，好像叫做Data Integrator。

 

报表的任务跑在报表的服务器上面，单独的执行（无论你多线程还是单线程，

可以使用ms sql的DTS进行任务定制），执行完毕以后再进行"结算完之后修改系统中的一些设置"

如果你的报表任务跑在生产库上面，首先由于数据量的巨大，无论是查询还是记录的更改都会很缓慢，

尤其是当你的客户信息上千万，操作记录简直不可估计。你的结算操作其实只是针对一天的数据而言的。

 

  Lead to The IT Future

----------------------------------

[corlin 陈]

ETL过程也耗费不少时间，而且ETL到另一个库，再执行生成报表，并没有解决根本问题

我考虑上面的应用应该不是专业的BI和DM，没必要小题大做，而且在空闲时间跑报表是生产系统经常做的日常任务。

 

问题比较明显，只需要分析任务耗时瓶颈，合理建立索引，零时表及做好程序优化就可以解决问题。

手工并行可以实现，将流水化的任务并行，建立临时任务调度表，监控该表来监控子任务的完成情况并合理启动下一步任务。。直到所有任务完成，如中断，也可以从断点开始，节省时间。

[郁也风]

我靠，12都出来了，11还没怎么用呢

On 2/24/06, MMv.maX <magui...@gmail.com> wrote:

[求]PowerDesigner 12的crack

--
纵使天涯也牵手
千里烟波共寒暄

Blog: http://www.someok.com
MSN:some...@msn.com
QQ:  1265016

[shanzb]

你说的这种办法适用于小型生产环境，如果数据量大时效要求高的话（比如7*24或者99.9%的生产系统），恐怕在生产环境执行报表任务是行不通的。很多客户在提出需求的时候也经常要求在同一个库上面跑，但是最后出来的东西反而未必是他们想要的。

你说的分析任务的瓶颈以及优化数据库和语句这些是每个DBA或者说报表开发（基于SQL的报表）人员必须做的事情，这个我同意。

[姜铁成]

直接用Quartz不就行了吗？

[corlin 陈]

哈，偏题了，首先我们得考虑cots，看一套etl工具+olap+bi+report
是否值，我是希望用最少的成本解决问题，为客户着想，7*24的系统，也有忙时和闲时区分，我们必须合理高效利用资源，闲时可以执行闲时的任务，忙时必须保证事务完整。

数据库优化必须考虑，但我发现我接触的软件团队都很不重视，特别是做bi的，一个本可执行5分钟的统计操作，没优化前可能需要半个小时。

[shanzb]

如果从成本上面考虑的话,可以使用比较便宜的SQLServer来解决问题.比如DTS作为数据传输,SqlServer作为报表服务器的数据库,至于做呈现可以使用目前现有的报表呈现,只是把数据库的连接池改为报表服务器.

 

其实我想说的并不是要用专业的ETL和报表呈现工具,而是报表服务和主业务服务分离.主业务系统(7*24的系统)本身对系统的稳定和可靠性有极高的要求,而报表系统本身的时效性和实时性并不是那么高,所以我认为这两套系统应该分开运行.主业务系统本身的繁忙和空闲很多时候是由客户运营状况决定的,如果在设计开始就把某个时间点定为空闲或者繁忙恐怕会离最后的目标比较遥远(尤其是国际化的系统,各国的用户的高峰期都不一致),这个时间的改变可能会影响报表的运行.

 

使用DTS+SqlServer的方式投入相对较少,而且关键是对于后期的投入升级可以重利用投资(把DTS换成ETL工具,报表呈现改为专业工具即刻),不需要对主业务系统做太大的改变.这样即保护了客户的投入又保证了主业务系统的稳定性.客户的目前投资就是一套SQLserver+一台报表服务器

 

数据库优化是非常重要的工作,无论是对于报表还是生产系统,一个有经验的团队具有一个专业的数据库专家是非常必要的.

 

On 2/25/06, corlin 陈 <cyber...@gmail.com> wrote:

哈，偏题了，首先我们得考虑cots，看一套etl工具+olap+bi+report
是否值，我是希望用最少的成本解决问题，为客户着想，7*24的系统，也有忙时和闲时区分，我们必须合理高效利用资源，闲时可以执行闲时的任务，忙时必须保证事务完整。

--
----------------------------------

   你的支持 我的坚持

[corlin 陈]

你的解决方案讲的很好。

 

我再提一点吧，要考虑报表的占整个系统的比重是多少，负载情况，数据钻取量和日常访问频率。

报表是作为月报；还是日常工作每天都必须调用，查看和分析。是决策层访问还是所有业务人员/客户经理等普通员工访问，是否有多维报表要求，是否实时性要求很高。

也需要考虑日后的扩展情况，业务是否要向分析型转变。

 

报表库和生产数据库隔离应该考虑。

 

这里有没有电信，银行，24小时客服 系统熟悉的人，讲讲你自己的观点吧。）

[anders lin]

同意！报表应该独立使用数据库，无论是将来升级还是维护都有优势的，关键的是，一旦业务深入挖掘，其实考量的都是客户，也就是基于dw的CRM。

[一鸥 海天]

iLooch，你好！

支持Corlin的看法，毕竟姜是老的辣！

 

建议你先查原因，后出方案。

查原因不外三部分：

==〉数据库DB；

==〉JAVA VM /Middle Ware

==〉OS

 

估计数据库出问题的可能比较大。找个数据库监控软件（搞个试用版解决问题），再找个JAVA VM透视的工具，基本就能找到瓶颈了；对OS熟悉，也可以看看OS配置是否优化，用vmstat,sar看看负载变化。

 

Best

---

想成为冯小刚、陈凯歌、张纪中三大导演的主角吗？