ITPub博客

首页 > 应用开发 > IT综合 > 9ir2dataguard读书笔记(第一,二,三,八章)

9ir2dataguard读书笔记(第一,二,三,八章)

原创 IT综合 作者:zsj3874 时间:2007-11-13 12:11:02 0 删除 编辑

还是习惯于往纸质的纸张上记笔记,偶尔记在电子文档上的就传上来!

[@more@]

1-1:
DATAGUARD配置由一个主库(生产库)和最多9个备用库组成.
备用库可以和主库在同一台主机上,虽然说这样做的话在灾难恢复上没有任何的益处.
1-2 备用数据库的分类:
物理备用数据库:和主库的物理结构是完全一样的(但可以使用不同的目录结构2-6),采用标准的恢复技术作为日志应用方式,能进行管理的恢复操作或者只读操作,但却不能同时进行,也就是说在应用重做日志的时候就不能用物理备用库当作报表目的,反之也是一样的.
逻辑备用数据库:和主库的逻辑结构是一样的,但物理结构可以不一样(可以在逻辑备用数据库上创建主库上没有的索引,物化视图等,也可以创建主库上没有的模式),从主库传过来的重做日志被抽取为SQL语句而后在逻辑备用数据库上执行,在恢复的同时可以用作报表目的.
1-4 DATAGUARD服务:
日志传输服务,日志应用服务,角色管理服务
日志应用服务:物理备用库和逻辑备用库的一个主要区别就是日志应用服务的不同上,物理备用数据库使用redo apply技术,也就是说使用标准的恢复技术来应用重做日志(使用物理ROWID进行块对块的改变应用);而逻辑备用数据库使用sql apply技术(所以备用库必须保持打开状态),也就是说使用logminer技术将重做数据转化为SQL语句而后在备用数据库端执行.
角色管理服务:有主库和备用库两种角色,你可以使用switchover/failover切换角色.
1-6 DATAGUARD的保护模式:
三种不同的数据保护模式:最大量的数据保护,最大量的可用性,最大量的性能


2-2 物理备用数据库的益处:
可以支持主库支持的所有的数据类型和DDL,DML操作.
2-4 逻辑备用数据库的益处:
因为使用SQL APPLY技术,所以它必须一直保持打开状态,对于DG保护的数据对象只能执行只读操作,但对于额外创建的模式对象可以在任意时间执行正常的DDL/DML操作.
2-5 DG操作的前提条件:
主库端和备用库端的数据库版本必须是一样的;两端的ORACLE软件版本必须是一样的,OS必须是一样的,但发行版本可以不一样,可以使用不同的目录结构;主库必须运行在ARCHIVE模式下;主库必须启用FORCE LOGGING.


第三章:创建物理备用数据库
一.为主库做准备:
开启force loggin:
alter database force logging;
主库必须是ARCHIVED,开启了自动归档,设置了一个本地的归档目的地:
alter system set log_archive_dest_1='LOCATION=/disk1/ora_archive/zhao' scope=spfile;

二.创建物理备用数据库:
1.标识主库的数据文件
2.对主库做冷备份
3.为从库创建控制文件:(主库上执行,且是在备份完所有的数据文件之后执行的)
alter database create standby controlfile as '/disk1/oracle/zhao/control01.ctl';
4.为从库创建spfile:
主库上:create pfile='/disk1/initzhao.ora' from spfile;
拷贝到从库上,做出相应的调整之后,再还原为spfile
从库上:create spfile from pfile='/disk1/initzhao.ora';
做一些必要的解释:
db_name:应该和主库相同
instance_name:如果主从库在同一台主机上,这个设置必须和主库的不同
lock_name_space:如果主从库使用同一个oracle_home的话,这个可以设置为instance_name
standby_archive_dest:从库接受来自主库的归档重做日志文件的目录
log_archive_dest_1:从库切换为主库时,归档到哪里
5.把数据文件,从控制文件,PFILE拷贝到从库主机上.
6.创建windows服务,配置监听器,配置net service name.
7.开启从库上的死连接检测:
从库上sqlnet.ora中sqlnet.expire_time=2(单位:分钟)
8.启动物理备用数据库:
从库上:
sql>startup nomount;
sql>alter database mount standby database;
9.启动日志应用服务:
sql>alter database recover managed standby database (disconnect from session日志应用服务作为后台会话运行);
10.开启归档到物理备用数据库处:
主库上:
sql>alter system set log_archive_dest_2='service=zsj' scope=spfile;
sql>alter system set log_archive_dest_state_2=enable scope=spfile;

