Archives for 三月 2016

【dbdao Hadoop 大数据学习】HDFS 配额指导

dbDao.com 引导式IT在线教育

Hadoop 技术学习QQ群号  : 134115150

本文固定链接:http://www.askmaclean.com/archives/hadop-hdfs-quotas-guide.html

原文地址:http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsQuotaAdminGuide.html 

1概述

 

HDFS允许管理员为名称的数量进行配额限制,并且为单独的目录设置使用空间得大小。

命名限额和空间限额是独立的,但是管理员实施的时候这2者是密切配合的(www.askmaclean.com)。

 

 

2.名称限额

 

名称限额是根目录中的目录名称文件的硬性限制。如果达到了这个限制,创建文件和目录将会失败。限额也会在重命名操作上起作用,如果重命名也满足限制条件,这个操作也将失败。即使新的配额已经让当前的目录违反了,这个设置操作任然会成功(设置并不会去校验)。一个新创建的目录不会分配配额。最大的配额是Long.Max_Value。配额强制一个目录保持为空(一个目录的数量就是其自身的配额)

 

在fsimage上,配额是持续性的。当启动时,如果fsimage已经违背了一个配额(也行是fsimage被偷偷的修改),每一个违反都会打印一个警告。设置或删除创建一个日志条目的配额。

[Read more…]

诗檀软件与 Solix 合作大数据项目

诗檀软件与 Solix 合作大数据项目

