Infor Enterprise Server. Technical Reference Guide for SQL Server Database Driver

Transcription

1 Infor Enterprise Server Technical Reference Guide for SQL Server Database Driver

2

3 Copyright 2008 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 Document code: U8173E US Release: Infor Enterprise Server Publication date: March 08

4

5 Table of Contents Chapter 1 MSQL database driver overview The Infor ERP architecture Display tier Application tier Database tier Data flow in the Infor ERP architecture Level 1 and Level 2 database drivers Migration between Level 1 and Level Migration from Level 1 to Level Migration from Level 2 to Level Infor ERP hardware configurations Chapter 2 Infor ERP database organization Infor ERP data dictionary Table naming convention Column naming convention Index naming convention Data type mapping Additional constraints Chapter 3 Database driver internal processing Data integrity Locking Referential integrity Data buffering Database driver SQL processing

6 ii Table of Contents The ODBC interface SQL processing Setting driver behavior Driver resources Environment variables Storage parameter file Driver parameter file Chapter 4 Database security Security Groups Object security Authentication DBA module Chapter 5 Database driver profiling and statistics Profiling Level 1 profiling Level 2 profiling Gathering statistics Troubleshooting Logging database driver trace information Logging errors Chapter 6 Database driver configuration and tuning Cursor management Level 1 mode Level 2 mode Array interface Optimistic and pessimistic reference checks Locking behavior SQL Server locking strategies Infor ERP MSQL database driver locking strategies Statement and lock time-outs

7 Table of Contents iii Isolation level Fill factor and indexes Index optimization in Level 1 drivers Duplicate indexes Hash column naming convention Size of hash columns To specify index optimization Fetch optimization in Level 1 drivers Row caching in Level 1 drivers Query Tuning in Level 2 drivers Concatenated expressions Chapter 7 SQL Server configuration and tuning SQL Server configuration SQL Server tuning Configuration parameters Disk I/O configuration and data placement Windows Operating System tuning Chapter 8 To migrate between Level 1 and Level 2 databases Introduction To migrate from Level 1 to Level To migrate from Level 2 to Level Appendix A Driver resources and environment variables... A-1 Summary of MSQL resources and environment variables...a-2 Detailed description of resources and environment variables...a-5 Generic driver resources...a-5 MSQL driver specific resources...a-15 Appendix B Parameter file formats and configuration options... B-1 Parameter file naming...b-1 Parameter file formats...b-1 Storage parameter file format...b-2

8 iv Table of Contents Driver parameter file format...b-2 Relationship with the msql_storage file...b-2 Parameter file field descriptions...b-2 To set parameters in the storage parameter file...b-5 To set parameters in the driver parameter file...b-6 Conversion from previous porting sets...b-7

9 About this Guide This document supplies technical reference information about the Infor ERP database driver for the Microsoft SQL Server (MSQL). The database driver forms the interface between the Infor ERP application and Microsoft SQL Server. This document is intended for those who want to configure or customize the Infor ERP database driver for the Microsoft SQL Server. An elementary knowledge of Windows Operating System and Microsoft SQL Server 2000 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 SQL Server and Infor ERP software are described in separate documents (take appropriate document according to the use Infor ERP version): Infor ERP Baan IV Installation Guide for MS SQL server (U7210 US) Infor ERP Baan 5.0c Installation Guide for Microsoft SQL Server (U8991 US). Infor ERP LN 6.1 Pre-installation Guide for Windows (U8072 US). Infor ERP LN 6.1 Overall installation Guide (U8204 US). The word Infor Enterprise Server comprises the tools and porting set, but this document only handles things related to the porting set, whereof the MSQL database driver is a part of. Affected porting set versions are 6.1c.x, 7.1d.x, 7.5a.x and 7.6x 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 SQL Server/MSQL will be used to refer to SQL Server version If things are (only) applicable to a certain Infor ERP version, then it is mentioned. The term database driver will refer to Infor Enterprise Server MSQL database driver.

10 vi Table of Contents Unless mentioned somewhere else, this documentation applies to both Level 1 and Level 2 mode of the database driver. The Level 1 mode of the database driver is not available for Infor ERP LN 6.1, but only for Infor ERP Baan IV and Infor ERP Baan 5.0c. The guide is divided into the following chapters and appendices: Chapter 1 provides an overview of the Infor ERP database driver architecture and how the database driver fits within the Infor ERP system. Chapter 2 describes the Infor ERP database organization and details the naming conventions used for data and objects within the SQL Server database. Chapter 3 describes some of the internal features of the Infor ERP MSQL database driver. Chapter 4 describes several aspects of database security provided by the Infor ERP MSQL database driver. Chapter 5 describes the facilities for profiling and gathering statistics about database driver performance. Chapter 6 details the configuration and tuning options for the Infor ERP MSQL database driver. Chapter 7 details the configuration and tuning options for the Microsoft SQL Server database server. Chapter 8 provides a brief description to migrate the database between 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 parameter files and the driver configuration options specific to the Infor ERP MSQL Server database driver. Send us your comments We continually review and improve our documentation. Any remarks/requests for information concerning this document or topic are appreciated. Please e- mail your comments to [email protected]. In your , refer to the document code and title. More specific information will enable us to process feedback efficiently.

11 Table of Contents vii

12

13 Chapter 1 MSQL database driver overview 1 This chapter gives a short overview about the MSQL database driver. The database driver is an important part of Infor s commitment to an open systems client/server architecture. Because the Infor ERP architecture includes the Infor ERP software and a third party relational database management system (RDBMS), the driver is needed to provide a seamless interface between the Infor ERP software and the different RDBMS products. The database driver allows the majority of the Infor ERP processing to be independent of the RDBMS. This chapter provides an overview of the database driver and how it fits into the Infor ERP architecture. The following topics are covered in this chapter: The Infor ERP architecture. Data flow through the Infor ERP architecture. Infor ERP hardware configurations. The Infor ERP architecture Infor ERP supports a three-tier architecture consisting of the following: a display tier an application tier A database tier. The display tier provides presentation services for user interaction. The application tier consists of the Infor ERP application virtual machine, the application objects and the Infor ERP database driver.

14 1-2 MSQL database driver overview The database tier consists of a third party RDBMS product that acts as the database server. Figure 1 depicts the Infor ERP architecture. The emphasis of this document is the Infor ERP database driver. The database driver is the interface between the Infor ERP applications and the RDBMS server. The database driver translates database requests from the Infor ERP application virtual machine to RDBMS specific SQL requests that are sent to the database server. After the database server retrieves the requested information, the database driver passes the data back to the Infor ERP application virtual machine. To put the functions of the database driver into perspective, each of the three tiers of the total Infor ERP architecture is described briefly in the following figure: Display Driver Display Tier Application Virtual Machine (bshell) Application Objects Database Driver Application Tier Database Server (RDBMS) Database Tier Figure 1 Infor ERP three-tier architecture Display tier The display tier consists of the display driver, which includes the Infor ERP user interface for Microsoft Windows (for example; Infor Worktop, Infor Baan Windows or Infor WebTop). The display driver facilitates the communication between the user and the application tier. Data input from the user through Worktop is relayed to the Infor ERP application virtual machine; data returned

