前言：
在信息技术自主可控的浪潮下，我部门核心业务系统于2021年启动数据库国产化替代工程。历经从Oracle到Kingbase V8.3的初代迁移，再到V8.7的特殊迁移，并在特殊场景下完成V8.7到V8.6的备份还原验证，实现了数据库全生命周期的自主掌控。本文将分享这一过程中的技术挑战与实践经验。
一、破局：从Oracle到Kingbase V8.3的初战
2021年，我部门核心业务系统在相关部门的要求下，开展国产化替代工程，一个由里到外替代的过程，即从服务器、操作系统、数据库、中间件、vpn等等来一次脱胎换骨的替代。作为甲方DBA，对kingbase也是十分陌生，因此也是从那时开始从零开始学习kingbase，恰逢我省正举办信创大赛，其中数据库管理比赛项目使用的正是kingbase，借此机会除了学习到很多kingbase基础知识以外，也向kingbase培训讲师请教过不少问题。
回归正题，项目迁移尽管大部分工作由乙方承担，但作为甲方决不能放任不管，例如甲方提出的新需求即便是简单的查询展示需求，乙方总以系统架构限制无法实现，对此在许多需求场景下，都是由我编写好查询展示的sql丢给乙方去做前端界面。
二、考验：V8.3到V8.7安全迁移的攻坚战
2023年，上级部门加大对系统安全的监督，以及我市政务网络的调整，此项目被迫迁移到专网。可能很多人对kingbase V8.7非常陌生，这也不奇怪，毕竟奢靡版本使用场景并不广泛。之所以是攻坚战，是因为时间非常紧迫，不在规定时间改造并备案，会造成系统下线，影响范围是全市。此战最大的挑战，反而是兼容性问题，看似V8.3到V8.7是在升级，其实不然，V8.7是基于V8.2改造的，数据库迁移过后，很多日常的sql需要重写。此外，数据库三员改造也是一个全新话题。
这一年我也并没有闲着，而是继续在kingbase领域持续学习获得kcp。
三、守护：V8.7到V8.6备份还原的守护战
项目验收工作，因乙方单位的变更，新合作乙方对原系统代码不熟悉导致验收时间拖到2025年。而因国产化替代的政策与推进方向的转变，V8.7已基本退出历史舞台。但是我们的系统依然健在，数据库备份与还原就显得困难重重。第一无法再购置同版本的数据库配套的服务器，第二乙方的能力范围内仅可实现备份，手动异机还原。
针对此问题，我利用部门在用的备份系统，鼎某又命某甲，实现了对生产环境的定期全备，但是还原始终不顺利，因不同版本之间，全备还原限制很多，而逻辑备份还原也不顺利。耗时近一个月，前前后后测试过3个V8.6的不同小版本，在kingbase技术人员的推荐下终于找到能实现与V8.7全备还原的版本，最终实现定时自动异地备份还原。
结语：
从Oracle到Kingbase V8.3的国产化破冰，到V8.7的安全改造，再到跨版本的备份还原，这条曲折的道路印证了金仓数据库的成熟度与工程可行性，但因项目敏感性，不便提供更多项目细节及代码。未来我将继续深化对kingbase的学习，为国产数据库生态建设贡献实战经验。
