wallimn
- 浏览: 5174593 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
-
silence19841230：
先拿走看看
SpringBoot2.0开发WebSocket应用完整示例 -
wallimn：
masuweng 写道发下源码下载地址吧!三个相关文件打了个包 ...
SpringBoot2.0开发WebSocket应用完整示例 -
masuweng：
发下源码下载地址吧!
SpringBoot2.0开发WebSocket应用完整示例 -
masuweng：
SpringBoot2.0开发WebSocket应用完整示例 -
wallimn：
水淼火 写道你好,我使用以后,图标不显示,应该怎么引用呢,谢谢 ...
前端框架iviewui使用示例之菜单+多Tab页布局
实验时间：2011年10月14日 环境：RED HAT4，Oracle 10.0.20
基于时间的不完全恢复，难点之一是找出恢复的时间点。如果用户记得当然很多，但很多时候，用户是不知道的，或者不能说知道。如果用户不知道，可以借助于LOG MINIER工具的确定。
一、假定场景
用户误删一个重要的表（SCOTT用户的EMP表），并且清空了回收站。当然此种情况也可以使用闪回技术来恢复，这里使用不完全恢复方法进行恢复。
二、场景模拟
以SCOTT用户登录，删除表，新建一个表。
SQL> conn scott/oracle
Connected.
SQL> drop table emp purge;
Table dropped.
SQL> create table dept_new as select * from dept;
Table created.
不完全恢复后，EMP表应该存在，DEPT_NEW表应该不存在
为了更加接近实际情况，再手动切换几次日志。
SQL> conn / as sysdba
Connected.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
三、恢复过程
1、设置LOG MINER用的参数
SQL> conn / as sysdba
Connected.
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string /home/oracle/oracle/product/10
.2.0/db_1/dbs/spfileorcl.ora
SQL> alter system set utl_file_dir='/tmp/logmnr' scope=spfile;
System altered.
SQL> startup force
ORACLE instance started.
Total System Global Area 130023424 bytes
Fixed Size 1218100 bytes
Variable Size 62917068 bytes
Database Buffers 62914560 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> show parameter utl_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir string /tmp/logmnr
验证一下，设置成功，当然，对应的目录要存在。
2、创建数据字典
SQL> exec dbms_logmnr_d.build('dictora','/tmp/logmnr');
PL/SQL procedure successfully completed.
SQL> !ls -l /tmp/logmnr
total 22992
-rw-r--r-- 1 oracle oinstall 23509170 Oct 14 22:20 dictora
创建成功后，可以看到对应的文件
3、添加要分析的日志（包括联机日志和归档日志）
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 35 52428800 1 YES INACTIVE 915247 14-OCT-11
2 1 36 52428800 1 NO CURRENT 935795 14-OCT-11
3 1 34 52428800 1 YES INACTIVE 915244 14-OCT-11
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- ------------------------------------------------------------ ---
3 ONLINE /home/oracle/oracle/product/oradata/orcl/redo03.log NO
2 ONLINE /home/oracle/oracle/product/oradata/orcl/redo02.log NO
1 STALE ONLINE /home/oracle/oracle/product/oradata/orcl/redo01.log NO
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo02.log',-
> dbms_logmnr.new);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo01.log',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo03.log',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
再加入两组归档日志
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/archive/1_33_760842868.dbf',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/archive/1_32_760842868.dbf',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
4、开始分析，根据分析结果确定时间
SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'/tmp/logmnr/dictora');
PL/SQL procedure successfully completed.
字典文件名称就是前面的目录，加上字典文件名称
SQL> select to_char(timestamp,'yyyy-mm-dd hh24:mi:ss') sj,
2 scn,sql_redo from V$logmnr_contents
3 where upper(sql_redo) like 'DROP TABLE EMP%';
SJ SCN SQL_REDO
------------------- ---------- ------------------------------------------------------------
2011-10-14 22:04:56 915163 drop table emp purge;
由以上SQL可以确定了删除表的时间，以及SCN号。
5、具体的恢复过程
SQL> shutdown abort;
ORACLE instance shut down.
SQL> !cp /disk2/oracle/coldbak/*.dbf $ORACLE_BASE/oradata/orcl/
SQL> startup mount
ORACLE instance started.
Total System Global Area 130023424 bytes
Fixed Size 1218100 bytes
Variable Size 67111372 bytes
Database Buffers 58720256 bytes
Redo Buffers 2973696 bytes
Database mounted.
SQL> recover database until time '2011-10-14 22:04:56';
ORA-00279: change 869963 generated at 09/26/2011 03:49:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_22_760842868.dbf
ORA-00280: change 869963 for thread 1 is in sequence #22
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 890420 generated at 09/26/2011 03:58:51 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_23_760842868.dbf
ORA-00280: change 890420 for thread 1 is in sequence #23
ORA-00278: log file '/home/oracle/oracle/product/archive/1_22_760842868.dbf' no longer needed for this recovery
ORA-00279: change 910592 generated at 09/26/2011 04:14:24 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_24_760842868.dbf
ORA-00280: change 910592 for thread 1 is in sequence #24
ORA-00278: log file '/home/oracle/oracle/product/archive/1_23_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912028 generated at 09/26/2011 04:39:55 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_25_760842868.dbf
ORA-00280: change 912028 for thread 1 is in sequence #25
ORA-00278: log file '/home/oracle/oracle/product/archive/1_24_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912030 generated at 09/26/2011 04:39:56 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_26_760842868.dbf
ORA-00280: change 912030 for thread 1 is in sequence #26
ORA-00278: log file '/home/oracle/oracle/product/archive/1_25_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912033 generated at 09/26/2011 04:40:01 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_27_760842868.dbf
ORA-00280: change 912033 for thread 1 is in sequence #27
ORA-00278: log file '/home/oracle/oracle/product/archive/1_26_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912035 generated at 09/26/2011 04:40:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_28_760842868.dbf
ORA-00280: change 912035 for thread 1 is in sequence #28
ORA-00278: log file '/home/oracle/oracle/product/archive/1_27_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912037 generated at 09/26/2011 04:40:04 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_29_760842868.dbf
ORA-00280: change 912037 for thread 1 is in sequence #29
ORA-00278: log file '/home/oracle/oracle/product/archive/1_28_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912039 generated at 09/26/2011 04:40:05 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_30_760842868.dbf
ORA-00280: change 912039 for thread 1 is in sequence #30
ORA-00278: log file '/home/oracle/oracle/product/archive/1_29_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912041 generated at 09/26/2011 04:40:05 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_31_760842868.dbf
ORA-00280: change 912041 for thread 1 is in sequence #31
ORA-00278: log file '/home/oracle/oracle/product/archive/1_30_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912152 generated at 09/26/2011 04:46:45 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_32_760842868.dbf
ORA-00280: change 912152 for thread 1 is in sequence #32
ORA-00278: log file '/home/oracle/oracle/product/archive/1_31_760842868.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
简述一下具体过程：关库，转储备份的数据文件，打开数据库的MOUNT状态，使用recover database until time '2011-10-14 22:04:56'命令进行不完全恢复，
使用alter database open resetlogs命令打开数据库
6、检查
SQL> conn scott/oracle;
Connected.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
DEPT TABLE
EMP TABLE
BONUS TABLE
SALGRADE TABLE
RECOVER_TEST TABLE
RECOVER_TEST2 TABLE
EMP_BAK TABLE
7 rows selected.
好了，该存在的表EMP存在，不该存在的表DEPT_NEW不存在。
7、关于resetlogs参数
切换几次重做日志，查询一下，可以看到由此带来的相应变化；日志的SEQUENCE#从１重新开始编了，RESETLOGS_CHANGE#变成一个新的数字了。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 2 52428800 1 YES INACTIVE 915564 14-OCT-11
2 1 4 52428800 1 NO CURRENT 915569 14-OCT-11
3 1 3 52428800 1 YES INACTIVE 915566 14-OCT-11
SQL> select name,status,thread#,sequence#,resetlogs_change# from v$archived_log;
NAME S THREAD# SEQUENCE# RESETLOGS_CHANGE#
-------------------------------------------------------------------------------- - ---------- ---------- -----------------
/home/oracle/oracle/product/archive/1_33_760842868.dbf A 1 33 690028
/home/oracle/oracle/product/archive/1_34_760842868.dbf A 1 34 690028
/home/oracle/oracle/product/archive/1_35_760842868.dbf A 1 35 690028
/home/oracle/oracle/product/archive/1_36_760842868.dbf A 1 36 690028
/home/oracle/oracle/product/archive/1_1_764549776.dbf A 1 1 915159
/home/oracle/oracle/product/archive/1_2_764549776.dbf A 1 2 915159
/home/oracle/oracle/product/archive/1_3_764549776.dbf A 1 3 915159
基于时间的不完全恢复，难点之一是找出恢复的时间点。如果用户记得当然很多，但很多时候，用户是不知道的，或者不能说知道。如果用户不知道，可以借助于LOG MINIER工具的确定。
一、假定场景
用户误删一个重要的表（SCOTT用户的EMP表），并且清空了回收站。当然此种情况也可以使用闪回技术来恢复，这里使用不完全恢复方法进行恢复。
二、场景模拟
以SCOTT用户登录，删除表，新建一个表。
SQL> conn scott/oracle
Connected.
SQL> drop table emp purge;
Table dropped.
SQL> create table dept_new as select * from dept;
Table created.
不完全恢复后，EMP表应该存在，DEPT_NEW表应该不存在
为了更加接近实际情况，再手动切换几次日志。
SQL> conn / as sysdba
Connected.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
三、恢复过程
1、设置LOG MINER用的参数
SQL> conn / as sysdba
Connected.
SQL> show parameter spfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string /home/oracle/oracle/product/10
.2.0/db_1/dbs/spfileorcl.ora
SQL> alter system set utl_file_dir='/tmp/logmnr' scope=spfile;
System altered.
SQL> startup force
ORACLE instance started.
Total System Global Area 130023424 bytes
Fixed Size 1218100 bytes
Variable Size 62917068 bytes
Database Buffers 62914560 bytes
Redo Buffers 2973696 bytes
Database mounted.
Database opened.
SQL> show parameter utl_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir string /tmp/logmnr
验证一下，设置成功，当然，对应的目录要存在。
2、创建数据字典
SQL> exec dbms_logmnr_d.build('dictora','/tmp/logmnr');
PL/SQL procedure successfully completed.
SQL> !ls -l /tmp/logmnr
total 22992
-rw-r--r-- 1 oracle oinstall 23509170 Oct 14 22:20 dictora
创建成功后，可以看到对应的文件
3、添加要分析的日志（包括联机日志和归档日志）
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 35 52428800 1 YES INACTIVE 915247 14-OCT-11
2 1 36 52428800 1 NO CURRENT 935795 14-OCT-11
3 1 34 52428800 1 YES INACTIVE 915244 14-OCT-11
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- ------------------------------------------------------------ ---
3 ONLINE /home/oracle/oracle/product/oradata/orcl/redo03.log NO
2 ONLINE /home/oracle/oracle/product/oradata/orcl/redo02.log NO
1 STALE ONLINE /home/oracle/oracle/product/oradata/orcl/redo01.log NO
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo02.log',-
> dbms_logmnr.new);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo01.log',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/oradata/orcl/redo03.log',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
再加入两组归档日志
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/archive/1_33_760842868.dbf',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.add_logfile('/home/oracle/oracle/product/archive/1_32_760842868.dbf',-
> dbms_logmnr.addfile);
PL/SQL procedure successfully completed.
4、开始分析，根据分析结果确定时间
SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'/tmp/logmnr/dictora');
PL/SQL procedure successfully completed.
字典文件名称就是前面的目录，加上字典文件名称
SQL> select to_char(timestamp,'yyyy-mm-dd hh24:mi:ss') sj,
2 scn,sql_redo from V$logmnr_contents
3 where upper(sql_redo) like 'DROP TABLE EMP%';
SJ SCN SQL_REDO
------------------- ---------- ------------------------------------------------------------
2011-10-14 22:04:56 915163 drop table emp purge;
由以上SQL可以确定了删除表的时间，以及SCN号。
5、具体的恢复过程
SQL> shutdown abort;
ORACLE instance shut down.
SQL> !cp /disk2/oracle/coldbak/*.dbf $ORACLE_BASE/oradata/orcl/
SQL> startup mount
ORACLE instance started.
Total System Global Area 130023424 bytes
Fixed Size 1218100 bytes
Variable Size 67111372 bytes
Database Buffers 58720256 bytes
Redo Buffers 2973696 bytes
Database mounted.
SQL> recover database until time '2011-10-14 22:04:56';
ORA-00279: change 869963 generated at 09/26/2011 03:49:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_22_760842868.dbf
ORA-00280: change 869963 for thread 1 is in sequence #22
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 890420 generated at 09/26/2011 03:58:51 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_23_760842868.dbf
ORA-00280: change 890420 for thread 1 is in sequence #23
ORA-00278: log file '/home/oracle/oracle/product/archive/1_22_760842868.dbf' no longer needed for this recovery
ORA-00279: change 910592 generated at 09/26/2011 04:14:24 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_24_760842868.dbf
ORA-00280: change 910592 for thread 1 is in sequence #24
ORA-00278: log file '/home/oracle/oracle/product/archive/1_23_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912028 generated at 09/26/2011 04:39:55 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_25_760842868.dbf
ORA-00280: change 912028 for thread 1 is in sequence #25
ORA-00278: log file '/home/oracle/oracle/product/archive/1_24_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912030 generated at 09/26/2011 04:39:56 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_26_760842868.dbf
ORA-00280: change 912030 for thread 1 is in sequence #26
ORA-00278: log file '/home/oracle/oracle/product/archive/1_25_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912033 generated at 09/26/2011 04:40:01 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_27_760842868.dbf
ORA-00280: change 912033 for thread 1 is in sequence #27
ORA-00278: log file '/home/oracle/oracle/product/archive/1_26_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912035 generated at 09/26/2011 04:40:03 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_28_760842868.dbf
ORA-00280: change 912035 for thread 1 is in sequence #28
ORA-00278: log file '/home/oracle/oracle/product/archive/1_27_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912037 generated at 09/26/2011 04:40:04 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_29_760842868.dbf
ORA-00280: change 912037 for thread 1 is in sequence #29
ORA-00278: log file '/home/oracle/oracle/product/archive/1_28_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912039 generated at 09/26/2011 04:40:05 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_30_760842868.dbf
ORA-00280: change 912039 for thread 1 is in sequence #30
ORA-00278: log file '/home/oracle/oracle/product/archive/1_29_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912041 generated at 09/26/2011 04:40:05 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_31_760842868.dbf
ORA-00280: change 912041 for thread 1 is in sequence #31
ORA-00278: log file '/home/oracle/oracle/product/archive/1_30_760842868.dbf' no longer needed for this recovery
ORA-00279: change 912152 generated at 09/26/2011 04:46:45 needed for thread 1
ORA-00289: suggestion : /home/oracle/oracle/product/archive/1_32_760842868.dbf
ORA-00280: change 912152 for thread 1 is in sequence #32
ORA-00278: log file '/home/oracle/oracle/product/archive/1_31_760842868.dbf' no longer needed for this recovery
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
简述一下具体过程：关库，转储备份的数据文件，打开数据库的MOUNT状态，使用recover database until time '2011-10-14 22:04:56'命令进行不完全恢复，
使用alter database open resetlogs命令打开数据库
6、检查
SQL> conn scott/oracle;
Connected.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
DEPT TABLE
EMP TABLE
BONUS TABLE
SALGRADE TABLE
RECOVER_TEST TABLE
RECOVER_TEST2 TABLE
EMP_BAK TABLE
7 rows selected.
好了，该存在的表EMP存在，不该存在的表DEPT_NEW不存在。
7、关于resetlogs参数
切换几次重做日志，查询一下，可以看到由此带来的相应变化；日志的SEQUENCE#从１重新开始编了，RESETLOGS_CHANGE#变成一个新的数字了。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 2 52428800 1 YES INACTIVE 915564 14-OCT-11
2 1 4 52428800 1 NO CURRENT 915569 14-OCT-11
3 1 3 52428800 1 YES INACTIVE 915566 14-OCT-11
SQL> select name,status,thread#,sequence#,resetlogs_change# from v$archived_log;
NAME S THREAD# SEQUENCE# RESETLOGS_CHANGE#
-------------------------------------------------------------------------------- - ---------- ---------- -----------------
/home/oracle/oracle/product/archive/1_33_760842868.dbf A 1 33 690028
/home/oracle/oracle/product/archive/1_34_760842868.dbf A 1 34 690028
/home/oracle/oracle/product/archive/1_35_760842868.dbf A 1 35 690028
/home/oracle/oracle/product/archive/1_36_760842868.dbf A 1 36 690028
/home/oracle/oracle/product/archive/1_1_764549776.dbf A 1 1 915159
/home/oracle/oracle/product/archive/1_2_764549776.dbf A 1 2 915159
/home/oracle/oracle/product/archive/1_3_764549776.dbf A 1 3 915159
分享到：
发表评论
-
Oracle连接故障的排除
2024-09-09 22:33 663Oracle版本为11G，操作系统为Windows Ser ... -
Oracle数据库相关系统突然提示“SQLException:违反协议”
2024-02-19 15:50 5178SQLException:违反协议这个异常可能由很多的 ... -
CentOS在Docker中安装Oracle
2024-02-06 12:13 12781.拉取Oracle镜像，并检 ... -
Windows Server安装oracle数据库一直停在82%
2023-02-04 12:01 626网上有个说法：服务器超过一定数量的CPU后，将不能正常安装 ... -
ORA-04030错误处理
2023-02-04 11:52 2706【错误描述】 错误信息如下： ORA-04030：在尝 ... -
ORA-04030错误处理
2023-02-04 11:45 403【错误描述】 错误信息如下： ORA-04030：在尝 ... -
Linux安装MySQL数据库
2019-06-10 22:27 18281.进入安装包所在目录，解压： tar zxvf mysql- ... -
确定MySQL在Linux系统中配置文件的位置
2019-04-14 19:30 27871.通过which mysql命令来查看mysql的安装位置。 ... -
mysql set names 命令和 mysql 字符编码问题
2019-04-12 00:34 1166转自：https://www.cnblogs.com/digd ... -
MYSQL中取当前周/月/季/年的第一天与最后一天
2018-11-17 23:16 2223转自：https://blog.csdn.net/ ... -
Oracle删除大量数据的实践
2016-11-07 18:03 5845一、引言 从来没有 ... -
Oracle 数据库简明教程 V0.1
2016-03-23 21:01 2072供初学者入门学习使用，以开发者常见、常用的知识为主，基本上 ... -
Oracle拆分字符串函数
2016-03-23 10:58 3373create or replace type string ... -
Oracle数据库远程连接无响应
2016-03-21 10:20 4332故障现象： 服务器本机使用sqlplus / as s ... -
Oracle PGA详解
2015-10-21 15:34 11497转自：http://yanguz123.iteye.com/b ... -
Oracle12C导入dmp数据
2015-10-08 23:43 20559Oracle12C，发生了较大的变化。以前熟悉的东西变得陌 ... -
SQLLDR数据导入小结
2015-07-25 22:06 75521.创建数据表 CREATE TABLE ... -
Window7安装Oracle10
2015-03-06 12:14 1629每次安装都要百度，转到自己的博客上，找起来方便，还能增加访 ... -
Oracle SQL Developer 连接 Mysql 数据库
2015-02-25 19:36 3692下载JDBC包，解压缩这里只要mysql-connector- ... -
Mysql数据备份与恢复
2015-02-25 19:15 1371备份/恢复策略 1. 要定期做 mysql备份，并考虑系统可以 ...
相关推荐
### Oracle RMAN 异机不完全恢复 #### 实验背景 在实际的数据库管理工作中，可能会遇到因误操作导致的数据丢失或损坏的情况。在这种情况下，如何有效地利用备份数据完成数据库的恢复工作至关重要。本实验模拟了一...
Oracle数据库的不完全恢复是一种特殊的恢复机制，它用于在某些特定情况下，如丢失部分归档日志或数据文件，使得完全恢复无法实现时，通过应用部分日志来恢复数据库到故障发生前的一个特定状态。不完全恢复的目标是尽...
本篇将探讨Oracle基于数据挖掘的不完全恢复方法，它允许你在误操作后恢复到特定的时间点，而非仅仅回滚到最近的备份状态。 首先，理解不完全恢复的概念。不完全恢复是一种在数据库关闭状态下进行的恢复方式，它可以...
使用RMAN进行基于时间点的不完全恢复 - Oracle Life.files 使用RMAN进行快速Dataguard数据库创建 - Oracle Life.files Oracle RMAN物理备份技术详解 Oracle RMAN快速入门指南 如何彻底删除Oracle 使用RMAN进行快速...
对于完全恢复，Oracle使用归档日志（Archived Redo Logs），这是在每次日志切换时产生的历史记录，用于在数据库灾难性失败后进行完全恢复。 归档日志是Oracle数据恢复策略中的关键元素，因为它们包含了自上次备份...
本资源“Oracle数据库备份与恢复之完全攻略”提供了一份详尽的指导，涵盖了Oracle数据库的备份、还原过程及注意事项。 一、Oracle数据库备份类型 1. **完整备份**：包括数据库的所有数据文件、控制文件、参数文件...
而不完全介质恢复则在无法进行完全恢复或无需完全恢复时进行，包括基于撤销、基于时间和基于修改的恢复。基于撤销的恢复允许DBA控制恢复到某一特定操作前的状态，而基于时间或修改的恢复则可以恢复到某个特定的时间...
- 不完全介质恢复：在无法进行完全恢复或不需要完全恢复时使用，如基于撤销、基于时间或基于修改的恢复。基于撤销恢复允许DBA控制恢复到特定操作之前，而基于时间和基于修改的恢复则允许恢复到特定的时间点或系统...
总结来说，Oracle备份与恢复是数据库管理中的核心技能，涉及到实例恢复、介质恢复、不同类型的不完全恢复策略，以及使用如`exp`和`imp`等工具进行数据迁移。了解并熟练掌握这些概念和技术，能够帮助DBA有效地应对...
2. 恢复模式：根据业务需求，可以选择完全恢复、不完全恢复或单个表空间恢复等模式。 3. 指定恢复时间点：如果选择了时间点恢复，用户需要确定到哪个时间点的数据需要恢复。 4. 执行恢复：工具会解析用户的恢复指令...
Oracle 12c 备份恢复-RMAN 工具技术手册 本文档旨在提供 Oracle 12c 备份恢复的技术手册，主要介绍 RMAN 工具的概念、架构、备份类型和使用方法。 一、RMAN 概念 RMAN（Recovery Manager）是 Oracle 推荐的备份和...
同城容灾和异地灾备的部署策略可以确保在故障发生时，业务能够快速恢复，减少中断时间。 此外，EasyDB还提供了数据库运维管控平台，名为easyDBagent，用于简化Oracle的管理和监控。通过这个SaaS平台，可以进行全量...
Oracle数据库是企业级广泛使用的数据库管理系统，为了保证数据的安全性和完整性，定期备份是必不可少的环节。本项目"Oracle 备份工具,基于.net"提供了一种解决方案，它利用.NET框架来实现对Oracle数据库的自动备份...
Oracle 数据库提供了多种恢复方法，包括基于时间的不完全恢复、基于 SCN 的恢复、基于日志的恢复等。 1. 基于时间的不完全恢复 基于时间的不完全恢复是指恢复数据库到某个指定的时间点。这种方法可以使用热备份来...
不完全介质恢复则是在无法或不需要完全恢复时使用，它可以是基于撤销、基于时间或基于修改的恢复。例如，基于撤销的恢复适用于日志组受损，需要在使用最近的未损日志组后中断恢复；基于时间或修改的恢复则允许恢复到...
冷备份是在数据库关闭的情况下进行的，适用于完全备份，但操作期间数据库不可用；热备份则允许在数据库运行时进行备份，适合于事务繁忙的环境；逻辑备份通过导出数据和SQL脚本实现，适用于数据迁移和数据复制；物理...
- **基于时间（TIME）和基于修改（SCN）的恢复**：如果DBA希望将数据库恢复到过去某个特定的时间点或修改点，可以采用基于时间和基于修改的不完全恢复。例如，在意外删除了某个数据表之后，可以使用这种方式将数据库...