Re: raw vs. cooked files under linux
We are running 24 instances of IDS 9.4 on 24 machines - about 95% raw
chunks - no problems so far -Can you explain some of your reasoning below?
What specifically are the risks and additional management?
----- Original Message -----
From: "Data Goob" <datagoob@netscape.net>
To: <informix-list@iiug.org>
Sent: Wednesday, May 11, 2005 9:08 PM
Subject: Re: raw vs. cooked files under linux
> Art S. Kagel wrote:
> > Heinz Weitkamp wrote:
> >
> >> Hi all,
> >
> >
> > Go RAW all the way. Contrary to the Goob's understanding my own testing
> > shows RAW devices to be 15-25% faster than COOKED devices which are in
> > turn 10-15% faster than filesystem files, even on the best filesystem
> > implementations that adds up to a 25% improvement. Well worth any minor
> > inconveniences in my book.
>
> OK so you get some speed increases, but also the additional management
> of linking raw files. The original post indicated he was a newbie.
> Raw files are not necessarily difficult, but they ARE optional and not
> something I would entrust to a newbie. It's a great learning experience,
> but who's paying for it??
>
> But another point to make is that in many SAN environments, raw files are
> a complete waste of time, with the data already being spread out over many
> drives, and, with speeds typically in the 10-15K rpm range, or even
faster,
> you get speeds today on cooked files that are faster than raw was even a
> couple of years ago.
>
> Another point, if **YOU** are the one managing the system, do you
> want to create extra work for yourself, and extra risk if you don't
> have to or don't have the experience to work with them? In a
> lot of shops where ONE DBA is the rule, dear god, make sure you know
> what to do with raw systems before taking on the additional management.
> ( Your tips below illustrate the point )
>
> Do you know what to do to restore? This will typically happen right
> as you were about to go on your vacation, so be prepared.
>
> Lastly, many environments change so rapidly that implementing raw
> disks can actually impede repurposing or modifying architectures
> at the pace necessary for the environment/business. To be sure you
> can argue all my points to the opposing view, but the bottom line is to
> do what is right for your environment and the best overall risk for you
> and your career. I would argue RAW is great if you can, but I'd argue
> more that it isn't worth the risk in most circumstances, even if you
> can.
>
> If you want to assume the risks, go for it, making doggone sure you
> do the backups, and perform an actual restore test to your satisfaction,
> something very few DBAs are willing to do. You will be quite surprised
> what your options are at restore-time, make sure you communicate them
> to management ahead of a disaster--you **will** be surprised what you can
> and cannot do if you never do a restore test--reading documentation and
> never restoring at least once is begging the boss to fire you for
> incompetence. Of course with the almost zero number of Informix people
> available to replace you, your job is probably pretty secure even if you
> screw it up. :-)
>
>
>
> I have not yet tested Linux RAW devices
> > versus the various filesystems that Linux directly supports, but early
> > reports when Linux RAW devices were first rolled out showed similar
> > results. The performance gain was one reason why Linus Torvalds was
> > convinced finally to include RAW devices in Linux, a development he had
> > resisted for years. The other major reason being the need to provide
> > high speed low level IO capability to software like IDS that manages its
> > own disk space.
> >
> > I also don't know why Data Goob thinks that you can backup cooked files
> > or devices for IDS any differently than you can raw devices. An archive
> > taken without using ontape or onbar is known as an 'external' archive.
> > In all three cases you can use ontape or onbar to perform online
> > backups. In all three cases if you want to produce an external archive
> > successfully (read "be able to restore the data later") you have to
> > perform the archive while the engine is not modifying the disk
> > contents. That means one of three scenarios 1, 2a, or 2b:
> >
> > 1) Shutdown the engine and use dd, tar, Legato Networker, or whatever to
> > copy the chunk files to tape/CD/DVD/whatever.
> > 2) Run onmode -c block to force a hard checkpoint and block the server
> > from modifying anything until you're backup is complete. Then you
either:
> > a) Back up the chunks as in 1) or
> > b) Break mirrors, onmode -c unblock, backup the mirrors, recreate the
> > mirrors.
>
> Certainly doable for a noob.
>
> :-)
>
> I learn something new every day, but this is not for newbies. Even
experienced
> people will be challenged, especially if they don't do this every day.
Knowing
> the current IT market and the talent pool you will not find many people
who can
> do this, or would want to, thusly, they will opt for cooked--it's easier
on the
> blood pressure and the family.
>
> >
> > UNDER NO CIRCUMSTANCES can you successfully archive the underlying chunk
> > files - whether they are RAW, COOKED, or files - while the IDS engine is
> > actively processing transactions! For an OLTP or OLTP-like server, you
> > could not reliably successfully restore the resulting archive. AN
> > unreliable archive is no archive at all!
> >
> > Sure if you're running a DW server and nothing's been modified in a week
> > and there was a recent hard checkpoint (or you forced one) you'll
> > probably luck out and get a usable external backup without blocking or
> > shutting down the engine.
> >
> > Art S. Kagel
> >
> >> i am an linux newbie.
> >> I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux
> >> Enterprise Edition 8.1 (2.4.21-190-smp glibc 2.2.5) or (8.2) or 9 and
> >> SuSE
> >> Linux Professional 9.3 (2.6.11.4 glibc 2.3.4) (IDS 7.31 UD8).
> >>
> >> Later on i want to upgrade (in place) to IDS 10.0.
> >> Which Version of SuSE Linux Enterprise Edition must I use (8.? , 9 ..)?
> >>
> >> Under Sco Unix we use raw-devices.
> >> Is it better to use cooked files or raw files under these
Linux-Versions?
> >> A colleague mentioned, it can be, that later releases of Linux don't
> >> support
> >> raw-devices. Is that correct?
> >>
> >> Experiences or comments are welcome.
> >> Thanks in advance.
> >> (Excuse my poor school-english)
> >>
> >> Heinz
> >>
> >> sending to informix-list
>
sending to informix-list