Escolar Documentos
Profissional Documentos
Cultura Documentos
Table of Contents
INTRODUCTION ........................................................................................................................................ 1
Introduction
DB2® Universal Database (DB2 UDB) can help improve the performance of database
applications. Many solution developers have already chosen DB2 UDB as their primary
development database environment, and have ported and continue to enable
applications to it to take advantage of its unique features.
DB2 UDB is a true cross-platform DBMS, running on a wide variety of systems including
Windows NT and 95, Solaris, HP-UX, AIX®, SCO UnixWare and OS/2®. It scales from
single-processor workstations or servers, to symmetrical multiprocessor (SMP) servers,
and on up to massively parallel processing (MPP) computers.
A real database leader in several technologies, it provides integrated support for complex
data such as text documents; images; video and audio clips; integrated Web access
through native support for Java, JDBC, SQLJ and Net.Data; integrated system
management tools; and data replication service.
This paper highlights the differences between the Informix Dynamic Server 7.3 and DB2
Universal Database (UDB) V5.2. DB2 UDB is now at version 6.1 and an updated version
of this paper is being prepared and will be available at a later date.
• Product Overview
• Database Administration
Note: All the information contained in this document is based on publicly available
information and is subject to change. IBM® disclaims all warranties as to the accuracy,
completeness, or adequacy of such information. IBM shall have no liability for errors,
omissions or inadequacies in the information contained herein or for interpretations
thereof.
DB2 UDB is a database leader in several technologies, and offers true multi-platform
support and scalability. The same database is able to mix workloads on a single server.
The DB2 UDB design handles workloads from high-volume online transaction processing
(OLTP) to complex multi-user queries while maintaining excellent performance.
On December 1, 1998, the IBM Personal Systems Group and the IBM Software Group
published a 100GB TPC-D benchmark (Transaction Processing Performance Council
Benchmark D) using DB2 UDB 5.2.0 under Windows NT on an IBM Netfinity 7000 M10
server with four Pentium II Xeon 400 MHz processors. This benchmark achieved a multi-
user throughput result of 831.2 QthD@100GB, a price/performance result of
$130/QphD@100GB, and a power result of 3450 QppD@100GB. It has also since been
published by TPC.
In addition to affordability and performance, DB2 UDB offers the following advantages:
DB2 administration tools allow users to perform database administration tasks for DB2
UDB servers that are available locally or remotely. The Control Center (Figure 1) is a
graphical interface that can be used to perform server administrative tasks such as
configuring, backing up and recovering data, managing directories, scheduling jobs and
managing media, as well as accessing and manipulating databases. This tool can be
installed on OS/2, Windows NT, or Windows 95/98 workstations.
The Control Center provides the following additional facilities to manage DB2 UDB
servers:
Data Replication
DB2 UDB includes a complete data replication solution by supporting sources and targets
that include the DB2 family, IMS, VSAM, Oracle, Sybase, Microsoft, Lotus Notes, and
others to ensure timely, reliable, and consistent data across an enterprise. IBM offers the
following data replication tools:
• IBM Replication – the DataPropagator® Relational Version 1 (DPROPR V1) products
have been updated for Version 5 (V5) of the DB2 database.
DB2 UDB provides web access to enterprise data on DB2 databases through native
support for Java, Java Database Connectivity (JDBC), Embedded SQL for Java (SQLJ)
and Net.Data®.
JDBC can be used to create applications or applets that access data in DB2 databases.
These applets can be run inside HTML web pages on any system with a Java-enabled
browser, independent of the client’s platform. The processing of JDBC applets is shared
between the client and the server.
DB2 SQLJ support facilitates the creation, building and running of SQLJ programs
against DB2 UDB databases.
DB2 Net.Data enables application developers to create Internet applications that access
data from DB2 databases, are stored on a web server and are viewable from any web
browser. While viewing these documents, users can either select automated queries or
define new ones that retrieve the specified information directly from a DB2 UDB
database.
DB2 Universal Database Extenders allow storage and manipulation in the database of
nontraditional data such as images, video, voice, complex documents, spatial objects and
more. All these data types can be brought together in one SQL query and can then be
manipulated with powerful built-in functions.
Each extender defines a new type of data in DB2 UDB by using built-in support for user-
defined types and user-defined functions. Each extender also exploits DB2 Version 5
support for large objects of up to 2 gigabytes, and uses DB2 triggers to ensure referential
integrity of image data.
The DB2 Extenders exploit the DB2 client/server model. Supported platforms are AIX,
OS/2, Windows NT, HP-UX and Solaris Operating Environment.
DB2 provides a Software Developer's Kit (SDK) that contains a collection of tools
specially designed for database application developers. The DB2 SDK includes libraries,
header files, documented Application Programming Interfaces (APIs) and sample
programs to build database applications.
• Hardware and software discounts, equipment lease and loaner programs and
business discounts to reduce development costs
• On-site and remote access to fully equipped testing and porting facilities at full-
service IBM Solution Partnership Center (SPC) locations around the world
• Exclusive, focused development support
• Examples of how to interface with and exploit the newest technologies
• Technical information based on actual development experience in the form of
“Frequently Asked Questions” and “Hints And Tips”
• The IBM Developer Connection, which is loaded with development tools, software
and late-breaking news from IBM
• The Global Software Solutions Guide, an online catalog providing worldwide
exposure to new customers for partners' solutions
• In-depth technical seminars and hands-on workshops
• Partners In Development specialty areas, with specialized technical, business,
marketing and information services for areas of expertise
• A technical library, complete with the latest white papers, road maps and a calendar
of upcoming events
• The IBM Solution Developer Program worldwide web site,
http://www.developer.ibm.com/, which is a dynamic, 24-hour, 7-day-a-week service
that provides information about all services.
The DB2 product family scales through a variety of platforms: AS/400® systems, RISC
System/6000® hardware, IBM S390 systems, Intel systems and non-IBM machines from
Hewlett-Packard and Sun Microsystems. Figure 2 provides a pictorial representation of
the DB2 UDB connectivity.
DB2 UDB version 5.2 database software servers run on the following software
environments: AIX, HP-UX, OS/2, SCO UnixWare, SINIX, Linux, Sun Solaris, Windows
NT, Windows 98 and Windows 95.
Client access is provided for all these platforms, as well as for DOS, Apple MacOS, and
Silicon Graphics IRIX. In addition, web access is provided with popular browsers and
Java applications using DB2's native Java/JDBC support and Net.Data.
DB2 Universal Database Personal Edition allows for the creation and use of local
databases. It also allows access to remote relational databases when they are available.
This product is available for the OS/2, Windows NT, and Windows 95 operating systems.
The DB2 Universal Database Workgroup Edition server enables local clients, remote
clients and applications to create, update, control and manage relational databases using
Structured Query Language (SQL), ODBC, or CLI. It contains all the latest DB2® Client
Application Enablers, which enable client workstations to access the DB2 UDB server
and all supported DB2 Net.Data products.
The DB2 Enterprise Edition includes all functions provided in the DB2 Workgroup Edition,
plus DB2® Connect Enterprise Edition to allow support for host connectivity. This
provides multi-user access to DB2 databases residing on host systems such as
MVS/ESA, OS/390, AS/400, VM, and VSE. The DB2 Enterprise Edition supports
unlimited LAN database access.
DB2 Universal Database Extended Enterprise Edition (formerly known as DB2 Parallel
Edition) enables a database to be partitioned across multiple independent computers of a
common platform. SQL operations and utilities can operate in parallel on the individual
database partitions. Performance is enhanced by speeding up the execution time of a
single query or utility.
DB2 SDK is a collection of tools that enable database application developers to build
character-based, multimedia or object-oriented applications. It includes libraries, header
files, documented APIs and sample programs.
The DB2 SDK can be used to develop applications that use the following interfaces:
• DB2® Connect Personal Edition, which provides access from a single workstation to
DB2 databases residing on host systems such as MVS/ESA, OS/390, OS/400, VM
and VSE, as well as access to DB2 Universal Databases. This product is available
for the OS/2, Windows 3.1x, Windows NT, and Windows 95 operating systems. DB2
Connect Enterprise Edition provides similar capabilities in a multi-user environment
including UNIX systems, OS/2, and Windows NT.
• DB2® OLAP (online analytical processing) Server, which is designed for
multidimensional planning, analysis, and reporting applications.
• DB2 for Domino, which extends the capabilities of DB2 Universal Database to Lotus
Notes and Domino users.
• DB2 DataJoiner 2.1.2, which provides a single interface to heterogeneous
databases. It provides global query optimization, and supports most relational and
non-relational database systems.
Database Engines
DB2 Tools
Control Center – a GUI user-interface that is packaged with DB2 UDB and runs on a
workstation. It is used to control and manage the DB2 UDB server. Its components can
administer all aspects of the database server, run queries, commands, scripts, schedule
and execute utilities, journal database events such as backups and recovery, and monitor
performance. The SmartGuide feature of the Control Center guides the novice user by
providing information about parameters and other options used for creating database
objects or running utilities.
Command Line Processor (CLP) – a text-based tool that is installed and used on the
server. SQL statements and database commands may be executed from within the CLP
environment or from the command line of the operating system.
Informix
Developer’s Edition – single-user version for workstations that is used as a
development platform
Personal Edition – a subset of Dynamic Server for use in single-user mode
Workgroup Server- a subset of Informix Dynamic Server that is used for smaller
applications running on low-end processors
Informix Dynamic Server (ODS) – full product, multi-user version for Intel and UNIX
platforms. Does not support user-defined types, user-defined functions or other object
relational features without the Universal Data Option. ODS alone will support two types of
large object data types, Byte and Text.
Advanced Decision Support Option – extends the capabilities of Dynamic Server’s
indexing and optimizer for decision support applications.
Extended Parallel Option (XPS – 8.2) – extends the capabilities of Dynamic Server for
inter-parallelism.
Universal Data Option (9.1) – extends the capabilities of Dynamic Server for object
relational support.
OnWeb – Web based administration tool that is similar to Control Center but not as
powerful.
Client Connectivity
DB2 UDB
Client Application Enabler (CAE) – software installed on client machines to enable
connection to DB2 UDB database servers.
Client Configuration Assistant (CCA) – a GUI tool, used from the workstation, that is
designed to automate the configuration of clients for connectivity to remote DB2 UDB
database servers.
Informix
INFORMIX-Net (I-Net) - software required on a client machine in order to talk to an
Informix server.
Informix-Connect – provides runtime libraries for INFORMIX-ESQL for C and COBOL
and INFORMIX-CLI.
Informix
Informix-SQL (ISQL) – is a separate product that is used for interactive SQL access, as
a forms builder, report writer (Ace) and menu builder.
Informix Client Software Developer’s Kits – provides single packaging for several
application programming interfaces. It includes C, C++, Java and ESQL.
Informix-4GL – is a rapid development language that compiles into C.
ESQL – is an SQL API that permits the embedding of both static and dynamic SQL
statements directly into a 3GL program.. Informix has ESQL product releases for C and
COBOL. Informix embedded static SQL means that all the components of an SQL
statement are available at compile time. Informix embedded dynamic SQL does not have
all the SQL statement components at compile time, but rather, receives all or part of the
statement at runtime.
NewEra – is a graphical development environment.
Informix CLI – is a Call Level Interface that enables application developers to
dynamically access Informix database servers, eliminating the need of an SQL
preprocessor and the recompilation of source code. It is based on Microsoft’s Open
Database Connectivity (ODBC) architecture.
SQL Extenders
DB2 UDB
DB2 Extenders – contain sets of predefined data types and functions. Each extender
helps to manage a particular kind of data, such as text, images, audio or video. For
example, the text extender can construct a linguistic index that supports fast content-
based retrieval of large text documents. The text, image, audio, and video extenders are
included with the Developer’s Editions of DB2 UDB.
Informix
DataBlades – are object extensions that expand the capabilities of Informix Dynamic
Server to manage complex data types such as video, audio and image, as well as to
develop and use functions to manipulate these data types. These are included with
Informix’s Universal Data Option.
Gateways
DB2 UDB
DB2 Connect (formerly DDCS) – enables users to connect to any database server that
supports the Distributed Relational Database Architecture protocol. All the functionality of
DB2 Connect is included in the Enterprise Edition of DB2 UDB. In addition, DB2 Connect
is available in a Personal Edition and Enterprise Edition. Personal Edition provides a
single workstation remote access to a DRDA server, while Enterprise Edition supports
many workstations on a LAN sending requests to a DRDA server.
Informix
Informix-Gateway with DRDA – provides access to non-Informix databases such as
Oracle, Sybase, and DB2.
Web Support
DB2 UDB
Net.data – is a tool kit that enables development of applications that are accessible from
the Web. Net.data is called from a Web server to and expands a macro that can handle
requests made by a Web browser. The macro can contain SQL statements that retrieve
data from a database and then display the content on a Web page.
Web Sphere Studio – is a Web development environment
Informix
Internet Foundation 2000 – is similar to DB2’s Net.data
Universal Web Connect – provides connectivity between Web servers and Informix
Dynamic Server. Enables Web developers to create, manage and deploy Web
applications (pages) and content to Internet users.
Data Director for Web – is a suite of graphical user interface tools designed to enable a
developer to build and manage Informix-based Web sites and applications.
Data Warehousing
DB2 UDB
Intelligent Miner – is a set of applications that can search large volumes of data for
patterns or trends.
OLAP Server – is a joint product of IBM and Arbor that provides operations for online
analytical processing of large volumes of historical data.
Visual Warehouse – provides for the periodic extraction of data from an operational
database for archiving and analysis into a data warehouse. It includes a catalog facility
for storing metadata about the extracted data.
Informix
MetaCube – is a suite of software products designed to analyze, query, aggregate,
report, administer and maintain a data warehouse.
Database Administration
Architecture
DB2 UDB
An installation of DB2 UDB is called an Instance, and each Instance may have one or
more databases. Each Instance has one Database Manager Configuration file. In
addition, each database has its own Database Configuration file, catalog tables, logs,
reserved bufferpool area and table spaces. Table spaces can be regular, long (for LOB
data) and temporary. Tuning parameters, resource management, and logging may differ
for each database in the Instance and may be controlled at the database level.
Configuration parameters at the Instance and database level can be set using the Control
Center.
Temporary Table Spaces are used to store temporary tables that are created and
managed by the database management system. By default, one temporary table space,
TEMPSPACE1 is created but additional temporary table spaces can be created at
different page sizes, (i.e., 4K, 8K, 32K). Temporary objects are allocated to temporary
table spaces in round robin fashion.
Informix
An installation of Informix is also called an Instance. When an Informix ODS Instance is
initially created, only one dbspace, the ROOT dbspace (rootdbs), exists. The
SYSMASTER catalog tables and logs are created in the ROOT dbspace. For best
performance, the logs must be moved out of the ROOT dbspace into new dbspaces
created for the physical and logical logs. Within each Instance, one or more databases
may be created. The log mode for an individual database is specified at creation time,
and each database in the Instance may have a different log mode.
Each database that is created has its own set of database system tables. Catalog tables
at the database level contain information about tables, columns, indexes, views, users,
triggers, stored procedures and authorities. This is in addition to the SYSMASTER tables,
the global set of catalog tables at the Instance level. SYSMASTER contains information
about databases, dbspaces, chunks, extents, locks, logs and sessions.
The Informix database configuration file, ONCONFIG, is global to the entire Instance and
all tuning parameters affect all databases in the Instance. In addition, bufferpool space is
global to all databases and can only be tuned at the Instance level. Database logs are
also defined at the Instance level and are used by all databases in the Instance.
Configuration parameters in the ONCONFIG file can be set using a menu-based utility on
the server called ON-MONITOR. Only the informix user or ROOT can initialize an
Instance. If a database is created in LOG MODE ANSI, then tables may have the same
name as long as the owner is different. If the database is created using any other log
mode or NO LOG, then each table name must be unique within the database.
Optimizers
Both DB2 UDB and Informix have cost-based optimizers which determine costs based on
statistics stored in catalog tables.
DB2 UDB
DB2 UDB allows for seven levels of optimization. The QUERYOPT parameter is used to
specify the optimization level for static SQL and is done with the PREP or BIND
command. The optimization level is set for dynamic SQL using the SET command as:
SET CURRENT QUERY OPTIMZATION = 3. If not specified, the default setting of the
database configuration parameter DFT_QUERYOPT is used.
DB2 UDB has a query rewrite feature and the order of tables in a join are not important
as the optimizer will rewrite the order for the optimal access path. Catalog statistics are
updated using the RUNSTATS utility. If an application uses static SQL, the access paths
that are generated at bind time by using the statistics in the catalogs are stored with the
SQL executable code on the database. If an application uses dynamic SQL, the access
path is generated at runtime by using the statistics recorded in the catalog tables.
Dynamic caching of SQL executable may allow for quick reuse of the optimized code.
Informix
For Informix, the optimization level is set using SET OPTIMZATION HIGH or LOW. You
can specify a default setting for the optimizer by running the OPTCOMPIND command.
OPTCOMPIND is used to influence the optimizer to select a different join method. Three
settings can be used with this command. Since there is minimal query rewrite, selecting
the best table order is important.
Optimization or access path selection for static SQL is determined each time an
application is invoked and is not stored before runtime. Static or dynamic SQL may be
reused if found in the SQL cache area. Catalog statistics are updated using the UPDATE
STATISTICS utility.
Parallelism
DB2 UDB and Informix both support two types of parallelism: parallelism within a
database instance and parallelism between database instances. The former most
commonly runs on a symmetric multiprocessor (SMP) machine in which multiple
processors share common memory and disks. The latter usually involves a collection of
processors each of which has its own main memory and disks that are not shared with
other processors (“shared-nothing”).
Intra-Parallelism
With intra-parallelism on an SMP machine, multiple processes can serve a given user
simultaneously. The optimizer generates access plans containing multiple threads that
can be active simultaneously during processing of an SQL statement. The number of
threads generated is called the “degree”. This type of parallelism is used by DB2 UDB EE
and Informix ODS. In addition, both products facilitate parallel I/O by “fragmenting” or
striping (round robin) data across multiple storage devices. Unless the storage device is
RAID, striping of data in Informix is a task performed by the DBA while in DB2 UDB it is
handled automatically by the database management system.
DB2 UDB
For a DB2 UDB database to exploit this type of parallelism, the database manager
configuration parameter INTRA_PARALLEL must be set to YES. When performing a
PREP or a BIND, the DEGREE parameter can be set to a specific integer indicating the
number of threads to be generated, or it may be set to ANY.
If set to ANY, the optimizer determines the number of threads to generate. Each thread
may be processed by a separate processor. The degree for dynamic SQL can be
specified by setting the CURRENT DEGREE register. The default value for DEGREE is
controlled by a database configuration parameter named DFT_DEGREE.
Informix
Informix uses PDQ (Parallel Data Query) to control parallelism or the number of threads
generated. To make the most efficient use of PDQ parallelism with Informix, values for
the number of scan threads, memory size, number of queries and the query’s priority
must be set. The four parameters in the ONCONFIG file that must be set are
DS_MAX_QUERY, DS_MAX_SCANS, DS_TOTAL_MEMORY and
MAX_PDQPRIORITY. Several Environment variables must also be set to enhance PDQ
processing.
Inter-Parallelism
With inter-parallelism on an MPP (massively parallel processor) or a cluster of SMP
machines connected by a LAN, each database instance runs on a separate machine and
has its own memory and disks. A single table may have rows that are owned by many
instances of the database. This type of parallelism is used by DB2 UDB EEE and
Informix XPS. In DB2 UDB, each instance is called a Partition; in XPS, each instance is
called a Co-server.
DB2 UDB/EEE
DB2 UDB/EEE supports an SP AIX availability feature called HACMP. This function
allows automatic takeover of a failing node’s DASD by another node. The takeover node
could be a hot standby or another working node. In either case, the DASD is “wired” to
the partner nodes. When a failure occurs, DB2 will be started on the standby node and
access to the DASD of the failed node will be automated. If a query is in progress when a
node fails, and the query needs data on the failed node, backout will occur automatically
and the query can be restarted, accessing the failed node’s DASD through the takeover
node. This improves availability.
When loading data, DB2 UDB/EEE automatically spreads data evenly across the
processors in a parallel complex, thus providing the ability for each processor to process
a subset of data in parallel. As the data warehouse grows, additional SP nodes must be
added to the configuration to allow the complex to support additional data. When this
happens, data must be redistributed across the new configuration to spread the data
evenly on the processors. DB2 UDB/EEE has a Redistribute Utility that allows the data to
be automatically distributed when adding or removing processors. This feature enhances
availability of the warehouse.
Informix/XPS
Informix does not support HACMP or automated takeover of a failing node. Informix also
does not support a Redistribute Utility. The user must drop the database, redefine it, and
then reload the entire database. This could take considerable time, thus affecting the
availability of the warehouse.
Bufferpool Management
DB2 UDB
Each database has a default bufferpool area named IBMDEFBP. Additional bufferpools
can be created, and table spaces can be created or altered to use specific bufferpools.
By assigning table spaces to a particular bufferpool, data pages from tables that are read
often can be made to reside in memory. By separating bufferpools for highly accessed
read-only tables from bufferpools for tables with high update activity, it is possible to
insure that data pages will reside in memory longer and thus, enhance performance.
Informix
Buffers make up the largest part of the Resident portion of Informix’s Shared Memory.
The size for Resident memory and the size of the buffers within the Resident memory is
specified in the ONCONFIG file. Buffer space is global to the entire Instance and
dbspaces or tables are not assigned to specific buffer areas; however, tables or parts of
tables and indexes can be made to remain resident in memory.
Storage Management
DB2 UDB
The physical space within a database is organized into a collection of table spaces. Each
table space consists of a collection of containers, each of which is either a directory in the
machine’s file system, a physical file or a raw device. When creating a table space, an
extent size in the number of 4K pages is specified. If an extent size is not specified, then
a default extent, which is specified in the database configuration file, is used. When a
table is created, it is assigned to a table space. An extent contains data for only one table
and all extents are the same size. After the initial extent fills, all additional extents are
created on each additional container in the table space in round robin fashion.
Distributing data in this way, enables parallel input and output and optimizes
performance. Indexes for a table may be contained in the same table space or in a
separate table space as long as the table space type is DMS. Large objects can be
stored in special table spaces named LONG.
Two types of table spaces are available: SMS and DMS. SMS table spaces are managed
by the operating system and DMS are managed by DB2 UDB. SMS table spaces are
better suited for smaller tables where performance is not a prime consideration and
where they are also easier to maintain. The space in a SMS table space is defined as a
directory and is not pre-allocated. Data can be added as long as there is enough physical
space available. More than one directory can be assigned to the table space. With the
SMS type table space, data, indexes and large objects are all stored in the same table
space.
DMS table spaces are better suited for large data where performance is a key factor.
Containers are added to DMS table spaces in the form of a file or physical disk device.
The space is pre-allocated and fixed in size. Additional containers may be added to
support growth. DMS table spaces support the separation of data, indexes and large
objects.
DB2 UDB provides two types of GUI panels to assist the DBA in table space creation, the
Create Table space Smartguide and the Create Table space Notebook.
Informix
The dbspace is the equivalent of DB2 UDB’s table space. Unlike, a DB2 UDB table
space, which is created using DDL, dbspaces are created by executing the ONSPACES
command. Each dbspace is composed of physical storage called chunks. Chunks are
either raw devices or files and correspond to the container of DB2 UDB. Chunks may be
added to a dbspace when more space is required. Indexes may be stored in separate
dbspaces from data. (Informix has a concept of a “Table space,” but in Informix, “Table
space” has a different meaning than DB2 UDB’s table space). Blobspaces are used for
storing the large binary objects of data types Byte and Text.
Data is not distributed across chunks automatically by Informix. In order to distribute data
across physical storage, a fragmented table with several dbspaces must be created and
the type of “fragmentation” must be specified. Fragmentation is specified in the Create
Table DDL by assigning each fragment into a different dbspace. Data for fragments are
distributed either by round robin or by an expression.
Extent size is also specified by the Create Table DDL. A size is given in 4K pages for the
Initial and Next extent and these sizes may be different. If the table is not fragmented,
then the Initial and all Next extents will be assigned to the same dbspace and may be
contained on the same Chunk. Having many noncontiguous extents unevenly distributed
across physical devices may impact performance.
DB2 UDB
A client is configured to connect to a database. Several directories are used to allow
clients to access local and remote databases. The System Database Directory identified
the name, alias and physical location of each database. All clients and servers must have
a system directory. A local directory exists at the location where each database is created
and contains the name of a database and the subdirectory pathname in which the
database files are stored.
For a client to connect to a remote database, each client machine must have a Node
directory which contains an entry for all nodes to which a database client can connect.
Each entry contains the node’s name, communication information and Instance
information. These directories can be configured by using the Client Configuration
Assistant or the Control Center.
Informix
A client is configured to connect to an Instance also referred to as a database server. The
Sqlhosts file resides on a database server machine and lists all the Instances that have
been created for the local machine and any other server machine on the network. Also
specified for each Instance is the type of connection to be used and a service name that
represents a port and the protocol for that connection.
On the client side, Setnet32 is used to set parameters for the client connection. Using
Setnet32, the client can establish connectivity to the all the databases found on an
Instance by specifying the database server name (Instance name), the machine name,
the service name and the protocol used for each Instance to which the client wants
connectivity. Setnet32 is also used to set environmental variables on the client machine.
DB2 UDB
SQL can be embedded within 3GL languages such as C, C++, COBOL, FORTRAN and
Java. Embedded SQL can be static or dynamic. Static SQL means that the entire SQL
statement is known at compile time. Dynamic SQL means that the complete SQL
statement may not be known until runtime at which time the SQL statement can be
compiled using an EXEC PREPARE statement.
In either case, the host language program with embedded SQL statements is
preprocessed using the PREP statement. The embedded SQL statements are replaced
with host language procedure calls, and the SQL statements are placed into a file with a
file extension of .bnd. The BIND statement is used to compile the .bnd file into a package
of executable SQL, and together with an access path strategy, the Package is stored and
cataloged on the DB2 UDB database. Static SQL is simply executed each time it is
invoked and dynamic SQL is prepped and executed at runtime unless the prepared code
is already in the cache, in which case it is simply executed. Stored procedures are
prepared and compiled for execution just like embedded SQL programs.
Informix
ESQL is the Informix product that allows SQL development with C and COBOL. The
source language with embedded SQL is preprocessed and the SQL statements are
converted into procedures and data structures of the source language. The source
language is then compiled using an ESQL compiler. The executable code is linked with
SQL APIs procedures. The SQL APIs are a library of procedures that are part of the
ESQL product. Only the source language statements are compiled.
The SQL API’s are compiled at runtime when they are invoked for execution. Although
Informix embedded SQL is always compiled and executed like DB2 UDB dynamic SQL,
Informix refers to SQL statements that are completely known at preprocessor time as
“Static” SQL.
Stored procedures are embedded SQL in a proprietary source language known as SPL.
With Informix stored procedures, SQL is parsed, validated, optimized and stored in an
executable format on the database. In this way, Informix stored procedures are similar to
a static SQL package in DB2 UDB.
Concurrency
Isolation Levels
DB2 UDB
DB2 UDB has four isolation levels: Repeatable Read, Cursor Stability, Uncommitted
Read (dirty read) and Read Stability. Read Stability is the only isolation level that does
not exist in Informix. Read Stability keeps a lock only on those rows accessed that
actually qualify for the query of an application program. Since read locks are not held on
unqualifying rows, the next time the same query is executed, unqualifying rows may have
been changed to qualifying rows and as a result, new rows may appear in the result set.
This isolation level permits a little more concurrency to Repeatable Read where the
application keeps a lock on all rows that are accessed by an application program.
The isolation level is specified at pre-compile time as a parameter to the PREP command
or when an application is bound to the database using the BIND command. The default
isolation level is Cursor Stability.
Informix
The four types of Isolation levels that affect shared locks in Informix are: Repeatable
Read, Cursor Stability, Committed Read and Dirty Read, which is also known as
Uncommitted Read. All Isolation levels except for Committed Read behave like the
Isolations levels of DB2 UDB.
The Committed Read Isolation level does not exist in DB2 UDB and is the default
Isolation level used by a logged database except for mode ANSI. (If the database is in
mode ANSI, then the default isolation level is Repeatable Read.) Committed Read will
not return a row to an application if it is locked for update, insert or deletion. When using
Committed Read, the instance checks to see if a shared (read) lock can be placed on the
row, but does not actually put a read lock on the row. The advantage of using this type of
Isolation level is speed. Committed Read does not prevent a row that is being read by an
application from being changed by another application. It only prevents reading a row that
is being changed.
Isolation levels for an application are set in Informix by issuing the SET ISOLATION TO
xxxx command. This command is either entered interactively or embedded within the
application program.
Locking
DB2 UDB
DB2 UDB provides row and table lock levels. All locks are at the row level by default
unless the LOCK TABLE IN xxxx MODE statement is used to enable locking at the table
level. Locks are held in shared or exclusive modes. When the number of locks issued
exceeds the capacity specified by maxlocks (calculated by the DBA) and locklist in the
database configuration file, lock escalation occurs. When this happens many row locks
are freed and converted into one table lock. A deadlock detector periodically looks for
deadlock situations and rolls back one of the transactions involved. The deadlock
detection interval is set in the database configuration file. A timeout parameter for waiting
on a lock to release is also set in the database configuration file.
Informix
Informix supports row, page, table and database locking. Page locking is the default.
Lock levels are defined in the Create Table DDL by using the LOCK MODE xxxx clause.
To lock an entire table, the LOCK TABLE IN xxxx MODE (xxxx = shared or exclusive)
can be used in application code. It is also possible to lock an entire database in exclusive
mode.
The types of locks in Informix are shared, exclusive and promoteable. A promoteable lock
is one which is first a shared lock with the intent of becoming an exclusive lock (i.e.,
SELECT FOR UPDATE). How long a process waits to get an exclusive on a data item
that is currently being held by another exclusive lock before it times out is determined by
the SET LOCK MODE TO xxxx command in the application code. The lock mode can be
set to a time in seconds, to an indefinite wait or to no wait at all.
An ONCONFIG configuration parameter called LOCKS determines the maximum number
of locks that can be held by a process at one time. Informix ODS has a limit of 8,000,000
locks per user process. If the number of locks is exceeded, all data affected is rolled back
and there is no lock escalation.
Security
DB2 UDB
DB2 UDB supports authorities at the instance and database levels. Userids can be
authenticated at the server level, the client level, or by DCS. The authentication type is
specified in the database manager configuration file. If the userid is authenticated at the
server level, then the userid must be a valid operating system userid.
Three levels of authority exist at the Instance level that span the entire Instance. These
levels of authority are defined in terms of groups and are recorded in the Database
Manager Configuration file. Groups are created and maintained at the operating system
level by the system administrator. The three levels of authority are SYSADM, SYSCTRL,
and SYSMAINT.
When a DB2 UDB Instance is created, the group to which the creator of the Instance
belongs is given SYSADM authority. This SYSADM group is recorded in the Database
Manager Configuration file. SYSADM is the highest level of authority for an DB2 UDB
installation and is used to create other levels of authorities in an Instance. SYSCTRL is
an Instance level of authority that has the right to control resources in the Instance.
SYSCTRL can create and destroy databases and table spaces. SYSMAINT is a level of
authority that can maintain the Instance. SYSMAINT can start and stop the Instance,
backup and restore databases and perform monitoring tasks.
At the Database level, certain authorities (DBADM, BINDADD, CONNECT and
CREATAB) must be granted for each database within an Instance by the SYSADM. The
highest level of database authority is DBADM. The DBADM authority can be granted to a
userid or a group, and can access and modify all objects within a database, as well as
grant database authorities to other userids.
Another Database authority, the BINDADD authority, provides the right to create new
packages in the database for their own userid or for other users. The BINDADD authority
is needed when installing SQL applications on the database. The user with BINDADD
authority or the owner of a package can grant the BIND authority on a package to other
users.
A third Database authority is CONNECT. This authority conveys the right to connect to
the database. A user with CONNECT authority can only manipulate tables that they own
or tables to which they have been granted the specific privileges of SELECT, INSERT,
UPDATE or DELETE.
A fourth Database authority, the CREATAB authority, provides the right to create tables
in a database. The userid that creates objects in the database is the owner and inherently
has the right to fully manipulate those objects. If the owner of an object would like another
user to have privileges on those objects, the owner must GRANT those privileges to the
other user's userid. All users who can connect to a database can automatically SELECT
from the catalog tables.
Other database authorities and privileges can control various operations within a
database. A discussion of these authorities and privileges, however, is beyond the scope
of this paper.
Informix
After a client has connectivity to a database server, the userid that is used to connect
must exist at the operating system level on the server. After that, users can be granted
authority at the database level.
The three Informix levels of authority for a database are CONNECT, RESOURCE and
DBA. Users with CONNECT database authority can perform select, insert, update and
delete statements if they have been granted these privileges by the owner of the tables.
Users with RESOURCE authority can create, alter, and drop their own tables and place
indexes on these tables and grant privileges to others users for their tables. The creator
or owner of the database is automatically given DBA privileges. Users with DBA authority
can grant and revoke CONNECT, RESOURCE and DBA authorities to other users;
create, drop and alter other users’ tables and views; and drop, start, stop and recover the
database. Informix has the keyword PUBLIC that represents all users who can access
the database server. Informix supports the use of roles (similar in functionality to groups
in DB2 UDB) and the use of an administrator group.
In addition to Database authorities, Informix uses the informix userid role. A user and
group each with the name informix must exist and be used to install the server. On UNIX,
the informix user’s home directory is the same directory where the server is installed. The
informix userid has super-user authority at the instance level and can be used to grant
database authorities to other userids.
Access Paths
Clustering/Clustered Index
In DB2 UDB, an index can be defined as a clustering index. In this case, rows in a table
will be ordered according to that index, and that order will be maintained as long as there
is free space on a page to allow for insertions of future rows. Similar to DB2 UDB, an
index may be created in Informix with the CLUSTER keyword; however, since no free
space is allocated to data pages, the table will not maintain rows in the same order as the
index as new rows are inserted.
PCTFREE/FILLFACTOR
In DB2 UDB, PCTFREE is the amount of free space on an index or data page that is left
free for future insertions of indexes or data rows. PCTFREE is a parameter of the
CREATE INDEX and CREATE TABLE statement. The percent of free space left on each
index page in Informix is controlled by the FILLFACTOR parameter which is set in the
ONCONFIG file. This value applies to all indexes in the Instance. If the FILLFACTOR is
set to 90, then 10 percent of the page is left free for future inserts to the index. This helps
to maintain the ordering of index insertions. The FILLFACTOR is similar in concept to
DB2 UDB’s PCTFREE for index pages. In Informix, however, FILLFACTOR cannot be
used for data pages.
DB2 UDB
Logging
Logging occurs at the database level in DB2 UDB and can be enabled differently for each
database in the Instance. The Control Center is used to select a database for backup and
recovery operations. The database log, which can be used in several ways, is an
important part of the backup and recovery processes. The system log records all
committed changes to the database, and it is used to bring the database to a consistent
point after a power failure. It can also be used to restore a database to its current state
after media failure or application failure.
The system log is maintained as a set of files in a directory whose path name is specified
by the database configuration parameter named LOGPATH. The number of log files is
controlled by the LOGPRIMARY parameter and the size of the log files is controlled by
the LOGFILSIZ parameter. In addition to the primary logs, DB2 UDB also uses a number
(between 0 and 126) of secondary logs as specified in the LOGSECOND parameter.
Secondary logs do not occupy permanent file space, but are allocated one at a time as
needed and de-allocated as they are not needed. Secondary logs are used when the
primary logs fill up and more log space is required.
When a database is created, the default logging mode is circular logging. As circular
logging is performed, the log files are reused and overwritten when more space is
needed. This type of logging is used to protect against power failure and is used by
applications to rollback uncommitted changes. When this type of logging is enabled, the
LOGRETAIN and USEREXIT parameters in the database configuration file are set to NO.
Only off-line, full database backups can be performed with this type of logging. A
database can only be recovered to the last full backup.
Rollforward is another log mode that can be used. With this type of logging, logs are not
reused, but are maintained online until they are archived. The online and archived logs
are used, along with the last full backup, to recover a database back to the current state
just before a media or application failure. The LOGRETAIN and USEREXIT parameters
must be set to YES for Rollforward to be enabled. If the USEREXIT parameter is set to
YES, a user-written program controls moving the online logs to archived off-line logs.
With Rollforward logging, the database backup can be online or off-line, and can be a full
database backup or a selected table space backup. Recovery of a database can be
performed to the last current committed transaction before the failure or to some specific
point in time. Also, with this type of logging, recovery can be performed on a table space
basis.
In DB2, UDB logging must be either circular or Rollforward. The option of NO LOG,
available with Informix, does not exist in DB2 UDB.
Long Transactions
When primary logs are full, secondary log files are allocated one at a time as needed. If
more space is needed than what the secondary log parameter allows for, then the
database will automatically rollback the work. When the secondary logs are no longer
needed, the space that they occupy is freed.
Backups
Backups can be performed at the database level or table space level in DB2 UDB and be
written to disk, a tape device, or to a location managed by a storage management system
such as ADSTAR. Backups can be either off-line or online depending on the log mode
used. To perform a backup, a user must have SYSADM, SYSCTRL or SYSMAINT
authority. The Control Center can be used to perform a backup on demand or to
schedule a backup for a specific time.
Recovery
The RESTORE command is used to recover a database or can be used to create a copy
of a database. In order to restore a database, a user must have the SYSADM, SYSCTRL
or SYSMAINT authority. If Rollforward logging is used, recovering from an online backup
copy will leave the database in a roll-forward pending state. The database cannot be
used until a ROLLFORWARD command is applied. This is also true if recovery is done
on a table space basis. If the restore comes from an off-line, whole-database backup,
then the phrase WITHOUT ROLLING FORWARD can be added to the RESTORE
command. This will avoid the roll-forward pending state, and the database will be usable
immediately. Each backup used to restore a database is identified by its directory and a
timestamp. A single table space may be restored from a whole-database backup.
Roll-Forward Recovery
The ROLLFORWARD command is used to apply log changes to the database or table
space recovered from a backup. The ROLLFORWARD may be done to the end of the
logs or to a specific point in time in the logs by specifying a date and time. A directory for
archived logs is specified along with the online logs specified by the LOGPATH
parameter.
DB2 UDB has a graphical tool called the Journal that can be used to manage recovery of
a database. The Journal is part of the Control Center and records all events for a
database. The Journal’s recovery panel displays a history of the backups and restores for
a database. To restore a database from particular recovery, simply select the backup
from the Recovery panel. A SmartGuide can be used to guide the user through the
selection of options that can be used with a RESTORE.
Load Utility
Data is not logged when loading data using the Load utility.
LOB Data
Data with the BLOB or CLOB data types can be stored in a table with the NOT LOGGED
option.
Mirroring
Mirroring for DB2 UDB is managed at the hardware level.
Informix
Logging
Informix uses two types of logging, one set of logical logs and one set of physical logs, for
the entire Instance. The physical logs are used to capture the before image of data prior
to any changes. Physical logs are used primarily for fast forward recovery, and by
Informix backup procedures. The logical logs are where all data changes made by
transactions and whether or not they have been committed are tracked.
The number of logs to configure, their sizes and other parameters affecting logging are
set in the ONCONFIG configuration file. Each database in an Instance can be created to
use a different log mode. Informix supports NO LOG, ANSI LOG MODE and LOG MODE
of BUFFERED or UNBUFFERED.
Long Transaction
It is important to set the LTXHWM (percent of the logical log that can be filled by a long
transaction before it will be rolled back.) parameter in the ONCONFIG file correctly. If a
long transaction runs out of log space the transaction will be rolled back. Rolling back a
transaction, however, generates additional log records and requires adequate log space
in order to be successful. If the logical log space is not sufficient to support the rollback of
the long transaction, the Instance will crash and will not come up without the assistance
of the Informix Support Center.
Ontape
The Ontape utility has a command line interface. Archives can only be done at the entire
Instance level Ontape supports the incremental archive levels of 0, 1 and 2. Ontape is
also used to backup the logical logs. Log files can be backup up in continuous mode or
on-demand. Continuous mode requires sufficient disk space or a dedicated tape device.
On demand mode requires a monitor of the logs. Databases that are logging will suspend
processing of transactions if the logs fill up. Only the informix user can execute Ontape.
The Ontape configuration parameters are set in the ONCONFIG configuration file for the
Instance.
The Ontape utility is also used to perform a restore. The restore can be one of the entire
Instance or an individual dbspace. If the restore is for an entire database, it must be done
off-line. If the restore is for one or more dbspaces, then the restore can be done online.
OnBar
Configuring OnBar involves setting parameters in the ONCONFIG configuration file of the
Instance and configuring a storage management system if one is used. In addition, a
native storage manager called ISM is available. OnBar can also be invoked from the
command line on the server or from the Informix Enterprise Command Center. OnBar
supports the backup and restore of the entire Instance or individual dbspaces. Backups
and restores can be done either online or off-line. OnBar also supports the backup of the
log files as continuous or on demand. Point-in-time recovery can only be done at the
entire Instance level.
Mirroring
The mirroring mechanism provides instantaneous fail-over protection of the physical
media in case of a disk crash. If Informix receives a disk failure, it automatically moves
the disk off-line and converts the mirror from being a read-only device to the active,
updateable device. When the primary disk is placed, the mirroring mechanism
resynchronizes the primary and mirror copies. The use of mirroring is controlled by the
DBA and specified in the ONSPACES command. To use mirroring, it must first be
enabled in the ONCONFIG file.
Blobspaces
LOB data that is stored in BLOBSPACES is not logged.
DB2 UDB
Import
The import utility can be used at the table level. It is used to insert rows into a table from
an external file using the SQL INSERT statement. Data that is imported is logged. During
the import, data in the table remains accessible. All constraints and triggers remain in
effect during the import and are activated in the usual way as rows are inserted. Data
may be imported to a client location.
Export
This utility can be used at the table level and extracts data from the database and saves
it in a file, using one of several file formats. The data to be extracted is specified by an
SQL query. Exports may be performed from a client location.
Load
Load inserts data into an existing table a page at a time. Load is intended for the initial
load, for replacing existing data or for appending new data to existing data. The data
being loaded must be local to the server. Indexes are constructed in a separate step after
the bulk loading of data. Statistics may be updated as part of the Load process or
afterwards. During Load, the table spaces that contain the table being loaded are not
accessible to other applications. During the loading of a table, constraints and triggers
attached to that table are temporarily suspended. After the load, the constraints are
reactivated. and a check on the new data is performed to verify that constraints have not
been violated. Data that is loaded is not logged. Instead of logging loaded data, a copy
of the loaded data must be performed after the Load. If the load is used with the non-
recoverable option, a copy of the loaded data may be omitted. Loading data may take
advantage of parallel processing if multiple storage devices are used. The SET
CONSTRAINTS statement is used to verify that referential integrity and Check
constraints have not been violated. Violations of a unique key are written to an
exceptions table.
db2move
db2move is a tool used to help move large numbers of tables between DB2 databases
located on workstations. Db2move queries the system catalog tables for a particular
database and compiles a list of all user tables. The tool then exports these tables in IXF
format. This utility is similar to Dbimport and Dbexport in Informix.
Runstats
The Control Center may be used to run this utility by selecting a table and then invoking
Run Statistics. Statistics may be updated for columns and indexes and are stored in the
catalog tables. In order to run statistics, the user must have the SYSADM, SYSCTRL,
SYSMAINT or DBADM authority or the CONTROL privilege on the table. Statistics in
some catalog tables may also be updated manually. After updating statistics, a rebind
should be performed so that the new information can be used to update access
strategies for application programs.
DB2look
This utility is a tool used to collect statistical information from catalog tables and save it in
a file. The tool is also used to capture DDL for tables and indexes, and it can be used to
clone databases and statistics for testing purposes.
Reorg
Reorg is a data and index management utility that helps maintain rows in physical pages
of a table in the clustering sequence of an index. Reorg prevents fragmentation of the
data and indexes as a result of deletes, and reestablishes the free space on a data page
(PCTFREE) for newly inserted rows that are ordered by a clustering index. The Control
Center may be used to select a table or index for reorganization.
Reorgchk
This command helps to identify tables that need to be reorganized.
Informix
Dbimport
The import utility can be used only at the database level and is used to create or move a
complete database environment. Only a user with the DBA authority or the informix user
can perform an import. This utility is not available in Informix XPS.
Dbexport
The export utility operates only at the database level and exports every table and index in
the database and its schema. An exclusive lock is placed on the database during export.
Only a user with the DBA authority or the informix user can perform an export. This utility
is not available in Informix XPS.
Dbload
This command line utility is for loading data from text files of the delimited or fixed column
type into one or more existing tables. This utility performs SQL insert statements.
Onload
This utility is used to create a database or table in a specified, pre-existing dbspace. Only
data that is unloaded using the Onunload utility can be loaded using Onload.
Onunload
This unloads one or more tables and indexes, a page at a time, into a file in binary
format.
Update Statistics
The Update Statistics utility operates on a table basis and is the equivalent of DB2 UDB’s
Runstats utility. This utility inserts statistical information about database data in the
catalog tables. The information is used by the optimizer to select the best access path to
the data.
Dbschema
This utility is used to dump the entire schema of a database or of one object into a file.
Objects include tables, indexes, views and privileges.
Replication
DB2 UDB
Replication uses the changes stored in the database log from the source table and
applies them to a target table in any database in the Enterprise. Specifications for how to
apply changed data are known as replication subscriptions. Two programs, Capture and
Apply, perform the ongoing replication. Capture reads the database log and copies the
changes to a staging area for replication at a later time. The Apply program reads the
changes and applies them to the target table. The target table can be read-only or can be
updateable, and the changes can be captured and applied back to the original source
table.
Replication can be enabled using the Control Center. A table can be defined as a
Replication source. Once this is done, a Subscription can be defined that allows all
updates to the replication source to be automatically replicated into a target table.
Mirroring in DB2 UDB is not performed at the database level. Instead, it is performed
outside of the database at the hardware level.
Informix
Informix supports High-Availability Data Replication (HADR) which is built into the product
and Informix Enterprise Replication which is a separate option. HADR is enabled by
sending the logical logs from the primary server to the secondary server where all the
changes are applied. The primary server is updateable and the secondary server is read-
only. If the primary server fails, users can be redirected to the secondary server.
Informix‘s Enterprise Replication option also supports peer-to-peer replication with the
update anywhere feature.
Mirroring is enabled by defining a secondary chunk and linking it to the primary chunk.
Every write to the primary chunk is also written to the secondary or “mirror” chunk.
LOB Datatypes
Informix uses the TEXT and BYTE datatypes for large character and byte data
respectively. UDB has comparable datatypes, CLOB and BLOB. Unlike Informix, UDB
requires that the maximum length of the CLOB or BLOB be specified.
MONEY Datatype
UDB does not have a money datatype. A user-defined type named MONEY with a
datatype of DECIMAL with a scale of 2 should be created and used in the DDL to create
tables.
INTERVAL Datatype
UDB allows date/time arithmetic, which can be used within a DB2 application to
manipulate DATE, TIME and TIMESTAMP fields to generate intervals of time. The
following provides an example of this procedure:
SELECT col1 FROM table 1 WHERE CURRENT DATE < (DATE1 + 10 YEARS);
DATE/TIME Datatypes
The character string formats for representing these date/time datatypes differ from the
Informix format. Internally, UDB stores these values in a packed decimal format. Informix
stores these values as integers. UDB applications use Character datatypes to declare
host variables in the EXEC SQL DECLARE BEGIN section to hold date/time values.
Informix applications use Integer datatypes or use DATE/TIME typedefs to declare host
variables for date/time values in the EXEC SQL DECLARE BEGIN section.
TYPEDEFS
Informix allows the use of typedefs when declaring host variables in ‘C’. A typedef allows
the application developer to rename a datatype such as INTEGER with a more
descriptive name such as DATE. DATE can then be used as a datatype throughout the
program, including the host variable declare section, in place of INTEGER. UDB does not
allow the use of typedefs in the EXEC SQL DECLARE BEGIN section. All SQL host
variables must be declared using the datatypes of the host language.
Outer Joins
The syntax for Informix outer joins differs from that of UDB’s syntax for outer joins.
Matches Predicate
In UDB, the LIKE predicate should be used in place of MATCHES.
Temporary Tables
Informix allows a SELECT statement to select into a temporary table. Data inserted into a
temporary table is not logged or cataloged. UDB allows the use of a not logged initially
clause on CREATE TABLE. Summary tables may also be used.
Select UNIQUE
Informix uses SELECT UNIQUE and SELECT DISTINCT. UDB uses only SELECT
DISTINCT.
Page Locking
UDB does not have a lock type at the page level. A row or table should be used instead.
Isolation Levels
Isolation levels cannot be set in application programs. Isolation levels are specified at
bind time.
CR Isolation Level
UDB does not have a CR isolation level. UR should be used instead.
Stored Procedures
In UDB, stored procedures are written in a 3 GL such as C or COBOL. Stored procedures
must be converted from Informix’s SPL to one of UDB’s host languages.
Dynamic SQL
All SQL in Informix is dynamic, but Informix calls SQL statements that are enclosed as
strings “dynamic SQL.” This is only important to note if an automated tool is used to
convert the application programs, in which case the way in which the tool handles this
type of SQL should be determined.
Fragmentation
UDB does not support fragmented or partitioned tablespaces or tables. A determination
should be made as to whether or not this database storage feature impacts the design of
the application.
CHAR(n) CHAR(n)
VARCHAR(n) VARCHAR(n)
TEXT CLOB(2GB)
INTEGER , INT INTEGER, INT
SMALLINT SMALLINT
DECIMAL(p,s) DEC(p,s) , DECIMAL(p,s)
FLOAT FLOAT
DOUBLE PRECISION DOUBLE PRECISION
MONEY NUMERIC(19,4)
SMALLMONEY NUMERIC(10,4)
BYTE BLOB(2GB)
DATETIME TIMESTAMP
DATE (MM/DD/YYYY) DATE (MM/DD/YYYY)
SERIAL not supported (see below)
INTERVAL not supported (see below)
The "value(MAX(key),0)" statement will return the first non-null value. Thus, if the table is
empty, it will return 0 and increment it by one.
Outer Joins
The syntax for Informix outer joins differs from that of UDB’s syntax for outer joins. For
example, the Informix outer join statement:
SELECT c.cust_num, c.lname, d. call_dtime
FROM customer c, OUTER cust_calls d
WHERE c. cust_num = d.cust_num
SELECT UNIQUE
Informix uses SELECT UNIQUE and SELECT DISTINCT. UDB uses SELECT DISTINCT
only.
Built-In Function
Both database products provide a variety of built-in functions. Some of these functions
are identical in Informix and DB2 UDB, some function the same, but have different
names. Informix has one built-in function that does not have match in DB2; however, it
can usually be converted to a DB2 user-defined function.
Compound SQL
To reduce network traffic and improve efficiency, DB2 provides a way for a program to
wrap two or more SQL statements into a bundle and send it to the server in a single
request. This bundle is called a compound SQL statement. Only static SQL statements
may be compound. DB2 distinguishes atomic and not atomic compound SQL.
For atomic statements, all individual statements inside the compound statement are
rolled back if any individual statement fails. If not atomic, the changes made by
successful statements within compound SQL statement remain effective even if some
individual statements are not successful. The following example illustrates use of
Compound SQL:
EXEC SQL
BEGIN COMPOUND ATOMIC STATIC
INSERT INTO org (dept, deptname, location)
VALUES (:dn, :dname,:dloc);
UPDATE employee
SET dept =:dn
WHERE empnum > :empnum;
END COMPOUND;
CLI/ODBC
The Call Level Interface (CLI) is based on Microsoft’s Open Database Connectivity
(ODBC) interface, supporting ODBC 3.0, Level 1, plus certain additional features. At
present, CLI is supported only for the C and C++ languages.
An advantage of CLI is that application programs that use it do not need to be
precompiled. An application written using CLI can be ported to other database systems
that support ODBC.
Triggers
DB2 has two types of triggers: BEFORE and AFTER. Informix triggers may be converted
to DB2 triggers with very few changes in syntax. The differences between Informix and
DB2 triggers are as follows:
• DB2 does not allow calls to stored procedures from the trigger, while Informix
does.
• Order of firing for DB2 triggers is based on creation time, while in Informix order
of firing can be coded.
• DB2 triggers can use the CASE expression, while Informix uses WHEN().
If the trigger body contains more than one SQL statement DB2 allows COMPOUND SQL
to be used. The SQL statements are enclosed between BEGIN ATOMIC and END, and
separated by semicolons.
Error Handling
DB2 and Informix use similar syntax for automatic exception testing:
EXEC SQL WHENEVER SQLERROR GOTO label;
Unlike Informix, however, DB2 cannot use call within WHENEVER statement.
To get diagnostics for an error, DB2 Universal Database provides a special run-time API
function to return an error message based on SQLCODE:
rc=sqlaintp(msg_buffer, 1024, 80, sqlca.sqlcode);
Note that sqlaintp requires that a large error message text buffer be defined and
available prior to the function invocation; e.g., char msg_buffer[1024].
Stored Procedures
Informix uses the SQL extension procedural language SPL as its stored procedure
language. The executable procedure and information about the procedure are stored on
the Informix database in the SYSPROCEDURES, SYSPROCBODY AND
SYSPROCPLAN tables as opposed to DB2 stored procedures which are stored on the
database server in a library. DB2 stored procedures can be written using most popular
programming languages: C, COBOL, Java, FORTRAN, REXX.
For DB2 stored procedures written in C, all SQL statements must be preceded by EXEC
SQL for the precompiler to distinguish them from native C statements. All Informix SPL
statements must be converted to the C statements. The following table maps SPL
statements to C statements:
The parameters of the SQL CALL statement are treated as both input and output
parameters and are converted into an SQLDA structure with the number of variables
equal to the number of parameters on the CALL statement.
To avoid sending unnecessary data between the client and the server, the client
application should provide an indicator variable with each parameter and set the indicator
to –1 if the parameter is not used to pass data to a stored procedure (output-only). The
stored procedure should set the indicator variable to –128 for any input-only parameter
that is not used to return data from a stored procedure.
The client program allocates the SQLDA and SQLCA data structures and assigns values
to the input variables that are passed by the SQLDA. SQLVAR structure is part of
SQLDA and is provided for each parameter. The SQLVAR structures are used to
describe the data types, lengths and values for each parameter required in the order
specified in the parameter list of the CALL statement.
The SQLDA and SQLVAR data structures are described below:
struct sqlda
(
char sqldaid(8); /* contains ‘SQLDA ‘ */
long sqldabc; /* SQLDA size in bytes 44*SQLN */
short sqln; /* number of sqlvar elements=2 */
short sqld; /* # of host variables =2 */
struct sqlvar sqlvar[1] /* first sqlvar element */
);
struct sqlvar
(
short sqltype; /* typecode/datatype code */
short sqllen; /* length of data value */
char *sqldata; /* pointer to data value */
short *sqlind; /* pointer to Null indicator */
struct sqlname sqlname; /* variable name */
);
A stored procedure takes four parameters. Two parameters are used as pointers to the
SQLDA and SQLCA data structures. The other two parameters are unused, but still exist
to support DARI calling conventions from earlier DB2 releases. In C, the declaration of
the stored procedure would look like the following:
SQL_API_RC SQL_API_FN procname(
void *reserved1, /* not used */
void *reserved2, /* not used */
struct sqlda * inout_sqlda, /* input and output
*/
);
The stored procedure returns values to the client program by copying them into the
buffers pointed to by the SQLVARs and by copying a set of return codes into the SQLCA
structure pointed to by the out_sqlca.
Finally, the stored procedure ends by returning one of two possible integer codes which
are defined in sql.h: SQLZ_HOLD_PROC, indicating that the procedure should be
retained in memory for further invocations, or SQLZ_DISCONNECT_PROC, indicating
that the procedure should be removed from memory. These values are not returned to
the client program.
In a CALL statement, the arguments passed to the stored procedure must be host
variables. The host variables are defined in the EXEC SQL BEGIN DECLARE SECTION
of the client program. The following is an example of the CALL statement in an
embedded static SQL program:
EXEC SQL CALL “stprocs!server1”(:x :xind, :y :yind);
The procedure named in the above example of the CALL statement is stprocs!server1.
The name of the file where the procedure is found is stprocs and the name of the entry
point for the procedure is server1. A host variable may be used for the name of the
procedure.
The same example CALL statement passes two variables (:x, :y), each with a null
indicator variable (:xind, :yind). An SQLDA structure will be dynamically allocated that will
have two SQLVAR structures, SQLVAR[0] and SQLVAR[1]. The SQLVAR structures are
used to describe the datatypes, lengths and values for each parameter required in the
order they are specified in the parameter list of the CALL statement.
The SQLDA and SQLVAR data structures are described below:
struct sqlda
(
char sqldaid(8); /* contains ‘SQLDA ‘ */
long sqldabc; /* SQLDA size in bytes=16+44*SQLN */
short sqln; /* number of sqlvar elements=2 */
short sqld; /* # of host variables =2 */
struct sqlvar sqlvar[1] /* first sqlvar element */
);
struct sqlvar
(
short sqltype; /* typecode/datatype code */
short sqllen; /* length of data value */
char *sqldata; /* pointer to data value */
short *sqlind; /* pointer to Null indicator */
struct sqlname sqlname; /* variable name */
If a parameter is used only for input and not output, a null indicator variable must be
assigned to the parameter. The stored procedure program assigns a NULL value to that
parameter indicating that no data is returned.
If a parameter is used only for output and no input data is passed, the client should
assign the null indicator variable for that variable to a –1 to indicate that no data is
passed.
The C declarations for the SQLDA structures can be found in sqllib/include/sqlda.h on the
UDB AIX server.
If a full path name for the procedure is not provided in the CALL statement, UDB first
searches the default directory sqllib/function. If not found, UDB then searches the
PROCEDURES catalog table for a stored procedure that was registered with the name
used in the CALL statement.
No special installation procedures are required for the use of the client program. Simply
precompile, compile and bind it as for any other UDB application program.
);
ROLLBACK only if the client issued a type 1 connection (a non-distributed unit of work).
Since the stored procedure runs in the same transaction as the client program, any
commit or rollback also affects any changes performed by the client program since the
last commit.
A stored procedure cannot issue printf statements since it runs in background mode.
Finally, the stored procedure ends by returning one of two possible integer codes which
are defined in sql.h: SQLZ_HOLD_PROC, indicating that the procedure should be
retained in memory for further invocations, or SQLZ_DISCONNECT_PROC, indicating
that the procedure should be removed from memory. These values are not returned to
the client program.
Return(SQLZ_DISCONNECT_PROC);
On Windows NT…
Suppose a source file named stprocs.c contains two stored procedures named
server1 and server2. If using the Microsoft Visual C++ compiler, a module
definition file named stprocs.def should be created with the following contents:
LIBRARY stprocs
EXPORTS server1
Server2
On AIX…
The module definition file is called an export file. If using the IBM XLC compiler,
an export file named stprocs.exp should be created with the following contents:
#! Stprocs export file
server1
server2
3. For each database will execute the stored procedure:
a. Connect to the database and precompile, compile and link the file with the
stored procedure. Use the command files provided with UDB in the
sqllib/samples/c directories.
Bldmsstp.bat can be used with the Microsoft Visual C++ compiler on Windows NT
Bldxlcsrv and be used with the IBM XLC compiler on AIX.
b. Modify required these files with the include and link libraries. These files
require four parameters: the name of the stored procedure, the name of the
Informix stored procedures are written in an SQL procedural language known as SPL.
The executable procedure and information about the procedure are stored on the
Informix database in the SYSPROCEDURES, SYSPROCBODY AND SYSPROCPLAN
tables as opposed to UDB stored procedures, which are stored on the database server in
a library.
Unlike Informix’s embedded SQL, which is parsed, optimized and executed dynamically
at run-time, Informix’s stored procedures are precompiled, and an optimized execution
plan is stored in the database for future use. When an Informix stored procedure is called
for the first time, the plan is simply cached and executed. Since Informix’s stored
procedures are precompiled, they are similar to the way UDB’s static embedded SQL is
implemented.
An Informix stored procedure is created using the CREATE PROCEDURE command.
This command can be run from DBACCESS, Informix’s interactive interface. Unlike UDB,
where the CREATE PROCEDURE statement is used primarily to document the
procedure and define the parameter list, the Informix CREATE PROCEDURE statement
contains the entire body of the procedure code, including the SPL, and is used to install
the procedure on the database. The Informix CREATE PROCEDURE command parses,
optimizes, builds and stores the execution plan in the database. The procedure’s source
code is also stored in the Informix database’s catalog tables. UDB stored procedures are
compiled and linked in the same way that other application programs are built.
Any user that has the DBA or RESOURCE privilege may create a stored procedure and
may grant other users the privilege to execute the procedure. When creating UDB stored
procedures, only unfenced procedures require the SYSADM, DBADM or a special create
unfenced procedure privilege.
The Informix stored procedure can be executed from an ESQL, Informix 4GL, or
Powerbuilder programs or from DBACCESS using the EXECUTE PROCEDURE
statement. In UDB, the stored procedure is executed from a client program by using the
CALL statement.
Variables can be passed into the stored procedure at run-time by the calling program
using the EXECUTE PROCEDURE statement with a parameter list. The EXECUTE
PROCEDURE parameter list may contains data values, as well as host variables. In
contrast, the UDB parameter list must contain only host variables. When passing
parameters, the Informix CREATE PROCEDURE statement must define a matching
parameter list with datatypes for each of the input parameters passed into the procedure.
Output variables are returned to the calling program by using a CREATE PROCEDURE
command with a RETURNING clause that defines the datatype for each parameter to be
returned. A RETURN statement with a parameter list in the body of the procedure is used
to return the values. With UDB stored procedures, both input and output parameters are
passed by using the SQLDA data structure. The following is an example of an Informix
CREATE PROCEDURE command:
CREATE PROCEDURE read_many (lastname char(15))
RETURNING char(15), char(20);
DEFINE a char(15);
DEFINE b char(20);
……..
RETURN a, b;
Variables in Informix’s stored procedures are declared by using the SPL DEFINE
statement. Variables in UDB’s stored procedures are defined in the EXEC SQL
DECLARE BEGIN section. Host variables used in SQL statements in the procedure are
not required to have semicolons, and SQL statements in the procedure are not preceded
by EXEC SQL. UDB stored procedures require host variables with semicolons in SQL
and EXEC SQL precedes each SQL statement.
Informix stored procedures can call other Informix stored procedures, and can be called
from a SELECT list and a trigger. UDB stored procedures cannot be called from a trigger
or SELECT list, and a UDB stored procedure cannot be called from within another UDB
stored procedure. When converting a nested Informix stored procedures to UDB stored
procedures, the nested Informix procedure can be converted to a UDB ‘C’ application
with embedded SQL. The only drawback to this method is that the nested ‘C’ function is
not truly a UDB stored procedure and, therefore, cannot be directly invoked as a stored
procedure from a client program.
Informix procedures can also return multiple sets of values when using a cursor. Only
UDB stored procedures that use CLI calls to the procedure can return multiple result sets.
select lname, fname into v_lname, v_fname from customer where customer_num
=c_num;
return v_lname, v_fname;
end procedure
*/
FILE * fp;
fp = fopen("proc2.out", "w+");
fprintf (fp, " Server SP: Begin log file (optional) \n");
errorExitL:
fprintf (fp, " Server SP: End log file \n");
fclose (fp);
memcpy((char *)out_sqlca, (char *)&sqlca, sizeof(struct sqlca));
#include <sqlenv.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
EXEC SQL INCLUDE SQLCA;
c_num = 125;
v_lname_ind = -1;
v_fname_ind = -1;
/* -- good practise to initialize ind var ... and */
/* -- set ind var for output only parms to -1 */
printf ("Client: <- Return from Server Stored Procedure ... \n");
printf ("Client: lname = %s \n", v_lname);
printf ("Client: fname = %s \n", v_fname);
errorExitL:
printf ("Client: *** Error ... SQLCODE = %d \n", SQLCODE);
EXEC SQL ROLLBACK WORK;
EXEC SQL CONNECT RESET;
return (-1);
}
Trademarks
The following terms are trademarks or registered trademarks of the IBM Corporation in
the United States and/or other countries:
AIX IMS
AIXwindows MVS/ESA
AS/400 MVS/XA
C Set++ OS/400
C/370 OS/390
DATABASE 2 OS/2
DataJoiner RISC System/6000
DataPropagator SQL/DS
DataRefresher SQL/400
DB2 S/370
DB2 Connect System/370
DB2 Universal Database System/390
DB2 OLAP Server VisualAge
Distributed Relational Database VM/ESA
Architecture VSE/ESA
DRDA VTAM
IBM WIN-OS/2
The following terms are trademarks or registered trademarks of the companies listed:
Java and all Java-based trademarks and logos are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, Windows 95 and the Windows 98 are trademarks or
registered trademarks of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark in the United States, other countries, or both and is
licensed exclusively through X/Open Company Limited.
Other trademarks and trade names mentioned herein are the property of their respective
owners.