Table Of ContentWhat is Informix database? Informix database
administrator's guide
How to understand Informix database
Informix database 101
John D Tintop
Copyright © 2017 by John D T Tintop
Content:
1. Theoretical basis.
1.1. The concept of a database server.
1.1.1 Main functions of the DBMS
Managing the memory buffers
Transaction management
Journalism
Database languages
1.1.2 Typical organization of modern DBMS
1.2 The concept of client-server architecture.
2. Theoretical Foundations of Informix database server OnLine v.7.X
Informix 2.1 database server.
2.1.1 Description Informix products
2.1.2 Typical configurations
2.2 The architecture of the database server Informix OnLine v.7.X
2.2.1. Dynamic scalable architecture
2.2.1.1 Streams
2.2.1.2 Virtual Processors
2.2.1.3 Planning streams
2.2.1.4 Separation flows between virtual processors.
2.2.1.5 Saving memory and other resources
2.2.2 The organization of shared memory
2.2.3 Organization of exchange operations with disks
2.2.3.1 Managing disk storage
2.2.3.2 asynchronous IO
2.2.3.3 Read-Ahead
2.2.4 Support for the fragmentation of the tables and indexes
2.2.5 Parallel query processing
2.2.5.1 What is the basis PDQ technology
2.2.5.2 Iterators
2.2.5.3 Application Examples concurrency
2.2.5.4 Balance between OLTP and DSS-applications
2.2.6 Optimizer query cost
2.2.7 Means of reliability
2.2.7.1. Mirroring disk areas
2.2.7.2 Duplication
2.2.7.3 Rapid recovery when the system is turned on
2.2.7.4 Backup and recovery
2.2.8 Dynamic administration
2.2.8.1 System Monitoring Interface
2.2.8.2 DB / Cockpit Utility
2.2.8.3 OnPerf Utility
2.2.8.4 Utility parallel loading
2.2.9.1 Client-Server Interaction
2.2.9.2 Data Location Transparency
2.2.9.3 Distributed databases and protocol the two-phase commit transactions
recovery procedure
optimization transactions
Resolution deadlock
2.2.10 Support National Language
2.2.11 Means C2 Security
2.3 Additional components of Informix to perform specific tasks.
2.3.1 Informix-Enterprise Gateway 7.1
2.3.2 Technology and components EDA / SQL
2.3.2.1 EDA API / SQL
2.3.2.2 EDA / Link
2.3.2.3 EDA / SQL Server
2.3.2.4 EDA / Data Drivers
2.3.3 Features Enterprise Gateway
2.3.3.1 Transparent access to read and write
2.3.3.2 Distributed compound
2.3.3.3 Configuring the Enterprise Gateway
2.3.3.4 Safety
2.3.4 Library interface Informix-OnLine DS server transaction manager: Informix-TP /
XA and Informix-TP / TOOLKIT
2.4 Conclusion
1. T .
HEORETICAL BASIS
1.1. T .
HE CONCEPT OF A DATABASE SERVER
The traditional capabilities of file systems are not enough to build even
simple information systems. When building an information system, it is
required to ensure: maintaining a logically consistent set of data; Ensuring
the language of data manipulation; Recovery of information after various
kinds of failures; Really parallel work of several users. To accomplish all
these tasks, a group of programs united into a single program complex is
singled out. This complex is called a database management system
(DBMS). Let us formulate these (and other) important functions separately.
1.1.1 M DBMS
AIN FUNCTIONS OF THE
Among the functions of the DBMS is the following:
Direct data management in external memory
This function includes providing the necessary external memory structures
both for storing the direct data included in the database, and for service
purposes, for example, to speed up access to data in some cases (usually
indexes are used for this). In some implementations of the DBMS, the
capabilities of existing file systems are actively used, in others the work is
done up to the level of external memory devices. But we emphasize that in
developed DBMS users in any case do not have to know whether the DBMS
uses a file system, and if it uses, then how are the files organized. In
particular, the DBMS supports its own system of naming database objects
(this is very important, since the names of database objects correspond to the
names of objects in the domain).
There are many different ways to organize external database memory. Like
all decisions made in the organization of databases, specific methods of
organizing external memory must be selected in close connection with all
other solutions.
M
ANAGING THE MEMORY BUFFERS
DBMSs usually work with a large database; At least this size usually
significantly exceeds the available amount of RAM. It is clear if, when
accessing any data item, an exchange with external memory is performed, the
entire system will work with the speed of the external memory device. The
only way to actually increase this speed is to buffer the data in RAM. And
even if the operating system produces system-wide buffering (as in the case
of the UNIX operating system), this is not enough for the purposes of the
DBMS, which has much more information about the usefulness of buffering
a particular part of the database. Therefore, in developed DBMS it supports
its own set of RAM buffers with its own discipline of buffer
replacement. When managing the main memory buffers, you must develop
and apply consistent algorithms of buffering, logging, and
synchronization. Note that there is a separate direction of the DBMS, which
are oriented to the permanent presence in the operative memory of the entire
database. This direction is based on the assumption that in the foreseeable
future the amount of computer RAM can be so large that it will not worry
about buffering. While these works are in the research stage.
T
RANSACTION MANAGEMENT
A transaction is a sequence of operations on a database, considered by the
DBMS as a whole. Either the transaction is successful, and the DBMS
commits (changes) the database changes made to it in the external memory,
or none of these changes is reflected in the state of the database. The
concept of a transaction is necessary to maintain the logical integrity of the
database. If we recall our example of a HR information system with files of
STAFF and DEPARTMENTS, the only way to not break the integrity of the
database when performing the operation of recruiting a new employee will be
to combine the elementary operations over the files of STAFF and
DEPARTMENTS into one transaction. Thus, maintaining the transaction
mechanism is a prerequisite for even single-user databases (if, of course, such
a system deserves the name of a DBMS). But the concept of transaction is
much more significant in multi-user databases. The property that each
transaction starts with an integral state of the database and leaves this state
complete after its completion makes it very convenient to use the concept of
transaction as units of user activity in relation to the database. With the
appropriate management of parallel transactions on the part of the DBMS,
each user can in principle feel himself to be the only user of the DBMS (in
fact, this is a somewhat idealized view, since users of multi-user databases
can sometimes sense the presence of their colleagues).
With the management of transactions in a multi-user DBMS, important
concepts of transaction serialization and the serial execution of a mixture of
transactions are associated.Under serialization of concurrently running
transactions, this is the order of planning their work, in which the overall
effect of a mixture of transactions is equivalent to the effect of some
sequential execution. A serial plan for executing a mixture of transactions is
a way of performing them together, which leads to the serialization of
transactions. It is clear that if it is possible to achieve a truly serial execution
of a mixture of transactions, then for each user who initiated the transaction,
the presence of other transactions will be invisible (except for some
slowdown for each user compared to single-user mode).
There are several basic algorithms for serializing transactions. In the
centralized DBMS, the most common algorithms based on the
synchronization capture of database objects.When using any serialization
algorithm, there are situations of conflicts between two or more transactions
to access database objects. In this case, to maintain serialization, you must
roll back (eliminate all changes made to the database) of one or more
transactions. This is one of the cases when a user of a multiuser DBMS can
really (and rather unpleasantly) feel the presence of other users in the
transaction system.
