进行核心系 统数据库转型升级牵一发而动全身，需要全面分析转型需求、面 临的挑战，总结经验，推动转型实施。
一是功能方面，核心系统新引入的数据库除了支持传统数据 类型、对象类型、SQL 以及 PL/SQL 等基本功能外，特别需要在 驱动、语法、架构等方面实现与现有国际主流数据库的兼容。且 核心系统需要与交易、结算、风控等不同系统进行无缝集成，所 以，需要核心系统数据库支持常用的数据接口和标准协议。同时， 对于业务量大、性能要求高的核心系统，需要数据库适配新一代 分布式、共享存储集群等架构体系。
二是在性能方面，核心系统对性能的极致要求，需要数据库 具备极强的高并发、高速读写能力，以及满足低延迟、强实时性 要求，并具备灵活的扩展性。核心系统数据库交易处理能力需稳 定支持 1 至 2 万 TPS，峰值支持 2 至 4 万 TPS。核心系统的 OLTP 场景要求数据库响应时间能够达到毫秒甚至亚毫秒级别，OLAP 场景要求数据库响应时间能够达到秒甚至毫秒级别。此外，在分 布式场景下，对数据库弹性扩展能力提出更高要求，实现自动在 线横向扩展，扩展后性能呈线性增加，无明显损耗，且根据业务 量的变化实现对数据库资源的弹性扩/缩容，以应对业务快速增 长和海量数据处理需求。
三是鲁棒性方面，核心系统数据库需要具备稳定性、高可靠 性和高可用性。在负载、数据量或者其它环境因素急剧变化时， 核心系统数据库依然能提供稳定的、可预期的服务能力。核心系统数据库需要满足金融核心业务对数据 100%可靠、99.999%以上 的可用性极致要求。同时灾备能力要求 RTO 为秒级，RPO 为 0， 且要求核心系统数据库能在线修复或者能自检测并自愈，保证金 融服务的实时性和连续性。
四是安全方面，核心系统的数据不仅包括业务数据，还涉及 到客户的敏感信息，其数据库在安全方面要具备“3A+E”（认证： Authorization、授权：Authentication、审计：Audit、加密： Encryption)的能力。通过提供数据库层的身份认证、访问授权、 行为审计，保证正确的人、在正确的时间、以正确的方式访问正 确的数据，并留下访问痕迹以供事后审计。随着数据资产化进程 的加快，越来越强调精细颗粒度的访问授权。同时，为了防止数 据泄露、失窃，多层次、多场景、基于商用密码加密算法的支持， 对于多层次、灵活颗粒度的数据脱敏、数据遮蔽的支持也必不可 少。
一是我国数据库产品在核心系统应用还存在多方面能力不 足。与国际主流数据产品相比，我国数据库产品在 SQL 优化器、 全局事务管理、并发控制、列存和行列混存、共享集群、多读多 写等多个关键核心技术上仍然需要打磨和进一步提升；在执行计 划、资源利用、任务并行、算法、IO、存算分离等方面与国际商 用主流数据库产品仍有一定差距。关键技术能力欠缺不利于我国数据库产品在核心系统的顺利落地应用。另外，核心系统数据库 需要有强大的技术支持服务体系，以及时解决运行过程中出现的 问题，目前我国数据库相对国际商用主流数据库在该方面也存在 不足。
二是我国数据库产品灾备和数据同步水平还难以完全满足 核心系统需求。根据核心业务系统多活容灾建设需求，我国数据 库产品在异地 RPO、故障切换和灾难恢复时间等灾备能力与核心 系统要求还有一定距离。同时，在采用新旧系统并轨运行模式， 确保核心系统转型的平稳过渡，实现核心系统异地容灾，以及在 核心系统数据库作为周边系统为数仓、数据中台、客服系统等提 供实时数据时，都需要进行数据同步，这些对数据库的数据同步 能力提出了很高要求。
三是核心系统数据库创新实施及运维管理难度大。首先，由 于核心系统安全稳定运行是金融机构安全生产的关键，在数据库 创新实践中选择新引入的数据库要慎之又慎，加之目前我国数据 库产品与现有国际商用主流数据库产品还有一定差距，且数量多、 技术路线各异、发展的不平衡等多种因素，给核心系统数据库选 型带来很大压力。其次，核心系统已建设多年，在数据处理逻辑 方面较多依赖数据库本身，通过数据库的存储过程、函数等实现 业务规则中的复杂逻辑计算，而这部分程序可移植性差，一般需 经过改造才可以在新的异构数据库上运行，这些改造在切流后容易给系统带来功能和性能上的风险。再次，为确保业务连续性， 核心系统数据库创新实践通常采取新老系统并行策略，相关的开 发、测试涉及新老两套系统，为确保新老系统的功能一致性，极 大增加了开发测试难度。此外，现有数据库中存量数据大，迁移 工具有限，导致迁移周期长，且由于技术队伍的不稳定、掌握新 技术产品的人员有限，进一步加大了核心系统数据库创新实施难 度。最后，由于运维的整体自动化、智能化水平有限，不同类型 技术产品还难以做到统一运维管理，核心系统引入新的数据库， 特别是分布式数据库架构复杂、集群规模庞大、技术多样化、运 维管理复杂，进一步增加了运维保障难度，为核心系统安全稳定 运行带来隐患。
一是加大产用联合创新力度，基于核心系统应用场景打磨优 化产品，提升服务能力。数据库厂商在自我研发、创新同时，还 应进一步加强与金融机构的联合创新力度，充分利用在核心应用 中复杂、高压、苛刻的场景，对产品进行反复打磨和优化，补齐 在核心技术、灾备能力、技术服务能力的短板，满足核心系统数 据库创新实践需求。同时数据库厂商需要与操作系统，芯片等数 据库依赖的关键软硬件生态厂商展加大容性适配，并进一步依托 我国在存储、计算、网络方面已经取得的产业优势和成熟经验， 联合创新，实现数据库产品性能、可用性、集约性的突破。例如在高可用高可靠方面，通过主备架构、多主架构、共享存储集群、 分布式集群等架构，实现数据库的高可用性和容灾能力，设臵自 动故障切换和数据同步机制，确保系统在发生故障时能够快速切 换到备用节点，并提供持续的服务。此外，产业侧需要提升数据 库服务能力，不仅要提升原厂服务能力，同时也要通过原厂的培 训加大数据库认证学习，为用户团队培养更多的数据库人才。
二是安全与应用并重，合理选型，高效推动核心系统数据库 创新实践。由于金融业核心系统属于国家关键信息基础设施，核 心系统在选择新引入数据库时，首先要考虑金融安全问题，其次 考虑业务需求、自身技术实力、成本及数据库产品特性，综合评 估后进行合理选型。针对传统核心系统与数据库采取的紧耦合模 式带来的改造难度风险，核心系统数据库创新实践需秉承多品牌 的策略，避免形成对单一数据库技术和产品的绑定。同时，为了 提高应用研发和改造效率，降低后续产品收敛升级改造的成本， 需要在技术路线、研发标准方面进行统一约束规范，尽量选择对 业务侵入性比较小的数据库，最大限度实现应用与数据库解耦。
三是加大生态工具的研发应用，支持核心系统数据库创新实 践。在数据库迁移方面，梳理核心系统常用数据库的特性，分析 新引入数据库的实现差异，开发自动化迁移工具，周密设计迁移 规则和数据库处理逻辑的对等转换模式，对于源数据库的复杂特 性和巨量存储过程提供自动化迁移能力，以降低迁移改造人工成本。在数据同步复制方面，优化异构数据库增量数据复制工具， 在新老系统并行阶段，通过数据同步工具进行业务高峰期增量归 档数据在异构数据库间的双向复制，实现新老系统业务数据的准 实时一致，确保故障场景下能及时回切，提升对外服务的连续性。 在数据库开发方面，通过研发友好的功能强大的客户端工具支持 数据库设计、开发，提升数据库开发者的工作效率。在测试方面， 研发覆盖单元测试、功能测试、性能测试、生产验证和测试管理 过程的自动化测试工具链，降低测试人力投入和测试复杂度，提 升测试效率。在数据库运维方面，通过完备的数据库运行状态检 查、监控、备份、恢复接口和工具，为核心系统稳定运行、数据 安全提供保障。
四是加强核心系统数据库创新实践的统筹管理、经验总结， 逐步形成指导行业实践的方法论。金融机构应将核心系统数据库 创新实践，纳入整体“一把手”重大工程规划中，统筹推进、重 点关注，确保资源投入、精心设计、稳步实施。同时建立并行运 行机制，明确专业分工，将基础技术和应用技术分开，安排专人 进行版本管理和程序发布工作，减少核心业务应用系统开发人员 转型难度。另外，在进行核心系统数据库升级优化时，金融机构 要充分总结经验，编写部署方案、技术方案、数据库迁移技术指 引、数据库迁移测试白皮书、各类工具使用手册等涵盖数据库升 级优化全过程的指导手册，形成整套的系统性技术资产、解决方 案和方法论，以指导后续核心系统数据库全面升级优化。
