星期四 三月 03, 2016

为什么我们应在外键上创建索引

在外键上不创建索引,可能会引发死锁的问题。我将通过一些简单的案例,展示在不同情境下,索引的有无对锁状态的影响。
测试的数据库版本是11.2.0.2,所使用的表emp、dept与scott用户下的表相同。

[Read More]

星期四 二月 04, 2016

Thread Checkpoint 在单节点和 RAC 中的不同

在 Oracle 的官方文档中介绍 Oracle 的 Checkpoint 有:
(1)Thread Checkpoint;
(2)Tablespace and datafile checkpoint;
(3) Incremental checkpoint。
对于后两种 checkpoint,大家都有一个比较清晰的认识。 但是对于 Thread checkpoint 和 database checkpoint 之间的关系以及他们在单节点和RAC数据库之间的不同可能存在一些误区。 下面将通过一些例子来讲解一下 Thread checkpoint,以及在单节点和 RAC 中 Thread checkpoint 的不同。

[Read More]

星期四 十月 22, 2015

TimesTen 返璞归真 – 多连接在ttIsql 中的应用

最近有用户咨询:ttIsql是否可以支持多个并发连接到 TimesTen 数据库。这个问题具有一定的普遍性,相信其他用户也会感兴趣,因此决定将其纳入这篇博客。ttIsql 是一个用来操作TimesTen数据库的交互式SQL命令型管理程序 (utility)。除了支持SQL命令的执行,它还提供了一整套丰富的功能,使得用户不仅能够连接到数据库, 执行其内置(built-in)程序和管理程序,还能支持灵活的命令编辑,以及调用主机操作系统的命令。 所有这些都可以在同一个ttIsql会话中实现!

[Read More]

星期五 十月 16, 2015

Class of Secure Transport (COST) 限制实例注册 测试

COST 是class of secure transports 的缩写。是为了控制实例注册提供的一种安全控制机制。其作用是对于一个确定的listener,限制哪些实例通过哪些协议可以进行注册。这将避免有其他远程实例进行恶意注册,并由此产生信息泄露等风险。它通过在 listner.ora中设置参数SECURE_REGISTER_listener_name的值,指定为一个transport list(限定的注册协议列表,如IPC、TCP、TCPS)来实现这一功能。  该功能从 10.2.0.3 版本开始支持(虽然10g R2的在线文档中并未明确说明),一直到11.2.0.4版本及之后依然可用。但是,在11.2.0.4后,oracle建议使用默认的VNCR配置。

[Read More]

星期二 六月 02, 2015

错误的用户名密码登录导致的数据库性能问题

背景:
从Oracle 11.1开始,错误的用户名密码登录可能会导致在数据库层面看到显著的“row cache lock”等待。
很多用户认为这是一个bug,而实际上这是一个数据库保护机制。
Oracle的sqlplus工具会在3次错误密码输入后自动断开连接,但是外部应用程序却可以编码,不断调用登录API进行密码尝试。所以如果没有一个数据库层面的安全控制,这将是非常危险的。
从Oracle 11.1开始,数据库会在对同一个用户3次错误的密码尝试之后,开始锁定这个用户3秒钟,才允许下一次登录。这个锁定时间将从3秒逐渐延长,不断增加。
所有以该用户登录的session都会等待“row cache lock”,哪怕他是用正确的密码登录的。

很多用户不理解这样做是为了帮助用户避免风险,而对看到的“row cache lock”等待提出抱怨。
所以Oracle在Bug 7715339的修复中提供了一个方法(event 28401)来绕过这段代码,来供用户做不同选择。
event="28401 trace name context forever, level 1" # disable logon delay
必须说明的是,这实际上并不是一个bug,而是一个功能增强。用户必须清楚如果设置了这个事件,将使您的数据库暴露在密码猜测的风险之下。

Bug 7715339的修复被包含在11.2.0.1 PSU之中。而在11.1.0.7上打补丁7715339,默认已经相当于打开event 28401了。
在11.2.0.2之后,Oracle修改代码,将这一段“row cache lock”等待修改成了“library cache lock”等待。
总结一下:
1)11.1.0.X上,错误的用户名密码登录,将导致显著的“row cache lock”等待。
用户可以在11.1.0.7上打补丁7715339,不用设置event 28401,就可绕过这段安全控制代码。
2)11.2.0.1上,错误的用户名密码登录,将导致显著的“row cache lock”等待。
用户不用打补丁(因为已经包含在11.2.0.1中了),直接设置event 28401,就可绕过这段安全控制代码。
3)11.2.0.2以上的版本(包含11.2.0.2),错误的用户名密码登录,将导致显著的“library cache lock”等待。
用户不用打补丁(因为已经包含在11.2.0.1中了),直接设置event 28401,就可绕过这段安全控制代码。

必须再次说明的是,用户必须清楚如果打补丁或者设置了这个事件,将使您的数据库暴露在密码猜测的风险之下。

正题:
有用户反馈,即使设置了event 28401,仍会观察到错误的用户名密码登录导致“library cache lock”等待,这是为什么呢?为此,我们做了以下测试进行说明:

起10个进程,同时进行错误的用户名密码登录,并测试未设置event 28401和设置event 28401进行比较,从V$SYSTEM_EVENT中多次观察获取平均等待时间:
select total_waits,Time_waited_fg/total_waits
from V$SYSTEM_EVENT
where event='library cache lock'

未设置event 28401:
91    1395.252747252747252747252747252747252747
98    2352.959183673469387755102040816326530612
106    2687.698113207547169811320754716981132075
116    3495.862068965517241379310344827586206897

<========library cache lock的平均等待时间很快从13.95秒逐渐增加到34.95秒,并且持续增加。

