添加或者删除shard，是shard的数量发生变化，叫做re-shard。re-shard会导致chunk的挪动（chunk migration），re-shard的chunk migration是将原来的chunk的序号大的部分，移动到新node上。示意图如下：我们来发起一次添加shard节点，做re-shard：1. 检查初始状态，在shardcat主机：[oracle12c@sdb1 ~]$ gdsctl GDSCTL: Version 12.2.0.0.0 - Beta on Mon Nov 07 10:52:30 CST 2016 Copyright (c) 2011, 2015, Oracle. All rights reserved. Welcome to GDSCTL, type "help" for information. Current GSM is set to SHARDDIRECTOR1 GDSCTL>set gsm -gsm SHARDDIRECTOR1 GDSCTL>connect mygdsadmin/oracle Catalog connection is established GDSCTL> GDSCTL> GDSCTL>config shard Name Shard G ...继续阅读 (28)

根据twitter上 ‏@OracleDatabase 的消息12.2在oracle云上已经可用了。具体的说，是在DBCS(Oracle Database Cloud Service)，ECS(Exadata Cloud Service)，以及EECS(Exadata Express Cloud Service)上已经可以用12.2了。Oracle当初说12.2 Nov available，还真没跳票。经历了2015年十月的beta 1版本，2016年2月的beta 2版本，和2016年8月的beta 3版本，目前发布的版本可能是2016年10月25日的版本。同时在文章『Oracle Database 12c Release 2 on Oracle Cloud Now Available』上提到的『12.2 on Oracle Cloud New Features Guide』，也指向了12.2的在线文档。目前这些12.2的在线文档，已经不限于内部访问，外部用户也已经可以查看这些文档了。具体的连接地址是：http://docs.oracle.com/database/122/index.htm。喜欢sharding的小伙伴们，可以通过官方途径，查看『Administrator’s Guide』了。这个2016年十月版本的Administrator’s Gui ...继续阅读 (24)

我写关于12.2 sharding database的文章已经好久了，今天再次把环境启动了起来，启动了主机之后，依次启动了listener和shardcat数据库和shard node数据库实例。检查shard状态的时候，发现报错：（a）问题一：status显示warnings：GDSCTL>config shard Name Shard Group Status State Region Availability ---- ----------- ------ ----- ------ ------------ sh1 primary_shardgroup Ok Deployed region1 ONLINE sh2 primary_shardgroup Warnings Deployed region1 - GDSCTL>遇到这样的情况，我们可以使用recover shard的命令。注意recover shard -h出来的帮助是错误的。GDSCTL>recover shard ...继续阅读 (28)

