针对城商行稳态业务核心系统的国产数据库选型而言，以下选型标准框架是否完整？敬请大家投票把关。
希望城商行的各位同行专家，能从城商行选型国产数据库角度出发，基于核心系统的实际业务场景需求（高并发、高可用切换、7x24高稳定等）出发，判断以下表格内的选型标准框架是否完善，参与投票以及提出您的观点和建议。
- 如您认为以下选型标准框架已经完善，请在下方投票选项勾选——A、无需调整，可以直接作为我们核心系统国产数据库选型测评标准框架；
- 如您认为以下选型标准框架不够完善，请在下方投票选项勾选，并且点击【讨论】发表您的观点——B、需要调整，建议如评论区所示；
↓ ↓ ↓ ↓ 投票栏在下方 ↓ ↓ ↓ ↓
背景介绍
随着信创数据库逐步从周边进入到核心关键应用，同时也看到了走在信创前列的一些企业遇到了生产系统稳定运行的巨大挑战。数据中心生产系统应要秉持稳定压倒一切的基本原则上不断演进信创和创新。
因此为了给城商行负责信创数据库工作的同行提供核心系统的国产数据库选型决策参考，我们需要一个形成共识的选型评估框架作为尺子指导大家的信创工作落地，如下表格为社区数据库自主可控课题组专家“大唐小少”梳理的初版选型评估框架。
本投票自企业IT应用趋势项目创新联盟——数据库自主可控 课题组发起，由某银行数据库架构师：闫昕主持，基于twt社区平台面向城商行行业群体征集投票和补充建议，最终《城商行稳态业务核心系统国产数据库选型评估框架 》将发布到社区平台供各位同行参考。
每位反馈了建议的同行，均可凭点评截图向社区工作人员领取100社区金币，联系方式：微信号twthenglong。
《城商行稳态业务核心系统国产数据库选型评估框架——初版》
投票选项【单选】
- 无需调整，可以直接作为我们核心系统国产数据库选型测评标准框架0%
- 需要调整，建议如评论区所示0%
各方声音(9)
1：支持在线绑定执行计划（outline那种），这个功能很重要，因为当前国产数据库经常出现走错执行计划的情况
2：实例的动态扩缩容这个功能最好支持，而且是在线的。如果他们说关数据库后支持扩缩容那就不好了。
3：监控指标的完善性、可观测行这个是需要衡量的。如果只是有这个工具，什么问题都抓不出来那就麻烦了。
"数据库运维管理"中的"数据迁移"中，可以新增迁移评功功能，对源库镜像流量或者全库扫描进行迁移进行兼容性评估，这对国产化改造非常有用。
"数据库运维管理"中的"数据迁移"中，可以新增恢复抽检或者备份验证功能。
"数据库其他功能"中的"数据库性能和稳定性"中，可以增加一键信息收集功能，现在国产数据库迭代较快，经常会遇到各式BUG，排查时候的信息收集与沟通占用了大量的时间，如集成一键信息收集，可较快的排查各类BUG，提高ST解决速度。
“数据库安全功能” 模块中可考虑增加是否支持加密存储，加密方式是否支持国密。
“数据库高可用能力”模块中应考虑跨站点切换时应用端是否无感（该场景主要用于每年度的切换演练）
1、是否有闪回、闪回查询功能
2、知识库文档完善
3、BUG修复计划
4、产品生命周期
5、数据可带条件导出，可选字段导出
6、手动干预sql执行计划，HINT提示或者执行计划绑定
7、提供类似AWR和ASH供性能分析报告
8、支持锁等待源头追踪。
9、故障时关键信息DUMP现场保留。
1、索引可加全局唯一索引，以及索引是否有特殊要求，比如带分片键；
2、功能方面，跨库的数据访问能力，类似oracle dblink;
3、安全方面，支持数据加密，表级别或者是文件级别。
核心系统作为银行的重要生产系统，结合监管和自身的要求，应该具备数据库产品要稳定、数据库底层的核心技术要自主可控（国内生态、国内的研发实力）具备长久独立的发展能力，数据库性能要满足要求（批量时间的限定），数据库的安全性要足够高（数据库自身安全，架构高可用、容灾等）。
建议：
1、增加数据库产品研发能力，同时将“数据库开发功能”合并到“数据库运维管理”，调整比例，同时增加数据库高可用的比例；
2、数据库基本功能不好控制，其实数据库除了支持相应的sql标准外，核心功能还有优化器的能力（保证性能），具体怎么改还是建议先研究一下国产主流数据库的基本功能以及db2、oracle等数据库的功能后再定，而且标准太粗，至少达到什么程度才算合格。
以上仅是个人一点建议，数据库博大精深，能力有限，说的不对的地方，请各位多多包涵。
1.在从开发的角度来说，没有存储过程及自定义方法。
2.处理字符串的方法是否足够，例如对自符串的聚合分组及排序，类似于oracle的listagg方法。
3.对于SQL执行的管理，大部分的开发人员对SQL只要求结果是正确的即可，但数据量到达一定量，是对SQL有一定要求的。