如果这不是一个正确的问题，我很抱歉，但是找不到更好的地方。也道歉，因为我是专业领域的新手，可能不知道＆＃34;术语＆＃34;
我们有一个第三方提供的Oracle数据库，我们已经使用了几年，我们的大多数人员级别的数据（姓名，年龄，地址等等）都是我们正在努力的＃34 ;同步＆＃34;我们正在实施的新数据库。这不是必须是实时的，但我们当前的计划是创建我们需要的表的每日快照（总共约80万条记录，大多数表格低于500k），然后输出这些记录并将其导入另一端。
我们获取记录后的所有内容都可以通过我们的管道正常工作，但我们的问题是Oracle DB已经过时了（DBA对升级服务不感兴趣），因此输出会使系统过载（CPU和IO）等待所有输出将使这个过程持续几个小时。
生成这些输出的SQL只是：
CREATE TABLE x NOLOGGING AS (SELECT * FROM table);
commit;
然后通过自定义程序将输出发送到用户的电子邮件（编辑：输出实际上是通过下载链接发送的，因此DB可能会写入CSV文件并存储它，但是不确定）我不知道它是如何编码的（这个第三方对分享它的工作原理不感兴趣）。
另一种选择是创建快照，将其移动到新数据库一次，然后使用过去一天的更改更新新数据库。我非常担心这个因为有几个边缘情况需要考虑甚至更多 - 因为这个数据库有多个主键发生变化（事务2被确定为事务1的逆转，所以他们将2合并为1）。
我们有什么可以做的吗？公司通常如何移动这么多数据或保持数据库定期同步？如果这个过程需要几个小时才能完成（例如，如果我们在早上创建输出并在一天内输出以避免服务器过载），这是一个大问题吗？
编辑：数据库对使用有助于此的软件（例如Cloudberry）甚至内置的Oracle数据泵不感兴趣
答案 0 :(得分：3)
＆＃34;我们有什么可以做的吗？公司通常如何定期移动这么多数据或保持数据库同步？＆＃34;
通常的做法是使用复制方法 - Streams或Materialized Views用于更旧的skool，或Oracle GoldenGate用于有额外现金支付许可证的组织（或需要它的异构数据环境）。对于非常大量的数据，他们可能会选择使用Data Pump进行初始填充，并使用复制来使用增量更新目标数据库。
换句话说，就是你在问题中提到的那些事情。这指出了你真正的问题：你似乎有一个有毒的项目环境。没有DBA团队的积极支持和参与，您将无法实现任何目标。您还没有详细说明为什么DBA对帮助不感兴趣。但是如果你有这个问题并不重要：政治问题对于StackOverflow来说是非常不合适的。
关键是，你所拥有的主要是管理问题。你的老板（或你老板的老板）需要解决这个问题并解锁团队间的渠道。用技术补丁修复政治问题是不可能的，几乎是不可能的;如果你尝试并且没有成功，你就不想抱着孩子。所以 - 如果仅从职业角度来看 - 你应该迅速，广泛和经常地标记这一点。至少要确保风险登记簿中有一些东西。