搜索[补数据]结果-低调大师优秀个人博客

Vue 3 里数据明明改了，为什么页面上没反应？

**这类问题的根源几乎都能归到一处：这份数据已经不在响应式系统的追踪范围里了。** ## 响应式的追踪是怎么建立的？这套系统的做法是：读取时记录谁在用这个数据，写入时通知这些使用者。

2026-09-29

保留存储不等于数据不用迁：替代边界核验

“存储设备保留”不代表原有数据存储格式可以直接被新平台接管。共享存储协议、文件系统与虚拟磁盘格式属于不同层次。

2026-09-29

2026年出海AI企业如何采购海外多模态训练数据？

** *不同市场的数据保护法规差异，叠加多语言、多文化场景覆盖需求，让出海企业的数据采购复杂度远超本土业务。

2026-09-28

数据采集需求增长，代理IP选型会发生什么变化？

数据采集需求增长后，代理IP选型最明显的变化，不是大家突然需要更大的IP池，而是开始追问一件更具体的事：**这些连接，能不能在需要的时间，把需要的数据稳定送进来？** 过去很多采集项目是“攒数据”。

2026-09-28

量化交易本地数据交互：主流方案、实现机制与选型对比

在做量化交易中，我们经常回设计到一个问题，数据的交互，量化软件数据保存到本地，本地的数据导入量化系统等，数据的交互主要涉及到交易序号的交互，数据行情的交互，下面是几个常见的方式，本质都是一样，通过一个中间的文件保存

2026-09-28

【赵渝强老师】崖山数据库的控制文件

数据库的名字。 2. 数据文件和联机日志文件的名字及位置。 3. 创建数据库时的时间戳。 4. 备份的元信息。

2026-09-25

国际原油行情查询API :实时油价、历史数据采集

## 一、应用场景原油作为核心大宗商品基准标的，很多内部业务系统需要接入行情数据，常见需求包括：定时拉取入库、BI可视化展示、价格阈值告警、历史价格复盘。

2026-09-24

工业数据质量——传感器漂移和异常值处理实战

做数据采集的人都知道一句话：“Garbage in, garbage out.” 数据质量不行，后面做什么分析、什么AI、什么优化，全是白搭。一个让我印象深刻的数据质量事故。

2026-09-24

腾讯云AI应用数据保护：应对模型迭代快于备份窗口

训练数据集的版本管理、推理日志的合规留存、向量数据库的持续写入，这些数据形态跟传统业务系统完全是两个物种。

2026-09-22

敏感内容识别：从“关键词拦截”转向“数据风险发现”

### 2、敏感文件扫描策略【配置敏感文件策略】，同样维护关键词列表，每条规则可设置**类型、数据、分值**。敏感文件认定规则：**总分超过设定阈值，即判定该文件为敏感文件**。

2026-09-22

园区充电桩海量数据接入，MyEMS 采集与能耗分摊实践

系统采用双库策略： - MySQL 数据库：存储配置信息、用户数据、计量点位台账、费率规则、成本中心等结构化数据 - 时序数据库：存储海量能源实时数据与历史数据，针对能源数据高频率、高维度、高压缩比的特点进行深度优化

2026-09-22

用 Jev 把测试员的直觉变成可追溯的数据

--- ## **七、这套方案能带来什么，不能带来什么** **能带来的：** - 让探索性测试的产出从"一堆聊天记录"变成可以按模块、类型、严重度筛选和统计的结构化数据； - 保留测试员原始判断的同时

2026-09-21

数据加密软件怎么挑？让文件出公司就打不开

https://developer.qcloudimg.com/http-save/yehe-12625089/6a364712383cf8d561d2d70b4290b026.png) ## 四、边界与补位

2026-09-21

从复购分析看业务定义、数据方案与团队协作

> **摘要：** 从确定指标、接入数据，到完成专题分析、培养内部团队，数据分析项目需要扎实的技术实施，也需要相应的业务方法。

2026-09-20

国内大模型能用哪些数据作依据

真正的问题不在词的多少，而在于我们还没有把“选词”当成一件有数据支撑的事来做。

2026-09-20

