ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 物理dg的维护

物理dg的维护

原创 Linux操作系统 作者:jjslove 时间:2012-03-20 22:26:52 0 删除 编辑
一:physic standby 的维护:

      1:启动并挂载 physic standby database


      startup mount;

           

      2:  开始重做应用或 实时重做应用:

          alter database recover managed standby database disconnect from session;
          alter database reocver managed standby database using current logfile disconnect from session;


          a

      3:  主数据库查看重做应用模式(普通,实时)例子是普通重做应用

        
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

RECOVERY_MODE
-----------------------
IDLE
MANAGED
MANAGED
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE


  
     4:背库上查看重做应用模式,如果MRP0 或MRP 进程存在,则备数据库应用重做
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

PROCESS   STATUS
--------- ------------
ARCH      CLOSING
ARCH      CLOSING
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE
RFS       IDLE

PROCESS   STATUS
--------- ------------
RFS       IDLE
RFS       IDLE
RFS       IDLE
MRP0      WAIT_FOR_LOG

    5:取消重做应用

alter database recover managed standby database cancel;

    
   6:评估是否需要打开备库:
  
只要物理备库一直处于mount 应用状态。如果之前没有只读打开过,那么可以直接open,而不需要重启。
  注:
  10g物理备库open之后,不能应用日志。
  11g 物理备库open 之后,可以应用日志。

   7:DEPENDENCY 属性实现归档目的地共享
当在同一系统配置超过一个备数据库,
考虑使用LOG_ARCHIVE_DEST_n初始化参数的DEPENDENCY属性来定义一个归档目的地来代表所有目的地接收重做数据,而不是传送重做数据到每个单独目的地
LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY'
LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL'
LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2' 


8:打开备库
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN;


9:DG 的降级
当备库打开之后,可以运行重做运用命令来实现降级,此时数据库状态由open到 mount
alter database recover managed standby database disconnect from session;

10:添加数据文件或表空间
a 如果你在备数据库服务器参数文件(SPFILE)中设置STANDBY_FILE_MANAGEMENT初始化参数为AUTO,则任何在主数据库上创建的新数据文件一样自动创建在备数据库上。
b 如果你没有指定STANDBY_FILE_MANAGEMENT初始化参数,或者你设置为MANUAL,则当你添加数据文件到主数据库时你必须手工拷贝新数据文件到备数据库。

举例:
STANDBY_FILE_MANAGEMENT=auto

数据库建立表空间

SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m;
Tablespace created.

SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.

系统还没有创建/Dave/raw/raw101裸设备。备警告日志在恢复归档时显示下述信息: 

Fri Apr  8 10:00:22 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_8_15ffjrov_.arc
File #7 added to control file as 'UNNAMED00007'.
Originally created as:
'/dev/raw/raw101'
Recovery was unable to create the file as:
'/dev/raw/raw101'
MRP0: Background Media Recovery terminated with error 1274
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Apr  8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Fri Apr  8 10:00:22 2005
MTS; MRP0: Background Media Recovery process shutdown
ARCH: Connecting to console port... 

解决办法:

1.在备数据库上创建裸分区,并赋予权限给 Oracle用户。
2 查询V$DATAFILE视图获取相关信息。
SQL> SELECT NAME FROM V$DATAFILE;

NAME
--------------------------------------------------------------------------------
/u01/MILLER/MTS/system01.dbf
/u01/MILLER/MTS/undotbs01.dbf
/u01/MILLER/MTS/sysaux01.dbf
/u01/MILLER/MTS/users01.dbf
/u01/MILLER/MTS/mts.dbf
/dev/raw/raw100
/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007

3:
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' AS '/dev/raw/raw101';

4.在备数据库上,设置 STANDBY_FILE_MANAGEMENT为 AUTO并重启重做应用: 
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
RECOVER MANAGED STANDBY DATABASE DISCONNECT; 

11:删除数据文件或表空间:
库standby_archive_dest=manual 时候
库执行删除表空间操作:
SQL> drop tablespace testimp including contents and datafiles;

Tablespace dropped.

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/home/oracle/product/oradata/dg1/system01.dbf
/home/oracle/product/oradata/dg1/undotbs01.dbf
/home/oracle/product/oradata/dg1/sysaux01.dbf
/home/oracle/product/oradata/dg1/users01.dbf
/home/oracle/product/oradata/dg1/example01.dbf
/home/oracle/product/oradata/dg1/users02.dbf
/home/oracle/product/oradata/dg1/test01.dbf
/home/oracle/product/oradata/dg1/test_lob01.dbf
/home/oracle/product/oradata/dg1/ogg_tab.dbf
/tmp/test1.dbf
/tmp/test2.dbf

NAME
--------------------------------------------------------------------------------
/home/oracle/product/oradata/dg1/tbs_test01.dbf


库查看日志应用信息:
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[6]: Assigned to RFS process 5806
RFS[6]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[6]: Successfully opened standby log 4: '/home/oracle/product/oradata/dg2/stdlog1'
Thu Mar 15 15:26:55 2012
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 5808
RFS[7]: Identified database type as 'physical standby'
RFS[7]: Successfully opened standby log 5: '/home/oracle/product/oradata/dg2/stdlog2'
Thu Mar 15 15:26:55 2012
Recovery of Online Redo Log: Thread 1 Group 5 Seq 902 Reading mem 0
  Mem# 0: /home/oracle/product/oradata/dg2/stdlog2
