从报错日志看dump的代码是-3,就是莫名其妙的失败,怀疑是宕机的时候,磁盘vscsi路径就失败了,导致dump文件根本写入不了磁盘,如果是这种情况,是否有方法可以避免?
1、在实现虚拟化之后,我们原有的集中备份系统依然可以支持虚拟化环境,进行数据备份,仍然保留了虚拟化之前的备份方式。 2、虚拟化之后,由于操作系统是放在存储上,对于操作系统的备份,有更多的功能能够支持备份,如存储快照,虚
谢谢邀请。建议可以从以下几个方面降低集中度带来的风险: 1、应用层面进行高可用建设,降低对底层基础架构高可用的依赖; 2、降低单台虚机上的应用颗粒度,降低影响度; 3、在同一台物理机上对分布的应用分区进行分级,将核心与
目前互联网都是以开放、开源产品为主,但这也需要强大的技术团队支持,如果人力资源投入难以保证,建议采用市场上相对成熟的产品,可以有较好的客户体验,以及更轻松的维护。
产品的选择,各家都有自己的原因,我们在实施虚拟化之前已经有Oracle数据库在使用了,虚拟化之后,主要是进行物理机到虚拟机的改造,未对其他数据库产品进行测试、使用。
1、在Power虚拟化环境中部署数据库,可能一台物理机上的虚机相对会多,但是虚机分布式固定的,并不会经常进行分区在线迁移,管理上并不会陷入错综复杂的感觉; 2、另外监控上需要加强虚拟化环境相关监控,监控VIOS端的网络流量、
1、在Power虚拟化环境中部署Oracle数据库,建议要充分考虑生产、心跳网络带宽需求,尽可能采用万兆网络,做好冗余,避免网络带宽不足或高可用性不足; 2、要预估存储IO的类型及量的大小,根据不同存储访问类型,设计更多的存储路径
以我们的实施过程来看,如果没有涉及到操作系统、数据库版本升级,或者硬件异构环境的情况下,Oracle数据库改造的工作量并不多。建议做好循序渐进的方式,逐步往虚拟化平台进行迁移,按新项目上线方式,做好相应的测试工作。
在由传统物理机方式改造迁移至Power虚拟化环境后,由于基础网络环境配置的优化,基本消除了由于心跳网络时延、拥堵等造成的节点宕机情况,RAC集群稳定性较传统物理机方式大大提高。在虚拟化环境中配置新的数据库集群中,可以
1、这种物理机和虚拟机结合的思路很好,对于重要系统,第一次准备上到虚拟化,总是有很大的担心,这可以是一个逐步适应的过程,根据实际运行情况,慢慢转向虚拟化; 2、从我们目前运行情况来看,可靠性和性能上暂时还没有出现过大问
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30