我的vbox的根目录磁盘空间快不够用了，[root@testdb2 ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_testdb2-lv_root 27431124 21329720 4707948 82% / tmpfs 3481600 88 3481512 1% /dev/shm /dev/sda1 495844 56258 413986 12% /boot [root@testdb2 ~]#我原来的oracle软件和数据，都放在根目录的/u01下，现在根目录已经82%了。我决定给vbox加一块盘，扩大根目录的空间。首先，在vbox的图形化界面添加一块硬盘。当然，如果不用图形化界面，用命令行如下，也是可以的。VBoxManage createhd --filename "Z:\Oralce_Virtual_Box\Test DB\TestDB2(11g 12c)\Test_db(11 12c)_AttachStorage.vdi" --size 8192 --format VDI --varia ...继续阅读 (31)

继上次聊SQL Plan Directives（SPD）可能会造成过量的动态采样之后，我再小结一些关于SPD的使用方法。（1）SPD的信息，有MMON每隔15分钟刷进数据字典，如果要在15分钟不到前，查询dba_sql_plan_dir_objects和dba_sql_plan_directives，可以先flush强制刷出，再查询：exec dbms_spd.FLUSH_SQL_PLAN_DIRECTIVE;（2）如何关联sql id和directive id，可以在display_cursor时使用format=>’+METRICS’conn test/test explain plan for select cust_id, channel_id, product from big_table where product = 'Nokia' and channel_id = 1 order by product; select* from table(dbms_xplan.display(null,null,'+METRICS'));（3）ALTER_SQL_PLAN_DIRECTIVE可以改变ENABLED和AUTO_DROP的属性。dbms_spd.alter_sql_plan_directive(14130932452940 ...继续阅读 (31)

在12c中，优化器进行了较大的改变，推出了Adaptive query optimization，从整体上说，Adaptive query optimization可以看作如下两部分：一部分是自适应执行计划，一部分是自适应统计信息。这里注意一下，• Adaptive Plans – 是在第一次执行的时候，从default plan变成adaptive plan。• Automatic Re-optimization -是在第二次执行的时候• Statistics Feedback 以前叫Cardinality Feedback• Dynamic Statistics 以前叫Dynamic Sampling• SQL Plan Directives（SPD） 到目前12.1为止，你可以认为是动态采样的持久化好，我们今天讨论的主题是最后一项，SQL Plan Directives（SPD）。我们来一起看看SPD。在2013年6月oracle官方的白皮书『Oracle Database 12c 中的优化器』中，提到：SPD是根据从自动重新优化获得的信息自动创建的。SQL 计划指令是优化器用于生成更优执行计划的附加信息。例如，当联接在其联接列中具有数据偏差的两个表时，SQL 计划指令可指导优化器使用动态统计获得更准确的联接基数估算。所以，当SQL第一次运行时，oracle发现统计信息估计的 ...继续阅读 (36)

12c的GI中，/oracle_grid/app/oracle/crsdata/@global/cvu/baseline/cvures这个目录下的文件占用空间巨大。某生产环境中，目录已经到了32G以上。这可能和如下3个bug有关：Unpublished Bug 18143707 CVU NEED TO DO CVU BASELINE REPORT CLEAN TO AVOID DISK FULL will limit .txt files to 5 Unpublished Bug 19703199 CVU NEED TO DO CVU BASELINE REPORT CLEAN TO AVOID DISK FULL will limit .xml files to 5 Unpublished Bug 20177779 BIGBH U01 SPACE CONSUMPTION BY CVUCHECKREPORT.XML will purge the files on remote nodes解决方案：Bug 18143707 is fixed in 12.1.0.2 Bug 19703199 is fixed in 12.1.0.2.4 PSU Bug 20177779 is fixed in 12.1.0.2.5 PSU The workaround is to remove t ...继续阅读 (28)

很多人不喜欢omf，包括我。但是我给大家讲个故事，在这个故事中，我们可以看到使用omf的重要性。因为在使用omf的情况下，也就不会发生下面的场景。在一个夜黑风高的夜晚，客户的生产库某个数据文件在晚上突然之间消失了，数据库crash。数据文件是在asm的+DATA diskgroup上，在数据库和asm的alertlog中看不到任何关于该数据文件被删除的信息。DBA和主机组的同事，都没有发起过删除该数据文件的命令。并且由于该数据文件是正在被使用，正常情况下，即使运行asmcmd命令删除，也是无法执行成功的。那么是谁删除了生产正在使用的数据文件呢？幸好我们还有操作系统的旁路审计，从日志中可以看到当晚有个创建dataguard的操作。问题就发生在duplicate的过程中。客户的环境是这样的，这个生产库在大集群中（我们姑且称大集群1），四节点。客户用的是single instance的HA，5，6个数据库跑在一个节点上，其他几个节点是空负载，在必要的时候可以切换过去。这些数据库的数据文件放在asm上，是在+DATA路径。这个生产库后面跟着一个物理datguard，物理dataguard也是在一个大集群中（我们称作集群2），两节点，也是single instance HA，几十个数据库跑在一个节点上。剩余的节点空负载。这些数据库的数据文件也是放在asm上，是在+DATA路径。即primar ...继续阅读 (33)

故事最开始的起因，是监控发现v$log中的first_time时间，显示的是昨天的时间。而登录数据库检查sysdate是正常的时间。我们可以模拟出来下面的故障：session 1，用 TZ=EST5EDT起库，此时，可以看到v$log中的FIRST_TIME是12小时之前的。[oracle11g@testdb2 ~]$ export TZ=EST5EDT [oracle11g@testdb2 ~]$ [oracle11g@testdb2 ~]$ [oracle11g@testdb2 ~]$ [oracle11g@testdb2 ~]$ sqlplus "/ as sysdba" SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 25 00:19:39 2016 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application ...继续阅读 (23)

rman的备份，我们平时总是希望越快越好。但是有时候，rman的备份会撑爆HBA卡的流量，严重影响生产系统。在一个大的cluster中，有17个db，当13个db发起rman备份的时候，主机上的HBA卡流量几乎被撑爆了，几乎所有的IO操作都不可进行了。所以，我们要想办法让rman“慢”一些，减少备份对生产系统的影响。在mos中，有一篇文档，是将关于减少rman备份对OLTP的影响，How to Minimise the impact of an Online RMAN Backup on an OLTP system (Doc ID 369573.1)。里面讲到了几种方式：1. 在standby上备份 2. Split mirror snapshot backup（存储技术） 3. BCT（block change tracking） 4. 使用参数RATE（9i以上） 5. 使用参数DURATION+MINIMIZE LOAD（10g以上）而第5种方式，对于带库的备份，oracle也是不建议使用的。因为它会长时间的hold住磁带。所以我们平常可能用RATE的参数来限制。RATE的参数解释，在在线文档上说，像掐喉咙（serve as throttle）一样，即限制读取数据文件的吞吐量，又限制写数据文件到磁带的吞吐量。我测试了一下rate参数，可以看到，当我使用rate 15M的时候 ...继续阅读 (26)

客户有个数据库从HP平台迁移到linux平台，字符集相同。impdp的时候报错ORA-01401了。Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANT Processing object type SCHEMA_EXPORT/TABLE/TABLE ORA-39083: Object type TABLE:"MYORDATA"."ASS_ACCHSHT_GREEN_MEMORY" failed to create with error: ORA-01401: inserted value too large for column Failing sql is: CREATE TABLE "MYORDATA"."ASS_ACCHSHT_GREEN_MEMORY" ("GROUP_ID" VARCHAR2(16 BYTE) NOT NULL ENABLE, "ACCOUNT_ID" VARCHAR2(16 BYTE) NOT NULL ENABLE, "ADDED_BY" ...继续阅读 (26)

（一）参数说明：（1）. rate_limit参数从9.2.0.8引入，可以用来控制连接风暴。rate_limit后面跟的参数是允许每秒连接的个数，配置完成后，需要stop/start listener生效。如下：LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host.sample.com)(PORT = 1521)(RATE_LIMIT=5)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host.sample.com)(PORT = 1522)) ) )上面的配置表示1521端口只允许每秒5个连接，而1522端口是没有限制的。配置以后，在listener.log中，如果有超过设置的连接数，会报错tns-1158：在11：42：24这个时刻，可以看到最多5个连接，超出的就报错tns-1158了。15-MAY-2010 11:42:24 * establish * 1158 TNS-01158: Internal connection limit reached, preventing dispatcher from conn ...继续阅读 (28)

