Hi,
and thanks for replys to (so far):
>>> webster_at_europa.mdc.com:
---------------------------
>>> I agree that the chfile manual page is misleading, but I have never
>>> seen a sane filesystem implementation that can guarantee application
>>> file stability...
>>> ohad_at_comport.com :
----------------------
>>> Sybase does not support any unix file system! ...
>>> ... Oracle supports running on ADVFS with integrity!
My own conclusions:
As far as I know, Sybase used to support running on top of JFS onto AIX.
Does this mean Sybase did a special AIX implementation ?
I used to test Sybase on ADVfs with DATA LOGGING == ON and deliberately
provoqued tens of crashes and power outages. No problem so far ! BUT when
data logging was off, the database check reported major corruptions. In
addition, Sybase stated that if DEC supports data logging onto ADVfs, they
"support" the FS implementation. Sybase assumed data logging to guarantee
the fact that a successfull write returned to application meanned that
data was on stable media.
So, we used this ADVfs implementation with a life system. But then my
system started to crash and DEC UNIX engineering stated there is a problem
(which they did not know about until me escalating it) with the DATA
LOGGING being turned on for ordinary files. I know they will fix this
problem in the future; but, in the meanwhile, they tried to prove to me
that "chfile -l on" brings no benefit - other than statistic ! (as you
could read from my mail).
So, yes, I'll move all Sybase installations to raw device (or raw LSM),
but this may also mean we no longer use DIGITAL UNIX for Sybase.
Cheers,
/lh
Full responses below:
=====================
hello there,
Sybase does not support any unix file system! the only way to get
reliebility from Sybase s to run all your disks raw. I just finished doing
3 large Sybase installes. If you have Sybase running on a file system
and the system crashes - you will have to restore from tape! The three
things that we hope for Sybase in the future are the FS support, large
block size, and better read-ahead.
Oracle supports running on ADVFS with integrity! I have been running Oracle
on D.U. + ADVFS for about 2.5 years, and never had a problem! Even when
one of the machines crashed - Oracle came back without any problems.
Just like archive loggin enables Oracle to keep all the transactions
since last backup - So does the ADVFS logging. It saves all changes to
the file - so the having the old data on disk and having all the loggin
information you then can recreate the actual new data. This is also how
you are able to create a clone files set and get a good backup of it!
Good luck,
Ohad
----------------------------------------------------------
Lucien,
I agree that the chfile manual page is misleading, but I have never seen a
sane filesystem implementation that can gaurantee application file
stability.
The promise of journaling filesystems has always been that the system
would ALWAYS come up with a stable filesystem. Writes that had not been
flushed to the logs or had not finished being written to the logs would be
lost.
The chfile logging option seems to just be a way of instructing ADVFS to
write more, smaller logs to the journal, more often. While it would be
possible
to require that the log had been written to the journal before the write()
returned, I think you would find that performance would go right down the
drain.
Besides that, is Sybase willing to confirm that all of the needed updates
to retain application stability are done as part of a single write() call?
I don't think that they will. Even if all writes are un-buffered, I'd
have to belive that there are points where a system failure would render
databases or indexes unstable. (Ok, maybe in a PURE TP envirionment, you
would get the logical equivelant of a journaling filesystem for the
DB....) Is this the claim
Sybase is making with raw partition use?
In any event, if you:
1. Physically secure the server.
2. Connect the server to a good UPS.
3. Use redundant power supplies in the server.
4. Use RAID-0 or RAID-5 (with no controler caching or battery backed
caching). 5. Use ECC RAM.
I can't think of much that would manage to munge the system (other than
something
that the users or sysadmin does via software (intended or not)) that these
steps wouldn't cover. If you make the assumtion that the software is
running, everything
else is a matter of providing a safe environment for the system, where you
can gaurantee that it always has time to flush its buffers.
BTW - CC:Mail is encoding your message as an enclosure, rather than as
text encoded
mesage text. You may want to look into this, or not.
Just my $0.02's worth,
Tom
Received on Wed Nov 27 1996 - 12:02:11 NZDT