Re: Popped over from c.d.informix

From: Roy Crabtree <crabtree_at_zero.rtp.dg.com>
Date: Sat, 2 Oct 93 17:41:13 GMT
Message-ID: <1993Oct2.174113.22112_at_dg-rtp.dg.com>


In article <1993Sep28.053141.4458_at_wvus.org> sford_at_wvus.org (Scott Ford) writes:
>Greetings,
>
>I'm just popping over from my normal comp.databases.informix habitat to
>ask a couple of questions about Oracle:
>
>1) do Oracle DBAs make use of raw partitions on disk rather than
> filesystems? informix DBAs practically live in raw partitions.

        Yes.

>

 ...
>2) please tell me that oracle 7.1 or 8.0 (whatever) will have a clean
> online backup. no "fuzzy" stuff. the possibility of incremental
> backups.
>
> no? if one limits themselves to operating system backups (which is
> the preferred method, ostensibly), then an incremental is not
> possible. sure, cpio can do incremental but only by copying
> WHOLE FILES where files have had changes. that, in the eyes of
> the data base, is not an incremental backup. and we're not much
> better off using the export facility, which states, "you should
> have file offline during the export".
>
> the point about a "clean" backup is a request for a facility that works
> within the data base to supply a backup that is consistent at a certain

	I actually do not buy it that Informix does a full DB
	wide clean backup; it DOES produce a serializeable result,
	but not the one that would necessarily have BEEN the serialized
	result of no backup; andthat s not quite what I mean by a
	clean incremental backup.

	I very much prefer to have a backup that can be punted to a spcific
	TIME (as well as rolback log sequnece number) for revoery purposes.

	An if I a mistaken about Informix providing such a thing (and I will
	grant I have not deliberately tried to break Informix 5.0 nor seen
	6.0), then I would also like tosee the performance numbers during
	such a run under full loads against that data base; because the
	Oracle approach (and I am not necesarily an Oracle fan) is a must
	have option for DBs that have constant high transaction rates;
	you just cannot afford to lose the realtime throughput such a
	consistency lock requires (in the implementations I have seen;
	please note a combination of the ORacle backup plus a rollforward
	application to then store the result WILL give you that; no one
	does this on the front/save end; they all do it (Informix included)		on the restore/back end).


> point in time. this is not the same as one "becoming clean" after you
> apply a redo log. the right idea comes from the notion of a read-
> consistent transaction. if only we could do this to backup the whole
> instance. that is a clean backup.

	I do agree with the need for a temporal and transaction serial clean
	backup, though; Isuspect the way to really do this for high
	speed DBs is a Greenlee file approach; only committed data would show to
	the backup process, where ongoing processing would see the rest
	in real stim stream.

>
>Thanks for your comments.
>--
>Scott F. Ford, Data Base Administrator | sford_at_wvus.org
>bps (Benefit Panel Services) | elroy.jpl.nasa.gov!wvus!sford
>888 South Figueroa Street, Suite 1400 | Voice: (213) 489-2694
>Los Angeles, CA. 90017 | FAX: (213) 489-7973
>
> "...The bozone layer: shielding the rest of the solar
> system from the earth's harmful effects...."
>

royc Received on Sat Oct 02 1993 - 18:41:13 CET

Original text of this message