现在我排查问题，越来越多交给 AI 跑，形成了极大依赖。最近测试环境有人报这台 175.186 的库 `/arch` 撑到 95%，我本来得自己 ssh 上去、一条条查视图、算缺口、写删除脚本。这次我把活全丢给 AI 了——它写诊断脚本、跑命令、读视图、算文件缺口，我基本只动嘴。省事是真的省事。但过程又一次证明：**AI 没经验、有误区，关键判断还得人拍板。**不过也同时说明以后我还是会这样去做的。 --- ## 一、AI 上场：它替我把脏活全干了环境是 175.186（源库 STG19C，一个 19c CDB，挂着十几个 PDB），归档目录 `/arch`。我贴了一段 RMAN 现场：`crosscheck archivelog all` 只校验出 15005~15023 共 19 个归档，想删老归档又被 `RMAN-08137: needed for standby or upstream capture process` 拦住；而 `ls /arch` 看到的文件是 3 月份的 14184~14190 和 9 月份的 15005 往后，中间断了 813 个。我让 AI 上机诊断。它一口气干了这些： - 写了 4 个诊断脚本，逐个 scp 上去执行； - 查 `v$database`、`v$archive_dest_status`、`v$managed_standby`、`dba_capture`、`dba_registered_archived_log`、`v$archived_log`、`v$session`； - 在 OS 层 `ls /arch` 统计文件数、算序列缺口、看 crontab 找清理脚本； - 把"假缺口"和"真孤儿"区分开，把 OGG 所在机器定位出来（这里其实不是他知道有OGG，是因为我知道有OGG。我们自己做的我们知道）。这些重复劳动它干得又快又稳，**我不用再一条条敲命令**。但一涉及"该怎么判断、能动哪块"，它就开始露怯了。 --- ## 二、AI 的第一次跑偏：把 RMAN-08137 的 "standby" 当真现场最唬人的一句是：`RMAN-08137: needed for standby or upstream capture process`。字面上写着 "standby"，再加上归档之间"断了一大段"，第一反应很容易是——**"有 Data Guard 从库，而且从库落后了 / GAP 了，得修 DG。"** AI 也顺着这条线查了 `log_archive_dest_2`、`fal_server/fal_client`、`v$archive_gap`。但我让它去**核实到底有没有从库**，结果一查就翻案： ``` -- log_archive_dest_2 是空的，fal_server/fal_client/log_archive_config 全空 -- v$managed_standby 里只有 ARCH(CLOSING) 和 DGRD，没有 MRP、没有 RFS -- 根本没有挂载的备库 ``` 那 08137 里的 "standby" 是**误读**——真正的拦路虎是 **OGG 集成捕获进程**。我在 186 上查 `v$session`，一堆捕获会话的来源清清楚楚： ``` MACHINE = stg-ogg-175187 PROGRAM = extract@stg-ogg-175187 (TNS V1-V3) USERNAME = C##OGG ``` OGG 服务端根本不在这台库，而在 **175.187**。10 个 `OGG$CAP_EX*` 捕获进程，以 `C##OGG` 连过来，在 `dba_registered_archived_log` 里注册了 **43649 条**记录——这才是 RMAN 不敢删归档的原因。这一步如果没人把关，AI 会一路去"排查 Data Guard 缺口"，越查越偏。**专家的价值就在这：先确认"到底有没有从库"，而不是被报错字面带着走。** --- ## 三、AI 的第二次跑偏：想用 RMAN 一把清，险些误删在用日志确诊是归档堆积后，最朴素的想法是：**"那不就 RMAN 删归档嘛，DELETE ARCHIVELOG ALL 一把清。"** AI 的第一版方案也往这靠。但我让它先把"能删 / 不能删"算清楚，一对就发现这条路走不通，而且有雷： **第一，孤儿文件 RMAN 根本删不掉。** `control_file_record_keep_time=7`，控制文件里归档记录的保留期只有 7 天，是循环复用的——老记录早被顶掉了。所以 `/arch` 里 13310~14190 那 601 个文件，在控制文件里已经是 `deleted=YES / status=D`，**Oracle 已经"忘记"它们，RMAN 看不见，自然删不掉**。 **第二，在用日志删了会出大事。** 15005~15023 这 19 个，是 OGG 捕获还注册占用的（08137 保护），`DELETE` 删不动。但更要命的是——**绝不能 ****`DELETE FORCE**`** 强删**。强删会让还在注册的 OGG 捕获报 `ORA-01292 找不到 logminer 文件` 而 abend。这正是我们 9-15 在 146.86 上踩过的同一个坑。所以正确的做法不是 RMAN，是 **OS 层 ****`rm**`** 只删孤儿**： ``` # 先干跑，列出待删清单并校验不碰在用日志 ls -1 /arch/1_*.dbf | awk -F_ '$2+0 /tmp/del_arch_list.txt # 校验：清单里混入 15005+ 的数量必须为 0 awk -F_ '$2+0>=15005' /tmp/del_arch_list.txt | wc -l # =0 # 确认无误后再删（仅删除控制文件已忘的孤儿） xargs -a /tmp/del_arch_list.txt rm -f ``` 我让 AI 严格按"先 dry-run 校验、再执行"走，删前确认清单混入 15005+ 的数量 = **0**。结果： |指标|删前|删后| | --- | --- | --- | |/arch 使用率|95%（剩 18G）|61%（剩 117G）| |释放空间|—|约 100G| |文件数|620|19（15005~15023 完好）| |≤14190 残留|601|0| `alter system switch logfile` 验证归档生成正常，OGG 在用的那批一个没碰。**这步如果交给 AI 自由发挥，一句 ****`RMAN DELETE ARCHIVELOG ALL**`** 要么删不掉孤儿（白忙），要么撞 08137，最糟还会 FORCE 删用在用日志触发 ORA-01292。** --- ## 四、AI 的第三次跑偏：没看穿 keep_time 的死结删完腾出空间，我问了一句：**"这是因为没有定期删除归档的机制，而控制文件只保存了近期，只能控制近期导致的对吧？"** AI 第一反应差点顺着答"对，就是没机制"。但再一查 crontab，发现**机制是有的**： ``` 0 2 * * * /arch/clean_archivelog.sh ``` 脚本里写的是 `DELETE NOPROMPT FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'`。那问题出在哪？其实我把根因看穿了，AI 只是确认并修复： > **保留策略（7 天）恰好等于控制文件可见期（7 天），中间没有缓冲。** 文件满 7 天该删，可一旦删除动作稍晚一点，控制文件里的记录已经被顶掉、Oracle 忘了它，RMAN 永远看不见 → 文件永久脱管，堆在盘上变孤儿。治法很直接：把 `control_file_record_keep_time` 从 7 提到 30，让"账本记得久一点"，给删除动作留出缓冲。 ``` alter system set control_file_record_keep_time=30 scope=both; -- 回滚：alter system set control_file_record_keep_time=7 scope=both; ``` 改完 `memory` 和 `spfile` 都是 30。现在 `keep_time=30 > 保留期 7天`，7 天前该删的归档在 30 天窗口内控制文件里仍有记录，RMAN 看得见、能删得动了——原来的死结解了一大半。 **这里 AI 的误区在于"看现象下结论"：看到孤儿堆积就说"没机制"。专家看的是机制为什么失效，是"保留期=可见期、无缓冲"这个结构性死结。** 这两句话差着一层原理。 --- ## 五、175.187 我没让 AI 碰整个过程中，我在 187 上自己确认了"确实有 OGG"，然后明确说：**"175.187 情况不清楚，先不要动。"** 这正是专家和风险意识的体现。187 是 OGG 服务端，跑着 10 个捕获、连着一堆 PDB 的下游。它和 186 的归档纠缠在一起（08137 的根因有一部分就在 187 的测试捕获）。在没摸清 187 上 Extract/Replicat 状态之前，任何"顺手清理"都可能把同步链路搞挂。所以这次我只动了 186 的 `/arch` 孤儿文件 + 参数，**187 一直没碰**。 --- ## 六、还留着的那块（等下再做）现在 `/arch` 安全了（61%），但 15005~15023 这 19 个在用日志**暂时仍删不掉**——它们被 187 上的测试捕获 `OGG$CAP_EXTEST / EXTEST1 / EXTEST2` 注册占位。这三个是测试捕获，其中 `EXTEST` 的 `captured_scn` 还卡在起点、`applied_scn=0`，从起始点就把老归档钉死，是 43649 条注册记录的大头，也是 `RMAN-08137` 的元凶。清掉它们，注册记录释放，RMAN 才能正常清理那 19 个日志。但这活牵连 187，**稳妥起见，我们先不做**。 --- ## 七、总结：用 AI 替自己干活，好处是实打实的：诊断脚本、视图查询、文件缺口计算、干跑校验、实际删除，它全包了，**我不用再劳心劳神地敲命令，甚至有些命令生疏了，我需要从记事本中复制，现在连复制都不用了**，把我从重复劳动里解放出来。这才是专家该有的样子——把力气花在判断上。但它的短板这次也还有有点问题：**遇到"报错字面 vs 实际含义""RMAN 能删 vs 不能删""机制存在 vs 机制失效"这类需要原理理解和风险意识的判断，它会顺着最省事的路径走，甚至差点动用在用日志。** 尤其是 RMAN-08137 这种把 "standby" 写在脸上的报错，几乎必然把人（和 AI）引向"查 Data Guard"的死胡同，而真正的答案藏在"OGG 捕获注册 + 控制文件健忘"里——这是原理级的理解，搜不出来，只能靠经验和对环境的熟悉。

