Technical Reference Guide for Informix Database Driverbaansupport.com/docs/erpln/U8781F US.pdf ·...

Infor Enterprise Server

Technical Reference Guide for Informix Database Driver

Copyright © 2011 Infor All rights reserved. The word and design marks set forth herein are trademarks and/or registered trademarks of Infor and/or related affiliates and subsidiaries. All rights reserved. All other trademarks listed herein are the property of their respective owners. Important Notices The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor. By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Infor and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Infor pursuant to a separate agreement ("Purpose"). In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above. Although Infor has taken due care to ensure that the material included in this publication is accurate and complete, Infor cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Infor does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause. Trademark Acknowledgements All other company, product, trade or service names referenced may be registered trademarks or trademarks of their respective owners. Publication Information Release: 8.7 Publication date: September 22, 2011 Document code: U8781F US

Infor Enterprise Server Technical Reference Guide for Informix Database Driver | 3

Contents

About this guide ................................................................................................................................... 7

Contacting Infor................................................................................................................................ 8

Chapter 1 Infor ES Database Driver Overview .............................................................................. 9 The Infor ES architecture .......................................................................................................... 9

Display tier ......................................................................................................................... 11 Application tier ................................................................................................................... 11 Database tier ..................................................................................................................... 11

Data flow in the Infor ES architecture ...................................................................................... 12 Infor ES hardware configurations ............................................................................................ 13

Chapter 2 Infor ES Database Organization ................................................................................. 17 Infor ES data dictionary ........................................................................................................... 17 Table naming convention ........................................................................................................ 18 Column naming convention ..................................................................................................... 18 Index naming convention ........................................................................................................ 19 Data type mapping .................................................................................................................. 19

Chapter 3 Database Driver Internal Processing ......................................................................... 23 Data integrity............................................................................................................................ 23

Referential integrity ..................................................................................................... 23 Distributed databases ................................................................................................. 23 Data buffering .............................................................................................................. 24 Logging ........................................................................................................................ 24

Database driver SQL processing ............................................................................................ 24 Informix SQL processing ............................................................................................. 24 Infor ES Informix database driver SQL processing .................................................... 25

Setting driver behavior............................................................................................................. 26 Driver resources .......................................................................................................... 26 Environment variables ................................................................................................ 27 Server environment variables ..................................................................................... 27

Contents

4 | Infor Enterprise Server Technical Reference Guide for Informix Database Driver

Client environment variables....................................................................................... 28 Storage parameter file ................................................................................................ 28

Chapter 4 Database Security ........................................................................................................ 29 Database driver security features............................................................................................ 29

Groups ......................................................................................................................... 29 Object security ............................................................................................................ 30 Authentication ............................................................................................................. 31

Informix security features ........................................................................................................ 31 DBA module ............................................................................................................................. 33

Chapter 5 Database Driver Profiling and Statistics ................................................................... 35 Profiling .................................................................................................................................... 35 Gathering statistics .................................................................................................................. 36 Troubleshooting ....................................................................................................................... 37

Logging database driver trace information ................................................................. 38 Logging errors ............................................................................................................. 38

Chapter 6 Database Driver Configuration and Tuning .............................................................. 41 Concatenated expressions ......................................................................................... 41 The nested technique ................................................................................................. 42 The iterative technique ................................................................................................ 43 The filter technique...................................................................................................... 43 The keystart technique ................................................................................................ 43 Selecting the right technique....................................................................................... 44

Prepared cache ....................................................................................................................... 44 Cursor management ................................................................................................................ 45 Informix directives .................................................................................................................... 46 Optimistic and pessimistic reference checks .......................................................................... 46 Informix multiplexing ................................................................................................................ 46 Fillfactor and indexes ............................................................................................................... 47 Update Statistics ...................................................................................................................... 48

Chapter 7 Informix Configuration and Tuning ............................................................................ 49 Disk organization ..................................................................................................................... 49

Disk storage units .............................................................................................................. 49

Appendix A Driver Resources and Environment Variables ...................................................... 51 Summary of Informix driver resources and environment variables ........................................ 51 Detailed description of Informix driver resources and environment variables ........................ 54

Contents


Generic driver resources ................................................................................................... 54 Informix driver specific resources ..................................................................................... 65

Informix environment variables used with Infor ES ................................................................. 73

Appendix B Parameter and Storage Files ................................................................................... 75 Parameter file formats ............................................................................................................. 75

Storage file format ............................................................................................................. 75 Storage parameter file format ........................................................................................... 75 Driver parameter file format .............................................................................................. 76

Parameter file field descriptions .............................................................................................. 76 Storage parameter file performance tips ................................................................................. 79 Conversion from previous porting sets .................................................................................... 80

Appendix C The Informix Maintain Program inf_maint6.2 ......................................................... 81 Using inf_maint6.2 on UNIX .................................................................................................... 81 Using inf_maint.exe on Windows ............................................................................................ 82 Options for both UNIX and Windows ...................................................................................... 83 Differences between inf_maint6.2 on UNIX and on Windows ................................................ 84

Appendix D Format of Files used by the Informix Driver .......................................................... 87 The inf_users file ..................................................................................................................... 87 The inf_groups file ................................................................................................................... 88 The tabledef6.2 file .................................................................................................................. 88 The update statistics files ........................................................................................................ 89

Appendix E Informix Client/Server Connections........................................................................ 91 Shared memory connections ................................................................................................... 91 Network connections ............................................................................................................... 91

Appendix F Miscellaneous ............................................................................................................ 93 Informix Limitations .................................................................................................................. 93 Performance tips and guidelines ............................................................................................. 94

Appendix G Database Connections in Combo Mode ................................................................. 97 To configure database connections in combo mode .............................................................. 97

UNIX platforms .................................................................................................................. 97 Windows platforms ............................................................................................................ 98


About this guide

This document supplies technical reference information about the database driver for Informix which is part of Infor Enterprise Server. Infor Enterprise Server is the tools and porting set layer used for Infor ERP LN 6.1, Infor ERP Baan 5.0c, or Infor ERP Baan IV.

The database driver forms the interface between the Infor Enterprise Server application server layer and Informix. This document is intended for those who wish to configure or customize the database driver for Informix. The database driver for Informix can run on either Windows or UNIX. An elementary knowledge of Informix and either Windows or UNIX is assumed. An understanding of database technology is also assumed.

The procedures for installing the Informix and Infor ERP LN software are described in the installation documents.

For simplification, the term Infor ES will be used to refer to Infor Enterprise Server and ERP LN for versions that are enabled to be used with Infor Enterprise Server.

This document supplies technical reference information about the Infor ERP database driver for Informix. The database driver forms the interface between the Infor ERP application and Informix. This document is intended for those who want to configure or customize the Infor ERP database driver for Informix. The database driver for Informix can run on either Windows or UNIX. An elementary knowledge of Informix and either Windows or UNIX is assumed. In addition understanding the contents, it is easier if you are familiar with the database technology.

This document covers the database driver for Infor ERP Baan IV, Infor ERP 5.0c and Infor ERP LN6.1.

The procedures for installing Informix and Infor ERP software are described in separate documents (take appropriate document according to the used Infor ERP version):

The word ‘Infor Enterprise Server’ comprises the tools and Porting Set, but this document only handles things related to the Porting Set, whereof the Informix database driver is a part of. Affected Porting Set versions are 8.7b and higher versions.

For simplification, the term Infor ERP will be used to refer to ERP Baan IV, ERP5.0c and ERP LN 6.1 of the Infor ERP application and Informix will be used to refer to a supported Informix version. If things are (only) applicable to a certain Infor ERP version, then it is mentioned. The term database driver will refer to the Informix database driver. For supported platforms and Informix versions, check the technical notes of the Infor Enterprise Server Porting Set.

When Infor ERP Baan IV is used, then a minimum version of Porting Set 8.7b is required. This document only applies to the 8.x Porting Set.

About this guide


This document only applies to Level 2 mode of the database driver. The Level 1 mode of the database driver is no longer supported. For more information regarding Level 1 for Infor ERP Baan IV with 6.1c.x Porting Set, consult earlier revisions of this document.

Contacting Infor If you have questions about Infor products, go to Infor365 Online Support at http://www.infor365.com.

If we update this document after the product release, we will post the new version on Infor365. We recommend that you check this Web site periodically for updated documentation.

If you have comments about Infor documentation, contact [email protected].

http://www.infor365.com/

mailto:[email protected]


Chapter 1 Infor ES Database Driver Overview 1

The database driver plays an important role in Infor’s commitment to an open systems client/server architecture. Because the Infor ES architecture includes both the Infor ES software and a third party relational database management system (RDBMS), the driver is needed to provide a seamless interface between the Infor ES software and the different RDBMS products. The database driver allows the majority of the Infor ES processing to be independent of the RDBMS. This chapter provides an overview of the database driver and how it fits into the Infor ES architecture.

The following topics are covered in this chapter:

• The Infor ES architecture • Data flow through the Infor ES architecture • Infor ES hardware configurations

The Infor ES architecture Infor ES supports a three-tier architecture consisting of a display tier, an application tier, and a database tier. The display tier provides presentation services for user interaction. The application tier consists of the Infor ES application virtual machine, the application objects and the Infor ES database driver. The database tier consists of a third party RDBMS product that acts as the database server. Figure 1 depicts the Infor ES architecture.

The emphasis of this document is the Infor ES database driver. The database driver is the interface between the Infor ES based applications and the RDBMS server. The database driver translates database requests from the Infor ES application virtual machine to RDBMS specific SQL requests that it sends to the database server. After the database server retrieves the requested information, the database driver then passes the data back to the Infor ES application virtual machine.

To put the functions of the database driver into perspective, each of the three tiers of the total Infor ES architecture is described briefly below.

Infor ES Database Driver Overview


ApplicationVirtual Machine

(bshell)

Display Tier

Application Tier

Database Tier

Database Driver

Display Driver

Application Objects

Database Server(RDBMS)

Figure 1 Infor ES three-tier architecture



Display tier The display tier consists of the display driver which includes the Infor ES user interface for Microsoft Windows (Worktop) and/or for Internet browsers (Webtop). The display driver facilitates the communication between the user and the application tier. Data input from the user through Worktop or Webtop is relayed to the Infor ES application virtual machine; data returned from the Infor ES application virtual machine is displayed to the user in graphical form by the display driver.

Application tier The application tier includes the application objects and the Infor ES application virtual machine as well as the database driver. Together, the application objects and the application virtual machine provide much of the functionality of ERP LN whereas the database driver provides connectivity to the database server for storing and retrieving application data.

The application objects include the compiled ERP LN applications and the data dictionary. The ERP LN applications provide the functionality needed to implement the ERP LN Enterprise Resource Planning (ERP) system. These applications are written in Baan 3GL or Baan 4GL, programming languages supported by the Infor ES Tools package and are compiled into an intermediate code which is interpreted at runtime by the VM.

The data dictionary defines the data models used by the applications. The data dictionary includes information about the domains, schemas, and referential integrity rules used by ERP LN.

The Infor ES application virtual machine schedules and runs the application objects, sends and receives information to and from the display server, and initiates an instance of the database driver as necessary for communication with the database server. A running database driver can support multiple connections to a single RDBMS instance. If an ERP LN installation stores data tables in multiple RDBMS products or instances, the application virtual machine must start one instance of the database driver for each RDBMS product or RDBMS instance with which it must communicate.

The Infor ES application virtual machine has traditionally been called the bshell. Throughout the remainder of this document, it is referred to as the Infor ES application virtual machine or the application virtual machine.

The Infor ES database driver is also typically a part of the application tier. The database driver provides a common interface between the Infor ES application virtual machine and the database server. Communication between the application virtual machine and the database driver is the same, no matter which RDBMS product is used as the database server. There is one database driver for each of the RDBMS products that Infor ES supports.

Database tier The database tier typically consists of a 3rd party database server product Communication between the database driver and the database server is tailored to the RDBMS being used. The database



driver communicates with the RDBMS through structured query language (SQL) statements and the native application programming interface (API) of the RDBMS.

The database server consists of one of four third party RDBMS products: Oracle, Informix, IBM DB2, or Microsoft SQL Server. All ERP LN application data is stored in a relational database managed by an RDBMS. It is possible to have multiple RDBMS products in one ERP LN installation, with some data residing in one database server and some data residing in another, however, this is not recommended.

Data flow in the Infor ES architecture Note that the database driver provides an interface between the Infor ES application virtual machine and the specific RDBMS server being used. The flow of data through the system is described below.

When a user performs an operation at a GUI workstation, the display server interprets the input and sends the information to the Infor ES application virtual machine. Based on the information it receives, the application virtual machine causes the appropriate application object to be executed.

When a running application object requires information that is stored in the database, the application virtual machine sends the request to the database driver. Data requests from the client applications are RDBMS independent and are made using BaanSQL, an RDBMS independent SQL language.

When the application virtual machine executes a database query from an application object, it first determines whether or not there is a running database driver available to process the query.

If there is no database driver running, or if the running database driver instances are communicating with a database server other than the one storing the needed data, the application virtual machine starts a new instance of the database driver. The application virtual machine parses the BaanSQL database query it receives from the application object and sends an internal representation of the query to the database driver. The internal representation of the query that the database driver receives is still RDBMS independent.

The database driver translates the database query into an appropriate database-specific query using SQL statements compatible with the RDBMS being used. Each database driver takes advantage of the design of the particular RDBMS that it supports so that the resulting SQL statements are valid for the RDBMS and provide the best possible performance. The RDBMS specific SQL statements are then submitted to the RDBMS server, which processes the data request.

When the RDBMS has processed the query, it returns the data to the database driver. Any error conditions are caught and handled by the database driver. The database driver then returns the data and status information to the application virtual machine, where it provides the information to the application that requested it. The application virtual machine may also send a message to the display server, which displays an appropriate message on the user’s workstation.



Infor ES hardware configurations Several hardware configurations are supported for an ERP LN implementation. These configurations include standalone mode and many variations of client/server mode. Available hardware, data storage requirements, and performance expectations determine the most appropriate hardware configuration.

Standalone mode refers to a configuration where all components of the Infor ES architecture run on a single machine. In standalone mode, an end user can work from the host machine or from a thin client machine, such as an X-Terminal running BI. The standalone mode configuration is illustrated in Figure 2.


(bshell)

Database Driver

Display Driver