中国领先的数据库服务公司,基于Apache Hadoop的平台,提供信息生命周期管理(ILM通用数据平台和先进分析。

 

2016 — Santa Clara, Calif. — Solix Technologies, Inc.,  Solix Technologies,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商在今天宣布,中国的数据库服务公司诗檀数据已经选择了Solix的大数据套件,基于Apache Hadoop进行交付归档,应用停用和先进分析。

 

Apache Hadoop是ILM的理想平台,因为它为企业级数据提供了高度可扩展,低成本,大容量存储。诗檀数据将为客户提供Solix的大数据套件,以提高应用程序的性能,降低成本,并满足管理,风险和合规性要求。Solix的大数据套件作为企业共同的数据平台,对大型数据集的结构化和非结构化数据进行高级分析。

 

“Apache Hadoop作为一个通用数据平台,是先进企业分析和ILM应用的理想工具。” John Ottman,Solix Technologies, Inc执行主席说道。“我们非常期待与诗檀数据在大中国区市场的合作。”

 

Solix是目前唯一一家为所有企业数据提供全面的信息生命周期管理(ILM)解决方案的供应商。我们很幸运在中国有这样强大的合作伙伴,诗檀数据CEO Maclean Liu说道。

 

要了解有关Solix大数据套件的更多信息, 点击这里

 

关于Solix Technologies

Solix Technologies, Inc.,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商,通过其优化的基础设施,安全保障和先进分析,帮助企业管理自己的企业信息。 Solix Big Data Suite 是一个ILM应用解决方案架构,包括 Enterprise Archiving Enterprise Data Lake,  Application Retirement, Database Archiving, Test Data Management (数据库子集)和 Data Masking。 Solix Technologies, Inc. 总部位于美国加州的圣克拉拉,通过增值经销商(VAR)和系统集成商构建的网络遍及全球。要了解更多信息,请访问 www.solix.com

 

关于 Parnassus Data

Parnassus Data 是位于上海的一家Oracle 数据库服务公司,提供数据库开发,实施,管理和紧急支持服务。诗檀数据是数据库优化和监控工具开发方面的专家,同时也为Oracle数据库用户提供远程和现场服务。

 

联系 Solix

访问我们的网站:http://www.solix.com

在Twitter上关注我们:@solixedms

加入我们的Facebook: http://www.facebook.com/solixtechnologies

 

媒体联系

Jessica Hasson

PulpPR for Solix

jessica@pulppr.com

Oracle常见备份方案对应使用RMAN恢复场景

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

 

使用RMAN恢复场景

 

 

内容提要

 

当灾难发生的时候实施Restore/Recovery,可以还原生产数据库到最接近灾难发生前的一致性点。

Restore/Recover测试是备份策略很重要的一部分。当真的需要恢复的时候,确保备份可用并且能克服小毛病。如果需要恢复可以减少生产恢复的时间。

 

本文提供了大多数恢复场景,在灾难发生后的反应。例子的场景不是相关的具体存储。文中提供的场景基于基本的文件系统。稍微改动,就可用于ASM,裸设备,ocfs或其他类型存储。

简介

 

 

Redo Vs Rollback

Rode  Logs:  重做日志被用于前滚提交和未提交的变化

Rollback:         用于undo/rollback(撤销/回滚)未提交的变化

 

 

 

恢复类型

  • 在线块恢复(进程错误)

Oracle数据库的PMON进程会自动执行恢复。在某个进程修改buffer时异常死掉时发生

Oracle会使用重做日志重建buffer并写入磁盘。

  • 线程恢复 (实例错误)

也是oracle自动执行。发生在打开数据库实例崩溃的时候。

Oracle在线程上应用从上次线程检查点之后发生的所有的redo。

  • 介质恢复.

当一个数据文件从备份中恢复的时候需要进行介质恢复,因为数据文件中的checkpoint和控制文件中的不同,也发生在离线文件没来得及做checkpoint操作和使用备份控制文件的时候。

 

 

 

介质恢复类型

 

完全介质恢复

称之为完全恢复是因为oracle应用所有的重做日志将数据库回到最近的点,代表性的是应用于数据文件或控制文件的介质损坏。

它可以恢复整个数据库也可以只恢复表空间或数据文件。

 

数据库完全恢复 表空间/数据文件完全恢复
数据库mount 数据库 open
所有数据文件在线 要恢复的表空间/数据文件离线
恢复整个备份 恢复数据文件备份
应用在线或归档日志 应用在线或归档日志

 

场景:

  • 丢失数据文件
    1. System datafile

run {

shutdown abort; startup mount; restore datafile 1;

recover datafile 1; alter database open; }

 

恢复数据文件到不同的位置

run {

shutdown abort; startup mount;

set newname for datafile 1 to ‘/tmp/system01.dbf’; restore datafile 1;

switch datafile all; recover datafile 1; alter database open; }

  1. Non-system datafile

run {

sql “alter database datafile 5 offline”; restore datafile 5;

recover datafile 4;

sql “alter database datafile 4 online”; }

 

 

恢复到不同的位置

run {

sql “alter database datafile  6 offline”;

set newname for datafile 6 to ‘/u01/oracle/app//oradata/orcl/test02.dbf’;

restore datafile 6;

switch datafile all; recover datafile 6;

sql “alter database datafile 6 online”; }

 

  • 丢失整个数据库

run {

startup nomount; restore controlfile from  ‘/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/ o1_mf_s_917622140_crvn3xbh_.bkp’;

startup mount; restore database; recover database;

alter database open resetlogs; }

 

不完全介质恢复

称之为不完全恢复是因为oracle不会应用所有的重做日志恢复数据库到之前的点。

应用于下面这些情况:

  • 丢失当前控制文件(备份的控制文件用于打开数据库)
  • 丢失一个或所有的重做日志文件
  • 用户/应用错误和基于时间点恢复
  • 丢失归档日志.

 

不完全介质恢复类型

 

  • 基于时间恢复 : 恢复到指定的时间
  • 基于取消的恢复 : 恢复直到输入cancel (当RMAN不可用的时候).
  • 基于SCN的恢复 : 恢复到指定的SCN
  • 基于日志序号的恢复 : 恢复到指定的日志序号 (只有RMAN不可用的时候).

 

场景:

  1. 丢失控制文件

*如果使用noresetlogs方式重建控制文件,需要所有的日志文件完整。修改“alter database backup controlfile to trace noresetlogs;”的输出结果来重建。

SQ> startup nomount

SQL> create controlfile … noresetlog … SQL> alter database open

 

 

*如果你没有备份trace,尝试手工建控制文件。

* 如果上面的方法都没办法重建控制文件,你不得不从备份中恢复,打开数据库使用resetlogs模式,然后添加临时文件(这是无论你用什么方法重建控制文件都必须做的)。

run {

shutdown abort; startup nomount; restore controlfile; startup mount; recover database;

alter database open resetlogs; }

 

恢复控制文件到一个新的位置

run {

shutdown abort; startup nomount;

restore controlfile to ‘/tmp/control01.ctl’; restore controlfile from ‘/tmp/control01.ctl’; Shutdown immediate;

# 编辑init.ora文件映射控制文件的新位置             startup mount;

recover database;

alter database open resetlogs; }

 

  1. 丢失部分或全部的日志文件
Status Archived
UNUSED, CLEARING, INACTIVE Yes
CURRENT, No
ACTIVE Yes / No

col member for a50 set linesize 120

 

select l.group#,l.thread#, lf.member,l.status,l.archived from v$log l , v$logfile lf

where l.group# = lf.group#;

 

活动的已归档在线日志

如果系统还没切换到丢失的日志文件,你可以安全的删除日志文件然后添加新的在线日志.

$ sqlplus ‘/as sysdba’

SQL> alter database drop logfile group 2;

SQL> alter database add logfile group 2 ‘/u02/oradata/test10g/redo02.log’ size 50M;

 

 

如果数据库已经切换到丢失的日志文件,会报下面的错误:

Errors in file

/u01/app/oracle/admin/test10g/bdump/test10g_arc1_32016.trc: ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: ‘/u02/oradata/test10g/redo02.log’ ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory Additional information: 3

 

$sqlplus ‘/as sysdba’ SQL> shutdown abort SQL> startup mount

SQL> alter database clear unarchived logfile group 2; SQL> Alter database open

活动的未归档在线日志

$sqlplus ‘/as sysdba’ SQL> shutdown abort SQL> startup mount

SQL> alter database clear unarchived logfile group 2; SQL> Alter database open

 

当前的在线日志文件

run {

startup nomount force;

set until sequence 44; # this is the same value of “Current log sequence” restore controlfile;

alter database mount; restore database; recover database;

alter database open resetlogs;}

 

  1. 用户误操作(删除一个表, 或者错误的DML操作)

表空间基于时间点恢复(TSPITR)功能让你恢复一个或多个表空间到你最想要的一个时间点不同于数据库其他部分:

  • 恢复错误的drop或truncate表操作
  • 恢复一个逻辑损坏的表
  • 恢复一个错误的批处理job或者只影响一个数据库子集的DML语句
  • 恢复一个独立的schema到不同于物理数据库其余部分的时间点
  • 恢复一个表空间在一个很大的数据库而不是从备份中恢复整个数据库并执行一个完整的数据库前滚

 

 

 

在同一个主机上因用户误操作(drop/truncate/update)恢复

  • 拷贝ora文件,然后修改下面这些参数: db_name=’test10g’ # 和生产库名字相同 service_names = ‘testaux’

db_unique_name = ‘testaux’ control_files=’/u02/oradata/testaux/control01.ctl’

audit_file_dest = ‘/u01/app/oracle/admin/testaux/adump’ (optional) background_dump_dest = ‘/u01/app/oracle/admin/testaux/bdump’ (optional) core_dump_dest = ‘/u01/app/oracle/admin/testaux/cdump’ (optional) user_dump_dest = ‘/u01/app/oracle/admin/testaux/udump’ (optional) log_archive_dest_1 = ‘?/?/?’ (Optional)

log_archive_format = ‘<>’ (optional)

  1. 对AUX实例设置ORACLE_HOME和ORACLE_SID export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db1

export ORACLE_SID=testaux

  • 创建密码文件:

orapwd file=orapwtestaux password=oracle10g

  1. 确定sqlnet设置正确并测试连接(ora和listener.ora)
  2. 连接rman从生产库(主库)备份中恢复控制文件到AUX库。

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat run {

set until time “TO_DATE(’02/JAN/2009 10:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

restore controlfile to ‘/u02/oradata/testaux/control01.ctl’; } #同步骤1中指定的位置

exit

  1. 连接AUX实例恢复所有需要的表空间到指定的点。

rman target sys/oracle10g@testaux nocatalog run {

startup mount;

set until time “TO_DATE(’02/JAN/2009 10:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

set newname for datafile 1 to ‘/u02/oradata/testaux/system01.dbf’; set newname for datafile 2 to ‘/u02/oradata/testaux/undotbs01.dbf’; set newname for datafile 3 to ‘/u02/oradata/testaux/sysaux01.dbf’; set newname for datafile 4 to ‘/u02/oradata/testaux/users01.dbf’; restore datafile 1,2,3,4;

switch datafile all;

sql “alter database datafile 1,2,3,4 online”; recover database;

 

 

# 你需要指定”skip forever tablespace <list of tablespaces> if need to skip some”

# 恢复数据库跳过表空间ts1,ts2;

sql “alter database rename file ”/u02/oradata/test10g/redo01.log” to ”/u02/oradata/testaux/redo01.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo02.log” to ”/u02/oradata/testaux/redo02.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo03.log” to ”/u02/oradata/testaux/redo03.log””;

alter database open resetlogs;}

 

Note: 你可以使用DB_FILE_NAME_CONVERT

LOG_FILE_NAME_CONVERT 转换文件, 代替 “SET NEWNAME

 

  • 从AUX数据库中导出丢失的表,然后导入到生产库中。
  • 删除AUX数据库(数据文件/控制文件/重做日志文件,Dump目录,ora,密码文件以及整个sqlnet[tnsnames.ora和 sqlnet.ora])

 

TSPITR – 恢复用户误操作 (drop/truncate/update)在别的主机上

同上面相同的步骤,主库的RMAN备份集要进行恢复的主机上可用。

恢复控制文件到一个临时的位置, 然后上传到新的主机上, 然后在新主机上继续执行剩余的步骤。

 

TSPITR –在一个数据库中恢复整个表空间因为用户误操作或者没有影响其他表空的patch job

 

  1. 挑选目标时间: 当不希望的数据库变更发生,你可以使用OracleFlashback Query , Oracle Transaction Query 和Oracle Flashback Version Query去寻找时间点。在这个例子中 (Fri Jan 2 15:05:50 EST 2009)
  2. 确定恢复集: 目标数据文件需要被恢复到指定的时间
  • 分析数据关联在恢复集中 select *

from sys.ts_pitr_check

where ( ts1_name in (‘torder’)  and ts2_name not in (‘torder’)  ) or       ( ts1_name not in (‘torder’)  and ts2_name in (‘torder’) );

 

如果上述查询返回no rows你可以准备执行TSPITR,否则你需要执行下面这些:

  1. 在你的恢复集中添加表空间包括相关的对象。
  2. 删除关联
  3. 在TSPITR执行期间暂停持续的关联
  1. 你需要确定TSPITR执行之后会丢失的对象 askmaclean.com

 

 

select owner, name, tablespace_name ,to_char(creation_time, ‘yyyy-mm- dd:hh24:mi:ss’)

from ts_pitr_objects_to_be_dropped where tablespace_name in (‘users’,’tools’)

and creation_time > to_date(’01-jan-09:15:04:00′,’yy-mon-dd:hh24:mi:ss’) order by tablespace_name, creation_time;

  1. 确定的TSPITR目标
  2. 全自动TSPITR: 使用 RMAN 处理TSPITR所有的方面.  rman target sys/oracle10g@test10g catalog rman/rman@rcvcat

run {

recover tablespace users until time “to_date(’09-Jan-02:15:04:00′,’yy-mon- dd:hh24:mi:ss’)” auxiliary destination ‘/u01/ray/aux’;

sql ‘alter tablespace users online’; }

Note:恢复集文件将被恢复到它们原来的位置,然而辅助集将被恢复到指定的位置根据设置。成功完成后,你需要把表空间设置成online然后尽快进行备份。

 

  1. 使用自动的辅助实例的自定义 TSPITR: 使用RMAN 处理TSPITR所有的方面. 但是自定义一个或多个behavior方面,例如 定制一个或多个behavior方面, 像辅助集的位置 ,恢复集的位置或指定的初始化参数或RMAN管理和生成辅助实例的通道配置.
    1. 重命名或重定位你的恢复集数据文件

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat run {

set newname for datafile 4 to ‘/u02/oradata/testaux/users01.dbf’;

recover tablespace users until time “to_date(’09-Jan-02:15:04:00′,’yy-mon- dd:hh24:mi:ss’)” ;

sql ‘alter tablespace users online’; }

  1. 为一些或所有的辅助集数据文件指定一个除了auxiliary destination

以外的位置                                                                          rman target sys/oracle10g@test10g catalog rman/rman@rcvcat run {

set newname for datafile 4 to ‘/u02/oradata/testaux/users01.dbf’;

recover tablespace users until time “to_date(’09-Jan-02:15:04:00′,’yy-mon- dd:hh24:mi:ss’)” auxiliary destination ‘/u01/ray/aux’;

sql ‘alter tablespace users online’; }

  1. 提前设置好你数据文件的image copy backup,通过避免从备份中恢复从而加快TSPITR速度.

这意味着你需要image copy backup一周一次用来给TSPITR使用当需要的时候

configure auxname for datafile n to auxname_n; # for every datafile

 

 

backup as copy datafile n format auxname_n;

当需要执行TSPITR

recover tablespace tablespace until time until time “to_date(’09- jan-02:15:04:00′,’yy-mon-dd:hh24:mi:ss’)

 

  1. 执行TSPITR使用自己的辅助实例:你负责设置开启, 关闭和 清除 用于 TSPITR的辅助实例, 并且管理 TSPITR 使用一些方法,像”使用自动的辅助实例的自定义 TSPITR :
  • 辅助实例使用不同的通道配置。
  • 指定不同的初始化参数为你的RMAN管理辅助实例。

创建密码文件

创建参数文件使用下面的参数                                             db_name=’test10g’ # THIS IS the same as the production name db_unique_name = ‘testaux’

remote_login_passwordfile = EXCLUSIVE compatible = #The same as in the target database db_block_size = #The same as in the target database log_file_name_convert =(‘/a/b/trgt’, ‘/x/y/auxdest’)

db_file_name_convert =(‘/a/b/trgt’, ‘/x/y/auxdest’) this is optional if not used set newname control_files=’/u02/oradata/testaux/control01.ctl’

audit_file_dest = ‘/u01/app/oracle/admin/testaux/adump’ (optional) background_dump_dest = ‘/u01/app/oracle/admin/testaux/bdump’ (optional)

core_dump_dest = ‘/u01/app/oracle/admin/testaux/cdump’ (optional) user_dump_dest = ‘/u01/app/oracle/admin/testaux/udump’ (optional)

准备AUX实例的网络连接         start/nomount aux instance

rman target sys/oracle10g@test10g auxiliary sys/oracle10g@testaux catalog rman/rman@rcvcat

run {

#指定所有恢复集数据文件的新名字如果db_file_name_convert没指定

set newname for datafile 4 to ‘/u02/oradata/testaux/users01.dbf’;

#指定辅助集的新名字如果db_file_name_convert没指定

# 数据文件有有效的映像副本避免恢复:

set newname for datafile 1 to ‘/u02/oradata/testaux/system01.dbf’; set newname for datafile 2 to ‘/u02/oradata/testaux/undotbs01.dbf’; set newname for datafile 3 to ‘/u02/oradata/testaux/sysaux01.dbf’;

#指定磁盘和管道

allocate auxiliary channel c1 device type disk; allocate auxiliary channel c2 device type disk;

 

 

allocate auxiliary channel t1 device type sbt; allocate auxiliary channel t2 device type sbt;

#恢复表空间到24小时前:

RECOVER TABLESPACE users UNTIL TIME “to_date(’09-jan- 02:15:04:00′,’yy-mon-dd:hh24:mi:ss’); }

 

  1. 丢失归档日志:

DBPITR – 恢复数据库直到最后一个可用的归档日志或最后一个知道的SCN或时间点

run{

shutdown abort; startup mount;

set until sequence=29 thread=1; #将恢复直到 seq 28      restore database ;

recover database ;

alter database open resetlogs; }

其它  restore/recover 情况

 

恢复数据库到resetlogs之前的点

例如你不得不使用resetlogs打开数据库无论什么原因                              run{

shutdown abort; startup mount;

set until time “TO_DATE(’20/AUG/2001 22:38:00′,’DD/MON/YYYY HH24:MI:SS’)”;

set until time ‘sysdate-1/24/60*5’; restore database ;

recover database ;

alter database open resetlogs; }

 

  1. 使用这些方法获得RESETLOGS SCN:

 

– 运行一个LIST INCARNATION 命令,然后Reset SCN 列的值减1.当然,记下数据库的INC key列所有的值。

 

RMAN> List Incarnation;

DB Key  Inc Key DB Name DB ID         STATUS  Reset SCN  Reset Time

——- ——- ——– —————- — ———- ———-

8053 8054 TEST10G 925414866 PARENT 935646     31-DEC-08
8053 8480 TEST10G 925414866 PARENT 1213793    07-JAN-09
8053 8853 TEST10G 925414866 CURRENT 1216303    07-JAN-09

 

 

  • RESETLOGS时检查log , 查找关键字 RESETLOGS. 寻找像这样的一行: RESETLOGS after incomplete recovery UNTIL CHANGE 1234. 使用它, 例如

Wed Jan  7 13:08:19 2009

Incomplete Recovery applied until change 1216302

 

  • RESETLOGS之后通过控制文件 (当前控制文件或者resetlogs打开后备份的控制文件), 运行查询:

SELECT (RESETLOGS_CHANGE#)-1 FROM V$DATABASE; (RESETLOGS_CHANGE#)-1

———————

1216302

  • 决定目标 incarnation ( list incarnation of database <db name> ) 并记录主键和scn. 在这个场景中目标 incarantion 是 8480

RMAN> Shutdown immediate startup nomount

reset database to incarnation 8480; run {

set until scn 1216302; restore controlfile; startup mount;

restore database; recover database;

alter database open resetlogs;}

 

数据块介质恢复

blockrecover corruption list; ##  在视图V$DATABASE_BLOCK_CORRUPTION中显示所有要恢复的块

blockrecover datafile 4 block 999;

blockrecover tablespace ts1 dba <address of the block>

 

场景:

======

conn scott/tiger

create table xx as select * from emp;

 

conn / as sysdba select header_block from dba_segments

where segment_name=’XX’;

 

HEADER_BLOCK

————

59

 

 

 

dd if=/dev/zero of=/u02/oradata/test10g/users01.dbf bs=8192 conv=notrunc seek=60 count=1

1+0 records in

1+0 records out

8192 bytes (8.2 kB) copied, 0.000177 seconds, 46.3 MB/s

 

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat backup tablespace users;

RMAN-03009: failure of backup command on ORA_DISK_1 channel at 01/07/2009 12:22:51

ORA-19566: exceeded limit of 0 corrupt blocks for file

/u02/oradata/test10g/users01.dbf

 

alert.log:

=======

Hex dump of (file 4, block 60) in trace file

/u01/app/oracle/admin/test10g/udump/test10g_ora_21798.trc Corrupt block relative dba: 0x0100003c (file 4, block 60) Completely zero block found during backing up datafile

Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data

 

RMAN> blockrecover datafile 4 block 60; RMAN> backup tablespace users;

 

恢复参数文件

如果实例是启动的

=============

RMAN> restore spfile to ‘/tmp/spfiletest10g.ora’;

$ mv /tmp/spfiletest10g.ora $ORACLE_HOME/dbs/ spfiletest10g.ora

 

如果实例是关闭的:

===============

创建一个参数文件只使用下面的参数:

*.db_name=’test10g’

*.large_pool_size=8m

*.shared_pool_size=100m

*.db_cache_size=4m

RMAN> Restore spfile from autobackup; RMAN> shutdown immediate

删除之前的参数文件

 

 

RMAN> startup

 

恢复数据库到新的主机上

Note1:下面的步骤是用来执行DR测试恢复,移动生产库到一个新的主机 ,或者恢复数据库如果recovery catalog被损坏或丢失。

Note2: 下面步骤也用于创建一个目标数据库的副本,推荐使用RMAN Duplicate代替, 因为RMAN会分配新的dbid.如果选择不使用RMAN Duplicate 不要连接指定的recovery catalog在这个例子中, 否则将来恢复你的生产库将受到影响。

Note3:  如果你选择复制数据库使用下面的步骤,考虑以下几个方面:

  • 不要连接recovery catalog
  • 成功后请变更dbidrecovery catalog注册克隆数据库之前。请参考“Restore database in the same host”DBNEWID 部分

 

  1. 记录源库的dbid

RMAN> list incarnation; or select dbid from v$database;

  1. 获得源库的数据文件列表用来重命名 col name for a60

col member for a60

 

select file# as “file/grp#”, name from v$datafile; select group#,member from v$logfile;

  1. 复制源库的参数文件到新主机上

scp inittest10g.ora sscnjlnx3:/u01/app/oracle/product/10.2.0/db_1 更改下面这些:

control_files=’/u01/ray/oradata /control01.ctl’ background_dump_dest = ‘/u01/ray/dump/bdump’ user_dump_dest = ‘/u01/ray/dump/udump’ core_dump_dest = ‘/u01/ray/dump/cdump’ audit_file_dest = ‘/u01/ray/dump/adump’ log_archive_dest_1 = ‘ location=/u01/ray/arch’

  1. 上传所有的备份集到新主机,和源库相同的位置. cd /u03/ray/backup

scp * sscnjlnx3:/u03/ray/backup

 

如果不是相同的位置,你可以创建软链接 mkdir /u03

cd /u03 mkdir ray cd  /

 

 

ln -s /d01/backup /u03/ray/backup

  1. 在新主机上

$ export ORACLE_SID=test10g

$ rman target / nocatalog RMAN> set dbid 925414866 RMAN> startup nomount

RMAN> restore controlfile from ‘/u03/ray/backup/cf_c-925414866- 20090112-00’;

RMAN> alter database mount; RMAN> run {

# 用来恢复文件到不同的位置

# DB_FILE_NAME_CONVERT 可以用来替代

set newname for datafile 1 to ‘/u01/ray/oradata/new/system01.dbf’; set newname for datafile 2 to ‘/u01/ray/oradata/new/undotbs01.dbf’; set newname for datafile 3 to ‘/u01/ray/oradata/new/sysaux01.dbf’; set newname for datafile 4 to ‘/u01/ray/oradata/new/users01.dbf’;

# LOG_FILE_NAME_CONVERT 可以用来替代

set until scn 1352525; restore database; switch datafile all; recover database;

#下面rename部分用来重建在线日志到不同的位置

sql “alter database rename file ”/u02/oradata/test10g/redo01.log” to ”/u01/ray/oradata/new/redo01.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo02.log” to ”/u01/ray/oradata/new/redo02.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo03.log” to ”/u01/ray/oradata/new/redo03.log””; alter database open resetlogs; }

 

恢复数据库在相同的主机

拷贝 inittest10g.ora至 initdup10g.ora,修改按照下面: control_files=’/u03/ray/dup10g/oradata/control01.ctl’ background_dump_dest = ‘/ u03/ray/dup10g/dump/bdump’ user_dump_dest = ‘/ u03/ray/dup10g/dump/udump’ core_dump_dest = ‘/ u03/ray/dup10g/dump/cdump’ audit_file_dest = ‘/ u03/ray/dup10g/dump/adump’ log_archive_dest_1 = ‘ location=/ u03/ray/dup10g arch’ db_unique_name=dup10g

$ export ORACLE_SID=dup10g

 

 

$ rman target / nocatalog RMAN> set dbid 925414866 RMAN> startup nomount

RMAN> restore controlfile from ‘/u03/ray/backup/cf_c-925414866-20090112-00’; RMAN> startup mount

RMAN> run {

set newname for datafile 1 to ‘/u03/ray/dup10g/oradata/system01.dbf’; set newname for datafile 2 to ‘/u03/ray/dup10g/oradata/undotbs01.dbf’; set newname for datafile 3 to ‘/u03/ray/dup10g/oradata/sysaux01.dbf’; set newname for datafile 4 to ‘/u03/ray/dup10g/oradata/users01.dbf’; set until scn 1352525;

restore database; switch datafile all; recover database;

sql “alter database rename file ”/u02/oradata/test10g/redo01.log” to ”/u03/ray/dup10g/oradata/redo01.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo02.log” to ”/u03/ray/dup10g/oradata/redo02.log””;

sql “alter database rename file ”/u02/oradata/test10g/redo03.log” to ”/u03/ray/dup10g/oradata/redo03.log””;

alter database open resetlogs; } exit from RMAN

SQL> alter database backup controlfile to trace SQL> shutdown immediate

#变更 db_name = <new name>

edit the controlfile create stmt to “create controlfile reuse set database “dup10g” resetlogs  archivelog ..”

SQL> recover database using backup controlfile until cancel; SQL> alter database open resetlogs;

# 创建密码文件

$ orapwd file=orapwdup10g password=oracle10g

# 你可以移除 DB_UNIQUE_NAME=dup10g如果需要

#这种情况数据dbid和生产相同, 所以你需要更改dbid使用DBNEWID 功能, 使其能在RMAN注册像下面这样:

DBNEWID

# 备份数据库               SQL> shutdown immediate SQL> startup mount

$ nid target=sys/oracle10g@dup10g or nid target=/

SQL> startup mount

SQL> alter database open resetlogs

askmaclean.com

 

副本数据库

  • RMAN使用源数据库备份执行数据库复制

2-   克隆数据库可以:

  1. 完全相同的,
  2. Until point in time in the past within the current incarnation
  3. 包括表空间的子集, 使用SKIP TABLESPACE. (rman 默认跳过离线表空间)
  4. 使用SKIP READONLY 会排除只读表空间
  5. 同源库相同或不同的名字
  6. 不同的主机上有不同或相同的目录结构[NOFILENAMECHECK] (假如在同意主机上复制,必须有不同的目录结构)
  • 可以在不同的或相同的主机上复制
  • 复制数据库可以被来下面这些目的, 例如:
    1. 测试主库备份
    2. 恢复 dropped/truncated 的表 或者恢复错误的 update 对表或者方案直到过去的时间点.
    3. 创建开发/测试用的相同数据库
    4. 创建备库
  • RMAN执行下面这些步骤去复制:
    1. 为副本数据库创建控制文件
    2. 恢复所有的数据文件到副本数据库
    3. 执行不完全恢复 (因为在源库没有备份在线日志)
    4. 使用 RESETLOGS打开副本数据库 (创建standby时跳过)
    5. 为副本数据库产生一个新的,唯一的DBID (创建standby时跳过)
  • 复制期间重命名文件
    1. 控制文件位置和名字取决于 CONTROL_FILES 初始化参数
    2. 数据文件和临时文件名字和位置取决于下面的参数:

DB_FILE_NAME_CONVERT DB_CREATE_FILE_DEST

DB_FILE_NAME_CONVERT语句(DUPLICATE SET)

NEWNAME FOR DATAFILE

CONFIGURE AUXNAME  askmaclean.com

  1. 重做日志文件名字和位置取决于下面的参数:

LOG_FILE_NAME_CONVERT DB_CREATE_ONLINE_DEST_n

DUPLICATE 的LOGFILE 语句 DB_RECOVERY_FILE_DEST

 

 

复制到一个新的主机,有相同的目录结构

在目标主机必须启动辅助实例

  1. 使用最小的参数创建服务器参数文件 DB_NAME

CONTROL_FILES

Compatible=<same as source> sga_target=536870912

 

可选参数:

background_dump_dest= /u01/app/oracle/admin/test10g/bdump user_dump_dest= /u01/app/oracle/admin/test10g/udump core_dump_dest= /u01/app/oracle/admin/test10g/cdump audit_file_dest= /u01/app/oracle/admin/test10g/adump

  1. 创建密码文件

orapwd file=orapwtest10g password=oracle10g

  1. 同 recovery catalog 和目标库建立网络连接 test10g =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST =

sscnjlnx5.us.oracle.com)(PORT = 1521)) (CONNECT_DATA =

(SERVER = DEDICATED) (SERVICE_NAME = test10g) (INSTANCE_NAME = test10g)   ) )

rcvcat = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST =

sscnjlnx5.us.oracle.com)(PORT = 1521)) (CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = rcvcat) (INSTANCE_NAME = rcvcat)    ) )

  1. 确保备份的所有数据文件可以被复制(目标/AUX主机)的主机访问
  2. 启动AUX到mount状态

