BAAN IVc. Technical Reference Manual for DB2 Database Driver

Transcription

1 BAAN IVc Technical Reference Manual for DB2 Database Driver

2 A publication of: Baan Development B.V. P.O.Box AC Barneveld The Netherlands Printed in the Netherlands Baan Development B.V All rights reserved. The information in this document is subject to change without notice. No part of this document may be reproduced, stored or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Baan Development B.V. Baan Development B.V. assumes no liability for any damages incurred, directly or indirectly, from any errors, omissions or discrepancies between the software and the information contained in this document. Document Information Code: U7184D US Group: User Documentation Edition: D Date: December, 2000

3 Table of contents 1 Introduction 1-1 The BAAN IV architecture 1-2 Display tier 1-3 Application tier 1-3 Database tier 1-4 Data flow in the BAAN IV architecture 1-4 BAAN IV hardware configurations 1-6 Level 1 and Level 2 database drivers BAAN IV database organization 2-1 BAAN IV data dictionary 2-1 Table naming convention 2-2 Column naming convention 2-3 Index naming convention 2-4 Data type mapping 2-5 Additional constraints Database driver internal processing 3-1 Data integrity 3-1 Referential integrity 3-1 To buffer data 3-1 Database driver SQL processing 3-2 Call level interface 3-2 SQL processing 3-3 To set driver behavior 3-4 Driver resources 3-4 Environment variables 3-5 Storage file Database security 4-1 Security 4-1 Groups 4-2 Object security 4-3 Authentication 4-4 DBA module 4-5 Utility programs db2_admin6.1 and db2(v5)_maint The User Administration menu 4-7 The User Information menu 4-9 i

4 Table of contents db2(v5)_maint6.1 tool Database driver profiling and statistics 5-1 To profile 5-1 Level 1 profiling example 5-2 Level 2 profiling example 5-3 To gather statistics 5-4 To troubleshoot 5-6 To log database driver trace information 5-6 To log errors Database driver configuration and tuning 6-1 Cursor management 6-1 Level 1 mode 6-1 Level 2 mode 6-2 db2_max_open_handles 6-2 db2_retained_cursors 6-2 Array interface 6-3 Index optimization 6-4 Indexes that accept duplicate values 6-6 Hash column naming convention 6-6 Size of hash columns 6-6 To specify index optimization 6-7 Fetch optimization 6-7 To cache rows 6-9 To tune query 6-9 Concatenated expressions 6-10 Optimistic and pessimistic reference checks 6-12 Locking behavior 6-12 High-level lock retries DB2 configuration and tuning 7-1 To tune DB2 7-1 Environment variables 7-1 To tune a database manager configuration 7-2 To tune a database configuration 7-3 Tuning to load data faster 7-6 To tune in Level 2 mode 7-7 Disk I/O configuration and data placement 7-8 To tune AIX To migrate between Level 1 and Level 2 databases 8-1 ii

5 Table of contents 9 Appendix A: Driver resources and environment variables 9-1 Summary of driver resources and environment variables 9-1 Detailed description of driver resources and environment variables 9-4 Generic driver resources 9-4 DB2 driver specific resources Appendix B: Storage file format and configuration options 10-1 Storage file format 10-1 Storage file field descriptions 10-1 iii

6 Table of contents iv

7 About this document This document provides technical reference information about the BAAN IVc database driver for DB2 for both UNIX and Windows NT operating systems. This document is intended for those who wish to configure or customize the BAAN IVc database driver for DB2. No detailed knowledge is required to use this document. However, understanding the contents is easier if you are familiar with the basic functions of UNIX, Windows NT, DB2, and database technology. The procedure to install the DB2 and BAAN IVc software is described in the Installation Guide for BAAN IVc on UNIX (U7016F US), DB2 Installation Guide for BAAn IV on UNIX (U7030D US), and DB2 Installation Guide for BAAN IV on NT (U7181B US ). This document describes the BAAN IV database driver that forms the interface between the BAAN IV application server layer and DB2. The formal name for this database driver is the BAAN IV database driver for DB2. For simplicity, in this document, the database driver is referred to as the BAAN IV DB2 driver. The document is divided into the following chapters and appendices: Chapter 1, Introduction, provides an overview of the BAAN IV database driver architecture and how the database driver fits into the BAAN IV system. Chapter 2, BAAN IV database organization, describes the BAAN IV database organization and details the naming conventions used for data and objects in the DB2 database. Chapter 3, Database driver internal processing, describes some of the internal features of the BAAN IV DB2 driver. Chapter 4, Database security, describes several aspects of database security provided by the BAAN IV DB2 driver. Chapter 5, Database driver profiling statistica, describes the facilities to profile and gather statistics about DB2 driver performance. Chapter 6, Database driver configuration and tuning, details the configuration and tuning options for the BAAN IV DB2 driver. Chapter 7, DB2 configuration and tuning, details the configuration and tuning options for the DB2 database server. v