Application Objects


Figure 2 Standalone mode configuration

In a client/server configuration, the components of the Infor ES architecture are distributed over two or more machines. There are many client/server configurations. The most common configurations are described here.

The simplest client/server configuration is sometimes thought of as a variation of standalone mode. In this configuration, the application tier, database driver and RDBMS are on one machine, while the display drivers are distributed among the user workstations. An instance of the application virtual



machine and at least one instance of the database driver is started for each user. This configuration is illustrated in Figure 3.


(bshell)

Database Driver

Display Driver Display Driver

Application ObjectsApplication

Virtual Machine(bshell)

Database Driver


Figure 3 Client/Server configuration I

When two machines are available to be used as servers, two configurations are commonly used. In both configurations, the display drivers reside on the user workstations.

In the first configuration, the application tier and database driver are placed on one server, while the database server is placed on another. An instance of the application virtual machine and at least one instance of the database driver is started for each user. All users have access to the same application objects and database servers. This client/server configuration is illustrated in Figure 4. This configuration uses the RDBMS’s networked client functionality to provide client/server access.




(bshell)

Database Driver




Database Driver


Figure 4 Client/Server configuration II

In the second configuration, the application tier is placed on one server, while the database driver and database server are placed on another. As with the previous configuration, an instance of the application virtual machine and at least one instance of the database driver is started for each user. All users have access to the same application objects and database servers. This client/server configuration is illustrated in Figure 5. This configuration uses the Infor ES method of client/server access between the application virtual machine and the database driver.

Note: This configuration is not supported by the ERP LN installer and must be set up manually, it’s not recommended either.




(bshell)

Database Driver




Database Driver


Figure 5 Client/Server configuration III

There are many other configurations of client/server systems, including dividing the application logic among multiple servers or using multiple servers for distributing the database.


Chapter 2 Infor ES Database Organization 2

All of the application data used by ERP LN is stored in database tables in the RDBMS. To keep the majority of the ERP LN processing independent of the RDBMS, Infor ES uses a data dictionary. The data dictionary includes domain, schema, and referential integrity information that are stored in a database independent manner.

Because so many tables are needed, a convention is used for naming tables, columns within tables, and indexes to data within the tables. This chapter describes the data dictionary and the naming conventions used by the Infor ES database drivers to access data stored in the RDBMS. It also discusses how Infor ES data types are mapped to Informix data types.


• Infor ES data dictionary • Table naming convention • Column naming convention • Index naming convention • Hash column naming convention • Data type mapping • Additional constraints

Infor ES data dictionary A data dictionary is a catalog that provides information about the data in a database. It can be thought of as “data about the data,” or metadata. A data dictionary can be used to find data that resides within a database table.

The Infor ES database drivers maintain a data dictionary because the data used by the ERP LN applications may differ from the database tables defined in the RDBMS. The Infor ES data dictionary maps ERP LN data types, domains, schemas, and referential integrity information to the appropriate information in the RDBMS. When storing or retrieving data in the RDBMS, the database driver maps data dictionary information to database table definitions.

Infor ES data dictionary information can be kept in shared memory where it will be available to all running Infor ES application virtual machines. The data dictionary information is shared among all the sessions open within a single database driver.

The Infor ES data dictionary cannot be used directly by the database driver to create Informix tables. This is because not all Infor ES data types exactly match Informix data types. To create valid Informix tables, the driver must perform some mapping or translation. When mapping the Infor ES

Infor ES Database Organization


data dictionary to tables in Informix, conventions are used for the table names, column names, and index names.

Table naming convention The table name of an Infor ES table stored in Informix has the following format.

t<Package><DD Table name><Company number>

The following describes each of the components of the table name. • Package

The package is a two letter code that refers to the ERP LN package that created the table. For example, a table created by the Infor ES Tools package has the package code tt.

• DD Table Name The DD table name is the name of the table used in the data dictionary. The data dictionary table name consists of three letters followed by three digits. The letters refer to the application that uses the table and the digits indicate the order in which the tables were created.

• Company Number Within Infor ES, three digit company numbers are used to differentiate areas of functionality. There must be a company with the number 000. In addition, there may be several other company numbers.

For example, the data dictionary table adv999 with company number 000 is created in Informix as tttadv999000.

Column naming convention Each column in the Infor ES data dictionary corresponds to an Informix column. If an Infor ES data dictionary column has a depth greater than one, each level in the Infor ES data dictionary column maps to a separate Informix column. In addition the Infor ES data dictionary uses the Informix row id as a pseudo-column. The column does not exist in the table, but is used for data retrieval.

The rules for column names are as follows: • General

When an Infor ES column name is created in Informix, it is preceded by the string t_. For example, the Infor ES column with the name cpac is created in Informix with the name t_cpac. By preceding column names by t_, reserved words are avoided. If a column name contains a period [ . ], the period is replaced by the underscore [ _ ] character.

• Array columns In the Infor ES data dictionary, array columns can be defined. An array column is a column with multiple elements in the column. The number of elements is called the depth. For example, a column containing a date can be defined as an array of three elements—a day, a month, and a



year. In Informix, the three elements of the array column are placed in separate columns. The names of these columns include a suffix with the element number. For example, an array column called date will become: • t_date_1: element 1 • t_date_2: element 2 • t_date_3: element 3

Index naming convention Infor ES indexes are identified by a sequence number for each table, with the sequence numbers starting from one. Each table has at least one index: the primary index. To make all index names unique, the names of several components are concatenated to make the index name. The index name includes the package code, the table name, the company number, the index number, the index type, and the table owner name. The index type refers to the order, either ascending or descending.

Index names have the following format:

<Table name><Company number><Index number><Index type><Table owner name)>

For example, the index name for an Infor ES table with name ttadv999, index number 1, company number 000, index type ascending order, owned by user baan is:

ttadv9990001abaan

If the name of the table owner is long, it is truncated so that the index name does not exceed 18 characters.

For each index entry in the data dictionary, the database driver creates one index. Since Informix indexes are bi-directional, the same index can be used in a descending order query.

Note:

• when a table has one or more BLOB columns the following additional index is created: i<DD table name><company number>_UUID

Data type mapping The following table shows the mapping between Infor ES data types and their Informix counterparts.

Mapping between Infor ES and Informix data types

Infor ES data type Informix data type

BDB_CHAR Smallint



BDB_ENUM Smallint

BDB_SHORT Smallint

LONG Integer

TIME Datetime 1

TEXT Integer

BITSET Integer

DATE Date

FLOAT Smallfloat

DOUBLE Float

STRING Char

TSS_STRING Nchar

RAW1) Char (in a base64-like encoding)

BLOB2)3) blob

Not supported in Infor Baan IV

If a table contains BLOB columns a column UUID is generated, which is mapped as STRING in BaanIV and mapped as RAW in other versions.

Informix stores BLOBs in a socalled “smart blob space”, which can be created using the “-S (minus capital S)” option of the ‘onspaces’ program. A resource variable called ‘inf_smart_blob_space’ exists to configure the name of the smart blob space.

There are several instances where this mapping is not perfect. The following lists discrepancies in this mapping.

• Informix allows you to store short values in the range -32767 to 32767 while the application virtual machine allows you to store short values in the range -32768 to 32767. For long data types, Informix allows you to store values in the range -2147483647 to 2147483647 while the application virtual machine allows you to store values in the range -2147483648 to 2147483647. The value -2147483648 of the long data type in the application virtual machine cannot be stored in Informix because it is out of the range for long data types. To support all values in the application virtual machine, Infor ES allows the user to map these data types to integer or double in Informix.

• Informix allows users to store the hexadecimal value 0 in the character field but it cannot be used for comparison, for example, where char_field > [ hex 0 ]. To allow this comparison, BDB_CHAR is mapped as a number to the Informix data type “short”. In the application virtual machine, a date is stored as the number of days from the year 0001. Informix stores a date as the number of days since December 31, 1899.

• Conversion from a application virtual machine date to an Informix date involves getting the day, month, and year from the application virtual machine date (using the application virtual machine function) and passing these to an Informix function which returns the corresponding Informix date.



Conversion from Informix to the application virtual machine follows the reverse path. In the application virtual machine, date 0 means that the date is not specified.

• To transform an application virtual machine date 0 to an Informix date, minimum values (day_of_month = month = year= 1) are used. Similarly, when day_of_month = month = year = 1 is retrieved from Informix, the application virtual machine date is set to zero.

Notes:

• Infor ES converts multibyte data into TSS format for internal processing. • Multibyte data can be stored in the database either in TSS format or in the original native format.

For storing in TSS format, the Informix data type char is used. For storing in native format, the Informix data type nchar is used. The difference between char and nchar is that char data is sorted on byte order and nchar data is sorted on localized order. Certain environment variables need to be set to use the Informix Global Language Support (GLS) functionality.

• For a complete discussion on Informix GLS features, refer to the Informix Guide to GLS functionality. In particular, the environment variables DB_LOCALE should be correctly set to match the actual database locale. If there is a mismatch between DB_LOCALE and the database locale, the Informix driver prints a warning in the log file. Since this may or may not be an error, the Informix driver continues to work after printing this warning. If this warning is displayed, you should investigate the setup and make sure that the locales are compatible.


Chapter 3 Database Driver Internal Processing 3

The Infor ES Informix database driver converts RDBMS independent database requests into requests designed specifically for Informix. This chapter describes some of the internal processing that occurs within the Infor ES Informix database driver.

• Data integrity • Database driver SQL processing • Setting driver behavior

Data integrity Several features of the Infor ES database driver help to insure data integrity. These features include locking mechanisms, methods used for insuring referential integrity, and methods used for distributed databases.

Data integrity is also maintained while minimizing network traffic by using data buffering techniques. In addition, the Informix server maintains data integrity through logging. This section gives an overview of the features used by the Infor ES Informix database driver to ensure referential integrity, to work with distributed databases, and to apply data buffering techniques. It also discusses the Informix logging facility. Locking strategies are discussed in detail in Chapter 6.

Referential integrity

Referential integrity preserves the defined relationships between tables when records are maintained. The Infor ES database driver has a built-in mechanism for preserving referential integrity; it does not depend on the underlying RDBMS for maintaining referential integrity.

Distributed databases

An Infor ES Informix query can require information from multiple tables. When tables are distributed, they can be physically located in different databases. To access data from distributed tables, the query is split into multiple queries, with one query for each database. To service each of these queries, the application server activates multiple database drivers. One active database driver is called upon to retrieve the data required from a single database. When all of the data required by the original query is gathered from the databases, the database driver joins the data and returns it to the application server.

Database Driver Internal Processing


Data buffering

Updates can be buffered by the application server and flushed at the time of transaction commit, or earlier when necessary. This reduces the number of network round trips and data volumes.

When multiple rows are returned from a query, the rows are buffered and then sent back to the application server as one block. Data reduction and compression is applied to minimize the amount of data transferred between the application server and the database driver.

Logging

The Informix server uses logging to implement data integrity. This facility implements transactions and brings the database up to date after a system or media failure. To take advantage of this facility, either the database must be created with logging or logging must be turned on by the database administrator after the database is created. Informix provides a logging system so that you do not have to specify a path for the log. A table can optionally be created without logging. The Informix driver creates all tables except temporary tables with logging.

Database driver SQL processing As discussed in Chapter 1, the application server layer sends RDBMS independent database queries and update requests to the database driver. It is up to the database driver to convert these RDBMS independent database requests into SQL statements that are appropriate to the specific RDBMS being used. This section first describes the SQL processing provided by the Informix database server, then details the SQL processing performed by the Infor ES Informix database driver.

Informix SQL processing

The Informix database server uses the ANSI standard structured query language (SQL) data language, and allows embedded SQL (ESQL) processing. ESQL allows SQL statements to be embedded of into a host language such as C. ESQL statements can be mixed with other host language statements; host variables can be used to represent many of the database manipulation elements. ESQL provides the same capabilities as interactive SQL, and allows SQL statements to be generated at runtime.

When SQL statements are generated at runtime, this is called dynamic SQL. There are two types of dynamic SQL statements: SELECT type and non-SELECT type. A SELECT type statement is used to fetch rows from a table. Optionally, they can perform some manipulations on the fetched rows, such as updating the row or deleting the row. For these kinds of operations, a structure called cursor is used. A non-SELECT type statement is used to perform actions other than SELECTs, such as creating tables, dropping tables, indexing tables, or committing transactions. In dynamic SQL, to perform these database actions, a statement is PREPARED and EXECUTED, optionally with parameters.



A cursor is used when executing a SELECT type statement. It can be thought of as a row marker for a database table. With a single cursor, or multiple simultaneously opened cursors, you can retrieve and update sets of rows or issue other database statements. Once a cursor has been opened, the cursor row marker can be moved forward through the set, pointing to each individual row in turn. When the cursor moves onto a row, the data in the row can be transferred to host variables. In addition, the row can be deleted or updated.

Special cursor oriented statements are available in dynamic SQL, which provide the following functionality:

• PREPARE a select statement and DECLARE a cursor for it • OPEN a cursor to start processing data • FETCH a new row and move data from the row to a host variable • UPDATE the current row using host variables • DELETE the current row • CLOSE the cursor, stop processing the data

A hold cursor remains open even after a transaction ends. A hold cursor allows uninterrupted access to a set of rows across multiple transactions. Ordinarily, all cursors close at the end of a transaction; a hold cursor does not. Hold cursors allow fetch optimization to be applied for fetching the next record or previous record on a table after a commit.

Infor ES Informix database driver SQL processing

SQL statements are dynamically generated by the database dependent layer of the Infor ES Informix database driver. Because Infor ES applications are dynamic, it is not known in advance which tables will be used at run time, hence it is not possible to prepare the queries before run time.

Within the Infor ES Informix database driver, SQL statements are processed in several steps. This section describes these steps.

When the Infor ES Informix driver receives a query from the application server, the query is translated into a format suitable for Informix. The SQL statement is parsed, input and output variables are bound and the query is executed using the statement handle. The rows returned by Informix are passed to the database independent layer of the Infor ES Informix database driver, which sends the results back to the application server.

When a statement needs to be re-executed, the cursor from the previous execution is closed and the resulting rows are discarded (whether the re-execution is with the same input parameters or not). If new input values are required, the new values are assigned to the input parameter columns, and the query is re-executed. However, for re-execution, no re-parse of the statement or re-bind of input and output parameters is required. This improves the overall performance.

