11GR2 中的常见 RMAN 问题

本文是Oracle support对11GR2 RMAN备份过程中的问题总结

11GR2 中的常见 RMAN 问题

11gR2 中少数几个结构更改对 RMAN 设置产生了广泛的影响

1. Snapshot/Backup（快照/备份）控制文件位置必须位于 RAC 环境中的共享位置。

在 11gR2 及更高版本中，控制文件的备份在执行时不会持有 CF enqueue。对于非 RAC 数据库，这不会造成任何影响。但是，对于 RAC数据库，由于在 11gR2 中控制文件备份机制发生了更改，集群中的任何实例都可以写入到 snapshot/backup（快照/备份）控制文件。因此，Snapshot（快照）控制文件需要对所有实例都可见。从 SQL*Plus 直接创建控制文件的备份时也存在这种情况。集群中的任何实例都可以写入到备份控制文件。控制文件备份，即使使用 SQL“alter database backup controlfile...”，也必须在共享设备上创建备份。

Snapshot（快照）控制文件必须可由 RAC 数据库的所有节点访问；如果 snapshot（快照）控制文件不在共享设备上，则在 RMAN备份获取控制文件的 snapshot（快照）时会引发错误。这适用于使用 SQL*Plus 备份控制文件和在非共享位置配置了控制文件自动备份的情况。

RMAN-00571: ========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: =========================================================
RMAN-03009: failure of resync command on default channel at 03/13/2012 10:19:41
ORA-00245: control file backup operation failed

解决方案是将 Snapshot/backup（快照/备份）控制文件位置更改到共享设备上，否则将会失败，并出现 ORA-245: control file backup operation failed。

提醒：Note 1472171.1 In RAC environment from 11.2 onwards Backup Or Snapshot controlfile needs to be in shared location 是针对此问题而发布的。

2. MMON 进程在结构发生变化之后自动进行控制文件备份

在 11GR2 之前的发行版中，更改数据库结构的每个 DDL 命令都会创建一个控制文件自动备份。在 alert.log 中可以看到，执行每个 DDL 命令之后都会有一条关于控制文件自动备份创建的消息。在同时进行多个结构更改时，这可能会导致严重的性能问题。

从 Oracle Database 11g 发行版 2 开始实施了 Controlfile Autobackup Deferral 功能。在应用的脚本中包含多个结构更改时（例如，添加表空间、变更表空间或数据文件的状态、添加新的联机重做日志、重命名文件等），RMAN 只进行一次控制文件自动备份。在 11gR2 中，控制文件自动备份由 MMON 从属进程在结构更改后的几分钟时间内创建，这可以提升性能。因此，在对数据库的结构更改数分钟之后获取控制文件自动备份是正常行为，同时在 alert.log 中不显示有关控制文件自动备份创建的消息也是正常的。

负责备份控制文件的 MMON 从属进程会产生包含了创建控制文件所需信息的跟踪文件并命名为：<SID>_m000_<OS_PID>.trc

3. 可以在磁盘上执行恢复区备份

在 11gR2 之前，只能在磁带上执行 Flash Recovery Area（快速恢复区，简称 FRA）的备份。从 11GR2 开始，可以在磁盘上执行 FRA备份。BACKUP 命令中添加了“TO DESTINATION”子句。这个添加的选项可指定特定目录位置，以便备份到磁盘，该选项主要用于 BACKUP RECOVERY AREA 命令。如果启用了 BACKUP OPTIMIZATION，则 RMAN 仅跳过已存在于“TO DESTINATION”子句所指定目录位置中相同文件的备份。

RMAN> Backup recovery area TO DESTINATION ‘+DATA’;

11GR2 中影响 RMAN 稳定性的常见 BUG。

1. BUG 9877980: SR11.2.0.2CSHAR_FORCE - TRC - KKSLMARKLITERALBINDS

症状：

数据库版本：11.2.0.2，CURSOR_SHARING 为 FORCE 或 SIMILAR

RMAN 备份失败，出现 ORA-01008，或者显示各种错误