8 Introduction Chapter 8, To migrate between Level 1 and Level 2 database, explains how to migrate the database between the Level 1 and Level 2 modes. Appendix A supplies information about the variables that can be configured for the database driver. Appendix B contains information about the file format of the storage file and the driver configuration options specific to the BAAN IV DB2 driver. vi

9 1 Introduction The database driver plays an important role in Baan s commitment to an open systems client/server architecture. Because the BAAN IV architecture includes both the BAAN IV software and a third-party relational database management system (RDBMS), the driver is required to provide a seamless interface between the BAAN IV software and the various RDBMS products. The database driver enables the majority of the BAAN IV processing to be independent of the RDBMS. This chapter provides an overview of the database driver and how the driver fits into the BAAN IV architecture. This chapter covers the following topics: The BAAN IV architecture. Data flow through the BAAN IV architecture. BAAN IV hardware configurations. Level 1 and Level 2 database drivers 1-1

10 Introduction The BAAN IV architecture BAAN IV supports a three-tier architecture that consists 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 BAAN IV application virtual machine and the application objects. The database tier includes the BAAN IV database driver and a third-party RDBMS product that acts as the database server (see Figure 1). The emphasis of this document is the BAAN IV database driver. The database driver is the interface between the BAAN IV applications and the RDBMS server. The database driver translates database requests from the BAAN IV application virtual machine to RDBMS-specific SQL requests that BAAN IV sends to the database server. After the database server retrieves the requested information, the database driver then returns the data to the BAAN IV application virtual machine. Display Driver Display Tier Application Virtual Machine (bshell) Application Objects Application Tier Database Driver Database Server (RDBMS) Database Tier Figure 1 BAAN IV three-tier architecture 1-2

11 Introduction Display tier The display tier consists of the display driver which includes the BAAN IV user interface for Microsoft Windows (BW) and/or Internet browsers (BI). The display driver facilitates the communication between the user and the application tier. Data input from the user through BW or BI is relayed to the BAAN IV application virtual machine. Data returned from the BAAN IV application virtual machine is displayed to the user in graphical form by the display driver. Application tier The application tier includes both the application objects and the Baan IV application virtual machine. Together, the application objects and the application virtual machine provide much of the functionality of BAAN IV. The application objects include the compiled BAAN IV applications and the data dictionary. The Baan IV applications provide the functionality required to implement the BAAN IV Enterprise Resource Planning (ERP) system. These applications are written in Baan 3GL or Baan 4GL, which are programming languages supported by BAAN Tools. 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 BAAN IV. The BAAN IV application virtual machine performs the following tasks: Schedules and runs the application objects. Sends and receives information to and from the display server. Initiates an instance of the database driver as required for communication with the database server. A running database driver can support multiple connections to a single RDBMS instance. If a BAAN IV 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 the application virtual machine must communicate. The BAAN IV application virtual machine has traditionally been called the BAAN IV shell, or more often, the bshell. Throughout the remainder of this document, BAAN IV shell is referred to as the BAAN IV application virtual machine, or simply the application virtual machine. 1-3

12 Introduction Database tier The database tier consists of the BAAN IV database driver and the database server. The database driver provides a common interface between the BAAN IV application virtual machine and the database server. Communication between the application virtual machine and the database driver is the same for each RDBMS product used as the database server. Each of the RDBMS products that BAAN IV supports contains a database driver. Communication between the database driver and the database server is dependent on the RDBMS that is used. The database driver communicates with the RDBMS with the structured query language (SQL) statements and the native application programming interface (API) of the RDBMS. The database server consists of one of five third party RDBMS products: Oracle, Informix, Sybase, DB2, or Microsoft SQL Server. All BAAN IV application data is stored in a relational database managed by an RDBMS. You can have multiple RDBMS products in one BAAN IV installation, with some data on one database server and other data on another. Data flow in the BAAN IV architecture Note that the database driver provides an interface between the BAAN IV application virtual machine and the specific RDBMS server that you use. The flow of data through the system is described later in this section. If a user performs an operation at a GUI workstation, the display server interprets the input and sends the information to the BAAN IV application virtual machine. Based on the information the machine receives, the appropriate application object runs. If a running application object requires information 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 with BAAN IV SQL, an RDBMS-independent SQL language. If the application virtual machine processes a database query from an application object, the machine first determines whether a running database driver is available to process the query. If no database driver is running, or if the running database driver instances communicate with a database server other than the one that stores the required data, the application virtual machine starts a new instance of the database driver. The application virtual machine parses the BAAN IV SQL database query received 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. 1-4