Note: Data can be manually placed into the database using the Infor ES utility bdbpost6.x. This utility is used to place data into a new database table or to append data to an existing database table. Certain options can be set when using bdbpost6.x. When bdbpost6.2 is used with the -f option, the rows are buffered by default and are flushed when the buffer is full. The buffer size needs to be specified; otherwise buffering is not done. The array buffer size can be specified by using an



environment variable or resource variable. The environment variables, resource variables, and parameter files are explained in a later chapter.

Setting driver behavior There are several facilities available for configuring the Infor ES Informix database driver. The most common is through driver resources. Two other facilities for configuring the Infor ES Informix database driver are environment variables and the parameter files (storage and driver). The driver resources and environment variables are described in more detail in Appendix A and the parameter files in Appendix B.

Driver resources

The database driver resources are parameters that can be set to modify the behavior of the Infor ES Informix database driver. These parameters are set in a file called the resource file (db_resource). There is one resource file for all database drivers that run in an Infor ES environment; resources for all the database driver types can be found there. A database driver reads the parameters set in the resource file when it is first invoked.

The resource file may contain many entries, with one entry per line. Each entry is used to set a single resource parameter, with the resource name followed by a colon and then the value to which the resource is to be set.

The following is an example of the contents of a resource file containing two entries:

dbsinit:01 infenv_lock_timeout:90

When modifying the behavior of the database driver, it is often necessary to modify the behavior of the Infor ES application virtual machine to take advantage of the characteristics of the database driver.

Therefore, there are two types of database driver resources: those that are used to modify the behavior of the database driver and those that are used to modify the behavior of the application virtual machine. Driver resources that are used to modify database driver behavior are called resources for the server. Driver resources that are used to modify behavior in the application virtual machine are called resources for the client.

In a Windows environment, the resource file, db_resource, is located in the directory %BSE%\lib\defaults, where %BSE% refers to the directory where the Infor ES software environment is installed. In a UNIX environment, the resource file, db_resource, is located in the directory $BSE/lib/defaults where $BSE refers to the directory where the Infor ES software environment is installed. When both the database driver and the application virtual machine run on the same machine, there will be only one db_resource file containing all the necessary resources parameters. When the database driver and the application virtual machine run on different machines, there must be one db_resource file located on the machine running the database driver



that contains the server resources, and one db_resource file located on the machine running the application virtual machine that contains the client resources.

In addition to the default resource file, db_resource, it is possible to set up an alternative resource file to override resource values for specific users or groups of users. The alternative resource file is specified with the environment variables USR_DBS_RES and USR_DBC_RES. USR_DBS_RES is used to specify the path to a file containing an alternative resource file for the server and must be set on the machine running the database driver. USR_DBC_RES is used to specify the path to a file containing an alternative resource file for the client and must be set on the machine running the application virtual machine. Any driver resource set in the alternative resource file will override the setting of the same driver resource in db_resource. The next section describes how to set the database driver environment variables.

Environment variables

Environment variables can be used to override driver resources. Usually, a default set of resource parameters is configured in the resource file. The administrator can override these default settings with environment variables.

For the most part, there is an environment variable corresponding to each resource parameter. The environment variable name is usually the uppercase equivalent of the resource parameter name.

As with the database driver resources, some environment variables are used to modify the behavior of the database driver (server) and some are used to modify the behavior of the application virtual machine (client). When a database driver environment variable for the server is to be used, it must be set on the machine running the database driver to override the corresponding driver resource. When a database driver environment variable for the client is to be used, it must be set on the machine running the application virtual machine to override the corresponding driver resource.

Server environment variables

Environment variables that affect the database driver can be used to override the driver resources for all tables in a database or for specific tables and company numbers within the database. There are three ways to set the database driver server environment variables:

• By using the Infor ES sessions Database Definitions (ttaad4510m000) and Tables by Database (ttaad4111m000)

• By manually modifying the Infor ES tabledef6.x file • By using the standard operating system mechanism for setting environment variables

The Infor ES session Database Definitions is the recommended method to modify database driver behavior. When specific tables and companies are to be configured for access with a specific database driver, the session Tables by Database should be used. These sessions causes environment variables for a particular database driver to override the defaults set in the resource file and allow the environment variables to be maintained centrally.

The session Database Definitions maintains database driver configuration information in a file called tabledef6.x. This file is stored in the Windows directory %BSE%\lib or the UNIX directory $BSE/lib residing on the machine where the database driver runs.



While it is recommended that the Database Definitions session be used to maintain this file, advanced users can modify this file manually. The format of the tabledef6.x file is as follows:

<table name>:<company number>:<driver type>(<environment variable>=<value>)

If multiple environment variables are to be specified for a single table and company number, they are listed within the parentheses and separated by commas. If all tables or all companies are to be specified, the asterisk (*) is used in place of table name or company number.

For example, the following entry can be made in the tabledef6.x file:

tccom010:812:inf(INFPROF=0.4)

In this example all the queries on table tccom010812 which require at least 0.4 seconds are logged in the INFPROF file. Note that this table is considered to have a different database definition from other tables. If an Informix driver is already running, but is accessing a different table, a separate driver will be started for this table. Environment variables that appear in the driver specifications of the tabledef6.x file are put into the driver’s environment before it is invoked, so they are available to the driver at startup.

If the default database driver resources must be modified for specific users, the standard operating system method can be used to set database driver environment variables for specific users. These environment variables will override the settings created in the Database Definitions session for these users.

Client environment variables

Database driver environment variables that affect the client can be used to override the client resources that affect the application virtual machine. These environment variables must be set on the machine running the application virtual machine and should be set using the standard operating system methods used for setting environment variables. Any client environment variables that are used override the equivalent resource variables set for the client in the db_resource file.

Storage parameter file

The storage parameter file provides a way to specify the distribution of table and index data in different segments. Storage parameters are used by the database driver whenever a DDL statement such as a create table or create index statement is executed. The following is an example of an entry in the storage parameter file:

*:*:T:INITIAL 32

In this example, tables are created with an initial extent size of 32 KB.

A storage parameter file is defined for each database driver. The file for the Infor ES Informix database driver is located in the Windows directory %BSE%\lib\informix or the UNIX directory $BSE/lib/informix. The format of the storage parameter file is described in detail in Appendix B.


Chapter 4 Database Security 4

The Infor ES Informix database driver maintains security by controlling user access to the database and user access to database objects. The Infor ES DBA module allows the DBA to control access to the database through the GUI screens provided with the Worktop or Webtop interface. Using the DBA module makes DBA tasks easier and less prone to errors than using database driver tools directly. This chapter first discusses how the Infor ES Informix database driver handles issues related to database security. It then explains how to use the DBA module to maintain database security.


• Database driver security features • Informix security features • DBA module

Database driver security features There are two aspects of database security: object security and authentication. Object security refers to the process of determining whether or not a user who has access to the database is authorized to access particular database objects. Authentication refers to the process of determining whether or not a user is authorized to access the database. Both object security and authentication use the concept of groups to ensure security.

This section first describes the group concept, then describes how the Infor ES Informix driver provides object security and authentication.

Groups

In any RDBMS, a group is defined as a collection of database users. All users assigned to a group are granted the same database privileges. Once a group is defined with a certain set of privileges, users can be assigned to that group. Using groups simplifies management of a large number of users with common requirements.

An Infor ES group consists of a database name and methods for providing object security and authentication within the database. The Infor ES group name is the same as the name of the database that holds the Infor ES data within the RDBMS. The Infor ES group uses the mechanisms of the RDBMS to provide object security and authentication. An Infor ES group is a superset of the usual RDBMS group in that it includes not only the RDBMS group, but also the database name and an RDBMS login.

Database Security


In Informix, an Infor ES group is made up of three components: a database, a login (for authentication) and an Informix group (for object security). The Informix database has the same name as the Infor ES group. The login is the same name as the Infor ES group and is assigned DBA privileges in the database. An Informix group is created which becomes the target for privileges granted on objects in the database. Users are associated with the Informix group and, as a result, inherit the privileges granted to the Informix group. The advantage of having a group table is that the members of the group can share and operate on the same data in a single table.

For example, users maria and john can both be assigned to Infor ES group baandb. Group baandb owns the tables and grants select, insert, delete, and update privileges to the Informix group. As a result, users maria and john inherit the select, insert, delete, and update privileges granted to the Informix group, allowing them to access and manipulate Infor ES group table data.

The Infor ES user is shielded from the RDBMS groups. The database driver does all the processing that is needed to make use of the RDBMS groups. Only the database administrator needs to be concerned about the RDBMS groups, and the Infor ES DBA module allows the administrator to easily maintain the RDBMS groups.

Object security

In Informix, when a user creates an object such as a table, the user becomes the owner of that object, and only the owner can access the object. Other users can only access the object if they have been granted privileges to do so. In an Infor ES environment where many users access the same tables in the Informix database, a mechanism has been developed to allow users to share these tables.

To allow different Infor ES users to share the same Informix table, the group concept is used. An Infor ES group maps users to a database in Informix and ensures that members of the Infor ES group have sufficient privileges to access data in the Infor ES group’s tables.

The Infor ES Informix driver uses an Informix group to implement the Infor ES group concept. Whenever a new table is created by the Infor ES group user, select, insert, delete, and update privileges are granted to the Informix group. Any user associated with the Informix group automatically inherits these privileges and can individually perform these operations on the Infor ES group table.

When new users are added, they need only be associated with the Informix group; they automatically inherit all privileges currently granted to the Informix group without need to grant privileges on every group object in the database to the user. When the user is dropped from the Informix group, these privileges are revoked. The user no longer has access to tables within that Informix group. If the privileges to operate on the tables are explicitly granted to the user, then they must also be explicitly revoked when the user is dropped from the Informix group. The overhead of adding users is greatly reduced by granting privileges to the Informix group. This also provides flexibility and ease of maintenance.

In addition, an Informix role is created in the group database. The role name is the group name with the character r concatenated to the end. For example, for group baan, the Informix role will be baanr. The role is created by the group login. In this document, this role is called a group role.

Database Security


In the DDL statements generated by the driver, object names are not qualified by the owner name. Ownership is determined by the session (group or user) the create table is executed in. When creating objects identified as belonging to the group, the user creating the object logs into Informix as the group user. In this case the table will be owned by the group and permissions will be granted on it to allow all group users access.

A table’s configuration is defined in the parameter file. See Appendix B for more information on this file.

Authentication

The database driver maps Infor ES users to Informix user accounts to allow them to establish a connection to Informix and access data. To prevent unauthorized users from accessing the database, non-mapped users cannot establish a connection to the database. When a database is created, an Informix DBA creates a login for the user and associates the user with an Infor ES group. The Infor ES group is mapped to an Informix role in the database. The members belonging to this Informix role inherit the role privileges and are able to establish a connection to the database using a valid password stored in encrypted form in the driver administration files.

A user can be added to or dropped from an Informix group by using the Infor ES DBA module. Users who are authorized to access the database are registered in the Infor ES driver administration files. The user name and password Infor ES uses to log on to Informix on behalf of the user are maintained in the Windows file %BSE%\lib\informix\inf_users or the UNIX file $BSE/lib/informix/inf_users.

All the Infor ES users and their corresponding Informix logon names and passwords and the name of the group they are assigned to are defined in the users file. In Windows this file is %BSE%\lib\informix\inf_users. In UNIX, it is $BSE/lib/informix/inf_users. The format of each entry in this file is as follows:

<Infor ES user>:<Informix user>:<Encrypted Informix user password>: <Infor ES group name>

The Infor ES Informix driver is started by the Infor ES application virtual machine on behalf of the user. From the users file, the driver identifies the Informix user and the user’s password and establishes the connection to Informix.

The group logon procedure also includes a password, which is defined in the groups file. In Windows this file is %BSE%\lib\informix\inf_groups. In UNIX, it is BSE/lib/informix/inf_groups. The format is as follows:

<Group name>:<Encrypted Group password>

Informix security features The Informix database server privileges are used to control data access at the database level as well as at the individual table level.

Database Security


The privileges used by Informix are summarized in the following tables.

Database level privileges

Privilege Description

CONNECT Allows the user to access database tables but not to create permanent tables or indexes. A user with CONNECT privileges can create views and temporary tables.

RESOURCE Includes all the CONNECT privileges, plus authority to create permanent tables and indexes.

DBA Includes all RESOURCE privileges, plus authority to grant and revoke CONNECT, RESOURCE, and DBA privileges for a given database. The user informix is a system administrator and has permission to alter the system catalogs as well.

Table level privileges

Privilege Description

ALTER The user can add a column to a table, delete a column from a table, or modify the data type of a column.

DELETE The user can delete rows from a table.

INDEX The user can create an index on a table.

SELECT (cols)

The user can retrieve data from specified columns. If no columns are specified, SELECT is granted for all columns.

UPDATE (cols)

The user can change values in specified columns. If no columns are specified, UPDATE is granted for all columns.

ALL The user has all of the above table privileges.

When determining privileges, the following should be considered:

• The most restrictive privileges always take precedence. For example, if you grant RESOURCE privileges to a user but do not grant INDEX privileges on a table, the user is unable to create an index on that table.

• When a user creates a table in a database that is not MODE ANSI, all table level privileges except ALTER are automatically granted to all users. In a database created as MODE ANSI, no default table privileges exist.

Database Security


• The DBA can grant table privileges on behalf of other users. The DBA can also grant privileges to a user that allows the user to grant the same privileges to other users.

DBA module The Infor ES DBA module maintains the database administration files used by the Informix database driver. This module allows an administrator to register authorized users and to give users access to data. A tool is provided with the Infor ES Informix database driver to maintain the administration files that the database driver needs at run time. The administration files are stored in the UNIX directory $BSE/lib/informix or the Windows directory %BSE%\lib\informix.

The DBA module implements the user and group administration functions for all Infor ES database drivers. The INF_MAINT utility is an executable program (inf_maint6.x) called by the DBA module that implements the functions necessary to make changes in Informix. While it is possible to call the INF_MAINT utility from outside the DBA module, this is not recommended because the users and groups files are not modified by INF_MAINT.

Note: In Infor ERP Baan IVc the DBA module is not implemented for UNIX platforms.


Chapter 5 Database Driver Profiling and Statistics 5

