HDTenEightyP/NetNews huggingface dataset:
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: Hot Standby DBMS's
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 21 Aug 1992 01:17:47 GMT

In article <1992Aug20.192538.17842@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:
[about TUXEDO...]
>
>Another new feature allows separately administered TUXEDO networks
>to call each others services and allows transactions to span these
>networks.
>
>This means that a bank's application, which knows how to debit your
>bank account, and a stock brokerage application, which knows how to
>buy shares of stock, can be linked in a distributed transaction
>such that the stock purchase and the debit occur together.  Without
>this capability, the stock brokerage has to generate a batch EFT
>transaction to the bank that may bounce, but the stock has already
>been purchased.
>
As an implementor of just such EFT systems, I can assure you that this
would be unthinkable. Distributed transactions have the well-known effect
of eroding system autonomy. If one system goes down, it can leave various
locks on the other which can not be broken until the system is recovered
(unless they are forcibly broken, resulting in possible inconsistent databases
requiring manual resolution).

>These facilities allow for a hot standby system or network to exist
>far away, with all service requests done both locally, and also queued
>for processing at the backup site. (I'm talking about high level
>application requests: DEBIT, RESERVE-ROOM, etc., not physical database
>operations.)

Again, I must say that this is impractical. Unless the system is
trivial, or is single-threaded, you can not
guarantee the same application execution history for a copy of the input 
stream, due to timing differences in race conditions. For example, two
operators request to update the same record at the same time. One is told to
try again later. You can't guarantee that the same one will lose the race
upon a re-execution of the same input stream with slightly different timings.

>One thing that the other proposed schemes do not address is that of
>software bugs.  Whether using locally redundant hardware, or geographically
>separated backup systems, the physical updates to the databases are
>still done by one piece of software.
>
>By architecting the backup system so that it uses a different DBMS,
>or even a different implementation of the application, it is more
>likely that one system will be able to continue processing if the other
>is stopped by a bug.

Maybe you should think about this idea a little bit more. I'll leave it
at that.

Thanks for your post never the less.
It sounds like Tuxedo is alive and well, and perhaps taking on TransArc.
I will have to look into it further.


Newsgroups: comp.databases
From: ozsu@cs.UAlberta.CA (Tamer Ozsu)
Subject: Re: distributed transactions
Organization: University of Alberta, Edmonton, Canada
Date: Sat, 22 Aug 1992 03:34:29 GMT

mao@triplerock.CS.Berkeley.EDU (Mike Olson) writes:

>In <BtCrA6.Iuy@cup.hp.com>, dhepner@cup.hp.com (Dan Hepner) asks for
>details on how non-blocking commit protocols handle network partitions:

>> Maybe you can explain how this apparent dilemma is addressed:
>> 
>> Time 1:  node n acknowledges prepare
>> Time 2:  node n notes an inability to communicate with anyone else, in 
>> 	 particular any site capable of being the transaction coordinator
>> Time 3:  still no communications, patience exhausted at node n

>here's what the distributed systems theorists say:  a partition splits
>a network into two pieces.  whichever piece contains a majority of
>the nodes in the original network may continue processing.  nodes in
>the minority clique cannot make further updates until the partition is
>repaired.

>there are some obvious problems with this -- for example, if no clique
>contains a majority of the nodes in the original network, no one can
>make progress.

Actually, this won't be a problem. Protocols dealing with network
partitioning use a weighted voting strategy where the nodes are
assigned votes such that one of the partitions will always have more
votes than the other. The problem is with multiple partitioning. Dale
Skeen, in the various articles that were mentioned in other messages
talks about this. The whole thing is also treated in our book
"Principles of Distributed Database Systems", Prentice-Hall, 1991.


>the added complexity of three-phase commit, coupled with the fact that
>a clever adversary can force blockage anyway, have meant that it hasn't
>gotten a lot of attention by commercial vendors.  in real life, what
>people do is spend a lot of money on redundant, highly reliable
>communications systems.  when something crashes, some expensive employees 
>get it working again fast.

