在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.

全部内容

XTTS迁移的全过程

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

检查数据库用户自包含

准备 xtts 前期环境

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

目标端进行全量恢复

源端目标端多次增量恢复

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

元数据导入导出

检查对象

1 迁移实施方案

1.1 迁移主要步骤

1.2 备份前准备

1.2.1

全部内容

对ORACLE的AWR/ADDM/ASH报告，大家都不会陌生，是DBA做性能诊断和SQL分析调优的好帮手。但这个报告只包括两个采样时间点，而且数据以表格形式展现不是很直观。

由ORACLE ACS部门 WangWenjie - valen.wang#oracle.com开发的AWRCRT工具弥补了这两个缺点，能够生成更为直观更为细化的AWR报告：

源网址：http://www.dbfine.net/ords/ 下载后只需执行awrcrt.sql就能够生成如下报告，清晰地看到各个时间段的TOP事件和TOP SQL。
查看AWRCRT报告

全部内容

#!/usr/bin/perl
##########################################
# This script checks alert logs for all 
# Oracle instances on the server where 
# it's scehduled to run and pages dba oncall
# in case of any new ORA- errors 
#########################################
#

$ORATAB_FILE="/etc/oratab&q

全部内容