有一个库，在主库添加了一个tora10g的配置，发现原来已经存在的rora10g和lora10g都发生了异常，不再继续传日志。检查v$archive_dest显示status为BAD PARAM，error为：ORA-16053 DB_UNIQUE_NAME is not in the Data Guard Configuration：SQL> select dest_id, status, destination, error from v$archive_dest; DEST_NAME DESTINATION STATUS ERROR ------------------------------ -------------------------------------------------- --------- ----------------------------------------------------------------- LOG_ARCHIVE_DEST_1 USE_DB_RECOVERY_FILE_DEST VALID LOG_ARCHIVE_ ...继续阅读 (39)

客户有个12c的环境，正在做xtts的迁移，从10g迁移到12c。其中一项要求是12c的一些初始化参数和10g一致，如parallel_max_servers。发现设置后，重启了数据库，还是无法达到预期的修改值。SQL> show parameter parallel_max_servers NAME TYPE VALUE ---------------------- ----- --------- parallel_max_servers integer 474 SQL> alter system set parallel_max_servers=585 scope=spfile; shutdown immediate; startup; SQL> show parameter parallel_max_servers NAME TYPE VALUE ---------------------- ----- --------- parallel_max_servers integer 474打开其alertlog中，我们可以看到类似如下的信息：Adjusting the altered value of pa ...继续阅读 (45)

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。primary的rman archivelog deletion policy是ship to all standby同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。远程standby的rman archivelog deletion policy是applied on all standby。某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：RMAN-08120:WARNING: archived log not deleted, not yet applied by standby只有加force参数才能强行删除日志。这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。This behavior has changed and is related to:Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT B ...继续阅读 (27)

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。primary的rman archivelog deletion policy是ship to all standby同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。远程standby的rman archivelog deletion policy是applied on all standby。某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：RMAN-08120:WARNING: archived log not deleted, not yet applied by standby只有加force参数才能强行删除日志。这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。This behavior has changed and is related to:Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT B ...继续阅读 (34)

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。primary的rman archivelog deletion policy是ship to all standby同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。远程standby的rman archivelog deletion policy是applied on all standby。某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：RMAN-08120:WARNING: archived log not deleted, not yet applied by standby只有加force参数才能强行删除日志。这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。This behavior has changed and is related to:Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT B ...继续阅读 (28)

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。primary的rman archivelog deletion policy是ship to all standby同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。远程standby的rman archivelog deletion policy是applied on all standby。某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：RMAN-08120:WARNING: archived log not deleted, not yet applied by standby只有加force参数才能强行删除日志。这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。This behavior has changed and is related to:Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT B ...继续阅读 (27)

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。primary的rman archivelog deletion policy是ship to all standby同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。远程standby的rman archivelog deletion policy是applied on all standby。某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：RMAN-08120:WARNING: archived log not deleted, not yet applied by standby只有加force参数才能强行删除日志。这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。This behavior has changed and is related to:Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT B ...继续阅读 (19)