2026-09-20

精选列表

Vue 3 里数据明明改了，为什么页面上没反应？

保留存储不等于数据不用迁：替代边界核验

2026年出海AI企业如何采购海外多模态训练数据？

数据采集需求增长，代理IP选型会发生什么变化？

量化交易本地数据交互：主流方案、实现机制与选型对比

【赵渝强老师】崖山数据库的控制文件

国际原油行情查询API :实时油价、历史数据采集

工业数据质量——传感器漂移和异常值处理实战

腾讯云AI应用数据保护：应对模型迭代快于备份窗口

敏感内容识别：从“关键词拦截”转向“数据风险发现”

园区充电桩海量数据接入，MyEMS 采集与能耗分摊实践

用 Jev 把测试员的直觉变成可追溯的数据

数据加密软件怎么挑？让文件出公司就打不开

从复购分析看业务定义、数据方案与团队协作

企业智能体连接数据库方案对比分析

国内大模型能用哪些数据作依据

重度依赖Agent管理数据库：我让 AI 清理归档

电脑加密软件：企业终端数据防护选型误区与落地实践

量化交易的核心逻辑：从数据到下单全流程解析

gPTP精密时钟同步：自动驾驶车载数据技术应用方案

资源下载

Mario

腾讯云软件源

Nacos

Spring

欢迎您来访！