ITPub博客

关于Data Guard在我原来印象中是有阴影的，起源是在OCM考试中，有很多同学在一个小时内搭建出Data Guard环境，但是做了主备切换，反复切换的时候出了问题。而自己在搜狐畅游的一大收获也算是Data Guard了，因为接触各类的环境，碰到了太多的问题，所以就触发了很多的感受或者不满。所以...

今天想到一个问题，如果有一个环境是一主一备架构，根据业务需要做逻辑备份，该怎么规划和考虑。数据库版本为10g,11g这个问题如果在考虑性能的前提下，我觉得是蛮有意思的一个问题。   首先逻辑备份工具，是在物理备份（Data Guard也算一种）的基础上扩展，需要做逻辑备份，一定是业务场景有Data...

昨天对Data Guard的归档压缩进行了一个初步的测试，我今天又做了一些补充。   1.昨天测试的是默认50M的redo，如果redo增大，在IO bound的场景中，是否有很大的变化   2.对于归档压缩来说，数据量如果增大，是否会有较大的抖动，昨天测试的是20G的数据量，初始化了50%   3.对于...

   Oracle Data Guard对归档的传输提供了很多辅助的选项，这个可 以通过log_archive_dest_x看到。  一般说这类的优化，如果有大批量的归档需要传输，对于网络带宽还真是一个不小的冲击，有一种改进方法，就是打包压缩归档，然后传输到备库，然后解压应用，整个过程有几个地方需要注意，整个过程...

   对于DBA来说，面对误操作带来的数据恢复难度，其实很大。主要有以下几个方面：误操作的影响范围极大，很可能不是删点，改点数据的操作，有时候可能是让人望而兴叹的truncate,drop操作。数据恢复时需要确认数据损坏的时间点，依此来作为数据恢复的一个基准，该舍弃多少数据，该如...

     Oracle Data Guard中很可能出现延迟的情况，而数据一旦出现延迟就意味着丢数据。退一步来说丢数据总比数据乱了好，但是回过头来，能不丢数据但是丢了，这就有些说不过去了。    因为预防人为误操作等，可能有些环境中会特意设置一个延迟，基本就是下面的设置方法：方法1...

   今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。   在一个一主多备的环境中，的确需要...

    大概在2年前，我写过一篇文章，当时也算是随感。由Gavin King的故事所做的感悟 (r4笔记第24天) ，年轻嘛，都是意气风发，想好好撸起袖子大干一场。    但是可能很多人都会碰到了这样一个问题，那就是在公司内造轮子的情况非常普遍，而且很多时候一个脚本，工具，系统只...

    对于Active Data Guard，我是这样想的，可能会有很多不对的地方，互相讨论，一起补充吧。    如果有一天我成了Oracle的产品架构师，时光倒退10年，那个时候还是9i,10g的年代，现在摆在我面前的一个艰巨的任务那就是Data Guard的可用性，易用性的问题，刚刚从xx部门得到了一份...

    DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来...

    在Oracle 10g的中搭建Data Guard环境真是一个纠结，目前大体都是采用两种方式，一种是rman备份，一种是duplicate的方式，但是这两个地方不够让我满意，一来是rman备份数据量不小，需要先在本地生成备份，然后拷贝到备库去，这个搭建周期略长，另外一个就是推荐的方式duplicate,在10g中有些鸡肋的味...

sdasdf

    今天看到有一个网友提了一个问题，描述很简短    测试DG时，主库不能宕机，如何测试failover?    其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就希望在备库上做一下演练工作，而这个演练其实又不想影响到目...

对于备库的使用，尤其是一主多备的环境，一直以来有一点感觉不大给力，那就是主备库的关系，总是感觉会少一点什么。尤其是在做月度404审计的时候，总是要反复确认备库的IP。如果是手工管理的场景中，基本就是查看log_archive_config的配置，也还需要解析里面的TNS配置如果配置了DG Broker，可能情况会好些，输出的关系是...

自前些天写了一个脚本之后，今天特意测试了一下，没想到一下子发现了一个大问题。有一套一主两备的10gR2环境，一个异机备库一直在READ ONLY状态，也就意味着数据库在打开之后一直忘了恢复应用归档，然后在某一天发现时，已经延迟了好几个月。无论怎样，还得庆幸发现了这个问题。目前来看一种行之有效的方法就是重搭备库，...

应有些网友的要求，今天还是硬着头皮把半自动化的方案给发出来了。内部测试了一下，因为我是开发者，使用者，所以都玩得转，大体的测试，从安装数据库软件到搭建Data Guard，在duplicate同步数据前，大概用了近15分钟时间。明天会再次测试一下，争取把脚本分享出来，当然脚本里的小问题很多。   &nbsp...

今天总算抽了些时间把半自动化的脚本完成了大半，目前还缺少两部分的脚本，一部分是安装前的检查脚本，可以做一个预检查。虽然目前来看还不是必须，但是这些是标准和规范的地方，这些条件不满足，失败的概率会加大。另外一部分是安装后的补充脚本，其实安装后还有很多需要注意的地方。大体想了下，补充的脚本包含下面的部...

关于半自动化搭建Data Guard，自己花了一些时间，总算是把这件事情继续推进了一下，还是再啰嗦一句，为什么不自动化，因为安全。主库就是主库，任何变更都要手工检查审核，自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP，不用一次又一次连过去配置和检查，当然要完成自动化还是半自动化，有些网友...

    一直以来搭建Data Guard是一件看起来还蛮有含量的工作，因为这其中涉及的工作比较琐碎，比较细，况且手工搭建起来都会碰到各种各样的问题，如果中途碰到一点儿小问题，那可能需要花点时间来排查，如果想要脚本自动化，那简直寸步难行。所以搭建Data Guard一方面会需要很多的提前准备和配置，另一方面这...

其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节，也是最关键的处理过程。假设你半夜正在睡觉，被报警电话惊醒，得知某个服务器产生了故障宕机，在这种情况下，我们大体会有下面的处理流程：1）检查原来的节点是否可用，需要查看ILO和存储，是否存在异常2）如果原来的节点可以重启，可以尽量马上恢复业务...