13 Introduction The database driver translates the database query to an appropriate databasespecific query with SQL statements that are compatible with the RDBMS used. Each database driver uses the design of the particular RDBMS that the driver 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. After the RDBMS has processed the query, the RDBMS returns the data to the database driver. Any error conditions are detected and handled by the database driver. The database driver then returns the data and status information to the application virtual machine, where the machine provides the information to the application that requested the data. The application virtual machine can also send a message to the display server, which displays an appropriate message on the user s workstation. 1-5

14 Introduction BAAN IV hardware configurations Several hardware configurations are supported for a BAAN IV implementation. These configurations include stand-alone mode and a number of variations of client/server mode. Available hardware, data storage requirements, and performance expectations determine the most appropriate hardware configuration. Stand-alone mode refers to a configuration where all components of the BAAN IV architecture run on a single machine. In stand-alone mode, an end user can work from the host machine or from a thin client machine, such as an X- Terminal running BI (see Figure 2). Display Driver Application Virtual Machine (bshell) Application Objects Database Driver Database Server (RDBMS) Figure 2 Stand-alone mode configuration In a client/server configuration, the components of the BAAN IV architecture are distributed over two or more machines. Several client/server configurations exist. The most common configurations are described here. 1-6

15 Introduction The simplest client/server configuration is sometimes thought of as a variation of the stand-alone mode. In this simple 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 are started for each user (see Figure 3). Display Driver Display Driver Application Virtual Machine (bshell) Application Objects Application Virtual Machine (bshell) Database Driver Database Driver Database Server (RDBMS) Figure 3 Client/Server configuration 1 If 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 is placed on one server, while the database driver and the 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 are started for each user. All users have access to the same application objects and database servers. 1-7

16 Introduction This following figure (see Figure 4) illustrates the client/server configuration. This configuration uses the BAAN IV method of client/server access between the application virtual machine and the database server. Display Driver Display Driver Application Virtual Machine (bshell) Application Objects Application Virtual Machine (bshell) Database Driver Database Driver Database Server (RDBMS) Figure 4 Client/Server configuration 2 An alternative configuration with two servers is to place the applications and the database driver on one server and the database server on another. The user workstations are again linked to the machine with the application virtual machine. Again, an instance of the application virtual machine and at least one instance of the database driver are started for each user. All users have access to the same application objects and database servers. 1-8

17 Introduction The following figure (see Figure 5) illustrates the client/server configuration. This configuration uses the RDBMS s ability to provide client/server access. Display Driver Display Driver Application Virtual Machine (bshell) Application Objects Application Virtual Machine (bshell) Database Driver Database Driver Database Server (RDBMS) Figure 5 Client/Server configuration 3 Several additional configurations of client/server systems also exist, which include dividing the application logic among multiple servers or using multiple servers for distributing the database. Level 1 and Level 2 database drivers BAAN IVc database drivers can communicate with the RDBMS server in two modes: Level 1 and Level 2. With these two modes, several methods to process BAAN IVc SQL queries and store data in the database are used. 1-9

