ORA-17514 错误表明 Oracle 数据库备份或恢复操作中没有正常访问 clonedb bitmap 文件。修复步骤包括：切换到 Oracle 安装用户，进入$ORACLE_HOME/clone/bin 目录；查看 bitmap 文件位置，检查文件名是否正确及文件是否存在；若文件丢失或损坏，需重新安装 Oracle 数据库软件；若文件存在，检查权限及安装位置是否正确；最后在安全情况下重新执行备份操作。远程处理需确保网络畅通及权限配置正确，必要时检查 trace file 中的额外错误信息并联系 Oracle 支持服务。

ORA-17514: Access to clonedb bitmap file failed ORACLE 报错 故障修复 远程处理

ORA-17514: Access to clonedb bitmap file failed ORACLE 报错 故障修复 远程处理 文档解释 ORA-17514:Access to clonedb bitmap file failed Cause:Accessing the bitmap block file in clonedb environment has encountered an error Action:check additional error messages in the trace file and call Oracle Support Services ORA-17514 :Access to clonedb bitmap file failed 该错误表明 Oracle 数据库备份或恢复操作中没有正常访问 clonedb bitmap 文件。clonedb bitmap 文件是通常用于数据库完全恢复的文件。因此，当无法访问这个文件时，可能会出现的问题是用户无法正常完成或使用数据库恢复操作。该错误基本原因可能有很多。但是，常见的原因主要是包括以下几个：1. 不能够正常访问 clonedb bitmap 文件，这可能是因为安装位置或权限设置问题。2. 系统上 clonedb bitmap 文件丢失或损坏。3. 安装了旧版本的 Oracle 数据库软件，而恢复过程中仍然使用了新版本的 clonedb bitmap 文件。一般处理方法及步骤 1. 首先，切换到 Oracle Database 的安装用户，然后进入$ORACLE_HOME/clone/bin 目录。2. 查看 clonedb bitmap 文件的位置，并检查是否文件名称正确，确保文件存在且可以正常访问。3. 如果 clonedb bitmap 文件不存在或损坏，重新安装 Oracle Database Software，以便正常访问 clonedb bitmap 文件。4. 如果文件存在，检查文件的权限及安装位置，确保这两个地方正确又符合设置，确保我们可以正常访问 Bitmap 文件。5. 最后，在安全的情况下重新执行备份操作，使完整的备份可以正常执行。（该信息的时间戳是 2025 年 5 月 24 日）

Oracle 12c 远程克隆 PDB 的问题及修复 (r12 笔记第 78 天)

Oracle 12c 里面的 PDB 迁移还是有很多花样的，玩法很多，如果想达到一种平滑方式的迁移，克隆远程 PDB 也是一种方法，保证网络畅通，即可远程克隆 PDB 到指定的目标容器数据库中，当然这种方式还是推荐数据量不大的 PDB。要实现远程克隆，主要就是创建 DB link，然后使用 create pluggable database 语句指定 db link 复制的路径即可。当然这个过程中还是可能出现一大堆的问题。我就抛砖引玉，提一个比较有代表性的。首先在目标端容器数据库创建 DB link，指向源端的 PDB create public database link tcymob1_new12c connect to pdb_mgr identified by oracle using 'tcymob1'; 接着在目标端容器数据库远程克隆 PDB CREATE PLUGGABLE DATABASE pdb4 FROM test_pdb ? FILE_NAME_CONVERT = file_name_convert=('/U01/app/oracle/oradata/dbcadb','/U01/app/oracle/oradata/dbcadb/pdb4'); 当然很不幸，抛出了下面的错误，这个错误如果在 12.2 中测试很可能不会碰到，但是在 12.1 和 12.2 之间切换，那还是很可能有的，因为其中的一个重要原因就是 undo 了。ORA-17628: Oracle error 65035 returned by remote Oracle serverORA-65035: unable to create pluggable database from 我们看看错误分析：$ oerr ora 6503565035, 00000, "unable to create pluggable database from %s"// *Cause: An attempt was made to clone a pluggable database that did not have// local undo enabled.// *Action: Enable local undo for the PDB and and retry the operation. 为了进一步验证，我们到源端，查看源容器数据库的信息 SQL> show pdbs;CON_ID CON_NAME OPEN MODE RESTRICTED---------- ------------------------------ ---------- ----------2 PDB$SEED READ ONLY NO3 PDB2_PROXY MOUNTED5 TCYMOB0 READ WRITE NO6 TCYMOB1 READ WRITE NO 查看 database_properties，或者查看 dba_data_files 都可以，源库中的 undo 是共享模式的，接下来的问题就会变为如果把 share undo 改为 local undo 修复 share undo 为 local undo 核心的命令就是 alter database undo local，但是要实现这样一个目标还是需要花些功夫。我们先启动源数据库到 upgrade 模式。SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup upgrade 然后在 root 容器下执行 undo 的切换命令。SQL> show con_nameCON_NAME------------------------------CDB$ROOTSQL> alter database local undo on;Dat

两个数据访问受限的问题

