26 04, 2011
ocr保存了rac中节点列表、实例和节点的关联、以及rac各种资源（VIP、监听等）信息。
如果ocr所在磁盘或者阵列没有使用raid，则强烈要求对ocr做镜像。
因为OCR也非常重要，除了mirror外，也要做好充分的备份。
备份ocr有两种方法：
查看全文26 04, 2011
voting disk存储RAC中各个节点成员的信息，它是RAC中很重要的一个组成部分。为了提高安全性，除了mirror外，也要做好定期备份。1、什么时候需要备份voting disk
一般来说，voting disk只需要在以下情况下需要备份：
1) 刚安装完成
2) 添加或删除节点后
3) 添加或删除voting disk后
查看全文
4 03, 2011
最近在做一些DW相关的优化工作，发现跑得很慢SQL大多数都和包含聚合运算的关联update相关。很多人开发人员不清楚update的原则，按照习惯直接把update语句写成类似如下形式：
update a set a.value=(select count(1) from b where a.col=b.col);
28 02, 2011
在RAC环境下打patch与单节点类似，不过在RAC环境下Oracle提供了rolling patch方式，降低打patch对数据库的影响。
以下是基于RAC + ASM环境的patch步骤，简单记录。
17 02, 2011
二、后续处理上面的步骤解决了坏块对数据库的潜在影响，但是此时v$database_block_corruption的信息是还没有清除的，需要清除，需要再运行RMAN，如果没有坏块已经修复，才会从v$database_block_corruption删除对应记录。
但是在大部分情况下，即使删除了原来的对象，数据块的状态让人是标识损坏的，但是不影响一般的数据库操作，可以忽略。如果你看不顺眼或者担心它影响RMAN的备份，可以用以下方法格式化这个数据块，只有被正常格式化后，数据块状态才会恢复正常。
查看全文
18 01, 2011
Linux AS 5.5 下基于HDLM创建LVM
最近的项目中用到了HDS的多路径软件HDLM，基于它创建lvm着实费了一份劲。
以下说明如何在redhat as 5.5下基于HDLM创建LVM。
13 01, 2011
在数据仓库的一个应用中，有一个这样的案例：1. 源表很大，且是根据天做的分区表
2. 正常情况下，每天凌晨往源表一次性导入上一天的数据
3. 正常情况下，数据导入后不会做任何的修改和删除操作
4. 有其他的应用需要对这个源表的数据做聚合查询(group by)，其他一个维度是分区键
查看全文
7 01, 2011
在10g以前，虽然支持联机重定义表，但是联机重定义后的后续工作还有很多，比如创建触发器、索引、约束等等，当一个表包含很多依赖对象时，这个后续工作就非常耗费精力时间，并且很容易漏掉一些东西。值得庆幸的是，10g后这个都不会成为我们的负担，10g的dbms_redefinition新提供一个过程COPY_TABLE_DEPENDENTS，可以帮我们做这件事情。 查看全文
6 01, 2011
最近在做系统上线的性能测试，在测试过程中发现了一个与gc buffer busy相关的性能问题，经过一份周折，最终解决问题。总体来说，这次测试的现象是有三个节点的压力正常，事务处理效率也正常，但另外一个节点事务处理能力很差，且系统负载根本上不去。
以下是解决过程。
查看全文
6 01, 2011
自动删除归档日志的脚本(尤其是dataguard环境)
在自动删除日志需要考虑几点：
1. 日志必须是已经被apply的
2. 日志备份已经被备份过的
3. 为了保证一定的管理余地，不要apply后马上删除，而应该根据实际情况设定一个删除策略。
4. 脚本要能够兼容primary和standby两种状态，且自动判断状态并执行不同的逻辑，否则在切换后，如果忘记修改脚本，那就可能杯具了。
查看全文
3 01, 2011
在RAC下spfile位置的修改与单节点环境不完全一致，有些地方需要特别注意，否则可能修改会失败。
下面用一个例子说明：SPFILE放在ASM中一个不正确的目录(+ARCH)中，现在想把它放在另外一个目录(+DBSYS)下。
以下是具体步骤：
1 01, 2011
Linux AS 5中hugepage的一些变化
以前一直用的是Linux AS4，在大内存情况下，也一直在用hugepage，没有发现什么让人不省心的问题，但最近的Oracle项目用到了AS 5，且用到的机器内存都较大，有128GB，使用hugepage时遇到一些怪异的现象。
查看全文28 12, 2010
最近在做一个ORACLE数据仓库的项目，由于存储量巨大，lun的数量有几百个。不管是用裸设备还是ASM都需要把这些lun做分区。由于lun太多，如果一个一个手工分区，不但工作量巨大，且容易出错或者疏漏。而本项目要做的分区非常简单，每一个lun分一个区，单个区占用lun的所有空间，因此可以通过脚本自动处理此类工作。
以下是具体步骤：
查看全文
25 11, 2010
顾名思义，只读表空间就是空间只可读，不可写，这一特性对备有有很大的好处，尤其是对数据仓库这种历史数据很少变化，而数据规模又非常庞大的场景。
下面通过一些例子来说明只读表空间如何影响备份与恢复。
21 11, 2010
Nologging在提高性能的同时，会给恢复带来一定的影响。下面通过两个案例来说明它是怎么影响恢复的。第二个案例要验证在先备份数据文件，再发生nologging操作的情况下，是否可以完全恢复数据。
查看全文
21 11, 2010
Nologging在提高性能的同时，会给恢复带来一定的影响。下面通过两个案例来说明它是怎么影响恢复的。第一个案例要验证在先发生nologging操作，再备份数据文件的情况下，是否可以完全恢复数据。
查看全文
29 10, 2010
在数据仓库环境中，分区表会非常多，尤其是范围分区的表。为了确保业务不受影响，需要确保分区表的分区的边界足够大，以免导入数据时会出错。为了避免出错，很多人设置了maxvalue或者提早分配很多个分区，这些都是不好的习惯。
设置MAXVALUE可能会导致两个问题：
1) 产生垃圾数据
2) 因为疏忽导致MAXVALUE的分区变得巨大，给后续的数据管理带来麻烦
提早分配很多个分区也会导致一些问题：
1) 也可能会产生垃圾数据
2) 不是按需分配可能会导致后续的一系列问题，如因为数据量变化而修改分区方式等
更好的做法是只提前分配少量的分区，并密切监控分区的扩展情况。那么，如何监控分区是否会溢出边界呢？我的做法是写一段代码实时监控分区的边界及当前时间的差异，如果边界接近溢出，则告警。
这里比较麻烦的是处理high_value，它是一个long类型的字段，下面是我的做法。
查看全文
26 10, 2010
cluster可以把一个或者多个表的数据按照键值聚合在一起，在很多应用场景能提高查询性能。cluster可以为B*Tree cluster也可以是hash cluster，这篇文章主要讨论hash cluster。(延伸阅读《用hash cluster表提高查询性能 (一)》 查看全文