18 Introduction With a Level 1 database driver, queries to the database only process a single row of a single table in the database at a time. When a complex query requires data from multiple tables, the query must be broken into multiple single table/single row queries. The database driver then joins the combined data before returning the results to the application. Application programs designed for a Level 1 database driver usually access data one record at a time. This type of access maps well to the Level 1 single table/single row queries. To provide a good system performance for single table/single row queries, an extra column called a hash column is created for each index defined in the table. The use of the hash column is called hash optimization. Hash optimization is used to simplify the SQL statements sent to the database server so that the RDBMS optimizer can process the statements more efficiently. A Level 2 database driver sends more complex queries to the database server, which requires the RDBMS to do more of the work. An application program written for a Level 2 database driver typically uses set-oriented database access. The Level 2 database driver can process these more-complex queries in a more efficient manner than a Level 1 driver can. In addition, a Level 2 driver does not use the hash columns that are added when using a Level 1 driver with hash optimization, therefore less space is required to store the database. A Level 2 database driver typically improves system performance when the application programs are designed with set-oriented database access. If an application is written with record-at-a-time database access, the database queries are very simple. Applications with complex database queries often show performance gains when run with a Level 2 driver, but record-at-a-time applications can perform poorly with a Level 2 driver because there is no hash optimization. Most BAAN IV applications are record oriented, and therefore do not gain much performance from a level 2 database. Many batch applications, however, benefit from a Level 2 database. You can migrate between a Level 1 and a Level 2 database driver using the BAAN IVc utilities bdbpre and bdbpost. The process requires that you change all database tables to either add or remove the hash columns. While the process to change the database tables is not a difficult operation, the process can be quite time consuming, depending on the quantity of data that must be converted. This procedure is described in Chapter 8, To migrate between Level 1 and Level 2 databases. 1-10

19 2 BAAN IV database organization All of the application data used by BAAN IV is stored in database tables in the RDBMS. To keep the majority of the BAAN IV process independent of the RDBMS, BAAN IV uses a data dictionary. The data dictionary includes domain, schema, and referential integrity information, which is stored in a databaseindependent manner. Because many tables are required, a convention is used to name tables, columns in tables, and indexes to data in the tables. This chapter describes the data dictionary, as well as the naming conventions BAAN IV database drivers use to access data stored in the RDBMS. This chapter also discusses how BAAN IV data types are mapped to DB2 data types. This chapter covers the following topics: BAAN IV data dictionary. Table naming convention. Column naming convention. Index naming convention. Data type mapping. Additional constraints. BAAN IV data dictionary A data dictionary is a catalog that provides information about the data in a database. You can think of the dictionary as data about the data, or metadata. You can use a data dictionary to find data that resides in a database table. The BAAN IV database drivers maintain a data dictionary because the data used by the BAAN IV applications can differ from the database tables defined in the RDBMS. The BAAN IV data dictionary maps BAAN IV 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. The user can store BAAN IV data dictionary information in shared memory, where the information is available to all running BAAN IV application virtual machines. The data dictionary information is shared among all the sessions open in a single database driver. 2-1

20 BAAN IV database organization The database driver cannot use the BAAN IV data dictionary directly to create DB2 tables because not all BAAN IV data types exactly match DB2 data types or limits. To create valid DB2 tables, the driver must perform some mapping or translation. When mapping the BAAN IV data dictionary to tables in DB2, conventions are used for the table names, column names, and index names. Table naming convention The table name of a BAAN IV table stored in DB2 has the following format: t<package><dd Table name><company number> The following table contains descriptions of each component of the table name. Components of the table name Component Description Package The package is a two-letter code that refers to the BAAN IV package that created the table. For example, a table created by BAAN Tools has the package code tt. DD Table Name Company Number 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. In BAAN IV, three-digit company numbers are used to differentiate areas of functionality. There must be a company with the number 000. In addition, there can be several other company numbers. For example, the data dictionary (ttadv999) table with company number 000 is created in DB2 as tttadv

21 BAAN IV database organization Column naming convention Each column in the BAAN IV data dictionary corresponds to one or more columns in a DB2 table. The following table contains the rules for column names: Rules for column names Component Description General If a BAAN IV column name is created in DB2, the column name is preceded by the string t_. For example, the BAAN IV column with the name cpac is created in DB2 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 an underscore [ _ ]. Long string columns BAAN IV columns of type string can exceed the maximum length of character columns in DB2. The DB2 data type CHAR has a limit of 254 characters. If a BAAN IV string column exceeds this limit, the column is split into segments with up to 254 characters each. The first 254 characters are placed in a column where the name of the column is extended with _1. The next 254 characters are placed in a column with a name extended by _2, and so on, until all the characters of the string are placed in a column. For example, if a BAAN IV string column called desc contains 300 characters, the following two DB2 columns are created: - t_desc_1: size t_desc_2: size 46 Array columns In the BAAN IV 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 DB2, 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 Note that if the element is of type string and one element type exceeds the maximum DB2 character size of 254, the element is split. For example: - t_str_1_1: element 1, part 1 - t_str_1_2: element 1, part 2 2-3

