oracle 数据同步复制故障解决

故障解决：oracle10g 数据库复制同步

呵呵。oracle我是个菜鸟，没花功夫研究它，但我还是兼任dba，目前oracle全部是由以前的dba创建的，oracle确实好。基本没有出过问题，我也就基本不管它了，可是由于自己粗心大意，在一次修改服务器地址时候，数据库里的tns...这个配置文件忘了修改，结果导致同步失败，等我发现的时候，发现已经失效，结果我花了2天时间，才得以解决。。。

先说说问题的发现

我有2台服务器，分别放置于不同机房，系统都为linux，数据库都为oracle10g，俩台数据库之间定时同步数据，有一次我更改了一台服务器地址，后来发现oracle同步出现故障，故障为broken 的值为Y，FAILURES=16,经过google ，说是broken =Y，FAILURES=16就是表示此job 失效，就是不再执行。

故障解决：

经过了无数次的google。。。。。我解决过程如下：

首先用oracle帐号登陆进数据库

sqlplus / as sysdba

然后查询dba_jobs情况

select job,next_date,next_sec,failures,broken from dba_jobs;

于是我运行

execute dbms.job.run(这里是停止了的job-id号)

发现无法运行。

这时发现failures 为16  ， broken 为 Y

经过google，job如果由于某种原因未能成功之行，oracle将重试16次后，还未能成功执行，将被标记broken为Y（说明此工作将标记为破，而FLASE说明此工作将标记为未破）

现在看来这个job为破了，那就先将它改为未破

execute dbms.job_broken(id号，false,next_date);

说明一下：

id号：是停止了job所标示的唯一号

false：表示将broken 设置为false,意思就是未破啦

next_date:表示下一次此job运行的时间。

运行以上命令后，发现提示一下：

提示错误如下：

ORA-23421: job number 109 is not a job in the job queue

ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86

ORA-06512: at "SYS.DBMS_IJOB", line 529

ORA-06512: at "SYS.DBMS_JOB", line 258

ORA-06512: at line 2

通过查询，才明白，如果你是以sys登录数据库的话，如果运行其他用户的job，必须使用SYS.DBMS_IJOB，如果是当前用户登录运行当前用户的job，就用SYS.DBMS_JOB，这我才明白。重新输入上述代码：：

execute sys.dbms_ijob.broken(id号，false,next_date);

输入后完成，显示成功

然后提交 commit;

这时在查询job表的broken，发现那个为破的job，现在以改为未破 N。

接下来在运行execute dbms_ijob.run（id）

发现自动停止，在察看又发现broken 又变为Y。

继续google,学习一下高级复制制作过程。

我这就简单说一下注意的地方：

注意数据库里的配置文件一定正确

sqlnet.ora  tnsnames.ora

我经过察看我将这俩个文件里的修改前的对方数据库地址该为修改后的对方数据库地址，特别注意tnsnames.ora配置文件。

自定义名称=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 另一台库地址)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME =另一台库SID)
    )
  )

看了其他人的文章，大概知道了数据库相互连接的大概情况，我只需察看一下以前创建的内容

 select * from all_db_links;

可以看到这个db links的内容，有owner,db_link,username,host,created,通过察看。我发现我这里的host内容不同于以上tnsnames.ora文件中自定义名称，于是我将tnsnames.ora文件中自定义名称改为all_db_links表中host的名称。

重起数据库，

execute sys.dbms_ijob.broken(id,false,'next-date')

观察中，发现到了next_date，虽然broken没有变成Y,但是仍然没有运行，这时发现this_date 出现日期值，经过查询，this_date为空表示任务闲，this_date不为空表示任务忙，忙有2种状态：任务死锁--next-date为当前时间前的一个时间值，或者是很大的值4001-01-01。

看网上说找到死锁的快照进程号 kell -9 ，可是我不知道哪个才是死锁的，所以我用了最笨的办法，重起数据库。哈哈哈。

可是经过几次启动发现仍然无法启动，我就察看了数据库里的进程；

sql>show parameter job

发现我目前可以有10个可以同时连接

我在给改大些，看网上说，更改范围是0--36，

alter system set job_queue_processes=15

经过察看文章，发现可能和分布式事务有关系，继续寻找问题中；

可以自己上网查一下分布式事务。这个我也不熟悉

分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过dblink update远程数据库的一行记录，如果在执行过程中网络异常，或者其他事件导致本地数据库无法得知远程数据库的执行情况，此时就会发生in doublt的报错。此时需要dba介入，且需要分多种情况进行处理。

然后我重起数据库，死锁进程也随着重起了，

接下来恢复分布式事务：

ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY

最后在开启job定时

execute sys.dbms_ijob.broken(id,false,next_date);

commit;

接下来在观察job 工作情况，

发现在next_date时间到时任务运行成功。恩。。目前解决了一台的数据库同步故障，剩下的另一台也就不用多少了。经过这2天，自己也觉得学到了很多，看来是没有压力就没有动力。。希望和我一样碰到了同样问题的人，我的解决方法可以提供帮助。。故障解决，可以抽根烟奖励一下。。。