设置event 28401之后:
23142    2.97325209575663296171463140610146054792
24329    3.03592420568046364421061284886349623906

<========即使在24329次等待之后,library cache lock的平均等待时间仍然稳定在0.03秒。

也就是说,event 28401是生效的,“等待时间从3秒逐渐增加的”的安全机制被绕过了,但是“library cache lock”却无法避免。
这是因为,错误的用户名密码登录仍会在数据库内部更新该用户的登录次数,错误登录次数,上次登录时间等信息,需要申请“library cache lock”。
而“library cache lock”的等待时间跟并发登录的进程数和数据库性能有关。
如果有多个用户进行不断的进行错误的密码尝试,可能仍会观察到较高的“library cache lock”等待。
因为“错误的密码尝试”应用程序的代码逻辑一般都是非常疯狂的,正确的登录可能一次就过了,而一旦错误会反复尝试并且没有sleep等待,这将导致一秒钟可能会发起几百次上千次的尝试,
而多个进程并发时就容易观察到平均等待几十毫秒甚至几百毫秒的“library cache lock”了。因为会不断尝试,在数据库层面会累积而很容易观察到。
但是设置event 28401之后,一般不会有几十秒上百秒的单次等待了,因为单次递增的等待机制被绕过了。

总体来讲,数据库管理员应该尽快发现并解决错误的用户名密码登录问题(它们一般是因为数据库密码被更改而应用程序没有及时同步造成的),而不应该过度依赖event 28401。
因为无论从哪个角度来看,错误的用户名密码登录都是一个应用层面的异常问题,是应该被避免的。

星期一 六月 01, 2015

11gR2 RAC OCR磁盘组的换名重建恢复测试

11gR2 RAC OCR磁盘组的换名重建恢复测试


一、背景


根据文档1062983.1中的步骤恢复OCRreplace
voting disk
到新的磁盘组后,发现新磁盘组无法通过crsctl stat res -t查看。由于11gR2不支持srvctl add diskgroup目录,需要用crsctl add res ora.OCR.dg -type ora.diskgroup.type -file ocrdg.txt添加。


二、测试目的


删除虚拟机RACCRS物理磁盘后,使用OCR备份恢复到新的OCR磁盘组,看恢复后crsctl stat res –t是否可以列出新的OCR磁盘组,如果没有列出,手工增加磁盘组。


全文请下载附件(右键点击链接,“另存为”即可):11gR2 RAC OCR磁盘组的换名重建恢复测试





星期日 五月 31, 2015

使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4

        目前,绝大多数RAC环境都是UNIX/Linux平台,但Windows RAC由于易操作性其数量在增加,而相应的文档却比较少。人们搭建RAC测试环境的最大障碍是共享存储。在生产环境中,共享存储通常有SAN或高端NAS设备提供,但这些选择非常昂贵,显然不适合用来搭建测试环境学习RAC。使用VirtualBox您可以在一个机器上运行多个虚拟机(VMs),并允许您创建虚拟的共享磁盘,免去了使用昂贵共享存储的开销。因此这里使用VBox来做Win RAC的安装和升级演示。


详细请下载附件(右键点击链接,“另存为”即可):


使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4(1 of 2)


 使用VirtualBox搭建Windows8平台11.2.0.3 RAC并升级11.2.0.4(2 of 2)

星期日 八月 24, 2014

Data Guard - Snapshot Standby Database配置

概述

--------

一般情况下,物理standby数据库处于mount状态接收和应用主库的REDO日志,物理standby数据库不能对外提供访问。如果需要只读访问,那么可以临时以read-only的方式open物理备库,或者配置ACTIVE DATA GUARD,那么物理standby数据库可以进行只读(read-only)访问(比如报表业务查询),但是物理standby数据库不能进行读写操作(read-write)。

有些情况下,为了实现系统的压力测试或者Real Application Testing(RAT)或者其他读写操作测试,那么可以临时将物理standby数据库转换为snapshot standby数据库然后进行测试,因为snapshot standby数据库是独立于主库的,并且是可以进行读写操作(read-write)。测试过程中snapshot standby数据库正常接收主库的归档日志,保证主库的数据安全,但是不会应用这些日志,当压力测试结束后,可以非常简单的再将snapshot standby转换为物理standby数据库,继续同步主库日志。



配置

--------- 

1.物理standby配置闪回日志

SQL> Alter system set db_recovery_file_dest_size=500M;

System altered.



SQL> Alter system set db_recovery_file_dest='/u01/app/oracle/snapshot_standby';

System altered.



2.物理standby停止应用日志

SQL> alter database recover managed standby database cancel;

Database altered.



3.物理standby转换为snapshot standby,并且open snapshot standby

SQL> alter database convert to snapshot standby;

Database altered.



SQL> alter database open;   

Database altered.



检查snapshot standby数据库角色是SNAPSHOT STANDBY,open模式是READ WRITE:

SQL> select DATABASE_ROLE,name,OPEN_MODE from v$database;

DATABASE_ROLE    NAME      OPEN_MODE

---------------- --------- --------------------

SNAPSHOT STANDBY FSDB      READ WRITE



4.对snapshot standby数据库进行压力测试或者Real Application Testing(RAT)或者其他读写操作。



5.测试结束后,再将snapshot standby转换为physical standby,并且重新开始应用日志

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.



SQL> shutdown immediate;

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.



5.转换为物理standby后,查看备库角色是PHYSICAL STANDBY,open模式是MOUNTED

SQL> select DATABASE_ROLE,name,OPEN_MODE from v$database;

DATABASE_ROLE    NAME      OPEN_MODE

---------------- --------- --------------------

PHYSICAL STANDBY FSDB      MOUNTED