$ export ORACLE_SID=test10g

$ sqlplus ‘/as sysdba’

startup nomount pfile=/u02/oradata/test10g/inittest10g.ora

  1. RMAN 连接3个实例

rman target sys/oracle10g@test10g auxiliary / catalog rman/rman@rcvcat

run {

# allocate at least one aux channel if not configured already allocate auxiliary channel aux1 device type disk;

duplicate target database to test10g NOFILENAMECHECK;}

 

 

 

Note1: 这种情况下, 你可以添加额外的db参数和网络连接

Note2: RMAN 分配一个新的DBID给复制的数据库          Note3: 复制命令可以在任何一个主机上运行.

Note4: 在这个例子中,复制数据库到新的主机使用相同的数据库名, 你可以更改名字通过指定不同的名字用 “duplicate target database to <>..”

Note5: NOFILENAMECHECK 被使用因为复制数据库使用了相同的目录结构

 

复制到新的主机,使用不同的目录结构                                            同样的步骤和 “复制到新的主机,使用相同的目录结构”,有一些轻微的变动:

1:  使用 DB_FILE_NAME_CONVERT 和 LOGFILE 在复制脚本中去指定新的日志文件和数据文件

2: 指定 DB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT在辅助实例的参数文件.                                                                                                3: 你可以用set  newname 去指定数据文件新的位置在rman脚本中

 