最近几天实在忙得厉害，处理了各种数据需求，有种顾及不来，而其中有一部分问题是和数据访问相关的，问题的原因很简单，但是分析问题的过程就需要很多的经验，推导，比如下面的两个案例。第一个是开发同学反馈，连接数据库的时候报出了下面的错误。第一个错误是：ORA-12154: TNS:could not resolve the connect identifier specified 第二个错误是：ORA-12170: TNS:Connect timeout occurred 连接 10.129.xx..51 如果直接看这个错误，可能没有思路，第一个错误明显是网络配置的问题，但是我查看了网络的配置，本机的网络服务都是正常的，另外需要说明一下，这是一套迁移的环境。第二个问题看起来是网络超时，可能是网络情况不好，或者访问网络的权限限制。同时我查看了防火墙的配置，该有的 IP 信息都有了。到底是哪里出了问题呢，和开发的同学聊，他的回答让我有些诧异，访问数据的时候就报这个 这个连接串没问题 查询请求可以执行 但是 insert 的时候就报错了 看到这里，我脑海里就有了大概的思路了，这很可能是 DB link 的问题，而上面的两个错误很可能就是访问的两个 DB link，是访问失败的两个问题，一个是目标环境的监听服务有问题，另外一个是防火墙的权限问题。明白了问题修复起来分分钟就能搞定，但是分析排查还是花了些时间。第二个是一个数据访问报错，业务同学反馈，一台搬迁的服务器修改了 IP 之后，他们连接应用的时候抛出了下面的错误，[show] java.sql.SQLException: ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Linux-x86_64 Error: 2: No such file or directory 看到这个错误，很明显是数据库实例出了问题，要么就是连接的数据库信息有误。和业务同学反馈确认，他们的反馈是 IP 信息没有问题，我这边的权限信息也没有问题，经过了多方排查，还是没有进展，这时候我们就换一个角度来看，因为涉及到的系统是一个整体，可能包含很多子系统，所以不能完全依赖于已得到的信息，但是他们稍后反馈另一个业务出现了问题，带着疑问查看了他们的数据服务，发现这台数据库已经宕机了，错误日志如下：PMON (ospid: 4354): terminating the instance due to error 471 System state dump requested by (instance=1, osid=4354 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /U01/app/oracle/diag/rdbms/csdb/csdb/trace/csdb_diag_4364.trc Instance terminated by PMON, pid = 4354 可以看到是 pmon 终止了实例，而 0

将 Oracle Database 迁移到 OCI 的常见问题解答

Oracle 致力于提供一种简单、自动化、无中断的升级和迁移方法，帮助用户将每一个版本的 Oracle Database 迁移到最新版本的数据库和数据库平台。从传统的脱机备份和还原到更复杂的联机、零停机操作，Oracle 迁移方法可满足一系列广泛的操作需求。概要了解如何从本地迁移到云端 如何获取 Oracle Database 迁移信息？点击以下第一个链接，您可以简要了解 Oracle Database 迁移步骤和规划顾问，查看 Oracle 的预构建迁移工作流图示及其采用的技术。对于每一种迁移方法，您都可以查看概述信息、参考架构、分步式技术指南、Oracle LiveLab 演练及相关文档。迁移和升级有何区别？数据库升级 (如从 Oracle 19c 升级到 Oracle 23ai) 是指升级数据库软件系统和相关的客户元数据，整个过程中客户数据“原地”不动。数据库迁移则意味着将数据移动到一个新平台，例如从本地部署服务器移动到基于 OCI 或 Cloud@Customer 运行的 Oracle Database Cloud Service。通常来说，当跨操作系统从旧版本迁移到新版本以及进行字符集迁移时，您需要执行一定的数据库升级工作。不过，这种升级在顺序上比较灵活，可以在迁移前、迁移中或迁移后执行。请从业务和技术两个方面来判断何时升级 — 请参阅 Oracle Database 升级指南 (PDF) 和 Cloud Premigration Advisor Tool。业务连续性是选择逻辑还是物理迁移方法的关键驱动因素。联机方法允许应用在迁移期间保持运行状态。在初始加载数据后实时捕获新产生的数据，然后增量式地将新产生的数据应用到目标数据库。随后，Oracle 将在一个适当的时间点执行最终切换，使目标数据库替代源数据库。在脱机方法中，应用并不运行，一次性完成数据库迁移。在数据移动方面，Oracle 迁移方法可兼顾备份/恢复的速度和灵活性。物理方法基于极少到零停机容错恢复功能，使用 Recovery Manager 和 Oracle Data Guard。虽然这是最快的方法，但还需要源数据库和目标数据库具有相同的特征，例如版本或字符集。逻辑方法基于更灵活的导出和导入功能，在数据从源移动到目标时允许进行数据库配置和存在版本差异。

FAQ

ORA-17514 错误的主要原因是什么？

常见的原因主要是包括以下几个：1. 不能够正常访问 clonedb bitmap 文件，这可能是因为安装位置或权限设置问题。2. 系统上 clonedb bitmap 文件丢失或损坏。3. 安装了旧版本的 Oracle 数据库软件，而恢复过程中仍然使用了新版本的 clonedb bitmap 文件。

远程克隆数据库时如何避免 ORA-65035 错误？

需要 Enable local undo for the PDB and and retry the operation。核心的命令就是 alter database undo local，但是要实现这样一个目标还是需要花些功夫。我们先启动源数据库到 upgrade 模式。SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup upgrade 然后在 root 容器下执行 undo 的切换命令。

遇到数据库连接超时或无法解析标识符怎么办？

第一个错误明显是网络配置的问题，但是我查看了网络的配置，本机的网络服务都是正常的，另外需要说明一下，这是一套迁移的环境。第二个问题看起来是网络超时，可能是网络情况不好，或者访问网络的权限限制。同时我查看了防火墙的配置，该有的 IP 信息都有了。这很可能是 DB link 的问题，而上面的两个错误很可能就是访问的两个 DB link，是访问失败的两个问题，一个是目标环境的监听服务有问题，另外一个是防火墙的权限问题。