6.检查主库和物理备库日志是同步的

主库日志:

SQL> select ads.dest_id,max(sequence#) "Current Sequence",

           max(log_sequence) "Last Archived"

       from v$archived_log al, v$archive_dest ad, v$archive_dest_status ads

       where ad.dest_id=al.dest_id

       and al.dest_id=ads.dest_id

       and al.resetlogs_change#=(select max(resetlogs_change#) from v$archived_log )

       group by ads.dest_id;



   DEST_ID Current Sequence Last Archived

---------- ---------------- -------------

     1              361           361

     2              361           362



--备库日志

SQL>    select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"

      from (select thread# thrd, max(sequence#) almax

          from v$archived_log

          where resetlogs_change#=(select resetlogs_change# from v$database)

          group by thread#) al,

         (select thread# thrd, max(sequence#) lhmax

          from v$log_history

          where resetlogs_change#=(select resetlogs_change# from v$database)

          group by thread#) lh

     where al.thrd = lh.thrd;



    Thread Last Seq Received Last Seq Applied

---------- ----------------- ----------------


         1               361              361


参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:Data Guard - Snapshot Standby Database配置


星期二 六月 03, 2014

开启归档的模式,恢复没有备份的数据文件


场景:


1.数据库开启归档;


2.创建数据文件之后的所有归档日志都在线;


3.数据文件或者表空间没有进行过备份,数据库也没有全库备份,数据文件异常丢失;


步骤:


创建测试用的表空间:


SQL> create table test_b (id number(10)) tablespace bbb;


Table created.


SQL> insert into test_b values (1);


1 row created.


SQL> commit;


NAME


--------------------------------------------------------------------------------


    FILE#


----------


/opt/oracle/oradata/R11203/aaa.dbf


       10



/opt/oracle/oradata/R11203/bbb.dbf


       11




11 rows selected.


SQL> host


删除数据文件,模拟异常丢失


bash-4.2$ ls -al /opt/oracle/oradata/R11203/bbb.dbf


-rw-rw----   1 oracle    
dba        10493952 Apr  4 09:53
/opt/oracle/oradata/R11203/bbb.dbf


bash-4.2$ mv /opt/oracle/oradata/R11203/bbb.dbf
/opt/oracle/oradata/R11203/bbb.dbf.bak


bash-4.2$ sqlplus / as sysdba


SQL*Plus: Release 11.2.0.3.0 Production on Fri Apr 4
09:55:03 2014



Copyright (c) 1982, 2011, Oracle.  All rights
reserved.


Connected to:


Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -
64bit Production


With the Partitioning, OLAP, Data Mining and Real
Application Testing options


SQL> alter tablespace bbb read only;


alter tablespace bbb read only


*


ERROR at line 1:


ORA-01116: error in opening database file 11


ORA-01110: data file 11:
'/opt/oracle/oradata/R11203/bbb.dbf'


ORA-27041: unable to open file


HPUX-ia64 Error: 2: No such file or directory


Additional information: 3


SQL> shutdown immediate;


ORA-01116: error in opening database file 11


ORA-01110: data file 11:
'/opt/oracle/oradata/R11203/bbb.dbf'


ORA-27041: unable to open file


HPUX-ia64 Error: 2: No such file or directory


Additional information: 3


SQL> select status from v$instance;


STATUS


------------


OPEN


SQL> alter system switch logfile;


System altered.


SQL> /


System altered.


SQL> /


System altered.


SQL>/


System altered.


SQL> /


System altered.


SQL> /


System altered.


SQL>


停机


SQL> shutdown immediate;


ORA-01116: error in opening database file 11


ORA-01110: data file 11:
'/opt/oracle/oradata/R11203/bbb.dbf'


ORA-27041: unable to open file


HPUX-ia64 Error: 2: No such file or directory


Additional information: 3



SQL> shutdown abort;


ORACLE instance shut down.


把数据库启动到mount状态


SQL> startup mount;


ORACLE instance started.



Total System Global Area  329859072 bytes


Fixed
Size                 
2182336 bytes


Variable
Size            
285213504 bytes


Database
Buffers           37748736
bytes


Redo
Buffers               
4714496 bytes


Database mounted.


使用alter database create datafile <> as ....的方式,重建这个丢失的数据文件:



SQL> alter database create datafile 11;


Database altered.


通过归档日志和redo log对数据文件进行恢复


SQL> recover datafile 11;


Media recovery complete.


SQL> alter database open;


Database altered.


SQL> select * from test_b;



       ID


----------


        1

星期一 四月 28, 2014

Oracle的Central Inventory和Local inventory详解


很多朋友对Oracle的inventory信息不太了解以至遇到相关的问题不知道如何处理,这篇文章我们将详细讲解Oracle的Central Inventory (oraInventory)和Local Inventory (Oracle Home inventory)
首先我们通过查看$ opatch lsinventory的输出来抛出几个问题:
[oracle@dbnode1 OPatch]$ ./opatch lsinventory
Invoking OPatch 11.2.0.1.7
Oracle Interim Patch Installer version 11.2.0.1.7
Copyright (c) 2011, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory  <<<<<=====什么是Central Inventory?
   from           : /etc/oraInst.loc<<<<<=====oraInst.loc是什么文件,它有什么作用?如果它被删除掉了会怎么样?
OPatch version    : 11.2.0.1.7<<<<<=====这是OPatch版本?
OUI version       : 11.2.0.3.0<<<<<=====OUI version 这里OUI 版本是指的什么?  
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-03-23_21-03-24PM.log
Lsinventory Output file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2014-03-23_21-03-24PM.txt
--------------------------------------------------------------------------------
Installed Top-level Products (1):
Oracle Database 11g                                                  11.2.0.3.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
--------------------------------------------------------------------------------
OPatch succeeded.
这里OPatch version 就是Opatch的版本,它是不同于数据库版本的。
如果OPatch 版本过低那打patch时就会报错,不过这个问题很快可以通过查看patch的readme通过其指定的Note 下载最新的Opatch 来解决。
OUI version 就是安装的ORACLE_HOME的版本
言归正传,什么是Central Inventory (oraInventory)呢 ?
每一个安装了Oracle产品的操作系统上都至少有一个Central Inventory (oraInventory),他通过一个叫做inventory.xml的文件记录了在此操作系统上安装过的Oracle Homes等信息。
实际上Oracle就是通过Central Inventory (oraInventory) 来确定Oracle Home的位置,名称,是否是CRS_HOME及其他节点等信息的。

我们可以具体看一下inventory.xml的内容:
inventory.xml位置就在< Central Inventory >/ContentsXML/inventory.xml
例如:
[oracle@dbnode1 OPatch]$ cd /u01/app/oraInventory/ContentsXML/
[oracle@dbnode1 ContentsXML]$ ls
comps.xml  inventory.xml  libs.xml
[oracle@dbnode1 ContentsXML]$ cat inventory.xml
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2011, Oracle. All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>11.2.0.3.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/product/11.2.0/db_1" TYPE="O" IDX="1"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>
[oracle@dbnode1 ContentsXML]$ pwd
/u01/app/oraInventory/ContentsXML
这里我们只安装了一个ORACLE_HOME它的名字叫OraDb11g_home1,路径在/u01/app/oracle/product/11.2.0/db_1。
请注意这里TYPE="O" IDX="1"
TYPE="O"意思是这是一个ORACLE数据库的HOME,如果它后面还有CRS="true"这样的标记就表明这是一个CRS_HOME。
IDX="1" 意思就是该HOME是第一个安装的产品。
我们再看一个安装了CRS的inventory.xml输出来对比一下
[oracle@ ContentsXML]$ cat inventory.xml
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2011, Oracle. All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>11.2.0.3.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/11.2.0/grid" TYPE="O" IDX="1" CRS="true">
   <NODE_LIST>
      <NODE NAME="nascds10"/>
      <NODE NAME="nascds11"/>
   </NODE_LIST>
</HOME>
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/product/11.2.0/db_1" TYPE="O" IDX="2">
   <NODE_LIST>
      <NODE NAME="nascds10"/>
      <NODE NAME="nascds11"/>
   </NODE_LIST>
</HOME>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>
通过对比我们已经非常明显的看到inventory.xml 里记录了详细ORACLE_HOME信息。
问题是Oracle是如何知道< Central Inventory >在哪里的呢?
答案很多人可能已经猜到了就是opatch lsinventory里列出来的
from           : /etc/oraInst.loc
这个/etc/oraInst.loc是有专业名称的,它的名字就叫Central Inventory Pointer File。
这个指向文件在不同的操作系统上有不同的默认位置,例如:
Linux And AIX — /etc/oraInst.loc
Other Unix Platforms — /var/opt/oracle/oraInst.loc
Windows — The pointer is located in the registry key:
\\HKEY_LOCAL_MACHINE\\Software\Oracle\inst.loc
Opatch就是通过Central Inventory Pointer File找到< Central Inventory >的路径,然后读取ORACLE_HOME的详细信息的。
现在又有新的问题了?
1.我们是否可以删除Central Inventory Pointer File?或者如果Central Inventory Pointer File丢失了会怎么样?
2. Central Inventory丢失或者损坏了会怎么样?
3. 我们能否手工修改Central Inventory的内容?
我先回答这几个问题,然后通过几个实验来看一下具体的情况。
答案:
1.不能删除Central Inventory Pointer File,如果Central Inventory Pointer File丢失了可以手工重建该文件。如果Central Inventory Pointer File丢失或者损坏那么opatch的所有命令都将失败。
2.也不能删除Central Inventory的文件,如果Central Inventory的文件是损坏的,比如内容不完整,或者内容是错误的,都将导致opatch失败。Central Inventory在ORACLE_HOME完好的情况下可以通过重建的方式解决以上问题。
3.Oracle官方不support手工修改Central Inventory的内容。

请注意以下所有的实验都不要在生产环境操作,以免导致Inventory错误.
实验1: 模拟Central Inventory Pointer File丢失的场景
[root@dbnode1]# mv /etc/oraInst.loc /etc/oraInst.loc.bak  <<<<<<=====这里手工mv了oraInst.loc文件,实验结束后需要手工再mv 回来
[root@dbnode1]# exit
exit
[oracle@dbnode1]$ cd /u01/app/oracle/product/11.2.0/db_1/OPatch/
[oracle@dbnode1 OPatch]$ ./opatch lsinventory
Invoking OPatch 11.2.0.1.7
Oracle Interim Patch Installer version 11.2.0.1.7
Copyright (c) 2011, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : n/a
   from           :
OPatch version    : 11.2.0.1.7
OUI version       : 11.2.0.3.0
Log file location : n/a<<<<<<=========
OPatch cannot find a valid oraInst.loc file to locate Central Inventory. <<<<<<=========
OPatch failed with error code 104<<<<<<=========
[oracle@dbnode1 OPatch]$
通过这个实验我们看到当Oracle不能找到一个有效的Central Inventory Pointer File时Opatch以失败告终。
这个时候如果我们确定Central Inventory是完好无损的情况下,可以在不同平台对应的默认路径下手工创建或者编辑oraInst.loc 文件
例如在linux平台,正常的内容如下
$ cat /etc/oraInst.loc
inventory_loc=/u01/app/oraInventory
inst_group=oinstall
实验2: 模拟Central Inventory丢失的场景
[oracle@dbnode1 app]$ mv oraInventory oraInventory.bak<<<<<<=====这里手工删除了oraInventory
[oracle@dbnode1 app]$ ls
oracle  oraInventory.bak
[oracle@dbnode1 app]$ cd /u01/app/oracle/product/11.2.0/db_1/OPatch/
[oracle@dbnode1 OPatch]$ ./opatch lsinventory
Invoking OPatch 11.2.0.1.7
Oracle Interim Patch Installer version 11.2.0.1.7
Copyright (c) 2011, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.2.0.1.7
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-03-24_12-15-04PM.log
OPatch failed to locate Central Inventory.  <<<<<<=====报错无法加载Central Inventory.
Possible causes are:
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.
LsInventorySession failed: OPatch failed to locate Central Inventory.
Possible causes are:
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.
OPatch failed with error code 73<<<<<<=====
这个实验可以说明当Central Inventory 丢失时Opatch也是失败的。
实验3 模拟Central Inventory内容损坏
为实验目的我们手工修改ORACLE_HOME LOC成/u01/app/oracle/product/11.2.0/db_100 实际上这个目录是不存在的。但请注意手工修改inventory.xml的任何内容都是不support的。
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/product/11.2.0/db_100" TYPE="O" IDX="1"/>
[oracle@dbnode1 OPatch]$ cd /u01/app/oraInventory/ContentsXML/
[oracle@dbnode1 ContentsXML]$ cp inventory.xml inventory.xml.bak
[oracle@dbnode1 ContentsXML]$ ls
comps.xml  inventory.xml  inventory.xml.bak  libs.xml
[oracle@dbnode1 ContentsXML]$ vi inventory.xml
[oracle@dbnode1 ContentsXML]$ cat inventory.xml
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2011, Oracle. All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>11.2.0.3.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraDb11g_home1" LOC="/u01/app/oracle/product/11.2.0/db_100" TYPE="O" IDX="1"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>
[oracle@dbnode1 ContentsXML]$ /u01/app/oracle/product/11.2.0/db_1/OPatch/opatch lsinventory
Invoking OPatch 11.2.0.1.7
Oracle Interim Patch Installer version 11.2.0.1.7
Copyright (c) 2011, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.2.0.1.7
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-03-24_12-25-43PM.log
List of Homes on this system:
  Home name= OraDb11g_home1, Location= "/u01/app/oracle/product/11.2.0/db_100"
Inventory load failed... OPatch cannot load inventory for the given Oracle Home.<<<=========
Possible causes are:
   Oracle Home dir. path does not exist in Central Inventory
   Oracle Home is a symbolic link
   Oracle Home inventory is corrupted
LsInventorySession failed: OracleHomeInventory gets null oracleHomeInfo
OPatch failed with error code 73
Central Inventory 如果损坏或者丢失是可以重建的。
重建过程非常简单,也不需要停机。我们来看下面的实验
实验4 重建Central Inventory
[oracle@dbnode1 ~]$ cd /u01/app
[oracle@dbnode1 app]$ ls
oracle  oraInventory
[oracle@dbnode1 app]$ mv oraInventory oraInventory.bak
[oracle@dbnode1 app]$ opatch lsinventory
Oracle Interim Patch Installer version 11.2.0.3.6
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0/db_1/oraInst.loc
OPatch version    : 11.2.0.3.6
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-03-25_17-13-48PM_1.log
OPatch failed to locate Central Inventory.
Possible causes are:
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.
LsInventorySession failed: OPatch failed to locate Central Inventory.<<<==== Central Inventory 被删除了,这个报错就是期待的报错。
Possible causes are:
    The Central Inventory is corrupted
    The oraInst.loc file specified is not valid.
OPatch failed with error code 73<<<<<<<<<<<<<=================
[oracle@dbnode1 app]$ cd $ORACLE_HOME/oui/bin
[oracle@dbnode1 bin]$ pwd
/u01/app/oracle/product/11.2.0/db_1/oui/bin
[oracle@dbnode1 bin]$ ./runInstaller -silent -ignoreSysPrereqs -attachHome ORACLE_HOME="/u01/app/oracle/product/11.2.0/db_1" ORACLE_HOME_NAME="OraDb11g_home1"
Starting Oracle Universal Installer...
Checking swap space: must be greater than 500 MB.   Actual 2996 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /u01/app/oraInventory
'AttachHome' was successful.
[oracle@dbnode1 bin]$ opatch lsinventory
Oracle Interim Patch Installer version 11.2.0.3.6
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/11.2.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0/db_1/oraInst.loc
OPatch version    : 11.2.0.3.6
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-03-25_17-16-37PM_1.log
Lsinventory Output file location : /u01/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2014-03-25_17-16-37PM.txt
--------------------------------------------------------------------------------
Installed Top-level Products (1):
Oracle Database 11g                                                  11.2.0.3.0
There are 1 product(s) installed in this Oracle Home.
Interim patches (1) :
Patch  17540582     : applied on Mon Mar 24 17:08:31 CST 2014
Unique Patch ID:  16985511
Patch description:  "Database Patch Set Update : 11.2.0.3.9 (17540582)"
   Created on 7 Jan 2014, 03:01:22 hrs PST8PDT
Sub-patch  16902043; "Database Patch Set Update : 11.2.0.3.8 (16902043)"
Sub-patch  16619892; "Database Patch Set Update : 11.2.0.3.7 (16619892)"
Sub-patch  16056266; "Database Patch Set Update : 11.2.0.3.6 (16056266)"
Sub-patch  14727310; "Database Patch Set Update : 11.2.0.3.5 (14727310)"
Sub-patch  14275605; "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch  13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch  13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch  13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
   Bugs fixed:
     13593999, 10350832, 14138130, 12919564, 13561951, 14198511, 13588248
     13080778, 13804294, 16710324, 12873183, 14472647, 12880299, 13369579
   ...............
     13059165, 14062797, 12959852, 12345082, 16703112, 13890080, 17333198
     16450169, 12658411, 13780035, 14062793, 13038684, 16742095, 13742464
     14052474, 13060271, 13911821, 13457582, 7509451, 13791364, 12821418
     13502183, 13705338, 16794239, 15862024, 13554409, 13645917, 13103913, 12772404
--------------------------------------------------------------------------------
OPatch succeeded.
[oracle@dbnode1 bin]$ cd /u01/app
[oracle@dbnode1 app]$ ls -l
total 12
drwxrwxr-x 9 oracle oinstall 4096 Nov 24 23:25 oracle
drwxrwx--- 4 oracle oinstall 4096 Mar 25 17:16 oraInventory<<<<<<<==新创建的Central Inventory
drwxrwx--- 5 oracle oinstall 4096 Mar 24 17:12 oraInventory.bak
Central Inventory里只记录了Oracle的HOME信息,但是在这个HOME下打了哪些patch Oracle是怎么知道的呢?
答案就是Local Inventory (Oracle Home inventory)。
Local Inventory (Oracle Home inventory) 存在于每一个ORACLE_HOME中,它记录了这个HOME中的相关信息,比如这个HOME中包含的组件,打过的补丁集(patchset 信息),打过的小补丁和PSU等信息。这些信息被记录在Local Inventory 中的comps.xml文件。
ORACLE_HOME/inventory/ContentsXML/comps.xml
同样Local Inventory (Oracle Home inventory)里的任何文件都是不允许手工修改的。
一个重要的信息是Oracle的Local Inventory (Oracle Home inventory)如果丢失或者损坏时无法重建的,只能通过重新安装ORACLE软件的方式解决。

参考文章:
FAQs on Central Inventory and Oracle Home Inventory (Local Inventory) in Oracle RDBMS (Doc ID 564192.1)
Steps To Recreate Central Inventory(oraInventory) In RDBMS Homes (Doc ID 556834.1)
Steps to Recreate Central Inventory in Real Applications Clusters (Doc ID 413939.1)


参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖 "Oracle的Central Inventory和Local inventory详解 "




星期三 四月 02, 2014

Oracle数据库坏块(corruption)-物理坏块




概述

-------------

数据库坏块(corruption) 的类型可以按照坏块所属对象的不同,分为用户数据坏块,数据字典坏块,Undo坏块,控制文件坏块,Redo坏块,Lob坏块,index坏块等等;也可以按照坏块产生的原因,分为物理坏块(physical corruption)和逻辑坏块(logical corruption )。

本文主要讨论用户数据发生物理坏块(physical corruption)分析和解决方法。


物理坏块

-------------

常见的物理坏块(Physical Block Corruptions)有块头和块尾信息不一致(Fractured/Incomplete),checksum值无效,数据块信息全部为0等情况,并且可能伴随错误ORA-1578和ORA-1110



为了及时发现物理坏块和准确定位坏块产生的原因,oracle建议设置初始化参数DB_BLOCK_CHECKSUM=TYPICAL(默认值)。一般情况下,物理坏块是由于底层OS/disk系统错误/损坏,导致数据块被修改,数据块标志为坏块(corruption)。



Case分享

-------------

数据块的Checksum值无效是一种常见的物理坏块,当数据库初始化参数DB_BLOCK_CHECKSUM=TYPICAL(默认值)时,DBWR进程将数据块写入disk时会计算数据块的Checksum,并且将Checksum值记录在数据块的位置offset 16和17;当从disk读取该数据块时,oracle重新计算数据块的Checksum,并且与记录在数据块中的Checksum做异或运算(Xor),如果异或结果为非0,说明数据块被修改过,数据块为坏块(corruption)。



1. 当前数据库初始化参数配置DB_BLOCK_CHECKSUM=TYPICAL,因此从disk读取数据块时校验checksum:

SQL> show parameter DB_BLOCK_CHECKSUM



NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

db_block_checksum                    string      TYPICAL



2. 查询表dept时发现有坏块,报错信息ORA-1578和ORA-1110,坏块为file # 4, block # 133



SQL> select * from dept;

 select * from dept

*

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 4, block # 133)

ORA-01110: data file 4: '/u01/app/oracle/oradata/orcl/users01.dbf'



3. 出现以上错误的同时在alert log中也有详细错误信息,这些错误信息说明数据块(file # 4, block # 133)损坏的原因是checksum无效。数据块中记录的checksum值为0x8167(这个值是上一次DBWR写入磁盘时计算的),读取数据块时重新计算得到的checksum是0x8122,checksum值异或运算(Xor)的结果是0x45 (computed block checksum)。由于两次checksum值不同(即异或结果为非0),说明数据块被修改过,数据块为坏块(corruption)。



Alert log错误信息:

Hex dump of (file 4, block 133) in trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20892.trc

Corrupt block relative dba: 0x01000085 (file 4, block 133)

Bad check value found during multiblock buffer read  <<<<<<<<<<<<<< 说明坏块的原因是checksum无效

Data in bad block:

 type: 6 format: 2 rdba: 0x01000085

 last change scn: 0x0000.0023d69a seq: 0x5 flg: 0x06

 spare1: 0x0 spare2: 0x0 spare3: 0x0

 consistency value in tail: 0xd69a0605

 check value in block header: 0x8167   <<<<<<<<<<<<<< 数据块中记录的checksum值为0x8167

 computed block checksum: 0x45         <<<<<<<<<<<<<< 0x8167与0x8122异或运算(Xor)的结果是0x45

Reading datafile '/u01/app/oracle/oradata/orcl/users01.dbf' for corruption at rdba: 0x01000085 (file 4, block 133)

Reread (file 4, block 133) found same corrupt data (no logical check)

Sun Mar 23 22:53:40 2014

Corrupt Block Found

         TSN = 4, TSNAME = USERS

         RFN = 4, BLK = 133, RDBA = 16777349

         OBJN = 14343, OBJD = 14343, OBJECT = DEPT, SUBOBJECT = 

         SEGMENT OWNER = JAMES, SEGMENT TYPE = Table Segment         <<<<<<<<<<<<<< 坏块对应的object ID

Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20892.trc  (incident=182595):

ORA-01578: ORACLE data block corrupted (file # 4, block # 133)

ORA-01110: data file 4: '/u01/app/oracle/oradata/orcl/users01.dbf'



4.1 对应的orcl_ora_20892.trc中也有数据块的信息,其中数据块上记录的checksum值是0x8167(chkval)

Block dump from disk:

buffer tsn: 4 rdba: 0x01000085 (4/133)

scn: 0x0000.0023d69a seq: 0x05 flg: 0x06 tail: 0xd69a0605

frmt: 0x02 chkval: 0x8167 type: 0x06=trans data

Hex dump of block: st=0, typ_found=1


4.2 通过dd也查看数据块中记录的checksum值, offset 16,17 对应的是checksum值0x8167

$ dd if=/u01/app/oracle/oradata/orcl/users01.dbf bs=8192 count=1 skip=133 of=/tmp/dd133.out



$ od -x /tmp/dd133.out

0000000 a206 0000 0085 0100 d69a 0023 0000 0605

0000020 8167 0000 0001 0000 3807 0000 2fef 000c

^^^^



5. 修复数据坏块的方法可以通过备份恢复或者DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块。

5.1 方法#1 RMAN数据块恢复:

RMAN> run {blockrecover datafile 4 block 133;}



SQL> select * from dept;



    DEPTNO DNAME          LOC

---------- -------------- -------------

        10 ACCOUNTING     DALIAN

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON



5.2 方法#2 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块,然后将dept表中的其他数据导出重建表

SQL> alter session set db_file_multiblock_read_count=1;

SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('JAMES','DEPT'); 


SQL> create table dept_new as select * from dept;

参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:Oracle数据库坏块(corruption)-物理坏块"���





星期三 三月 26, 2014

也来谈谈tnsping


[Read More]

星期二 三月 25, 2014

如何安装11.2单机Grid Infrastructure(Oracle Restart)?

本文通过图示给出了安装单机的11.2 Grid Infrastructure (也称Oracle Restart)的步骤。


在11.2及之上,如果要使用ASM,必须安装集群件Grid Infrastructure; 在11.2之前,ASM 不属于集群件,可以单独安装ASM。

请下载:How_To_Install_Standalone_GI(OracleRestart).pdf

星期一 二月 10, 2014

RAC中误将数据文件创建在本地盘时的修正


用户创建表空间时误将数据文件放到了本地盘,重启数据库时一个实例启动不了,只能offline该表空间后启动数据库。现用户想知道怎样能把这个表空间数据文件中的数据恢复出来。

测试目的:验证RAC中误将数据文件创建在本地盘时的修复办法
环境说明:
两节点RAC,数据库名为db10g 版本10.2.0.5
使用了ASM作为共享存储解决方案。



1
,场景准备

1
)节点2:创建表空间test1,数据文件不放到ASM,而是放到本地盘:

SQL> create tablespace test1 datafile '/home/oracle/test1.dbf' size 10m;


Tablespace created.


SQL> select name,status from v$datafile;


NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


/home/oracle/test1.dbf

ONLINE



6 rows selected.


2
)节点2:在表空间test1中创建表没问题


SQL> create table test1 (id int) tablespace test1;


Table created.

SQL> create table test2 tablespace test1 as select * from dba_tables;


Table created.


3
)节点1:能查到表空间test1,但创建表报错

SQL> select name ,status from v$datafile;


NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


/home/oracle/test1.dbf

ONLINE



6 rows selected.


SQL> create table test1 (id int) tablespace test1;

create table test1 (id int) tablespace test1

*

ERROR at line 1:

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/home/oracle/test1.dbf'


4
)重启数据库,会发现节点1实例起不来,因为节点1无法读取节点2本地盘上的/home/oracle/test1.dbf

[oracle@rac10g2 ~]$ srvctl stop database -d db10g

[oracle@rac10g2 ~]$ srvctl start database -d db10g

PRKP-1001 : Error starting instance db10g1 on node rac10g1

CRS-0215: Could not start resource 'ora.db10g.db10g1.inst'.

[oracle@rac10g2 ~]$ crs_stat -t

Name          
Type          
Target    State    
Host        

------------------------------------------------------------

ora.db10g.db   application    ONLINE   
ONLINE    rac10g1     

ora....g1.inst application    ONLINE   
OFFLINE             
 

ora....g2.inst application    ONLINE   
ONLINE    rac10g2     

ora....SM1.asm application    ONLINE   
ONLINE    rac10g1     

ora....G1.lsnr application    ONLINE   
ONLINE    rac10g1     

ora....0g1.gsd application    ONLINE   
ONLINE    rac10g1     

ora....0g1.ons application    ONLINE   
ONLINE    rac10g1     

ora....0g1.vip application    ONLINE   
ONLINE    rac10g1     

ora....SM2.asm application    ONLINE   
ONLINE    rac10g2     

ora....G2.lsnr application    ONLINE   
ONLINE    rac10g2     

ora....0g2.gsd application    ONLINE   
ONLINE    rac10g2     

ora....0g2.ons application    ONLINE   
ONLINE    rac10g2     

ora....0g2.vip application    ONLINE   
ONLINE    rac10g2   


2
,处理过程


由于该过程中需要从本地盘把数据文件迁移到ASM共享存储,ASM文件的访问无法通过操作系统级别直接进行。


10gR2中,我们可以使用RMAN命令备份和恢复ASM文件,使用ASMCMD命令可以浏览和操纵目录结构。不过,Oracle 10g包中的DBMS_FILE_TRANSFER是处理ASM的另一种方式。 DBMS_FILE_TRANSFER可以在同一台Oracle服务器上或两台Oracle 服务器之间复制文件。它使用目录对象来指定源目录和目的目录,因为目录对象支持ASM路径名称,所以DBMS_FILE_TRANSFER也支持ASM路径名。这使得从常规文件系统的ASM存储区移入和移出文件变得十分简单,使用它可以完成如下的迁移:


ASM->ASMASM->OS
Flie
OS File->ASMOS
File->OS File



建错的表空间test1数据文件在节点2,所以只能从节点2上打开。可在节点2上将表空间offline之后使用dbms_file_transfer将数据文件移到ASM共享存储(如使用的是集群文件系统,直接拷贝数据文件即可)


1)为两个数据文件路径创建目录


