iwanghc

### **问题原因：** oracle.jdbc.timezoneAsRegion属性是在Oracle JDBC驱动程序的较新版本中引入的，主要用于处理日期和时间时区信息。 此问题在Oracle11g中复现，Oracle12c中并未出现， 所以Oracle JDBC驱动程序的早期版本（如Oracle 11g中使用的版本）可能不支持此属性 ### **可行解决方案：** **方案一**、dms中添加cloudbeaver map类型配置【properties】，并设置"oracle.jdbc.timezoneAsRegion": false，将新建数据源timezone region默认关闭 **方案二**、在cloudbeaver中启动脚本中（cloudbeaver容器/opt/cloudbeaver/run-server.sh）设置jvm参数， 指定时区： export JAVA_OPTS="-Duser.timezone=GMT+08" 或者将其设置为false：（不建议） export JAVA_OPTS="-Doracle.jdbc.timezoneAsRegion=false" ### **最终方案：** 方案一 原因：timezoneAsRegion设置为true时会将数据库中日期时间转为本地时区，对于sqle来说几乎不会使用， 且oracle11g中并无此属性，所以可以默认设置为关闭，若oracle12c有需要使用，在cloudbeaver驱动属性中打开即可。

### 验证Oracle TOP SQL任务问题 - 创建oracle扫描任务时获取不到TOP SQL任务类型 oracle扫描任务获取的instance type错误 ### 验证DM TOP SQL任务问题 - DM智能扫描任务TOP SQL采集sql失败 修复达梦采集sql时，获取不到实例

### 验证SQL管控的问题 sql管控获取sql分析时报错 

## 智能扫描动态参数联动问题方案 ### 背景： 慢日志类型参数“采集周期”、“启动任务时拉取慢日志时间范围”仅对 mysql.slow_log 表有效，所以需要在当采集来源选择slow.log文件采集时隐藏这两个输入框。 ### 方案一： 后端修改GetAuditPlanMetas接口层的ParamsRes参数结构，调整ParamsRes为父子结构，或ParamsRes新增字段依赖需要联动的key与value 优点：返回的结构清晰 缺点：不易做成通用，有一定局限性，多参数依赖的话只能处理与的联动关系。 影响面：较小，如果仅对mysql慢日志参数特殊处理的话不影响其他扫描任务类型。 ### 方案二： 调整params包Param结构体，新增字段依赖需要联动的key与value（接口层也同步新增字段） 优点：可以做成通用 缺点：有一定局限性，多参数依赖的话只能处理与的联动关系。 ### 方案三： 前端对mysql慢日志的参数做特殊处理 优点：成本小，后端不需要调整 缺点：处理后续新增的扫描任务类型或以后其他需要联动的参数 影响面：不影响其他  ### 最终方案 前端mysql慢日志的参数做特殊处理 原因：后端处理通用性不强，后续若出现稍复杂的依赖关系不易处理，目前仅有mysql慢日志参数需联动，且成本不高，所以由前端处理（隐藏参数也需要提交，因后端有对参数数量有做校验，后端需补充参数默认值，以默认值提交即可）

### 扫描任务操作按钮根据权限显示和隐藏 1、创建编辑页面，可选数据源根据权限显隐【前端】 2、页面增删改和立即审核按钮根据权限显隐【前端】 3、实例扫描任务接口返回instance id，支持前端获取权限【后端】

关联Comment：https://github.com/actiontech/sqle/issues/2523#issuecomment-2295848522 实例扫描任务列表instance_id出现精度丢失 解决：返回转成string返给前端

关联遗留问题：https://github.com/actiontech/sqle/issues/2572

Ok, thank you for your reply. @EvgeniaBzzz

## 智能扫描报告中LastCollectTime字段与同步任务更新冲突问题 1. AuditPlanV2表是否仅作为配置表，如果仅作为配置表存在，LastCollectTime属性与表定义存在冲突（这种情况需要拆表解决） 2. 当AuditPlanV2作为扫描任务记录，那么默认update_time字段值的变更，不应该被识别为任务做变更。应该由其他标准来确认配置变更（才能做出任务更新/删除动作）  - 方案1和2选中一个来解决 评估影响面和兼容 ### 方案一： 影响面：新增一个记录最后采集时间的表 1、任务采集sql：在每次进行采集的时候更新该时间 2、定时同步任务：记录配置更新时间到内存，每次根据更新时间查需要同步的任务 3、概览列表查询时关联该表、删除任务/实例任务时关联删除 兼容性：不兼容旧版本，需要将配置表记录的最后更新时间迁移到新表中，并删除扫描任务配置表的last_collect_time字段， ### 方案二： 影响面：在配置表新增一个字段记录配置最后更新时间 1、定时同步任务：同步任务时根据配置最后更新时间筛选需要同步的任务 2、在更新扫描任务配置、删除扫描任务时都需要更该字段 兼容性：兼容旧版本 ### 最终方案：方案一 方案一合理性：在配置表中不存储业务信息更为合理，将最后采集时间拆分出来。 优点：后续若有业务需要，任务有新的业务信息需要补充可以在此表新增字段，相较于方案二，不需要在更新删除任务时关注时间字段的更新。 缺点：成本略高 ## 升级方案：...

## 优化扫描任务审核逻辑，避免阻塞页面显示 ### 背景： 当采集的sql数量较大时，由于审核的阻塞，导致在前端展示会有一定时差（队列每次peek1000条-->批量审核(耗时)-->设置高优先级-->数据落地-->移除被peek的队列数据） ### 解决方案： 1、调整扫描任务审核逻辑（队列每次peek1000条-->开启事务-->数据落地-->移除被peek的队列数据-->提交事务-->开启协程-->批量审核(耗时)-->设置高优先级-->更新数据） 2、扫描任务sql列表的审核结果列补充一个审核中，首次采集到的sql数据落地但未审核完时展示为审核中 3、在sql管控列表的审核结果列补充一个审核中，审核结果为NULL的展示为审核中（需要调整sql管控接口定义，新增audit_status字段）  ### 影响： 1、智能扫描 2、sql管控 （采集后页面第一时间不能展示出审核结果和高优先级内容，影响仅在数据量较大时有感知） ### 兼容性： 兼容旧版本