可以看一下swap利用率高的进程是哪个,如果不是应用进程或者操作系统重要进程的话就要考虑重启进程,或者实在不行就重启应用或数据库释放,90%已经很危险了,再高操作系统会夯死。
如果不考虑信创,O的集中式架构绝对满足中小银行的业务需求,再加上现在io问题也随着全闪存阵列、一体机等新硬件的性能提升得到解决。所以没必要非要用分布式数据库,分布式数据库的优势是天然具备两地三中心高
不同数据库的优化器的算法是不同的,sql如果变慢了,一方面要看sql语句是不是优化器路径有问题,这个可以通过改写sql或者指定sql执行路径来解决,如果直接就是数据库读写性能的问题的话,就只能通过硬件加速或者找原厂来解决了
可以建一个函数索引,decode( BANKSWIFTCODE,null,0,1) 这样就可以走索引了
不需要,如果要基于时间点备份,可以指定scn
赞同韩老师的观点,国产数据库在成熟度方面确实还需要很长时间的验证和提高,不说别的,只说官方文档跟O相比就差很多。生态也是差很多,这个没办法,只能随着市场上用的人越来越多,不断的有人来完善这个生态,功能方面我觉得国产
分布式数据库的扩容肯定会涉及到数据的重分布,这个过程比较耗费资源,当然可能会影响正在运行的业务,就我接触的扩容来说,基本原理就是建立中间表将数据重新插入到新表,之后再做rename的操作,这个过程最好还是停止业务去做,如
个人觉得还是原生分布式数据库更好,分布式中间件对应用的改造量比较大,而且如果要做在线扩容的话比较麻烦。
金融行业目前都是做双向同步,完了把国产数据库先作为备库去验证完之后才正式承载业务的吧,没有一上来就把国产数据库做生产的,而且即便迁移了原来的数据库还会并行用一两年,做逃生库。
主要看数据量和备份速度了,如果数据量大到做一次全备超过24小时,就没什么意义了,备份周期太长,数据的一致性和实效性都没法保障,这个时候还不如做大数据的容灾,通过数据同步技术实时同步数据到备库。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30