节点2:创建两个directory,一个指向本地盘该数据文件目录;一个指向ASM数据文件目录。

SQL> create directory test1 as '/home/oracle';


Directory created.


SQL> create directory test2 as '+DG/db10g/datafile';


Directory created.


2
offline表空间


节点2offline表空间test1

SQL> alter tablespace test1 offline;


Tablespace altered.


3
)拷贝数据文件到ASM


节点2:使用dbms_file_transfer拷贝该数据文件到ASM

SQL> exec
dbms_file_transfer.copy_file('TEST1','test1.dbf','TEST2','test1.dbf');


PL/SQL procedure successfully completed.


4
)修改控制文件中的数据文件路径


节点2

SQL> alter database rename file '/home/oracle/test1.dbf' to
'+DG/db10g/datafile/test1.dbf'

SQL> /


Database altered.


5
online表空间test1


节点2online表空间test1

SQL> alter tablespace test1 online;


Tablespace altered.


6
)启动实例1

[oracle@rac10g2 ~]$ srvctl start instance -d db10g -i db10g1

[oracle@rac10g2 ~]$ crs_stat -t

Name          
Type          
Target    State    
Host        

------------------------------------------------------------

ora.db10g.db   application    ONLINE   
ONLINE    rac10g1     

ora....g1.inst application    ONLINE   
ONLINE    rac10g1     

