最近的几个技术问题总结和答疑(七) (r9笔记第38天)

今天抽空整理，发现近期问我数据恢复，灾备的问题还比较多，我简单整理了一下。 问题1： 能请教一个问题么？我们用was链接的oracle数据库，是不是不建议在was上设置statementcachesize的参数？我们目前设置的是200，发现数据库中那个session都会持有200个游标，有工程师建议把这个参数设置为0 这个问题着实还问到我了，不过我问了下专业的中间件工程师，答复如下： Statement Cache Size是指有多少个prepared statement或者callable statement可以被缓存，在遇到对这些statement的请求时会重用缓存中的statement而不会重新加载。这个不能为0吧，一般设置大于 0,小于数据库连接池的最大值 问题2：关于异机数据恢复 有个朋友说在服务器A中做了RMAN备份，想在异机恢复，但是控制文件忘了备份了。问能不能恢复回来。

这个问题其实要明确一点，就是数据文件是否最近有变化，如果没有那就很简单，甚至我们都可以自己创建一个控制文件出来。 异机恢复是完全可行的，不要看到ORA错误就害怕。 比如在现有的库中生成控制文件的trace,直接部署到异机。 问题3： 有一个朋友问我说，他碰到一个问题 oracle 11.0.2的库，有一个视图，关联了几十张表，视图有三百个字段，查询select * 的时候报错，但是select count(*) 的时候就可以，然后将视图中删除一张表select *就能查出来。截图如下：

对于这个问题，有几个思路可供参考。 1.看错误描述，感觉是一个bug 2.视图关联几十个表，上百个字段，本身设计上就有一些问题 3.这类问题是否可以复现是一个关键，如果能够复现，最好还是做一些细致的trace，看看问题边界，因为没有模拟环境，所以只能建议了。 问题4： 我如果不用ROSE HA或ORACLE ACTIVE DATA GUARD的HA软件，直接用SHELLE脚本实现HA功能，这样有什么风险吗 Data Guard如果不考虑更多的特性，就如同标准版的DG所做的，技术上实现是完全没有问题的。早期的Data Guard就是这么干的，很多老DBA就是写脚本，传归档，恢复 问题5： RAC环境中，业务是数据库仓库，一个节点跑存储过程在频繁DML一个表，同时在另一个节点也在另一个存储过程频繁DML同一张表 在DB层面,哪这种情况如何避免呢，这种情况下RAC2个节点之间的数据同步或缓存CACHE FUSION如何评估 这种情况下，会把RAC的限制放大。节点间频繁更新同步数据库，性能和锁影响都是全局的。 DB层面，可以根据业务把这种操作做切分，甚至只在单节点运行，效果都比双节点强。也就是业务的不同模板配置不同的SERVICE，这样就把应用的不同模 板连接到RAC不同节点了。如果配置service,设置策略，这种比较推荐，对应用来说，看到的是业务层面的数据库，其实是各个节点。 有些场景下，我们原来的电信客户，为了稳妥，用的active-passive模式，只激活一个节点，OLTP，另一个就用作高可用临时切换 问题5： 我这个Oracle10t,每天生成1T日志，目前是每天全备，每小时备份日志，但是还是未能满足12小时恢复，我想在每天全备基础上，12小时做次增量，滚日志就能少500G, 这样是否恢复能快些 在这种场景下，每天增备的日志量还是不小的，为了满足12小时恢复，其实Data Guard就是一个不错的选择，可以设置延迟归档应用，恢复相比全量的恢复要快得多。 还有一种思路就是使用第三方的恢复软件，我知道的ActInfo的那个软件不错，一次全量，永远增量。增量的幅度设置的频度可以略微频繁一些。 问题6： 一主多备的搭建，有服务器ABC,有网友使用服务器A switchover到服务器B,然后基于服务器B搭建备库C 但是恢复的时候碰到了一些问题。环境是10gR2 其实这个问题看起来思路还蛮有挑战，实践起来也很顺手的，理论上来说其实有更多更好的方法，上面的方案是比较常规的方案。 因为是10gR2，没法用11g优越的duplicate方式，但是使用rman备份恢复是完全没有问题的，有几个建议可供参考。 1.主备库的管理，建议配置DG Broker,这样很多操作都能直接忽略了，手工搭建备库看起来还是有些技术含量的，用了DG Broker，发现没有一点技术含量了。 2.主库RMAN，恢复到备库，肯定会有GAP,只是这个GAP的大与小而已，对于备库恢复而言，我们完全不需要关心备份后的临界点在哪里，在备库恢复之 后，备库会从主库去比对差距，然后通过RFS来同步归档，所以无需手工来传递归档，手工设置临界恢复的log_seq等。