Rac & DG

Rac环境：

1. RAC版本异同：[10R2,11R1(和10类似)],11R2,12c:
   1. 目录：
      1. 10.2的ASM需要单独的目录（oracle home）：rdbms home,asm home, crs home
      2. 11.2：rdbms，grid（crs+asm）
   2. IP：
      1. 10.2有私有IP（private IP）公有IP（public IP）和虚拟IP（VIP）；Private IP是用来做内部连接；Public IP和VIP是外部连接，并且在同一个网段。
      2. 11.2在外部连接（公有IP和虚拟IP）之上加入SCAN IP，Scan Ip有3个。
   3. 磁盘：
      1. 11.2之前，OCR和voting disks在裸设备上，11.2之后放在asm，并且oracle不在支持裸设备。
   4. 具体配置举例：
      1. 3节点Rac，OS：sun solaris，version 11.2.3， ASM
      2. 常用的cmd：crsctl，srvctl，crs_stat, crsctl status resources
2. 服务service：
   1. 使用service达到load balance的目的：每个节点跑特定的应用。
3. ASM：
   1. 优缺点：
      1. 易于管理：加减磁盘，易于条带化和镜像。
      2. 文件名非常奇怪，非常难以复制，难以用ftp传输文件，有时候非常危险，有时候SA不懂ASM，会导致磁盘损坏。
      3. HA不能保护数据。
   2. RAC的性能问题：
      1. 主要的问题是Cache Fusion(RAC为了保持数据一致性的一种内存机制。)，Cache Fusion增加了很多额外的开销，所以两个节点的性能不一定比一个好，所以说RAC并不提高性能。实际操作时候，用service对rac的每个节点要分配功能，比如一个节点专门负责DML，一个节点负责reporting。
      2. 关于补丁：In Rolling Patch mode:每个实例逐一关闭，patch crs和oracle rdbms home，使用local parameter in opatch。
   3. Load balance：
      1. 在客户端，SCAN作为主机名被使用在tnsnames.ora，这样oracle可以动态分配节点，scan相当于封装了真实的IP。
      2. 在服务器端，当scan listener处理从客户端连进来的call时，会将它放到least load(从cpu和连入进程的使用情况)的node上。
      3. 所以remote listener要恰当设置。一般rac的每个节点，我们有两种listener，本地和scan。从listener.ora可以看到。
   4. 关于init parameters：
      1. 在init.ora文件里，我们有两种参数文件：local 和global，global参数前带*号。
      2. Cluster_database 必须是TRUE。
      3. 其它：control_files,cluster_database_instances,Instance parameters(starting with instance name),thread,instance_number,undo_tablespace,
      4. 有些参数在每个节点上可以不一样，也可以都一样。如内存参数（SGA，PGA，memory target).
   5. Rac中共享与非共享：
      1. 非共享：Binaries,alert log,redo,archive logs,undo tablespace
      2. 共享：control files, spfile, temporary files
4. 案例：
   1. 性能案例1：在OEM我们观察到：Global Cache buffer busy，GC current block 2-way/3-way and cache buffer chains(hot blocks)
      1. 我们在数据库上有很多增删改的操作，导致buffer cache同步有问题。如果dml操作同时在不同节点运行，会马上要求global cache同步，导致很多系统等待。
      2. 解决：节点功能切分。一个节点用于增删改，另一个用于报告。
   2. 性能案例2：在OEM性能表上（log file sync），每小时有7分钟会出现commit high。
      1. 首先让应用组查代码，查看commit频率。
      2. 数据库，有任何bug相关？
      3. 存储组，看是否有任何问题，我们把redo logs放在快盘上，仍然解决不了问题。
      4. 使用BLUESTRIPE软件（可以在第二级别检测磁盘IO）。发现在那段时间，有一个root进程消耗大量IO，并且和数据库竞争。我们在crontab里面重新安排这个进程运行的时间段，问题解决。
   3. 回复案例：SA扫描asm磁盘，导致数据库崩溃。
      1. HA不能保证存储安全，在alert log里面有很多ora7445和ora600错误.块坏错误，数据库不能重启，或者数据库起来了，但是某些数据不可以获得。
      2. 我们需要incomplete RMAN recovery.(有个cutoff time，在那样以后的数据会丢失)
      3. recover script need two steps（restore datafiles and recover with incremental backups or archives）
   4. 关于ASM：在restore以后，如果recover失败，重新跑脚本的时候，在 linux文件系统下oracle不会restore数据文件，只会restore incremental backup pieces/archive logs.在ASM里面，oracle会重新restore 数据文件，会花更多的时间。所以需要在脚本里跳过restore datafile这一部分。直接recover。
   5. 关于备份恢复：增量备份真的很重要。

转载于:https://www.cnblogs.com/alexweng/p/4389343.html