From owner-freebsd-hackers Wed Mar 4 14:49:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11010 for freebsd-hackers-outgoing; Wed, 4 Mar 1998 14:49:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (cagw2.att.com [192.128.52.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA10986 for ; Wed, 4 Mar 1998 14:49:23 -0800 (PST) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by cagw2.att.com; Wed Mar 4 17:16 EST 1998 Received: from dcn71.dcn.att.com (dcn71.dcn.att.com [135.44.192.112]) by caig2.att.att.com (AT&T/GW-1.0) with ESMTP id RAA08596 for ; Wed, 4 Mar 1998 17:19:58 -0500 (EST) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Wed, 4 Mar 1998 17:22:16 -0500 Message-ID: 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... Date: Wed, 4 Mar 1998 17:22:15 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > 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