15 MSQL database driver overview 1-3 from the Infor ERP 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 ERP application virtual machine as well as the database driver. Together, the application objects and the application virtual machine provide much of the functionality of Infor ERP whereas the database driver provides connectivity to the database server for storing and retrieving application data. The application objects include the compiled Infor ERP applications and the data dictionary. The Infor ERP applications provide the functionality needed to implement the Infor ERP Enterprise Resource Planning (ERP) system. These applications are written in Baan 3GL or Baan 4GL, which are programming languages, supported by the Infor ERP Tools package and are compiled into an intermediate code which is interpreted at runtime by the virtual machine (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 Infor ERP. The Infor ERP 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 Infor ERP 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 ERP application virtual machine has traditionally been called the Infor ERP shell, or more often simply the bshell. Throughout the remainder of this document, it is referred to as the Infor ERP application virtual machine or the application virtual machine. The Infor ERP database driver is also typically a part of the application tier. The database driver provides a common interface between the Infor ERP 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 ERP supports.

16 1-4 MSQL database driver overview Database tier The database tier typically consists of a third 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 different third party RDBMS products, for example; Oracle, Informix, IBM DB2, or Microsoft SQL Server. All Infor ERP application data is stored in a relational database managed by an RDBMS. It is possible to have multiple RDBMS products in one Infor ERP installation, with some data residing in one database server and some data residing in another. Data flow in the Infor ERP architecture The database driver provides an interface between the Infor ERP application virtual machine and the specific RDBMS server being used. The flow of data through the system is described in the following section. When a user performs an operation at a GUI workstation, the display server interprets the input and sends the information to the Infor ERP application virtual machine. Based on the information it receives, the application virtual machine triggers the appropriate application object to be run. 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 Infor ERP SQL, an RDBMS independent SQL language. When the application virtual machine runs 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 Infor ERP SQL 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

17 MSQL database driver overview 1-5 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. Level 1 and Level 2 database drivers MSQL database drivers can communicate with the RDBMS server in two modes: Level 1 and Level 2. These modes distinguish themselves in the way the Infor ERP SQL queries are processed and in the way the data is stored in the database. Note: The level 1 database driver is available for Infor ERP Baan IV and Infor ERP Baan 5.0c (Infor Enterprise Server porting set 6.1c.x and 7.1c.x/7.1d.x). Level 1 is not available for Infor ERP LN (porting set 7.5x/7.6x). The level 2 driver is available for Infor ERP Baan IV, Infor ERP Baan 5.0c and Infor ERP LN 6.1. The biggest part of this paragraph is therefore not applicable to Infor ERL LN 6.1 users. 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 resulting information to the application. Application programs designed for a Level 1 database driver usually access data one record at a time. This type of access also maps to the Level 1 single table/single row queries. To ensure proper system performance for single-table/single-row queries, an extra column, called a hash column, is created for each index defined in the table. This extra column is called hash optimization, which 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 a larger portion of the work. An application program written for a Level 2 database driver typically uses set-

18 1-6 MSQL database driver overview oriented database access. The Level 2 database driver can process these more complex queries more efficiently 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, so 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. When an application is written with record-at-a-time database access, the database queries are 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 no hash optimization is present. Migration between Level 1 and Level 2 To migrate between a Level 1 and a Level 2 database driver, you can use the Infor Enterprise Server utilities bdbpre and bdbpost. Migration from Level 1 to Level 2 Infor has developed a fast migration tool for conversion from Level 1 to Level 2, which is offered as a premier service. The migration tool is an in-place conversion of the database, using MSQL functionality. Contact your account manager or local support organization for more information. The migration tool is much faster than the procedure as described in Error! Reference source not found.. Migration from Level 2 to Level 1 For a brief description of this procedure, refer to Error! Reference source not found.. Be aware that level 2 is the strategic direction for Infor. Infor ERP hardware configurations Several hardware configurations are supported for an Infor ERP implementation. These configurations include the stand alone mode and many variations of client/server mode. Available hardware, data storage requirements, and performance expectations determine the most appropriate hardware configuration.

19 MSQL database driver overview 1-7 Stand alone mode refers to a configuration where all components of the Infor ERP 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. The stand alone mode configuration is illustrated in 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 Infor ERP 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 the stand alone 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.

20 1-8 MSQL database driver overview 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 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.

21 MSQL database driver overview 1-9 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 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 ERP method of client/server access between the application virtual machine and the database driver. Note: This configuration is not supported by the Infor ERP installer and must be set up manually.

22 1-10 MSQL database driver overview 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 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.

23 Chapter 2 Infor ERP database organization 2 This chapter explains how the Infor ERP organizes the database. All of the application data used by Infor ERP is stored in database tables in the RDBMS. To keep the majority of the Infor ERP processing independent of the RDBMS, Infor ERP uses a data dictionary that consists of domain, schema, and referential integrity information that is 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 ERP database drivers to access data stored in the RDBMS. This chapter also discusses how Infor ERP data types are mapped to SQL Server data types. The following topics are covered in this chapter: Infor ERP data dictionary. Table naming convention. Column naming convention. Index naming convention. Data type mapping. Additional constraints. Infor ERP 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 describe data that resides within a database table.

24 2-2 Infor ERP database organization Infor ERP maintains a data dictionary because the data used by the Infor ERP applications must be described in a database-independent manner. Since Infor ERP domains and data types may differ from those available in the database server, the database driver performs any mapping and translation necessary to store and retrieve the Infor ERP data in the database server. The Infor ERP data dictionary defines Infor ERP data types, domains, schemas, and referential integrity information and the database driver maps this information to the appropriate elements in the RDBMS. When storing or retrieving data in the RDBMS, the database driver maps data dictionary information to database table definitions. Infor ERP data dictionary information can be cached in shared memory where it will be available to all running Infor ERP application virtual machines. The data dictionary information is shared among all the sessions open within a single database driver. The Infor ERP data types cannot be used directly by the database driver to create SQL Server tables. This is because not all Infor ERP data types exactly match SQL Server data types. To create valid SQL Server tables, the driver must perform some mapping or translation. When mapping the Infor ERP data dictionary to tables in SQL Server, specific conventions are used for the table names, column names, and index names. Table naming convention The name of an Infor ERP table stored in SQL Server has the following format. t<package><module><table number><company number> The following describes each of the components of the table name. Package Package is a two-letter identifier that refers to the Infor ERP package where the table is defined. For example, a table defined in the Infor ERP Tools package has the package code tt. Module Module is a three-letter identifier for the subset of the package that defines the table. Table Number The table number is a three-digit number uniquely identifying the table within the module that it was defined. The number often indicates the order in which the table was defined in the module. Company Number Within Infor ERP, three digit company numbers are used to isolate

25 Infor ERP database organization 2-3 datasets used for different purposes (for example; demo data, training data, production data). There must be a company with the number 000. Company 000 contains master data common to all companies. This data includes currencies and languages used. In addition to Company 000, there may be several other company numbers. For example, the table 999 in module adv with company number 000 is created in SQL Server as tttadv Column naming convention Each column in the Infor ERP data dictionary corresponds to one or more columns in a SQL Server table. The rules for column names are as follows: General When an Infor ERP column name is created in the SQL Server, it is preceded by the string t_. For example, the Infor ERP column with the name cpac is created in the SQL Server with the name t_cpac. By preceding column names by t_, reserved word collisions are avoided. If an Infor ERP column name contains a period [.], the period is replaced by the underscore [_] character. Long string columns SQL Server 2000 data type CHAR has a limit of 8000 characters. When an Infor ERP string column exceeds this limit, the column is split into segments with a maximum of 8000 characters each. The first 8000 characters are mapped to a column where the name of the column is extended with _1. The next 8000 characters are mapped to a column with a name extended by _2, and so on until all the characters of the string are mapped to a column. For example, if an Infor ERP string column called desc contains 8888 characters, the following two SQL Server columns are created: t_desc_1: size 8000 t_desc_2: size 888 Array columns In the Infor ERP 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 SQL Server, 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

26 2-4 Infor ERP database organization 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 SQL Server character size, it is split. For example: t_str_1_1: element 1, part 1 t_str_1_2: element 1, part 2 Array compression The maximum number of columns in a SQL Server 2000 is 1024 columns. If the number of Infor ERP columns exceeds the maximum number allowed in SQL Server, the database driver tries to compress (concatenate) array columns to reduce the total number of columns in the table. All elements of one array column can be stored as one column in the SQL Server table with the elements concatenated in binary format. The driver starts by compressing the array column that yields the highest number of columns. It continues compressing array columns until the number of columns is less than the maximum allowed. The name of the compressed column in the SQL Server follows the same convention used for the other columns. For example: t_array: contains all elements of the compressed column. Index naming convention Infor ERP indexes are identified by a sequence number for each table, with the sequence numbers starting from one. Each table has at least one index called the primary index. The SQL Server requires that for each database, all index names within each database 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, either ascending or descending. Index names have the following format: I<Table name>_<index number><index type> For example, the index name for an Infor ERP table with name ttadv999, company 000, index number 1, and index type ascending order is: Ittadv999000_1a If an Infor ERP index is defined as a unique index, then the SQL Server index is created with the UNIQUE clause. If the Infor ERP index is defined to allow duplicates:

27 Infor ERP database organization 2-5 In Level 1 mode, the driver includes the primary index values as part of the index to maintain uniqueness and again creates the index with the UNIQUE clause. This mode is not applicable to Infor ERP LN6.1. In Level 2 mode, the index is not created with the UNIQUE clause. Note: When the Multilanguage Application Data feature is enabled for a table or a table has one or more BLOB columns, the following additional index is created: [s t]<dd Table Name><Company Number>$UUID Data type mapping The following table shows the mapping between Infor ERP data types and their SQL Server counterparts. Mapping between Infor ERP and MSQL data types Infor ERP data types Level 1 1 MSQL data types Level 2 for Infor ERP Baan IV & Baan 5.0c Level 2 for Infor ERP LN CHAR Tinyint Tinyint Integer ENUM Tinyint Tinyint Integer INT Smallint Smallint Integer LONG Integer Integer Integer TIME DateTime DateTime DateTime TEXT Integer Integer Integer BITSET Integer Integer Integer FLOAT Real Real Real DOUBLE Float Float Float 1 Level 1 is not applicable to Infor ERP LN 6.1 and higher 2 Default behavior on Infor ERP LN6.1, but configurable to the behavior on Infor ERP Baan IV/Baan 5.0c

28 2-6 Infor ERP database organization STRING(N) Char(n) Char(n) Char(n) DATE DateTime DateTime DateTime BLOB 3) n/a VARBINARY (max) VARBINARY (max) Note that the Infor ERP MSQL driver uses the SQL Server CHAR data type since ANSI-compliant behavior is expected for character data, such as with the Infor ERP string type. Since Infor ERP SQL expects ANSI-compliant string comparison semantics, the SQL Server CHAR data type is used instead of VARCHAR. This SQL Server data type is used because an Infor ERP string data type has characteristics that conform to the ANSI specification for character data. When the CHAR data type is used, operations such as comparison and concatenation can be done in a predefined manner with predictable results. Additional constraints In addition to the above naming conventions and data types, the following rules apply when mapping Infor ERP data to SQL Server data: Because the binary sort order is selected during the installation, the SQL Server treats object names with case sensitivity. All columns created by the Infor ERP MSQL driver have the NOT NULL constraint. Infor ERP does not currently support NULL values in the data. The date range supported by the Infor ERP application virtual machine is not the same as the range for the SQL Server (the SQL Server is more restrictive). Therefore, some Infor ERP dates are not valid when stored with the Infor ERP MSQL driver. The Infor ERP date 0 is mapped to the earliest possible date in the SQL Server (01-Jan-1753). The earliest possible Infor ERP date is then 02-Jan-1753 and the latest is 31-Dec The SQL_BINARY type is used to store UUID columns, generated if a table contains a BLOB column (except in BaanIV, where the UUID column is a string column).

29 Chapter 3 Database driver internal processing 3 This chapter describes some of the internal processing that occurs within the Infor ERP MSQL database driver. The Infor ERP MSQL database driver converts RDBMS independent database requests into requests targeted specifically to the SQL Server. 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 that allow the default behavior of the database driver to be modified. In this chapter the following Infor ERP MSQL database driver internal issues are discussed: Data integrity. Database driver SQL processing. Setting driver behavior. Data integrity Several features of the Infor ERP database driver help to ensure data integrity. These features include locking mechanisms, methods used for enforcing referential integrity, and methods used for distributed databases. Data integrity is maintained while minimizing network traffic by the use of data buffering techniques. This section gives an overview of the features used by the Infor ERP MSQL database driver to maintain referential integrity, to work with distributed databases, and to apply data buffering techniques. Locking strategies are discussed in more detail in Chapter 6.

30 3-2 Database driver internal processing Locking Locking in the database typically occurs when a record is modified, deleted or inserted. The lock persists until the transaction that the modification is part of is committed. This type of locking may be referred to as implicit locking, because the lock is taken implicitly by virtue of the database being modified. Records can also be locked explicitly by simply selecting them in a mode that causes the records to be locked even though they have not been modified. Locking allows the database server to serialize changes to the content of the object being locked to prevent corruption of data. Explicit locking allows the application to obtain exclusive control over data. Referential integrity Referential integrity can be defined as the preservation of known relationships between data in tables when records are maintained. The Infor ERP database driver has a built-in mechanism for preserving referential integrity; it does not depend on the underlying RDBMS to maintain referential integrity. Data buffering Updates can be buffered by the Infor ERP application virtual machine and flushed at the time of transaction commit, or earlier when necessary. This can reduce the number of network round trips between the database driver and server. When multiple rows are returned from a query, the rows can be buffered and then sent back to the Infor ERP application virtual machine as one block transfer. Data reduction and compression can be applied to compact the data, minimizing the amount of data transferred between the application virtual machine and the database driver Database driver SQL processing As discussed in Chapter 1, the Infor ERP application virtual machine sends RDBMS independent read and update requests to the database driver. It is the function of the database driver to convert these RDBMS independent database requests into SQL statements that are appropriate for the specific RDBMS being used. This section details the SQL processing performed by the Infor ERP MSQL database driver.

31 Database driver internal processing 3-3 Because the Infor ERP database driver uses the Microsoft Open Database Connectivity (ODBC) interface to communicate with the SQL Server, the ODBC interface will be described first. The ODBC interface ODBC is an application programming interface (API) used to communicate with the database server. ODBC is made up of a function library that can be called from an application program to execute SQL statements and communicate with the data source (for example. Microsoft SQL Server). The ODBC functions called by the Infor ERP MSQL database driver perform the following actions: Connect to Microsoft SQL Server (open session). Allocate a statement handle. Parse a SQL statement. Bind input variables. Define result variables. Execute a SQL statement. Fetch the resulting rows. Commit or abort a transaction. Close, unbind and drop a cursor. Disconnect from MSQL (close session). The Infor ERP MSQL driver also uses the following features of ODBC: Array fetches (when enabled). Array inserts (when enabled and possible). SQL processing The Infor ERP MSQL database driver processes SQL statements in several steps. This section describes these steps. SQL statements are dynamically generated by the database dependent (specific) layer of the Infor ERP MSQL database driver. Because the application virtual machine interprets code dynamically and the Infor ERP tools allow for modifications to the applications, it is not known in advance which tables will be accessed at run time; therefore it is not practical to prepare the queries before run time.

32 3-4 Database driver internal processing When the Infor ERP MSQL driver receives a query from the application virtual machine, the query is translated into a format suitable for SQL Server. The text of the query is transferred to the SQL Server using ODBC function calls. The database driver makes a function call to the ODBC driver manager to allocate a statement handle, and the query is executed by assigning it to the statement handle and calling the ODBC query-execute function. In some cases, SQL Server opens a server cursor internally for query execution. After the query is executed, a fetch operation is done and the resulting column values are placed in the bound result variables. Control is returned to the database independent layer of the Infor ERP MSQL database driver, which sends the results back to the application virtual machine. When a statement needs to be re-executed, the cursor from the previous execution is closed. The resulting rows are discarded (whether the reexecution is with the same input parameters or not). If new input values are required, the new values are assigned to the input parameter bind variables 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 typically required. Because binding is an expensive operation, avoiding it when possible can improve overall performance. When array fetching is enabled, multiple rows can be fetched in one ODBC call to the server. Space is allocated within the driver to buffer multiple rows fetched in one operation. Multiple rows can be fetched to the buffer; and they are returned to the application virtual machine when requested. When no rows are left in the buffer and more rows are requested, another fetch operation is executed. Inserts can also be buffered. When array inserting is enabled, the driver places the rows to be inserted in a buffer. When the buffer is full, or when some other event necessitates it, the rows are flushed to the database. The rows in the buffer are inserted with a multi-row insert. Note: Data can be placed into the database using the Infor ERP utility bdbpost. This utility is used to import data into a new database table or to append or replace data in an existing database table. Certain options can be set when using bdbpost, see also (check the document appropriate to your Infor ERP version): Infor ERP Baan ERP 5.0c Tools Technical Manual (U7040 US). Infor Enterprise Server 7 Technical Manual (U8172 US). For example, when the -f option is used with bdbpost, the rows are buffered by default and are flushed when the array buffer is full. The array size needs to be specified; otherwise buffering is not done. The array buffer size can be specified in the parameter file on a per table basis or globally, by using an environment variable or resource variable. The environment variables,

33 Database driver internal processing 3-5 resource variables, and parameter file(s) options are explained in the next section. Note: The name of the parameter file differs per Infor ERP version. See Error! Reference source not found. for more information. Setting driver behavior There are several facilities available for configuring the Infor ERP MSQL database driver. The most common is through driver resources. Two other facilities for configuring the Infor ERP MSQL database driver are environment variables and the storage and parameter files. The driver resources and environment variables are described in more detail in Appendix A. The storage and parameter files are described in Appendix B. Driver resources The database driver resources are configuration parameters that can be set to modify the behavior of the Infor ERP MSQL database driver. These parameters are set in the resource file (%BSE%\lib\defaults\db_resource). There is one resource file for all database drivers that run in an Infor ERP environment; resources for all the database driver offerings can be set there. The database driver reads the parameters set in the resource file when it is first invoked and uses these settings to configure itself. 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 msql_lock_timeout:10 When modifying the behavior of the database driver, it may be necessary to modify the behavior of the Infor ERP 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 database driver s client (for example the application virtual machine).