22 BAAN IV database organization Rules for column names Component Description Array compression If the number of BAAN IV columns exceeds the maximum number of DB2 columns, the database driver tries to compress or join array columns to reduce the number of columns. All array elements of one array column are stored as one column in the DB2 database with the elements concatenated in binary format. The driver starts by compressing the array column that yields the highest number of columns. The driver continues to compress array columns until the number of columns is less than the maximum number of columns allowed by DB2. The name of the compressed column in DB2 follows the same convention used for the other columns. For example: - t_array: Contains all elements of the compressed column Note that if the number of characters in a compressed array column is longer than 254 characters, the column is split in segments of 254 characters or less. Index naming convention BAAN IV 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. DB2 requires that index names must be unique. For this reason, the table name, index number, and the index type are included in the index name. The index type refers to the order and can be either ascending or descending. Index names have the following format: i<table name>_<index number><index type> For example, the index name for a BAAN IV table with name ttadv999, index number 1, company number 000, and index type ascending order is: ittadv999000_1a If a BAAN IV index is defined as a unique index, the DB2 index is created with the UNIQUE clause. The UNIQUE clause prevents duplicate rows from being created in the table. NOTE If bi-directional indexes are used, which is possible as of DB2 v6.1, the driver only creates one ascending index from that point on. Bi-directional indexes have type a. 2-4

23 BAAN IV database organization Data type mapping The following table shows the mapping between BAAN IV data types and their DB2 counterparts. Mapping between BAAN IV and DB2 data types BAAN IV data types DB2 data types CHAR Level 1: CHAR(1) for bit data Level 2: SMALLINT ENUM CHAR(1) for bit data INT SMALLINT LONG INTEGER UTC DATE DATE UTC TIME TIMESTAMP TEXT INTEGER BITSET INTEGER FLOAT DOUBLE DOUBLE DOUBLE STRING(N) CHAR(N) MULTIBYTE STRING CHAR(N) DATE DATE Note that the BAAN IV DB2 driver uses the CHAR data type when ANSIcompliant behavior is expected for character data, such as with the BAAN IV string type. This DB2 data type is used because a BAAN IV string data type has characteristics that conform to the ANSI specification for character data. If the CHAR data type is used, operations such as comparison and concatenation can be carried out in a predefined manner with predictable results. Note Level 1 to Level 2 migration must also consider the change of BAAN IV CHAR data type. BAAN IV converts multibyte data into TSS (Triton Super Set) 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 either TSS or native format, the DB2 data type char is used. Note that char data is sorted in byte order because Baan databases are built with COLLATE USING IDENTITY. In addition, the correct locale and code page must be specified when creating the Baan database for your multibyte environment to function properly. 2-5

24 BAAN IV database organization Additional constraints In addition to the previously mentioned naming conventions and data types, the following rules apply when you map BAAN IV data to DB2 data: All names generated by the database driver are in lowercase characters, and are not enclosed in double quotation marks. Because the binary sort order is selected during the installation, DB2 treats object names with case sensitivity. All columns created by the DB2 driver have the NOT NULL constraint. BAAN IV applications do not support NULLS. If a BAAN IV index is defined as a unique index, the DB2 index is also created with the UNIQUE clause. Otherwise, indexes which allow duplicates are not defined with the UNIQUE clause. The date range for the BAAN IV application virtual machine is the same as the range for DB2 with the following exception. The application virtual machine date 0 is mapped to the DB2 date 1. The application virtual machine date 1 is marked as an invalid date. 2-6

25 3 Database driver internal processing The DB2 database driver converts RDBMS independent database requests into requests designed specifically for DB2. This chapter describes some of the internal processing that occurs within the BAAN IV DB2 driver. First, some of the features that ensure data integrity are discussed. Next, the internal processing of a SQL statement within the driver is explained. The final section of this chapter describes the mechanisms to modify the default behavior of the database driver. This chapter discusses the following BAAN IV DB2 driver internal issues: Data integrity. Database driver SQL processing. Driver behavior setting. Data integrity Several features of the BAAN IV database driver help to insure data integrity. These features include locking mechanisms, methods to insure referential integrity, and methods used for distributed databases. In addition, data integrity is maintained while minimizing network traffic with the use of data buffering techniques. This section provides an overview of the features used by the BAAN IV DB2 driver to ensure referential integrity, to work with distributed databases, and to apply data buffering techniques. Locking strategies are discussed in detail Chapter 6, Database driver configuration and tuning. Referential integrity Referential integrity preserves the defined relationships between tables when records are maintained. The BAAN IV database driver has a built-in mechanism to preserve referential integrity. The BAAN IV database driver does not depend on the underlying RDBMS to maintain referential integrity. To buffer data Updates can be buffered by the application virtual machine and flushed at the time of transaction commit, or earlier if required. This action reduces the number of network round trips and data volumes. 3-1

