你的营帐数据库多大？（调查）

wolfop

不用归档？出了问题恢复的时候怎么办？
不过我们现在用的是INFORMIX，无法不归档，而且同样的DML操作INFORMIX的日志比ORACLE的要大，一样没有问题。不清楚你那里有多少用户，日志怎么可能那么大，当然你把清单往营销帐务数据库里面插那是另外一回事

xysco

最初由 phonee 发布
[B]我就是怕麻烦，一直没用归档
不知道各位是否都用 [/B]

归档一定要用 备份很重要的 电信的营帐/计费 应该都用归档

lx_king

最初由 xysco 发布
[B]

归档一定要用 备份很重要的 电信的营帐/计费 应该都用归档 [/B]

raid0+1   
而且 天天晚上 逻辑备份  在和容灾同步

bkj

对于生产系统不敢冒不做归档的风险

trouble

楼上的各位，不知道你们的营帐数据库是否包括详单的计费、优惠和入库模块。我们现在的数据库大小（不包括详单信息），有500G。一个服务器，全部的终端有3000多个，其中活动链接有60,70左右，最高的时候（部分sql语句不走索引）有400。每天产生的redolog为50G。我们也试图想让数据库运行在archivelog mode ，但是系统从上线后就有性能问题，archive的所有工作都准备好了，就是没有办法启动。不过我们有大量的使用exp导出文件做备份和恢复的经验（每年省级的服务器最少出事故3次，恢复时间不超过24h）。说到底，我们做技术的都想试试一些新功能（archive 对于我们来说，还是比较新的，所有的操作都是纸上谈兵），但是现实使我们不得不放弃，敢问楼上的兄弟们，你们的营帐服务器可以在archivelog mode模式启动，没有什么性能问题吗？
        还有一个问题，你们的话单汇总是如何实现的？在详单服务器上汇总，还是在营帐服务器上做？

lx_king

起不来 为什么？

wolfop

你估计是搞电信计费的，我们的营帐系统不考虑计费，或者说基本不考虑。即使要对实时话单累加也不通过数据实现，数据库只更新累加结果。所以数据的日志不会太大？
你们500G的数据库大小一天REDOLOG 50G，这么恐怖啊？除非我们的计费系统20T的容量才可能这么大的日志，ORACLE 的REDOLOG不是比较小吗？

trouble

最初由 wolfop 发布
[B]你估计是搞电信计费的，我们的营帐系统不考虑计费，或者说基本不考虑。即使要对实时话单累加也不通过数据实现，数据库只更新累加结果。所以数据的日志不会太大？
你们500G的数据库大小一天REDOLOG 50G，这么恐怖啊？除非我们的计费系统20T的容量才可能这么大的日志，ORACLE 的REDOLOG不是比较小吗？ [/B]

请教一下楼上的兄弟，对你的这句话实在是搞不明白“即使要对实时话单累加也不通过数据实现”，不通过数据，那么是通过什么呢？
我是做移动计费的，每个log有200M，6个group，平均每一分钟左右，我们的营帐数据库就switch 一个log，使用archive根本做不起。

trouble

真的是非常虚心的请教

wolfop

写漏一个子，不是不通过数据实现，是不通过数据库实现。用基于文件系统＋自己写的索引实现，累加话单用数据库开销太大，而且这些实时话单不是真正的计费依据。
我们这里即使原来处理话单的计费系统的话单也不入库的，当然现在新的用大机器了将批价后的话单入库了。