对大容量的数据库操作的一些思路

       同一平台升级数据库，以前版本用exp/imp的时候多些，这往往因为版本差异或者数据库中某些字段，BUG等因素，常常要手工操作的比较多。节省表空间倒不一定，最大的好处就是减少了数据库碎片。今天用到了一个新的工具DBUA，用起来感觉不错，它是对源库直接做动作达到升级的目的，对于大型数据库，用这个方法到可以节省不少时间。     

 

      偶然碰到这个行业的一个大牛,和他谈起单Instance转换成RAC的方式，如果碰到容量很大的数据库，如何才能减少停机的时间，我提出的方案就是常用的那种方法，即先把一个Instance变成RAC方式，然后再把其他节点加进来。其中花时间最多的是RMAN恢复的时间，应用会收到影响是肯定的，比如，如果一个大型数据库需要恢复5个小时，那在一切顺利的情况下，数据库至少要停5小时。他给了一个新的思路，就是架一个单独的DG，把DG做成RAC方式，然后主存切换，整个过程数据库停机10分钟都不到，真是强人。

      附上11G的Active DG，可以做到一边应用Archive，一边查询。这样可以将MSS类型的应用和OLTP的在服务器层分开，他目前维护的数据库是10G，也实现了这个方法，具体没问是不是用的这个软件。

     

      备份方面就不用讲了，备份时对主数据库的IO影响是比较大的。不过，大家不要局限于数据库层面，如果你数据文件是放在阵列上，那就可以利用阵列上的功能加数据库的知识可以把这种影响降到最小。现在，一般阵列上都有Snapshot/MirrowView的功能，利用热备指令+Snapshot+MirrorView功能，既可以双阵列热备，也可以实现备份时不吃正式库的IO。

      曾经碰到一些客户说我买2个阵列，并且之间做一个MirrowView，这样放在阵列上的数据库不就更安全了吗，我只能说如果你仅仅做了阵列级别的MirrowView，那是远远不够的，因为这个效果和数据库打开时，把数据文件拷贝走的效果一样。事后，他们做了一下测试，发现备用阵列上的数据库打不开，总是报有坏块，原因不言自明。

 

      说了这么多，作过DBA的人都知道我讲的到底是什么，主要是想说利用你积累的知识，换一种思路，也许会更完美一些。

      那么，今天就聊这么多了，改天继续。

 

Compard

2010/7/21