最近的几个技术问题总结和答疑（七)
今天抽空整理，发现近期问我数据恢复，灾备的问题还比较多，我简单整理了一下。
问题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等。
问题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等。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2120769/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-2120769/