I agree. There are not too many vendors which implement 2PC either. 
--
____________________________________________________________________________
M. Tamer Ozsu			   Internet: ozsu@cs.ualberta.ca	
Department of Computing Science    Tel: (403) 492-2860; Fax: (403) 492-1071
University of Alberta		   Edmonton, Alberta, Canada T6G 2H1
From: umak@atar.epps.kodak.com (Uma Krishnan)
Newsgroups: comp.databases
Subject: Re: Distributed vs. Centralized Database
Date: 13 Aug 92 14:08:13 GMT
Reply-To: umak@atar.Atex.Kodak.COM
Organization: Atex Publishing Systems, Inc.

In article <1992Aug12.190713.26205@linus.mitre.org>, kalagher@mwunix.mitre.org (Dick Kalagher) writes:
|> 
|> Organization: The MITRE Corporation
|> 
|> I have a question related to response time of a centralized vs. a 
|> distributed database.  Suppose I have a database made up of one record 
|> type that is fairly simple, consisting of 20 or so data elements.  Suppose 
|> there are X records, where X is a large number, lets say 10*6.  Suppose
|> I am concerned about the response time.  If I had all records stored in 
|> one database on a single computer, would the response time be better than having the database distributed among 10-20 computers on a wide area network.  Assume that network traffic is not a problem and that I am using a modern relational database such as |> Oracle 
|> 7.  I may also have thousands of users accessing the database.
|> 
|> Any help, either theoretical or operational would be appreciated.
|> 
|> Dick Kalagher
|> 
|> 

In this model, you have not specified the access behavior, ie. whether it will
be primarily used as a read-only database etc. 

The other factor is that even though it has a homogeneous data structure, the data itself
may not be homogeneous. An example of this, is lets say you have a library
system, and users belong to different univ. departments. The chance of
a comp. sc student interested in fine arts may be dim -  Hence you can
parition the data horizonatally. An index can be maintained with the book
category (fine arts, comp. sc) and the corresponding table.

In the distributed alternative, you say 10-20 computers on a WAN. Does that
imply that the users get to the centralized database over a a WAN? This is not
clearly stated in the model. If users are spread across geographically, then
a distributed solution would make sense in a read situation. In this scenerio,
data will be replicated in the different sites. However, a write is going
to be awfully expensive, since it will have to update all the site databases.
If the data is horizontally partitioned then by keeping the data close
to the access point should yield better results.

Another factor is response time itself. Not all users may need the same
thruput. I do not know if the users themselves can be categorized based
on response time.

Uma Krishnan
Newsgroups: comp.databases
From: yaseen@controls.ccd.harris.com (Rahim M. Yaseen)
Subject: Re: Object What is an OODBMS?
Originator: yaseen@rs2
Keywords: OODBMS, C++, POET
Organization: Harris Controls
Date: Fri, 14 Aug 1992 12:41:48 GMT


In article <1992Aug13.170024.11525@genghis.borland.com>, cy@genghis.borland.com (Cy Shuster) writes:
|> [discusses limits of the relational model to store real world
|> relationships, such as many-to-many]
|> 
|> Have we really come full circle, back to Codasyl networked structures?

In a sense, yes and no.

The yes applies to the fact that networked structures would appear to be 
similar to the physical (storage-level) structures for OODBMSs.

The no applies to the fact that in Codasyl databases, the user-level 
abstractions of relationships is very close to that at the physical-level
(i.e., parent-child) thus requiring users to think like programmers.
In OODBMSs, there is usually a user-level abstraction of relationships
and corresponding semantics of such relationships (e.g. IS-A, IS-PART-OF,
superclass-subclass, inheritance, etc. etc.). Several semantic data models
capture such relationships e.g., extended ER, NIAM, Express, ..
The argument is that if one knows the static relationships ahead of time,
go ahead and define them (note that nothing prevents these relationships 
from being re-defined or changed later i.e., schema evolution)


|> What about the vaunted features of ad hoc queries and on-the-fly
|> joins, over casting relations into concrete at schema design time?
|> 

The way I see ad-hoc queries and on-the-fly joins is that dynamic 
relationships are being created at run-time using domain-compatible values.
There is nothing preventing a query language in OODBMSs from querying
pre-defined relationships AND creating dynamic on-the-fly relationships. 
(I have seen a couple of experimental query languages attempt to do this)
I see this concept as derived relationships: a concept similar to that of 
derived data.

Thus, you have the advantages of two worlds: static (pre-defined) relationships
(which are definable in many large applications) and dynamic (on-the-fly)
relationships.