34 3-6 Database driver internal processing Resources that are used to modify database driver behavior are called resources for the server. Resources that are used to modify behavior in the application virtual machine are called resources for the client. In a Windows Infor ERP environment, the resource file, db_resource, is located in the directory %BSE%\lib\defaults, where %BSE% refers to the directory where the Infor ERP 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 resource.

35 Database driver internal processing 3-7 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 ERP Database Definitions (ttaad4510m000) session and Tables by Database (ttaad4111m000) session. By using the Infor Baan ES Service Management console to modify environment variables for each Baan instance. By using the standard operating system mechanism for setting environment variables. The Infor ERP 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 Tables by Database session must be used. These sessions allow environment variables for a particular database driver to be written to the following table definitions files: %BSE%\lib\tabledef6.1 for Infor ERP Baan IV %BSE%\lib\tabledef6.2 for Infor ERP Baan 5.0c/ERP LN6.1 Environment variables present in the driver specifications in the table definitions file are passed to the driver and added to its environment after startup. Environment variables that correspond to resources override the defaults set in the resource file. This method allows the environment variables to be maintained centrally. The Database Definitions session maintains database driver mapping and configuration information in the table definition file. This file is stored in the directory %BSE%\lib residing on the application server machine where the database driver runs. The format of entries in the table definition file is as follows: <table name>:<company number>:<driver type>(<environment variable>=<value>) The <driver type> and optional (<environment variable>=<value>) portions are collectively known as the driver specification. 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 as a wildcard in place of table name or company number. For example, the following entry can be made in the table definition file: tccom010:812:msql7(msql_lock_timeout=10,msql_dsn=sqlsrv)

36 3-8 Database driver internal processing In this example all the queries on table tccom are sent to an Infor ERP SQL Server driver and the MSQL_LOCK_TIMEOUT and MSQL_DSN settings specified will added into the driver s environment after it is started. Note: Tabledef entries with different driver specifications are considered to have a different database definition from entries. If an MSQL driver is already running, but has a different driver specification, a separate driver will be started for this entry. Environment variables that appear in the driver specifications of the table definition file are put into the driver s environment after 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 on a per-user basis. These environment variables will override the resource settings for these users. Client environment variables 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 must be set using the Infor NT Manager or 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 affect the distribution and configuration of table and index objects at create time. 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: FILEGROUP filegroup name In this example, the database driver adds the on <filegroup name> clause to the create statement during table creation. A storage parameter file is defined for each database driver. The storage parameter file is located in the directory %BSE%\lib\msql. The name of the file and the format of the storage parameter file is described in detail in Error! Reference source not found..

37 Database driver internal processing 3-9 Driver parameter file The driver parameter file provides a way to specify runtime parameters used by the database driver whenever a table is accessed. The following is an example of an entry in the driver parameter file: Level 1 mode *:*:T:group:011:5: In this example, the database driver is configured to use index optimization with ascending index on a single ascending hash column. Level 2 mode *:*:T:group:00400:: In this example, the database driver is configured to use iterative query optimization technique. A parameter file is defined for each database driver. The parameter file for the Infor ERP MSQL database driver is called msql_driver_param and is located in the directory %BSE%\lib\msql. The format of the parameter file is described in detail in Appendix B. The driver will scan storage parameter and driver parameter files top-down. The first matching line will be used (not the best matching line). Note: Infor ERP Baan IV has one single file, called msql_storage, for both storage parameters and driver parameters. See Error! Reference source not found. for more information.

38

39 Chapter 4 Database security 4 The Infor ERP MSQL database driver maintains security by controlling user access to the database and user access to database objects. The Infor ERP database administrator (DBA) module allows the DBA to control access to the database using Infor ERP sessions. 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 ERP MSQL database driver handles issues related to database security, and it then briefly describes the DBA module. The following topics are covered in this chapter: Database security. The DBA module. Security 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 (in other words, connect to) the database. Both object security and authentication use the concept of database groups or roles to ensure security. This section first describes the group concept, then describes how the Infor ERP MSQL driver authenticates and provides object security. Groups In Infor ERP, 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

40 4-2 Database security 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 ERP group consists of a database name and methods for providing object security and authentication within the database. The Infor ERP group name is the same as the name of the database that holds the Infor ERP data within the RDBMS. The Infor ERP group uses the mechanisms of the RDBMS to authenticate and provide object security. For the Microsoft SQL Server, an Infor ERP group consists of three components: A database A login (for authentication) A SQL Server role (for object security) The SQL Server database has the same name as the Infor ERP group. The login is also named the same as the Infor ERP group and is assigned database owner (DBO) privileges in the database. A SQL Server role is created whose name is derived from the Infor ERP group name. This role becomes the target for privileges granted on objects in the database. Users are associated with the SQL Server role and, as a result, inherit the privileges granted to the role. The advantage of having a group table is that all members of the group can share and operate on the same data in a single table. Infor ERP tables are typically owned by the group so that the tables and data can be shared amongst all users of the application. For example, users Maria and john can both be assigned to the Infor ERP group baandb. Group baandb owns the tables and grants select, insert, delete, and update privileges to the SQL Server role. As a result, users maria and john inherit the select, insert, delete, and update privileges granted to the role, allowing them to access and manipulate Infor ERP data stored in the group s tables. The Infor ERP users are shielded from directly administering the role. The Infor ERP DBA sessions and the database driver do all the processing that is needed to make use of the role. Only the administrator needs to be concerned about role administration, and the Infor ERP DBA module allows the administrator to easily maintain the role within the Infor ERP Tools. Object security If a user creates an object such as a table, in the SQL Server, the user becomes the owner of that object. Only the owner can access the object

41 Database security 4-3 unless privileges are explicitly granted to other users. Other users can only access the object if they have been granted privileges to do so. In an Infor ERP environment where many users access the same tables in the SQL Server database, a mechanism has been developed to allow users to share these tables. To allow different Infor ERP users to share the same SQL Server table, a group concept is used. An Infor ERP group maps users to a database in SQL Server and ensures that members of the Infor ERP group have sufficient privileges to access data in the Infor ERP group s tables. The Infor ERP MSQL driver uses a SQL Server role to implement the Infor ERP group concept. Whenever a new table is created by the Infor ERP group user, select, insert, delete, and update privileges are granted to the SQL Server role. Any user associated with the SQL Server role automatically inherits these privileges and can individually perform these operations on the Infor ERP group table. When new users are added, they only need to be associated with the SQL Server role. New users automatically inherit all privileges currently granted to the role without the need to grant privileges on every object in the database to the user. When the user is dropped from the role, these privileges are revoked. The user no longer has access to tables within that SQL Server group. If the privileges to operate on the tables were explicitly granted to the user, then they must also be explicitly revoked when the user is dropped from the Infor ERP group. The overhead of adding users is greatly reduced by granting privileges to the role and simply associating users with that role. The use of this method provides flexibility and ease of maintenance. 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 the SQL Server as the group user (the database driver handles this transparently). In this case the table will be owned by the group and permissions will be granted on it to allow all group users access. When accessing objects, users connect to the SQL Server under their own login. Authentication The Infor ERP DBA module sessions are used to map Infor ERP groups and users to SQL Server logins to allow them to establish a connection to the SQL Server 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 administrator or SQL Server database owner (DBO) creates a login for the user and associates the user

42 4-4 Database security with a SQL Server role in the database. The members that belong to this role inherit the role's privileges and are able to establish a connection to the database either via unified login or using a valid password stored in encrypted form in the driver administration files. A user can be added to or dropped from an Infor ERP group by using the Infor ERP DBA (database administration) module sessions. Users who are authorized to access the database are registered in the Infor ERP driver administration files. The user name and password Infor ERP uses to log on to the SQL Server on behalf of the user are maintained in the file %BSE%\lib\msql\msql_users. Here, %BSE% refers to the Infor ERP software environment (BSE), the directory where the Infor ERP software was installed. All the Infor ERP users and their corresponding SQL Server login names and passwords and the name of the Infor ERP group to which they are assigned are defined in the file %BSE%\lib\msql\msql_users. The format of each entry in this file is as follows: <Infor ERP user>:<sql Server login>:<encrypted SQL Server user password>: <Infor ERP group name> The Infor ERP MSQL driver is started by the Infor ERP application virtual machine on behalf of the user. From the file %BSE%\lib\msql\msql_users the driver identifies the SQL Server login and password and establishes the connection to the SQL Server. The group logon process also requires a password, which is defined in the file %BSE%\lib\msql\msql_groups. The file format is as follows: <Infor ERP group name>:<encrypted group password>

43 Database security 4-5 DBA module The DBA module is used to maintain the database administration files used by all Infor ERP database drivers. The sessions in this module allow an administrator to register authorized users and give them access to data. A tool is provided with the Infor ERP MSQL database driver to maintain the administration files the database driver needs at run time. The administration files are stored in the directory %BSE%\lib\msql. The DBA module implements the user and group administration functions for all Infor ERP database drivers. The MSQL_MAINT utility is an executable program called by the DBA module that implements the functions necessary to make changes in the SQL Server. While it is possible to call the MSQL_MAINT utility from outside the DBA module, this is not recommended because the users and groups files are not modified by MSQL_MAINT. The DBA module is described in more detail in next documents: Infor ERP Baan IV Database Administration (DBA) on Windows (U7247 US). Infor ERP Baan 5.0c Administrator s Guide (U7189 US). Infor ERP LN 6.1 Administrator s Guide (U8116 US).

44

45 Chapter 5 Database driver profiling and statistics 5 The Infor ERP MSQL database driver provides a facility for monitoring driver performance. These include 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 tracing facility for troubleshooting problems. In this chapter, the profiling, statistics, and tracing features of the Infor ERP MSQL database driver are discussed. The following topics are covered in this chapter: Profiling. Gathering statistics. Troubleshooting. Profiling The database driver allows users to log timing and statistics information. 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 easily analyzed. It is possible to define a logging threshold where only statements that take more than a given amount of time to complete 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 one hundredth of a second.

46 5-2 Database driver profiling and statistics To determine which table actions are most time consuming you can set the MSQLPROF environment variable to a time threshold (in seconds). For example, MSQLPROF can be set as follows: SET MSQLPROF=1.0 This sets MSQLPROF to one second, causing statements that take more than 1.0 seconds of elapsed time to complete to be logged to the MSQLPROF file in the directory %BSE%\tmp. Statement execution time can be viewed for individual tables by setting the MSQLPROF environment variable. See Appendix A for detailed information about the environment variables. Level 1 profiling If the driver runs in Level 1 mode (which is not applicable for Infor ERP LN6.1), the following two event types are timed and can appear in the log file: Execute event: This represents the amount of time the RDBMS takes to execute an SQL statement. Fetch event this represents the amount of time required to retrieve data from the driver s internal buffer cache or the RDBMS. The following example shows a sample MSQLPROF file when the driver mode is Level 1: Profiling value = 0.00 sec Pid Table Owner I Mode Cache Exe Fetch Exe Fetch Tot <11350> tiitm jim 1 FIRST : < 8024> tiitm jim 1 FIRST : <11350> tiitm jim 1 FIRST : <11350> tiitm jim 1 FIRST : <11350> tiitm jim 1 FIRST*: < 8024> tiitm jim 1 FIRST*: <11350> tiitm jim 1 NEXT : <11350> tiitm jim 1 NEXT : <11350> tiitm jim 1 NEXT : <11350> tiitm jim 1 NEXT : <11350> tiitm jim 1 NEXT : <11350> tiitm jim 1 NEXT* : <11350> tiitm jim 1 NEXT* : <11350> tiitm jim 1 PREV : <11350> tiitm jim 1 PREV : <11350> tiitm jim 1 PREV : The data in this sample file can be interpreted as follows: The number of seconds (profiling value) is 0.00, which means that all actions are logged to the file. The asterisk (*) after some of the records indicates that the records were first read and then locked.