run{

allocate auxiliary channel aux1 device type disk; duplicate target database to test10g

db_file_name_convert=(‘/u02/oradata/test10g/’,’/u02/oradata/test10g/new/’) logfile

group 1 (‘/u02/oradata/test10g/new/redo01.log’) size 50m, group 2 (‘/u02/oradata/test10g/new/redo02.log’) size 50m, group 3 (‘/u02/oradata/test10g/new/redo03.log’)  size 50m; }

 

在同一主机复制

这种类型的复制不同于其他的; 你必须指定不同的位置和不同的名字。

实施这种类型的复制请参考“复制到新的主机,使用不同的目录结构”.

 

复制数据库作为备库

  • RMAN 不能用来创建逻辑备库, 因为它不是块级复制
  • 手动创建standby库 ora
  • 不挂载控制文件启动备库
  • 设置Oracle Net
  • RMAN 备份必须是可读的对备库来说

 

 

  • 物理备库的备份和主库的备份是可互换的,换句话说:
    • 备库的备份可以用来恢复主库
    • 主库的备份可以用来恢复备库
    • 备库的控制文件备份可以恢复不用重建,如果丢失的话
  • 使用RMAN创建备库的优点
    • RMAN 使用主库备份, 所以在主库的操作是不受影响的
    • RMAN 自动重命名文件
    • RMAN 恢复归档日志文件从备份中然后执行恢复备库同步主库

场景:

  • 确保你有主库的备份并上传到备库上去。

RMAN> backup database plus archivelog;

  • 使用RMAN创建备库控制文件

$ rman target sys/oracle10g@test10g catalog rman/rman@rcvcat

RMAN> backup current controlfile for standby; # 位置取决于之前设置的

或者

RMAN> copy current controlfile for standby to ‘/u03/ray/backup/sby_control01.ctl’;

  • 选择文件/日志名字给备库数据文件
备库主机 目录结构 重命名 重命名选项
和主库相同主机名 和主库主机不同 必要. 1- DB_FILE_NAME_CONVERT 和

LOG_FILE_NAME_CONVERT参数在 init.ora中

2- DB_FILE_NAME_CONVERT

3-  设置新的位置

4-  设置数据文件的AUXNAME

 

和主库相同主机名 和主库主机相同 Illegal. NA
和主库不同主机名 和主库主机相同 不必要. 同上面第一个
和主库不同主机名 和主库主机不同 必要. 同上面第一个

 

 

  • 配置备库参数:

DB_NAME=test10g # the same as the primary db DB_UNIQUE_NAME=tstsby CONTROL_FILES=’/u02/oradata/tstsby/new/control01.ctl’, ‘/u02/oradata/tstsby/new/control02.ctl’ STANDBY_FILE_MANAGEMENT=AUTO

STANDBY_ARCHIVE_DEST = ‘/u03/ray/incomarch’ #the location of archive logs arriving from a primary LOG_ARCHIVE_DEST_1=’location=/u03/ray/arch’ LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

CORE_DUMP_DEST=’/u01/app/oracle/admin/tstsby/cdump’ USER_DUMP_DEST=’/u01/app/oracle/admin/tstsby/udump’ AUDIT_FILE_DEST=’/u01/app/oracle/admin/tstsby/adump’ BACKGROUND_DUMP_DEST=’/u01/app/oracle/admin/tstsby/bdump’ LOG_FILE_NAME_CONVERT=’/u02/oradata/test10g/’, ‘/u02/oradata/tstsby/new/’

  • 备库创建密件  orapwd file=orapwtstsby  password=oracle10g
  • 设置网络
    • 添加TNS信息在备库主机用来连接recovery catalog数据库
    • 添加TNS信息在备库主机上用来连接目标库(源库)
    • 添加SID信息在备库的监听上
    • 添加TNS信息在主库主机上为了连接备库
  • 在备库主机上,连接RMAN并运行duplicate

$ export ORACLE_SID=tstsby

$ sqlplus ‘/as sysdba’ SQL> startup nomount; SQL> exit

创建备库没有恢复的情况下 (默认)

$ rman target sys/oracle10g@test10g auxiliary / catalog rman/rman@rcvcat

RMAN> run{

allocate auxiliary channel aux1 device type disk; duplicate target database for standby

 

 

 

db_file_name_convert=(‘/u02/oradata/test10g/’,’/d01/app/oracle/product/or adata/tstsby/’); }

Note:这种情况下RMAN只恢复备库控制文件和数据文件,并且mount备库在没恢复的情况下。你需要恢复数据库并且手动开启自动恢复。

 

你另外能做的是 强制RMAN 恢复到指定的时间, 系统变更号(SCN), 或者 日志文件 sequence number, 或者产生的最后归档日志 如果之前没指定的话

RMAN> run{

allocate auxiliary channel aux1 device type disk; duplicate target database for standby DORECOVER

db_file_name_convert=(‘/u02/oradata/test10g/’,’/u02/oradata/tstsby/new/’);

}

在这种情况, RMAN 让起 mount 并且不放它处于自动恢复模式

  • 在主库上

alter system set log_archive_dest_2=’service=tstsby’ scope=both;

  • 在备库上

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

