已知问题

新数据库中的现有可插入数据库

详细资料

现有可插入数据库 (Pluggable Database,PDB) 不会显示在新创建的数据库中,并且可能需要长达几个小时才能显示在 OCI 控制台中。这包括新数据库的默认 PDB 以及克隆或还原数据库的现有 PDB。如果将就地还原到较旧版本,则 PDB 列表将以类似方式更新,并且可能会有一些延迟。

解决方法

无。

现有 Data Guard 配置中的 PDB

详细资料

不允许通过 OCI 控制台或 API 在主数据库中创建和克隆 PDB。

解决方法

您可以使用 SQL*Plus 在主数据库中创建或克隆 PDB,稍后将在 OCI 控制台中同步这些 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 证书更改可能会导致备份到对象存储失败。

解决方法

检查日志文件中列出的错误,如果找到,则更新备份模块。

  1. 有关上面列出的错误,请查看 RMAN 备份日志文件:

    1. 运行以下命令以确定失败的备份作业的 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
    2. 使用失败作业的 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.
  2. 更新 Oracle Database Cloud 备份模块:

    1. 确定 Swift 对象存储 ID 和数据库用于备份的用户。

      1. 运行 dbcli list-databases 命令以确定数据库的 ID。

      2. 使用数据库 ID 确定备份配置 ID (backupConfigId)。

        dbcli list-databases
        dbcli describe-database -i <database_ID> -j
      3. 使用上一步中记录的备份配置 ID,确定对象存储 ID (objectStoreId)。

        dbcli list-backupconfigs
        dbcli describe-backupconfig –i <backupconfig_ID> -j
      4. 使用您在上一步中记下的对象存储 ID,确定对象存储用户 (userName)。

        dbcli list-objectstoreswifts
        dbcli describe-objectstoreswift –i <objectstore_ID> -j
    2. 使用从步骤 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 备份模块:

  1. 通过 SSH 访问数据库系统,并以 opc 身份登录。

    ssh -i <SSH_key> opc@<DB_system_IP address>
    login as: opc

    或者,可以使用 opc@<DB_system_hostname> 登录。

  2. Oracle Database Cloud 备份模块下载 Oracle Database Cloud 备份模块。
  3. opc_installer.zip 的内容提取到目标目录,例如 /home/opc
  4. 在您的租户中,创建一个临时用户,并向他们授予访问租户对象存储的权限。
  5. 对于此临时用户,创建验证令牌并记下密码。有关创建验证令牌的更多信息,请参见 Managing User Credentials

    注意:

    Swift 密码现在被称为“Auth 令牌”。
  6. 通过运行以下 curl 命令验证凭证是否有效:

    curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

    要确定正确的区域,请参阅对象存储常见问题解答

    该命令应返回 HTTP 200HTTP 204 No Content 成功状态响应代码。其他任何状态代码都表示连接到对象存储时出现问题。

  7. 运行以下命令:

    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)。

  8. 将目录转到目标目录,并将 lipopc.soopc_install.jar 文件复制到 /opt/oracle/oak/pkgrepos/oss/odbcs 目录中。

    cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs
    cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

    (可能需要将 sudo 与复制命令一起使用,才能将它们作为 root 运行。)

  9. 运行以下命令检查指示的目录是否存在:

    ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

    如果此目录存在,请执行以下步骤:

    1. 备份 /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 目录中的文件。
    2. 运行以下两个命令以替换该目录中的现有 libopc.soopc_install.jar 文件:

      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
  10. 验证 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.
  11. (可选)删除用于安装备份模块的临时用户和目标目录。

完成该过程后,请与 Oracle 技术支持或租户管理员联系以获得进一步说明。您必须提供要为其启用备份的数据库系统的 OCID。

由于进程崩溃,托管自动备份在 VM.Standard1.1 配置上失败

详细资料

运行 VM.Standard1.1 配置的主机计算机的内存限制可能会导致由 Oracle Cloud Infrastructure 管理的自动数据库备份作业(使用 OCI 控制台或 API 管理的任务)失败。您可以更改系统的内存参数以解决此问题。

解决方法

更改系统的内存参数,如下所示:

  1. 切换到操作系统中的 oracle 用户。

    [opc@hostname ~]$ sudo su - oracle
  2. 设置环境变量以登录到数据库实例。例如:

    oracle@hostname ~]$ . oraenv 
    ORACLE_SID = [oracle] ? orcl
  3. 启动 SQL*Plus。

    [oracle@hostname ~]$ sqlplus / as sysdba
  4. 按如下方式更改初始内存参数:

    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
  5. 重新启动数据库实例。

    [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 组添加读取权限,然后重试连接。执行以下步骤以添加读取权限。

  1. 通过 SSH 到数据库系统主机,以 opcsudo 的身份登录到 grid 用户。

    [opc@dbsysHost ~]$ sudo su - grid
    [grid@dbsysHost ~]$ . oraenv
    ORACLE_SID = [+ASM1] ?
    The Oracle base has been set to /u01/app/grid
  2. 获取 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))
  3. 返回到 opc 用户,切换到 oracle 用户,然后切换到 wallet 目录。

    [opc@dbsysHost ~]$ sudo su - oracle
    [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet
  4. 列出目录内容并记下权限。

    [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
  5. 更改权限。

    [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*
  6. 验证是否已添加读取权限。

    [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 控制台同步并显示有关使用 dbaasapidbaascli 实用程序创建和管理的数据库的信息。但是,配置了 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 包。

此时,请执行以下步骤:

  1. 验证 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.
  2. 检查 /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
  3. 还可以使用 SQL*Plus 确认投票磁盘已损坏:

    1. 以网格用户身份登录,并将环境设置为 ASM。

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid
    2. SYSASM 身份登录到 SQL*Plus。

      $ORACLE_HOME/bin/sqlplus / as sysasm
    3. 运行以下两个查询:

      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

      在健康系统中,第一个查询中返回的每个表决磁盘也应在第二个查询中返回,并且所有磁盘的计数应为非零。否则,您的一个或多个投票磁盘会损坏。

  4. 如果投票磁盘已损坏,请使包含投票磁盘的网格磁盘脱机。单元将自动将错误的投票磁盘移动到其他网格磁盘,并将该投票磁盘联机。

    1. 以下命令使名为 DATAC01_CD_05_SCAQAE08CELADM13 的网格磁盘脱机。

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.
    2. 等待 30 秒,然后重新运行步骤 3c 中的两个查询,以验证投票磁盘是否已迁移到新网格磁盘并且是否正常运行。

    3. 验证脱机网格磁盘现在处于联机状态:

      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
  5. 如果您使用的是不带任何捆绑包补丁程序的 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(零)。