|
|
最初由 Yong Huang 发布
[B]I'm afraid I have to clarify something you wrote. A server process *is* what Oracle articles sometimes call foreground process, as distinct from a background process (v$bgprocess). But you may already agree with this.
You seem to keep saying before image of a data block is written to log buffer (and eventually redo logfiles). That's not true. As I said, redo records only record changes, no before image, which is what rollback or undo does.
"在频繁执行Update操作的情况下，LGWR会满负荷运行" should be qualified to be "在频繁执行DML操作的情况下 *and* with frequent commits,..." Without commits, LGWR doesn't work that hard. It's true that without commits, server processes still write redo records into log buffer. But LGWR only works when log buffer is 1/3 full (the 3 second rule still applies but it's unrelated to frequent DMLs).
A change vector does not contain before image. It does have block DBA, as well as block version number and op code.
By "在编写程序的时候要集中transaction再进行处理", you mean commit only if absolutely necessary? That's good advice because you want to avoid too many log file sync waits, one common problem in OLTP databases. However, regardless how frequently you commit, the amount of redo is about the same and is dependent on your business logic.
Generally, update generates the most *undo*, insert the least, delete in the middle unless it's a long row. (But you can create cases this general rule doesn't apply.) It's an interesting question which one of the three generates the most or least *redo*. I think since the accompanied undo for these DMLs also generates redo, the total amount of redo follows the same order (i.e. update > delete > insert). Anyway, I don't follow your logic that "UPDATE、INSERT、DELETE对REDO日志文件写入的信息量并没有太大的差异" based on logfile block size being 512.
Yong Huang [/B]
Can you please provide more information about change vector? Which is the correct explanation? |
|
楼主: liyongdong
IP卡
狗仔卡
发表于 2006-8-6 16:22
显身卡