停止自动恢复

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Note: 不要在 recovery catalog注册备库, 因为这种情况备库还没分配一个新的DBID

 

从物理备库恢复主库

  • 备份被两个系统使用的数据文件和归档日志文件用来恢复
  • 使用备库作为备份主机的优点:
    • 备库备份不会受到生产库事务或者批处理作业的影响. 因此在备库上备份是对生产库影响最小的备份.
    • 备库备份操作不取决于CPU,分配非内存或者其他生产主机的资源 .
  • 只有备库实例产生的归档日志能备份. 如果有归档日志产生在备库开始之前, 必须在主库备份. 例如, 第一个从主库发送到备库的是seq100 thread 1, 然后备份归档日志小于100的必须在主库进行.
  • 主库和备库使用相同的recovery catalog. 尽管有相同的 DBID, RMAN 能区分他们

 

.注意你不需要在catalog注册备库如果主库已经注册. 直接连接备库,然后运行备份命令

  • 最好的练习方法:
    • 控制文件和参数文件 must必须在主库备份,每天都做或者一周一次,取决于应用能忍受丢失程度.总的来说备份主库控制文件当你备份备库的时候

RMAN> connect target <primary database> RMAN> backup current controlfile;

  • 然后备库进行备份 RMAN> connect target <standby database> RMAN> backup database plus archivelog;
  • 如果主库备库重建控制文件 , 主库变成备库或者备份切到主库,你必须catalog所有的归档日志自从上次备份之后。

场景:

  1. 恢复在主库丢失的数据文件使用备库的备份
    • 一起上传丢失的数据文件备份和需要的归档日志到主库服务器上

run {

sql “alter database datafile 4 offline”; restore datafile 4;

recover datafile 4;

sql “alter database datafile 4 online”; }

 

  1. 恢复备库丢失的数据文件使用备库的备份

run {

sql ” alter database recover managed standby database cancel;”; restore datafile 4;

sql ‘alter database recover managed standby database disconnect from session’;}

Note: 不需要恢复数据文件,因为MRP进程会自动完成。.

 

  1. 恢复备库丢失的控制文件使用备库的备份

Note: 连接RMAN恢复控制文件,会出现下面报错:

ORA-00210: cannot open the specified control file

 

 

ORA-00202: control file: ‘/d01/app/oracle/product/oradata/tstsby/control01.ctl’ ORA-27041: unable to open file

Linux Error: 2: No such file or directory Additional information: 3

 

恢复备库的控制文件:

SQL> shutdown abort run {

startup nomount

restore controlfile from autobackup; startup mount

sql ‘alter database recover managed standby database disconnect from session’;}

 

你也可以从主库创建控制文件,然后上传到备库:

SQL> alter database create standby controlfile as ‘/tmp/ control01.ctl’;

  • 然后上传到备库

Note: 你不能停止恢复,如果你这么做了,会出现控制文件错误:

SQL> shutdown abort # 在备库操作   SQL> startup mount;

  • 然后重命名数据文件如果备库使用不同的路径:

SQL> alter system set STANDBY_FILE_MANAGEMENT = MANUAL; SQL> alter database rename file ‘/u02/oradata/test10g/sysaux01.dbf’ to ‘/d01/app/oracle/product/oradata/tstsby/sysaux01.dbf’;

SQL> alter database rename file ‘/u02/oradata/test10g/system01.dbf’ to ‘/d01/app/oracle/product/oradata/tstsby/system01.dbf’;

SQL> alter database rename file ‘/u02/oradata/test10g/undotbs01.dbf’ to ‘/d01/app/oracle/product/oradata/tstsby/undotbs01.dbf’;

SQL> alter database rename file ‘/u02/oradata/test10g/users01.dbf’ to ‘/d01/app/oracle/product/oradata/tstsby/users01.dbf’;

SQL> alter system set STANDBY_FILE_MANAGEMENT = AUTO;

  • 开始应用redo

sql> alter database recover managed standby database disconnect from session;

 

或者你可以使用RMAN做这些:

RMAN> copy current controlfile for standby to ‘/u03/ray/backup/control01.ctl’;

  • 上传到备库,
  • 关闭备库实例
  • 挂载控制文件

 

 

  • 禁用文件自动管理 (STANDBY_FILE_MANAGEMENT= MANUAL)
  • 重命名数据文件
  • 启用文件自动管理 (STANDBY_FILE_MANAGEMENT = AUTO)
  • 然后应用redo

Note:创建的控制文件丢失所有它创建之前的归档日志。因为RMAN 通过控制文件的的归档日志列表备份,从上次备份之后产生的所有归档日志必须手动catalog.

  1. 恢复备库丢书的控制文件如果没有可用的备份
    • 从主库创建备库控制文件

$rman sys/oracle10g@test10g nocatalog

RMAN> backup current controlfile for standby format ‘/tmp/stdby2_ctl.bck’; exit

  • 上传到备库 scp  bck nerlinux03:/tmp
  • 执行备库控制文件的恢复  run {

Startup nomount

restore standby controlfile from ‘/tmp/stdby2_ctl.bck’ alter database mount;

catalog start with ‘/d01/app/oracle/product/oradata/tstsby/’; switch database to copy;

sql ‘alter database recover managed standby database disconnect from session’;}

Note: Catalog 和 Switch 命令 不需要执行如果备库有相同的目录结构

 

  1. 恢复主库丢失的控制文件

自从你使用备库作为一个备份主机, 假如你丢失主库控制文件你不能使用备库的控制文件恢复主库控制文件因为它不是current。 这就是为什么之前说主库备份控制文件和参数文件非常重要。然而,如果主库的备份不可用,有以下两种方法:

 

  • 重建控制文件使用 NORESETLOGS选项
  1. 在备库上, 使用 NORESETLOGS选项创建trace文件 alter database backup controlfile to trace noresetlogs;
  2. 编辑trace文件并放到适当的位置
  3. 启动主库到nomount
  4. 重建控制文件

 

 

  1. 使用resetlogs打开数据库
  2. 然后添加临时文件,这是无论怎么重建控制文件都要做的

 

  • 如果你不能执行之前的步骤,你可以从备份中恢复控制文件并resetlogs打开数据库:

run {

startup nomount; restore controlfile; startup mount; restore database;

alter database open resetlogs; }

  1. 恢复主库丢失在线重做日志文件
  2. Inactive Archived

你可以删除然后重建,例如:            SQL> alter database drop logfile group 2;

SQL> alter database add logfile group 2 ‘/u02/oradata/test10g/redo02.log’ size 50M;

SQL> alter database add logfile member ‘/u02/oradata/test10g/redo02.log’ reuse to group 2;

 

  1. Current 或 Aactive not arcived

你必须切换到备库

  1. 为了解决归档日志差距问题,对备库做一些差距检查,并上传所有的归档日志到备库。

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

  1. 检查每个线程最大的seq号,然后从主库上传所有高seqence的归档日志:

SQL> select unique thread# as thread, max(sequence#)over (partition by thread#) as last

from v$archived_log;

  1. 注册所有来自步骤1和2的新的归档日志  sql> alter database register physical logfile ‘?/?/?xyz.arch’;

Note:如果执行第三步中来自步骤1的部分,你不能解决归档日志的差距(例如,因为你连接主库失败导致没访问系统),一些数据会丢失在切换期间。

  1. 强制恢复结束意味着终止所有inactive redo传输。

alter database recover managed standby database finish force;

  1. alter database commit to switchover to primary;

 

 

or alter database activate standby database # 这个将导致一些数据丢失, 如果之前执行reslove gap。

  1. 如果备库自从上次启动之后从没开启到只读模式,你可以“alter database open”
  2. 如果备库自从上次启动之后一直处于只读模式,先shutdown immediate然后startup
RMAN 配置
  • 配置控制文件自动备份开启:

自动备份能让RMAN恢复数据库即使当前控制文件,catalog和参数文件丢失。

因为自动备份的文件名使用了众所周知的格式, RMAN 可以不实用知识库去寻找它, 然后恢复参数文件. 通过恢复的参数文件启动实例后, RMAN 可以从自动备份恢复控制文件. 挂载控制文件之后, RMAN 知识库变得可用,RMAN 可以恢复数据文件和寻找归档日志.

CONFIGURE CONTROLFILE AUTOBACKUP ON;

默认的格式是 c-<dbid>-<timestamp>-<hex sequence>, 如果你像改变格式:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR

DEVICE TYPE DISK TO ‘/u01/ray/backup/cf_%F’; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘+dgroup1/%F’;

  • 配置默认的写介质,格式和并行度 CONFIGURE DEFAULT DEVICE TYPE TO disk|sbt; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT

‘/u01/ray/backup/%U’;

CONFIGURE CHANNEL DEVICE TYPE ‘SBT_TAPE’ PARMS

‘ENV=mml_env_settings’ FORMAT   ‘%U’; CONFIGURE DEVICE TYPE sbt PARALLELISM 3; CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

  • 配置保留策略

保留备份能恢复数据库到过去几天的任何一个时间点,或者保留每个数据文件的备份:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 20 DAYS;

CONFIGURE RETENTION POLICY TO REDUNDANCY 4;

  • 配置归档日志的删除策略

确保闪回区删除归档日志被强制应用于备库

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

 

 

  • 增加 CONTROL_FILE_RECORD_KEEP_TIME到一个更高的值, 防止你需要目标数据库恢复,但RMAN recover catalog 不可用。
常用RMAN维护命令

 

  • 查询RMAN中备份和副本信息的状态,而不是介质像磁盘或者磁带

EXPIRED =备份没有被找到在备份位置         AVAILABLE =备份是可用的                      UNAVAILABLE =备份是不可用的

 

crosscheck backup; # 核对 备份集 和 映像副本         crosscheck backup of database | controlfile | archivelog all; crosscheck copy of database | controlfile | archivelog all

 

