|
Some points that could be used against Adabas.
Adabas uses global sections to handle communication
between processes on the same node. Each Natural user has a separate
process which communicate with the database server via a shared
section called ADALNK. In order to communicate across a cluster
or a network each node has a network server process which also maps
to ADALNK. This process reads messages from the global section and
routes them, via Decnet calls, to the node running the database
server.
Note that messages are passed using Decnet calls (not Ethernet or CI)
with the overhead of extra message packaging.
Software AG claim that their approach to clusters is more efficient
and provides better performance. They should be asked to quantify
this as I believe they have no comparative figures.
Having a single database server means that there is a bottleneck
in the system. If there is one production database this is served
by a single VMS process. Each of the Natural users have their own
process. A typical split of CPU time between the server and user
processes is 70% Natural, 30% Adabas. As a process may not be scheduled
by VMS across more than one processor in a SMP machine or cluster
then the size of the biggest single processor in the network defines
the total CPU power available. For example, Adabas and Natural running
in a network of 10X2 VUP machines can only make use of about 7 VUPs.
Adabas keeps a cache of disk blocks in memory (buffer pool). This
reduces IOs to disk. However, once a certain percentage of the blocks
in memory have been modified a "buffer flush" occurs where the whole
buffer is written to disk. Any users waiting for response from the
database during this period will have very long response times.
Adabas claims to have multi-threaded update. With V1 of Adabas (the
current version) updates to the same database file must be in the
same thread.
The after image journalling in Adabas is also an optional feature
and, if on, causes an extra load on the system. The automatic recovery
utility does not recover any database changes (e.g. new fields,
new indexes). Instead the utility stops and waits for the operator
to repeat the database modification before proceeding with the
recovery. This is not easy to use.
Adabas backup is fast but does not provide any checksums and redundancy
blocks as with VMS backup.
Software AG claim the existence of 20 utilities as a benefit. Most
users will agree that the number of utilities make them harder to
use. There is no DCL interface to the utilities. Adabas V2 (currently
in test) will provide a DCL-like interface (via foreign commands)
but this is not very good. Input and output files to utilities must
be set up by defining logical names before invoking the utility
rather than by /INPUT= or /COMMAND_FILE=.
If an application written in Natural accesses a field as an index
then removing the index from the database will cause the application
to fail. For example,
FIND CARS WITH MAKE='FORD'
will fail of MAKE ceases to be an index.
Software AG claim that being able to store Natural programs and
objects in an Adabas file is a benefit. However they offer the option
of using RMS files (one per program or object). Most users take
the option and use RMS files. If programs are stored in the database
there are no versions (as with RMS), if a program needs to be restored
from backup then all programs must be restored, space allocated
to program source is finite depending on space allocated in database.
Loading of object from RMS files is much quicker than from the database.
Predict is an optional product from Software AG. It has been ported
from the IBM and looks like an IBM product. Menus contain IBM options
(e.g. references to VSAM) and there is no Vax-like editor. Performance
of Predict is poor.
Software AG sell their products as an "Integrated Software
Architecture" allowing the same products and user interface to be
used on a number of hardware platforms (currently IBM mainframe,
VMS, Wang, and soon Unix). In a mixed hardware environment including
IBM mainframes Software AG are a significant competitor due to the
market penetration and quality of their products on IBM. However,
if the prospect is Vax/VMS only then Rdb should win easily.
Ian Dent, CRAC, Nottingham, UK
|
| Hi Don,
As a humble Rdb freak in Denmark I will try to contribute to your winning
agains ADABAS.
As .-1 says, you should be able to do it, Rdb is a GREAT product.
Just look at V3.1 (announced about two weeks ago)
Have fun.
ADABAS VS. Rdb
I. ARCHITECTURE
A. Rdb implements its architecture via a one DBMS per node.
With this strategy, synchronization must be done at the process
level since the only process communications that work across a
cluster are task to task communication, shared RMS files, and
the lock manager. This synchronization using the lock manager
can negatively impact performance.
> Well one DBMS per node is hardly the case.
> Rdb let the user process do all the work (except Invoke and nasty
> recovery after system failure), thereby slipping out of any problems
> of per node/cluster/server architecture in the cluster.
> It is true that the DISTRIBUTED LOCK MANAGER is used to do all
> communications across the cluster, but this is THE FASTEST METHOD to
> use in a cluster. Yes it uses CPU power, but that should easyli
> outperform any usage of DISK or DECnet.
> And it gives you automatic CLUSTER support not
> one-node-in-a-cluster-is-the-master support (se later aswell)
B. ADABAS utilities a file-server approach which requires no
synchronization between processes. This approach also allows
ADABAS to use its buffer pool for efficient access of commonly
accessed files and records. It also gives the user access to
the most current data.
> Se .-1
> No communication, come on, are ADABAS guessing that another guy in
> the cluster is using the database ??.
> Some processes HAVE to communicate.
II. CLUSTERS
A. Rdb uses the lock manager to maintain the integrity of the
databases in a cluster. The lock manager works cluster-wide
to lock blocks of data being read or updated in cache. However,
in a competitive update environment with the Rdb approach large
amounts of locking must bed one on blocks in the cache as well
as immediate physical writes to the database to maintain
integrity. The immediate writes are necessary to ensure that
the next user gets the current data and not what is in cache.
In a transaction processing environment with the locking and
buffer flushes occurring serious performance degradation results.
In one Rdb benchmark 20% of the CPU capacity was taken by the
lock manager.
> Yep everything is true, exept the SEVERE performance hit, se above
> comment aswell (though the comment has some merit, I'll have to admit)
B. ADABAS does not use the distributed lock manager. Instead a
file-server or single server approach is used. The main
advantage of the approach is performance. The buffers for the
ADABAS nucleus is through the nucleus which eliminates the
problem in Rdb where the remote user has updated the actual
data and has invalidated the buffer, which must then be
immediately flushed to disk.
> Se .-1 to see what the implications are.
III. LOCKING
A. Rdb uses a very complex locking scheme for relations and records
with different reserving and access modes. The locking
complexities introduce problems in maintaining new applications
that use files that are accessed by older applications. The
programmer must be aware of the transaction locking scheme used
in the older applications to make it compatible with his
application, otherwise locking conflicts occur. DEC documents
some of the scenarios where locking conflicts occur when Rdb
is accessed sequentially or through indices.
1. One user has a shared read lock; another has a
shared write lock.
2. One user has a shared lock; another has a protected
write lock.
3. One user has a shared write lock; another has a
shared write lock.
B. The locking of files and records within the files is handled
by the ADABAS nucleus. ADABAS maintains a hold queue that
ensures the integrity of each update while allowing read
access. The hold queue contains the ISN (unique record id)
for any record in the update process. Couple Software AG's
efficient locking approach with sophisticated buffering
algorithms, multi-threaded update, and buffered commits,
ADABAS provides the necessary performance for any high
transaction environment.
> Bull.... by NOT using the lockmanager, they will never be able to
> get same locking performance as Rdb in a cluster.
IV. DATA INTEGRITY
A. Rdb without the AIJ option can result in the loss of data
integrity through a system or disk failure since one is
relying on RMS in these incidents. Data integrity must also
be suspect even when backing up the database since neither
RDO or VMS BACKUP give any ability to verify the integrity
of the backup once completed.
> But who is preventing the user from using AIJ, and the performance
> is negligable.
> Not having any verification, and backup utillities is hardly the
> case.
> V3.1 RMU/BACKUP/ONLINE/AREA/CRC or /CHECKSUM to get complete
> end-to-end error detection.
> Along with RMU/RESTORE/AREA to get the area back again.
> RMU/VERIFY/you-name-it
> and the abilliti to use AIJ rollforward per area gives the
> state-of-the-art Relational daatabase operational utillity.
> And of course Rdb is capable of running the database even with
> sick areas , just dont use the data in the area.
> Automatic recovery from PROCESS DEAD, SYSTEM DEAD and CLUSTER DEATH
> is natural in Rdb.
B. ADABAS provides complete data through comprehensive restart
and recovery facilities. ADABAS guarantees data integrity
at the user, application, system, and hardware levels. Data
protection is provided through the nucleus with features such
as automatic restart and automatic back out. With ADABAS
backup utility the backup information can be verified to ensure
that the backup that was performed without error.
>Hmm, needs manual intervention, and their AIJ is hardly state-of-art
>regarding metadata (se .-1).
V. EASE OF MAINTENANCE
A. Rdb provides one database utility - RDO. This facility is
the DLM. No other database specific utilities are provided
to maintain and report on database activities.
>Rdo, SQL both are "user" and programming interfaces
>RMU is THE manager interface.
>Thje number of utillities is hardly a number showing how easy the
> maintenance is (just the opposite).
B. ADABAS provides some 20 DB utilities to aid the database
administrator in the care of the database. These utilities
provide facilities for backup and recovery, reporting and
monitoring, file loading, file compression, adding or
lengthening columns, creation of indices, etc.
VI. DATA INDEPENDENCE
A. DEC states that SOME database modifications are possible
without having to rewrite the Rdb application.
> Of course just SOME
> The simple ones are: INDEXES define, chage and delete,
> different index types (hash and Sorted), no changes necesary
> Adding new metadata does not require any change to existting programs
> unless the want to use it.
> All metadata changes can of course be done online (ie. other can be
> bound to the database, as long as the do not use that particalary
> matadata), and with data in the tables.
> Alle metadata are subject to BEFORE IMAGE (for rollback) and
> and AFTER IMAGE for RMU/RECOVER journaling.
B. ADABAS permits all database modifications without having
to rewrite the application.
> WOW they have invented the first cross precompiled-application-full-
> dynamic-dictionary system !!!! (I am amazed they dont bring out that
> market information more loudly (hmmm).
> Any change in field length must of course mean some form of program-
> readjustment; atleast recompilation and re-linking must be done, to
> get new variable with the correct sizing.
VII. DMLs
A. RDO interprets the RDO syntax. No object is created, so each
list of commands must be stored as an RMS file and then
re-interpreted when it is needed again. RDO does not handle
screen management, if-then-else logic, etc. Production
systems will revert to a 3GL, and the Rdb call interface.
> Of course production systems will use 3gl, I mean you don't write
> VMS in DCL do you ???
> Screen handling aso is hardly a DBMS job, but about 30 different
> programs interface to Rdb (Like RALLY our own 4gl)
B. NATURAL is a 4GL that is integrated with ADABAS, NATURAL
has the complete functionality of a programming language.
NATURAL programs are compiled and the source and objects
are stored in NATURAL - maintained libraries.
> And NATURAL of course interfaces to Rdb aswell (did they forget to
> say that ??).
VIII. DATA DICTIONARY
A. DEC utilizes CDD/Plus as the data dictionary. CDD is a
completely optional product. CDD does not allow documentation
of relations, fields, etc. It does not conform to the IRDS
standards.
> Does not allow documetation of fields, what do they mean by that ??
> Cross referecing (piece tracking we call it), discriptions,
> language independant METADATA aso.
> Metadata can even be shared between distributed processors connected
> via DECnet.
> Oh and Cdd/Plus is using Rdb as it's data manager, which means
> taht you have all capabilities of locking, maintenance, and...
>
B. PREDICT is Software AG's data dictionary. Complete documentation
facilities exist. Reporting, generating, cross referencing are
just a few of its capabilities. PREDICT conforms to the
ANSI IRDS standards for data dictionaries. Since PREDICT is
an ADABAS file it can be extended by the user.
> Does that mean that ADABAS ceases to wrok if the file-allocation is
> reached ??
> Surely it just allocates more space, without interrupting the users
> work.
|