oracle在10g版本明确引入time model,直观的作为一种量度指标反映给用户。时间作为一种性能上的量度和反映，一直贯穿在oracle的各个版本中，可以说时间模型并不是10g特有的东西。只不过，这种模型和概念在10g之前并没有明确和加以细化，而且，在oracle各个版本的升级和演化中，也在不断进行调整。
时间作为我们性能优化的一个重要参考，虽然有时候并不能给诊断带来直接的切入点，比如我们常常提到的cpu time、db time甚至是response time，这些指标孤立起来因为负载和系统环境的不同可能并没有横向比较的意义，却可以作为某个系统的状态数据和优化前后的成果参考，有很高的纵比意义。
结合awr/statspack，看一下数据库层面上对优化有指导意义的几个重要的时间概念。
【阅读全文】
ASM是10g版本后oracle大力推荐的一种数据文件存储方式,也是以后的一个重点方向.尽管现在asm在稳定性和一些操作上还存在不少问题，但已经有越来越多的企业把核心系统部署架构到上面.
本文重点不在于探讨ASM的优劣问题，爱青菜与爱白菜的人总有自己的理由支持自己的喜好.
朋友有套系统需要更换存储，数据库文件部署在asm上，需要尽量短的停机时间完成此次存储更换。由于不涉及异构的迁移转换，迁移起来也不难，无需借助三方的工具来完成这次高可用切换.当然，ASM下的一些特性也为我们做迁移提供了更多的选择方案.
针对该环境，列几种选择方案(以下操作都在新存储已挂载在主机上的情况下).
【阅读全文】
前几日检查一个生产环境库备份的时候发现了某个数据文件产生了逻辑坏块，检查该Corrupt block，上面并没有任何对象存在.
对于这种情形的坏块,我们可以采用扩展extent的形式来格式化这些逻辑坏块,并配合一些细节上的处理技巧.
以下是模拟案例.
案例描述:
(1)备份数据文件6，发现有坏块存在.
RMAN> backup datafile 6 format ‘E:\Backup\full_%s_%p’;
启动 backup 于 03-8月 -09
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 启动全部数据文件备份集
通道 ORA_DISK_1: 正在指定备份集中的数据文件
输入数据文件 fno=00006 name=G:\ORACLE\MM01.DBF
通道 ORA_DISK_1: 正在启动段 1 于 03-8月 -09
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: backup 命令 (ORA_DISK_1 通道上, 在 08/03/2009 21:36:58 上) 失败
ORA-19566: 超出损坏块限制 0 (文件 G:\ORACLE\MM01.DBF)
Dataguard从9i起就在oracle的高可用和容灾方面发挥着巨大的作用，尤其是物理dg，整体来讲，部署容易，管理相对简单，运行比较稳定，是企业高可用架构中承担举足轻重的角色。
10g physical dataguard同9i 版本相比，整个风格还是一脉相承的，调整增加了一些功能和参数以便于更平滑的切换和更可控的故障切换。另外，在日志的传送机制上，也有了相应的优化改进。
不管是小到十几G的db，还是大到T级别的db，架构dataguard都是一套理想的软件层面的高可用方案。它能避免数据库主机的单点隐患，有效的提高业务系统的服务时间，能够在短时间内完成计划内的切换和计划外不可预计的故障切换。
在我所在的企业环境中，大面积的采用了物理dataguard来作为数据库服务器应急方案(以下就物理dg谈)。
1.健壮性
Dataguard是相当健壮的产品，一般搭建好环境后，不容易破坏。运行会出现一些故障，但都容易fix。除非你的归档日志由于规划问题或者人为原因丢失而断档(少数bug情况除外)，一般情况下整个dg环境无需重建。
另外，无论是数据库小版本之间的升级/打patch还是类似9i到10g跨大版本升级，只要操作合理，整个dg环境都能保持，无需重建。
2.稳定性
物理dataguard具有极高的稳定性。因为dg需要通过网络对archivelog或者redo进行transprot，因此网络的稳定和带宽往往较其他方面会对整个dg的性能和稳定运行产生影响。糟糕的网络环境和IO会带来一些特定的dg环境的等待事件，对主库性能和运作造成影响。例如较高的wait on等待(ARCH wait on SENDREQ/ATTACH/DETACH||LGWR wait on SENDREQ/ATTACH/DETACH||LNS wait on SENDREQ/ATTACH/DETACH)，可先从网络方面入手诊断，当然，在高负载的环境中，这种dg等待还是会时常出现的，大部分并不是网络带来的问题。
3.高可用迁移
应该说，对于同平台的db迁移(同版本或者跨版本)，物理dataguard对其具有强大的杀伤力，不论你的数据库容量多大，采用dataguard做迁移都能将停机时间控制在几小时或者几分钟之内。而且，因为不涉及数据库辑对象层面的变更，整个过程风险小，考虑的因素少，即便不小心失败也不会对现有的环境造成破坏。
这里讨论的并不单单是恢复上的技巧问题，还有如何对你的DB管理规划的问题。
案例情形：
某个生产环境的业务表(不大，100M左右）被误删除了一个字段，现在要尽快找回这些被删除的业务数据（数据库容量为700多G,有一个实时恢复的物理备库，主要的表空间为该所在表空间BIS和另外一个表空间,各自300多G,单个数据文件统一8G一个).
情况很乐观：有误操作之前RMAN全备份和到现在连续的归档日志，也就是说用RMAN的不完全恢复可以找到为删除之前的数据。
这是一个看似很基础和简单的案例，但作为DB的管理维护人员，尤其是作为服务型的人员角色来说，如何缩短故障的解决时间，将直接决定你的服务质量和客户的满意度。
不妨让我们思考一下，面对这个案例，有什么样的技巧可以缩短恢复的进度时间呢？
【阅读全文】
基于LINUX的Oracle 10G RAC管理维护学习手记之前言目录
基于LINUX的Oracle 10G RAC管理维护学习手记之一―――RAC相关以及基础知识
基于LINUX的Oracle 10G RAC管理维护学习手记之二―――RAC规划安装
基于LINUX的Oracle 10G RAC管理维护学习手记之三（上）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之三（下）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之四―――RAC故障/负载平衡配置
基于LINUX的Oracle 10G RAC管理维护学习手记之五―――RAC下其他维护实施相关/案例
基于LINUX的Oracle 10G RAC管理维护学习手记之六―――RAC性能监控调整
基于LINUX的Oracle 10G RAC管理维护学习手记之七―――其他Troubleshooting
1.思路及等待事件说明
鉴于RAC体系的复杂性，RAC的优化比单实例的优化给我们提出了更高的难度和要求。大部分情况下，单实例上的优化方法在RAC结构下同样适用。
RAC优化的2个核心问题:
【阅读全文】
基于LINUX的Oracle 10G RAC管理维护学习手记之前言目录
基于LINUX的Oracle 10G RAC管理维护学习手记之一―――RAC相关以及基础知识
基于LINUX的Oracle 10G RAC管理维护学习手记之二―――RAC规划安装
基于LINUX的Oracle 10G RAC管理维护学习手记之三（上）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之三（下）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之四―――RAC故障/负载平衡配置
基于LINUX的Oracle 10G RAC管理维护学习手记之五―――RAC下其他维护实施相关/案例
基于LINUX的Oracle 10G RAC管理维护学习手记之六―――RAC性能监控调整
基于LINUX的Oracle 10G RAC管理维护学习手记之七―――其他Troubleshooting
本环节侧重一些RAC工程维护相关的实际案例,暂举例以下案例
1.集群中主机名的更改
2.集群中IP地址的更改
3.集群中节点的添加/删除
4.升级:9i rac升级10g rac
5.rac + dg 搭建
6.其他
基于LINUX的Oracle 10G RAC管理维护学习手记之前言目录
基于LINUX的Oracle 10G RAC管理维护学习手记之一―――RAC相关以及基础知识
基于LINUX的Oracle 10G RAC管理维护学习手记之二―――RAC规划安装
基于LINUX的Oracle 10G RAC管理维护学习手记之三（上）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之三（下）―――RAC日常管理维护
基于LINUX的Oracle 10G RAC管理维护学习手记之四―――RAC故障/负载平衡配置
基于LINUX的Oracle 10G RAC管理维护学习手记之五―――RAC下其他维护实施相关/案例
基于LINUX的Oracle 10G RAC管理维护学习手记之六―――RAC性能监控调整
基于LINUX的Oracle 10G RAC管理维护学习手记之七―――其他Troubleshooting
1.Service
服务是rac体系中相当重要的概念，它为应用提供高可用和多样化的解决方案。实际中，我们可以创建不同性质的service来满足我们应用的不同需求。
【阅读全文】