Note:如果EXPIRED备份后来变available,下次crosscheck将标记成AVAILABLE。

 

  • 显示知识库中备份集信息,proxy copies信息, 和映像副本信息

List incarnation of database <db_name>;

 

List BACKUP | backupset | COPY

List backup of database | controlfile | spfile | archivelog all; List backup of database by file|summary

 

List all|global script

List expired backup of database| archivelog all| controlfile |spfile | 3-   去执行RMAN知识库的详细分析结果

Report need backup Report obsolete Report  schema Report unrecoverable;

4- 删除物理备份和副本同时更新目标控制文件并从catalog移除知识库中的记录

Delete noprompt obsolete; Delete noprompt expired; Delete backup |of

Delete copy | of

DELETE backup of database  completed before ‘sysdate -1’;

 

 

5-   删除指定的备份集:

Change backupset <BS_Key> delete;

 

 

 

 

 

 

 

演练:

 

完全介质恢复

  1. 丢失数据文件

场景一:系统层面丢失数据文件有完整的rman备份

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

模拟丢失数据文件

[oracle@dbdao orcl]$ mv test02.dbf  bak.dbf

关闭再打开数据库时报错

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

ORA-01110: data file 6: ‘/u01/oracle/app/oradata/orcl/test02.dbf’

 

恢复方法:

[oracle@dbdao ~]$ rman target /

run {

shutdown abort;

startup mount;

restore datafile 1;

recover datafile 1;

alter database open;

}

 

打开数据库后查询,发现已经恢复

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

恢复数据文件到不同的位置

run {

shutdown abort;

startup mount;

set newname for datafile 6 to ‘/tmp/test02.dbf’;

restore datafile 6;

switch datafile all;

recover datafile 6;

alter database open;

}

 

 

 

场景二:非系统层面丢失数据文件

SQL> alter database datafile 6 offline drop;

 

Database altered.

 

SQL> select * from test02.torder;

select * from test02.torder

*

ERROR at line 1:

ORA-00376: file 6 cannot be read at this time

ORA-01110: data file 6: ‘/u01/oracle/app/oradata/orcl/test02.dbf’

 

恢复方法

在线直接恢复

RMAN> run{

2> restore datafile 6;

3> recover datafile 6;

4> sql “alter database datafile 6 online”;

5> }

 

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

恢复都不同的位置

RMAN> run{

2>sql “alter database datafile 6 offfline”;

3>set newname for datafile 6 to ‘/u01/oracle/app/oradata/test02.dbf’;

4> restore datafile 6;

5>switch datafile all;

6> recover datafile 6;

7> sql “alter database datafile 6 online”;

8> }

 

 

场景三:丢失整个数据库

删除oradata下面的所有数据文件文件

[oracle@dbdao orcl]$ rm -rf *

 

[oracle@dbdao orcl]$ rman target /

 

RMAN>

run {

startup nomount;

restore controlfile from ‘/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917622140_crvn3xbh_.bkp’;

startup mount;

restore database;

recover database;

alter database open resetlogs;

}

 

Oracle instance started

 

Total System Global Area     839282688 bytes

 

Fixed Size                     2233000 bytes

Variable Size                553651544 bytes

Database Buffers             281018368 bytes

Redo Buffers                   2379776 bytes

 

Starting restore at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

 

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/u01/oracle/app/oradata/orcl/control01.ctl

output file name=/u01/oracle/app/fast_recovery_area/orcl/control02.ctl

Finished restore at 19-JUL-16

 

database is already started

database mounted

released channel: ORA_DISK_1

 

Starting restore at 19-JUL-16

Starting implicit crosscheck backup at 19-JUL-16

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

Crosschecked 7 objects

Finished implicit crosscheck backup at 19-JUL-16

 

Starting implicit crosscheck copy at 19-JUL-16

using channel ORA_DISK_1

Finished implicit crosscheck copy at 19-JUL-16

 

searching for all files in the recovery area

cataloging files…

cataloging done

 

List of Cataloged Files

=======================

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917622140_crvn3xbh_.bkp

 

using channel ORA_DISK_1

 

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 /u01/oracle/app/oradata/orcl/system01.dbf

channel ORA_DISK_1: restoring datafile 00003 to /u01/oracle/app/oradata/orcl/undotbs01.dbf

channel ORA_DISK_1: restoring datafile 00007 to /u01/oracle/app/oradata/orcl/test03.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx4vg_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx4vg_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:35

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 /u01/oracle/app/oradata/orcl/sysaux01.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx42n_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx42n_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:15

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 00004 to /u01/oracle/app/oradata/orcl/users01.dbf

channel ORA_DISK_1: restoring datafile 00005 to /u01/oracle/app/oradata/orcl/test01.dbf

channel ORA_DISK_1: restoring datafile 00006 to /u01/oracle/app/oradata/orcl/test02.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx47m_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx47m_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:35

Finished restore at 19-JUL-16

 

Starting recover at 19-JUL-16

using channel ORA_DISK_1

 

starting media recovery

 

archived log for thread 1 with sequence 4 is already on disk as file /u01/oracle/app/oradata/orcl/redo01.log

archived log for thread 1 with sequence 5 is already on disk as file /u01/oracle/app/oradata/orcl/redo02.log

archived log file name=/u01/oracle/app/oradata/orcl/redo01.log thread=1 sequence=4

archived log file name=/u01/oracle/app/oradata/orcl/redo02.log thread=1 sequence=5

media recovery complete, elapsed time: 00:00:02

Finished recover at 19-JUL-16

 

database opened

 

 

 

 

 

 

 

不完全恢复

  1. 丢失控制文件(noresetlogs)
数据库处于开启状态,模拟丢失控制文件

[root@dbdao orcl]# mv control01.ctl control01.ctl.bak

 

[oracle@dbdao orcl]$ mv control02.ctl control02.ctl.bak

 

恢复过程

使用语句获得跟踪日志

SQL> alter database backup controlfile to trace noresetlogs;

 

Database altered.

 

在alert文件找到跟踪文件位置

alter database backup controlfile to trace noresetlogs

Backup controlfile written to trace file /u01/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2169.trc

 

获得建立控制文件语句

CREATE CONTROLFILE REUSE DATABASE “ORCL” NORESETLOGS  ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 ‘/u01/oracle/app/oradata/orcl/redo01.log’  SIZE 50M BLOCKSIZE 512,

GROUP 2 ‘/u01/oracle/app/oradata/orcl/redo02.log’  SIZE 50M BLOCKSIZE 512,

GROUP 3 ‘/u01/oracle/app/oradata/orcl/redo03.log’  SIZE 50M BLOCKSIZE 512

— STANDBY LOGFILE

DATAFILE

‘/u01/oracle/app/oradata/orcl/system01.dbf’,

‘/u01/oracle/app/oradata/orcl/sysaux01.dbf’,

‘/u01/oracle/app/oradata/orcl/undotbs01.dbf’,

‘/u01/oracle/app/oradata/orcl/users01.dbf’,

‘/u01/oracle/app/oradata/orcl/test01.dbf’,

‘/u01/oracle/app/oradata/orcl/test02.dbf’,

‘/u01/oracle/app/oradata/orcl/test03.dbf’

CHARACTER SET AL32UTF8

;

 

关闭数据库,启动到nomount

SQL> startup nomount

ORACLE instance started.

 

Total System Global Area  839282688 bytes

Fixed Size              2233000 bytes

Variable Size                553651544 bytes

Database Buffers      281018368 bytes

Redo Buffers                 2379776 bytes

 

执行上面的语句,生成控制文件

 

SQL> alter database open;

 

Database altered.

 

丢失控制文件(resetlogs)

关闭数据库,启动到nomount状态

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup nomount

ORACLE instance started.

 

Total System Global Area  839282688 bytes

Fixed Size              2233000 bytes

Variable Size                553651544 bytes

Database Buffers      281018368 bytes

Redo Buffers                 2379776 bytes

 

RMAN> restore controlfile from ‘/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp’;

 

Starting restore at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1 device type=DISK

 

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/u01/oracle/app/oradata/orcl/control01.ctl

output file name=/u01/oracle/app/fast_recovery_area/orcl/control02.ctl

Finished restore at 19-JUL-16

 

RMAN> startup mount

 

database is already started

database mounted

 

RMAN> recover database;

 

Starting recover at 19-JUL-16

Starting implicit crosscheck backup at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=20 device type=DISK

Crosschecked 3 objects

Finished implicit crosscheck backup at 19-JUL-16

 

Starting implicit crosscheck copy at 19-JUL-16

using channel ORA_DISK_1

Finished implicit crosscheck copy at 19-JUL-16

 

searching for all files in the recovery area

cataloging files…

cataloging done

 

List of Cataloged Files

=======================

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_98_crvkzy4c_.arc

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_99_crvkzy6d_.arc

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc

 

using channel ORA_DISK_1

 

starting media recovery

 

archived log for thread 1 with sequence 100 is already on disk as file /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc

archived log for thread 1 with sequence 101 is already on disk as file /u01/oracle/app/oradata/orcl/redo02.log

archived log file name=/u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc thread=1 sequence=100

archived log file name=/u01/oracle/app/oradata/orcl/redo02.log thread=1 sequence=101

media recovery complete, elapsed time: 00:00:01

Finished recover at 19-JUL-16

 

 

RMAN> alter database open resetlogs;

 

database opened

 

 

  1. Active状态的已归档的在线日志
SQL>

select l.group#,l.thread#, lf.member,l.status,l.archived from v$log l , v$logfile lf

2  where l.group# = lf.group#;

 

GROUP#    THREAD# MEMBER                                        STATUS      ARC

———- ———- ——————————————          —————-   —

3         1 /u01/oracle/app/oradata/orcl/redo03.log   CURRENT         NO

2         1 /u01/oracle/app/oradata/orcl/redo02.log   ACTIVE                YES

