TTA — when you believe

基于LINUX的Oracle 10G RAC管理维护学习手记之前言目录

前言: 本文主要记录了自己在学习和管理维护RAC过程中的一点心得和笔记，鉴于网上安装文档参考资料相对详尽，故尽量对此过程减少笔墨。RAC是一个相对复杂的体系，其高效稳定运行与主机/存储/网络等密不可分，因此文中很多认知难免存在偏颇疏漏之处，姑且抛砖引玉。藉此，希望能得到更多指正并不吝分享宝贵经验。
如不加特殊说明，后续提及环境皆为RedhatAS 4/Oracle 10gR2.
提供PDF下载，下载地址>>.ITPUB下载地址>>

目录:

一 RAC相关以及基础知识…
1.CRS简介…
(1).CRS进程…
(2).Virtual IP Address.
(3).OCR，Voting disk.
2.ASM相关…
3.RAC存储/网络需求…
(1).存储需求…
(2).网络需求…
4.其他概念…
(1).缓存融合…
(2).后台进程..
二 RAC安装…
1.安装规划部署…
2. 安装过程…
3.几点注意问题.
三 RAC管理维护…
1.CRS管理维护…
(1).OCR的管理维护…
(2).Voting disk管理维护…
2.RDBMS管理维护…
(1).spfile以及相关参数说明…
(2)REDO/UNDO管理
(3)Archivelog/flashback配置管理
(4)ASM管理
3.Database备份/恢复…
(1) .Archivelog对各节点可见的备份/恢复…
(2). Archivelog对各节点不可见的备份/恢复…
四.故障切换/负载平衡配置
1.Service 18
2. failover 18
(1).TAF以及实现
(2).FCF以及实现
3.Load Balance
五.其他维护实施相关/案例
1.集群中主机名的更改
2.集群中IP地址的更改
3.集群中节点的删除/添加
4.升级与迁移
5.高可用架构:RAC+DG
六．RAC监控优化
1.思路及等待事件说明
2.性能诊断

一则父子表下trigger抛出ORA-04091异常的变通处理

   trigger抛出ORA-04091异常,无非是当前trigger下的事务access了一mutating table,比较常见的就是trigger访问了自身上的表.在一个指定on delete cascade模式下的父子表中,trigger中如果有对其相关的父/子表的访问,依然会抛出ORA-04091.这是比较隐性的.

   拿oracle的示例表emp和dept来做这个试验.
   dept的表结构如下:

    emp表结构如下:
【 阅读全文 】

Segment Header 占用几个block

       段空间手动管理的LMT下，Segment header被用来记录freelist的使用情况，extent的扩展分配情况以及记录HWM等重要信息。当table/index等object被建立的时候，被分配一个block用来记录segment header信息。随着object的数据量增大，导致 extent大量扩展，初始分配的这一个段头block必然不能维护容纳下当前的信息，Oracle将又继续分配一个/几个block用来存放（这些块，暂且称之为extent map block）。Oracle采用链表的方式，将这些块串联起来，用来维护整个segment。而这个/些block的逻辑存储位置，就是前一个segment header/extent map block块里记录中的最后一个extent 的下一个extent的首个块。

      做如下一个测试：

1.创建一个非ASSM管理的LMT表空间，设置uniform size 40K，使得在空间有限的情况下，extent尽量扩展

SQL>create tablespace test_mu datafile ‘E:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMO\TEST_Mu.DBF’ size 500M segment space management manual uniform size 40K;

Tablespace created

【 阅读全文 】

读一致性测试一例

     首先构造产生读一致性的案例环境，本例采用2个session来构造读一致性案例（当然一个session也可完成该实验）。为力求效果明了，本次排除延时块清除以及itl重用等情况。

Session 1:

SQL> conn mecoyoo/mecoyoo@test
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0
Connected as mecoyoo

SQL> create table test_cr (id number, value number) tablespace test;
Table created

SQL> insert into test_cr values(1,10′);
1 row inserted

SQL> insert into test_cr values(2,20′);
1 row inserted

SQL> commit;
Commit complete

SQL> exec pro_test_cr;

 执行pro_test_cr,在此过程中,开启session 2 并执行相应 DML操作，等待session 1 产生结果。

【 阅读全文 】

Data Guard 之表误操作恢复

    有这样种情况，由于误操作了一个业务表(drop/truncate/delete column,etc..)幸被及时发现.此时，我们可以在短时间内恢复这个表的常规操作有这么几种：

1) Flashback/Logmnr(如果是DML类，可以使用闪回查询或者logmnr挖掘;如果是drop，可以使用flashback table，但若是字段的更改或者truncate等操作，上述就无法起到作用了)
2) Dataguard端恢复(当然，需要standby端设置delay，利用延迟应用日志时间差，来迅速将standby recover到故障时间点之前，然后利用逻辑exp&imp来实现表级恢复)

    Dataguard体系下，方法2不失为一种高效简洁的办法.下面，看如下一个试验：
【 阅读全文 】