我一直在支持很多 Oracle 数据库（不是全职；我 90% 的时间是程序员），我只是偶然在Oracle 19 Linux 安装文档中看到将 Oracle 数据文件存储在本地文件系统上不推荐。我一直支持的所有数据库都有本地文件系统上的数据。
我们正在设置一个有 5 个内部驱动器的新服务器；2 个用于操作系统的小型驱动器和 3 个大型（4 TB）驱动器。所以，似乎我可以做我熟悉的事情，在 3 个大驱动器上设置 RAID 5，指向 /u01。或者，在这些驱动器上设置 ASM。我大概 10 年前就玩过 ASM，所以我对它不是很熟悉。
对于这个新服务器，数据中心 DBA 组将对其进行设置和维护。所以我基本上想知道在使用 ASM 上的数据进行设置时是否需要注意任何事项。还有，对于我们现有的数据库来说，从本地Linux文件系统迁移到ASM是多么的重要。
我无法在该语句的Oracle 19c 文档CREATE TABLE中找到“Result_Cache”子句的确切语法。它提到了DEFAULTor的值FORCE，但没有提到语法。ALTER TABLE 语句也有同样的问题。正确的语法是什么？
我有两个数据库实例，开发和生产完全相同。在生产中，结果缓存工作正常，在开发中则不然。数据库参数的值result_cache_max_size设置为，0因此我将其重置以删除该值，退回数据库，当数据库备份时，该值仍设置为，0因此我尝试从PFILE没有值的result_cache_max_size相同问题开始。然后我尝试将其设置为20M（生产中的值）并反弹，但结果相同。然后我调用
SELECT dbms_result_cache.status() FROM dual;
返回BYPASS。
参数result_cache_max_result和result_cache_mode设置到5两个MANUAL数据库上。
我在两个实例上都使用企业版（所以问题为什么在 Oracle 11g 中总是禁用结果缓存不适用于我）：
发展：
SYS@extdev02> select banner from v$version;
BANNER
----------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...
生产：
extuat01> select banner from v$version;
BANNER
----------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...
编辑：bypass根据@BalazsPapp 的答案尝试了proc，但没有运气。我想我已经尝试过了，但是没有第二个参数，根据文档，它默认为 false。今天的尝试，包括一个flush只是为了好玩的过程：
SYS@extdev02> select dbms_result_cache.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
---------------------------
BYPASS
SYS@extdev02> exec dbms_result_cache.bypass(true, false);
PL/SQL procedure successfully completed.
SYS@extdev02> exec dbms_result_cache.flush
PL/SQL procedure successfully completed.
SYS@extdev02> select dbms_result_cache.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
--------------------------
BYPASS
SYS@extdev02> exec dbms_result_cache.bypass(false, false);
PL/SQL procedure successfully completed.
SYS@extdev02> select dbms_result_cache.status() FROM dual;
DBMS_RESULT_CACHE.STATUS()
--------------------------
BYPASS
我在周日使用以下全局脚本进行 0 级（完全）增量备份：
printing stored global script: weekly_backup
{
allocate channel DISK1 device type disk format '&1/&2_Disk1_%U.bkp';
allocate channel DISK2 device type disk format '&1/&2_Disk2_%U.bkp';
allocate channel DISK3 device type disk format '&1/&2_Disk3_%U.bkp';
backup section size 1g incremental level 0 as compressed backupset
tag '&2'
keep until time 'SYSDATE+&3'
restore point '&2'
database plus archivelog;
delete noprompt obsolete;
}
周一到周六，我运行以下 RMAN 命令进行 1 级增量备份：
run {
backup section size 1g incremental level 1 as compressed backupset archivelog all database;
delete noprompt obsolete;
}
我的重要设置：
RMAN> show all;
RMAN configuration parameters for database with db_unique_name RCATN are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
现在，当我连续几天使用参数 15 调用脚本时，我的 0 级备份集具有相应的 Keep 值：
（我在 2019 年 3 月 28 日运行的所有其余命令）
RMAN> list backupset tag=L0_2019_03_17;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
4349986 7.90M DISK 00:00:01 2019-03-17 02:05:12
BP Key: 4349990 Status: AVAILABLE Compressed: YES Tag: L0_2019_03_17
Piece Name: /mnt/shares/backup/RCATN/L0_2019_03_17_Disk2_sgtskh2n_1_1.bkp
Keep: BACKUP_LOGS Until: 2019-04-01 02:05:11
...
但是当我列出所有备份集时，它显示我有几天的 1 级增量备份，这些备份比我最旧的 0 级（完整）备份还要早：
RMAN> list backupset summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
4324675 B 1 A DISK 2019-03-07 2 1 YES TAG20190307T020510
4324676 B 0 A DISK 2019-03-07 1 1 YES TAG20190307T020510
4324677 B 1 A DISK 2019-03-07 1 1 YES TAG20190307T020510
4325630 B A A DISK 2019-03-07 1 1 NO TAG20190307T120513
4326388 B A A DISK 2019-03-08 1 1 NO TAG20190308T000512
4326760 B A A DISK 2019-03-08 1 1 YES TAG20190308T020510
4326761 B 1 A DISK 2019-03-08 1 1 YES TAG20190308T020510
4326762 B 1 A DISK 2019-03-08 2 1 YES TAG20190308T020510
4327695 B A A DISK 2019-03-08 1 1 NO TAG20190308T120513
4332857 B A A DISK 2019-03-09 1 1 NO TAG20190309T000508
4333313 B A A DISK 2019-03-09 1 1 YES TAG20190309T020508
4333314 B 1 A DISK 2019-03-09 1 1 YES TAG20190309T020508
4333315 B 1 A DISK 2019-03-09 2 1 YES TAG20190309T020508
4334294 B A A DISK 2019-03-09 1 1 NO TAG20190309T120512
4335404 B A A DISK 2019-03-11 1 1 NO TAG20190311T000508
4335904 B A A DISK 2019-03-11 1 1 YES TAG20190311T020509
4335905 B 1 A DISK 2019-03-11 1 1 YES TAG20190311T020509
4335906 B 1 A DISK 2019-03-11 2 1 YES TAG20190311T020509
4336825 B A A DISK 2019-03-11 1 1 NO TAG20190311T120508
4337610 B A A DISK 2019-03-12 1 1 NO TAG20190312T000508
4338006 B A A DISK 2019-03-12 1 1 YES TAG20190312T020509
4338007 B 1 A DISK 2019-03-12 1 1 YES TAG20190312T020509
4338008 B 1 A DISK 2019-03-12 2 1 YES TAG20190312T020509
4338956 B A A DISK 2019-03-12 1 1 NO TAG20190312T120508
4339810 B A A DISK 2019-03-13 1 1 NO TAG20190313T000508
4340248 B A A DISK 2019-03-13 1 1 YES TAG20190313T020507
4340249 B 1 A DISK 2019-03-13 1 1 YES TAG20190313T020507
4340250 B 1 A DISK 2019-03-13 2 1 YES TAG20190313T020507
4341190 B A A DISK 2019-03-13 1 1 NO TAG20190313T120508
4342684 B A A DISK 2019-03-14 1 1 NO TAG20190314T000508
4343074 B A A DISK 2019-03-14 1 1 YES TAG20190314T020508
4343075 B 1 A DISK 2019-03-14 1 1 YES TAG20190314T020508
4343076 B 1 A DISK 2019-03-14 2 1 YES TAG20190314T020508
4344192 B A A DISK 2019-03-14 1 1 NO TAG20190314T120508
4345115 B A A DISK 2019-03-15 1 1 NO TAG20190315T000509
4345510 B A A DISK 2019-03-15 1 1 YES TAG20190315T020508
4345511 B 1 A DISK 2019-03-15 1 1 YES TAG20190315T020508
4345512 B 1 A DISK 2019-03-15 2 1 YES TAG20190315T020508
4346447 B A A DISK 2019-03-15 1 1 NO TAG20190315T120508
4347266 B A A DISK 2019-03-16 1 1 NO TAG20190316T000509
4347630 B A A DISK 2019-03-16 1 1 YES TAG20190316T020508
4347631 B 1 A DISK 2019-03-16 1 1 YES TAG20190316T020508
4347632 B 1 A DISK 2019-03-16 2 1 YES TAG20190316T020508
4348621 B A A DISK 2019-03-16 1 1 NO TAG20190316T120509
4349564 B A A DISK 2019-03-17 1 1 NO TAG20190317T000509
4349986 B A A DISK 2019-03-17 1 1 YES L0_2019_03_17
4349987 B A A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350036 B 0 A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350037 B 0 A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350038 B 0 A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350039 B 0 A DISK 2019-03-17 2 1 YES L0_2019_03_17
4350061 B A A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350062 B A A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350079 B F A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350097 B F A DISK 2019-03-17 1 1 YES L0_2019_03_17
4350114 B A A DISK 2019-03-17 1 1 YES L0_2019_03_17
4351780 B A A DISK 2019-03-17 1 1 NO TAG20190317T120509
4352876 B A A DISK 2019-03-18 1 1 NO TAG20190318T000508
4353260 B A A DISK 2019-03-18 1 1 YES TAG20190318T020508
4353261 B 1 A DISK 2019-03-18 1 1 YES TAG20190318T020508
4353262 B 1 A DISK 2019-03-18 2 1 YES TAG20190318T020508
4354185 B A A DISK 2019-03-18 1 1 NO TAG20190318T120508
...
如果我列出 1 级增量备份的详细信息（我在上面的摘要列表中选择了第一个），我看不到任何 KEEP 数据：
RMAN> list backupset 4324675;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4324675 Incr 1 380.61M DISK 00:01:15 2019-03-07
List of Datafiles in backup set 4324675
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ---------- ----------- ------ ----
3 0 Incr 40466491 2019-03-07 NO /u01/app/oracle/oradata/rmcat/sysaux01.dbf
Backup Set Copy #1 of backup set 4324675
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:01:15 2019-03-07 YES TAG20190307T020510
List of Backup Pieces for backup set 4324675 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
4324680 1 AVAILABLE /u01/app/oracle/recovery_area/RCATN/backupset/2019_03_07/o1_mf_nnnd1_TAG20190307T020510_g80vlp4r_.bkp
4324681 2 AVAILABLE /u01/app/oracle/recovery_area/RCATN/backupset/2019_03_07/o1_mf_nnnd1_TAG20190307T020510_g80vn3cq_.bkp
RMAN>
那么为什么 RMAN 保留比我最旧的 0 级备份更早的 1 级备份呢？
我对 RMAN 有点陌生，并且已经上过 Oracle 课程，但是在使用级别 0 和 1 时我很难验证我的备份；为了节省空间，我正在考虑周日做0级（全）增量备份，周一周二做1级差异备份，周三做1级累积备份。然后周四周五level1 1差异备份，周六level 1累积。
我的想法是在周三成功完成 1 级累积备份后，我可以删除周一和周二的差异 1 级备份。所以，在星期三，为了在我做一些激烈的测试之前进行验证，我做了一个
RMAN> restore database validate;
然后它就消失了，验证文件；但它只查看 0 级星期日备份中的文件。
我原以为它也至少会验证从周三开始的增量 1 级备份。
所以两个问题：
我在两台服务器上安装了 Oracle 12c。在服务器上UAT，我有一个RMCAT托管 RMAN 恢复目录的实例。在服务器上EXT我有两个实例，extdev02和extuat01. 我可以在服务器上使用以下命令UAT连接到我的RMCAT目录和目标extdev02，但是当我尝试连接到extuat01它时会出现ORA-01017
UAT> rman target= sys/tiger@extdev02 catalog= rmuser/tigerman@rmcat
Recovery Manager: Release 12.1.0.2.0 - Production on Wed May 30 22:59:26 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database: EXTDEV02 (DBID=4287636681)
connected to recovery catalog database
RMAN> exit
Recovery Manager complete.
UAT> rman target= sys/tiger@extuat01 catalog= rmuser/tigerman@rmcat
Recovery Manager: Release 12.1.0.2.0 - Production on Wed May 30 22:59:42 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-01017: invalid username/password; logon denied
tnsping我从UAT服务器到两个实例都获得了 OK 结果EXT，并且我可以从服务器连接到非 dba 用户UAT到两个实例。orapw我在EXT服务器实例上使用重新创建了 Oracle 密码文件EXTUAT01，但没有帮助。
实例名称是extdev02和extuat01on server EXT。这是我在该服务器上的密码文件：
/u01/app/oracle/product/12.1.0.2/db_1/dbs> ls -o orapw*
-rw-r-----. 1 oracle 18432 Jun 1 00:07 orapwextuat01
/u01/app/oracle/product/12.1.0.2/db_0/dbs> ls -o orapw*
-rw-r-----. 1 oracle 7680 Feb 6 20:22 orapwextdev02
请注意，它们位于两个不同的 ORACLE_HOME 目录中。的值适用remote_login_passwordfile于EXCLUSIVE两种情况
托管RMAN目录实例的服务器UATRMCAT前几天重启了加内存，现在可以连上了！如果我有一台 wayback 机器，我会回去看看尝试在 UAT 主机上重新启动监听器是否有帮助；无论如何，它都有效。感谢您的建议；我只是为了后代而提出答案。
extdev02：
AtlasExt:SYS@extdev02> select * from v$pwfile_users;
USERNAME SYSDBA SYSOPER SYSASM SYSBACKUP SYSDG SYSKM CON_ID
--------- ------- ------- ------- ---------- ------- ------ ------
SYS TRUE TRUE FALSE FALSE FALSE FALSE 0
extuat01（注意：我运行 orapw 指定 sysbackup 无济于事）
AtlasExt:SYS@extuat01> select * from v$pwfile_users;
USERNAME SYSDBA SYSOPER SYSASM SYSBACKUP SYSDG SYSKM CON_ID
--------- ------- ------- ------- ---------- ------ -------- ------
SYS TRUE TRUE FALSE FALSE FALSE FALSE 0
SYSBACKUP FALSE FALSE FALSE TRUE FALSE FALSE 0
extuat01通过 SQL*Plus从 UAT 连接到 EXT 实例；但重启后我是：来自 UAT 的 extdev02：
AtlasUAT:SYS@extdev02> select host_name, instance_name from v$instance;
HOST_NAME INSTANCE_NAME
------------------------- ----------------
plsekatlasexta01 extdev02
来自 UAT 的 extuat01：
18:25:07 AtlasUAT:SYS@extuat01> select host_name, instance_name from v$instance;
HOST_NAME INSTANCE_NAME
------------------------- ----------------
plsekatlasexta01 extuat01
发现 pmon PID：
plsekatlasexta01> ps -fu oracle | grep pmon | grep -v grep
oracle 1976 1 0 Jun01 ? 00:00:43 ora_pmon_extuat01
oracle 32373 1 0 May16 ? 00:02:45 ora_pmon_extdev02
plsekatlasexta01> cat /proc/1976/environ | tr '\000' '\n' | grep -E 'ORACLE_(HOME|SID)'
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_1
ORACLE_SID=extuat01
plsekatlasexta01> cat /proc/32373/environ | tr '\000' '\n' | grep -E 'ORACLE_(HOME|SID)'
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_0
ORACLE_SID=extdev02
在 Oracle 12c 上，安装了 APEX 的相当新的数据库。我做一个
expdp \"/ as sysdba\" directory=dp_dir full=y dumpfile=full.dmp logfile=full.log
我只从 SYS 和 SYSTEM 导出了几个表：
. . exported "SYS"."KU$_USER_MAPPING_VIEW" 5.882 KB 24 rows
. . exported "SYS"."AUD$" 0 KB 0 rows
. . exported "SYS"."DAM_CLEANUP_EVENTS$" 0 KB 0 rows
. . exported "SYS"."DAM_CLEANUP_JOBS$" 0 KB 0 rows
. . exported "SYS"."DAM_CONFIG_PARAM$" 6.523 KB 14 rows
. . exported "SYS"."TSDP_ASSOCIATION$" 0 KB 0 rows
. . exported "SYS"."TSDP_CONDITION$" 0 KB 0 rows
. . exported "SYS"."TSDP_FEATURE_POLICY$" 0 KB 0 rows
. . exported "SYS"."TSDP_PARAMETER$" 5.945 KB 1 rows
. . exported "SYS"."TSDP_POLICY$" 5.914 KB 1 rows
. . exported "SYS"."TSDP_PROTECTION$" 0 KB 0 rows
. . exported "SYS"."TSDP_SENSITIVE_DATA$" 0 KB 0 rows
. . exported "SYS"."TSDP_SENSITIVE_TYPE$" 0 KB 0 rows
. . exported "SYS"."TSDP_SOURCE$" 0 KB 0 rows
. . exported "SYS"."TSDP_SUBPOL$" 6.320 KB 1 rows
. . exported "SYSTEM"."REDO_DB" 25.58 KB 1 rows
. . exported "SYSTEM"."REDO_LOG" 0 KB 0 rows
. . exported "SYS"."FGA_LOG$FOR_EXPORT" 0 KB 0 rows
. . exported "SYSTEM"."SCHEDULER_JOB_ARGS" 8.671 KB 4 rows
. . exported "SYSTEM"."SCHEDULER_PROGRAM_ARGS" 10.21 KB 22 rows
. . exported "SYS"."AUDTAB$TBS$FOR_EXPORT" 5.953 KB 2 rows
. . exported "SYS"."DBA_SENSITIVE_DATA" 0 KB 0 rows
. . exported "SYS"."DBA_TSDP_POLICY_PROTECTION" 0 KB 0 rows
. . exported "SYS"."NACL$_ACE_EXP" 10.14 KB 3 rows
. . exported "SYS"."NACL$_HOST_EXP" 6.976 KB 2 rows
. . exported "SYS"."NACL$_WALLET_EXP" 0 KB 0 rows
Master table "SYS"."SYS_EXPORT_FULL_01" successfully loaded/unloaded
但是我知道我在其他模式中有表和其他对象：
AtlasProd:SYS@extern01> select owner,
2 decode(segment_type, 'TABLE', 'TABLE', '-other-') as segment_type,
3 count(*)
4 from dba_segments
5 group by owner, decode(segment_type, 'TABLE', 'TABLE', '-other-')
6 order by 1, 2;
OWNER SEGMENT_TYPE COUNT(*)
------------------------------ ------------------ ----------
APEX_050000 -other- 646
APEX_050000 TABLE 155
AUDSYS -other- 6
DBSNMP -other- 4
DBSNMP TABLE 2
GSMADMIN_INTERNAL -other- 15
GSMADMIN_INTERNAL TABLE 6
OUTLN -other- 6
OUTLN TABLE 3
SYS -other- 1987
SYS TABLE 1059
SYSTEM -other- 321
SYSTEM TABLE 124
XDB -other- 655
XDB TABLE 49
15 rows selected.
我在Export pump all schemas except Sytem related schemas中看到了一种解决方法，但我知道我之前已经full=y成功使用过。