1         1 /u01/oracle/app/oradata/orcl/redo01.log   INACTIVE         YES

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. 用户误操作(删除一个表)在同一个主机上恢复
模拟错误,drop一个表

SQL> drop  table auchan.torder;

 

Table dropped.

 

模拟恢复过程

1.       新建参数文件,并修改部分参数

[oracle@dbdao01 dbs]$ vi initaux.ora

db_name=’dbdao01′

service_names=’aux’

db_unique_name=’aux’

control_files=’/u01/app/oracle/oradata/aux/control01.ctl’

2.       设置ORACLE_SID

[oracle@dbdao01 ~]$ export ORACLE_SID=aux

3.       创建密码文件

[oracle@dbdao01 dbs]$ orapwd file=orapwdaux password=oracle entries=30

4.       配置tnsname和listener

在listener.ora添加

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = aux)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = aux )

)

)

在tnsname.ora添加

aux =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = dbdao01)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = aux)

 

重启监听,配置完毕

5.       连接rman从dbdao01中恢复控制文件到aux库(以启动到nomount,用之前的参数文件)

[oracle@dbdao01 admin]$ rman target / catalog rman/oracle@dbdao02

RMAN> run{

2> set until time “TO_DATE(’21/JUL/2016 14:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

3> restore controlfile  to ‘/u01/app/oracle/oradata/aux/control01.ctl’ from ‘/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/o1_mf_s_917793936_cs0vwjpk_.bkp’;

4> }

6.       恢复数据库到aux实例上

[oracle@dbdao01 ~]$ rman target / nocatalog(为了使用控制文件上的备份信息)

 

run{

startup mount

set until time “TO_DATE(’21/JUL/2016 15:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

set newname for datafile 1 to ‘/u01/app/oracle/oradata/aux/system01.dbf’;

set newname for datafile 2 to ‘/u01/app/oracle/oradata/aux/sysaux01.dbf’;

set newname for datafile 3 to ‘/u01/app/oracle/oradata/aux/undotabs01.dbf’;

set newname for datafile 4 to ‘/u01/app/oracle/oradata/aux/users01.dbf’;

set newname for datafile 5 to ‘/u01/app/oracle/oradata/aux/example01.dbf’;

restore datafile 1,2,3,4,5;

switch datafile all;

sql “alter database datafile 1,2,3,4,5 online”;

recover database;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo01.log” to ”/u01/app/oracle/oradata/aux/redo01.log””;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo02.log” to ”/u01/app/oracle/oradata/aux/redo02.log””;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo03.log” to ”/u01/app/oracle/oradata/aux/redo03.log””;

alter database open resetlogs;

}

7.       将丢失的表导出再倒回原来的数据库

SQL> select count(*) from auchan.torder;

 

COUNT(*)

———-

91982

数据已经恢复,将表导出

[oracle@dbdao01 ~]$ exp auchan/oracle file=torder.dmp tables=torder

再导入原来的库中

[oracle@dbdao01 ~]$ imp auchan/oracle file=torder.dmp fromuser=auchan touser=auchan tables=torder

 

在查询生产库

SQL> select count(*) from auchan.torder;

 

COUNT(*)

———-

91982

8.       最后删除辅助实例

过程略

  1. 用户误操作恢复到不同的主机上

步骤和上面基本相同,除了恢复控制文件时,恢复到一个指定位置,然后上传到要进行恢复的主机上。

 

  1. 恢复整个表空间
  2. 挑选目标时间,一般根据OracleFlashback Query , Oracle Transaction Query 和Oracle Flashback Version Query去寻找时间点。
  3. 分析数据关联

select * from sys.ts_pitr_check  where ( ts1_name in (‘torder’) and ts2_name not in (‘torder’)) or ( ts1_name not in (‘torder’)  and ts2_name in (‘torder’) );

  1. 确认执行后会丢失的对象

select owner, name, tablespace_name ,to_char(creation_time, ‘yyyy-mm- dd:hh24:mi:ss’) from ts_pitr_objects_to_be_dropped where tablespace_name in (‘users’,’tools’) and creation_time > to_date(’01-jan-09:15:04:00′,’yy-mon-dd:hh24:mi:ss’) order by tablespace_name, creation_time;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

恢复数据库到新的主机上

  1. 记录源库dbid
SQL> select dbid from v$database;

 

DBID

———-

3800849824

 

  1. 获得源库的文件列表
SQL> col name for a60

SQL> col member for a60

SQL> select file# as “file/grp#”, name from v$datafile;

 

file/grp# NAME

———- ————————————————————

1 /u01/app/oracle/oradata/dbdao01/system01.dbf

2 /u01/app/oracle/oradata/dbdao01/sysaux01.dbf

3 /u01/app/oracle/oradata/dbdao01/undotbs01.dbf

4 /u01/app/oracle/oradata/dbdao01/users01.dbf

5 /u01/app/oracle/oradata/dbdao01/example01.dbf

 

SQL> select group#,member from v$logfile;

 

GROUP# MEMBER

———- ————————————————————

3 /u01/app/oracle/oradata/dbdao01/redo03.log

2 /u01/app/oracle/oradata/dbdao01/redo02.log

1 /u01/app/oracle/oradata/dbdao01/redo01.log

 

  1. 复制源库的参数文件上传到新主机上
[oracle@dbdao01 dbs]$ scp initdbdao01.ora dbdao02:/u01/app/oracle/product/11.2.0/db_1/dbs/

 

 

  1. 上传备份集到新主机,和源库相同位置
[oracle@dbdao01 2016_07_21]$ scp * dbdao02:/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/

oracle@dbdao02’s password:

o1_mf_s_917793936_cs0vwjpk_.bkp 100% 9600KB   9.4MB/s   00:00

o1_mf_s_917796181_cs0y2o7q_.bkp 100% 9600KB   9.4MB/s   00:00

 

[oracle@dbdao01 DBDAO01]$ scp backupset/2016_07_21/* dbdao02:/u01/app/oracle/fast_recovery_area/DBDAO02/backupset

oracle@dbdao02’s password:

o1_mf_annnn_TAG20160721T144230_ 100% 4095KB   4.0MB/s   00:00

o1_mf_annnn_TAG20160721T144534_ 100%   22KB  21.5KB/s   00:00

o1_mf_ncnnf_TAG20160721T152257_ 100% 9568KB   9.3MB/s   00:00

o1_mf_nnndf_TAG20160721T144232_ 100% 2115MB  24.6MB/s   01:26

 

  1. 在新主机上进行恢复
[oracle@dbdao02 ~]$ export ORACLE_SID=dbdao01

[oracle@dbdao02 ~]$ rman target / nocatalog

RMAN> set dbid 3800849824

 

executing command: SET DBID

RMAN> startup nomount

 

Oracle instance started

 

RMAN> restore controlfile from ‘/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/o1_mf_s_917793936_cs0vwjpk_.bkp’;

output file name=/u01/app/oracle/oradata/dbdao01/control01.ctl

output file name=/u01/app/oracle/fast_recovery_area/dbdao01/control02.ctl

Finished restore at 21-JUL-16

 

RMAN> alter database mount;

 

database mounted

released channel: ORA_DISK_1

 

 

因为路径都完全相同,所以这里直接恢复即可

RMAN> run{

set until scn 1090728;

restore database;

switch datafile all;

recover database;

alter database open resetlogs;

}

 

database opened

 

恢复成功。

 

 

 

恢复数据库在相同的主机

基本同上一个实验,注意设置新的dbid

 

诗檀软件帮助广州某制造企业恢复ORACLE数据库

广州某制造企业的金蝶SHR人力管理系统的后台Oracle数据库出现无法打开OPEN DATABASE的问题:

 

ORA-00600: internal error code, arguments: [3020], [2], [99072], [8487
[], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 99072
offset is 811597824 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DB
ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'

诗檀软件工程师王工基于ORACLE底层数据块至少快速修复了该SHR后台 ORACLE数据库。

金蝶 EAS 财务、SHR人力 系统后台 ORACLE损坏请找 诗檀软件快速恢复!

 

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

【MySQL学生手册】binary备份 vs 文本备份

本文地址:http://www.askmaclean.com/archives/mysql-binary-vs-text-backup.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

Mysql技术学习QQ群:146959374

 

11.2 binary备份 vs 文本备份

当备份数据库时,你有两种备份格式可选:

  • 二进制(binary)备份是一种对数据库中存储的内容文件的拷贝。这种拷贝实际上使得备份文件格式和MySQL在磁盘上存储的数据库文件格式保持了完全一致。因此此类数据库恢复则涉及将这些文件拷贝回它原有的位置。建立binary备份的技术包括使用文件拷贝命令(如cp或tar),mysqlhotcopy以及InnoDB Hot Backup**。
    ** 需要注意的是mysqlhotcopy从MySQL 5.7及其之后就被去除了,相关功能被融合到了其企业版MySQL Enterprise Backup工具mysqlbackup中。而InnoDB Hot Backup原先是商用软件的一部分,在MySQL Enterprise Backup 3.9之后其相应工具也被融合入mysqlbackup中。
  • 文本备份则是将数据库内容导出(dump)至文件文件中。恢复则涉及到通过处理这些文件的内容将数据返回到数据库中。生成文本备份的技术包括了使用SELECT … INTO OUTFILE 的SQL语句,mysqldump工具等。

 

这两种备份格式有其不同的优缺点。通常选择使用何种备份的考虑因素是对速度和便携性之间的权衡。

 

由于二进制备份仅是对文件进行拷贝操作,它不需要了解文件中的内部结构,因此在速度上这种备份速度会更快。然而,如果需要将这种备份传输到另一个使用不同架构的机器上,那么文件就需要更多考虑二进制的便携性。意思就是这些文件需要平台无关化才行,这样你才能直接拷贝它们,从一个MySQL服务端传输到另一个处于不同服务器上的数据库中,而且这第二个服务端需要能够没有任何问题地访问这些文件的内容。使用二进制备份方法,你还需要确保在进行备份的时候,服务端不会对在被拷贝的文件进行修改。【dbdao.com 数据岛】

[Read more…]

Oracle PRM-DUL Undelete Oracle record/rows

Download PRM-DUL http://www.parnassusdata.com/en

On scenarios without valid physical or logical backups, when a mistaken delete occurred in Oracle, it will be given priority to use techniques such as flashback or logminer to recover the data rows in Oracle tables in general, but in many cases even flashback or logminer could not turn the tide.

For the row piece in the underlying data block of Oracle, delete operation only modify the row flag and mark them as deleted. It allows records of the subsequent INSERT to override these data marked as delete, and also allows to destroy the structure of these data that are deleted. In other words, if no operations has been done on tables after delete, it is possible to read the complete data by directly reading those records that are marked as deleted in blocks.

 

In a word, whether it can recover the deleted data or not all depends on whether the deleted data rows in oracle block on the disk have been eventually cleared or not.

 

As soon as it has not been cleared, ORACLE PRM-DUL can attempt to recover the data, and the specific steps has little difference with the ordinary data dictionary mode.

 

Start up the PRM – DUL, click the restore wizard in dictionary mode
prm-undelete1

prm-undelete2

 

 

 

prm-undelete4

prm-undelete5

 

Add all of the Oracle data files, no TEMPFILE, UNDO data files, control files, log files is required.

prm-undelete6

 

Click the load button, PRM will automatically load the data dictionary, i.e. bootstrap operation

 

prm-undelete7

ow on the left of PRM, you will see the object tree, select the corresponding data table under the user that you need to recover, right-click the object and then select unload deleted data.

prm-undelete8

 

prm-undelete9

After completing the recovery of the deleted data, PRM-DUL will write the data to the location of File path in the picture above, the Sample data recovery is as follows.

prm-undelete10

 

okex.com c2c 类场外交易BTC交易教程

比特币BITCOIN BTC 以太坊 ETHEREUM ETH 莱特币LITECOIN LTC 、TEZOS $XTZ 、EOS $EOS 等ICO资产托管增值服务 QQ:47079569

比特币钱包BITCOIN CORE WALLET wallet.dat密码恢复服务,请找数据恢复服务商 QQ:47079569

Genesis Mining 比特币云挖矿优惠码

嫌自己挖矿麻烦?你可以使用云挖矿

节约4%的成本获得更多的算力:cjVGvt

点击访问世界最大云挖矿服务商 genesis-mining 官方网站

点击下载genesis-mining云挖 矿购买使用指南

 

OKEx关于上线C2C交易平台的公告

你们好,今天我们很高兴跟大家分享我们的喜悦:

10月31日,OKEx将会开放全球首创的C2C交易平台,提供比特币等数字资产的点对点交易服务。

随着比特币成交价突破6000美金,市值也超过1000亿美元,其背后的区块链技术带来的技术革命以及比特币数量有限等特性使得比特币成为近几年来最佳的投资风险产品。为了让世界各国用户可以简单便捷的使用本地法币购买或出售比特币等数字资产,OKEx推出了C2C交易这款创新产品。

OKEx C2C交易平台的用户有两种角色:用户和商家。用户定义为投资数字资产的人,其目的是在不同的价格买入或卖出数字资产;商家定义为随时愿意和用户做交易对手,可以自我通过提前购买比特币、合约对冲、价格预测等手段来控制风险的人。

整个C2C交易分为投资交易区、开放交易区。
1)投资交易区帮普通用户更简单便捷的使用本地法币投资比特币,但没有提币需求的用户。用户可以随时按OKEX指数价格上浮或下浮一定比例来买入或卖出比特币,交易对手为商家,配单成功以后给商家转账本地法币,即可完成交易,投资区采用法币进法币出,数字资产进数字资产出的运营策略,即无论用户或商家,充进N个比特币,只能提走N个比特币,多余的部分只能卖出为法币。

2)开放交易区定位于购买比特币有提现需求的用户。用户可以自己决定买入或卖出价格,用户和商家之间自由选择成交。

OKEx会通过强大的KYC和反洗钱系统帮助用户和商家规避风险,目前首期上线的为投资区,购买区也会尽快上线。
OKEx-C2C交易平台有如下特点:
1、市场一口价定价:
以OK价格指数(根据全球四大现货交易所加权平均所得)为基准,以及OKEx-C2C实时购买趋势计算买卖比例,实时计算得出。

2、用户完全免手续费:
用户所见即所得,买卖价格外,无需任何平台手续费。

3、即时成交:
引入平台服务商家,智能匹配,成交订单,无须等待撮合。行情快人一步。

4、平台担保交易
平台认证商家,安全有保障,24小时客户服务为您的交易保驾护航。
最后OKEx-C2C交易平台在此向全球招募C2C商家,成为平台商家可享受OKEx优质的流量,享受平台买卖价差带来的丰厚利润。我们将严格审核商家资格,只有资金量充足,服务用户能力强的商家可以获得批准,如果您有意成为OKEX C2C商家,请将个人资料(个人联系方式、身份证证明文件、个人简介、数字资产拥有量、是否从事过数字资产交易)发送邮件至team@okex.com。我们会尽快审核您的申请。

OKEx始终坚持提供给用户更易用,更快速,更安全的产品体验。

更多交易方式,更多币种,更多国家货币,马上到来。

OKEx-C2C产品&运营团队
2017-10-30晚

 

如何认证?

 

PC端:

1.点击“个人中心”-“基础设置”-“身份认证”,按照提示填写姓名和身份证信息;

1.png

 

2.完成基础认证;若单笔超过200000元的交易,需进行高级身份认证,点击“继续完成级别2验证”;

2.png

 

3.上传身份证正面、反面及手持身份证照片,点击“提交”,完成身份认证;

3.png

 

4.进行视频认证,点击“去下载”前往OKEx APP-“我的”-“身份认证”,进行视频认证即可;

4.png

 

APP端(以iOS为例):

1.点击“我的”-“身份认证”,选择“级别1”,去认证;

5.png

 

2.按照提示填写姓名、手机号,点击“提交”,完成级别1认证;

6.png

 

3.选择“级别2”,点击“去认证”;

7.png

 

4.按照提示上传身份证正面照、身份证反面照、手持身份证照片,即可完成“级别2”认证;

8.png

9.png

10.png

5.同理,选择“级别三”,点击“去认证”,完成视频认证。

 

如何充值与交易?

如何充值:

充币:

点击“C2C交易”,点击“充币”,自动跳转“资金管理”页面,可在“账户余额”下查看C2C交易账户;

以BTC为例,点击“转入”,可按照所需划转数量从现货账户划转到C2C账户,即可完成充币。

11.png

22.png

 

绑定银行卡/微信/支付宝:

1、点击“个人中心”-“基本设置”-“C2C交易设置”,可支持银行转账、微信支付及支付宝。

33.png

  • 银行转账

点击“开启”,填写姓名、开户行、开户支行、银行卡号、确认卡号,后点击“确认”即可完成设置;

44.png

  • 微信及支付宝支付(以微信为例)

点击“开启”,填写微信支付收款人姓名、微信支付账号、微信支付收款码(若不知道如何获取收款码,可点击蓝色字体提示,会出现相应教程)。

55.png

 

如何交易

点击“C2C交易”,可在左侧栏选择BTC/LTC/ETH/ETC/BCC交易,以BTC为例,可根据提示的买入价格和卖出价格,填写买入/卖出数量、买入/卖出金额,快速实现交易。

66.png

 

 

【MySQL学生手册】备份和恢复

本文地址:http://www.askmaclean.com/archives/mysql-backup_recovery_knowledge.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

Mysql技术学习QQ群:146959374

 

第11章 备份和恢复

 

章节概述

本章介绍了MySQL数据备份和恢复。你将学习并了解:

  • 备份的类型
  • 进行二进制备份和文本备份
  • 备份中日志和状态文件的角色作用
  • 使用一个复制从库(replication slave)来进行备份
  • 进行数据恢复
  • 倒入数据文件

 

11.1 备份概述

MySQL数据库备份一般用于应对可能的系统崩溃或硬件故障而导致的数据损失或讹误问题。备份同样对于用户误操作,如误删数据库或表等恢复有帮助。也有时候备份被用于将数据库拷贝或移动到另一个服务器中,如当你需要进行MySQL安装迁移,或建立一个复制从库时。

 

备份可以是对数据文件的直接拷贝,或是通过设计程序来完成同样的备份目的。这些程序包括mysqldump,mysqlhotcopy和InnoDB Hot Backup。

 

对于数据库运维,备份总是必要的,不过备份仅仅是在数据受损后所需进行数据恢复的组件之一。其它的你还需要二进制日志(binary log)文件,它包含了数据修改的记录。进行数据库恢复时,你使用备份将数据库恢复到备份时的状态,然后重新执行binary log中包含的语句来应用备份后的数据修改。

 

这里列出了在进行备份时需要记住的一些原则:

  • 制作一般备份。
  • 启用binary log,这样你在进行备份后,对数据修改的记录将会被保存在日志文件中。
  • 在备份后,使用flush命令,使得服务端从一个新的binary log文件开始,这个日志文件对应了备份的时间(也就是说,将此备份后的日志看作是一个“检查点”,从这个时间后开始的日志记录是备份之后新的数据修改)。
  • 将数据文件目录和你的备份放置在不同的物理设备中,这样一旦某个设备出现故障,不会造成同时被影响的后果。
  • 将你的备份存在在通常合理的文件系统位置中,这样一旦需要就可以从这些位置上找到备份进行恢复。【dbdao.com 数据岛】

[Read more…]

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569