oracle中跟踪数据变化的最佳方法

发布于 2024-11-02 13:37:16 字数 321 浏览 2 评论 0原文

正如我所说的标题,在oracle中跟踪数据变化的最佳方法是什么?我只想知道哪一行被更新/删除/插入?

一开始我想到了触发器,但是我需要在每个表上编写更多触发器,然后记录下影响我的更改表的rowid,这不好,然后我在Google中搜索,学习有关物化视图日志和更改的新概念数据捕获,

物化视图日志对我有好处,我可以将它与原始表进行比较,然后我可以获得不同的记录,甚至不同的字段,我认为方法与我从原始表创建/复制新表相同(但我不知道有什么不同?);

更改数据捕获组件对我来说很复杂:),所以我不想浪费时间来研究它。

有人有在oracle中跟踪数据变化的最佳方法的经验吗?

as the title i am talking about, what's the best way to track data changes in oracle? i just want to know which row being updated/deleted/inserted?

at first i think about the trigger, but i need to write more triggers on each table and then record down the rowid which effected into my change table, it's not good, then i search in Google, learn new concepts about materialized view log and change data capture,

materialized view log is good for me that i can compare it to original table then i can get the different records, even the different of the fields, i think the way is the same with i create/copy new table from original (but i don't know what's different?);

change data capture component is complicate for me :), so i don't want to waste my time to research it.

anybody has the experience the best way to track data changes in oracle?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

北斗星光 2024-11-09 13:37:16

您需要查看 AUDIT 声明。它收集 SYS.AUD$ 表中的所有审计记录。

示例:

AUDIT insert, update, delete ON t BY ACCESS

问候,
抢。

You'll want to have a look at the AUDIT statement. It gathers all auditing records in the SYS.AUD$ table.

Example:

AUDIT insert, update, delete ON t BY ACCESS

Regards,
Rob.

吹梦到西洲 2024-11-09 13:37:16

您可能想看看金门。这使得捕获更改变得非常简单,但价格昂贵,但具有良好的性能和快速的设置。

如果性能不成问题,触发器和审核可能是有效的解决方案。
如果性能是一个问题并且 Golden Gate 被认为太昂贵,您还可以使用 Logminer 或 Change Data Capture。如果有这个选择,我会选择 CDC。
正如您所看到的,有很多选项,近实时和离线的。

手动编写解决方案也是有代价的,Golden Gate 值得研究。

You might want to take a look at Golden Gate. This makes capturing changes a snap, at a price but with good performance and quick setup.

If performance is no issue, triggers and audit could be a valid solution.
If performance is an issue and Golden Gate is considered too expensive, you could also use Logminer or Change Data Capture. Given this choice, my preference would go for CDC.
As you see, there are quite a few options, near realtime and offline.

Coding a solution by hand also has a price, Golden Gate is worth investigating.

戏舞 2024-11-09 13:37:16

Oracle 通过重做日志为您完成此操作,这取决于您尝试使用此信息执行的操作。我假设您的需求是复制(跟踪源实例上的更改并传播到 1 个或多个目标实例)。

如果是这种情况,您可以考虑 Oracle 流(其他选项,例如高级复制,但您需要考虑您的需求):

来自 Oracle:

当您使用 Streams 时,复制
DML 或 DDL 更改通常包括
三个步骤:

捕获进程或应用程序
创建一个或多个逻辑更改
记录(LCR)并将它们排队到
一个队列。 LCR 是一条带有
描述一个特定的格式
数据库更改。一个捕获过程
重新格式化从捕获的更改
重做登录 LCR 和应用程序
可以构建LCR。如果改变是
数据操作语言 (DML)
操作,然后每个LCR封装
DML 导致的行更改
对共享表的操作
源数据库。如果改变是
数据定义语言(DDL)
操作,然后LCR封装
对 DDL 所做的更改
源共享数据库对象
数据库。

传播传播分阶段
LCR 到另一个队列,通常
驻留在单独的数据库中
从 LCR 所在的数据库
被捕获。 LCR 可以传播到
在到达之前要排很多队
在目标数据库中。

在目标数据库中,应用
流程消耗变更
将 LCR 应用于共享
数据库对象。申请流程可以
将 LCR 出列并直接应用,
或者应用进程可以使
LCR 并将其发送到应用处理程序。
在 Streams 复制环境中,
应用处理程序执行定制
处理LCR,然后应用
LCR 到共享数据库对象。

Oracle does this for you via redo logs, it depends on what you're trying to do with this info. I'm assuming your need is replication (track changes on source instance and propagate to 1 or more target instances).

If thats the case, you may consider Oracle streams (other options such as Advanced Replication, but you'll need to consider your needs):

From Oracle:

When you use Streams, replication of a
DML or DDL change typically includes
three steps:

A capture process or an application
creates one or more logical change
records (LCRs) and enqueues them into
a queue. An LCR is a message with a
specific format that describes a
database change. A capture process
reformats changes captured from the
redo log into LCRs, and applications
can construct LCRs. If the change was
a data manipulation language (DML)
operation, then each LCR encapsulates
a row change resulting from the DML
operation to a shared table at the
source database. If the change was a
data definition language (DDL)
operation, then an LCR encapsulates
the DDL change that was made to a
shared database object at a source
database.

A propagation propagates the staged
LCR to another queue, which usually
resides in a database that is separate
from the database where the LCR was
captured. An LCR can be propagated to
a number of queues before it arrives
at a destination database.

At a destination database, an apply
process consumes the change by
applying the LCR to the shared
database object. An apply process can
dequeue the LCR and apply it directly,
or an apply process can dequeue the
LCR and send it to an apply handler.
In a Streams replication environment,
an apply handler performs customized
processing of the LCR and then applies
the LCR to the shared database object.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文