ora....g2.inst application    ONLINE   
ONLINE    rac10g2     

ora....SM1.asm application    ONLINE   
ONLINE    rac10g1     

ora....G1.lsnr application    ONLINE   
ONLINE    rac10g1     

ora....0g1.gsd application    ONLINE   
ONLINE    rac10g1     

ora....0g1.ons application    ONLINE   
ONLINE    rac10g1     

ora....0g1.vip application    ONLINE   
ONLINE    rac10g1     

ora....SM2.asm application    ONLINE   
ONLINE    rac10g2     

ora....G2.lsnr application    ONLINE   
ONLINE    rac10g2     

ora....0g2.gsd application    ONLINE   
ONLINE    rac10g2     

ora....0g2.ons application    ONLINE   
ONLINE    rac10g2     

ora....0g2.vip application    ONLINE   
ONLINE    rac10g2     


7
)节点1:检查数据文件状态和表空间内数据

SQL> select name ,status from v$datafile;


NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

--------------------------------------------------------------------------------

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


+DG/db10g/datafile/test1.dbf

ONLINE



6 rows selected.


SQL> select count(*) from test2;


  COUNT(*)

----------

      1522 




3、备注


以上迁移数据文件时是采用 dbms_file_transfer.copy_file迁移数据文件的方法,也可以使用RMAN来做:




