估计大部份的工作都是放在数据端里修改,应用里会比较少改。因为,是迁移数据库,不是迁移应用。除非是数据库端不能修改,或者修改风险大于修改应用端,才修改应用端。一般都是修改数据库端。
好问题,我也想问同类的问题,就是异构的数据库有什么好的转换工具,减少迁移的时间和后期手工调整SQL的时间?
最好还是升级。
这个最好看看IBM官方网站有没有针对这个漏洞提供IFIX(内部修补)和修补意见,如果有就打上。如果没有,那可能IBM也不认这个是漏洞。有可能是绿盟误报。
看看是不是磁盘坏了,进单用户系统 fsck试试了。
好像没有这个限制,曾建个30T的linux vg.只是在VG创建的LINUX的文件系统好像最大只支持到16T。
Linux6/7都可以,OL 6/7也可以。
你先理清,你想采购的数据库产品满足什么样的性能,安全标准,支持什么业务应用,然后,就知道技术规格书,怎样写。
可以尝试考虑做云平台的双活,也就是做多个云平台,互备。
B机的实例,平时是关闭状态,在HA 发生切换,从A切换到B机时,才启动实例,再挂载共享卷组里的数数库目录文件吧?
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30