Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Mar 1998 17:22:15 -0500
From:      sbabkin@dcn.att.com
To:        shimon@simon-shapiro.org
Cc:        wilko@yedi.iaf.nl, tlambert@primenet.com, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG, grog@lemis.com, karl@mcs.net
Subject:   RE: SCSI Bus redundancy...
Message-ID:  <C50B6FBA632FD111AF0F0000C0AD71EE4132D7@dcn71.dcn.att.com>

next in thread | raw e-mail | index | archive | help

> ----------
> From: 	Simon Shapiro[SMTP:shimon@simon-shapiro.org]
> 
> > Databases are not regular filesystems. They have little number of
> > big files.
> 
> Wrong.
> 
> First, databases can have many small tables (let's stick with RDBMS
> for simplicity).  What you refer to is what you can see from the
> utside. 
> Inside these few big files, is a complex organization that takes
> closely
> 
Yes, but the original mail was talking that if you restore
your backup from tape (and if you make your backup also)
it will take long time to create big number of filesystem
files. If you do export/import on a database, yes, you
will have the same problem. But if you backup a database as
a set of OS files, you will not see its internal structure.

> > Save it to tape as an image of logical disk. Restore it in the same
> > way. With things like OnlineJFS you can even do save it online.
> 
	...

> a.  You cannot shut it down, because the PUC said so and you hate
> prisons.
> b.  By the time you back it up (100 seconds, there have been 20,000
>     modifications to the database.
> c.  If you do a hot backup of the files, you will have approximately
> 10,000
>     changes that are not in your backup.
> d.  If this was on a Unix filesystem, your files are now corrupt.
> Totall. 
>     you tell me why.
> 
No. If you use Online JFS, what you do: make your database
residing in one filesystem. This is a must. Then take another
30G volume (the exact size depends on the intensity of changes,
this one estimates that no more than ~1/3 of blocks in your
original filesystem will be changed during backup) and mount it as 
a "freeze" to your original filesystem. When some operation is done 
on your original filesystem, the contents at the time of "freezing"
will be saved to the second volume. So when your backup reads the
"freezed" filesystem, it will take a proper block from either the
original or second volume. 

Yet better idea: don't store your database right in the filesystem, 
store it in Oracle and you will get possibility of online backups
for free.

> This is a simplistic examples.  Life is nastier than that.  Can it be
> solved?  Of course.  With Unix? Yes, what do you think a 5ESS switch
> runs?
> With FreeBSD?  Yes.  As is today?  No....
> 
Unless someone will make Oracle working on it :-)

-SB

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C50B6FBA632FD111AF0F0000C0AD71EE4132D7>