DBGSQL: TARGET> select count(*) into :dbstate from v$parameter where lower(name) = '_dummy_instance' and upper(value) = 'TRUE'
DBGSQL: sqlcode = 1008
RMAN-00571: =========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ==============
RMAN-00571: =========================================================
ORA-01008: not all variables bound

或者

RMAN-00571: =====================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ============
RMAN-00571: =====================================================
RMAN-03002: failure of allocate command at 12/07/2011 00:38:14
ORA-03114: not connected to ORACLE

并且 alert.log 中显示

ORA-07445: exception encountered: core dump [kkslMarkLiteralBinds()+240] [SIGBUS] [ADDR:0x18222D0202020D29] [PC:0x1049E96D0] [Invalid address alignment] []
或者
ORA-07445: exception encountered: core dump [kkslpli()+212] [SIGSEGV] [ADDR:0xFFFFFFFF7A973288] [PC:0x1049FEE14] [Invalid permissions for mapped object] []

根本原因是 BUG 9877980。此 Bug 的修复包括在 11.2.0.3 中。此 Bug 有one-off patch可用。

Workaround: 清空共享池

Ref:

Bug 9877980 - ORA-7445[kkslMarkLiteralBinds] / Assorted Errors on 11.2.0.2 if cursor sharing is enabled Note 9877980.8

Alert: Note 1472116.1 RMAN backup fails with Assorted Errors on 11.2.0.2 if cursor sharing is enabled

2. Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT

如果控制文件自动备份目标文件系统为 NFS，则要求使用“NOAC”选项装载该文件系统；否则将报错 ORA-27054

症状：

如果 snapshot（快照）控制文件定位到 NFS 文件系统并且不是使用选项“NOAC”装载的，则 RMAN 备份将失败，并出现 ORA-27054 错误。根据 Bug 5064356 的修复，如果运行的是 10.2.0.4.0 或更高版本，则不再需要 NFS 装载点的 NOAC 选项。但是，此修复似乎仅适用于特定文件类型，也就是：联机重做日志、归档重做日志、备份片（例如：RMAN）和跟踪文件。

Starting Control File and SPFILE Autobackup at 07-APR-12
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 04/07/2012 10:29:17
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not
mounted with correct options
Additional information: 3

在 alert.log 文件中

Starting control autobackup
WARNING:NFS file system /oracle/product mounted with incorrect options
WARNING:Expected NFS mount options:
rsize>=32768,wsize>=32768,hard, actimeo=0
Autobackup failed with following error
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3

出现此问题是因为 Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT. 此 Bug 已在 11.2.0.2 中修复

Workaround:

1) 对于保存snapshot（快照）控制文件的 NFS 文件系统，使用 NOAC 选项装载。

或者

2) 将 snapshot（快照）控制文件的位置更改到非 NFS。

Ref: Bug 8482162 Snapshot controlfile still needs "noac" on NFS mount points (ORA-27054) Note 8482162.8

3. Bug 9577583: FALSE ORA-942 OR OTHER ERRORS WITH MULTIPLE SCHEMAS HAVING IDENTICAL OBJECTS

当 RMAN 目录数据库（catalog）保存了多个 RMAN 目录 schema（方案）时，目录数据库上将提醒出现错误 ORA-00942。

症状：
用户发现多个 ORA-942 错误
任何在多个 schema（方案）下有同名对象的数据库都可能会遇到此问题。
这是间歇性问题，无法重现，但会多次出现。
这是通用的 Bug，主要影响 RMAN 目录备份。影响 11.2.0.1，在 11.2.0.2 中已提供了修复。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03015: error occurred in stored script incremental_level0
RMAN-03002: failure of backup command at 06/25/2010 13:21:22
RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
RMAN-06031: could not translate database keyword

Debug跟踪信息显示

DBGSQL: EXEC SQL AT RCVCAT begin dbms_rcvman . translateDatabase ; end ; [13:21:22.794]
DBGSQL: sqlcode=-942 [13:21:22.795]
DBGMISC: krmksqlerror called from file krmk.c, line 12649 [13:21:22.796]
DBGRCVMAN: ENTERING translateDatabase
DBGRCVMAN: ENTERING validateState
DBGRCVMAN: EXITING validateState validateState
DBGRCVMAN: OPENING cursor translateDatabase_c in translateDatabase
DBGMISC: krmicomp: error 6004 signalled during compilation [13:21:22.797]
DBGMISC: ENTERED krmkmrsr [13:21:22.797]

RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 4590
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 16168
ORA-06512: at line 1
RMAN-06097: text of failing SQL statement: begin dbms_rcvman . translateDatabase ; end ;
RMAN-06099: error occurred in source file: krmk.pc, line: 7618
RMAN-06031: could not translate database keyword

解决方案：

应用针对 Bug 9577583 的 Patch 9577583

Ref: Note 9577583.8 False ORA-942 or other errors when multiple schemas have identical object names.

4. BUG 10635701 - BACKUP OF FRA CONSUMES 15GB OF PGA AND FAIL WITH ORA-4030

RMAN 在备份大量文件时，会由于消耗过多内存而失败，并出现 ORA-4030。错误出现在heap（堆）KSFQ，其中包含带有注释“KSFQ Buffers”的块。影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中修复

症状：

RMAN 跟踪信息显示以下 function（函数）中出错。

dbms_backup_restore.validationvalidate，带有类似下文的跟踪行：
krmxrpc - channel t1 kpurpc2 err=4030 db=target proc=SYS.DBMS_BACKUP_RESTORE.VALIDATIONVALIDATE

失败进程的调用堆栈：

              kghalf <- ksfqbalo <- ksfqbcre <- ksfqxc <- ksfqxcrx <- ksfqxcre <- krbrvv

分配的内存为 KSFQ的 heap（堆），其中 KSFQ heap（堆）包含带有注释“KSFQ Buffers”的块。该信息会被转储到错误 ORA-4030 生成的跟踪文件中

以下文件中的错误： /cihcissdb028/dump01/oracle/dxls/udump/diag/rdbms/dxls/dxls/incident/incdir_68404/dxls_ora_27140_i68404.trc:

ORA-04030: out of process memory when trying to allocate 824492 bytes (pga heap,kco buffer)
ORA-04030: out of process memory when trying to allocate 1052684 bytes (KSFQ heap,KSFQ Buffers)

解决方案：

应用 Patch 10635701，这个问题没有办法绕过。影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中包括修复。

Ref: Note 10635701.8 RMAN backup many files consumes lots of PGA / fails with ORA-4030

5. BUG 12370722 - CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]

升级到 11.2.0.2 之后，归档进程持续引发 ORA_0600 [krr_highest_scn_tim_8]。升级之后在 11.2.0.2 中报错；影响升级，导致停机，解决方法是清除联机重做日志。此问题已在 11.2.0.3 中修复。

以下列出的 Bug，其症状类似于父 bug 12370722

    Bug 11872889: ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [KRR_HIGHEST_SCN_TIM_8]

    Bug 12534566: DATABASE OPEN FAILED ORA-00600 [KRR_HIGHEST_SCN_TIM_8]

    Bug 11062394: ORA-600 [KRR_HIGHEST_SCN_TIM_8] REPORTED BY AN ARCHIVER PROCESS

所有这些 Bug 均已关闭，与以下 Bug 重复：

   Bug 12370722: CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]

症状：

查找错误：
?运行 Oracle 版本 11.2.0.2
?数据库近期从 10.2（或 10.1）升级到 11.2.0.2，为确认这一点，11.2.0.2 alert log 应显示“ALTER DATABASE OPEN MIGRATE”。

归档进程定期（例如每分钟）报错 ORA-00600:[krr_highest_scn_tim_8]，然后终止，调用堆栈如下：
-> ksbrdp -> krsv_abs -> ksbabs -> kcrrwk -> kcrrwkx -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]

或者

尝试打开数据库的进程报错 ORA-00600:[krr_highest_scn_tim_8]，调用堆栈如下：
-> adbdrv -> kcfopd -> kcttsc -> krsq_arch_to_force_ -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]

或者

执行 alter system archive log all; 的进程报错 ORA-00600:[krr_highest_scn_tim_8]，调用堆栈如下：

-> kkyasy -< krsq_arch_all_or_next -> krsq_arch_one_log -> krse_arc_driver->krse_arc_driver_core -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]
一个特定联机重做日志未归档，以下查询会显示未归档的日志序列号：