SQL>select tablespace_name,file_name,status,online_status from
dba_data_files;

需要对表空间进行OFFLINE
登录RMAN

 RMAN> sql "alter tablespace test1 offline";


  RMAN> copy datafile '/home/oracle/test1.dbf' to
'+DG/rac10g/datafile/test1.dbf';




SQL> alter database rename file '/home/oracle/test1.dbf' to
'+DG/rac10g/datafile/test1.dbf';


SQL> alter tablespace test1 online;



参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"测试:RAC中误将数据文件创建在本地盘时的修正"

星期四 十二月 05, 2013

12c GI/RAC 安装文档

最近,很多读者希望我们共享一份12c GI/RAC的安装文档,所以花了一些时间做了一些测试,写了这篇文档。希望对大家安装12c 集群有所帮助,同时,了解些12c 的新特性。


这篇文档包含了12c GI/RAC step-by-step的安装文档,同时也包含了使用dbca 创建数据库的过程。另外,也对安装过程中涉及到的12c 新特性和一些其他的12c 新特性做了简单的介绍。


注意: 这篇文章只是为了向大家展示12c GI/RAC的安装过程,而且以测试为目的。如果您希望以此文档作为您的生产系统安装文档,请进行充分的测试并根据需要进行修改。


OS:OEL 6.3 64-bit 12c 已经不再支持32位操作系统了)


版本 12.1


节点数: 3


详细的安装文档,请在这里下载。 

About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 五月 2016
星期日星期一星期二星期三星期四星期五星期六
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
今天