ANBOB™

在服务器运维中，由于未配置NTP服务或存在CPU时钟精度问题，操作系统时间常会逐渐产生偏差。当需要修正这类时间差异时，通常希望在不停库的前提下完成操作以避免影响业务。
对于采用本地文件系统的Oracle单实例数据库，时间修正主要风险在于业务逻辑中若直接调用SYSDATE函数，可能导致事务时间戳跳跃（如业务单据时间异常），但一般不会影响数据库可用性。然而在Oracle RAC（Real Application Clusters）环境中，时间同步问题可能引发更严重的后果——包括集群实例崩溃和强制重启。

继续oracle “killed” 状态的session无法释放的问题，持有的锁可能会堵塞业务，之前有几种情况可以尝试，也有需要要重启实例才能解决的，这里再记录一种oracle 19c RAC的case, “killed” session在操作系统层的进程已不存在。在数据库中尝试kill session也无法正常清理，后台清理进程无法自动清理。

Udev uses the inotify mechanism to watch for changes in the rules directory, in both the library and in the local configuration trees (typically located at /lib/udev/rules.d and /etc/udev/rules.d). So most of the time you don’t need to do anything when you change a rules file.

最近一个比较新鲜的案例，环境ORACLE 2-nodes RAC,有3个PDB 多租户架构，在节点2在仅做了某1个PDB级的PGA大小参数后,实例2 crash,并且，重启node2 db instance后，逐个open PDB, 仅当open 此PDB时，实例2会再次crash, 并提示错误:
2025-04-15T12:33:53.433625+08:00
Errors in file /u01/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_lmon_50145.trc:
ORA-29740: evicted by instance number 2, group incarnation 121

数据堪称企业的生命线，任何一次不经意的操作失误都可能引发千万级别的经济损失，甚至招致法律上的责任追究。在今天的分享中，我将从规章制度、技术保障以及人员管理三个维度出发，为大家详细解读——无论是面对从Oracle到国产数据库的运维转型，还是探索国产数据库特有的安全机制时，我们应当注意的关键事项。同时，我们也会探讨在利用大型模型进行知识问答过程中可能出现的风险及其防范措施，旨在帮助大家构建坚固的数据安全防线，确保企业数据资产的安全与稳定。

近期OceanBase发布了单机版 – 小规格/小规模部署安装包，对硬件资源进一步降低，之前我有安装分布式单节点版，Oceanbase V4.2 (企业版) OBD单机安装（CentOS 7.9 Linux VBOX虚拟机），这次单机版邀测, 记录一下安装过程，总体比较感觉比较流畅，安装介质700M左右，一键安装包，几分钟完成。

Oracle DBA都知道Oracle的回收站功能可以做drop table后的flashback操作，目前部分国产数据库在回收站功能上做了truncate table的支持，像GaussDB (ustore), GoldenDB, Oceanbase同样也支持回收站的功能，今天看到一篇文档， 是有人问Oceanbase支持truncate吗？利用deepseek回答的，答案也对，也不对，只是不够严谨，很容易产生错误的后果。

GoldenDB作为分布式数据库，数据字典和元数据损坏属于严重故障，需谨慎处理。如果是主备架构，可能优先考虑切换主备，用备库恢复，这样可以减少停机时间。近期在做partition table的add 维护时，遇到了一个案例，版本 GoldenDB-ALL-DBCLUSTERV6.1.03.07SP5.r4895784， 报错信息如下

ERROR 3508 (HY000): Dictionary object id (xxx) does not exist.(Proxyid:1 Clusterid:1 Groupid:xx DBid:xx);part of DDL may succeed,please manual recovery!

尽量在同一个模式下创建和查询表,避免跨模式操作导致的数据类型问题,当表中使用了Oracle兼容的NUMBER数据类型时，强烈建议统一使用Oracle模式进行数据库连接和操作,在PG模式下查询包含NUMBER类型列的表时，会发生隐式类型转换,这种转换会导致查询优化器无法有效利用列上的索引，特别是影响范围扫描等高效查询方式,对于不需要Oracle特殊功能的场景，可考虑使用PostgreSQL原生数据类型如INT、BIGINT或NUMERIC

在MySQL中有些DDL操作可能会导致表重组,如<“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)>,如果表较大时，可能重组需要等待很久的时间，有没有什么方法可以跟踪一下DDL的进度呢？