47 Database driver profiling and statistics 5-3 Column I list the number of the index used. The Cache column lists a value when a result is retrieved from the driver s internal buffer cache. After a statement is executed, you can fetch the set multiple times, until the result set is exhausted or the cursor is closed. Level 2 profiling When the driver runs in Level 2 mode, each phase in the SQL query processing that exceeds the profiling value is printed. The following three event types are timed and can appear in the log file: The Parse event This represents the amount of time the RDBMS takes to parse an SQL statement. The Execute event This represents the amount of time the RDBMS takes to execute an SQL statement. The Fetch event This represents the amount of time it takes to retrieve data from the driver s internal buffer cache or the RDBMS. The following shows a sample MSQLPROF file: Profiling value exceeded <nkumar><qptool>: [11:25:05.491]: Time (parse) : seconds SQL statement: SELECT a.t_byte,a.t_date,a.t_double,a.t_float,a.t_int,a.t_long,a.t_string FROM dbo.taabdb a WITH ( INDEX=Itaabdb000001_1a) WHERE (a.t_byte >?) OPTION (FAST 1) Profiling value exceeded <nkumar><qptool>: [11:25:05.521]: Time (multi_exec) : seconds SQL statement: SELECT a.t_byte,a.t_date,a.t_double,a.t_float,a.t_int,a.t_long,a.t_string FROM dbo.taabdb a WITH ( INDEX=Itaabdb000001_1a) WHERE (a.t_byte >?) OPTION (FAST 1) Profiling value exceeded <nkumar><qptool>: [11:25:05.521]: Time (multi_fetch) : seconds SQL statement: SELECT a.t_byte,a.t_date,a.t_double,a.t_float,a.t_int,a.t_long,a.t_string FROM dbo.taabdb a WITH ( INDEX=Itaabdb000001_1a) WHERE (a.t_byte >?) OPTION (FAST 1) Profiling value exceeded <nkumar><qptool>: [11:25:05.611]: Time (multi_fetch) : seconds SQL statement: SELECT a.t_byte,a.t_date,a.t_double,a.t_float,a.t_int,a.t_long,a.t_string FROM dbo.taabdb a WITH ( INDEX=Itaabdb000001_1a) WHERE (a.t_byte >?) OPTION (FAST 1) Profiling value exceeded <nkumar><qptool>: [11:25:05.691]: Time (multi_fetch) : seconds SQL statement: SELECT a.t_byte,a.t_date,a.t_double,a.t_float,a.t_int,a.t_long,a.t_string FROM dbo.taabdb a WITH ( INDEX=Itaabdb000001_1a) WHERE (a.t_byte >?) OPTION (FAST 1)

48 5-4 Database driver profiling and statistics The data in the above sample file can be interpreted as follows: In this example, the number of seconds (profiling value) is This means that all actions are logged to the file. Once a statement is executed, the result set may be fetched from many times (until the result set is exhausted or the cursor is closed). 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 or connections). Number of inserts, updates, deletes. Number of commits, rollbacks. For each action, the cumulative elapsed time and the average time spent is logged. The statistics can be enabled with the environment variable MSQLSTAT. When the variable is set to zero, a statistics report is generated when the driver terminates (exit from Infor ERP). 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 MSQLSTAT in the directory %BSE%\tmp. The following are examples of how MSQLSTAT can be set: SET MSQLSTAT=0 SET MSQLSTAT=30 In the first example, MSQLSTAT is set to zero. With this value, only a final report is generated. In the second example, MSQLSTAT is set to 30. This logs a report every 30 seconds while the driver is active. The following is a sample output of MSQLSTAT for Level 1 and Level 2 modes of the driver. 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.

49 Database driver profiling and statistics 5-5 Level 1 mode <26752> [13:39:14]: Statistics [interval = 10] C U R S O R S Opened Closed Parse Bind Define Execute Fetch Count Time(s) Avg D A T A B A S E First Last Next Prev Curr Great Gteq Equal Less Eqle Equal* Count Read Cached Read Fetched Read Executed Read Time(s) Read Avg Read Count Lock Time(s) Lock Avg Lock Insert Delete Update Count Exe Time(s) Exe Avg Exe CrIdx DrIdx ChOrd CrTbl ClTbl DrTbl LkTbl NrRow Count Exe Time(s) Exe Avg Exe Commt Rolbk RdOnl PrCmt NotAc Count Exe Time(s) Exe Avg Exe S U M M A R Y Count Time(s) Avg Total asc read (s) Total desc read (s) Total exact read (s) Total all read (s) Total updates (s) Count Perc Total cache hit (%) Total fetch opt (%) Count Forced close 0 Current open cursors 6 Sessions (logon/logoff) 2 / 0

50 5-6 Database driver profiling and statistics Level 2 mode <395> [07:54:13]: Statistics [interval = 0] C U R S O R S Opened Closed Parse Bind Define Execute Fetch Count Time(s) Avg D A T A B A S E First Last Next Prev Curr Great Gteq Equal Less Eqle Equal* Count Read Cached Read Fetched Read Executed Read Time(s) Read Avg Read Count Lock Time(s) Lock Avg Lock Insert Delete Update Count Exe Time(s) Exe Avg Exe CrIdx DrIdx ChOrd CrTbl ClTbl DrTbl LkTbl NrRow Count Exe Time(s) Exe Avg Exe Commt Rolbk RdOnl NotAc Count Exe Time(s) Exe Avg Exe S U M M A R Y Count Time(s) Avg Total asc read (s) Total desc read (s) Total exact read (s) Total all read (s) Total updates (s) Count Perc Total cache hit (%) Total fetch opt (%) Count Forced close 502 Current open cursors 1 Sessions (logon/logoff) 3 / 3 In the Level 2 mode example, the first section refers to fetch cursor actions, the second section refers to row actions, the third section refers to lock actions, the fourth section refers to update cursors, the fifth section refers to table actions, and the sixth refers to transaction or database actions. The row actions other than Equal and Equal* are never used by the Infor ERP driver and hence they are always 0. The first section of the summary lists types of fetches and updates, the second section lists fetch optimization, and the third numbers the cursors that were forced closed, the open cursors, and sessions.

51 Database driver profiling and statistics 5-7 Troubleshooting The Infor ERP MSQL database driver provides a tracing facility for analyzing driver behavior. 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 trace log 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 file 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 directory %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 Error! Reference source not found. for more details. Logging errors In a Windows Infor ERP environment, the database driver logs its error messages in the Windows Application Event Log or in a log file in the %BSE%\LOG directory. The Application Event Log can be viewed using the Windows Event Viewer. The log file is called LOG.MSQL.MESG. An alternate location for the error log can be specified through the environment variable MSQL_DUMP_MESG. Warning messages can be logged to the error log by setting the environment variable MSQL_LOG_WARNINGS. Refer to Appendix A for detailed description of these two environment variables.

52 5-8 Database driver profiling and statistics The following information can be retrieved from the log entries: 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 (in log.msql.mesg). If a database error occurs, an attempt is made to map it to a known or anticipated error condition. Generally, these mapped (Baan database) BDB errors contain corresponding error numbers in the range of 1 to If a database specific error occurs, which does not have a corresponding BDB error code, it is mapped to an error code over 1000 with the following formula: abs(error_code) For example, if an error occurs, BDB error 2652 is returned to the application. In most cases, the log entries from the display driver, the Infor ERP application virtual machine, and the 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 must check the log entries from the database driver. All error log entries can be viewed in the Application Log by using the Windows Event Viewer.

53 Chapter 6 Database driver configuration and tuning 6 The Infor ERP MSQL database driver is designed to allow tuning for optimal performance in a variety of configurations. All parameters used by the database driver are preset with default values that will provide the best system performance in most situations. However, every environment is different, the default values of these parameters may be modified to achieve optimal performance. This chapter discusses the Infor ERP MSQL database driver parameters that can be set, and the changes in driver behavior that you can expect when you adjust these parameters. The following topics are covered in this chapter: Common Settings Cursor management. Array interface. Optimistic and pessimistic reference checks. Locking behavior. Level 1 Only Settings (not applicable to Infor ERP LN6.1) Index optimization. Fetch optimization. Row caching. Level 2 Only Settings Query tuning.

54 6-2 Database driver configuration and tuning Cursor management Cursor management differs for the MSQL database driver in Level 1 mode and the database driver in Level 2 mode. The following sections describe cursor management for both the Level 1 mode and the Level 2 mode. Level 1 mode The MSQL database Level 1 driver has a built-in cursor management mechanism that uses a least recently used (LRU) algorithm. Each cursor represents one type of SQL statement. The resource variable Msql_max_open_handles can be used to influence cursor management. This parameter limits the number of open cursors the driver maintains on a per-connection basis. The default is 200 open statement handles for each connection. Increasing the value of Msql_max_open_handles can result in more concurrent open cursors, therefore, more memory consumed, but in fewer cursors being opened and closed, therefore, fewer SQL statements that must be reparsed. Level 2 mode The Infor ERP MSQL Level 2 database driver has three resource variables that influence the cursor handling: msql_cursor_type, msql_max_free_cursors and msql_retained_cursors. Each of these resource variables is described in the following section. msql_cursor_type The resource msql_cursor_type configures the driver to use one of the two SQL Server cursor types: 1 (Keyset-driven with autofetch enabled) by default or 2 (Fast forward-only with autofetch enabled). Changing this value can result in a difference in performance slightly. Which type performs better depends on the particular scenario. In a 3-tier scenario (where the client, application server and the RDBMS physically exist on 3 different machines) msql_cursor_type:1 may give better performance. msql_max_free_cursors The resource msql_max_free_cursors influences the number of statement handles (SQL Server cursors) that are kept for reuse by the driver. The default value is 32. Whenever the application closes a query, most resources in the driver are freed. However, if the MSQL cursor being allocated will soon

55 Database driver configuration and tuning 6-3 be re-used, closing and opening of the cursor can be avoided. To avoid closing and re-opening cursors, the cursor is put in a free list containing all cursors, which are disassociated from a query. When a request for a new cursor comes, first a free cursor is taken from the free list. If no free cursors are available, a new cursor is opened. In this way the number of times a cursor is closed and opened is reduced. When the number of free cursors exceeds the value of msql_max_free_cursors, the MSQL cursor will be closed. Increasing the value of msql_max_free_cursors will result in more concurrent cursors open (thus more memory), but in fewer cursors being opened and closed. Note: When array fetch interface is enabled, free cursor list is not maintained. The driver internally resets the msql_max_free_cursors to 0. msql_retained_cursors With this resource the number of inactive cursors and thus the number of open cursors can be reduced. When a query has fetched all rows, a close is issued on the corresponding cursor, which means that SQL Server is notified that no additional fetches will be done. This gives SQL Server the chance to free certain query resources. After the cancel, the query can be re-executed without re-opening (parsing, binding) the cursor. The driver does not know if a cursor in cancel 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 cancel state) in a cancel list, so that they become candidates for being assigned to a different query. However, a number of inactive cursors in this list that is not available for this purpose are defined by the resource msql_retained_cursors, which defaults to 20. If the number of cursors in the cancel list is less than 20, a cursor from the cancel list cannot be assigned to a different query. If more than 20 cursors are in the cancel list, and a request for a new cursor is issued, the least recently inactivated cursor is used for this new cursor. This cursor is disassociated from the original query and assigned to a new query, which does parsing and binding on this cursor. When the original query is doing a re-execute, the driver detects that the cursor has been associated with another query and will get a new cursor and re-parse and bind the query again. Increasing the value of msql_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.