SQL> select sequence# from v$log where archived='NO' and status = 'CURRENT';

错误：

RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of sql command on default channel at 05/20/2011 01:26:24
RMAN-11003: failure during parse/execution of SQL statement: alter system archive log current
ORA-00600: internal error code, arguments: [krr_highest_scn_tim_8], [], [], [], [], [], [], [], [], [], []

Workaround:

为防止出现 ORA-00600:[krr_highest_scn_tim_8]，请在开始升级到 11.2.0.2 之后，不要返回并使用 Oracle 版本 10 打开数据库。

如果数据库由于无法切换到下一个（未归档的）联机重做日志而挂起，或者由于前台进程尝试归档联机重做日志并出现 ORA-00600:[krr_highest_scn_tim_8] 错误而终止，导致无法打开数据库，则尝试添加另一个重做日志组

SQL> startup mount

     alter database add logfile group <n> ('<filename>') size <x>M;

如果已经报错 ORA-00600:[krr_highest_scn_tim_8]，并且定期持续报错，则可以通过以下方法之一来解决：

- 安装补丁程序，

- 或者通过以下方法清除联机重做日志：

SQL> select group# from v$log

     where archived='NO' and status = 'CURRENT';

     alter database clear logfile group <group#>;

注：清除联机重做日志表示该序列号的日志中的重做无法用于恢复，因此应该在清除日志之后尽可能早地执行完整备份。

6. BUG 10170431 - CTWR CONSUMING LOTS OF CPU CYCLES

如果启用了 Block Change Tracking（块更改跟踪，简称 BCT），则 CTWR进程会消耗 CPU，而数据库整体性能将会受到严重影响。这种现象会在 11.2.0.2 中发生，解决方法是禁用块更改跟踪或应用one-off补丁程序。该问题已在 11.2.0.3 中修复

症状：

在最低负载的情况下，CTWR 后台进程消耗 90% 到 100% 的 CPU。

ALTER SYSTEM CHECKPOINT 会显著降低 CTWR CPU 负载，稍后将返回到 90% 到 100% CPU 负载（CTWR处理块更改之后），这种现象很有可能也是这个问题。

CTWR 的调用堆栈很可能显示在以下函数中不断循环（spinning）：

kcmgtsf ()
krcptmo ()
ksbabs ()
krcpabs ()
ksbrdp ()

Workaround: 禁用 BLOCK CHANGE TRACKING (BCT) 或者应用针对 bug 10170431 的 Patch 10170431。

7. BUG 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE

RMAN备份或者重新同步RMAN目录（resync catalog）命令失败，出现错误RMAN-20052: invalid datafile create SCN

将数据文件添加到transportable表空间，然后恢复目录出现问题。

由于插入(plug in) SCN 为零，导致在尝试使用恢复目录时出现问题。

解决方法是应用 patch 13000553.

Bug 13877582 - RMAN SOME DATAFILES AT STANDBY SITE APPEAR WITH NULL NAME

发现与以下 Bug 重复：

Bug 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE

症状：
目标数据库是 dataguard（物理备用）环境
表空间已插入(plug in)了主数据库。
插入(plug in)表空间之后，一些数据文件被添加到其中。
恢复目录为 11.2.0.3

已在以下版本中修复：12.1

解决方案

在恢复目录数据库中应用 patch 13000553，并在主站点与备用站点之间重新同步目录。如果在应用补丁之后，文件名仍显示为空白，则重新创建恢复目录，在新目录中注册主站点，然后将备用站点与新目录重新同步。

Ref:

Note 1446934.1 Some Datafiles At Standby Site Appear With NULL Name in RMAN

Note 1411883.1 RMAN-20052: invalid datafile create SCN During Resync or Backup using Recovery Catalog 11.2.0.3

8. BUG 12312133 - RMAN INCREMENTAL BACKUP WITH BLOCK CHANGE TRACKING MAY CAUSE STANDBY DB CRASH