第八章:管理物理备用数据库
8.1.1
启动物理备用数据库:
一般是先启动从库,而后启动主库
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;

8.1.2
关闭物理备用数据库:
如果物理备用数据库正处于管理恢复模式,那么先取消管理恢复模式:
select process,status from v$managed_standby;
如果存在MRP/MRP0,那么备用库处于管理恢复模式,先取消:
alter database recover managed standby database cancel;
如果主库开启着的话,应该defer到这个备用端的备份,即在主库端设置log_archive_dest_state_n=defer,而后切换日志(使得这个设置生效),而后才能关闭备用数据库:
因为日志传输服务要读写备用端的控制文件的,如果已经关闭了备用数据库,还开启着日志传输服务的话,它不能读写备用端的控制文件了(读写控制文件要求mount控制文件的),所以

会出错,所以应该先关闭日志传输服务,而后才能关闭备用数据库的:
shutdown immediate;

8.2 以只读方式打开物理备用数据库:
物理备用数据库只能处于管理恢复模式(应用重做数据,不能用于报表目的)/只读打开模式(不能应用重做数据,和主库不是实时事务一致的)
如果你想要备用库用于容灾和报表目的,你可以使用多个物理备用数据库:一部分用于打开只读访问(需要定期的切换到管理恢复模式,应用最新的归档重做日志到备用库上,而后切换

回打开只读访问),一部分只用于管理恢复.当然也可以考虑使用逻辑备用数据库.

数据库原先就是关闭的:
startup nomount;
alter database mount standby database;
alter database open read only;

数据库原先是处于管理恢复模式:
alter database recover managed standby database cancel;
alter database open read only;

数据库原先是处于open read only的,变为管理恢复模式:
终止备用库上的所有活动会话.(不用关闭数据库吗??????)
alter database recover managed standby database disconnect from session;(数据库原先是open的,不用关闭就可以由open->mount吗??????)

8.3 当物理备用数据库处于管理恢复模式的话,你可以在备用端使用RMAN来备份数据文件和归档重做日志文件.但你不能使用逻辑备用数据库来备份主库(因为RMAN的备份是物理备份

,而逻辑备用数据库和主库在物理结构上已经不同了)

8.4 管理影响从库的主库事件:
在有些情况下,发生在主库上的事件/改变是通过归档重做日志文件自动的传播到从库上的,不需要DBA在从库端做额外的动作.而在另一些情况下,却需要DBA在从库端执行维护任务
不需要DBA在从库端执行额外的操作的主库端操作:alter database enable/disable thread;改变表空间状态;创建表空间/添加新的数据文件,而且从库端设置
standby_file_management=auto(如果主从库目录结构不同的话,是不是从库端必须有db_file_name_convert设置呀?)

主库改变后,需要在从库端执行额外操作的主库动作:
1,如果从库端设置standby_file_management=auto,那么在主库端创建表空间/添加新的数据文件,都会在从库端也创建表空间/添加新的数据文件.
如果从库端设置standby_file_management=manual(或者未设置),那么在主库端创建表空间/添加新的数据文件后,你也必须手工的拷贝这个新的数据文件到从库端.如果从库数据文

件建立在裸设备上,那么standby_file_management=manual的设置是必须的,具体过程见文档.

2.在主库端drop tablespace之后,在切换了日志,且保证drop tablespace这样的动作已经应用到了从库端之后,在从库端删除相应的数据文件(OMF也是这样吗?).

3.重命名主库端的数据文件:具体操作见文档.(其中从库的standby_file_management必须设置为manual吗?????)

4.主库端添加/删除联机重做日志文件:
这些个动作都不对从库产生任何影响的,但如果switchover之后,从库扮演起了主库的角色的话,就会影响主库的性能了.可以在从库端执行这样的操作来和主库端保持同步.
如果开启了管理恢复的话,取消管理的恢复,如果standby_file_management=auto的话,临时改变为manual,而后alter database add/drop standby logfile ...;
复原standby_file_management的设置,复原管理恢复状态.(standby_file_management参数是系统级可改变且立即生效的)

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

请登录后发表评论 登录
全部评论
  • 博文量
    16
  • 访问量
    44158