问题是这样的：在12c中，我们测试了2种情况：第一种是加了hint，使得12c的执行计划和10g类似，只是由于12c的nlj_batching，多了一次nestloop。但是执行计划本质是相同的，都是索引S_CONTACT_X_U1返回表查询。第二种是使用了10g的outline hint，OFE=10g的，执行计划完全一样。但是我们发现，无论是在12c中的哪一种情况，驱动表S_SRV_REQ的索引PA_S_SRV_REQ_1_X的full index scan返回结果差异这么大？文章最后附在10g和12c环境中的测试经过，以及10g环境中的10046 trace和12c第一种情况的10046 trace。12c-第一种情况：12c-第二种情况：10g数据库的情况：###################################另外，根据过滤条件，10g和12c返回结果也差不多。且消耗也差不多！12c：10g：在同事的Fred Liu的帮助下，我们终于找到了答案。（Fred Liu在他近期的微信公共账号也写了这个问题。大家可以关注：『老虎刘谈SQL优化』 ）（1）首先，这个SQL逻辑有问题。可以见我附件10g.txt中的附件，有完整的sql文本SQL的主要功能是分页，客户这里把rownum和order by写在一层关系中了。所以这个是错误的。（2）就算是在逻辑错误，为什么10 ...继续阅读 (32)

