>>>>> "ai" == Asif Iqbal <vad...@gmail.com> writes:
>> If you disable the ZIL for locally run Oracle and you have an
>> unscheduled outage, then it is highly probable that you will
>> lose data.
ai> yep. that is why I am not doing it until we replace the
ai> battery
no, wait please, you still need the ZIL to be on, even with the battery.
disabling the cache flush command is what the guide says is allowed
and sometimes helpful for people who have NVRAM's, but disabling the
cache flush command and disabling the ZIL are different. Disabling
the ZIL means the write can be cached in DRAM until the next txg flush
and not issued to the disks at all, so even if you have a disk array
with an NVRAM that effectively writes everything as if it were sync,
the disk array will not even see the write until txg commit time with
ZIL disabled.
If you have working NVRAM, I think disabling the ZIL is likely not to
give much speed-up, so if you are going to try disabling it, now when
your battery is dead is the time to do it. Once the battery's fixed
theory says your testing will probably show things are just as fast
with ZIL enabled.
AIUI if you disable the ZIL, the database should still come back in a
crash-consisent state after a cord-yank, but it will be an older state
than it should be, so if you have several RDBMS behind some kind of
tiered middleware the different databases won't be in sync with each
other so you can lose integrity. If you have only one RDBMS I think
you will lose only durability through this monkeybusiness, and
integrity will survive. I'm not an expert of anything, but that's my
understanding for now.
pgpFapbkFrlFR.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