- yaseen
From: hsr4@vax.oxford.ac.uk
Newsgroups: comp.databases
Subject: Re: Import ASCII to DBase III
Date: 14 Aug 92 15:12:51 GMT
Organization: Oxford University VAX 6620

In article <14257@mindlink.bc.ca>, Tom_Gowdyk@mindlink.bc.ca (Tom Gowdyk) writes:
> Can someone tell me how to import an ASCII file into DBase 3.  The manuals are
> not clear on how or even if I can do this.

It depends on the organisation of your ASCII data.

If your data looks like this:

1234433221KING123GREEN2233.54456

then you can define your fields appropriately, and APPEND FROM <ascii-filename>
SDF.

If your data looks like this:

123 44 332 21 KING 123 GREEN 2233.54 456

then you can define your fields as before (i.e. don't include the blanks) and 
APPEND FROM <ascii-filename> DELIMITED WITH BLANK.

You can also try defining your fields as before but insert between each defined 
field a character field (called, say, S0, S1, S2, S3, S4, S5) of type CHARACTER
and length 1.  Sometimes I've found this to be a more reliable way of bringing
data on board than using the DELIMITED WITH BLANKS, especially when the number
of delimiting blanks varies! :-).  Once APPENDED ...SDF, the structure can be
modified to drop the S0, S1, ... et al.             ^^^

If your data looks like this:

123,44,332,21,KING,123,GREEN,2233.54,456

then define your fields, etc., and APPEND FROM <ascii-filename> DELIMITED.

Hope this helps,

Peter Brooks
Newsgroups: comp.databases
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: Hot Standby DBMS's
Organization: The World Public Access UNIX, Brookline, MA
Date: Tue, 18 Aug 1992 12:31:23 GMT

In article <9208172103.AA04378@hplwk.hpl.hp.com> albert@HPLWK.HPL.HP.COM (Joseph Albert) writes:
>
>Jonathan Edwards writes:
>
>>In the transaction-processing world, there is the concept of a 'hot standby'
>>system, which is a geographically separated system containing a copy of the
>>database, and capable of coming online very quickly. The replicated data must
>>be close to current, and guaranteeing complete synchronization is required
>>by some applications. A further feature is the ability to 'catchup'
>>incrementally to missed changes after an outage, without a complete database
>>copy. Our database (homebrew non-relational) does this.
>>Are there any other databases that can do this?
>
>A more reliable fault-tolerance would be obtained from redundancy at a
>level which is lowered than the level of abstraction of the database.
>Disks can be made redundant by having 2 or 3 physical disks, with
[...]

Yes, this is 'remote mirroring', which I discussed in my post.
Note that I am talking about keeping the systems 100 miles apart. To do disk
mirroring over that distance is EXTREMELY expensive: you basically need a
fiber optic cable. Sending the journal stream of the database requires an
order of magnitude (or two) less bandwidth.
 
And doing 'catchup' requires a complete database copy. Note that most
disk mirroring schemes, including DEC's and OSF's, force you to do a disk
copy (perhaps partial in OSF) after EVERY RECOVERY, even if the disks are
perfectly fine. This goes to show that mirroring is inapropriate to be
implemented at the device-level, and should be instead coupled with a
journal-based recovery mechanism.

>the scheme described at hte beginning of this article, where there is 
>a redundant logical database, with some form of update between
>the real and standby databases to keep the standby one current is
>less fault-tolerant than what was just described. effectively, the
>two databases become one large distributed dbms, with its own newly
>introduced points of failure.

Wrong - unless you are talking about software failures. We are both talking
about two equivalent hardware systems 100 miles apart with a cable between
them. Of course you need at least two cables, preferably not going through the
same telco switching centers. With T1 lines this is feasable - with dedicated
fiber it is even more outrageously expensive.
>
>Joseph Albert
>albert@hplabs.hp.com


Newsgroups: comp.databases
From: prastogi@netcom.com (PARAG RASTOGI )
Subject: RAIMA DATABASE MANAGER ? Experiences ?
Date: Tue, 18 Aug 92 01:33:40 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: RAIMA


I am interested in hearing the experiences from the internet on the
RAIMA's Database Object Manager. Is there any specific usergroup that discusses
this product ?