56 6-4 Database driver configuration and tuning Array interface The Infor ERP MSQL database driver can use multi-row ODBC statements for array fetches and array inserts. With the array interface, communication between the MSQL driver and SQL Server is more efficient, Multiple rows can be fetched or inserted with a single ODBC call. However, because multiple rows must be stored in a buffer in the Infor ERP MSQL database driver, more memory is consumed. The array interface is useful when you access a remote database, because the number of network round-trips is reduced. To adjust the size of the buffers that hold array rows, the msql_max_arrsz resource variable must be set. The array buffer size can be set on per table basis using the ARRAY_SIZE storage parameter in the parameter file (see also Error! Reference source not found.). The following is an example of an entry in the storage parameter file to adjust the array size: *:*:T: ARRAY_SIZE 5 The array fetch interface can be enabled with the resource variable msql_array_fetch. Array inserts are enabled by default when data is placed in the database tables using the bdbpost utility with the -f option. It is necessary to set the array size; otherwise the inserts will not be buffered (the driver s default array size is 1, so the driver behavior will not be altered. The array insert interface can be enabled with the resource variable msql_array_insert Optimistic and pessimistic reference checks To optimize concurrency, the Infor ERP MSQL database driver supports optimistic reference checking. In the 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. The pessimistic approach blocks an insert of another user referencing the same parent row, thereby affecting the concurrency. To avoid this problem there is another approach where the row in the parent table is not locked. 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

57 Database driver configuration and tuning 6-5 variable. Pessimistic reference checking is not available for MSQL driver at present. Locking behavior When updating a database table, a RDBMS must use a locking mechanism to ensure data integrity. The Infor ERP MSQL database driver can direct the SQL Server to choose a particular lock level when executing a query. Before understanding the Infor ERP MSQL database driver locking strategy, you must first understand the SQL Server locking mechanisms. SQL Server locking strategies Data integrity is enforced with locking mechanisms. As a result, different Infor ERP sessions, and even packages or tools other than Infor ERP that also use normal locking are concurrent. There are several levels of granularity that commercial RDBMS products can use to lock the physical data including row-level locking and page-level locking. With row-level locking, the smallest unit of data that can be locked is the row. Any row within a database can be locked. In some cases, rows, even within the same table, can have a variable length. With page-level locking, the smallest unit of data that can be locked is the page. A page is typically fixed in size and generally includes more than one row of data. The RDBMS can manage page-level locks more efficiently than row-level locks because page size is fixed and because page-level locking usually requires fewer locks than row-level locking. The disadvantage of page-level locking is that a page lock can affect more than the single row of data that is being modified. This can have an adverse impact on concurrency. SQL Server release 2000 offers the advantages of both row-level locking and page-level locking by introducing a dynamic locking strategy. This strategy allows the server to use page-level locking when there is no lock contention, but to de-escalate the page lock to a row-level lock if there is contention for the locked page. Infor ERP MSQL database driver locking strategies In most cases, the driver generates queries that contain optimizer lock hints to direct MSQL to choose a particular lock level when executing a query. In other cases, the driver does not supply these hints, but uses the default locking determined by the isolation level being used in the connection.

58 6-6 Database driver configuration and tuning When a record is locked for update or delete by the Infor ERP MSQL database driver, the row must be selected with a lock before it is actually updated or deleted. The row is locked when the SELECT WITH LOCK statement is executed to make sure that another user does not change the row. When the SELECT WITH LOCK statement locks the row; it acquires a shared or exclusive lock depending on the isolation level and any lock hints used. If the process tries to acquire an exclusive lock on a row that is already locked by another process, the process waits until the locked resources are released or the lock timeout period expires. If a time-out occurs, the client either retries the same operation or rolls back the transaction. The database driver uses a delayed locking strategy to improve concurrency. This means that before an update is executed, the driver checks each column to determine whether the related columns have been changed. If the columns have not changed, the update is not executed. This reduces both the workload on the RDBMS and the network traffic between the database driver and the RDBMS and may improve concurrency by reducing locking in the server. By default, the driver uses the read uncommitted isolation level to acquire shared locks and uses the exclusive lock for update and delete actions. The driver typically uses a dirty read for normal read operations. Exclusive locks are required so that any locks are retained until the transaction is committed or aborted, even after the cursor is closed. Several aspects of the Infor ERP MSQL database driver locking behavior can be configured. The following default characteristics of the Infor ERP MSQL database driver can be modified: the lock time-out interval, the number of high-level lock retries, and the fill factor for indexes. Each of these locking behaviors is described in the following sections. Statement and lock time-outs A SELECT WITH LOCK statement waits for a predetermined time period (time out duration) if a resource is locked by another session. The time out duration is configurable. Note that statements that do not take locks, or statements that read through locks, can also time out. This condition is commonly referred to as a query timeout and is often attributable to poor database server response time or high network latency. The lock wait period for SELECT FOR UPDATE, INSERT, DELETE and UPDATE statements can be specified using the MSQL_LOCK_TIMEOUT environment variable or the msql_lock_timeout resource variable. Note that care must be taken when experimenting with these options.

59 Database driver configuration and tuning 6-7 Isolation level The MSQL driver uses the read uncommitted isolation level by default Multirow read requests do not acquire any type of lock (shared or exclusive) unless explicitly stated in the query syntax. Queries such as INSERT, DELETE, and UPDATE acquire an exclusive lock implicitly. A SELECT WITH LOCK request acquires an update lock. Only in case of lookup references are shared locks acquired. The locks are retained until the transaction is committed or aborted. High-level lock retries When a row lock cannot be acquired due to a lock timeout, high-level lock retries are initiated. This means that the same action is repeated after some delay period. The retry behavior can be configured via the lock_retry resource variable. Its value consists of a comma-separated list of retry counts and sleep periods in milliseconds (MS). The following is an example of an entry that can be placed in the resource file. lock_retry:5*100,5*500 This example shows the default retry behavior; the action is retried five times with a sleep period of 100 MS between each attempt and then five times with a sleep period of 500 MS. The lock retries can also be disabled by including the following entry in the resource file. lock_retry:0 Fill factor and indexes For indexes, the fill factor setting can be used to reduce the impact of page locking on concurrency. When the index is created, a fill factor setting can influence the number of rows on each data page. Using a low fill factor setting causes the SQL Server to spread the data over a greater number of pages, giving better concurrency but consuming more space. The fill factor setting is not enforced after the index is created. Using the fill factor setting gives the most benefit when the number of rows in the table does not change (the table is static), but there is a significant amount of update activity on existing rows. The First Free Numbers (tcmcs047) table is an example of such a table. The following is an example of an msql_storage (Infor ERP Baan IV) or msql_storage_param (Infor ERP Baan 5.0c/ ERP LN6.1) file entry with the fill factor set to one for table tcmcs047.

60 6-8 Database driver configuration and tuning tcmcs047:*:t: FILLFACTOR 1 *:*:T: *:*:I: A low fill factor 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 fill factor setting has the negative side effect of consuming more space in the database (disk and buffers) and may also cause more I/O activity to satisfy reads. Index optimization in Level 1 drivers Index optimization is a technique used in Level 1 database drivers to achieve better performance for SELECT statements in relational databases. Because Infor ERP Level 1 database drivers generate only single-table queries, the driver can use this technique to improve access time. The index optimization technique causes a new column, which is referred to as a hash column, to be created in the table for each index defined in the Infor ERP data dictionary. This hash column contains a concatenation of values from each column participating in the key for that index. In addition, the first (or primary) index is always unique, so you can use this index (again concatenated) in other nonunique indexes to make these indexes unique. Finally, a raw data type can be chosen as the storage type for the hash column. You can use the combination of key reduction (concatenation into a single column) and index uniqueness to achieve performance gains in Level 1 drivers, primarily by simplifying the WHERE clause of SELECT statements used to retrieve data from the database. Sophisticated optimizers in RDBMS tend to overanalyze these simple queries in an attempt to optimize their execution, so the driver exploits any means available in the host RDBMS to reduce the effort required for the optimizer to arrive at an acceptable execution plan. In the Infor ERP MSQL database driver, this includes using Transact-SQL index hints, so the optimizer does not need to determine if a usable index exists for a query. In Infor ERP applications, an index can consist of multiple columns (concatenated keys). When you retrieve data in the order of the index, the first column in the index is considered most significant, while the last part of the index is considered the least significant. Each column has unique significance in the order. Infor ERP must enforce significance of the columns in the WHERE clause, which means that you must treat each column differently.

61 Database driver configuration and tuning 6-9 For example, consider Table A with columns t_col1, t_col2, and t_col3, all of type integer, and an index on t_col1, t_col2, and t_col3. The table contains the following five rows: Example Table A containing the following five rows: col1 col2 Col If you want the rows that are greater than the first row: {0, 0, 0}, the correct query is the following: SELECT col1, col2, col3 FROM A WHERE (col1 > 0 OR col1 = 0 AND (col2 > 0 OR col2 = 0 AND (col3 > 0))) ORDER BY col1, col2, col3 This query contains a nested list of AND/OR conditions, which the RDBMS cannot easily optimize. As a result, when an index contains multiple columns and the table contains many rows, the RDBMS server spends a long time searching through all the rows that meet the condition, which causes considerably slower performance. One way to solve this problem is with index optimization. Therefore, in the previous example, the contents of the three columns col1, col2, and col3 are concatenated and added to the table as a separate column. This additional column is called the hash column and contains a sort able value of the three concatenated column values. An index is created on the hash column.

62 6-10 Database driver configuration and tuning For the example table, this results in the following table. Note that the hash value is simplified in the example. Example table A with additional hash column col1 col2 col3 hash When you search for rows greater than {0, 0, 0}, you can now specify the following query, including the hash column: SELECT col1, col2, col3 FROM A WHERE hash1 > 000 ORDER BY hash1 This query is much simpler and can be quickly evaluated by the optimizer. Note that, the WHERE clause always contains one condition only. Duplicate indexes Hash column naming convention For duplicate indexes, the primary key parts are appended to the hash column to make the column unique. In this way, a distinction is made between an ascending and descending sorting order through the duplicate rows. The order as such, however, is not defined. The only distinction made is between ascending and descending. The name of the hash column in an Infor ERP application table is formed using the hash keyword and the index number for which the table is being created. If required, any descending hash column is created with a d appended, for example: hash1: ascending hash column for index 1

63 Database driver configuration and tuning 6-11 Size of hash columns The data types and sizes of all the columns in the index determine the size of the hash column. The following table demonstrates the contribution of each data type to the size of the hash column: Relationship between data types and size of hash column Data type Size of hash column CHAR 1 STRING(n) n SHORT 3 DATE 4 LONG 5 FLOAT (digv + diga + 2) / 2 DOUBLE (digv + diga + 2) / 2 In the table, digv is the number of digits before the decimal point and diga the number of digits after the decimal point. To specify index optimization You can specify index optimization for each table and for each index in the %BSE%\lib\msql\msql_driver_param file. The table/index optimization parameter in the driver parameter file is used to specify the index optimization. To specify whether index optimization must be used, the following (octal) values are available: 0000 no optimization 0001 optimization using both ascending and descending indexes 0010 optimization using ascending indexes only 0020 optimization using descending indexes only You can define the default index optimization value for each table in a table [T] entry. Any value in an index [I] entry overrides the table default for that index. If no entry exists for a specific table, the default value is 000.

64 6-12 Database driver configuration and tuning Fetch optimization in Level 1 drivers This functionality is only available in Level 1 mode and is not applicable to Infor ERP LN6.1. In Infor ERP, often a set of rows is retrieved from a table in the database. An application often performs the following sequence of actions on the database: READ FIRST READ NEXT READ NEXT READ NEXT and so on When a query is processed, after fetching the first row, any subsequent rows can be fetched from the existing result set and then returned to the user. This technique, combined with the isolation level or locking strategy employed, determines how current the data is during a read operation. On-demand reads, combined with dirty read locking, offer the most current view of the data. However, in many situations this behavior is not required. You can improve read performance at the expense of a less current view of the data. Fetch optimization is described as follows: after fetching the first row of a query with a multirow result set, subsequent rows satisfying the query are also fetched and returned to the client. Rows updated or deleted in other concurrent connections between fetches might not be reflected in this set of rows. The changes made in other concurrent connections are only reflected when the query is re-executed. A user might not need to see all row changes at the exact moment in which the changes occur, and can simply fetch the next row from the existing (buffered) row set, rather than re-executing the statement to get the most current view. This technique is referred to as fetch optimization. Critical to the use of this technique is the definition of a refresh time that enables the user to specify a time interval, in seconds, for which a fetchoptimized set of rows is valid. As long as the set is deemed valid, data can be fetched from the buffered row set. Changes that occurred as a result of activity in other connections since the query was executed are not reflected in the data. If the row set expires, that is, if the refresh time is exceeded, the statement is automatically re-executed in the driver before the next row is returned. For example, assume that a set of rows is retrieved when READ FIRST is issued. For a refresh time of five seconds, the READ NEXT call will fetch the next row from the fetch-optimized set of rows. All consecutive READ NEXT calls within five seconds will not fetch from the database, but will be fed from the buffered row set until the buffer is exhausted.

65 Database driver configuration and tuning 6-13 After five seconds, the set will be considered invalid, and a subsequent READ NEXT will cause a re-execute of the query and fetch from the database. This results in a performance improvement by reducing the number of query executions. This translates into reduced RDBMS server load and reduced network traffic. You must set the refresh time for tables (T entries) in the driver parameter file. For index (I) entries, the refresh field is ignored. The default is zero if not specified. For example, the msql_driver_param file can contain the following entries: *:*:T:group:011:5: *:*:I:group:011:: In this example, all tables and companies will use single hash columns for index optimization and a refresh time of five seconds for fetch optimization. Fetch optimization is useful when the result set contains several records and a fetch next action takes place within the refresh interval, or if the query locks the entire table. Row caching in Level 1 drivers This functionality is only available in Level 1 mode and is not applicable to Infor ERP LN6.1. Row caching is based on the fact that the last retrieved result (using fetch) is stored in a single-row cache. If two consecutive database requests are exactly identical, the result can be copied from a single-row cache. A restriction is that the second action must take place within the refresh time. This situation occurs frequently when joins are processed. Every time the outer row contains the same key value, a READ EQUAL on the outer table can be cached, so the request will not be passed to the RDBMS. Note that caching and fetch optimization is consistent for one Infor ERP user. Database changes made in any of the sessions running within a single Infor ERP application virtual machine will always disable current sets related to the update. Consequently, additional fetches will always fetch the new result. The changes that other users make might not be reflected within the refresh time.

66 6-14 Database driver configuration and tuning Query Tuning in Level 2 drivers This section describes how to externally influence the query generation done by the MSQL driver. Concatenated expressions The Infor application can use concatenated expressions, which operate on a combined column. Concatenated expressions that exist on combined columns are: select >= select > select <= select < select between and For example, a Infor BAAN SQL 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 MSQL driver can use one of the three different techniques: nested, iterative, and filter to let SQL Server solve the WHERE clause in different ways. These techniques are introduced because the SQL Server 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 SQL Server optimizer to make different decisions on how to execute a query. It provides some workarounds for typical optimizer behavior. The MSQLPROF variable can be used to detect long running or bad performing queries. Then you can experiment with these different techniques. MSQLPROF is described in Appendix A.

67 Database driver configuration and tuning 6-15 The following describes the nested, iterative, and filter techniques. These techniques are set in the index optimization field of the msql_storage (Infor Baan IV) or msql_driver_param (Infor ERP 5.0c/LN6.1) file. See Error! Reference source not found. for more information: 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 the MSQL. The iterative technique can only be used for unbounded queries. The iterative technique uses the following three conditions: c1 = "tt" and c2 = "adv" and c3 >= "000" c1 = "tt" and c2 > "adv" c1 > "tt" First, a query with the first condition is issued. When it does not return a row, it continues with the second condition. When the second condition does not return a row, it continues with the third condition. In addition, when one condition has returned all rows, but more rows are required, the driver continues with the next condition. 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") )

68 6-16 Database driver configuration and tuning 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"'. Specifying query tuning The query tuning can be specified per table and per index in the file %BSE%\LIB\msql\msql_storage (Infor ERP Baan IV) or %BSE%\LIB\msql\msql_driver_param (Infor ERP Baan 5.0c/ ERP LN6.1). Refer to Appendix B for the actual values that can be specified.

69 Chapter 7 SQL Server configuration and tuning 7 Configuring and tuning the Microsoft SQL Server is important to avoid performance bottlenecks and to optimize the performance of the Infor ERP applications using a SQL Server database. This chapter discusses the SQL Server configuration and tuning parameters that have the most impact on the Infor ERP environment. It also discusses disk I/O configuration and data placement issues. In addition, tuning Windows Operating System is briefly discussed. This chapter discusses the following topics: SQL Server configuration. SQL Server tuning. Disk I/O configuration and data placement. Windows Operating System tuning. SQL Server configuration Microsoft SQL Server 2000 is able to dynamically configure its resources which reduces the burden of server administration and can prevent most resource-related errors. In most cases, there is no need to manually configure the database server. If necessary, you can modify the SQL Server configuration parameters with the SQL Enterprise Manager. To access the SQL Enterprise Manager, choose SQL Enterprise Manager from the Microsoft SQL Server 2000 program group. You can also use the system stored procedure sp_configure. Note that SQL Server must be running before you can change the configuration parameters.

70 7-2 SQL Server configuration and tuning The following configuration parameters must be modified before you start using SQL Server. Some of these parameters may be modified during the Infor ERP installation by the installer. Memory. Disable Truncate log on Checkpoint. The memory parameters in SQL Server determine the amount of memory that the server will request from the operating system. From this pool of memory, the SQL Server allocates resources such as user connections and locks. The remaining memory is divided among the buffer and procedure caches. By default, the SQL Server is configured to manage its memory pool dynamically. In most cases, this is appropriate. In the SQL Server Enterprise Manager, the Memory tab of the Properties dialog for a given SQL Server allows you to influence the server s memory allocation by providing thresholds for minimum and maximum memory consumed or even specifying a fixed memory size for the server. The Truncate Log on Checkpoint option is configured for each database in the SQL Server. Log truncation is enabled by the installer for the Infor ERP target database during the load process and is disabled (by default) before the installation completes. If log truncation is enabled for a database, the server truncates the database transaction log every time a checkpoint occurs. This can have an adverse impact on performance. It also prevents the administrator from being able to restore the database to a consistent state in the event of a media failure, since logged operations are not saved. Disabling the option means that the log file will continue to be consumed and must be manually dumped or truncated by the database administrator to avoid filling the log file or having it grow excessively. If the database is used for purposes that do not require backups and recovery, this option can be enabled to avoid having to dump or truncate the log manually. SQL Server tuning Microsoft SQL Server tuning is basically a combination of modifying the server configuration and tuning the raw data (for example, device placement, indexing, locking, and so on). Also, tuning recommendations can depend on whether the application is run in standalone mode (Infor ERP application and the SQL Server on the same machine) or in a client/server configuration (Infor ERP application on one machine and the SQL Server on another).

71 SQL Server configuration and tuning 7-3 Configuration parameters In addition to the above recommendations, it can be beneficial to adjust the settings of other parameters in the SQL Server. The following configuration parameters can be modified from their defaults to improve Infor ERP performance with the SQL Server: Recovery interval. Set working set size. Priority boost. Affinity mask. Default network library (client). The recovery interval parameter configures the maximum number of minutes per database that the server will need to complete its recovery process. Changing this value can have an impact on the checkpoint interval. Assuming a fixed amount of transaction log activity, increasing the value can reduce the frequency of checkpoint operations. Decreasing this value can increase the frequency. The default is 5 minutes. The set working set size option can direct the operating system to reserve physical memory for the SQL Server to accommodate its memory demands (including tempdb if configured in RAM). The effect of this option is to lock physical memory for SQL Server s use. This can have an impact on memory allocation and swapping activity. It is a good idea to set this option on a machine that is being used strictly as a database server to prevent the SQL Server memory from being paged out, assuming there is sufficient memory available. It can be called for in other circumstances as well. If the machine is not a dedicated database server machine and this option is set, other applications can be adversely affected by a lack of memory. In these cases, it is important to analyze both the SQL Server and overall system memory utilization in order to maximize its effective use. The priority boost option determines whether the SQL Server must run at a higher priority than other processes that are being executed on the same machine. Again, this option must not be set unless you have a dedicated database server machine. The affinity mask parameter can control SQL Server s processor utilization by forcing its threads to be scheduled on designated CPUs. This can improve overall system performance by reducing context switching. It can also be used to isolate SQL Server threads so they do not consume all available CPU time on the machine. This is useful if a machine is used for both the Infor ERP application virtual machine and the database server.

72 7-4 SQL Server configuration and tuning The default network library for SQL Server clients is normally the Named Pipes network library (if installed). This is typically the best choice for configurations where the Baan database driver and Microsoft SQL Server run on the same machine, as Named Pipes gives a marginal performance improvement over TCP/IP in this configuration. However, in a configuration where the database driver communicates with a database server on another machine, the default network library on the driver machine must be configured as TCP/IP. The default network library must be configured in the General tab of the Client Network Utility which can be found in the SQL Server 2000 program group. Disk I/O configuration and data placement The goal of successful I/O configuration is to minimize situations where transactions in the server must wait on disk I/O. To accomplish this, it is useful to understand the server s I/O activity. In general, the server manages two types of I/O: database activity and transaction log activity. Database activity is routed through a complex and efficient read-ahead and buffering system. It can rarely cause transactions to wait, assuming the server s read-ahead and buffering subsystems are configured adequately. Database waits usually occur on reads when the cache does not contain data needed to satisfy a request. Database writes are normally accomplished in an asynchronous or write-behind fashion and the transaction need not wait for this I/O to complete. However, the transaction log is the repository for changes to the database during the course of a transaction, so it is wise to optimize write throughput for I/O of this type. This is usually one of the first arguments for isolating data and log activity onto separate devices. Because transactions depend on log writes, it is better to isolate the log device from other SQL Server devices. It is also a good idea to isolate the log device from other applications, including the operating system, at the hardware level. This can reduce resource contention that can adversely affect throughput. You must allocate the hardware in such a way as to favor log file write throughput. You must avoid using highly reliable disk configurations such as RAID 5 for the log device, where throughput can suffer in favor of availability. A less intrusive configuration that still offers redundancy, such as disk mirroring, is often preferable for log devices.

73 SQL Server configuration and tuning 7-5 Windows Operating System tuning In general, configuration and tuning efforts for Windows operating system are best initially focused on disk and file system configuration and the virtual memory subsystem (physical memory and paging). When creating paging space and installing products (including the operating system), distribute potential disk activity as uniformly as possible over the available hardware. As a result of the potentially high memory demands of database applications, it is useful to monitor memory utilization in Windows to minimize paging activity. When the contents of memory are swapped out to disk because of high memory demands, and that memory is again needed, the application using that memory space must wait for it to be retrieved from disk before it can execute. This can be an expensive operation. As the memory demand grows, the system can begin thrashing, where memory used by an application is constantly swapped out to disk to free physical memory and then back in again when the application needs to execute. The operating system spends too much time managing the physical memory demand and has less opportunity to run applications. The simplest solution is to add more physical memory to the machine. However, this may not always be necessary. When memory demands reach the limit of physical memory in the system, it becomes more critical to monitor memory utilization to make certain that it is allocated in the best possible way. With dynamic memory allocation in SQL Sever 2000, this has become a far less critical issue. For a thorough treatment of Windows Operating System configuration and tuning issues consult one or more of the numerous resources dedicated to the subject. There are an endless number of articles available via the Web and dozens of books that treat this subject in a much more detailed fashion. For more details on server configuration refer to the Microsoft SQL Server Administrator s Companion.

74

75 Chapter 8 To migrate between Level 1 and Level 2 databases 8 Introduction A migration is required to reconfigure the database tables when changing between the Level 1 and Level 2 modes. This chapter is not applicable to Infor ERP LN6.1. To migrate from Level 1 to Level 2 The migration from Level 1 to Level 2 removes hash columns from the database tables, rebuilds indexes on the tables, and can remap particular Baan data types to new data types in the database. Two methods of migration from Level 1 to Level 2 are available: Standard migration, which uses the Infor ERP tools bdbpre and bdbpost Fast migration, which uses native RDBMS tools. Contact your account manager, or local support organization. To migrate from Level 2 to Level 1 Note: Be aware that level 2 is the strategic direction. A migration from Level 2 to Level 1 adds hash columns to the database tables and remaps particular data types to Baan data types in the database. All Infor ERP users must log out before performing this procedure.

76 8-2 To migrate between Level 1 and Level 2 databases This procedure is merely a guideline and can require adaptation for your specific situation. Infor highly recommends that you contact Support before you perform this procedure. You cannot use Infor ERP for any other purpose during the migration process, and this process can take a very long time to complete. Support can help with migration planning and will provide the most current migration procedures. 1 Use the Create Sequential Dump of Table (ttaad4226m000) session to dump all tables in all companies to be converted. Click the File tab to specify the name and the location of the dump files. Note: A dump file is created for each company with the following naming convention: name.xxx Where name is the name you provided in session ttaad4226m000, and xxx is the number for the company that was dumped. 2 When all dumps are completed, use the Database Definitions (ttaad4510m000) session to set Level 1 mode. Add the MSQL_LEVEL1=1 environment variable to the database definition that will be used by all the dumped companies, then convert to run time. This updates the Table definition run-time file. To set Level 1 mode for one company and Level 2 for a second company, you can create another database definition, then set the MSQL_LEVEL1 environment variable for each definition. However, this can require duplication of all audited table entries in the Tables by Database (ttaad4111m000) session so you can assign these entries to the new definition. 3 Exit Infor ERP. Be sure to terminate all connections for all users. 4 In Step 2, you updated the Table definition file with MSQL_LEVEL1 using the Database Definitions session. You must now determine whether the MSQL_LEVEL1 environment variable and/or the driver resource MSQL_LEVEL1 ARE set anywhere else in your current configuration. Change or remove any of these additional settings based on your requirements. For more information on where environment variables and driver resources can be located, refer to Environment variables and Driver resources in Chapter 3, Database driver internal processing. 5 Turn off the printer daemon. 6 For each dump file, execute the following command: bdbpost -k -n -m -f -Idumppath\name.xxx -Cxxx

77 To migrate between Level 1 and Level 2 databases 8-3 Where dumppath is the drive and directory location of the dump file(s), and name.xxx is a dump file name. The -C option requires the company number xxx to be provided. The bdbpost options used in this command are: -k: Drop existing table. -n: Ignore referential integrity constraints. -m: Disable domain constraints. -f: Speeds bdbpost process. Builds indexes after table load. -I: Redirects input from the specified input file. -C: The number of the company to be posted. 7 Start Infor ERP and go directly to the Reorganize Tables (ttaad4225m000) session. Enter the desired company number range. Make sure that only the check boxes for Reference Integrity and Repair Reference Counter are selected. Click Reorganize. This step can take a very long time to complete. 8 When the reorganization is complete, the migration procedure is finished.

78 8-4 To migrate between Level 1 and Level 2 databases

79 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 MSQL database driver. Some of these resources are used with the client and others with the server. In this context, the client is the Infor ERP application virtual machine and the server is the Infor ERP MSQL database driver. If the Infor ERP application virtual machine and the database driver are running on different machines, client resources must be set on the machine running the Infor ERP 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 section Setting driver behavior in Chapter 3. This appendix provides the following information: Summary of MSQL resources and environment variables. Detailed description of MSQL resources and environment variables.

80 A-2 Driver resources and environment variables Summary of MSQL resources and environment variables There are four types of resources and environment variables that can be used with the Infor ERP MSQL database driver: Client and server resources used by all Infor ERP database drivers. Client resources used by all Infor ERP database drivers. Server resources used by all Infor ERP database drivers. Resources used only by the Infor ERP MSQL 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 MSQL resources and environment variables later in this appendix. Client and server resources used by all Infor ERP database drivers Resource name Environment variable Description baan_sql_cache_rows 4 BAAN_SQL_CACHEROWS Defines the size of internal buffers in the query processor baan_sql_trace 4 BAAN_SQL_TRACE Allows viewing of SQL query information rds_full RDS_FULL Sets maximum number of rows transferred in one block. tt_sql_trace TT_SQL_TRACE Allows viewing of SQL query information. use_shm_info 5 USE_SHM_INFO Enables or disables shared memory use. Client resources used by all Infor ERP database drivers Resource name Environment variable Description baan_sql_stmt_cache_size 6 BAAN_SQL_STMT_CACH Defines the size of the query E_SIZE cache 4 Only applicable to Infor ERP LN6.1 5 Not applicable to Infor ERP Baan IV

81 Driver resources and environment variables A-3 bdb_debug BDB_DEBUG Sets debugging link between client and server. bdb_driver BDB_DRIVER Sets database specifications. bdb_max_server_ schedule 7 BDB_MAX_SERVER_ SCHEDULE Defines mechanism for terminating idle database drivers. ssts_set_rows SSTS_SET_ROWS Sets number of rows read ahead. USR_DBC_RES Specifies alternative resource file for client. Server resources used by all Infor ERP 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 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. lock_retry LOCK_RETRY Defines the number of lock retries and the sleep period between retries. USR_DBS_RES Specifies alternative resource file for server. Resources used only by the Infor ERP MSQL database driver Resources common to both Level 1 and Level 2 6 Only applicable to Infor ERP LN6.1 7 Not applicable to Infor ERP Baan IV

82 A-4 Driver resources and environment variables Resource name Environment variable Description msql_65_schema 8 MSQL_65_SCHEMA Configures a MSQL driver to use the 6.5 schema limits (specifically max_char = 254). This resource is only needed when a database was migrated from SQL6.5. Do not use resource in other cases. msql_array_fetch MSQL_ARRAY_FETCH Enables array fetching. msql_array_insert MSQL_ARRAY_INSERT Enables array inserts msql_dsn MSQL_DSN Specifies data source to communicate with MSQL. MSQL_DUMP_MESG Specifies the filename where error messages will be written. msql_join_hint MSQL_JOIN_HINT Configures driver to send join hint to SQL Server. msql_level1 8 MSQL_LEVEL1 Specifies the mode in which the driver must run, which can be either Level 1 or Level 2. msql_lock_timeout MSQL_LOCK_TIMEOUT Specifies a timeout value for SQL statements blocked by locks. msql_log_warnings MSQL_LOG_WARNINGS Configures driver to log warning messages. msql_max_arrsz MSQL_MAX_ARRSZ Adjusts buffer size for array fetch and insert. msql_max_sql_buffer MSQL_MAX_SQL_BUFFER Sets the maximum memory allocated for one SQL statement. msql_odbc_perf_stat MSQL_ODBC_PERF_STAT Starts or stops ODBC s performance data logging. MSQLPROF Configures profiling. msql_serverhost MSQL_SERVERHOST Specifies host name for MSQL instance. MSQLSTAT Allows statistics to be gathered. Resources used by Level 1 driver (not applicable to Infor ERP LN 6.1) 8 Not applicable to Infor ERP LN6.1.

83 Driver resources and environment variables A-5 Resource name Environment variable Description msql_max_open_ handles MSQL_MAX_OPEN_ HANDLES Sets maximum number of open cursors per connection. msql_up_on MSQL_UP_ON Configures driver to use procedures for prepare. msql_use_ffo MSQL_USE_FFO Configures driver s use of Fast Forward Only cursors. msql_use_sp MSQL_USE_SP Configures driver s dynamic creation and use of stored procedures. Resources used by Level 2 driver Resource name Environment variable Description msql_cursor_type MSQL_CURSOR_TYPE Specifies the SQL Server cursor type to be used by the driver msql_max_free_cursors MSQL_MAX_FREE_CURSO RS Sets maximum number of open cursors per driver connection. msql_opt_rows MSQL_OPT_ROWS Adjusts number of rows retrieved. msql_retained_cursors MSQL_RETAINED_CURSOR S Sets number of breaked cursors per driver connection. Detailed description of resources and environment variables This section provides detailed information about the Infor ERP MSQL driver resources and environment variables. The driver resources are divided into two sections: those that are generic to all Infor ERP database drivers and those that are specific to the Infor ERP MSQL driver. Each group of resources is listed in alphabetical order. Generic driver resources baan_sql_cacherows / BAAN_SQL_CACHEROWS 9 9 Only applicable to Infor ERP LN6.1

84 A-6 Driver resources and environment variables Driver resource Environment variable Client/Server resource Type baan_sql_cacherows BAAN_SQL_CACHEROWS Set for both client and server Integer Default 71 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 must be specified for optimal performance of the internally used hash functions. baan_sql_stmt_cache_size / BAAN_SQL_STMT_CACHE_SIZE 9 Driver resource Environment variable Client/Server resource Type baan_sql_stmt_cache_size BAAN_SQL_STMT_CACHE_SIZE Set for client only Integer Default 330 Description This resource sets the number of inactive queries that must be retained for reuse. baan_sql_trace / BAAN_SQL_TRACE 10 Driver resource Environment variable Client/Server resource Type baan_sql_trace BAAN_SQL_TRACE Set for client only Integer (Octal) Default 0 Description This variable is introduced to view the BaanERP 10 Only applicable to Infor ERP LN6.1

85 Driver resources and environment variables A-7 SQL query information being handled in client and server. When this variable is set, the client prints debug information to the logfile (client). The available values of the baan_sql_trace variable and their descriptions are shown in the following rows Major query interface logging Detailed query interface logging bdb_debug / BDB_DEBUG Driver resource Environment variable Client/Server resource Type bdb_debug BDB_DEBUG Set for client only Integer (octal) Default 0 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: server types database actions delayed lock actions reference information TSS info from %BSE%\lib\tss_mbstore permission information Multiple categories can be defined by adding the octal values. The value is compared bitwise to determine if a given category must be logged.

86 A-8 Driver resources and environment variables bdb_driver / BDB_DRIVER Driver resource Environment variable Client/Server resource Type Default Description bdb_driver BDB_DRIVER Set for client only String None This variable is used to set a database specification, usually found in the table definition file, tabledef6.1 (Infor ERP Baan IV) or tabledef6.2 (Infor ERP Baan 5.0c/ ERP LN6.1). When this variable is set, all tables will be accessed using the database driver specified and the table definition file 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 11 Driver resource Environment variable Client/Server resource Type bdb_max_server_schedule BDB_MAX_SERVER_SCHEDULE Set for client only 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 ERP session is ended. At this point, all idle database drivers will have a schedule counter incremented. When the 11 Not applicable to Infor ERP Baan IV

87 Driver resources and environment variables A-9 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 Environment variable Client/Server resource Type Default Description bdb_max_sessions BDB_MAX_SESSIONS Set for server only Integer 0 (unlimited) 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 Environment variable Client/Server resource Type bdb_max_session_schedule BDB_MAX_SESSION_SCHEDULE Set for server only 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 ERP 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 will result in fewer connections from the driver to the RDBMS since whenever an Infor ERP session is ended; the corresponding RDBMS session (logon) is closed (logoff).

88 A-10 Driver resources and environment variables dbsinit Driver resource dbsinit Environment variable Client/Server resource Type Set for server only Integer (octal) Default 01 Description This variable allows flags to be set to specify the optimizations to be used. At this time, legal value is 001. Other values are reserved and must not be used. A flag of specifies that an optimistic approach must 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. Pessimistic reference checking is not available for Infor ERP MSQL driver at present. Multiple categories can be defined by adding the octal values. The value is compared bitwise to determine if a given category must be logged. dbslog / DBSLOG Driver resource Environment variable Client/Server resource Type dbslog DBSLOG Set for server only Integer (octal) 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:

89 Driver resources and environment variables A Data Dictionary information of tables within the driver Row action information Table action information Transaction action information DBMS input/output data Administration file info (SQL drivers) DBMS SQL statements General debug statements Data buffering info (communication) Lock retries logged (includes session name) Logs successful locks and longest lock duration in a transaction Multiple categories can be defined by adding the octal values. The value is compared bit wise to determine if a given category must be logged. DBSLOG_LOCK_PROF Driver resource Environment variable Client/Server resource Type DBSLOG_LOCK_PROF Set for server only Floating point number Default 0 Description Specifies the minimum duration of a lock that must 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 must 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.

90 A-12 Driver resources and environment variables DBSLOG_NAME Driver resource Environment variable Client/Server resource Type Default Description DBSLOG_NAME Set for server only String dbs.log 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 Environment variable Client/Server resource Type enable_refmsg ENABLE_REFMSG Set for server only 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. lock_retry / LOCK_RETRY Driver resource Environment variable Client/Server resource Type lock_retry LOCK_RETRY Set for server only String Default 5*100,5*500

91 Driver resources and environment variables A-13 Description This variable defines the high-level locking behavior that is used when an action is locked. It defines the number of retries and the length of the sleep periods between retries in milliseconds (MS). For example, for the default setting, the action is retried five times with a sleep period after each try of 100 MS. The action is then retried five more times with a sleep period of 500 MS after each retry. rds_full / RDS_FULL Driver resource Environment variable Client/Server resource Type rds_full RDS_FULL Set for both client and server Integer Default 5 Description This variable defines the maximum number of rows transferred between the Infor ERP 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 must be set to the same value for both client and server. ssts_set_rows / SSTS_SET_ROWS Driver resource Environment variable Client/Server resource Type ssts_set_rows SSTS_SET_ROWS Set for client only 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

92 A-14 Driver resources and environment variables the database without re-executing the query. use_shm_info / USE_SHM_INFO 12 Driver resource Environment variable Client/Server resource Type Default Description use_shm_info USE_SHM_INFO Set for both client and server Boolean 1 (enabled) 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. USR_DBC_RES Driver resource Environment variable Client/Server resource Type Default Description USR_DBC_RES Set for client only String None 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. 12 Not applicable to Infor ERP Baan IV

93 Driver resources and environment variables A-15 USR_DBS_RES Driver resource Environment variable Client/Server resource Type Default Description USR_DBS_RES Set for server only String None 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. MSQL driver specific resources msql_array_fetch / MSQL_ARRAY_FETCH Driver resource Environment variable Client/Server resource Type Default Description msql_array_fetch MSQL_ARRAY_FETCH Set for server only Boolean 0 (disabled) This environment variable is used to enable or disable the array fetch interface. The valid values are 0 and 1. When set to 0, the array fetch interface is disabled. When set to 1, it is enabled. Refer to the section Array interface in Chapter 6 for more information.

94 A-16 Driver resources and environment variables msql_array_insert / MSQL_ARRAY_INSERT Driver resource Environment variable Client/Server resource Type Default Description msql_array_insert MSQL_ARRAY_INSERT Set for server only Boolean 0 (disabled) This environment variable is used to enable or disable the array insert interface. The valid values are 0 and 1. When set to 0, the array insert interface is disabled. When set to 1, it is enabled. Refer to the section Array interface in Chapter 6 for more information. Note that this option cannot always be enabled. For example, if references must be checked or updated or the application requires immediate response from the driver as to whether the insert is successful, no array insert can be done. Refer to Chapter 6 for information about the array interface. msql_cursor_type / MSQL_CURSOR_TYPE Driver resource Environment variable Client/Server resource Type Default Description msql_cursor_type MSQL_CURSOR_TYPE Set for server only Integer 1 (Key set -driven with auto fetch enabled) This variable allows the driver to change the SQL Server cursor type. The possible values and their descriptions are shown in the following rows: 1 Key set-driven with auto fetch enabled 2 Fast forward-only with auto fetch enabled Refer to chapter 6 for more information on cursor management. msql_dsn / MSQL_DSN

95 Driver resources and environment variables A-17 Driver resource Environment variable Client/Server resource Type Default Description msql_dsn MSQL_DSN Set for server only String None Allows specification of a data source name to be used by the driver for communication with SQL Server. MSQL_DUMP_MESG Driver resource Environment variable Client/Server resource Type Default Description MSQL_DUMP_MESG Set for server only String Not set This environment variable allows the location of the log.msql.mesg file to be specified. By default, it is stored in the %BSE%\log directory. This variable must be the fully qualified filename where error messages will be written. msql_join_hint / MSQL_JOIN_HINT Driver resource Environment variable Client/Server resource Type Default Description msql_join_hint MSQL_JOIN_HINT Set for server only String NONE This variable allows the driver to send a join hint to SQL Server, which enforces a join strategy between two tables. Multiple join types in the same FROM clause of a query are not supported. So, it must be taken care to

96 A-18 Driver resources and environment variables specify the same join hint for all the tables in a query. CAUTION: In general, join hints need not be used. They have to be used only as a last resort by an experienced DBA. Using this setting without proper understanding can cause severe performance problems. The possible values and their descriptions are shown in the following rows: NONE LOOP HASH No join hint will be sent Looping strategy Hashing strategy MERGE Merging strategy msql_lock_timeout / MSQL_LOCK_TIMEOUT Driver resource Environment variable Client/Server resource Type msql_lock_timeout MSQL_LOCK_TIMEOUT Set for server only Integer Default 10 Description Determines the timeout value, in seconds, for queries blocked by locks in the database server. The default is 10 which means wait for 10 seconds for the lock to be released before giving up. When set to -1, the driver waits indefinitely for the locks to be released and when set to 0, the driver does not wait. msql_log_warnings / MSQL_LOG_WARNINGS Driver resource Environment variable Client/Server resource Type msql_log_warnings MSQL_LOG_WARNINGS Set for server only Boolean

97 Driver resources and environment variables A-19 Default Description 0 (disabled) This variable enables or disables the logging of warning messages. The warnings are logged to the %BSE%\LOG\msql.log.mesg or to the file specified by MSQL_DUMP_MESG environment variable. The valid values are 0 and 1. When 0 is set, logging is disabled and when 1 is set, logging is enabled. msql_max_arrsz / MSQL_MAX_ARRSZ Driver resource Environment variable Client/Server resource Type msql_max_arrsz MSQL_MAX_ARRSZ Set for server only Integer Default 1 Description If msql_array_insert is enabled, this variable defines the maximum number of rows inserted at once into the RDBMS. If msql_array_fetch is enabled, this variable defines the maximum number of rows fetched at once from the RDBMS. Refer to Chapter 6 for more information about the array interface. msql_max_free_cursors / MSQL_MAX_FREE_CURSORS Driver resource Environment variable Client/Server resource Type msql_max_free_cursors MSQL_MAX_FREE_CURSORS Set for server only Integer Default 32 Description This resource sets the number of SQL Server cursors that are kept by the driver for reuse. When array fetch interface is enabled, msql_max_free_cursors resource is disabled by the driver. Refer to Chapter 6 for more information on cursor management.

98 A-20 Driver resources and environment variables msql_max_sql_buffer / MSQL_MAX_SQL_BUFFER Driver resource Environment variable Client/Server resource Type Default Description msql_max_sql_buffer MSQL_MAX_SQL_BUFFER Set for server only Integer bytes This variable is used to specify the maximum size of memory to be allocated for any one SQL statement. msql_odbc_perf_stat / MSQL_ODBC_PERF_STAT Driver resource Environment variable Client/Server resource Type Default Description msql_odbc_perf_stat MSQL_ODBC_PERF_STAT Set for server only Boolean 0 (disabled) This variable is used to enable or disable ODBC s performance data logging. The data includes values like number of server round trips, average fetch time, average cursor size, number of selects, number of prepares, current connection count, maximum number of connections opened, bytes sent, bytes received etc. The valid values are 0 and 1. Logging is disabled when set to 0. When set to 1, the performance data is logged to the file odbcp<process id>.log at the location %BSE%\LOG. msql_opt_rows / MSQL_OPT_ROWS Driver resource Environment variable Client/Server resource Type msql_opt_rows MSQL_OPT_ROWS Set for server only Integer

99 Driver resources and environment variables A-21 Default Description 0, the FASTFIRSTROW table hint This option allows you to specify to SQL Server the hint that the first n rows have to be retrieved fast. This will allow SQL Server to optimize the fetch request. Based on this value, SQL Server determines a suitable communication buffer size to improve performance. This variable can have a value of n whose possible values and their descriptions are given in the following rows: n < 0 No optimization hint 0 FASTFIRSTROW table hint n > 0 OPTION( FAST n) query hint MSQLPROF Driver resource Environment variable Client/Server resource Type Default Description MSQLPROF Set for server only Floating point Not set 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. msql_retained_cursors / MSQL_RETAINED_CURSORS Driver resource Environment variable Client/Server resource Type msql_retained_cursors MSQL_RETAINED_CURSORS Set for server only Integer Default 20 Description This resource sets the number of inactive (breaked) cursors that must be retained in the list for reuse. These cursors may be reused

100 A-22 Driver resources and environment variables and thus save prepare/bind overhead but will also need more resources such as memory than if they were closed and released. Refer to chapter 6 for more information on cursor management. msql_serverhost / MSQL_SERVERHOST Driver resource Environment variable Client/Server resource Type Default Description msql_serverhost MSQL_SERVERHOST Set for server only String None Allows specification of a host name for the driver to locate the SQL Server instance to be used. MSQLSTAT Driver resource Environment variable Client/Server resource Type Default Description MSQLSTAT Set for server only Integer Not set 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.

101 Driver resources and environment variables A-23

102

103 Appendix B Parameter file formats and configuration options B There are two parameter files that influence the behavior of the database driver: the storage parameter file the driver parameter file. This appendix defines their formats and the parameters used with these two files. Note 1: Additional information about the storage parameter file can be found in the section Storage parameter file in Chapter 3 and Array interface and Fill factor and indexes in Chapter 6. Note 2: Additional information about the driver parameter file can be found in the section Driver parameter file in Chapter 3. Parameter file naming For Infor ERP Baan IV, there is one file, called msql_storage. For Infor ERP Baan 5.0c and ERP LN6.1, the msql_storage file is splitted up into two separate files: msql_storage_param and msql_driver_param. These two files are discussed here, but for Infor ERP Baan IV, the data can be used in the msql_storage file. Parameter file formats The parameter files consist of one or more entries, each consisting of several fields separated by colons.

104 B-2 Parameter file formats and configuration options Storage parameter file format The format of an entry in the storage parameter file is as follows: <table/module specification>:<company number>:<object type>: <storage parameters> Driver parameter file format The format of an entry in the driver parameter file is as follows: <table/module specification>:<company number>:<object type>:group:<query optimization>:< refresh time (obsolete)>:<driver parameters> Relationship with the msql_storage file Previous versions of Infor ERP Baan 5.0c, for example; Infor ERP Baan IV used the msql_storage file. This file is a predecessor to the storage and driver parameter files which is introduced in the Infor Baan ERP 5.0c release. The msql_storage file may still be in use within your configuration. The format of an entry in the msql_storage file is as follows: <table/module specification>:<company number>:<object type>:group:<query optimization>:< refresh time (obsolete)>: <storage parameters> ttadv999,ttadv000:000:t:group: 00400::NOIDXHINT In this example, for the tables ttadv999 and ttadv000 of company 000, the database driver is configured not to use index hints while fetching the data. As you can see, the implementation of the new storage and driver parameter files is a simple division of information in the msql_storage file. If you are still using the msql_storage file in your implementation, all references to either the storage or device parameter file in this technical reference manual must be adapted with this in mind. Parameter file field descriptions table/module specification

105 Parameter file formats and configuration options B-3 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 tt all tables in module tt and package adv all tables in module 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 I I <index number> table only all indexes only specified index * both table and indexes Example I1,I2 only index 1 and 2 T only for table group (only for msql_storage file, not for msql_storage_param file)

106 B-4 Parameter file formats and configuration options Description This field identifies the owner of the table. The value group must be specified. Query 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. Example no optimization nested iterative filter Default values can be defined for each table entry. Optimizations are explained in more detail in Query Tuning section of Chapter 6. refresh time Description This is an obsolete parameter which is ignored by the driver. Example - 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 storage parameters for the MSQL database driver may be specified in either all upper case or all lower case letters. The following MSQL storage parameters are defined: CLUSTER <n> Creates index n as a clustered index. Only one index on the table may be clustered. If this option is not

107 Parameter file formats and configuration options B-5 specified for a table, the primary index (index 1) will be clustered by default. To create all indexes nonclustered, specify CLUSTER 0. FILL FACTOR <n> Includes the fill factor <n> clause in the create index statement during index creation. NOINDEX Prevents index creation on the table(s). FILEGROUP <file group name> Includes the on <file group name> clause in the create table or create index statement during object creation. ARRAY_SIZE <n> Determines the array size for the array interface. Example CLUSTER 1 FILEGROUP primary driver parameters Description These are defined by the specific database driver implementation. The driver parameters for the MSQL database driver may be specified in either all upper case or all lower case letters. The following MSQL driver parameters are defined: NOIDXHINT Prevents the driver from generating index hints for the table(s) specified. Example NOIDXHINT To set parameters in the storage parameter file Note: The storage parameter file is scanned from the beginning whenever a CREATE TABLE or CREATE INDEX is performed. The first entry that matches the table or index is taken, therefore the order in which the entries are specified is important.

108 B-6 Parameter file formats and configuration options This is an example of a storage parameter file: ttadv999,ttadv000:000:t: FILEGROUP mydatafilegroup CLUSTER 1 ARRAY_SIZE 5 ttadv999,ttadv000:000:i1: FILEGROUP mydatafilegroup ttadv999,ttadv000:000:i: FILEGROUP myindexfilegroup *:*:T:011: FILEGROUP mydatafilegroup CLUSTER 1 *:*:I1:011: FILEGROUP mydatafilegroup *:*:I: FILEGROUP myindexfilegroup In the storage parameter file example, the tables ttadv999 and ttadv000 of company 000 will be created in the file group mydatafilegroup. The associated indexes, except index 1, will be created in file group myindexfilegroup and index 1 will be a clustered index. All other tables and indexes will be created in the default file group. Microsoft SQL Server requires that clustered indexes are in the same file group as the data file. Therefore a special rule for index 1 is needed in the storage parameter file. It is impossible to create a clustered index in a different file group as where the table is created. Note that only one clustered index can be created per table. Note: If the file group for a table or index is not specified, the table and index data are created in the default (usually primary) file group. If you want to physically separate the index data, you must specify a different file group. To set parameters in the driver parameter file The driver parameter file is read in at driver startup to specify several run time settings. This is an example of a driver parameter file: ttadv999,ttadv000:000:t:group: 00400::NOIDXHINT *:*:T:group: 00400:: *:*:I:: For group objects table or index a single entry must be created, consisting of all Infor ERP users in the group.

109 Parameter file formats and configuration options B-7 Write permission for the device parameter file must be controlled, and only the DBA can have write permission. Conversion from previous porting sets Existing Infor installations, installed on Infor ERP Baan IV or Infor ERP porting sets before porting set 7.1a, may not have the storage or driver parameter files. In these porting sets there is just the msql_storage file. When the driver parameter file and the storage parameter file do not exist, the Infor ERP database driver tries to open the msql_storage file for compatibility. The Convert Table and Index Repository (ttdba0540m000) session that converts the storage file to the storage parameter file and the driver parameter file. Use this session to convert the storage file.

110 B-8 Parameter file formats and configuration options