如果在备用数据库上启用了 BCT 并且 RMAN 执行增量备份，则 CTWR 会使备用数据库出现 ORA-0600[krcccb_busy]，并崩溃。此问题影响 11.2.0.2、11.2.0.3，绕过问题的方法是禁用块更改跟踪。

症状：
在备用数据库上启用了 BCT
RMAN 执行增量备份。
CTWR会出现 ora-0600[krcccb_busy]，使备用数据库崩溃。

Errors in file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_ctwr_499736.trc:

ORA-00600: internal error code, arguments: [krcccb_busy], [], [], [], [], [], [], [], [], [], [], []

CTWR (ospid: 499736): terminating the instance due to error 487

System state dump requested by (instance=1, osid=499736 (CTWR)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_diag_1884206.trc

Workaround: 解决方法：禁用块更改跟踪。应用 patch 12312133

Ref: Note 12312133.8 Standby DB crashes with ORA-600 [krcccb_busy] /Ora-00600 [krccckp_scn] with block change tracking

9. BUG 10318078 - RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY

在 11.2 中，RMAN 到磁带的备份成功完成并退出 RMAN 时生成 core dump。

症状：
Backup（备份）成功完成, RMAN 退出时，生成core dump（转储）。
core stack（堆栈）显示：/oracle/movt/11G/app/product/release/lib/libskgxp11.so

Workaround: 将 Oracle 可执行文件与 Media Manager API 库的静态版本链接，而不是动态链接库

关闭所有使用此 ORACLE_HOME 的实例

% cd $ORACLE_HOME/rdbms/lib

% make -f ins_rdbms.mk ioracle LLIBMM=/usr/lib/libnwora.a

% ln -s /usr/lib/libnwora.so libobk.so

使用静态链接的库“libnwora.a”而不是动态库“libnwora.so”

Ref: Note 1296704.1 RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY.

解决方案：

应用针对 Bug:10318078 的修复

Patch 11774404: TRACKING BUG FOR 10318078 FOR AIX11.2- 212 - IBM AIX on POWER Systems (64-bit)

Patch 11774413: TRACKING BUG FOR 10318078 FOR SOLARIS SPARC64

10. BUG 13602883 - BLOCK CHANGE TRACKING NOT USED FOR INCREMENTAL BACKUPS

症状：

如果在数据库（cluster_database=TRUE）运行期间意外禁用了增量备份的块更改跟踪 (BCT)、RMAN 会话或实例在上一次备份期间终止，并且 RDBMS 发行版早于 11.2.0.4，则可能命中这个 Bug。

该 Bug 影响 11.2.0.2/3（也可能影响更早的版本），任意平台都可能发生。但是，它只影响 RAC，即数据库设置了参数 cluster_database=true。

该 Bug 已在 11.2.0.4 及更高版本中修复。

11. MML 不兼容问题：使用 Oracle 11.2 执行 RMAN备份或恢复到磁带的操作期间出现 ORA-07445 [Strcpy()+48]

不兼容的 MML 软件在使用 RMAN备份数据库时将导致 core dump。alert.log 中报告 core dump 错误 ORA-07445 [Strcpy()]，并且备份通道意外终止。

症状：

Errors in file /apps/oh/admin/PPMP/bdump/diag/rdbms/ppmp/PPMP/trace/PPMP_ora_32421.trc (incident=29135):
ORA-07445: exception encountered: core dump [strcpy()+16] [SIGSEGV] [ADDR:0x9] [PC:0x3E2B170D00] [Address not mapped to object] []

RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of backup command on t1 channel at 11/18/2011 23:13:19
RMAN-10038: database session for channel t1 terminated unexpectedly

Call Stack（调用堆栈）：
__restore_rt strcpy put_string send_bprdreq bprd_get_features bsa_checkFeatureIdVxBSAValidateFeatureId xbsa_ValidateFeatureId int_StartJob sbtbackup skgfqcre ksfq_cre ksfqfcrx krbbOpenOutput krbbpc krbibpc

Ref: Note 959015.1 ORA-07445 [Strcpy()+48] during RMAN backup or restore to tape using Oracle 11.2

解决方案：

检查 MML 软件与 11.2 的兼容性。如需帮助，请联系供应商技术支持

例如：在以下网址可以找到与 Veritas netbackup 相关的详细信息

http://www.symantec.com/business/support/index?page=content&id=TECH77071

12. Bug 11694127 - RMAN DUPLICATE not honoring TIME portion of date for "UNTIL TIME" [ID 11694127.8]

症状：


    DUPLICATE 期间，当 NLS_DATE_FORMAT 不包含 TIME 规范时，
    UNTIL TIME 将被截断。因此，构建的duplicate数据库可能会处于错误的时间点
    例如：
      假设 RMAN 复制使用命令： set until time "to_date('Jan 27 2011 17:05:00','Mon DD YYYY HH24:MI:SS')";
      alert.log 文件将显示： start until time 'JAN 27 2011 00:00:00' using backup controlfile

    Rediscovery Notes:
     恢复期间 DUPLICATE 失败，原因是 NLS_DATE_FORMAT 不包含 TIME 部分，导致 UNTIL TIME 被截断。

Workaround
     将 NLS_DATE_FORMAT 设置为具有时间精度的格式，然后
     使用 UNTIL TIME 执行 RMAN 复制命令。
     示例：
      setenv NLS_DATE_FORMAT 'DD-MON-YYYY HH24:MI:SS'
      setenv NLS_LANG 'AMERICAN_AMERICA.UTF8'
      使用 RMAN 连接到目标和 auxiliary(辅助)实例
      执行带有 UNTIL TIME 的 RMAN 复制命令

有关受影响/修复的版本，请参阅： Note 11694127.8

11GR2 中的常见 RMAN 问题相关推荐

基于Python查找图像中最常见的颜色
点击上方"小白学视觉",选择加"星标"或"置顶" 重磅干货,第一时间送达如果我们能够得知道一幅图像中最多的颜色是什么的话,可以帮助我们解决 ...
详解pytorch中的常见的Tensor数据类型以及类型转换
文章目录概览 Tensor的构建补充类型转换附录概览本文主要讲pytorch中的常见的Tensor数据类型,例如:float32,float64,int32,int64.构造他们分别使用如 ...
人力资源中最常见的7张报表
以下是在人力资源中最常见的7张报表. 人员结构分析从部门.工龄.性别总体的分析整个员工的分布新增员工分析从学历和来源分析新增员工人员离职分析从原因和趋势分析部门层级学历层级工龄层级性 ...
php进攻教程,如何对PHP程序中的常见漏洞进行攻击（下）_php基
如何对PHP程序中的常见漏洞进行攻击(下)_php基发布时间:2016-06-17 来源: 点击: 次如何对PHP程序中的常见漏洞进行攻击(下) 翻译:analysist(分析家) 来源:http ...
编程面试过程中最常见的10大算法
编程面试过程中最常见的10大算法编程语言:C/C++ 1. 字符串如果IDE没有代码自动补全功能,所以你应该记住下面的这些方法. toCharArray() // 获得字符串对应的char数组 A ...
5 个 Android 开发中比较常见的内存泄漏问题及解决办法
Android开发中,内存泄漏是比较常见的问题,有过一些Android编程经历的童鞋应该都遇到过,但为什么会出现内存泄漏呢?内存泄漏又有什么影响呢? 在Android程序开发中,当一个对象已经不需要再 ...
Js中最常见的异常捕捉 TryCatch
Js中最常见的异常捕捉 TryCatch 参考文章: (1)Js中最常见的异常捕捉 TryCatch (2)https://www.cnblogs.com/Zwq286179/p/5999450.ht ...
java安装_Java开发中更多常见的危险信号
java安装在< Java开发中的常见危险信号>一文中,我介绍了一些不一定本身就是错误或不正确的做法,但它们可能表明存在更大的问题. 这些"红色标记"类似于" ...
C语言初学者代码中的常见错误与瑕疵(9)
题目字母的个数现在给你一个由小写字母组成字符串,要你找出字符串中出现次数最多的字母,如果出现次数最多字母有多个那么输出最小的那个. 输入:第一行输入一个正整数T(0<T<25) 随后T ...

11GR2 中的常见 RMAN 问题

11GR2 中的常见 RMAN 问题相关推荐

最新文章

热门文章