太长不看，简单一句话，Oracle Cloud上的 Autonomous 19c 升级到 Oracle Autonomous AI Database 26ai ，web页面点击两个下一步，等着完成即可，我的数据库容量大小是45G，升级用时 7分钟。以下是升级的流水账：

最近几天 ORACLE 发布了或者改名了所谓的数据库版本叫 Oracle AI Database 26ai ，同样 云上的 Oracle Autonomous 也改名为了：Oracle Autonomous AI Database 26ai ，不知道从什么时候开始官方文档上出现了：Oracle Autonomous AI Database Serverless （

  • You will see changes on the Autonomous AI Database cloud console that reflect the recent announcements at Oracle AI World. Click here to read about the announcement in the documentation. 这个连接就到了：What’s New for Oracle Autonomous AI Database Serverless ，也就是 Oracle Autonomous AI Database Serverless ），也就是多了个 Serverless。

看了介绍，本地下载版本的26ai都是阉割（可以看到版本上写的：Develop, Learn, and Run for Free），只有云上的在控制台上写的是 26ai，但是我看过介绍写的这样的：The REST API returns 23ai, but you will see 26ai in the Oracle Cloud Infrastructure (OCI) console.

我的云上之前创建了两个实例，一个是23c，一个是19c，现在可以看到 23c的Autonomous database 已经自动升级到 26ai了。截图如下：

image-20251021110708969

现在看下 19c的 库：在版本右侧有个 安排升级到 26ai

image-20251021110843356

那我就安排呗。点击 安排升级到 26ai，之后弹出如下页面：

要升级此数据库，您可以选择最早可用计划或将来计划。为开级选择最早可用计划不会产生额外费用。将升级安排在将来日期将预留额外的升级资源，因此将产生额外费用，直到升级完成为止。请注意，可用的升级窗口基于数据库大小、连接的备用数据库和可刷新克。如果在调度程序中某个日期处于禁用状态，这是因为该日期不在可用的升级窗口内。如果您重新安排或取消安排的升级，则原始升级窗口可能变为不可用。
⚠️警告
升级期间，数据库将经历几分钟的停机。附加的可刷新克隆和备用数据库也将与源数据库一起升级。安排升级时，您将无法创建新的可刷新克隆或灾难恢复备用数据库。

image-20251021111135670

也就是数据库会经历几分钟的停机，安排走起，UTC 的 10/20日的 14：30分，也就是北京时间的2025年10月10日 22:30，我太懒了，没有盯着他看升级过程，写了个脚本记录数据库的启动时间。

1
2
3
4
5
6
7
8
INSERT INTO ver (TIM, START_TIME, VERSION)
SELECT sysdate,
    i.STARTUP_TIME,
    v.BANNER_FULL
FROM
    v\$instance i,
    v\$version v
commit;

每分钟执行一次。

第二天早上，登录之后就看到了这个：此数据库及其关联的资源已成功升级到数据库版本 26ai。了解有关 26ai 及其新功能的更多信息。了解更多信息

image-20251021112135335

吼吼，也就是升级完成了。

但是呢我没找到升级日志，还好我写了个简单的记录数据库的启动时间，可以看到，14:30分的时候可以正常连接数据库，版本19c，14；37的时候也可以连接库，版本变成了23.10，可能就是所谓的 26ai。

但是呢，我发现了一个奇怪的问题：就是启动时间竟然是：2025-10-11 16:10:53，但是我这个数据库是安排的 2025年10/20的14:30进行升级的，启动时间怎么是一个多星期之前呢，我的第一个想法是ORACLE 难道是用的逻辑迁移升级的？把我的数据库从一个迁移到一个一个星期之前启动的高版本的数据库上了？但是我上面的监控脚本只记录了 v$instance 的启动时间和v$version 的版本信息，也记录其他的信息也，也不好判断，我想如果是逻辑迁移，这也太low了吧。

image-20251021112403815

我又继续寻找其他证据，证明这不是逻辑迁移升级的，还好之前有记录过数据库的datafile的名称，我这里查看了下 datafile的名称是完全相同的。

1
2
3
4
5
6
7
8
9
10
11
SQL> /

NAME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/system.3225.1215005339
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/sysaux.3255.1215005339
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/data.2798.1215005339
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/dbfs_data.3062.1215005339
+DATA/sampleschema_dbf
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/undo_f3117.3061.1215005339
+DATA/FCEYFTL6/051497325D7D6C5AE0631814000A56C9/DATAFILE/undo_b1498.3049.1215005339

image-20251021113455712

也就是在10月17日的时候记录的 datifle的name跟现在升级之后的datafile 的name是完全一样的，通常情况下，逻辑迁移新建数据库才有的 omf 方式，oracle自动命名的方式，不可能出现重名的情况。那我可以确定是不是逻辑迁移升级，是本地自动升级的。但是为什么，记录的启动时间是 一个多星期之前呢，我有捉摸了半天，我的脚步里是查询的v$instance 的start_time 时间，而我这个 database，实际上就是 oracle 给了我一个pdb而已，不能查询v$instacne，应该查询pdb的启动时间。欧耶。

1
2
3
4
5
6
7
SQL> SELECT NAME, OPEN_MODE, OPEN_TIME FROM V$PDBS;

NAME			       OPEN_MODE	    OPEN_TIME
------------------------------ -------------------- ---------------------------------------------------------------------------
AAD4UBQYWGUYKLY_LIUPS	       READ WRITE	    20-OCT-25 02.36.41.685 PM +00:00

SQL>

可以看到pdb的启动时间为：20-OCT-25 02.36.41.685 PM +00:00，这才对嘛，我看我的监控脚本：

内容如下：数据库是从 37分的时候开始连上的。

image-20251021114100576

这样就匹配上了，监控脚本检测14:30的时候是可以正常连上的，从31到36之间都开始抱错了，报ora-12514 。到14:37的时候连接正常。

ok，19c升级到所谓的 26ai，完成。总结一句话，越来越简单了。这就是所谓的自治了吧。在AI 盛行的今天，数据库也越来越智能了。以后数据库的维护变得越来越简单了。个人觉得最终变成了运营是最重要的了。

原文作者: liups.com

原文链接: http://liups.com/posts/e7bd21bf/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议