迁移和备份架构（复杂的数据库结构）
嘿伙计们， 我需要找到一种方法来备份并将 Oracle 数据库从生产模式迁移到开发模式，反之亦然。
我们有一堆配置表来驱动我们平台上的系统如何运行，并且在设置新系统或进行维护时，我们需要更新我们的配置表。我们希望能够处理开发模式，并且在设置系统/功能后，我们希望能够将所有这些配置迁移到开发模式。
我想运行一个程序，我们给出系统的 ID（来自主表），我将遍历所有表并选择 nvl(..)，如果它不存在，我将插入，如果它确实存在，然后我只需对该行运行更新。
这段代码将变得非常混乱和复杂，特别是因为整个配置模式非常复杂，并且可能很难正确处理所有键。
我正在考虑的另一个选项是触发器，因此在设置新系统时，会记录我们在设置/编辑系统时运行的所有语句，然后我们将在生产模式上运行它。
我是一个合作学期，只使用了 6 个月的数据库，所以我不知道那么多，任何信息/建议都会非常感激。
（我们使用pl/sql）
Hey guys,
I need to figure out a way to back up and also migrate our Oracle database from our production schema to the dev schema and the other way around.
We have bunch of config tables that drive how systems on our platform run, and when setting up new systems or doing maintenance, we need to update our config tables. We want to be able to work on the dev schemas and after setting up a system/feature, we want to be able to migrate all those configs to the dev schemas.
I thought of running a procedure where we give the ID of the system (from the main table) and i would go through all the tables and select nvl(..) and if it doesn't exist, i would insert into, and if it does exist then i just run an update on that row.
This code will get very messy and complicated especially since the whole config schema is very complex and it might be hard to handle all the keys properly.
Another option i was looking at was triggers, so when setting up a new system, there would be a log of all the statements we ran while setting up/editing a system, then we would run it on our production schema.
I'm on a coop term, and have only been working with databases for 6 months, so i don't know that much and any information/advice would be greatly appericiated.
(We use pl/sql)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用导出/导入（或数据泵）来引入配置表怎么样？
What about using export / import (or datapump) to bring over the config tables?
查看数据比较工具，例如此
我想 TOAD 已经内置了一个。我确信还有其他的。
Check out data comparison tools like this
Think TOAD has one built in. I'm sure there are others out there too.
模式中的表通常被我们称为“静态数据”，即用户不会更改它，因为它控制应用程序的工作方式。
对配置数据的每次更改不应在目标环境中临时运行。相反，您可以在一个或多个脚本中仔细设计和编码 DML，这些脚本在开发环境中进行测试，签入变更控制，并且可以在需要时在任何环境中重新运行。
It is common to have tables in a schema that are what we call "static data", i.e. the users don't change it because it controls how the application works.
Each change to config data should not be run ad-hoc in the target environment. Instead, you design and code your DML carefully in one or more scripts, which get tested in a dev environment, checked into change control, and can be re-run in any environment when required.