How to get around inconsistence when using Flashcopy for Oracle Snapshot Backup?

Note 300225.1 on Metalink says:
The AIX file system logging mechanism was designed to recover from a power failure or a system crash. In those situations, I/O to all of volumes containing user data, metadata and file system logs stops at the same time. This point-in-time image of the file system and log guarantees that when the log is replayed, all of the metadata will be consistent. [b]In situations where writing continues to either the log or the file system while writes to the other have been stopped, that guarantee cannot be made.[/b]
What on earth happened at the moment that FlashCopy is created on AIX?
Since the FlashCopy is a mirror of the based logcial Vloume Groups, I dont understand why the incosistence happens?

Anyone pls help me.

Thank you

flashcopy or snapshot?

flashcopy is executed by storage and initiated by host or storage console
snapshot is a command of aix to generate a filesystem's photo

or if you mean flashcopy of oracle? I don't know.

for aix jfs/jfs2, it's just like redolog recovery of oracle, but jfs/jfs2 can cover meta data only, the "real data" can not be recorded.

meta data: inode....
real data: the data in a file

ok, as you know, the FlashCopy of IBM Storage Management can get a snapshot - Point In Time. In order to ensure the integrity o fthe file systems on the target volumes during a point-in-time copy operation on AIX, the FlashCopy recommends that the file systems on the source volumes (Based Logical Volumes)be unmounted prior to taking the point-in-time copy.However,online backup for Oracle Database requires the file systems cannot be unmouted. What I actually wonder is what actually happens when performing the point-in-time copy. How the inconsistence happens? If the file systems on the Based Logical Volumes is not unmounted, why will the situations where writing continues to either the log or the file system while writes to the other have been stopped happen? And how does this happen?
Thanks

[[i] 本帖最后由 jpzhai 于 2006-3-25 21:00 编辑 [/i]]

unmount is not necessary, you can ues oracle alter database backup command to free write action to db file, then flash it, and alter db back to normal situation, but the log is writing, suggest you make some check point and switch log before flash. Another method is ues quiesce command, but I forget it, I'm sure there is a freeze db io command supported by oracle, you can check it.

freeze, flash, unfreeze

What happen when flash ? just like you take a photo.

Ok, in the previous post, you said it is unnecessary to unmounted the source file systems, right? Yeah, some people oso said it is unnecessaary. Actually the alter tablespace start backup command will flush cache to disks. And I think it's safe way for the online backup. But the Oracle Metalink says there is potential inconcosistence wehn performing like this. I dont understand how this inconsistence occurs.
below is some what from the Note:
Title:

Restrictions and procedural requirements for creating an on-line copy of an Oracle database utilizing IBM ESS TotalStorage FlashCopy (or similar point-in-time "snapshot" copy features provided in other storage subsystems) on the AIX platform.



Abstract:

In order to ensure the integrity of the file systems on the target volumes during a point-in-time copy operation on AIX, it is recommended that file systems on the source volumes be unmounted prior to taking the point-in-time copy. When online (hot backup) copies are required, the file systems cannot be unmounted and alternative measures are required to ensure the integrity of the target volumes.  








Cause:

If any writes are occurring to the file systems on the source volumes when the point-in-time copy is established, unexpected errors may occur, compromising the integrity of the file systems on the target volumes, making the target copy unusable.   



The AIX file system logging mechanism was designed to recover from a power failure or a system crash. In those situations, I/O to all of volumes containing user data, metadata and file system logs stops at the same time. This point-in-time image of the file system and log guarantees that when the log is replayed, all of the metadata will be consistent. In situations where writing continues to either the log or the file system while writes to the other have been stopped, that guarantee cannot be made.



Replaying a file system log in the situation where all I/O does not stop at the same point-in-time may result in a corrupted file system. There may be no indication of the corruption at the time the copy is mounted; mount may replay the log successfully and mount the file system. However, at some later time when the inconsistent metadata is accessed there will be problems. If the corruption is recognized as such then the system may crash. If it is not recognized when it is used, the loss or corruption of user data may result.

only wirte a script to let your database is quiescent.then do flashcopy.it is ok

ok thanks