在使用 PostgreSQL 数据库时,可能会看到过该错误消息，最近在highGoDB（postgresq）一个大的业务库做drop database时有遇到,也可能查询pgp_dump或查看表对象大小(如几千个分区)时，会提示提示错误” ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

Exporting BasicFile LOBs can be quite a pain. If your maintenance window is too short, here is a way to make the export faster.When Data Pump starts to export a table with a BasicFile LOB, only one worker will be assigned (due to the limited parallel access methods). If you have a large table, it will take a lot of time for that one worker to process the table.

最近一个客户的数据库出现了短暂1分钟左右的高负载，环境为oracle 11.2.0.4 2nodes RAC , 看当时的top event主要是buffer busy wait和log file sync, 关于buffer busy wait 在Troubleshooting Oracle wait event ‘buffer busy wait’ 有记录过分析方法，是一种hot block现象， 而log file sync又是提交类的，当两者同时发生时，可能是后者影响前者，首先建议排查I/O， 而另1个节点此时正在做RMAN增量备份，简单记录该问题.

最近股市的表现尤为显著，智能医疗、智能农业、自动驾驶汽车、智能一体机以及智能政务等领域股票轮番上涨，这无疑是对上述趋势的最佳注解。与此同时，信创数据库领域似乎已经被资本市场冷落，而与之相关的智能运维细分市场又显得过于狭小。不过，作为我的专业背景所在，我对这一领域依然充满热情。因此，本文将从数据库管理员（DBA）的角度出发，探讨DeepSeek与AI运维之间的联系及其潜在影响。

最近遇到一客户一套Oracle 19c(19.13) RAC 所有实例在提示ORA-00600 [krccfl_chunk] crash，并且无法启动，该问题发生前提是启用了Block Change Tracking，但并不是它的问题，而是前一天做了一个增加表空间的错误操作，如果有低于19.17的RAC数据库，并且启用了BCT时，注意这个未公开的bug，如果加文件人为失误. 可能会导致您所有的业务中断，这里简单记录。

最近一套oracle 19c的环境出现较高的cursor: mutex x等待，查询SQL ID有近4000+ version count, 从12c “_cursor_obsolete_threshold “参数值达8k，所以这么高的version也未过期，cursor: mutex x是因为version count高引起，哪什么引起high version count呢?MOS上有一篇比输全面的doc. 通过 v$sql_shared_cursor可以发现主要是USER_BIND_PEEK_MISMATCH和ROLL_INVALI

2025年初，DeepSeek 作为一家专注于大规模深度学习模型研发与部署的前沿企业，以其卓越的技术突破，推动了大模型智能应用在多个领域的蓬勃发展。其成功不仅证明了人工智能的强大潜力，众多大模型的崛起，也为AI与医疗的深度融合提供了更广阔的想象空间。如可以提高疾病诊断的精准度，加速药物研发，推动个性化治疗方案的发展等。此外，AI还能改善医疗管理效率，提升了医生的工作体验，同时增强了患者的就医体验。那AI医疗和数据库还有关吗？

按照过去十几年的惯例，每逢农历年末我都要整理回顾过去的一年， 岁月流转，多年的坚持犹如一场漫长的旅程，而在这趟旅途中，一个问题愈发强烈地萦绕在我的心头：我到底在执着于什么？这一切的付出与努力，是否真正值得？

oracle 的gateway透明网管支持像oracle dblink一样访问异构数据库如mysql, sql server等，在十四年前当时在维护oracle和sql server时，安装配置过还写了个整理了《安装透明网关 for sql server》，时间过的真快，没想到这次oracle的交接已经全面展开，在过渡阶段可能会存在一些异构数据库的访问，使用 Oracle ODBC 网关和异构服务技术从 Oracle 系统访问 MySQL 数据，本文介绍如何使用 ODBC Driver for MySQL 创建MySQL 和 Oracle 的数据库链接，并通过 SQL*Plus 工具查询 MySQL 数据。

这前总是通过 修改optimizer_feature_enable为不同版本，然后对比级联的参数变化，比较不同的数据库版本之间的参数差异，在Oracle 有个 ORAdiff app: https://oradiff.oracle.com/ 你也可以自己查询。