Recovery deleting file #13:'/tmp/testimp.dbf' from controlfile.
Recovery dropped tablespace 'TESTIMP'

Thu Mar 15 15:27:05 2012
Media Recovery Waiting for thread 1 sequence 903 (in transit)
Thu Mar 15 15:27:05 2012
Recovery of Online Redo Log: Thread 1 Group 4 Seq 903 Reading mem 0
  Mem# 0: /home/oracle/product/oradata/dg2/stdlog1

查看备库相关视图:
SQL>  select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/home/oracle/product/oradata/dg2/system01.dbf
/home/oracle/product/oradata/dg2/undotbs01.dbf
/home/oracle/product/oradata/dg2/sysaux01.dbf
/home/oracle/product/oradata/dg2/users01.dbf
/home/oracle/product/oradata/dg2/example01.dbf
/home/oracle/product/oradata/dg2/users02.dbf
/home/oracle/product/oradata/dg2/test01.dbf
/home/oracle/product/oradata/dg2/test_lob01.dbf
/home/oracle/product/oradata/dg2/ogg_tab.dbf
/tmp/test1.dbf
/tmp/test2.dbf

NAME
--------------------------------------------------------------------------------
/home/oracle/product/oradata/dg2/tbs_test01.dbf

发现已经同步drop 了该表空间,但是物理上并没有真正删除。
SQL> host
[oracle@dg2 ~]$ ls -la /tmp/testimp.dbf
-rw-r----- 1 oracle oinstall 20979712 Mar 15 15:26 /tmp/testimp.dbf
[oracle@dg2 ~]$ rm /tmp/testimp.dbf
[oracle@dg2 ~]$ ls -la /tmp/testimp.dbf
ls: /tmp/testimp.dbf: No such file or directory

库standby_archive_dest=auto 时候
   主数据库删除表空间
SQL> drop tablespace test including contents and datafiles;
Tablespace dropped.
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/home/oracle/product/oradata/dg1/system01.dbf
/home/oracle/product/oradata/dg1/undotbs01.dbf
/home/oracle/product/oradata/dg1/sysaux01.dbf
/home/oracle/product/oradata/dg1/users01.dbf
/home/oracle/product/oradata/dg1/example01.dbf
/home/oracle/product/oradata/dg1/users02.dbf
/home/oracle/product/oradata/dg1/test01.dbf
/home/oracle/product/oradata/dg1/test_lob01.dbf
/home/oracle/product/oradata/dg1/ogg_tab.dbf
/tmp/test1.dbf
/tmp/test2.dbf

备库应用日志如下:
Media Recovery Waiting for thread 1 sequence 904 (in transit)
Thu Mar 15 16:01:22 2012
Recovery of Online Redo Log: Thread 1 Group 4 Seq 904 Reading mem 0
  Mem# 0: /home/oracle/product/oradata/dg2/stdlog1
Thu Mar 15 16:27:31 2012
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;
Thu Mar 15 16:32:03 2012
Recovery deleting file #12:'/home/oracle/product/oradata/dg2/tbs_test01.dbf' from controlfile.
Deleted file /home/oracle/product/oradata/dg2/tbs_test01.dbf
Recovery dropped tablespace 'TEST'


查看物理是否删除:
SQL> host ls -la /home/oracle/product/oradata/dg2/tbs_test01.dbf
ls: /home/oracle/product/oradata/dg2/tbs_test01.dbf: No such file or directory
发现自动删除了物理文件。这里体现了auto 和manual的区别


12:在主数据库中重命名数据文件
1.要在主数据库中重命名数据文件,将表空间脱机:
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
2.从 SQL提示符退出并执行操作系统命令,如下面的 UNIX mv命令,来在主数据库上重命名数据文件:
mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf 
3.在主数据库中重命名数据文件并将表空间联机:
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE  '/disk1/oracle/oradata/payroll/tbs_4.dbf'
     TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; 
SQL> ALTER TABLESPACE tbs_4 ONLINE; 
4.连接到备数据库,查询 V$ARCHIVED_LOG视图来检验所有归档重做日志文件都被应用了,然后停止重做应用: 
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- ---
8 YES
9 YES
10 YES
11 YES
4 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
5.关闭备数据库:
SQL> SHUTDOWN;
6.在备站点使用操作系统命令重命名数据文件,如 UNIX mv命令:
mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf 
7.启动并安挂载(mount)数据库:
SQL> STARTUP MOUNT;
8.重命名备控制文件中的数据文件。注意STANDBY_FILE_MANAGEMENT初始化参数必须设置为MANUAL
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'  
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
9.在备数据库上,重启重做应用:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 
如果你没有在备系统上重命名相应的数据文件,然后试图刷新备数据库控制文件,备数据库将会企图使用重命名的数据文件,但是它将无法找到
因此,你将在警告日志中看到类似于如下的错误信息: 
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf' 



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/713360/viewspace-719158/,如需转载,请注明出处,否则将追究法律责任。

上一篇: expdp 引起ORA-39095
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2011-02-13

  • 博文量
    16
  • 访问量
    23341