Oracle用户和grid用户必须有相同的组，并且 ASM Disk的属组要和这个组保持一致，否则数据库无法访问ASM磁盘不能成功启动。

安装PSU或安装one-off patch补丁时，在relink编译oracle执行文件后文件的group ownership属组可能会发生改变，对比可以和oracle 执行文件相同路径下的oracle0文件(上一版oracle的mv)查看。 当oracle用户和oracle执行文件都没有OS ASM属组如asmadmin时，会无法读取ASM disk. 解决方法，手动修改或使用setasmgidwrap 修改；使用srvctl 启动实例，让oracle自动

全部内容

在DATAGUARD配置时如果没有在数据库级启用FORCE_LOGGING，来覆盖会话级的nologging操作。 当为了提升SQL执行速度或减少redo而使用NOLOGGING选项， 或者在segment级使用了NOLOGGING属性, 会导致缺少日志必要的信息，造成standby datafile block corruption

在DG RECOVERY介质恢复期间会将受影响的块标记为已损坏, 查询V$DATABASE_BLOCK_CORRUPTION.CORRUPTION_TYPE值为NOLOGGING。当使用ADG打开备用数据库尝试读取范围标记为“UNRECOVERABLE”的块，会

全部内容

CPU：Critical Patch Update，紧急补丁更新

CPU已更名为SPU（Security Patch Update）

每季度发布一次，用来修复安全方面的累积型补丁，即最新的CPU补丁已经包含以往的CPU补丁，只需安装最新的CPU补丁即可。

PSU：Patch Set Update，补丁集更新

Oracle选取在每个季度用户下载数量最多、且得到验证具有较低风险的补丁放入到每个季度的PSU中。在每个PSU中不但包含Bug的修复，还包含了最新的CPU。PSU通常随CPU一起发布。PSU通常是增量的，大部分PSU可以直接安装，但有些PSU必须要求安装上一个版本的PSU之后才能继续安装

全部内容

Oracle数据库环境尤其是RAC环境对下层的基础环境要求非常严格，常常会因为CPU不足，内存不足、网络,IO等原因导致数据库hang或脑裂驱逐， 这里如果没有系统信息数据的支撑， 可能会陷入SA和DBA互相扯皮的尴尬局面， Oracle也是操碎了心，引入了个工具CHM， 这也是Oracle安装介质越来越大的一个原因， 把这些工具也集成了进来，到12C后甚至还搞了个独立的库(GIMR)收信信息，还有SQL developer, SQLCL , ORATOP 等工具， 这也是正是她伟大的一面.

ora.crf是Cluster Health Monitor（以下简称CHM）提供服务的资源， 用来自

全部内容

现在老听到抱怨在VM安装12C RAC的资源需求太大，安装个12C GI就要几十G磁盘空间和4G的内存， 这些资源被哪用了？当然离不开GIMR和ASM memory target这两个的变化，这篇就简单的谈谈这两个变化及如何突破限制，注意生产环境如果没有理解其影响最好不要做。

1 GIMR （Grid Infrastructure Management Repository database ）

GIMR是一套完整的数据库，如在安装GI的过程中会提示是否要创建GIMR的数据库MGMTDB ，当然你可能会选NO，注意这里容易被误解， 在12.1.01版本时是可以选择GIMR不安装，但是在12.

全部内容

1.概述

本篇讲解group replication的安装部署。由于group replication最大支持9个节点，本文将大家在一台机器上快速部署9节点的group replication，多机器部署是一样的,没有任何区别。 1

2.安装规划

group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

节点名 Internal port   Db port datadir conf    mode
s1  5701    9001    /data/for_gr/s1 s1.cnf  read

全部内容

XTTS迁移的全过程

需要根据实际情况更改，主要包括以下几个流程：

检查数据库用户自包含

准备 xtts 前期环境

进行全量备份并传输备份集到目标端

目标端进行全量恢复

源端目标端多次增量恢复

表空间 readonly 进行最后一次增量

元数据导入导出

检查对象

1 迁移实施方案

1.1 迁移主要步骤

1.2 备份前准备

1.2.1

全部内容