The Infor ES Informix database driver provides a facility for monitoring system performance. This includes a profiling facility that allows the user to gather timing information for SQL statements, and a statistics facility for gathering driver-wide statistics. In addition, the driver provides a facility for troubleshooting problems. In this chapter, the profiling, statistics, and debugging features of the Infor ES Informix database driver are discussed.


• Profiling • Gathering statistics • Troubleshooting

Profiling The database driver allows users to log timing aspects and statistics. This is useful for tuning because the information may help to identify performance bottlenecks and can give input into the tuning process.

The database driver’s profiling option provides the user with a way to gather the timing of SQL statements that are being executed. Logging all statements with their timings, however, will result in a log file that is so large it cannot be properly analyzed. It is possible to define a logging threshold where only statements that take more than a predefined number of seconds are logged.

With profiling, the following information is logged: the RDBMS request, the elapsed time, the user name, the date, and the time. The maximum precision that can be specified is 0.01 seconds.

To determine which table actions are most time consuming you can set the INFPROF environment variable to a number of seconds. For example, INFPROF can be set as follows:

SET INFPROF=5.0

This sets INFPROF to five seconds, causing statements that takes more than 5.0 seconds of elapsed time to be logged to the file infprof in the current working directory of the driver.

Statement execution time can be viewed for individual tables by setting the INFPROF environment variable in the file tabledef6.x. On a UNIX system, this file can be found in the directory $BSE/lib/tabledef6.x. On NT, it can be found in %BSE%\lib\tabledef6.x. For example, the following entry can be made in the file:

tccom010:812:informix(INFPROF=0.4)

Database Driver Profiling and Statistics


In this example all the queries on table tccom010812 which require more than 0.4 seconds are logged in the INFPROF file. Note that a separate driver is started for this table; the table is considered to have a different database definition.

When profiling is done, each phase in the SQL query processing that exceeds the profiling value is printed.

A sample INFPROF file is shown below. 98-03-09[15:00:39]: Profiling value = 0.02 sec ------ Profiling value exceeded ----- <jim>:98-03-09[15:01:16.054]: Time (multi_fetch) : 0.033598 seconds SQL statement: SELECT /*+ FIRST_ROWS USE_NL(a,b,c) INDEX(a tttadv112000$idx1) */ a.t$pacc,a.t$cpac,a.t$sequ,b.t$desc,c.t$expi FROM baan5.tttadv112000 a,baan5.tttadv130000 b,baan5.tttadv200000 c WHERE c.t$cpac = :1 AND c.t$cmod = :2 AND c.t$cses = :3 AND c.t$vers = a.t$vers AND c.t$rele = a.t$rele AND c.t$cust = a.t$cust AND b.t$cpac = :4 AND b.t$vers = a.t$vers AND b.t$rele = a.t$rele AND b.t$cust = a.t$cust AND b.t$kdes = :5 AND b.t$rkey = :6 AND b.t$clan = :7 AND a.t$pacc = :8 AND a.t$cpac = :9 ORDER BY 1,2,3 ------------------------------------- ------ Profiling value exceeded ----- <jim>:98-03-09[15:01:16.101]: Time (parse) : 0.023754 seconds SQL statement: SELECT /*+ FIRST_ROWS INDEX(a tdctcs440000$idx9) */ a.t$adat,a.t$bfix,a.t$ccod,a.t$cdat,a.t$cgrp,a.t$conf,a.t$cprj,a.t$csta,a.t$ctyp,a.t$delc,a.t$dsca,a.t$dtim,a.t$ercs,a.t$erss,a.t$etim,a.t$fdat,a.t$fre1,a.t$fre2,a.t$fre3,a.t$fre4,a.t$fre5,a.t$fre6,a.t$fre7,a.t$ider,a.t$idln,a.t$loca,a.t$modc,a.t$name,a.t$pact,a.t$phse,a.t$pref,a.t$prgr,a.t$prib,a.t$prio,a.t$prjm,a.t$rdat,a.t$rtim,a.t$rtst,a.t$rtyp,a.t$rusr,a.t$sact,a.t$scmp,a.t$sdat,a.t$solv,a.t$stat,a.t$ttim,a.t$txta,a.t$txtp,a.t$txts,a.t$unit,a.t$uref,a.t$utyp,a.t$vref FROM baan5.tdctcs440000 a WHERE a.t$delc = :1 AND (a.t$loca >= :2) AND (a.t$loca <= :3) AND (a.t$rtyp = :4 AND a.t$unit = :5 AND a.t$uref = :6 AND a.t$utyp = :7 AND a.t$scmp = :8 AND a.t$vref = :9 AND a.t$csta = :10 AND a.t$loca > :11) ORDER BY 39,50,51,52,42,53,8,26,24 ------------------------------------- The example above shows two queries. The first query had an execute time that exceeded the limit, while the second one had a parse time that exceeded the limit.

Gathering statistics The database driver provides an option to gather driver-wide statistics on actions performed, such as:

• Number of cursors (opened, closed, current open) • Number of parses, binds, executes, fetches • Number of logons (sessions) • Number of inserts, updates, deletes • Number of commits, rollbacks

For each action, the cumulative elapsed time spent and the average time is logged. The statistics can be enabled with the environment variable INFSTAT. When the variable is set to zero, a statistics report is generated when the driver terminates (exit from Infor ES Tools or session). When a value n greater than zero is specified, the driver logs an incremental report every n seconds (the driver must be active). The statistics report is written to the file infstat in the current directory.

The following are examples of how INFSTAT can be set:



SET INFSTAT=0

SET INFSTAT=30

In the first example, INFSTAT is set to zero. With this value, only a final report is generated. In the second example, INFSTAT is set to 30. This logs a report every 30 seconds while the driver is active.

Below is a sample output of INFSTAT. Since the report is generic for all databases, some information, such as the specific row actions, may not be appropriate for a particular database driver. <3472> 2009-06-23[16:36:47]: Statistics [interval = 300] DB-Cursor Open Close Parse Bind Define Execute Fetch Break Count 7 7 7 7 13 9 5 5 Time(s) 0.0001 0.0001 0.0003 0.0001 0.0002 0.0100 0.0037 0.0000 Avg 0.0000 0.0000 0.0000 0.0000 0.0000 0.0011 0.0007 0.0000 DubIns DubDel DubUpd db.eq db.eq* Count 0 0 0 0 0 Time(s) 0.0000 0.0000 0.0000 0.0000 0.0000 Avg 0.0000 0.0000 0.0000 0.0000 0.0000 BlobRd BlobApp BlobSz BlobClr Count 60 59 61 1 Time(s) 0.0198 0.3063 0.0085 0.0008 Avg 0.0003 0.0052 0.0001 0.0008 3/4GL CrIdx DrIdx CrTbl ClTbl DrTbl LkTbl NrRow Count 0 0 0 0 0 0 0 Time(s) 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 Avg 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 Logon Logoff Commit Rollback ReadOnly Count 1 1 1 1 0 Time(s) 0.0069 0.0014 0.0051 0.0723 0.0000 Avg 0.0069 0.0014 0.0051 0.0723 0.0000

Statistics can be logged for individual tables by specifying INFSTAT in the tabledef6.x file as shown below: ttaad:*:informix(INFSTAT=0) ttadv:*:informix(INFSTAT=1)

Note that if two tables have different INFSTAT values, a separate server will be started when the second table is accessed.

Troubleshooting The Infor ES Informix database driver provides a facility for troubleshooting problems. The actions performed by the driver can be traced and stored in a log file. In addition, any errors that occur are logged. The following sections explain how to log trace information and how to find and interpret the error log.



Logging database driver trace information

The database driver provides an option to trace online information about the actions that are being performed by the driver. The resulting log file contains debugging information that can help solve problems.

When tracing is enabled, the information stored in the log files includes:

• Table and index information (data dictionary) • The SQL statements being executed • Values of the input and output bind variables • Other function-level debug statements

Tracing can be enabled using the environment variable DBSLOG. Debugging information is appended to the file DBS.LOG in the current directory. If logging is invoked with rexec, the log is stored in the user’s home directory on UNIX or the NT file %BSE%\tmp. Tracing can be enabled by entering the following command:

SET DBSLOG=0560

Several tracing categories are defined so that tracing can be enabled for only categories of interest. See Appendix A for more details.

Logging errors

If an SQL statement generates an error, an error code (a negative number) is returned. The Informix server maps this to the corresponding BDB layer error code. The BDB error code is sent back to the application virtual machine. Some Informix errors have no corresponding BDB error code. These codes are passed back to the application virtual machine after adding 1,000 to the absolute value of the error code.

For example, if the Informix error -399 cannot be mapped to a BDB error, it is passed to the application virtual machine as 1,399 (1,000 + abs(-399)). The user can get the actual error code from this by subtracting 1,000 and then making it negative. To find the meaning of an Informix error code, use the Informix utility finderr.

If an error cannot be mapped to a BDB error, the Informix driver logs it into the log file. The log file can be found on UNIX directory $BSE/log/log.informix or in the Application Log of the Event Viewer in Windows. Refer to this log for a detailed analysis of the cause of the error.

The following information can be retrieved from the log files.

• The user name, date, time, source file, and line number • The function called • The error code returned by the database • The database error description • The BDB error code returned to the application • The failing SQL statement, in some cases



When a database error occurs, an attempt is made to map it to some known or anticipated error condition. Generally, these mapped BDB errors have corresponding error numbers falling in the range of 1 to 1000. If a database specific error occurs, it is mapped to the BDB error code over 1000 with the following formula:

abs(error_code) + 1000

So, if an error -1652 occurs, BDB error 2652 is returned to the application.

In most cases, the log entries from the display driver, application server, and database driver contain enough information to determine the nature of and solution to the problem. Whenever an error is encountered with an error code greater than 1000, you are advised to check the log entries from the database driver.


Chapter 6 Database Driver Configuration and Tuning 6

The Infor ES Informix database driver is designed to allow tuning for optimal performance. Several parameters used by the database driver are present with default values that should provide acceptable system performance, but since every environment is different, the default values of these parameters may not provide optimal performance. This chapter discusses the Infor ES Informix database driver parameters that can be set, and the changes in driver behavior that you can expect when you adjust these parameters.

Concatenated expressions

The ERP LN application can use concatenated expressions, which operate on a combined column.

Database Driver Configuration and Tuning


Concatenated expressions that exist on combined columns are:

• select >= • select > • select <= • select < • select between and

For example, a BaanSQL statement can include a where clause such as:

WHERE comb >{“tt”, “adv”, “000”}

Here 'comb' is a combined column of say columns c1, c2 and c3. This expression selects the following ranges of rows:

• c1 = "tt" and c2 = "adv" and c3 >= "000" • c1 = "tt" and c2 > "adv" • c1 > "tt"

The Informix driver can let Informix solve the WHERE clause using four different techniques: nested, iterative, filter, and keystart. These techniques are introduced because the Informix cost based optimizer is not able to handle these queries efficiently in all situations (full table scans and sort operations can be introduced for these queries).

Specifying a different technique will cause the Informix optimizer to make different decisions on how to execute a query. It provides some workarounds for typical optimizer behavior. However, the optimizer behavior can change in different Informix versions. So each version may have to be tuned differently. This makes it also very difficult to give guidelines.

The INFPROF variable can be used to detect long running or bad performing queries. Then you can experiment with these different techniques. INFPROF is described in Appendix A.

The following describes the nested, iterative, filter, and keystart techniques.

The nested technique

The three conditions are ORed to the following expression:

c1 = “tt” and c2 = “adv” and c3 = “000” OR c1 = “tt” and c2 > “adv” OR c1 > “tt”



This can be rewritten as follows:

c1 > “tt” OR c1 = “tt” AND (c2 > “adv” OR c2 = “adv” AND (c3 = “000”))

The last expression has a nested AND/OR condition, and will therefore be referred to as the nested technique.

The iterative technique

Multiple SQL statements are issued to resolve one query. These statements do not contain 'OR' conditions, so they can be handled efficiently by Informix. The iterative technique can only be used for unbounded queries.

The iterative technique uses the following three conditions:

1 c1 = "tt" and c2 = "adv" and c3 >= "000"

2 c1 = "tt" and c2 > "adv"

3 c1 > "tt"

First, a query with Step 1 is issued. When it does not return a row, it continues with Step 2. When Step 2 does not return a row, it continues with Step 3. In addition, when one step has returned all rows, but more rows are required, the driver continues with the next step.

The filter technique

This technique is related to the nested technique but has a different approach. It initially selects too many rows, but then filters out those rows that do not match the total WHERE-clause. It selects based on the first column in a concatenated index and filters out rows with the NOT() operator. The query is solved as follows:

c1 >= "tt" AND NOT( c1 = "tt" AND (c2 < "adv" OR c2 = "adv" AND (c3 < "000") )

As can be seen, the NOT() expression is like an inverted nested query; these rows are filtered out of the initial set determined by the first condition 'c1 >= "tt"'.

The keystart technique

This optimization identifies concatenated indexes if expressed in certain syntax. This technique is called keystart because it can recognize keys only when the concatenated indexes are specified at the starting point of the WHERE clause.



For Index1 >=(“tt”, “adv”, “000”), the following query should be generated:

(c1 >= “tt” AND ( c1 > “tt” OR (c2 >= “adv” AND (c2 > “adv” OR c3 >= “000”))))

for >= and <= operator.

Following queries are generated for operators ‘>’ and ‘<’:

((c1 >= “tt” AND ( c1 > “tt” OR (c2 >= “adv” AND (c2 > “adv” OR c3 >= “000”)))) AND ( c1 != “tt” OR c2 != “adv” OR c3 != “000” ))

The last record is filtered-out from the result set.

Put in the corresponding resource variable concat_expr for the environment variable CONCAT_EXPR and set the default of this variable to KEYSTART.

Generating queries in the above syntax triggers the keystart optimization introduced in Informix IDS 7.31 to optimize ERP LN’s concatenated expressions. The Informix driver uses this syntax whenever these concatenated expressions are encountered.

Selecting the right technique

By default, the driver uses the keystart method in all cases. Keystart method should be used for index columns only. Other techniques can be used for both index columns and BETWEEN expressions.

When the first column of a concatenated index is very unselective, many rows may be inspected before the first row can be retrieved. In this situation the iterative method may give better performance.

When a technique is not relevant to the query being evaluated, the driver shall choose a technique. For example, the iterative technique cannot be applied on range conditions.

Different techniques will cause the Informix optimizer to take different query execution plans. Informix provides some workarounds for typical optimizer behavior. However, the optimizer behavior can change in different Informix versions, so each version may have to be tuned differently. This makes it difficult to give guidelines.

Set the EXPLAIN environment variable to ‘1’ to detect long running queries or bad performing queries, and experiment with these different techniques.

The iterative technique may perform better for an index whose first key-part is not quite selective.

Prepared cache To map multiple Informix cursors to the same Informix SQL statement, the driver maintains a list of prepared Informix SQL statements and its associated statement ids. When a prepare is required, the local prepared list is first searched to see if a statement has already been prepared. If one has been prepared, a new cursor is associated to the prepared statement. The number of cursors attached to the prepared statement is then increased.



The maximum limit on the length of this prepared statement list is configured using the resource variable inf_prepare_cache_length. A corresponding environment variable INF_PREPARE_CACHE_LENGTH is also available. The default length of this list is 70, which is the minimum allowable length.

This list is maintained in the LRU order. This list is internally maintained as a doubly-linked list.

The default is to use statement cache. To turn off the usage of prepare statement cache, set resource variable inf_use_prepare_cache to zero. The default is 1.

Resource variable inf_stmt_least_fit_policy is used to define the order in which this statement cache is maintained:

See Appendix A for more information on these variables.

Cursor management The Infor ES Informix database driver has two resource variables that influence the cursor handling, inf_open_cursors and inf_retained_cursors. Each of these resource variables is described below.

• inf_open_cursors This resource variable limits the number of cursors that can be open at one time. When a new cursor is opened, it is added to the list of open cursors. The system checks the number of open cursors and if the number exceeds this resource variable, the LRU cursor on the list is removed from the list and put on the retained cursor list. The default value is 30.

• inf_retained_cursors Using this resource variable, the number of inactive cursors and therefore the number of closed cursors, can be reduced.

When a query has fetched all the rows, a close cursor is issued on the query, which means that Informix is notified that no additional fetches will be done. This gives Informix the chance to free certain query resources, such as sort area space. After the close cursor, the query can be re-executed without re-opening (parsing, binding) the cursor. The driver does not know if a cursor in close cursor state will be re-used later. In the worst case it is not re-used, and the cursor will continue to be reserved for the query.

After all rows have been fetched, the driver has a facility to put inactive cursors (in close cursor state) in a break list. The number of inactive cursors in this list is controlled by the resource inf_retained_cursors, which defaults to 20. If more than this number of cursors appear in the break list, the least recently inactivated cursor is removed from the list. When the original query is performing a re-execute, the driver detects that the cursor is on the break list, and moves it to the open list.

Increasing the value of inf_retained_cursors leads to less re-parsing and re-binding of queries, which reduces CPU resources. The number of open cursors however (and thus memory) is increased.



Informix directives The purpose of Informix directives is to help the Informix query optimizer to make better query execution plans. However, there could be cases when the over-riding directives could hurt performance. In such cases, there should be a way to turn off the use of Informix directives.

Resource variable inf_use_hints determines whether to use Informix directives in the queries generated by the driver. There is a corresponding environment variable INF_USE_HINTS.

Optimistic and pessimistic reference checks To optimize concurrency, the Infor ES Informix database driver supports optimistic and pessimistic reference checks. In lookup reference mode, when inserts are performed in a child table, the driver checks whether the reference exists in the parent table and locks the referenced record to be sure that another user cannot delete it within the current transaction. This approach is called the pessimistic approach.

This approach blocks an insert of another user referencing the same parent row, thereby affecting the concurrency. To avoid this problem there is also an approach where a row in the parent table that is not locked is used depending upon the choice of the user. This approach is called the optimistic approach. As the record is not locked, another user can still perform an insert operation, which improves the concurrency. Enabling of this option is configurable via the dbsinit resource variable.

To choose either optimistic or pessimistic reference checks, set the value of dbsinit in the UNIX file $BSE/lib/defaults/db_resource or the Windows file %BSE%\lib\defaults\db_resource. The default is pessimistic reference checks. For optimistic reference checks, set dbsinit to 01.

Informix multiplexing Informix multiplexing decreases the number of TCP/IP connections that must be made between the database driver and the Informix engine. Multiplexing has been implemented within the Informix engine. It allows all Informix connections from a single database driver to use a single TCP/IP connection. Without multiplexing, Informix opens one TCP/IP connection for each connection with the database driver.

This is inefficient because the driver only uses one of these connections at a time. Informix multiplexing is only available on UNIX installations because it has been determined that it is not necessary for NT installations. By default, multiplexing is not enabled.

In addition to reducing the number of TCP/IP connections between the database driver and the Informix engine, multiplexing allows the database driver to benefit from Informix shared memory connections.



Shared memory connections are faster than network connections, but cannot be used when multiple connections are open. With multiplexing, multiple connections are avoided.

To enable Informix multiplexing, you must change entries in two Informix files: the SQLHOSTS file and the ONCONFIG file.

Without Informix multiplexing enabled, the following entry is included in the SQLHOSTS file:

#INFORMIXSEVER NETTYPE Host Name Service Name

For example:

erplnsrvr onsoctcp erp erpbm

Where erplnsrvr is the DBSERVERNAME, onsoctcp is the protocol used, erp is the machine name, and erpbm is the UNIX service in the file /etc/services.

To enable Informix multiplexing, if erplnsrvr already exists, add m=1 to the above line as follows:

erplnsrvr onsoctcp erp erpbm m=1

You must also add two lines similar to the following to the ONCONFIG file:

NETTYPE tlitcp, 2, 75, CPU NETTYPE sqlmux, 1, 100, CPU

The first line sets the number of TLI/TCP connections to 150 (2 * 75). The second line turns Informix multiplexing on.

Fillfactor and indexes For indexes, the fillfactor setting can be used to reduce the impact of page locking on concurrency. When the index is created, a fillfactor setting can influence the number of rows on each data page. Using a low fillfactor setting causes Informix to spread the data over a greater number of pages, giving better concurrency. The fillfactor setting is not enforced after the index is created.

Using the fillfactor setting gives the most benefit when the number of rows in the table does not change, but there is a significant amount of update activity on existing rows. The First Free Numbers table (tcmcs047) is an example of such a table. The following is an example of an parameter file entry with the fillfactor set to one for table tcmcs047.

tcmcs047:*:T:FILLFACTOR 70

A low fillfactor setting also helps reduce page and index splitting by allocating a greater number of pages for the data and indexes with ample extra space to accommodate new rows.

Note: A low fillfactor setting has the negative side effect of consuming more space in the database and may also cause more I/O activity to satisfy reads.



Update Statistics A database optimizer needs information about table columns, indexes and data distributions to generate a ‘good’ query execution plan. These kinds of information are collected with UPDATE STATISTICS command in Informix. The Informix database driver executes UPDATE STATISTICS after data loaded with bdbpost utility or table reorganization with bdbreconfig.

These are the commands executed from database driver to update statistics automatically.

• update statistics for table • update statistics medium for table distribution only • update statistics high for all heading index columns • update statistics for table index

In case more detailed statistics are needed for a specific table a statistics file can be used. More information about statistics files can be found in appendix A.


Chapter 7 Informix Configuration and Tuning 7

Configuring and tuning the Informix database server is important to avoid performance bottlenecks and to optimize the performance of the Infor ES applications using an Informix database. Please refer to the IBM Informix documentation for configuration and tuning related settings.

Disk organization When determining database placement, it is useful to understand how the database driver organizes the data. This section describes the Informix disk organization.

Disk storage units Informix does its own disk management.

The basic units of internal organization of data are the page, extent, tblspace, chunk, and dbspace.

• Page A page is the basic unit of data access used by Informix. The page size can be configured.

• Extent An extent is a collection of physically contiguous pages that contains data or index information for a single table.

• Tblspace A tblspace is a logical grouping of extents that contains information for a single table and its associated indexes.

• Chunk A chunk is a unit of physical storage. It can be a raw device, part of a raw device, or a set of UNIX or Windows files. Chunks reserve space for databases.

• Dbspace A dbspace is a collection of chunks used for storing databases. A single dbspace can contain all or part of one or more databases, each of which may contain many tables and associated indexes.


Appendix A Driver Resources and Environment Variables A

This appendix lists all the database driver resources and environment variables that can be used as configuration parameters to modify the behavior of the Informix database driver. Some of these resources are used with the client and others with the server. In this context, the client is the Infor ES application virtual machine and the server is the Infor ES Informix database driver. If the Infor ES application virtual machine and the database driver are running on different machines, client resources must be set on the machine running the Infor ES application virtual machine and server resources must be set on the machine running the database driver. Resources for both the client and the server must be set on both machines.

A description of how to set the database driver resources and environment variables can be found in the Chapter 3 section “Setting driver behavior.”

This appendix provides the following information:

• Summary of Informix driver resources and environment variables • Detailed description of Informix driver resources and environment variables • Informix environment variables used with Infor ES

Summary of Informix driver resources and environment variables There are four types of resources and environment variables that can be used with the Infor ES Informix database driver:

• Client and server resources used by all Infor ES database drivers • Client resources used by all Infor ES database drivers • Server resources used by all Infor ES database drivers • Resources used only by the Infor ES Informix database driver

The following four tables provide a summary of each of these types of resources and environment variables. Detailed descriptions of each entry in the tables can be found in the section “Detailed description of Informix driver resources and environment variables” later in this appendix.

Client and server resources used by all Infor ES database drivers

Resource name Environment variable Description

rds_full RDS_FULL Sets maximum number of rows transferred in one block

baan_sql_cache BAAN_SQL_CACHERO Defines the size of internal

Informix Configuration and Tuning


rows WS buffers in the query processor

baan_sql_trace (tt_sql_trace)

BAAN_SQL_TRACE (TT_SQL_TRACE)

Allows viewing of SQL query information

use_shm_info USE_SHM_INFO Enables or disables shared memory use

Client resources used by all Infor ES database drivers

Resource name Environment variable Description

bdb_debug BDB_DEBUG Sets debugging link between client and server

bdb_driver BDB_DRIVER Sets database specifications

bdb_max_server_schedule

BDB_MAX_SERVER_SCHEDULE

Defines mechanism for terminating idle database drivers

ssts_set_rows SSTS_SET_ROWS Sets number of rows read ahead (single table single row)

USR_DBC_RES Specifies alternative resource file for client

baan_sql_stmt_cache_size

BAAN_SQL_STMT_CACHE_SIZE

Defines the size of the query cache

Server resources used by all Infor ES database drivers

Resource name

Environment variable Description

bdb_max_ sessions

BDB_MAX_SESSIONS Defines number of sessions per driver

bdb_max_session_schedule

BDB_MAX_SESSION_ SCHEDULE

Defines mechanism for closing idle driver sessions

dbslog DBSLOG Allows driver profiling

DBSLOG_LOCK_PROF Specifies lock time above which locks are logged



dbslog_name DBSLOG_NAME Allows file name to be specified for logging

dbsinit Specifies optimistic or pessimistic reference checking

enable_refmsg ENABLE_REFMSG Causes logging of denied updates of delete actions

USR_DBS_RES Specifies alternative resource file for server

Resources used only by the Infor ES Informix database driver

Resource name

Environment variable Description

infenv_dd_map — Modifies datatype mapping

infenv_lock_timeout

INF_LOCK_TIMEOUT Sets the lock wait period

inf_fetarrsize FETARRSIZE Sets FetArrSize variable

inf_flush_rows FLUSH_ROWS Sets interval for flushing buffer

inf_init INF_INIT Enables driver optimizations

Inf_max_array_insert

INF_MAX_ARRAY _INSERT

Defines maximum number of rows inserted

inf_max_cursors INF_MAX_CURSORS Sets maximum open cursors

INFPROF Allows profiling

INFSTAT Allows statistics to be gathered

inf_open_cursors

INF_OPEN_CURSORS Limits the number of cursors open at one time

inf_prepare_ cache_length

INF_PREPARE_CACHE_LENGTH

Sets max. length for list of prepared Informix SQL statements used when assigning cursors

inf_retained _cursors

INF_RETAINED _CURSORS

Sets the number of inactive cursors to retain for reuse

inf_stmt_least_fit_policy

Defines the order in which the prepare statement cache is maintained



inf_update_statistics

INF_UPDATE_STATISTICS

This parameter turns on/off use of update statistics

inf_use_prepare_cache

This parameter turns on/off use of prepare statement cache.

max_sql_buffer MAX_SQL_BUFFER Allows adjustment to size of internal SQL buffers

optmsg OPTMSG Disables piggybacking of cursor operations

inf_smart_blob_space

INF_SMART_BLOB_SPACE

Name of the smart blob space where BLOBs must be stored

Detailed description of Informix driver resources and environment variables This section provides detailed information about the Infor ES Informix driver resources and environment variables. The driver resources are divided into two sections: those that are generic to all Infor ES database drivers and those that are specific to the Infor ES Informix driver. Each group of resources is listed in alphabetical order.

Generic driver resources

baan_sql_cacherows / BAAN_SQL_CACHEROWS

Driver resource baan_sql_cacherows

Environment variable

BAAN_SQL_CACHE_ROWS

Client/Server resource

Set for both client and server

Type Integer

Default 71

Supported Infor ERP LN 6.1

Description This variable influences the number of records that are internally cached by the query processor for sorting, aggregation functions or prepared sets. When this limit is exceeded, temporary files will be generated.



A prime number should be specified for optimal performance of the internally used hash functions.

baan_sql_stmt_cache_size / BAAN_SQL_STMT_CACHE_SIZE

Driver resource baan_sql_stmt_cache_size


BAAN_SQL_STMT_CACHE_SIZE


Set for client only

Type Integer

Default 330


Description This resource sets the number of inactive queries that should be retained for reuse.

baan_sql_trace / BAAN_SQL_TRACE tt_sql_trace / TT_SQL_TRACE

Driver resource baan_sql_trace


BAAN_SQL_TRACE


Set for client only

Type Integer (Octal)

Default 0

Supported TT_SQL_TRACE : Infor Baan IVc, Infor ERP 5b and 5c BAAN_SQL_TRACE : Infor ERP LN 6.1

Description This variable is introduced to view the Infor ES SQL query information being handled in client and server. When this variable is set, the client prints debug



information to the logfile (client) or dbs.log file (server). The information contains different categories which can be enabled separately, but most categories are not useable for the audience of this document. TT_SQL_TRACE is the old name used in Baan IV, ERP 5b and ERP 5c. BAAN_SQL_TRACE is used for ERP LN 6.1. The relevant values of the baan_sql_trace / tt_sql_trace variable and their descriptions are shown below:

0000200 Times for query execution

0002000 Major query interface logging

0004000 Detailed query interface logging

bdb_debug / BDB_DEBUG

Driver resource bdb_debug


BDB_DEBUG


Set for client only

Type Integer (octal)

Default 0

Supported All versions

Description This variable is used to generate debugging information about the communication between the client and the database driver. When set, the client prints debugging information to standard error (stderr). The following categories of debugging information can be specified:

00001 server types

00002 database actions

00004 delayed lock actions

00010 reference information

00040 TSS info from $BSE/lib/tss_mbstore

00100 permission information

Multiple categories can be defined by adding the octal values. The value is compared bitwise to



determine if a given category should be logged.

bdb_driver / BDB_DRIVER

Driver resource bdb_driver


BDB_DRIVER


Set for client only

Type String

Default None


Description This variable is used to set a database specification, usually found in the file tabledef6.2. When this variable is set, all tables will be accessed using the database driver specified and tabledef6.2 will not be read. The driver specified must be defined in the file $BSE/lib/ipc_info.

bdb_max_server_schedule / BDB_MAX_SERVER_SCHEDULE

Driver resource bdb_max_server_schedule


BDB_MAX_SERVER_SCHEDULE


Set for client only

Type Integer

Default 3


Description This variable defines the mechanism for terminating idle database drivers by the application virtual machine. Whenever the database driver has no more open sessions, it can be terminated by the



application virtual machine. Closing an idle database driver is done after a number of schedule ticks. A schedule tick is generated whenever an Infor ES session is ended. At this point, all idle database drivers will have a schedule counter incremented. When the value of the schedule counter reaches the value of bdb_max_server_schedule, the database driver is terminated.

bdb_max_sessions / BDB_MAX_SESSIONS

Driver resource bdb_max_sessions


BDB_MAX_SESSIONS


Set for server only

Type Integer

Default 0 (unlimited)


Description This variable defines the number of sessions per driver. If any driver has reached this threshold, a new driver will be started to handle any new sessions.

bdb_max_session_schedule / BDB_MAX_SESSION_SCHEDULE

Driver resource bdb_max_session_schedule


BDB_MAX_SESSION_SCHEDULE


Set for server only

Type Integer

Default 3


Description This variable defines the mechanism for closing idle sessions in the driver. Whenever the client process



has no more references (cursors or queries) to the session, it can be closed by the client. Closing an idle session is done after a number of schedule ticks. A schedule tick is generated whenever an Infor ES session is ended. At this point, all idle sessions will have a schedule counter incremented. When the value of the schedule counter reaches the value of bdb_max_session_schedule, the session is closed The default for bdb_max_session_schedule is three. Setting bdb_max_session_schedule to one would result in fewer connections from the driver to the RDBMS since whenever an Infor ES session is ended, the corresponding RDBMS session (logon) is closed (logoff).

concat_expr / CONCAT_EXPR

Driver resource concat_expr


CONCAT_EXPR


Set for server only

Type String

Default KEYSTART for Informix driver


Description This environment variable has to be set to either FILTER, ITERATIVE, NESTED, or KEYSTART depending on which Query Optimization Method is needed. This can also be set in the index optimization field in the inf_driver_param file. See table/index optimization in Appendix B.

dbsinit

Driver resource dbsinit


—


Set for server only




Default 1


Description This variable allows flags to be set to specify the optimizations to be used. At this time, legal values are 000 (not set) and 001. Other values are reserved and should not be used. A flag of 00001 specifies that an optimistic approach should be used when checking for references in parent tables. The referenced row in the parent table is not locked, improving the overall concurrency. If this flag is not set, optimistic reference checking is not used. See the section “Optimistic and pessimistic reference checks” in Chapter 6.

Dbslog / DBSLOG

Driver resource Dbslog


DBSLOG


Set for server only


Default 0


Description This variable provides detailed debugging information about the online processing of the driver. The information is logged in the file dbs.log in the driver’s current directory. The following debugging categories can be specified:

0000001 Data Dictionary information of tables within the driver

0000010 Row action information

0000020 Table action information

0000040 Transaction action information



0000100 DBMS input/output data -

0000200 Administration file info (SQL drivers)

0000400 DBMS SQL statements

0001000 General debug statements

0004000 Data buffering info (communication)

0100000 Lock retries logged (includes session name)

0200000 Logs successful locks and longest lock duration in a transaction

Multiple categories can be defined by adding the octal values. The value is compared bitwise to determine if a given category should be logged.

DBSLOG_LOCK_PROF

Driver resource —


DBSLOG_LOCK_PROF


Set for server only

Type Floating point number

Default 0


Description Specifies the minimum duration of a lock that should be logged. Any locks of shorter duration will not be logged. This variable specifies the minimum number of seconds, to a precision of milliseconds, that should elapse before a lock is logged. Lock time is calculated as the time from when the first record in a transaction is locked to the time of the commit or abort. This is the longest time a record remains locked during a transaction. Please note that the appropriate dbslog categories must be set.

DBSLOG_NAME

Driver resource —




DBSLOG_NAME


Set for server only

Type String

Default dbs.log


Description Allows a file name to be specified where DBS logging information is to be written. If there is already a file with the same name, it will be used for logging. If the file is locked during write operations, multiple servers can use the same log file.

Enable_refmsg / ENABLE_REFMSG

Driver resource enable_refmsg


ENABLE_REFMSG


Set for server only

Type Boolean

Default 0 (disabled)


Description There are two valid values for this variable: 0 and 1. When it is set to 1, a log message is generated in the database driver log file when an update of a delete action has been denied because of existing references. When it is set to 0, no log messages are generated.

Rds_full / RDS_FULL

Driver resource rds_full


RDS_FULL





Type Integer

Default 5


Description This variable defines the maximum number of rows transferred between the Infor ES application virtual machine and the driver as one block. Multiple blocks (and thus network round trips) are transferred if more rows are requested. This variable should be set to the same value for both client and server.

Ssts_set_rows / SSTS_SET_ROWS

Driver resource ssts_set_rows


SSTS_SET_ROWS


Set for client only

Type Integer

Default 3


Description This variable defines the number of rows to be read ahead for a fetch request from the client. The default is three rows, which means that for one fetch request, three rows will be read. For the following two fetch requests, rows will be taken from the client row buffer or fetched from the database without re-executing the query.

Use_shm_info / USE_SHM_INFO

Driver resource use_shm_info


USE_SHM_INFO



Type Boolean



Default 1 (enabled)

Supported Infor ERP 5b, ERP 5c, ERP LN 6.1

Description This variable can be used to enable or disable the use of shared memory to each of the database driver DDs. There are two valid values for this variable: 0 and 1. When it is set to 0, shared memory is disabled. When it is set to 1, shared memory is enabled. Use_shm_info is not supported in Baan IV.

USR_DBC_RES

Driver resource


USR_DBC_RES


Set for client only

Type String

Default None


Description This variable contains the file specification of an alternative resource file for the client. The file specification is based on the BSE directory and is within double quotes. When set, any resources in the alternative resource file override the same client resources set in db_resource.

USR_DBS_RES

Driver resource


USR_DBS_RES


Set for server only



Type String

Default None


Description This variable contains the file specification of an alternative resource file for the client. The file specification is based on the BSE directory and is within double quotes. When set, any resources in the alternative resource file override the same server resources set in db_resource.

Informix driver specific resources

infenv_dd_map

Driver resource infenv_dd_map


—


Set for server only


Default 0


Description The ranges for Infor ES datatypes short and long are larger than for the corresponding Informix data types. This means that some Infor ES data is potentially out of range in Informix. By setting this resource, the data type mapping can be changed to accommodate all data. The following are legal values for infenv_dd_map:

01 Infor ES short is mapped to Informix integer

02 Infor ES long is mapped to Informix float

03 Infor ES short is mapped to Informix integer and Infor ES long is mapped to Informix float.

Infenv_lock_timeout / INF_LOCK_TIMEOUT

Driver resource infenv_lock_timeout


INF_LOCK_TIMEOUT




Set for server only

Type Integer

Default Not set (no wait period)


Description This variable is used to set the lock wait period. The value specified indicates the maximum time, in seconds, that a process will wait for a lock to be released. If the lock is still held at the end of the waiting period, the database server ends the operation and returns an error code to the process. If this variable is not set, then there is no wait period and an error is returned immediately when a row or table is found to be locked. The recommended setting is 5.

Inf_fetarrsize / FETARRSIZE

Driver resource inf_fetarrsize


FETARRSIZE


Set for server only

Type Integer

Default 1


Description This variable is used to set the FetArrSize variable. If it is not set, the value 1 is used.

Inf_flush_rows / FLUSH_ROWS

Driver resource inf_flush_rows


FLUSH_ROWS




Set for server only

Type Integer

Default 100


Description The driver use in some situation buffered inserts to improve performance. Usually, inserts are buffered until the buffer is full. If the buffer needs to be flushed before it is full, inf_flush_rows can be used to set the number of rows in the flush interval.

inf_init / INF_INIT

Driver resource inf_init


INF_INIT


Set for server only

Type Integer

Default 0


Description This variable contains several flags that are used to enable driver optimizations. Multiple flags can be set by adding the octal values of each flag to be set. The following are the inf_init flags:

000010 CHECK_TABLE_EXISTS When this flag is set, the driver checks whether a table exists prior to accessing it for the first time in a session. The check is performed by doing a PREPARE on 'select count(*) from table name'. This is not usually necessary, so with the default setting, the driver does not do this check.



inf_init / INF_INIT

000040 LOCKING_OPT_OFF This flag once allowed you to enable/disable optimized locking. Since inf_use_rowids is no longer supported, this flag is also not supported.

000400 AVOID_DU Not exposed anymore. Driver automatically sets this value.

002000 NT_DOMAIN_LOGIN This flag allows the driver to log into Informix as the Windows Domain user. By default, the driver logs into Informix without a domain name qualification.

inf_open_cursors

Driver resource inf_open_cursors


INF_OPEN_CURSORS


Set for server only

Type Integer

Default 30


Description This parameter limits the number of cursors that can be open at one time in level 2 database mode. When a new cursor is opened, it is added to the list of open cursors. The system checks the number of open cursors and if the number exceeds this resource variable, the last cursor on the list is removed from the list and put on the retained cursor list.

inf_prepare_cache_length / INF_PREPARE_CACHE_LENGTH

Driver resource inf_prepare_cache_length


INF_PREPARE_CACHE_LENGTH




Set for server only

Type Integer

Default 70


Description This parameter sets the maximum limit on the length of the prepared statement list which is used to map multiple Informix cursors to the same Informix SQL statement in level 2 database mode. The minimum length is 70, which is the default.

inf_retained_cursors

Driver resource inf_retained_cursors


INF_RETAINED_CURSORS


Set for server only

Type Integer

Default 20


Description This parameter sets the number of inactive cursors that should be retained in the list for reuse in level 2 database mode

INFPROF

Driver resource —


INFPROF


Set for server only

Type Floating point

Default Not set




Description When a value is specified in this variable, any statement that takes more than the number of seconds specified will be logged. The maximum precision that can be specified is 0.01 seconds. This variable is used to determine which table actions are the most time consuming.

INFSTAT

Driver resource —


INFSTAT


Set for server only

Type Integer

Default Not set


Description This variable allows database driver statistics to be reported. If it is set to a value n greater than 0, statistics are logged every n seconds while the driver is active. If it is set to 0, a statistics report is generated when the driver terminates.

inf_stmt_least_fit_policy

Driver resource inf_stmt_least_fit_policy


—


Set for server only

Type Integer

Default 1




Description This parameter defines the order in which the prepare statement cache is maintained in level 2 database mode

Value Internal Name Description

1 SLFTP_LAST_ELEM Strictly LRU (default)

2 SLFP_LEAST_NO_REF Ordered by least number of references prepared statement

inf_update_statistics

Driver resource inf_update_statistics


INF_UPDATE_STATISTICS


Set for server only

Type Integer

Default 1


Description This parameter turns on/off the use of Informix update statistics.

inf_use_hints / INF_USE_HINTS

Driver resource inf_use_hints


INF_USE_HINTS


Set for server only

Type Integer

Default 1


Description This parameter turns on/off the use of Informix directives. The value 1 turns it on. The value 0 turns it off.



inf_use_prepare_cache

Driver resource inf_use_ prepare_cache


—


Set for server only

Type Integer

Default 1


Description This parameter turns on/off the use of prepare statement cache in level 2 database mode. The value 1 turns it on. The value 0 turns it off.

max_sql_buffer / MAX_SQL_BUFFER

Driver resource max_sql_buffer


MAX_SQL_BUFFER


Set for server only

Type Integer

Default 16


Description This resource sets the maximum size (in KB) of the internal SQL buffers. If the value set is less than the default value, the default value will be used.

optmsg / OPTMSG

Driver resource optmsg


OPTMSG

Client/Server Set for server only



resource

Type Short integer

Default 1


Description This feature reduces the number of round trips required for a cursor operation. With Infor ES, only the close cursor operation is piggybacked to the next operation sent to the Informix Engine, eliminating one round trip. This feature is activated by default. It can be disabled by setting this variable to 0.

Inf_smart_blob_space / INF_SMART_BLOB_SPACE

Driver resource Inf_smart_blob_space


INF_SMART_BLOB_SPACE


Set for server only

Type String

Default sbspace


Description This resource indicates the name of the smart blob space where BLOB columns are stored.

Informix environment variables used with Infor ES The following environment variables can be set to control the actions of Informix directly. These are supported by Informix and not Infor ES but do benefit the performance of the Infor ES application. They must be set before starting the Informix server.

• INFORMIXDIR This variable specifies the full path of the directory in which Informix is installed. If there are



multiple copies or versions of Informix on your system, INFORMIXDIR must contain the directory name for the version that you want to access.

• INFORMIXSERVER This variable specifies the name of the database server. Informix uses the database server name as the index to obtain the connectivity information in the remaining fields from the $INFORMIXDIR/etc/sqlhosts file when client applications connect to database servers. The database server name should correspond to an entry in the sqlhosts file.

• ONCONFIG If you have more than one Informix system initialized in your $INFORMIXDIR directory, you need to set the ONCONFIG environment variable. This variable contains the name of the onconfig file that holds the shared memory parameters. Each Informix system has its own onconfig file. You must store your onconfig file in the directory $INFORMIXDIR/etc. If you do not set ONCONFIG, the default name is onconfig. If Informix cannot find the onconfig file, it reads the configuration values from $INFORMIXDIR/etc/onconfig.std.

• DB_LOCALE For multibyte data, this specifies the locale used by the database.


Appendix B Parameter and Storage Files B

There are two parameter files that influence the behavior of the database driver. The storage parameter file and the driver parameter file. This appendix defines their formats and the parameters used with these files.

A storage parameter file is used for create tables, for example, it can keep information about initial table extent size or DBSPACE to use. The driver parameter file is used at runtime to get information like index optimization flags. Normally a driver parameter file should have a few lines only.

In the past one file called inf_storage was used only. This file is supported for backward compatibility, but the approach with two files is better for performance reason. In case storage parameter and driver parameter files does not exist the driver will fallback to inf_storage file usage.

Note: Infor Baan IVc uses inf_storage file only.

Parameter file formats The parameter files consist of one or more entries, each consisting of several fields separated by colons.

Storage file format The format of an entry in storage file, inf_storage, is:

[{<user list>}]<table/module specification>:<company number>:<object type>: <group>:<table/index optimization>:<refresh time>:<storage parameters>

Note: This file should be used in Infor Baan IVc only.

Storage parameter file format The format of an entry in the storage parameter file, inf_storage_param, is:

[{<user list>}]<table/module specification>:<company number>:<object type>: <storage parameters>

Note: Not available in Infor ERP Baan IVc.



Driver parameter file format The format of an entry in the driver parameter file, inf_driver_param, is:

[{<user list>}]<table/module specification>:<company number>:<object type>:group: <table/index optimization>:<refresh time>

Note: Not available in Infor ERP Baan IVc.

Parameter file field descriptions user list

Description This field consists of a list of comma-separated user names to which this entry applies. When no list is specified, the entry applies to all users.

Example {maria,john}

table/module specification

Description This field consists of a list of comma-separated table names or a module name to which the entry applies. An asterisk (*) indicates all tables.

Example ttadv000,ttadv999 two specific tables

Ttadv all tables in package tt and module adv

Tt all tables in package tt

* all tables

company number

Description This field consists of a list of company numbers to which the entry applies. An asterisk (*) indicates all company numbers.

Example 000,999 companies 000 and 999

* all companies

object type



Description This field consists of a list of object (table or index) identifications to which the entry applies. The following options can be specified:

T table only

I all indexes

I <index number> only specified index

* both table and indexes

Example I1,I2 only index 1 and 2

T only for table

Group

Description This field identifies the owner of the table. group should be specified.

table/index optimization

Description Specific flags related to indexes and tables can be specified. When specified on a “T” object entry, it defines the default for all indexes. The following octal values can be used to set the flags for a specific index or table:

00100 initial technique is nested

00200 initial technique is iterative

00400 initial technique is filter

01000 Initial technique is keystart

02000 Lock table for conversion

Optimizations are more fully explained in Chapter 6.

Example 00200

Use the iterative technique

storage parameters



storage parameters

Description These are defined by the specific database driver implementation and often map to table and index creation options available in the host RDBMS. The following Informix storage parameters are defined: INITIAL <n> Specifies the size of the initial extent to be created when creating the table. The variable n specifies the size in KB. The minimum size is 16 pages. The initial extent size is used when creating the table and cannot be changed later. If no size is specified, Informix uses 16 pages as default. NEXT <n> Specifies the size of next extent to be allocated for the table. The variable n specifies the size in KB. This is used while creating a table. If no size is specified, Informix uses 16 pages as default. LOCK <page/row> The lock mode used while accessing the table. It can be either page or row. This is used while creating the table. If the lock mode is not specified, tables are created with row level locking. DBSPACE This is the name of the dbspace where the table or index should be created. If no name is specified for the table, the table is created in the dbspace containing the database. If no name is specified for the index, the index is created in the dbspace containing the table. TEMP Specifies that the table is temporary. A temporary table only exists until the end of the session. Since Informix does not grant permissions on temporary tables, temporary tables cannot be created as group tables. Creating group tables involves granting table permissions to group roles. CLUSTERED Specifies that the primary index of the table will be clustered.

HOLD Specifies that the table should use hold cursors when accessed. Hold cursors are not closed at the end of the transaction. The next record can be fetched without



storage parameters opening the cursor if the request comes within the time frame of refresh time. Do not use hold cursors if the refresh time is zero.

<Fragmentation strategy> The fragmentation strategy can be specified for both tables and indexes. . The FRAGMENT clause of the CREATE TABLE statement can be specified within the square brackets ([ ]). Some example fragmentation strategies are: [fragmentation strategy in Informix format] [round robin in erpdbs, erpdbs1] [expression t_code < 50 in erpdbs, t_code > 50 in erpdbs1] A FRAGMENT clause can appear only as the last parameter in the storage file. Any string between square brackets is considered to be part of the FRAGMENT clause. If the closing square bracket is omitted, the string from the opening square bracket to the end of the line will be part of the FRAGMENT clause. If the fragmentation strategy is not specified for the index, Informix uses the fragmentation strategy of the table by default.

Example INITIAL 32

Storage parameter file performance tips Some more suggestions that can be used to improve performance.

• It is recommended that all databases be created in a non-root dbspace. For tables in the database, if DBSPACE is not specified in the storage file, the table will be created in the dbspace containing the database. Alternatively, a table can be put in any other dbspace by including the following entry in the inf_storage_param file:

*:*:T:DBSPACE dbspace_name

Important: You are strongly recommended not to create any tables in the root dbspace.

• The row lock mode should be used for better concurrency. This is also the default used by driver, if none is specified. The page lock mode is suitable only for tables that are mostly read-only and are rarely modified. After a table is created, to change the lock mode use ALTER TABLE command.



• If the initial extent size and the next extent size are not specified, Informix uses a default size of 16 pages. This may be too small for large tables, or tables that will grow significantly in the future. In such cases, the sizes should be estimated and the entry "INITIAL n NEXT m" should be created. To change the initial and next extent sizes of a table already created, you have two options: drop the table and recreate it, or use the ALTER TABLE command. Alter table will change the next extent size only. It will not reduce the current number of extents.

• A default table and index entry must be present that covers all users, tables, and company numbers. It is strongly recommended that the default table entry uses single hash optimization and the row lock mode. It is also recommended to specify sufficiently large initial and next extent sizes in the default table and index entries. The following is an example of a default table and index specification entry covering all users, tables, and company numbers. *:*:T:INITIAL 512 NEXT 512 *:*:I:

• Note that a temporary table cannot be a group table.

Conversion from previous porting sets The ERP LN 6.1 Convert Table and Index Repository (ttdba0540m000) session converts the storage file to the storage parameter file and the driver parameter file. Use this session to convert the storage file.


Appendix C The Informix Maintain Program inf_maint6.2 C

This chapter describes how to use the inf_maint6.2 program. The inf_maint6.2 program is called by the DBA module to make changes to the Informix users and groups files. It is recommended that you use the DBA module instead of invoking inf_maint6.2 directly because the Infor ES users and groups files are not updated by inf_maint6.2. The following topics are discussed in this appendix:

• Using inf_maint6.2 on UNIX • Using inf_maint6.2 on Windows • Options for both UNIX and Windows • Differences between inf_maint6.2 on UNIX and on Windows

Using inf_maint6.2 on UNIX This section describes the actions that can be performed using the inf_maint6.2 program on a UNIX platform. To invoke inf_maint6.2 from outside the DBA module, use the following command:

inf_maint6.2 option1 option2 option3

Where option1, option2, and option3 represent options described below. You can use as many options as you need.

The following lists options that you will need for specified needs:

• Add a user:

[-n] -a Infor ES user -m Informix user -p User password -G group {-F -c InformixAdminUser -i InformixAdminPassword | -P Group Password}

• Change user’s password:

[-n] -r Infor ES user -m Informix user -p User password

• Drop a user:

-d Infor ES user -G Group -P Group Password

or

-n -d Informix user -G Group { -P Group Password | -F -c InformixAdminUser -i informixAdminPassword }

• Add a group:

[-n] -A Group -P Group Password { -F -c InformixAdminUser -i InformixAdminPassword }

• Change group’s password:



[-n] -R Group -P Group Password

• Drop a group:

[-n] -D group {-P group password | -F -c InformixAdminUser -i InformixAdminPassword}

• Check password:

-h -m Informix user -p password -G group

• Batch mode:

-b batchFile

• Redirect errors to error file:

-q errorFile

• Print Usage:

-U

Using inf_maint.exe on Windows This section describes the actions that can be performed using the inf_maint program on a Windows platform. To invoke inf_maint from outside the DBA module, use the following command:

inf_maint.exe option1 option2 option3

Where option1, option2, and option3 represent options described below. You can use as many options as you need. The following lists options that you will need for specified needs.

• Add a user:

-a Infor ES user -m Informix user -p User password -G group {-F -c InformixAdminUser -i InformixAdminPassword | -P Group Password}

• Change user’s password:

-r Infor ES User -m Informix user [-F] -p User New password -o User current Password

• Change user password by Windows administrator:

[–F] –r Infor ES user –m Informix user –p new password

• Drop a user:

-d Informix user -G Group {-F -c InformixAdminUser -i InformixAdminPassword | -P Group Password}

• Add a group:

-A group -P Group Password { -F -c InformixAdminUser -i InformixAdminPassword }

• Change group’s password by a normal user:



-R Group [-F] -P Group New Password -o Group Current Password

• Change group’s password by a Windows administrator:

-R Group [-F] -P Group New Password

• Drop a group:

-D group {-P group password | -F -c InformixAdminUser -i InformixAdminPassword}

• Check password:

-h -m Informix user -p password -G group

• Batch mode:

-b batchFile

• Redirect errors to error file:

-q errorFile

• Print usage:

-U

Options for both UNIX and Windows There are several additional inf_maint6.2 options. This section describes these options.

• Force in DBMS A new option -F (force In DBMS) has been introduced. When this option is used, the user, if not already present, is automatically created in the database. And similarly, the Informix user is removed from the database. Connect and resource privileges are granted and revoked automatically.

If the -F option is not specified, the inf_maint6.2 program expects the user or group to be added to have connect and resource privileges. Similarly, the connect and resource privileges are not revoked for the user or group being dropped when this option is not specified.

The Informix administrator logon and password is required to use the -F option. The administrator need not be user informix. Any DBA of the database can use the –F option..

For example, if you add the group tools using the following command:

inf_maint6.2 -F -A tools -P tools -c informix -i informixpassword

Then the inf_maint6.2 utility will do the following:

grant DBA to "tools"; create role "toolsr";

For example, if you add user baan01 to the group tools using the following command:

inf_maint6.2 -F -a "baan01" -m "baan01" -P tools -G tools -c informix -i informixpassword



Then the inf_maint6.2 utility will do the following:

• Add NT user baan01 to the local machine if user baan01 does not exist (on Windows only, on UNIX this user should be created before calling inf_maint6.2)

• grant resource to “baan01”; • grant “toolsr” to “baan01”;

• Retain Infor ES files Use the -n option to avoid updating Infor ES files inf_users and inf_groups. For example, the following command: inf_maint6.2 -n -D tools -P tools

Drops role toolsr but does not remove the entry in inf_groups file.

• Generate error file Use the -q option to redirect error messages to an error file. The error file is created in the current working directory.

• Create batch commands Use the -b option to store a batch of commands in a text file and pass this text file path to inf_maint6.2 program using the -b option. For example: inf_maint6.2 -b /users/baan01/ batch_cmds -q errorfile

The batch_cmds batch file could look like this:

-A user1 -P user1 -G baan -P YcG/G_D)Y0gv{PhJIF\M9IHQ7oqhvr^l -F -c informix -i LOIC@Nd'Z*~x_aysaruL2W# -A user2 -P user2 -G baan -P YcG/G_D)Y0gv{PhJIF\M9IHQ7oqhvr^l -F -c informix -i LOIC@Nd'Z*~x_aysaruL2W# -A user3 -P user4 -G baan -P YcG/G_D)Y0gv{PhJIF\M9IHQ7oqhvr^l -F -c informix -i LOIC@Nd'Z*~x_aysaruL2W#

Passwords in the batch file should always be encrypted. Use encrypt6.2 to encrypt passwords.

Differences between inf_maint6.2 on UNIX and on Windows This sections lists the difference in functionality between inf_maint6.2 on UNIX and inf_maint6.2 on Windows.

• The Windows logon is created automatically.

You can use the -F option with add user or add group commands to add the Windows logon automatically. You have to be logged on as an administrator (you need to belong to the NT administration group) to create Windows logons. The user created will be added to the default group Users automatically.

NT login shall not be dropped with -F option.

Dropping a user with the -F option will NOT drop the NT login. inf_maint6.2 never drops a Windows users.

• inf_maint6.2 changes the Windows password automatically.



When the -F option is used in change password commands, the Windows password is changed automatically by inf_maint6.2. On a UNIX platform, the password has to be first changed manually before inf_maint6.2 is run. Inf_maint6.2 changes the Infor ES files only.

inf_maint6.2 can create Windows users or groups on the local machine, the domain, the primary domain controller, and the backup domain controller. inf_maint6.2 can be used on both the Windows server and the Windows workstations.

• Log-on-locally privilege required

When users are created on a Windows server, they do not have the privilege to log on locally. This privilege is required for the Infor ES Informix driver to login to Informix. When inf_maint6.2 creates a Windows user, it checks whether a group called baan-informix exists. If it doesn’t exist, it creates this group and grants the log-on-locally privilege to this group. It then adds the newly added user to this group. The group baan-informix is required to make sure that all Infor ES users have log-on-locally privileges. In the future, if new privileges need to be granted to all the Infor ES users, then they could be granted to group baan-informix instead of granting the privileges individually to each Infor ES user.

On a Windows workstation, all Windows users have the log-on-locally privilege by default. The group informix-admin is not created on the Windows workstation because it is not needed.

The group informix-admin is not created on UNIX installations.

• Infor ES files inf_users and inf_groups cannot be updated by the inf_maint6.2 program on Windows as they can be on UNIX. This functionality has been replaced by the database independent DBA module of Infor ES.


Appendix D Format of Files used by the Informix Driver D

This appendix describes format of the following files used by Informix driver:

• The inf_users file • The inf_groups file • The tabledef6.2 file

The inf_users file The inf_users file is part of the security mechanism used by the Informix driver. This file is more commonly referred to as user file. It can be found in the Windows directory %BSE%\lib\informix or the UNIX directory $BSE/lib/informix. Always use the DBA module to maintain the inf_users file.

The user file contains information about all Infor ES users on the system who use the Informix driver. Each line in this file consists of four fields, which are separated by a colon (:).

<Infor ES User>:<Informix User>:<User Password>:<User Group>

The fields are explained below:

• Infor ES user This is the name by which the user is known to Infor ES. This is the value of the environment variable USER.

• Informix user This is the database user name. The name of the database is same as the name of the group to which the user belongs. This should be a valid UNIX user name. This can be different from the Infor ES user name. A user can also use the logon of a different UNIX user to access the Informix database. For example, if UNIX user mary wants to access Infor ES, he can either use his logon name to access the Informix database, or another UNIX logon name, for example, edward.

• User password This is the UNIX password of the Informix user. The password is stored in encrypted form. The user password is used when the user tries to connect to the database environment.

• User group This is the group to which a user belongs. This should be a valid UNIX logon name.

A sample file is shown below.

edward:edward:MyNO?%H$h9/Bnc9yb/@2`(llU=8:4Wbj:finance mary:mary:\`$YW/k\RfbL^<qhM<vxk3Dhm2ayV^]7:finance john:john:>9~[{'EOu^UA,)[(vt\MTw3y=AhTdPgK:finance bill:bill:N$x'1$xHoY+^5hm[.:7JQx-;B(=>@,^/:Baan robert:robert:KqJeZwD@PC6d3Z+KojKb,;/utq%0nJa+:Baan



In this example Infor ES users edward, mary, and john are in the group named finance. Infor ES users bill and robert are in group Baan.

The inf_groups file The inf_groups file is part of the security mechanism used by the Informix driver. This file is more commonly referred to as the group file. It can be found in the Windows directory %BSE%\lib\informix or the UNIX directory $BSE/lib/informix. Always use the DBA module to modify the group file.

The group file contains information about all group databases accessed by the Informix driver. Each line in this file is made up of two fields, which are separated by a colon (:).

<Group Name>:<Group Password>

The fields are listed below:

• Group Name Name of the group. This should be a valid UNIX logon name.

• Group Password This is the UNIX password assigned to the group logon name. The password is in encrypted form. This is used when a user uses the group logon to connect to the database environment.

A sample group file is shown below.

finance:5tT'"I*/qmn;7cORtYP:8*Hksop*9`g6 trade:ESMQ3Ti(khD`@@a+,y"75+B5&NEno<f"

In this example the group file contains two groups, finance and trade.

The tabledef6.2 file Since a system can have multiple database systems, a table can exist in any one of the systems (for example, Informix or Oracle). The tabledef6.2 file identifies the type of the driver(s) to be used for accessing a table along with other driver parameters. It can be found in the Windows directory %BSE%\lib or the UNIX directory $BSE/lib.

Each line in this file consists of four fields separated by colons (:). The format of the line is as follows.

[{user}]<table_name>:<customer number>:<driver specification>:<audit trail>

The fields are listed below:

• user The same convention is followed as explained for user list, which is defined in the section “Parameter file field descriptions” in Appendix B.



• table name The same convention is followed as explained for table/module specification, which is defined in the section “Parameter file field descriptions” in Appendix B.

• customer number The same convention is followed as explained for company number, which is defined in the section “Parameter file field descriptions” in Appendix B.

• driver specification The database which is used for the table, for example, Oracle or Informix. Apart from specifying the driver, various parameters can also be specified for the corresponding driver.

For the Informix driver, any Informix or Infor ES environment variables can be specified.

A table can be simultaneously created in multiple databases, for example, Oracle and Informix. In this case you can specify a list of drivers and remote sites, separated by an ampersand (&).

The following is a sample tabledef6.2.

tttxt:*:oracle(ORACLE_HOME=/usr1/database/oracle,ORACLE_SID=D1):N ttadv:*:informix(INFORMIXDIR=/usr1/informix,INFORMIXSERVER=dserver, INFPROF=1):N tdsls:*:oracle&informix(INFORMIXDIR=/usr1/informix, INFORMIXSERVER=dserver) *:*:oracle:Y

The example file above specifies that the tables tttxt are in the Oracle database while ttadv are in the Informix database. The tdsls tables are created in Oracle as well as in Informix. All other tables are created in Oracle.

The update statistics files It is possible to define your own UPDATE STATISTICS commands per table. This feature can be used to overload automatic update statistics commands. The definition is done in a statistic file. A statistic file contains regular Informix UPDATE STATISTICS commands.

These files are stored in UNIX directory $BSE/lib/Informix/statistics or Windows directory %BSE%\lib\informix\statistics.

Keep in mind there will be no syntax check when this is used. You need to use correct Informix SQL syntax.

Filename: table without company number (for example, ttaad050)

Fileformat: <comp>:<command>

company number




Example 000,999 companies 000 and 999

* all companies

Command


Example update statistics low for table %t

The following is a sample for table ttaad050.

# Example update statistics file for ttaad050 000,500:update statistics for table %t *:update statistics high for table %t (t_syst)


Appendix E Informix Client/Server Connections E

With Informix, client applications and the database server communicate through shared memory connections and network connections. This appendix describes these connections.

Shared memory connections Shared memory connections are used when the client application and the database server are on the same computer. The application can make only one shared memory connection at a time. In a UNIX installation, if the user needs concurrent connections, the Informix administrator must change the connection type, as specified in the nettype field of the sqlhosts file, from a shared memory connection to a network connection. In Windows, this information is contained in the registry and is entered through the Informix Setnet32 utility.

An application cannot make multiple connections when shared memory communication (IPC) is used. The Informix driver supports multiple connections; hence it is advisable not to use shared memory connections.

Network connections Network connections are used when the client resides on one computer and the database server resides on another. Network connections can also be used when the client application and the database server are on the same computer. Consult the Informix manual for detailed information.


Appendix F Miscellaneous F

Informix Limitations This section describes some limitations in Informix and how they affect the Informix driver behavior.

• In Oracle, every query read is consistent. That is, a query will see only the committed data of all transactions at the start of a query plus the changes made in the current transaction. The query does not see uncommitted changes made by other transactions. Even if other transactions commit after the start of the query, the new data is not seen by the query. The query gets a consistent snapshot of the database. In addition, a read-only query never blocks on locked records, so a read-only query never generates a record locked error.

• In Informix, read-only queries cannot read locked records unless the dirty read isolation mode is used. In dirty read isolation, a query sees the uncommitted changes of other transactions, which may not be desirable.

• By default, the Informix driver uses dirty read isolation. With a read request without a lock, dirty read can return a row that is being updated or inserted and is not yet committed. If the row is being updated, dirty read returns updated values and not the original values. Also, if a row is deleted, dirty read will skip the deleted row even if the delete is not committed. This can lead to problems.

Suppose the following processes access a table with five rows, row1, row2, row3, row4, and row5.

• Process 1 deletes row2. • Process 2 reads row1 (read first) • Process 2 does read next

Now, the dirty read skips the deleted row and returns row3. If process 2 issues a read for update instead of an ordinary read, it gets the expected locked error.

Suppose the following processes access the same table:

• Process 1 reads a row without lock. • Process 2 updates the same row. It does not do a commit.

In this case dirty read returns updated values, so that process 1 gets the changed row even though process 2 has not yet done a commit.

• Many RDBMSs, for example, Oracle, support read consistent transactions. In a read consistent transaction, all queries see the data as a snapshot taken at the start of the transaction. This snapshot consists of changes made by all committed transactions up to that time. If multiple



queries are done on the same object, they will all see the same data even though other transactions may have changed it and done a commit after the transaction started.

Because Informix does not support read consistent transactions, the 3GL command SET TRANSACTION READONLY has no effect on the subsequent query.

• After reading a row for update, if the cursor is closed without doing the update, the lock is released. This results in inconsistent behavior as other processes can now lock the row even though the first process has successfully read the row for update. To prevent this, the Informix driver does a dummy update on the row that it locks. It updates the rows with the same value. The update promotes the lock to exclusive, and the lock is not released even when the cursor is closed.

• Unlike other RDBMSs, data definition statements such as create table/index or drop table/index are not single transactions in Informix, so they need to be explicitly committed. To present a consistent interface to applications, the Informix driver does commits internally after executing these statements.

• If a table is to be dropped, all users who may access that table should exit the application virtual machine while one user drops the table. This is not mandatory but is recommended for the following reasons. • For a prepared statement, Informix always keeps a parse lock on the table. As long as the

prepared statement exists, the table cannot be dropped. In a multi-user environment, many drivers may have prepared statements on a table, so dropping the table will fail.

• Once the Informix driver has prepared a statement, it is reused without being prepared again. This increases performance but will result in errors if the table is dropped by another user. After one process prepares a statement, if a second process drops the table and recreates the same table, the prepared statement for the first process becomes invalid and will return an error when the driver tries to reuse it. In this case, the $BSE/log/log.informix file will contain the cause of the error.

Performance tips and guidelines This section contains tuning tips for the Informix driver.

• For good performance on UNIX, the database should be created on a raw device and must be NON-ANSI.

• Set dbsinit to 01 to improve concurrency by using optimistic lookup approach. • Physical and logical log files must be on different file systems. • Table extents

Check your current number of table extents frequently. A high number of table extents have a negative impact to your performance. If you current number of table extents are > 8 you should adjust your storage settings and recreate the table. Following SQL statement can be used to check your current number of table extents.



SELECT tabname, dbsname, count(*) number FROM sysextents WHERE dbsname = ‘<baan database>’ GROUP BY tabname, dbsname HAVING count(*) > 8

• Clustering Clustering is a method for arranging the rows of a table so the physical order on the disk agrees with the sequence of entries in the index. If a table is usually accessed on the primary index, it is advisable to cluster the table. Note that only the primary index of a table in Infor ES can be clustered.

• Fragmentation Fragmentation allows you to improve the performance of decision-support queries and to reduce the disk I/O contention for table data. INITIAL and NEXT extents are used in inf_storage_param to provide values for the extent size during the CREATE TABLE statement. If they are used as part of a fragmentation scheme, it is recommended that the values of INITIAL and NEXT extent should be appropriately set, depending upon the values used while creating the table.

For example, originally the non-fragmented table had the following values:

tiitm001:*:T:INITIAL 81975 NEXT 20490 DBSPACE erpdbs

After using the fragmentation strategy the values change. If the dbspace is fragmented into two dbspaces (here it is assumed that the two dbspaces are the same size), then the extent size values are divided in half as follows:

tiitm001:500:T:INITIAL 40987 NEXT 10245 LOCK row \ [ round robin in erpdbs1, erpdbs2 ]

Or, if the dbspace is fragmented into three dbspaces (assuming that they are the same size), then the extent size values are divided in thirds as shown as follows.

tiitm001:500:T:INITIAL 27325 NEXT 6830 LOCK row \ [round robin in erpdbs1, erpdbs2, erpdbs3]

• Set OPT_GOAL to 0 in Informix onconfig file to use FIRST_ROW optimization. • Set OPTCOMPIND to 2 in your Informix onconfig file. • It is reported, sometimes better overall performance was seen when db_resource variable

inf_use_hints:0 is set.


Appendix G Database Connections in Combo Mode G

Important: Combo mode is not supported for Baan IV.

To use combo mode with Informix databases, a 32 bit Informix Connect version is required. Various InformixConnect versions are available on the IBM Web site.

Note: An Informix Connect version is identified by a version number, followed by a suffix that indicates the operating system and the number of bits, such as the following:

Suffix Description

UCx 32 bit version for UNIX in general

HCx 32 bit version for HP-UX RISC platforms. Do not use UCx for HP-UX RISC

TCx 32 bit version for Windows platforms

To prevent conflicts with Informix database server files, you must install Informix Connect into a new directory.

If a 32 bit Informix database server is used, Informix Connect is probably already installed.

To configure database connections in combo mode

UNIX platforms On UNIX platforms, to configure database connections in combo mode, complete the following steps:

1 You need a valid sqlhosts file in the <Informix Connect>/etc directory. For details about the Informix sqlhosts file, refer to the Informix documentation.

2 Ensure the bshell can find shared Informix Connect libraries; therefore, the shared library path must be extended in the $BSE/lib/bse_vars file.

Dependent on the UNIX platform, different variable names are used to define this shared library path, such as the following:

UNIX platform Variable name



HP-UX, SHLIB_PATH

AIX LIBPATH

HP-UX Itanium, SOLARIS and LINUX

LD_LIBRARY_PATH

You must extend the shared library path with the following:

<Informix Connect directory>/lib:<Informix Connect directory>/lib/esql

Note: use the absolute path for <Informix Connect directory>.

For example (AIX):

LIBPATH=${LIBPATH}:/usr/iconnect/lib:/usr/iconnect/lib/esql

3 Modify the $BSE/lib/tabledef6.2 file. You must set the INFORMIXDIR environment variable to the Informix Connect directory, such as the following:

*:*:informix(INFORMIXDIR=/usr/iconnect,INFORMIXSERVER=erpln,DB_LOCALE=en_US.819,CLIENT_LOCALE=en_US.819):N

4 After combo mode is enabled, start the Database Definitions (ttaad4510m000) session and check the database parameters. Ensure INFORMIXDIR is set to the Informix Connect directory, such as the following :

INFORMIXDIR=/usr/iconnect,INFORMIXSERVER=erpln,DB_LOCALE=en_US.819,CLIENT_LOCALE=en_US.819

Windows platforms On Windows platforms, no configuration is required, because Informix is, by default, installed in combo mode.

Technical Reference Guide for Informix Database Driverbaansupport.com/docs/erpln/U8781F US.pdf ·...

Documents

Transcript of Technical Reference Guide for Informix Database Driverbaansupport.com/docs/erpln/U8781F US.pdf ·...