问题是这样的：在12c中，我们测试了2种情况：第一种是加了hint，使得12c的执行计划和10g类似，只是由于12c的nlj_batching，多了一次nestloop。但是执行计划本质是相同的，都是索引S_CONTACT_X_U1返回表查询。第二种是使用了10g的outline hint，OFE=10g的，执行计划完全一样。但是我们发现，无论是在12c中的哪一种情况，驱动表S_SRV_REQ的索引PA_S_SRV_REQ_1_X的full index scan返回结果差异这么大？文章最后附在10g和12c环境中的测试经过，以及10g环境中的10046 trace和12c第一种情况的10046 trace。12c-第一种情况：12c-第二种情况：10g数据库的情况：###################################另外，根据过滤条件，10g和12c返回结果也差不多。且消耗也差不多！12c：10g：在同事的Fred Liu的帮助下，我们终于找到了答案。（Fred Liu在他近期的微信公共账号也写了这个问题。大家可以关注：『老虎刘谈SQL优化』 ）（1）首先，这个SQL逻辑有问题。可以见我附件10g.txt中的附件，有完整的sql文本SQL的主要功能是分页，客户这里把rownum和order by写在一层关系中了。所以这个是错误的。（2）就算是在逻辑错误，为什么10 ...继续阅读 (36)

问题是这样的：在12c中，我们测试了2种情况：第一种是加了hint，使得12c的执行计划和10g类似，只是由于12c的nlj_batching，多了一次nestloop。但是执行计划本质是相同的，都是索引S_CONTACT_X_U1返回表查询。第二种是使用了10g的outline hint，OFE=10g的，执行计划完全一样。但是我们发现，无论是在12c中的哪一种情况，驱动表S_SRV_REQ的索引PA_S_SRV_REQ_1_X的full index scan返回结果差异这么大？文章最后附在10g和12c环境中的测试经过，以及10g环境中的10046 trace和12c第一种情况的10046 trace。12c-第一种情况：12c-第二种情况：10g数据库的情况：###################################另外，根据过滤条件，10g和12c返回结果也差不多。且消耗也差不多！12c：10g：在同事的Fred Liu的帮助下，我们终于找到了答案。（Fred Liu在他近期的微信公共账号也写了这个问题。大家可以关注：『老虎刘谈SQL优化』 ）（1）首先，这个SQL逻辑有问题。可以见我附件10g.txt中的附件，有完整的sql文本SQL的主要功能是分页，客户这里把rownum和order by写在一层关系中了。所以这个是错误的。（2）就算是在逻辑错误，为什么10 ...继续阅读 (33)

问题是这样的：在12c中，我们测试了2种情况：第一种是加了hint，使得12c的执行计划和10g类似，只是由于12c的nlj_batching，多了一次nestloop。但是执行计划本质是相同的，都是索引S_CONTACT_X_U1返回表查询。第二种是使用了10g的outline hint，OFE=10g的，执行计划完全一样。但是我们发现，无论是在12c中的哪一种情况，驱动表S_SRV_REQ的索引PA_S_SRV_REQ_1_X的full index scan返回结果差异这么大？文章最后附在10g和12c环境中的测试经过，以及10g环境中的10046 trace和12c第一种情况的10046 trace。12c-第一种情况：12c-第二种情况：10g数据库的情况：###################################另外，根据过滤条件，10g和12c返回结果也差不多。且消耗也差不多！12c：10g：在同事的Fred Liu的帮助下，我们终于找到了答案。（Fred Liu在他近期的微信公共账号也写了这个问题。大家可以关注：『老虎刘谈SQL优化』 ）（1）首先，这个SQL逻辑有问题。可以见我附件10g.txt中的附件，有完整的sql文本SQL的主要功能是分页，客户这里把rownum和order by写在一层关系中了。所以这个是错误的。（2）就算是在逻辑错误，为什么10 ...继续阅读 (22)

