DBMS EVAL
Greetings Netters, We are in the process of collecting information to help us evaluate several DBMS products. Vendors are invited to respond, I appreciate the knowledgeable answers and comments, but I would also like to hear from VARS, integrators, users and administrators, in general any additional unbiased (???) information. Our system architecture and requirements are somewhat unique: 1. Distributed/replicated database with 8 database servers feeding over 48 nodes with data in Europe). Each node (db server and replicant) requires a copy of the engine locally. 2. Our system is based on a custom developed distributed database software product based on TCP/IP. The software acts as a 'transport' layer between the applications and the engine, performing the data transmission, queuing and resynchronization of hosts. It is implemented using a weak consistency model to afford the most flexibility and availability of data and isclient/server based with one of the client processes acting as the actual interface to the vendor specific DBMS. This module will require recoding/modification when (if) we change to another back-end product. 3. We currently are using ruggedized HP 9000/375s and 380s running HP-UX 8.0 and Informix 4.1 SE connected together over a packet switched WAN. The 375s are LAN servers with LANs of 375s and PCs. All the 380s are database servers and interact through the WAN to their children LANs. The 375s have approximately 700 MB (SCSI) of disk space (I know this is small) and the 380s have 912 MB (3 x 304 HPIB) to be upgraded to 1.3 GB (1 x 1.3 SCSI). There is talk of moving to the PA-RISC machines or similar (SPARCS?), but with the current budget outlooks... 4. This is a military system so it has to be relatively 'break proof'. In other words, the DBMS should not be too sensitive or finicky. I guess 'low maintenance' and 'robust' sums it up well. 5. We have severe power and user problems (some think its a big PC and simply shut it off), compounded by the fact that we have no effective UPS (UPSes ???) to speak of and the systems often take power hits. 6. The Army is in the process of cutting, cutting, cutting, so cost becomes a factor (large) too. I am of the opinion that we are comm-line (most end users have 9.6 lines) and cpu bound. And that buying Oracle or Online would be a waste. Ingress I know nothing about. In favor of SE, I feel that SE has a much higher robustness (lower sensitivity) to abrupt system crashes or power failures. I realize you may hose a table or index but that can be fixed rather easily. Also, the distributed nature of the databases seems to blow away any advantage that you would have using shared memory and what-not. Then there's cost... With this list of requirements and the leaning toward staying with SE, the question may arise, why change? Well, performance and standardization (we are told that Oracle will become the Army standard) primarily plus a dash of personal preference on the part of many to go with Oracle. I would appreciate any comments that people have regarding Oracle x.0, Ingress, Informix On-line or SE or any other product out there that would meet our needs. Post or E-mail, whatever suits you. I will summarize for those interested. Thanks, Jim Sauer ------------------------------------------------------------------------- James D. Sauer | Voice: 49-6221-577603/04 Technology Applications Inc. | EMail:sauerj@heidelberg-emh2.army.mil HQ-USAREUR | ODSCIM-C4IS-STACCS-E | -------------------------------------------------------------------------