I am interested in knowing the various opinions and comments on this.

How do the developers feel about using RAIMA's database products in comparison
to SYBASE, ORACLE or INFORMIX database products. Raima's database products 
are based on network model and for mapping Entity relationship analysis to
implementation, it seems like the network model is superior to the relational
model. 

Can someone shed light on this ?


Parag Rastogi
US SPRINT
(916)-636-7379
 
-- 
Oh, when I was in love with you,
	Then I was clean and brave,
And miles around the wonder grew
	How well did I behave.

And now the fancy passes by,
	And nothing will remain,
And miles around they'll say that I
	Am quite myself again.
		-- A. E. Housman
-----------------------------------------------------------------------
#include <std_disclaimers.h>
From:prastogi@netcom.com
-----------------------------------------------------------------------
Newsgroups: comp.databases
From: alessio@cs.columbia.edu (Eduardo Alessio)
Subject: Q&A question?
Organization: Columbia University Department of Computer Science
Date: Sat, 15 Aug 1992 18:23:39 GMT


I'm posting this question for a friend:

	When printing in a landscape mode with Q&A DB, the printer
ignores the program settings:

	paper width: 110
	paper length: 51
	cpi	    : 17 (compressed)
	left margin : 1
	right margin: 110

	The output comes out in landscape but prints only half of the
page. 	Printer is an Epson Lasser JetII; Is there something else that
should be specified?, has anyone had experience with this?.

	All help will be appreciated, Thanks.	
	Eduardo

-- 
   Eduardo Alessio				
   504 Computer Science Building	email: alessio@cs.columbia.edu
   Columbia University			phone: (212)854-5291
   New York, N.Y.  10027                fax:   (212)666-0140
Newsgroups: comp.databases
From: drew@objy.com (Drew Wade)
Subject: Re: OODB Experiences/Opinions (Objectivity)
Organization: Objectivity Inc.
Date: Thu, 20 Aug 92 07:33:10 GMT

In article <1992Aug17.221704.17350@odi.com> dlw@odi.com writes:
>In article <1992Aug14.191216.20576@slc.com> marcs@slc.com (Marc San Soucie) writes:
>
>   > Journal of Object Oriented Programming. June 92. pp 27-43.
>
>   3. It appears that not all of the products were evaluated with equal rigor.
>   At least one of the evaluations appears to be based upon an evaluation copy
>   of the product, which was available to the authorUs for a period of one
>   month in early 1991. Evaluation of other products were based upon extensive
>   use. What is often apparent after extensive use is often not apparent
>   during a one month evaluation - for example usability, scalability and
>   robustness.
>
>I'd like to go even farther than Jacob and Marc.  From reading the
>article, I did not get the impression that the authors did a one month
>evaluation on each of the OODBMS's they describe.  It strongly
>appeared to me that for most of the products, they simply read the
>manual.  People reading the article should keep in mind the inherent
>limitations of an evaluation that's not based on actual use.
>

I'll go yet farther...they didn't even read our manual!  We weren't
in the report.  Oh, well...

-drew wade
objectivity, inc.
-- 
----
Drew Wade
drew@objy.com
Newsgroups: comp.databases
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: Hot Standby DBMS's
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 22 Aug 1992 04:22:19 GMT

In article <BtCM7B.FyG@cup.hp.com> dhepner@cup.hp.com (Dan Hepner) writes:
>From: edwards@world.std.com (Jonathan Edwards)
>
>>Lock races are inherent functionally: what happens when two operators want
>>to update the same record.
>
>While a race in one sense, this is a benign race unlike the disruptive
>race described by:
>
>>My point is that the winner will not necessarily be the same on a 
>>system recieving a copy of the input stream.
>
>If so, your transactions will deadlock, and will not complete. In the
>system described, all locks must be obtained on all systems before the 
>transaction can complete.  The locking behavior is that of two unrelated
>databases.  This is not a claim that there is no problem here: the races 
>must be prevented in order to do any work, a well known problem in
>transactional application design.  But that inability to do work is 
>the penalty of screwing up, rather than an out-of-sync copy of the 
>database or some other manifestation of non-serialized behavior.
>
>Dan Hepner

