一般常用的交易型的数据库都不会特别大,比较大的基本都是OLAP类的分析性数据库,这种数据库目前基本上都转向分布式架构了,分布式架构的备份其实还是问题,虽然分布式数据库都有多副本技术,但是有时候也会面临整个分布式集群
250公里只能做数据级的灾备吧,要做应用级灾备的话成本太高,而且必要性也不大,你的数据中心的建设本来就要考虑应对各种非自然灾害,异地主要是应对超大自然灾害,这种情况发生的概率跟你投入的成本相比就太浪费了,必要性不大
完全可以靠备份工具和备份策略来实现,麻烦肯定是少不了的,最好是搞集中备份平台,要不然搞成数据孤岛,更不好管理了。
应用级灾备目前已经基本都是应用双活+数据库的主备这种方式,应用的双活依赖DNS和F5都可以做,数据库的话双活来讲由于受到运营商线路质量的影响比较大,基本还是采用主备的这种方式。成本的话要看你是要实现那个级别的灾备
我们的应用程序通过上线流程控制,应用程序的中间报文通过跨中心的GPFS共享文件系统实现,这种方式目前来看比较成熟,也未出现过问题。
脑裂分两个层面,一个层面是共享存储的脑裂,另外一个层面是数据库RAC层面的脑裂,共享存储的脑裂通过第三方站点仲裁避免,数据库层面的脑裂通过磁盘心跳和网络心跳避免,由于发生心跳网络中断时可能同时导致存储和数据库的仲
现在Oracle新版本对内存优化已经做的比较好了,每个系统要根据每个系统的性能测试结果调整内存参数,由于现在服务器内存基本都配置的比较大,基本上现在数据库遇到的绝大多数主要是IO、心跳网络、CPU相关的问题,这些问题的
从db2迁移到oracle不单单是数据迁移,会涉及到很多方面的东西,工具只是一方面,具体到应用程序会有很多变化,所以建议对不同表做不同的迁移策略,迁移后你的应用程序估计都要变了。
对于第一个问题不用设置本地备库的应用时延,在远端ADG库开启闪回就可以了,很方便,我们现在就用的这种方案。第二个问题本地ADG备库肯定要使用最大保护模式,最大保护模式数据必须写到备库返回给主库事务才会提交,所以100%不
awr报告可以分析,或者你直接从v$sql v$session等相关视图里去查询
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30