Oracle跨数据库实现定时同步指定表中的数据

简介: Oracle跨数据库实现定时同步指定表中的数据

一. 概述


在目标数据库中向源数据库建立一个database link远程连接,之后编写一个存储过程,用于将源数据库中的数据同步到目标数据库,再编写一个Oracle定时任务,最后在该定时任务中执行上述存储过程,即可实现定时同步。


二. 具体实现步骤


(1)在目标机上使用sqlplus登录


<pre><code>

sqlplus tianzhi_smart/tianzhi_smart@10.2.200.133:1521/orcl

</code></pre>


(2)建立远程连接database link

用如下命令建立DB Link:


<pre>

create public database link db21

connect to scott

identified by "tiger"

using '192.168.56.6:1521/ORCL';

</pre>


注意事项:


  1. 创建远程连接的类型必须为public;


  1. 在创建dblink时,要注意,有时候可能会报用户名和密码错误,但实际上我们所输入的账户信息是正确的,此时就注意将密码的大小写按服务器上所设置的输入,并在账号密码前号加上双引号(服务器版本不同造成的)。


(2)创建存储过程


<pre>

create or replace procedure UPDATETEST

as

begin

delete from TEST01;

insert into TEST01 (ID, NAME, SAL) select ID, NAME, SAL from TEST@db21;

dbms_output.put_line('同步成功!');

end;

/

</pre>


(3)创建任务JOB


<pre>

SQL> variable job1 number;

SQL>

SQL>

begin

dbms_job.submit(:job1,'UPDATETEST;',sysdate,'sysdate+1');

end;

/

</pre>


说明:


  1. 定时任务调用执行存储过程,执行时间间隔为1天,1/1440为一分钟。


  1. 时间不要设太短,否则很吃内存,会造成电脑卡死。


(4)运行任务JOB


<pre>

SQL> begin

2  dbms_job.run(:job1);

3  end;

4  /

</pre>


(5)删除任务JOB


<pre>

SQL> begin

dbms_job.remove(:job1);

end;

/

</pre>


三. 工作心得

(1) 磨刀不误砍柴工


对于此类步骤清楚,条理清晰的问题,在执行过程中,一定要确保每一步的执行结果都是正确的,千万不要等到执行到最后一步时,才去检验是否存在问题。


如果不对前面的步骤进行检验,只等到最后一步出现问题的时候才去检查。不仅不能明确问题出现的准确位置,而且还得倒着层层往前查找问题。如果问题是出现第一步,那之后肯定会连环出问题,这样不仅可能会需要大幅进行修改,而且还会很影响状态,费工费时。


而如果没进行一步,就检验清楚,将战场打扫干净。来一个干掉一个,后面即使出现问题,也是属于各个击破,不至于搞成被群殴的下场。


(2) 书到用时方恨少


这两天公司项目处于上线调试阶段,由于项目需要部署在集团公司机房,而集团公司又距离公司有一定的距离,同时集体公司机房为了确保安全又是与外界隔离开来的。所以,在部署调试阶段,出现问题,都只能是现场进行解决,而不能再是带回公司进行解决。


而出现问题时,我一直有一个感受。那就是通过上网搜索或者询问别人的方式,基本都可以想出来一个笨方法。而笨方法一般都是属于套路性的方式,代码重复率很高。

人都有偷懒的心理,为了少干点活儿,都会想一些巧方法。而我想出来的巧方法,一般都是知道有这种方式,但就是不知道如何具体去用。比如AOP,设计模式,涉及到复杂逻辑的存储过程等。


由于平时学的少,学的不够深入,虽然知道,但等到真到用的时候,却两眼抓黑,无处下手,真有一种摔头捶胸之感。


(3) 主动学习专业技能,物质基础决定上层建筑


一直在工作之外,逍遥地干着轻松愉快的事儿,完全不顾及工作技能上的不足。现在倒好,由于技能实力不足,有问题有任务时,不能及时杠上,都快要危及到自己的饭碗了。如果饭碗丢了,还拿什么谈诗和远方。


别看上面的解决过程简单,昨天就是为了解决这个数据库同步的问题,愣是折腾到凌晨十二点半。坚持日更千字不间断的我,愣是不得不中断一天。现在看来,这完全是可以避免的。如果平时注意多多积累专业知识,主动学习专业技能,提升学习和适应能力,遇到此类问题肯定是可以在不到一个小时的时间内就处理掉,而我愣是折腾了将近一天的时间。


平时看似在工作之外的时间,多花了时间做自己感兴趣的事情,看似是有效利用了时间,但虽然工作上出现的问题越来越多,才发觉自己其实在不恰当的时间段内做了应该分散开来的应该做的事情。导致没有利用完整的时间去进行充电学习。而专业技能上不来,工作上问题得不到及时解决,只得去加班,去熬夜解决,这不是自己工作努力的表现。这都是平时不注意学习的结构,而平时不注意积累,到最后只会低效的工作拖累,浪费大量的时间。


总之,工作之外的时间,主动学习专业技能,不是在占用业余时间,从长远来看,是在节约业余时间。因为以后技能提升了,工作效率提高了,反而会留出更多的业余时间去做自己想做的事情。工作技能提高了,才能保证好自己的饭碗,才能去更加随性的追求自己的诗和远方。


适当的时间,干正确的事儿。说的就是这个道理。一句话,守不住饭碗,其他的都是扯淡!

相关文章
|
13天前
|
SQL 存储 运维
从建模到运维:联犀如何完美融入时序数据库 TDengine 实现物联网数据流畅管理
本篇文章是“2024,我想和 TDengine 谈谈”征文活动的三等奖作品。文章从一个具体的业务场景出发,分析了企业在面对海量时序数据时的挑战,并提出了利用 TDengine 高效处理和存储数据的方法,帮助企业解决在数据采集、存储、分析等方面的痛点。通过这篇文章,作者不仅展示了自己对数据处理技术的理解,还进一步阐释了时序数据库在行业中的潜力与应用价值,为读者提供了很多实际的操作思路和技术选型的参考。
24 1
|
17天前
|
存储 Java easyexcel
招行面试:100万级别数据的Excel,如何秒级导入到数据库?
本文由40岁老架构师尼恩撰写,分享了应对招商银行Java后端面试绝命12题的经验。文章详细介绍了如何通过系统化准备,在面试中展示强大的技术实力。针对百万级数据的Excel导入难题,尼恩推荐使用阿里巴巴开源的EasyExcel框架,并结合高性能分片读取、Disruptor队列缓冲和高并发批量写入的架构方案,实现高效的数据处理。此外,文章还提供了完整的代码示例和配置说明,帮助读者快速掌握相关技能。建议读者参考《尼恩Java面试宝典PDF》进行系统化刷题,提升面试竞争力。关注公众号【技术自由圈】可获取更多技术资源和指导。
|
20天前
|
前端开发 JavaScript 数据库
获取数据库中字段的数据作为下拉框选项
获取数据库中字段的数据作为下拉框选项
52 5
|
17天前
|
NoSQL 关系型数据库 分布式数据库
基于PolarDB的图分析:通过DTS将其它数据库的数据表同步到PolarDB的图
本文介绍了使用DTS任务将数据从MySQL等数据源实时同步到PolarDB-PG的图数据库中的步骤.
|
1月前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
103 11
|
2月前
|
关系型数据库 MySQL 数据库
GBase 数据库如何像MYSQL一样存放多行数据
GBase 数据库如何像MYSQL一样存放多行数据
|
2月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
3月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
237 64
|
2月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。

推荐镜像

更多