代入表格名後，可以找到其他有引用到本表格欄位的外鍵。
SELECT table_name, constraint_name, r_constraint_name, status
FROM user_constraints
- 9月 13 週六 201414:38
查看Oracle資料庫表格的外鍵(foreign key)關係
代入表格名後，可以找到其他有引用到本表格欄位的外鍵。
SELECT table_name, constraint_name, r_constraint_name, status
FROM user_constraints
- 9月 13 週六 201414:37
oracle index使用
- 9月 13 週六 201414:35
oracle字元問題 參考:http://f.dataguru.cn/thread-194447-1-1.html
http://f.dataguru.cn/thread-194447-1-1.html
【前言】使用[url=]oracle[/url]的过程中，出现汉字的时候总是出现乱码现象，疑惑好久。今天决心把字符集的问题彻底搞清楚。下面将通过迭代的方法，由字符集的基本概念逐层深入并过渡到oracle问题上。
1. 字符集1） 常用的字符集：
单字节编码分为：7位编码和8位编码
US7ASCII：单字节7位编码，定义了128个符号，不支持中文。
WE8ISO8859P1：单字节8位编码字符集。
多字节编码分为固定长度编码和变长编码
ZHS16GBK：双字节字符集ZHS16GBK中，编码长度固定，一个中文汉字是一个字符，一个英文字母也是一个字符，所以他们俩占的存储空间一样大，都是两个字节！
GB18030：收录了所有汉字，本标准收录的字符分别以单字节、双字节和四字节编码。
UNICODE:一种集合了所有字符的集合，为变长长度。
UTF-8：UNICODE的一种实现方式，在UNICODE上做了改动，字符分别以1-4个字节编码。
2） UTF-8与UNICODE的深入区别
Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位(100111000100101)，也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。
这里就有两个严重的问题：
第一个问题：如何才能区别unicode和ascii?计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？
第二个问题：我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的
为了解决这两个问题，UTF-8就被创造出来了。
UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单，只有二条：
1)对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的（一个字节编码）。
2)对于n字节的符号(n>1)，第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
下表总结了编码规则，字母x表示可用编码的位。
Unicode符号范围| UTF-8编码方式
(十六进制) | (二进制)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
下面，还是以汉字“严”为例，演示如何实现UTF-8编码。
已知“严”的unicode是4E25(100111000100101)，根据上表，可以发现4E25处在第三行的范围内(0000 0800-0000 FFFF)，因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。
3） 接下来我们直接、真实的来感受一下字符与编码之间的对应关系
在[url=]Windows[/url]平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。
里面有四个选项：ANSI，Unicode，Unicode big endian和UTF-8。
1)ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码(只针对Windows简体中文版，如果是繁体中文版会采用Big5码)。
2)Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
3)Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。
4)UTF-8编码，也就是上一节谈到的编码方法。
选择完”编码方式“后，点击”保存“按钮，文件的编码方式就立刻转换好了。
然后，用文本编辑[url=]软件[/url]UltraEdit（很容易下载到的一个文本编辑软件）中的”十六进制功能“，观察该文件的内部编码方式。
1)ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。
2)Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。
3)Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。
4)UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。
后面部分说了这么多，只是想对字符集有一个更立体的认识，对后续内容的也更容易理解。
4） 乱码问题
将以UTF-8编码的“严”字，转换为US7ASCII编码，因为US7ASCII编码字符集中没有“严”这个字符。于是将“严”转换为目标字符集（US7ASCII）中的一个特殊字符（称为“替换字符”）。比如在这里我们可以将？作为替换字符，所以“严”就转换为了“？”，出现了信息的丢失。这里只是概括的说明一下，后续会针对实际情况进行分析。
2. ORACLE字符集问题
关于oracle应用中的字符集问题，涉及到三个方面：①操作系统的字符集②登陆客户端的字符集③[url=]数据库[/url]的字符集。下面将依次介绍各自字符集的设定所起到的作用。然后通过[url=]实验[/url]来进行模拟验证。
1） 文字介绍
操作系统字符集：当你在应用程序中（例如sql*plus）输入数据，此时数据的编码格式是由操作系统的字符集决定。
数据库字符集：我们在创建数据库时，需要考虑的一个问题就是选择什么字符集与国家字符集（通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）。考虑这个问题，我们必须要清楚数据库中都需要存储什么数据，如果只需要存储英文信息，那么选择US7ASCII作为字符集就可以；但是如果要存储中文，那么我们就需要选择能够支持中文的字符集（如ZHS16GBK）；如果需要存储多国语言文字，那就要选择UTF8了。数据库字符集的确定，实际上说明这个数据库所能处理的字符的集合及其编码方式，由于字符集选定后再进行更改会有诸多的限制，所以在数据库创建时一定要考虑清楚后再选择。而我们许多朋友在创建数据库时，不考虑清楚，往往选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，所以用这种字符集存储汉字信息从原则上说就是错误的。虽然在有些时候选用这种字符集好象也能正常使用，但它会给数据库的使用与维护带来一系列的麻烦，在后面的迭代过程中我们将深入分析。
【前言】使用[url=]oracle[/url]的过程中，出现汉字的时候总是出现乱码现象，疑惑好久。今天决心把字符集的问题彻底搞清楚。下面将通过迭代的方法，由字符集的基本概念逐层深入并过渡到oracle问题上。
1. 字符集1） 常用的字符集：
单字节编码分为：7位编码和8位编码
US7ASCII：单字节7位编码，定义了128个符号，不支持中文。
WE8ISO8859P1：单字节8位编码字符集。
多字节编码分为固定长度编码和变长编码
ZHS16GBK：双字节字符集ZHS16GBK中，编码长度固定，一个中文汉字是一个字符，一个英文字母也是一个字符，所以他们俩占的存储空间一样大，都是两个字节！
GB18030：收录了所有汉字，本标准收录的字符分别以单字节、双字节和四字节编码。
UNICODE:一种集合了所有字符的集合，为变长长度。
UTF-8：UNICODE的一种实现方式，在UNICODE上做了改动，字符分别以1-4个字节编码。
2） UTF-8与UNICODE的深入区别
Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位(100111000100101)，也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。
这里就有两个严重的问题：
第一个问题：如何才能区别unicode和ascii?计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？
第二个问题：我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的
为了解决这两个问题，UTF-8就被创造出来了。
UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单，只有二条：
1)对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的（一个字节编码）。
2)对于n字节的符号(n>1)，第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
下表总结了编码规则，字母x表示可用编码的位。
Unicode符号范围| UTF-8编码方式
(十六进制) | (二进制)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
下面，还是以汉字“严”为例，演示如何实现UTF-8编码。
已知“严”的unicode是4E25(100111000100101)，根据上表，可以发现4E25处在第三行的范围内(0000 0800-0000 FFFF)，因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。
3） 接下来我们直接、真实的来感受一下字符与编码之间的对应关系
在[url=]Windows[/url]平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。
里面有四个选项：ANSI，Unicode，Unicode big endian和UTF-8。
1)ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码(只针对Windows简体中文版，如果是繁体中文版会采用Big5码)。
2)Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
3)Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。
4)UTF-8编码，也就是上一节谈到的编码方法。
选择完”编码方式“后，点击”保存“按钮，文件的编码方式就立刻转换好了。
然后，用文本编辑[url=]软件[/url]UltraEdit（很容易下载到的一个文本编辑软件）中的”十六进制功能“，观察该文件的内部编码方式。
1)ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。
2)Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。
3)Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。
4)UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。
后面部分说了这么多，只是想对字符集有一个更立体的认识，对后续内容的也更容易理解。
4） 乱码问题
将以UTF-8编码的“严”字，转换为US7ASCII编码，因为US7ASCII编码字符集中没有“严”这个字符。于是将“严”转换为目标字符集（US7ASCII）中的一个特殊字符（称为“替换字符”）。比如在这里我们可以将？作为替换字符，所以“严”就转换为了“？”，出现了信息的丢失。这里只是概括的说明一下，后续会针对实际情况进行分析。
2. ORACLE字符集问题
关于oracle应用中的字符集问题，涉及到三个方面：①操作系统的字符集②登陆客户端的字符集③[url=]数据库[/url]的字符集。下面将依次介绍各自字符集的设定所起到的作用。然后通过[url=]实验[/url]来进行模拟验证。
1） 文字介绍
操作系统字符集：当你在应用程序中（例如sql*plus）输入数据，此时数据的编码格式是由操作系统的字符集决定。
数据库字符集：我们在创建数据库时，需要考虑的一个问题就是选择什么字符集与国家字符集（通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）。考虑这个问题，我们必须要清楚数据库中都需要存储什么数据，如果只需要存储英文信息，那么选择US7ASCII作为字符集就可以；但是如果要存储中文，那么我们就需要选择能够支持中文的字符集（如ZHS16GBK）；如果需要存储多国语言文字，那就要选择UTF8了。数据库字符集的确定，实际上说明这个数据库所能处理的字符的集合及其编码方式，由于字符集选定后再进行更改会有诸多的限制，所以在数据库创建时一定要考虑清楚后再选择。而我们许多朋友在创建数据库时，不考虑清楚，往往选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，所以用这种字符集存储汉字信息从原则上说就是错误的。虽然在有些时候选用这种字符集好象也能正常使用，但它会给数据库的使用与维护带来一系列的麻烦，在后面的迭代过程中我们将深入分析。
- 9月 13 週六 201414:35
启动dbconsole遇到的timezone问题
發生問題敘述:
TZ set to US/Eastern
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
TZ set to US/Eastern
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
- 9月 13 週六 201414:31
ORA-19502: write error on file "/oradata/ignt/ignite_egvsql01_d02.dbf", block number 334080 (block size=8192) & ORA-27072
ORA-19502错误原因：
一般是磁盤空間不足導致。用df命令查看磁盤空間
[root@gsp ignt]# df -h
- 9月 13 週六 201414:31
ORA-01950: no privileges on tablespace 'USERS'錯誤解決方法
SQL> create user lxy identified by lxy default tablespace users;
User created.
SQL> grant create session,alter session,create table,create view,
2 create synonym,create cluster,create database link,create sequence,
User created.
SQL> grant create session,alter session,create table,create view,
2 create synonym,create cluster,create database link,create sequence,
- 9月 13 週六 201414:30
LGWR CHECKPOINT時機
LGWR動作時機，說明如下：
當使用者下了 Commit指令。
LGWR 每隔 3 秒會起來檢查重作日誌緩衝區的目前使用量，當剩餘不到 2/3，
就會寫回線上重作日誌檔案。
當使用者下了 Commit指令。
LGWR 每隔 3 秒會起來檢查重作日誌緩衝區的目前使用量，當剩餘不到 2/3，
就會寫回線上重作日誌檔案。
- 9月 13 週六 201414:28
FRA 2G滿了 加到8G
oracle10g的 archive log是保存在flash area(FRA)中的，如果你在建立資料庫是使用預設，那flash area是2G，空間滿了後就無法archive了
- 9月 13 週六 201414:26
查看表中commit資料的scn 並回復
http://blog.roodo.com/mywork/archives/1684525.html
有關scn值就是記錄在這個table裡
有關scn值就是記錄在這個table裡
SQL> desc flashback_transaction_query;
Name Type Nullable Default Comments
---------------- -------------- -------- ------- -----------------------------------------
XID RAW(8) Y Transaction identifier
START_SCN NUMBER Y Transaction start SCN
START_TIMESTAMP DATE Y Transaction start timestamp
COMMIT_SCN NUMBER Y Transaction commit SCN
COMMIT_TIMESTAMP DATE Y Transaction commit timestamp
LOGON_USER VARCHAR2(30) Y Logon user for transaction
UNDO_CHANGE# NUMBER Y 1-based undo change number
OPERATION VARCHAR2(32) Y forward operation for this undo
TABLE_NAME VARCHAR2(256) Y table name to which this undo applies
TABLE_OWNER VARCHAR2(32) Y owner of table to which this undo applies
ROW_ID VARCHAR2(19) Y rowid to which this undo applies
UNDO_SQL VARCHAR2(4000) Y SQL corresponding to this undo
- 9月 13 週六 201414:22
多種非完整復原方法&基於SCN回復
http://blog.csdn.net/leshami/article/details/9253867
-->创建测试用表并插入记录
10:07:01 SQL> create table t2(id varchar2(10), dt varchar2(20));
10:07:57 SQL> insert into t2 select 'Robinson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:08:15 SQL> commit;
10:08:18 SQL> alter system archive log current; -->对当前日志进行归档
-->下面的查询可知产生新的归档日志29
10:08:28 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
------------------------------------------------------------ ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
-->应证归档日志中包含记录Robinson
10:09:53 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc | grep "Robinson"
Robinson
--->第二次插入记录
10:10:48 SQL> insert into t2 select 'Jackson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:11:27 SQL> commit;
10:11:30 SQL> alter system archive log current;
10:11:47 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
---------------------------------------------------------- ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc 30 A 20130705 10:11:47
10:12:17 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc | grep "Jackson"
Jackson
-->查看当前数据库的SCN
10:12:34 SQL> select name,current_scn from v$database;
NAME CURRENT_SCN
------------------------------ -----------
ORADB 1365679
--->第三次插入记录
10:15:07 SQL> insert into t2 select 'Winson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:15:47 SQL> commit;
10:21:18 SQL> alter system switch logfile;
--->第四次插入记录
10:22:53 SQL> insert into t2 select 'LastRecord',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:23:44 SQL> commit;
10:23:47 SQL> select * from t2;
ID DT
---------- --------------------
Robinson 20130705 10:08:15
Jackson 20130705 10:11:27
Winson 20130705 10:15:47
LastRecord 20130705 10:23:44
10:23:52 SQL> alter system switch logfile;
-->下面是最终的归档日志情况
10:24:00 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
------------------------------------------------------------ ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc 30 A 20130705 10:11:47
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc 31 A 20130705 10:21:53
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_32_8xdcl0rx_.arc 32 A 20130705 10:24:00
10:24:12 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc | grep "Winson"
Winson
--->最后一次插入记录
10:25:16 SQL> insert into t2 select 'Completed',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:26:20 SQL> commit;
-->此时数据库当前的redo log并没有归档，因此插入的数据位于联机日志
10:27:40 SQL> ho strings /u02/DB/oradb/redo/redo03.log | grep "Completed"
Completed
--->下面列出完成的记录与日志对照关系
SQL> select * from t2;
ID DT 对应的归档日志 对应的sequence
---------- -------------------- ------------------------ --------------
Robinson 20130705 10:08:15 o1_mf_1_29_8xdbnqx9_.arc 29
Jackson 20130705 10:11:27 o1_mf_1_30_8xdbv338_.arc 30
Winson 20130705 10:15:47 o1_mf_1_31_8xdcg1wc_.arc 31
LastRecord 20130705 10:23:44 o1_mf_1_32_8xdcl0rx_.arc 32
Completed 20130705 10:26:20 redo03.log
2、实施不完全恢复
a、基于时间点的不完全恢复
[oracle@node1 ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Fri Jul 5 10:28:53 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORADB (DBID=2557712192)
RMAN> run{
2> shutdown immediate;
3> startup mount;
4> set until time "to_date('20130705 10:09:53','yyyymmdd hh24:mi:ss')";
5> restore database;
6> recover database;
7> }
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 263639040 bytes
executing command: SET until clause
Starting restore at 20130705 10:33:36
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=24 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore ---->启动数据文件还原
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/DB/oradb/oradata/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u02/DB/oradb/oradata/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /u02/rman/full_ORADB_04odvgv7_1_1
channel ORA_DISK_1: piece handle=/u02/rman/full_ORADB_04odvgv7_1_1 tag=FULL_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /u02/DB/oradb/oradata/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u02/DB/oradb/oradata/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u02/DB/oradb/oradata/example01.dbf
channel ORA_DISK_1: reading from backup piece /u02/rman/full_ORADB_05odvgv7_1_1
channel ORA_DISK_1: piece handle=/u02/rman/full_ORADB_05odvgv7_1_1 tag=FULL_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45 --->完成数据文件还原
Finished restore at 20130705 10:35:28
Starting recover at 20130705 10:35:29 --->启动数据恢复
using channel ORA_DISK_1
starting media recovery
---->下面提示归档日志已经存在，是由于我们备份归档日志后并没有对其清除
archived log for thread 1 with sequence 27 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc
archived log for thread 1 with sequence 28 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc
archived log for thread 1 with sequence 29 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc
archived log for thread 1 with sequence 30 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc thread=1 sequence=27 --->列出日志对应的sequence
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc thread=1 sequence=28
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc thread=1 sequence=29
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc thread=1 sequence=30
media recovery complete, elapsed time: 00:00:09 --->介质恢复完成,可以看到介质恢复，日志apply到了30(不包含sequence 30的内容)
Finished recover at 20130705 10:35:42 --->完成恢复
RMAN> alter database open resetlogs; --->手动open resetlogs
database opened
RMAN> host;
[oracle@node1 ~]$ more query_t2.sh
#!/bin/bash
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
export ORACLE_SID=oradb
sqlplus -S /nolog <<EOF
connect scott/tiger
select * from scott.t2;
exit;
EOF
exit
-->验证结果，记录Robinson已经被恢复
[oracle@node1 ~]$ ./query_t2.sh
ID DT
---------- --------------------
Robinson 20130705 10:08:15
[oracle@node1 ~]$ exit
exit
host command complete
-->新的incarnation已经被产生，为3
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORADB 2557712192 PARENT 1 20090813 23:00:48
2 2 ORADB 2557712192 PARENT 754488 20130111 17:37:07
3 3 ORADB 2557712192 CURRENT 1365530 20130705 10:37:15
b、基于SCN的不完全恢复
RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> reset database to incarnation 2; --->在此需要reset incarnation
database reset to incarnation 2
RMAN> run{
2> set until scn 1365679;
3> restore database;
4> recover database;
5> alter database open resetlogs;}
executing command: SET until clause
Starting restore at 20130705 11:01:14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
......................
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 20130705 11:03:05
Starting recover at 20130705 11:03:06
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 27 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc
.............................
archived log for thread 1 with sequence 31 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc thread=1 sequence=27
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc thread=1 sequence=28
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc thread=1 sequence=29
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc thread=1 sequence=30 --->该日志包含记录Jackson
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc thread=1 sequence=31
media recovery complete, elapsed time: 00:00:10 --->此时apply到了31(不包含sequence 31的内容)
Finished recover at 20130705 11:03:19
database opened
RMAN> host;
-->验证结果，记录Jackson已经被恢复
[oracle@node1 ~]$ ./query_t2.sh
ID DT
---------- --------------------
Robinson 20130705 10:08:15
Jackson 20130705 10:11:27
-->创建测试用表并插入记录
10:07:01 SQL> create table t2(id varchar2(10), dt varchar2(20));
10:07:57 SQL> insert into t2 select 'Robinson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:08:15 SQL> commit;
10:08:18 SQL> alter system archive log current; -->对当前日志进行归档
-->下面的查询可知产生新的归档日志29
10:08:28 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
------------------------------------------------------------ ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
-->应证归档日志中包含记录Robinson
10:09:53 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc | grep "Robinson"
Robinson
--->第二次插入记录
10:10:48 SQL> insert into t2 select 'Jackson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:11:27 SQL> commit;
10:11:30 SQL> alter system archive log current;
10:11:47 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
---------------------------------------------------------- ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc 30 A 20130705 10:11:47
10:12:17 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc | grep "Jackson"
Jackson
-->查看当前数据库的SCN
10:12:34 SQL> select name,current_scn from v$database;
NAME CURRENT_SCN
------------------------------ -----------
ORADB 1365679
--->第三次插入记录
10:15:07 SQL> insert into t2 select 'Winson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:15:47 SQL> commit;
10:21:18 SQL> alter system switch logfile;
--->第四次插入记录
10:22:53 SQL> insert into t2 select 'LastRecord',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:23:44 SQL> commit;
10:23:47 SQL> select * from t2;
ID DT
---------- --------------------
Robinson 20130705 10:08:15
Jackson 20130705 10:11:27
Winson 20130705 10:15:47
LastRecord 20130705 10:23:44
10:23:52 SQL> alter system switch logfile;
-->下面是最终的归档日志情况
10:24:00 SQL> SELECT name,sequence# seq#,status,completion_time FROM v$archived_log where sequence#>=28;
NAME SEQ# S COMPLETION_TIME
------------------------------------------------------------ ---- - -----------------
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc 28 A 20130705 10:03:36
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc 29 A 20130705 10:08:23
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc 30 A 20130705 10:11:47
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc 31 A 20130705 10:21:53
/u02/DB/oradb/arch/2013_07_05/o1_mf_1_32_8xdcl0rx_.arc 32 A 20130705 10:24:00
10:24:12 SQL> ho strings /u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc | grep "Winson"
Winson
--->最后一次插入记录
10:25:16 SQL> insert into t2 select 'Completed',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
10:26:20 SQL> commit;
-->此时数据库当前的redo log并没有归档，因此插入的数据位于联机日志
10:27:40 SQL> ho strings /u02/DB/oradb/redo/redo03.log | grep "Completed"
Completed
--->下面列出完成的记录与日志对照关系
SQL> select * from t2;
ID DT 对应的归档日志 对应的sequence
---------- -------------------- ------------------------ --------------
Robinson 20130705 10:08:15 o1_mf_1_29_8xdbnqx9_.arc 29
Jackson 20130705 10:11:27 o1_mf_1_30_8xdbv338_.arc 30
Winson 20130705 10:15:47 o1_mf_1_31_8xdcg1wc_.arc 31
LastRecord 20130705 10:23:44 o1_mf_1_32_8xdcl0rx_.arc 32
Completed 20130705 10:26:20 redo03.log
2、实施不完全恢复
a、基于时间点的不完全恢复
[oracle@node1 ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Fri Jul 5 10:28:53 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORADB (DBID=2557712192)
RMAN> run{
2> shutdown immediate;
3> startup mount;
4> set until time "to_date('20130705 10:09:53','yyyymmdd hh24:mi:ss')";
5> restore database;
6> recover database;
7> }
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 263639040 bytes
executing command: SET until clause
Starting restore at 20130705 10:33:36
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=24 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore ---->启动数据文件还原
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u02/DB/oradb/oradata/system01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u02/DB/oradb/oradata/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /u02/rman/full_ORADB_04odvgv7_1_1
channel ORA_DISK_1: piece handle=/u02/rman/full_ORADB_04odvgv7_1_1 tag=FULL_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to /u02/DB/oradb/oradata/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u02/DB/oradb/oradata/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u02/DB/oradb/oradata/example01.dbf
channel ORA_DISK_1: reading from backup piece /u02/rman/full_ORADB_05odvgv7_1_1
channel ORA_DISK_1: piece handle=/u02/rman/full_ORADB_05odvgv7_1_1 tag=FULL_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45 --->完成数据文件还原
Finished restore at 20130705 10:35:28
Starting recover at 20130705 10:35:29 --->启动数据恢复
using channel ORA_DISK_1
starting media recovery
---->下面提示归档日志已经存在，是由于我们备份归档日志后并没有对其清除
archived log for thread 1 with sequence 27 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc
archived log for thread 1 with sequence 28 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc
archived log for thread 1 with sequence 29 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc
archived log for thread 1 with sequence 30 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc thread=1 sequence=27 --->列出日志对应的sequence
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc thread=1 sequence=28
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc thread=1 sequence=29
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc thread=1 sequence=30
media recovery complete, elapsed time: 00:00:09 --->介质恢复完成,可以看到介质恢复，日志apply到了30(不包含sequence 30的内容)
Finished recover at 20130705 10:35:42 --->完成恢复
RMAN> alter database open resetlogs; --->手动open resetlogs
database opened
RMAN> host;
[oracle@node1 ~]$ more query_t2.sh
#!/bin/bash
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
export ORACLE_SID=oradb
sqlplus -S /nolog <<EOF
connect scott/tiger
select * from scott.t2;
exit;
EOF
exit
-->验证结果，记录Robinson已经被恢复
[oracle@node1 ~]$ ./query_t2.sh
ID DT
---------- --------------------
Robinson 20130705 10:08:15
[oracle@node1 ~]$ exit
exit
host command complete
-->新的incarnation已经被产生，为3
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORADB 2557712192 PARENT 1 20090813 23:00:48
2 2 ORADB 2557712192 PARENT 754488 20130111 17:37:07
3 3 ORADB 2557712192 CURRENT 1365530 20130705 10:37:15
b、基于SCN的不完全恢复
RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> reset database to incarnation 2; --->在此需要reset incarnation
database reset to incarnation 2
RMAN> run{
2> set until scn 1365679;
3> restore database;
4> recover database;
5> alter database open resetlogs;}
executing command: SET until clause
Starting restore at 20130705 11:01:14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
......................
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 20130705 11:03:05
Starting recover at 20130705 11:03:06
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 27 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc
.............................
archived log for thread 1 with sequence 31 is already on disk as file /u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_27_8xd9c0f0_.arc thread=1 sequence=27
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_28_8xdbcrht_.arc thread=1 sequence=28
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_29_8xdbnqx9_.arc thread=1 sequence=29
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_30_8xdbv338_.arc thread=1 sequence=30 --->该日志包含记录Jackson
archived log file name=/u02/DB/oradb/arch/2013_07_05/o1_mf_1_31_8xdcg1wc_.arc thread=1 sequence=31
media recovery complete, elapsed time: 00:00:10 --->此时apply到了31(不包含sequence 31的内容)
Finished recover at 20130705 11:03:19
database opened
RMAN> host;
-->验证结果，记录Jackson已经被恢复
[oracle@node1 ~]$ ./query_t2.sh
ID DT
---------- --------------------
Robinson 20130705 10:08:15
Jackson 20130705 10:11:27