I think you are changing the subject.
I was replying to a proposal that suggested I could maintain a perfect
copy of a database by simply running the same input stream against the same
application code. I pointed out that race conditions are not deterministic.
You are disagreeing with me while shifting the subject to
some sort of general distributed database with replicated data and
distributed locking. That is a whole nother approach to the problem, and
is the subject of another ongoing thread. So lets save some bandwidth and
put it down.
From: drew@netcom.com (Drew Wade)
Newsgroups: comp.databases
Subject: Re: OODB Experiences/Opinions (Objectivity)
Keywords: none
Date: 21 Aug 92 02:51:45 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


Actually, Hartmut, I can get 'em for free...but that's a bit unfair because
I work here.  :)
But you can get a manual set just by purchasing them.  They're on the
price list for a price designed to cover our costs plus a little -- not
intended to be a money maker.  Feel free to contact remy@objy.com or
info@objy.com.

-Drew Wade
Objectivity, Inc.
800 El Camino Real
Menlo Park, CA  94025 USA
drew@objy.com
+1(415)688-8000 voice
+1(415)325-0939 fax
admin ass't:  Vickie Clements (vickie@objy.com)
information:  info@objy.com

In article <1992Aug20.085436.13400@fzi.de> schreiber@fzi.de writes:
>Message-ID: <1992Aug20.073310.13832@objy.com>
>Organization: Objectivity Inc.
>References: <bem.713721261@stone.NSD.3Com.COM> <1992Aug14.191216.20576@slc.com> <1992Aug17.221704.17350@odi.com>
>Date: Thu, 20 Aug 92 07:33:10 GMT
>Lines: 30
>
>In article <1992Aug20.073310.13832@objy.com>drew@objy.com (Drew Wade) writes:
>> In article <1992Aug17.221704.17350@odi.com> dlw@odi.com writes:
>> >In article <1992Aug14.191216.20576@slc.com> marcs@slc.com (Marc San Soucie) writes:
>> >
>> >   > Journal of Object Oriented Programming. June 92. pp 27-43.
>> >
>> >   3. It appears that not all of the products were evaluated with equal rigor.
>> >   At least one of the evaluations appears to be based upon an evaluation copy
>> >   of the product, which was available to the authorUs for a period of one
>> >   month in early 1991. Evaluation of other products were based upon extensive
>> >   use. What is often apparent after extensive use is often not apparent
>> >   during a one month evaluation - for example usability, scalability and
>> >   robustness.
>> >
>> >I'd like to go even farther than Jacob and Marc.  From reading the
>> >article, I did not get the impression that the authors did a one month
>> >evaluation on each of the OODBMS's they describe.  It strongly
>> >appeared to me that for most of the products, they simply read the
>> >manual.  People reading the article should keep in mind the inherent
>> >limitations of an evaluation that's not based on actual use.
>> >
>> 
>> I'll go yet farther...they didn't even read our manual!  We weren't
>> in the report.  Oh, well...
>> 
>> -drew wade
>> objectivity, inc.
>
>Did you ever try to get Objectivity/DB manuals without actually purchasing
>the software?
>
>You won't get it!  Oh, well...
>
>--
>
>Hartmut (schreiber@fzi.de)
>
From: ftmx@acad3.alaska.edu
Newsgroups: comp.databases
Subject: data and/or info
Date: 18 Aug 92 18:17:25 GMT
Organization: University of Alaska Fairbanks


	Anyone who has data or other materials about the relations of
introcellular organs? I am interested in the research of
interorgan-relationship. Anyone who has information about this please tell me.
Thank you very much. Anyone who is interested in this please don't hesitate to
contact me.
Thank you very much.
Newsgroups: comp.databases
From: jrawles@leland.Stanford.EDU (jody rawles)
Subject: Revolutionary Software's rdbX: Comments sought.
Organization: DSG, Stanford University, CA 94305, USA
Distribution: usa
Date: Wed, 19 Aug 92 01:05:58 GMT

Has anybody had any experience with Revolutionary Software's rdbX?
I would appreciate any comments and experiences anyone can offer.

Thanks in advance,
-- 
Jody M. Rawles					
Department of Psychiatry 		email: jrawles@leland.stanford.edu
Stanford University School of Medicine	voice: (415) 858-3914
Stanford, CA 94305 USA			fax:   (415) 493-4901
Newsgroups: comp.databases