当前页面位置: » 丰搜网 » 文档中心 » 详细内容
oracle数据库复制常用脚本
oracle 数据库复制常用脚本
（石骁騑 2001年07月30日 17:30）
oracle的数据复制是一个oracle数据库产品中比较成熟的一项技术，它是整个分布式计算解决方案的一个重要组成部分。对于具有复制环境的数据库系统，和oracle dba一样，同样要有一个人来专门负责维护oracle的数据复制问题，称之为oracle replication administrator（oracle复制管理员）。本文就oracle数据复制中复制管理员经常关心的一些关于复制系统的问题，编写了不同的存储过程。当然，通过oracle提供的复制管理器也可以达到这些目的，但在实际应用中，oracle复制管理器具有不灵活，速度慢，同时我们不能对其查询结果进行随意控制等等的缺点。
一、查看oracle8x延迟事务队列调用及调用个数
推（push）一个大的延迟事务（deferred transactions）队列是非常慢的。一个常见的问题就是一个事务中含有非常多的调用（calls）。如果系统检测到一个错误，如ora－01403（数据未找到错误），也就是我们常说的检测到冲突，而且没有冲突消除方法，写到deferror错误表和回滚事务的时间就会更长，事务中如果调用calls很多，则消耗在任何一个调用的时间就会以指数形式增长。
对于数据复制中每个事务的调用数oracel强烈建议不超过50个。下面的存储过程提供了一个快速查看延迟事务队列中的事务列表以及每个事务中调用数的脚本。输出是以传输顺序排列的，这个顺序就是事务将要传播到主节点的顺序。这对于确定传播中的延迟以及挂起等是非常有帮助的。
在搭建oracle数据复制环境中，有一个经验是值得注意的，那就是一定要设置冲突解决方案，即可使用oracle系统提供的几种方案，也可以自己编写脚本来完成冲突处理。为什么这样说，一定要设置冲突解决方案，也许我们可以说，我们的复制环境是一个单项复制，不可能出现冲突现象。在这里我讲一个自己的亲身经历的例子来说明这个问题，在实际工作中，我搭建了一个具有15个节点的高级复制环境，一个主定义节点，14个主节点，其中14个主节点向主定义节点单向传递数据。一般来讲这种情况下不会出现冲突。但是在实际应用中，问题就出现了，其中几个节点在传输了一些数据后，就挂（hang）了起来。所有可能查找的原因到查了，始终发现不了问题的根结。最后发现是由于数据传播到远程节点后，出现了错误，而在该节点又没有设置冲突解决方案，同时出现错误的该事务又具有超过1000条的调用。其中有一条调用出错了，事务需要回滚，而这个在本地和远程节点间的回滚时间就会以几何基数增长。就出现了前面谈到的系统挂起（hang）的表现。这也就是说即是在根本不可能出现冲突的系统中，由于偶然的不定的错误进程，批量数据的处理以及没有考虑复制情况下的数据导入都可造成在传播过程中严重的性能问题，最严重的情况就是系统挂起，不能完成正常的复制工作。最简单和有效的办法就是在多路复制环境下设置一个系统确省的冲突处理方法来避免这种情况的发生。
下面这个存储过程就是在oracle 8 环境下列出延迟事务队列中的事务和事务中调用个数的脚本，该脚本对oracle 7 不支持，这是因为oracle 8 和oracle 7 的复制机制发生了变化。
存储过程调用方法：
在sql/plus下，首先运行下面的设置，使存储过程的输出到屏幕上，
set serveroutput on size 200000
exec p_list_transactions(ora_sjjk);
其中，存储过程的参数as_destination为所要查看的事务传播到目的节点的延迟队列，为数据库联接（dblink）名。
如果我们看到一个事务具有很多的调用（超过50个），这个事务很可能就是造成延迟事务队列推过程延迟甚至是挂起的原因。
附：存储过程脚本：下载该脚本
create or replace procedure repadmin.p_list_transaction(as_destination in varchar2) is
local_node varchar2(128);
