已知问题
本文提供有关基本数据库服务中已知问题的信息。
基本数据库服务中确定了以下已知问题：
- 新数据库中的现有可插入数据库
- 更改许可证类型时出现开票问题
- 由于证书更改，使用 dbcli 备份到对象存储失败
- 由于证书更改，使用 RMAN 备份到对象存储失败
- 断开数据库服务 SDK 的更改
- 无法在数据库系统中使用托管备份
- 由于进程崩溃，托管自动备份在 VM.Standard 1.1 配置上失败
- Oracle Data Pump 操作返回 "ORA-00439: feature not enabled"
- 无法从单节点数据库系统连接到 EM Express 控制台
- 使用 dbaascli 时，未同步启用了 Data Guard 的数据库的 OCI 控制台信息
- 脱机并联机磁盘后网格基础结构不会启动
- 数据库系统存储缩放失败
- 数据库系统配置缩放失败
新数据库中的现有可插入数据库
详细信息：
现有可插入数据库 (Pluggable Database，PDB) 不会显示在新创建的数据库中，并且可能需要几个小时才能显示在 OCI 控制台中。这包括新数据库的默认 PDB 以及克隆或还原数据库的现有 PDB。如果将就地还原到较旧版本，则 PDB 列表将以类似方式更新，并且可能会有一些延迟。
解决方法：
无。
更改许可证类型时出现开票问题
详细信息：
将数据库或数据库系统的许可类型从 BYOL 更改为包含的许可类型，或者更改其他方式时，系统将在一小时内对这两种类型的许可开票。之后，将根据更新的许可证类型向您开票。
解决方法：
我们正在制定一个解决方案。
由于证书更改，使用 dbcli 备份到对象存储失败
详细信息：
使用数据库 CLI (dbcli) 向对象存储执行非托管备份失败，并出现以下错误：
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error为了响应两个常见的 Web 浏览器实施的有关 Symantec 证书的策略，Oracle 最近更改了用于 Oracle Cloud Infrastructure 的证书颁发机构。如果 Oracle Database Cloud 备份模块仍然指向旧证书，则由此产生的 SSL 证书更改可能会导致备份到对象存储失败。
解决方法：
检查日志文件中列出的错误，如果找到，则更新备份模块。
-
有关上面列出的错误，请查看 RMAN 备份日志文件：
-
运行以下命令以确定失败的备份作业的 ID。
dbcli list-jobs在此示例输出中，失败的备份作业 ID 为 "f59d8470-6c37-49e4-a372-4788c984ea59"。
root@<node name> ~]# dbcli list-jobs ID Description Created Status ---------------------------------------- ------------------------------------------------------------------------------- ----------------------------------- ---------- cbe852de-c0f3-4807-85e8-7523647ec78c Authentication key update for DCS_ADMIN March 30, 2018 4:10:21 AM UTC Success db83fdc4-5245-4307-88a7-178f8a0efa48 Provisioning service creation March 30, 2018 4:12:01 AM UTC Success c1511a7a-3c2e-4e42-9520-f156b1b4cf0e SSH keys update March 30, 2018 4:48:24 AM UTC Success 22adf146-9779-4a2c-8682-7fd04d7520b2 SSH key delete March 30, 2018 4:50:02 AM UTC Success 6f2be750-9823-4ed5-b5ff-8e49f136dd22 create object store:bV0wqIaoLA4xLT4dGjOu March 30, 2018 5:33:38 AM UTC Success 0716f464-1a10-40df-a303-cadee0302b1b create backup config:bV0wqIaoLA4xLT4dGjOu_BC March 30, 2018 5:33:49 AM UTC Success e08b21c3-cd09-4e3a-944c-d1da96cb21d8 update database : hfdb1 March 30, 2018 5:34:04 AM UTC Success 1c3d7c58-79c3-4039-8f48-787057ce7c6e Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname> March 30, 2018 5:37:11 AM UTC Success f59d8470-6c37-49e4-a372-4788c984ea59 Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname> March 30, 2018 5:43:45 AM UTC Failure -
使用失败作业的 ID 获取要查看的日志文件的位置。
dbcli describe-job -i <failed_job_ID>describe-job命令的相关输出应如下所示：Message: DCS-10001:Internal error encountered: Failed to run Rman statement. Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.
-
-
更新 Oracle Database Cloud 备份模块：
-
确定 Swift 对象存储 ID 和数据库用于备份的用户。
- 运行
dbcli list-databases命令以确定数据库的 ID。 -
使用数据库 ID 确定备份配置 ID (
backupConfigId)。dbcli list-databases dbcli describe-database -i <database_ID> -j -
使用上一步中记录的备份配置 ID，确定对象存储 ID (
objectStoreId)。dbcli list-backupconfigs dbcli describe-backupconfig -i <backupconfig_ID> -j -
使用您在上一步中记下的对象存储 ID，确定对象存储用户 (
userName)。dbcli list-objectstoreswifts dbcli describe-objectstoreswift -i <objectstore_ID> -j
- 运行
-
使用从步骤 1 获取的对象存储身份证明更新备份模块。
dbcli update-objectstoreswift -i <objectstore_ID> -p -u <user_name>
-
由于证书更改，使用 RMAN 备份到对象存储失败
详细信息：
使用 RMAN 到对象存储的未托管备份失败，并出现以下错误：
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error为了响应两个常见的 Web 浏览器实施的有关 Symantec 证书的策略，Oracle 最近更改了用于 Oracle Cloud Infrastructure 的证书颁发机构。如果 Oracle Database Cloud 备份模块仍然指向旧证书，则由此产生的 SSL 证书更改可能会导致备份到对象存储失败。
解决方法：
请查看 RMAN 日志文件以了解列出的错误消息。如果找到，请以 oracle 用户身份登录到主机，并使用 Swift 凭证重新安装备份模块。
注意： Swift 密码现在称为“Auth 令牌”。有关更多信息，请参见 Managing User Credentials 。
java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts对于多节点数据库系统，请在集群中的所有节点上执行解决方法。
有关 Oracle Database Cloud Backup Module 的更多信息，请参见 Using Oracle Database Backup Cloud Service 。
断开数据库服务 SDK 的更改
详细信息：
2018 年 10 月 18 日发布的 SDK 引入了对数据库备份 API 中数据库大小和数据库版本属性的突破性更改。
解决方法：
有关中断更改的更多详细信息，请参阅特定于语言的文档，并根据需要更新现有代码。
无法在数据库系统中使用托管备份
详细信息：
使用 OCI 控制台或 API 时，备份和还原操作可能在您的数据库系统中不起作用。
解决方法：
安装 Oracle Database Cloud Backup Module，然后与 Oracle Support Services 联系以获取更多说明。
执行以下步骤安装 Oracle Database Cloud 备份模块：
-
通过 SSH 访问数据库系统，并以
opc身份登录。ssh -i <SSH_key> opc@<DB_system_IP address> login as: opc或者，可以使用
opc@<DB_system_hostname>登录。 - 从 Oracle Database Cloud 备份模块下载 Oracle Database Cloud 备份模块。
- 将
opc_installer.zip的内容提取到目标目录，例如/home/opc。 - 在您的租户中，创建一个临时用户，并向他们授予访问租户对象存储的权限。
-
对于此临时用户，创建验证令牌并记下密码。有关创建验证令牌的更多信息，请参见 Managing User Credentials 。
注意： Swift 密码现在称为“Auth 令牌”。
-
通过运行以下 curl 命令验证凭证是否有效：
curl -v -X HEAD -u <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>要确定正确的区域，请参阅对象存储常见问题解答。
该命令应返回
HTTP 200或HTTP 204 No Content成功状态响应代码。其他任何状态代码都表示连接到对象存储时出现问题。 -
运行以下命令：
java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt请注意，
<target_dir>是您在步骤 3 中提取了opc_installer.zip的目录。此命令可能需要几分钟才能完成，因为它会下载
libopc.so和其他文件。命令完成后，您应该会在目标目录中看到多个文件（包括libopc.so）。 -
将目录转到目标目录，并将
lipopc.so和opc_install.jar文件复制到/opt/oracle/oak/pkgrepos/oss/odbcs目录中。cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcscp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs（可能需要将
sudo与复制命令一起使用，才能将它们作为root运行。） -
运行以下命令检查指示的目录是否存在：
ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs如果此目录存在，请执行以下步骤：
- 备份
/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs目录中的文件。 -
运行以下两个命令以替换该目录中的现有
libopc.so和opc_install.jar文件：cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
- 备份
-
验证
opc_install.jar的版本。java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build如果存在
/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs，则还运行以下命令：java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build这两个命令都应返回以下输出：
Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16. - （可选）删除用于安装备份模块的临时用户和目标目录。
完成该过程后，请与 Oracle 技术支持或租户管理员联系以获得进一步说明。您必须提供要为其启用备份的数据库系统的 OCID。
由于进程崩溃，托管自动备份在 VM.Standard1.1 配置上失败
详细信息：
运行 VM.Standard1.1 配置的主机计算机的内存限制可能会导致由 Oracle Cloud Infrastructure 管理的自动数据库备份作业（使用 OCI 控制台或 API 管理的任务）失败。您可以更改系统的内存参数以解决此问题。
解决方法：
更改系统的内存参数，如下所示：
-
切换到操作系统中的 oracle 用户。
[opc@hostname ~]$ sudo su - oracle -
设置环境变量以登录到数据库实例。例如：
oracle@hostname ~]$ . oraenv ORACLE_SID = [oracle] ? orcl -
启动 SQL*Plus。
[oracle@hostname ~]$ sqlplus / as sysdba -
按如下方式更改初始内存参数：
SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile; SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M; SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M; SQL> exit -
重新启动数据库实例。
[oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open
Oracle Data Pump 操作返回 "ORA-00439: feature not enabled"
详细信息：
在高性能和极致性能数据库系统上，使用压缩和/或并行操作的数据泵实用程序操作可能会失败，并返回错误 ORA-00439：未启用功能。此问题影响数据库版本 12.1.0.2.161018 和 12.1.0.2.170117。
解决方法：
对数据库版本 12.1.0.2.161018 或 12.1.0.2.170117 的 Oracle Database 主目录应用补丁程序 25579568 或 25891266。或者，使用 OCI 控制台将 2017 年 4 月打补丁应用于数据库系统和数据库主目录。
注：要确定数据库主目录中的数据库版本，请以 oracle 用户身份运行 $ORACLE_HOME/OPatch/opatch lspatches，或以 root 用户身份运行 dbcli list-dbhomes。
无法从单节点数据库系统连接到 EM Express 控制台
详细信息：
尝试从单节点数据库系统连接到 EM Express 控制台时，可能会收到“Secure Connection Failed（安全连接失败）”错误消息，因为未自动应用正确的权限。
解决方法：
在数据库系统的 wallet 目录上为 asmadmin 组添加读取权限，然后重试连接。执行以下步骤以添加读取权限。
-
通过 SSH 到数据库系统主机，以
opc和sudo身份登录到grid用户。[opc@dbsysHost ~]$ sudo su - grid [grid@dbsysHost ~]$ . oraenv ORACLE_SID = [+ASM1] ? The Oracle base has been set to /u01/app/grid -
获取
wallet目录的位置。这是以下命令输出中my_wallet_directory的值。[grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW)) -
返回到
opc用户，切换到oracle用户，然后切换到wallet目录。[opc@dbsysHost ~]$ sudo su - oracle [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet -
列出目录内容并记下权限。
[oracle@dbsysHost xdb_wallet]$ ls -ltr total 8 -rw------- 1 oracle asmadmin 3881 Apr 6 16:32 ewallet.p12 -rw------- 1 oracle asmadmin 3926 Apr 6 16:32 cwallet.sso -
更改权限。
[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/* -
验证是否已添加读取权限。
[oracle@dbsysHost xdb_wallet]$ ls -ltr total 8 -rw-r----- 1 oracle asmadmin 3881 Apr 6 16:32 ewallet.p12 -rw-r----- 1 oracle asmadmin 3926 Apr 6 16:32 cwallet.sso
使用 dbaascli 时，未同步启用了 Data Guard 的数据库的 OCI 控制台信息
详细信息：
OCI 控制台同步并显示有关使用 dbaasapi 和 dbaascli 实用程序创建和管理的数据库的信息。但是，在以下情况下，配置了 Data Guard 的数据库在 OCI 控制台中不会显示正确的信息：
- 如果使用 OCI 控制台启用了 Data Guard，然后使用
dbaascli对主数据库或备用数据库进行了更改（例如将数据库移动到其他主目录），则结果不会反映在 OCI 控制台中。 - 如果手动配置了 Data Guard，则 OCI 控制台不会显示两个数据库之间的 Data Guard 关联。
解决方法：
我们已意识到此问题并正在努力解决。同时，Oracle 建议您仅使用 OCI 控制台或命令行实用程序来管理启用了 Data Guard 的数据库。
脱机并联机磁盘后网格基础结构不会启动
详细信息：
这是一个集群件问题，仅当 Oracle Grid Infrastructure (GI) 版本为 12.2.0.1 且没有任何捆绑包补丁程序时才会发生。此问题是由以下原因导致的：在您脱机后，将表决磁盘变为联机。
解决方法：
确定 GI 的版本，以及投票磁盘是否已损坏。修复磁盘（如果适用），然后应用最新的 GI 包。
此时，请执行以下步骤：
-
验证 GI 版本是否为 12.2.0.1 且未应用任何捆绑包补丁程序：
[root@rmstest-udaau1 ~]# su - grid [grid@rmstest-udaau1 ~]$ . oraenv ORACLE_SID = [+ASM1] ? +ASM1 The Oracle base has been set to /u01/app/grid [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory Oracle Interim Patch Installer version 12.2.0.1.6 Copyright (c) 2018, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/12.2.0.1/grid Central Inventory : /u01/app/oraInventory from : /u01/app/12.2.0.1/grid/oraInst.loc OPatch version : 12.2.0.1.6 OUI version : 12.2.0.1.4 Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt -------------------------------------------------------------------------------- Local Machine Information:: Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com ARU platform id: 226 ARU platform description:: Linux x86-64 Installed Top-level Products (1): Oracle Grid Infrastructure 12c 12.2.0.1.0 There are 1 products installed in this Oracle Home. There are no Interim patches installed in this Oracle Home. -------------------------------------------------------------------------------- OPatch succeeded. -
检查
/u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc文件中是否有证据表明 GI 因投票磁盘损坏而无法启动：ocssd.trc 2017-01-17 23:45:11.955 : CSSD:3807860480: clssnmvDiskCheck:: configured Sites = 1, Incative sites = 1, Mininum Sites required = 1 2017-01-17 23:45:11.955 : CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: Aborting, 2 of 5 configured voting disks available, need 3 ...... . 2017-01-17 23:45:11.956 : CSSD:3807860480: clssnmCheckForNetworkFailure: skipping 31 defined 0 2017-01-17 23:45:11.956 : CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, slcc05db08 terminated. Removing from its own member and connected bitmaps 2017-01-17 23:45:11.956 : CSSD:3807860480: ################################### 2017-01-17 23:45:11.956 : CSSD:3807860480: clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread 2017-01-17 23:45:11.956 : CSSD:3807860480: ################################### 2017-01-17 23:45:11.956 : CSSD:3807860480: (:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally ------------ 2017-01-19 19:00:32.689 : CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 cbd]), found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c bd]), is not corrupted 2017-01-19 19:01:06.467 : CSSD:3452057344: clssnmvVoteDiskValidation: Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted -
还可以使用 SQL*Plus 确认投票磁盘已损坏：
-
以网格用户身份登录，并将环境设置为 ASM。
[root@rmstest-udaau1 ~]# su - grid [grid@rmstest-udaau1 ~]$ . oraenv ORACLE_SID = [+ASM1] ? +ASM1 The Oracle base has been set to /u01/app/grid -
以
SYSASM身份登录到 SQL*Plus。$ORACLE_HOME/bin/sqlplus / as sysasm -
运行以下两个查询：
SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0; SQL> select CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;如果系统正常运行，则结果应类似于以下示例。
Query 1 Results NAME VOTING_FILE ------------------------------ --------------- DBFSC3_CD_02_SLCLCX0788 Y DBFSC3_CD_09_SLCLCX0787 Y DBFSC3_CD_04_SLCLCX0786 Y Query 2 Results NAME COUNT(*) ------------------------------ --------------- DBFSC3_CD_02_SLCLCX0788 8 DBFSC3_CD_09_SLCLCX0787 8 DBFSC3_CD_04_SLCLCX0786 8在健康系统中，第一个查询中返回的每个表决磁盘也应在第二个查询中返回，并且所有磁盘的计数应为非零。否则，您的一个或多个投票磁盘会损坏。
-
-
如果投票磁盘已损坏，请使包含投票磁盘的网格磁盘脱机。单元将自动将坏投票磁盘移动到其他网格磁盘，并将该投票磁盘联机。
-
以下命令使名为 DATAC01_CD_05_SCAQAE08CELADM13 的网格磁盘脱机。
SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13; Diskgroup altered. - 等待 30 秒，然后重新运行步骤 3c 中的两个查询，以验证投票磁盘是否已迁移到新网格磁盘并且是否正常运行。
-
验证脱机网格磁盘现在处于联机状态：
SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';mode_status 应为 ONLINE，而且 voting_file 不能为 Y。
对包含腐败投票磁盘的每个剩余网格磁盘重复步骤 4a 到 4c。
注意：
如果 CRS 因表决磁盘损坏而未启动，请在执行步骤 4 中的命令之前使用独占模式启动它。
crsctl start crs -excl -
-
如果您使用的是不带任何捆绑包补丁程序的 Oracle GI 版本 12.2.0.1，则必须将 GI 版本升级到最新的 GI 捆绑包，无论投票磁盘是否已损坏。
数据库系统存储缩放失败
详细信息：
尝试在单个操作中从小于 10,240 GB 的值缩放到大于 10,240 GB 的值可能会导致缩放操作失败。
解决方法：
如果您要将常规数据存储或恢复区 (RECO) 存储从小于 10,240 GB (10 TB) 的值扩展到超过 10,240 GB 的值，请执行两次扩展操作。首先，将系统扩展到 10,240 GB。在第一个缩放操作完成且系统处于“可用”状态之后，执行第二个缩放操作，指定目标存储值大于 10,240 GB。
数据库系统配置缩放失败
详细信息：
将数据库系统缩放为使用较大的系统配置时，如果 DB_Cache_nX 参数未设置为 0（零），缩放操作将失败。
解决方法：
扩展数据库系统时，请确保所有 DB_Cache_nX 参数（例如 DB_nK_CACHE_SIZE）都设置为 0（零）。