26 Database driver internal processing If multiple rows are returned from a query, the rows are buffered and then sent back to the BAAN IV application virtual machine as one block. Data reduction and compression is applied to compact the data which minimizes the amount of data transferred between the application virtual machine and the database driver Database driver SQL processing As discussed in Chapter 1, Introduction, the application virtual machine sends RDBMS independent database queries and update requests to the database driver. The database driver must convert these RDBMS independent database requests to SQL statements that are appropriate to the specific RDBMS being used. This section details the SQL processing performed by the BAAN IV DB2 driver. Because the BAAN IV DB2 driver uses the call level interface (CLI) to communicate with DB2, CLI is described first. Call level interface The DB2 driver uses the call level interface (CLI) to communicate with DB2. CLI is a function library, or a set of C functions, that the user can call from a C program to carry out SQL statements. The functions that the DB2 driver calls perform the following actions: Logon to DB2 (open session). Allocate a statement handle. Parse a SQL statement. Bind input variables. Bind output variables. Carry out the SQL statement. Fetch the resulting rows. Break a query (asynchronous). Commit/abort transaction. Close a cursor. Logoff from DB2 (close session). The DB2 driver also uses the following features of CLI: Array fetches (if enabled). Array inserts (if enabled). 3-2

27 Database driver internal processing NOTE SQL processing The database dependent layer of the BAAN IV DB2 driver dynamically generates the SQL statements. Because BAAN IV applications are dynamic, the tables that are used at run time are not known in advance. Therefore, you cannot prepare the queries before run time. In the BAAN IV DB2 driver, SQL statements are processed in several steps. This section describes these steps. If the BAAN IV DB2 driver receives a query from the application virtual machine, the query is translated to a format suitable for DB2, and is passed to DB2 using CLI function calls. In DB2, a statement handle/cursor is allocated and the query is executed by assigning the statement handle to the query. The SQL statement is parsed, input and output variables are bound, and the query is carried out with the statement handle. In some cases, DB2 opens a server cursor internally for query execution. After the query is performed, a fetch operation is performed and the column values that result are placed in the bound output variables. The rows returned by DB2 are passed to the database independent layer of the BAAN IV DB2 driver, which sends the results back to the application virtual machine. If a statement must be rerun, the cursor from the previous execution is closed and the resulting rows are discarded, whether the rerun 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 rerun. However, for rerun, no reparse of the statement or rebind of input and output parameters is required. This action improves the overall performance. If the user enables array fetching, multiple rows are fetched in one call to the driver. Space is allocated in the driver to buffer multiple rows fetched in one operation. Multiple rows can be fetched to the buffer, which are returned to the application virtual machine when requested. If no rows are left in the buffer and more rows are requested, another array fetch operation is carried. Inserts can also be buffered. If you enable array inserting, the driver places the rows to be inserted in a buffer. If the buffer is full, or if required for another event, the rows are flushed to DB2. The rows in the buffer are inserted with a multirow insert. The array size must be specified and array fetch or array interface must be enabled, otherwise buffering is not performed. The array buffer size can be specified in the db2_storage file on a per-table basis or globally, with an environment variable or resource variable. Array inserts or array fetches happen only if you explicitly enable these processes and when the array size is greater than