客户有个需求，需要将在一个包含多个rac、多个single instance的大cluster中的某个rac 节点，改成single instance。数据文件还在asm上，原来的数据文件还要继续时候用。我们可以如下操作：High Level Step:1.备份spfile2.停需要转换的rac database3.删除在cluster中注册的这个rac database对应的service信息，对应的instance信息，和对应的database信息。4.修改spfile中，删除关于cluster有关的信息5.启动单实例，删除多余的redo和undo6.将spfile还原回asm上，并且将ORACLE_SID从ora11g1改成ora11g下面我们来具体操作：（1）备份spfile切到grid用户                                         [oracle@rac1 ~]$ crsctl stat res -t----------------------------------------------------------------- ...继续阅读 (36)

客户有个需求，需要将在一个包含多个rac、多个single instance的大cluster中的某个rac 节点，改成single instance。数据文件还在asm上，原来的数据文件还要继续时候用。我们可以如下操作：High Level Step:1.备份spfile2.停需要转换的rac database3.删除在cluster中注册的这个rac database对应的service信息，对应的instance信息，和对应的database信息。4.修改spfile中，删除关于cluster有关的信息5.启动单实例，删除多余的redo和undo6.将spfile还原回asm上，并且将ORACLE_SID从ora11g1改成ora11g下面我们来具体操作：（1）备份spfile切到grid用户                                         [oracle@rac1 ~]$ crsctl stat res -t----------------------------------------------------------------- ...继续阅读 (34)

客户有个需求，需要将在一个包含多个rac、多个single instance的大cluster中的某个rac 节点，改成single instance。数据文件还在asm上，原来的数据文件还要继续时候用。我们可以如下操作：High Level Step:1.备份spfile2.停需要转换的rac database3.删除在cluster中注册的这个rac database对应的service信息，对应的instance信息，和对应的database信息。4.修改spfile中，删除关于cluster有关的信息5.启动单实例，删除多余的redo和undo6.将spfile还原回asm上，并且将ORACLE_SID从ora11g1改成ora11g下面我们来具体操作：（1）备份spfile切到grid用户                                         [oracle@rac1 ~]$ crsctl stat res -t----------------------------------------------------------------- ...继续阅读 (31)

客户有个需求，需要将在一个包含多个rac、多个single instance的大cluster中的某个rac 节点，改成single instance。数据文件还在asm上，原来的数据文件还要继续时候用。我们可以如下操作：High Level Step:1.备份spfile2.停需要转换的rac database3.删除在cluster中注册的这个rac database对应的service信息，对应的instance信息，和对应的database信息。4.修改spfile中，删除关于cluster有关的信息5.启动单实例，删除多余的redo和undo6.将spfile还原回asm上，并且将ORACLE_SID从ora11g1改成ora11g下面我们来具体操作：（1）备份spfile切到grid用户                                         [oracle@rac1 ~]$ crsctl stat res -t----------------------------------------------------------------- ...继续阅读 (34)

rman连接catalog备份时使用的基表和view，解释如下：Base tables:=======================NAME       DESCRIPTION-------   --------------------AL         contains archived logs. archived logs are uniquely identified by dbinc_key, recid and stamp.BCB        contains corrupt block ranges in datafile backups.BCF        contains control file backups (in backup sets).BDF        contains all datafile backups (in backup sets).BP         contains all backup pieces of backup sets.BRL  ...继续阅读 (38)

rman连接catalog备份时使用的基表和view，解释如下：Base tables:=======================NAME       DESCRIPTION-------   --------------------AL         contains archived logs. archived logs are uniquely identified by dbinc_key, recid and stamp.BCB        contains corrupt block ranges in datafile backups.BCF        contains control file backups (in backup sets).BDF        contains all datafile backups (in backup sets).BP         contains all backup pieces of backup sets.BRL  ...继续阅读 (32)

rman连接catalog备份时使用的基表和view，解释如下：Base tables:=======================NAME       DESCRIPTION-------   --------------------AL         contains archived logs. archived logs are uniquely identified by dbinc_key, recid and stamp.BCB        contains corrupt block ranges in datafile backups.BCF        contains control file backups (in backup sets).BDF        contains all datafile backups (in backup sets).BP         contains all backup pieces of backup sets.BRL  ...继续阅读 (31)