28 Database driver internal processing To set driver behavior Several facilities are available to configure the BAAN IV DB2 driver. The most common facility is with driver resources. Two other facilities to configure the BAAN IV DB2 driver are environment variables and the storage file. The driver resources and environment variables are described in more detail in Appendix A and the storage file in Appendix B. Driver resources The database driver resources are parameters that the user can set to modify the behavior of the BAAN IV DB2 driver. The user can set the parameters in the resource file db_resource. One resource file is used for all database drivers that run in a BAAN IV environment, and resources for all the database driver types can be found in the resource file. A database driver reads the parameters set in the resource file when you first invoke the resource file. The resource file can contain several entries, each 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 must be set. The following is an example of the contents of a resource file that contains two entries: dbsinit:01 db2_max_open_handles:100 When you modify the behavior of the database driver, you must often modify the behavior of the BAAN IV application virtual machine to take advantage of the characteristics of the database driver. Therefore, two types of database driver resources exist: those used to modify the behavior of the database driver and those 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 UNIX environment, the resource file, db_resource, is located in the $BSE/lib/defaults directory. On Windows NT, the resource file is located in the %BSE%\lib\defaults directory, where $BSE or %BSE% refer to the directory where the BAAN IV software environment is installed. If both the database driver and the application virtual machine run on the same machine, only one db_resource file contains all the required resources parameters. If the database driver and the application virtual machine run on separate machines, one db_resource file must be located on the machine that runs the database driver which contains the server resources. A second db_resource file must be located on the machine that runs the application virtual machine, which contains the client resources. 3-4

29 Database driver internal processing In addition to the default db_resource resource file, you can set up an alternative resource file to override resource values for specific users or groups of users. The user can specify an alternative resource file with the environment variables USR_DBS_RES and USR_DBC_RES. You can use USR_DBS_RES to specify the path to a file that contains an alternative resource file for the server, and you must set this variable on the machine that runs the database driver. You can use USR_DBC_RES to specify the path to a file that contains an alternative resource file for the client, and you must set this variable on the machine that runs the application virtual machine. Any driver resource set in the alternative resource file overrides the setting of the same driver resource in the db_resource file. The following section describes how to set the database driver environment variables. Environment variables You can use environment variables 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. Usually, an environment variable exists that corresponds 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). If you use a database driver environment variable for the server, you must set the variable on the machine that runs the database driver to override the corresponding driver resource. If you use a database driver environment variable for the client, the variable must be set on the machine that runs the application virtual machine to override the corresponding driver resource. Server environment variables NOTE 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: Use the BAAN IV Database Definitions (ttaad4510m000) session and the Tables by Database (ttaad4111m000) sessions. Modify the BAAN IV tabledef6.1 file manually. Use the standard operating system mechanism to set environment variables. Because BAAN IV runs as a registered service in Windows NT, you must restart the system after you change/set values for environment variables. 3-5

30 Database driver internal processing NOTE The BAAN IV Database Definitions (ttaad4510m000) session is the recommended method to modify database driver behavior. If specific tables and companies must be configured for access with a specific database driver, you must use the Tables by Database (ttaad4510m000) session. These sessions cause environment variables for a particular database driver to override the defaults set in the resource file and enable the environment variables to be maintained centrally. The Database Definitions (ttaad4510m000) session maintains database driver configuration information in the tabledef6.1 file. This file is stored in the UNIX directory $BSE/lib or the Windows NT %BSE%\lib directory that resides on the machine where the database driver runs. Although for best results you must use the Database Definitions session to maintain this file, advanced users can modify this file manually. The tabledef6.1 file has the following format: <table name>:<company number>:<driver type>(<environment variable>=<value>) If multiple environment variables must be specified for a single table and company number, the variables are listed in the parentheses and separated by commas. If all tables or all companies must 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.1 file: tccom010:812:db2(db2prof=0.4) In this example, all the queries on table tccom that require at least 0.4 seconds are logged in the DB2PROF file. Note that this table is considered to have a separate database definition from other tables. If a DB2 driver is already running, but is accessing a different table, a separate driver is started for this table. The settings in the tabldef6.1 file override the environment settings. Client environment variables You can use database driver environment variables that affect the client to override the client resources that affect the application virtual machine. The user must set these environment variables on the machine that runs the application virtual machine, and must set the variables with the standard operating system methods used to set environment variables. Any client environment variables that you use override the equivalent resource variables set for the client in the db_resource file. 3-6

31 Database driver internal processing Storage file The storage file provides a way to specify the distribution of table and index data. The database driver uses storage parameters if a DDL statement such as a create table or create index statement is carried out. The following is an example of an entry in the storage file: *:*:T:0401:5:T_SPACE userspace1 I_SPACE indexspace1 In this example, the database driver adds the in <tablespace name> index in <index tablespace name> clause to the create statement during table creation. A storage file is defined for each database driver. The storage file for the BAAN IV DB2 driver is called the db2_storage file and is located in the UNIX directory $BSE/lib or Windows NT directory %BSE%\lib\db2. The format of the storage file is described in detail in Appendix B. 3-7

32 Database driver internal processing 3-8

33 4 Database security NOTE To maintain security, the BAAN IV DB2 driver controls user access to the database and to the database objects. The BAAN IV database administrator (DBA) module enables the DBA to control access to the database with BAAN IV sessions. The use of the DBA module makes DBA tasks easier and less prone to errors than the use of database driver tools directly. First, this chapter discusses how the BAAN IV DB2 database driver handles issues related to database security, and then briefly describes the DBA module. For BAAN IV, the sessions in DBA module are supported on Windows NT only and not on UNIX. In UNIX, the security is managed using the db2_admin6.1 shell script and the db2(v5)_maint6.1 binary. For DB2 V2, the maintenance tool is db2_maint6.1. This chapter covers the following topics: Database security. The DBA module. Utility programs db2_admin6.1 and db2(v5)_maint6.1 Security Database security consists of two main aspects: object security and authentication. Object security refers to the process to determine whether a user who has access to the database is authorized to access particular database objects. Authentication refers to the process to determine whether 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, and then describes how the BAAN IV DB2 driver provides object security and authentication. 4-1

34 Database security NOTE Groups In any RDBMS, a group is defined as a collection of database users. All users assigned to the group are granted the same database privileges. After a group is defined with a certain set of privileges, users can be assigned to that group. The use of groups simplifies the management of a large number of users with common privileges. A BAAN IV group consists of a database name and methods to provide object security and authentication in the database. The BAAN IV group name is the same as the name of the database that holds the BAAN IV data in the RDBMS. The BAAN IV group uses the mechanisms of the RDBMS to provide object security and authentication. A BAAN IV group is a superset of the usual RDBMS group, and consequently includes not only the RDBMS group, but also the database name and an RDBMS login. In DB2, a BAAN IV group is made up of three components, a database, a login (for authentication) and an operating system group (for object security). The DB2 database has the same name as the BAAN IV group. The login username is the same as the BAAN IV group and is assigned database owner privileges in the database. An operating system group is created, which becomes the target for privileges granted on objects in the database. Users are associated with the operating system group, and as a result, inherit the privileges granted to the 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. On Windows NT, the logon for the BAAN IV group is always set to baan. However, the database can be named differently, for example, baandb, unlike UNIX. But the Windows NT group has the same name as the DB2 database and the user baan must belong to this group. For example, users maria and john can both be assigned to the BAAN IV group baandb. Group baandb owns the tables and grants select, insert, delete, and update privileges to the operating system group, baandb. As a result, users maria and john inherit the select, insert, delete, and update privileges granted to the operating system group, which enables these users to access and manipulate BAAN IV group table data. The BAAN IV DBA module and the db2(v5)_maint tool enables the administrator to easily maintain groups. 4-2

35 Database security Object security In DB2, if 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 these users are granted the required privileges. In a BAAN IV environment, where many users access the same tables in the DB2 database, a mechanism was developed to enable users to share these tables. To enable several BAAN IV users to share the same DB2 table, the group concept is used. A BAAN IV group maps users to a database in DB2 and ensures that members of the group have sufficient privileges to access data in the BAAN IV group s tables. The BAAN IV DB2 driver uses an operating system group to implement the BAAN IV group concept. Initially the group is granted connect and createtab privileges to the database. Whenever the BAAN IV group user creates a new table, select, insert, delete, and update privileges are granted to the operating system group. Any user associated with the operating system group automatically inherits these privileges and can individually perform these operations on the BAAN IV group table. If new users are added, these users must only be associated with the operating system group. Therefore, the users automatically inherit all privileges currently granted to the operating system group without the need to grant privileges on every group object in the database to the user. If the user is dropped from the operating system group, these privileges are revoked. The user no longer has access to tables in that operating system group. If the privileges to operate on the tables are explicitly granted to the user, the privileges must also be explicitly revoked when the user is dropped from the operating system group. The overhead of adding users is greatly reduced by granting privileges to the operating system group. This procedure also provides flexibility and ease of maintenance. A user can define whether a table must be created as a group table or as a private table. If a table is identified as a private table, the user becomes the owner and privileges are not provided to other users. If a table is identified as a group table, the group logon creates the table and the privileges are granted to the group, which enables all users in the group to access the table. You can use the %BSE%\lib\db2\db2_storage file on Windows NT or the $BSE\lib\db2\db2_storage file on UNIX to configure a table as private or group. 4-3