oracle dataserver

Progress Software Corporation

Building High PerformanceApplications with the

Progress Oracle DataServer

Author: Oriana Merlo

Updated: December, 1998

Building High Performance Applications with the Progress Oracle DataServer

December, 1998 Page ii

Table of Contents

Table of Contents.................................................................................................................................... ii

Executive Summary................................................................................................................................ 1

Introduction............................................................................................................................................ 2

High Performance vs. Database Independence............................................................................... 2

DataServer Configurations..................................................................................................................... 3

Local DataServer and Local Oracle Database ....................................................................................... 3Local DataServer and Remote Oracle Database .................................................................................... 3Remote DataServer and Local Oracle Database .................................................................................... 4Remote DataServer and Remote Oracle Database ................................................................................. 4SQL*Net or Net8 vs. Progress Networking .......................................................................................... 4

Database Design ..................................................................................................................................... 5

Naming Conventions ........................................................................................................................... 5Database Limitations ........................................................................................................................... 5Data Types .......................................................................................................................................... 5Additional Database Objects Required ................................................................................................. 5Arrays.................................................................................................................................................. 6Case-Insensitive Indexes ...................................................................................................................... 6RECIDs............................................................................................................................................... 6Word Indexes ...................................................................................................................................... 7Unknown Values / NULLs / Zero-Length Character Strings ................................................................. 7Fixed vs. Variable Length Character Strings in Oracle.......................................................................... 7Trailing Blanks .................................................................................................................................... 7Progress To Oracle Database Conversion Utility .................................................................................. 8

Application Design ................................................................................................................................. 9

Unsupported Syntax............................................................................................................................. 9Utilizing Oracle-Specific Functionality ................................................................................................ 9

Stored Procedures ........................................................................................................................... 9Native Oracle SQL Syntax Support .................................................................................................. 9Optimizer Hints ............................................................................................................................... 9

Transactions ........................................................................................................................................ 9Stored Procedures and Transaction Scoping...................................................................................10Constraint Violations / Trigger Execution.......................................................................................10

Triggers..............................................................................................................................................10Record Locking ..................................................................................................................................10

No SHARE-LOCK Support in Oracle..............................................................................................11Automatic Optimistic Locking Support............................................................................................11

Cursor Repositioning ..........................................................................................................................11RECIDs and ROWIDs ........................................................................................................................12Record Scoping / Availability .............................................................................................................13Ordering of Records............................................................................................................................14

Query Tuning..........................................................................................................................................14Field Lists ......................................................................................................................................14Lookahead Cursors ........................................................................................................................14Progress 4GL vs. SQL ....................................................................................................................15Join-By-SQLDB .............................................................................................................................16


December, 1998 Page iii

Error Messaging .................................................................................................................................16Distributed and Batch Processing with an Oracle Database ..................................................................16Mass Database Modifications..............................................................................................................16Oracle Query Resolution.....................................................................................................................16INDEXED-REPOSITION Support......................................................................................................17

Deployment Considerations ..................................................................................................................18

Building Progress Executables ............................................................................................................18Schema Holders..................................................................................................................................18Oracle Database Changes and the Schema Holder ...............................................................................18Incremental Schema Difference File....................................................................................................18Code Recompilation Due to Schema Changes .....................................................................................19Startup Parameters..............................................................................................................................20Migrating Multiple Progress Databases ...............................................................................................20Progress Runtime Licenses .................................................................................................................21

Database Conversion Utilities ........................................................................................................21DataServer and Database Administration Utilities..........................................................................21

Troubleshooting and Performance Tuning...........................................................................................22

Query/Browse Performance ................................................................................................................22Version 7 Progress Oracle DataServer Performance ......................................................................22Version 8 Progress Oracle DataServer Enhancements ....................................................................22Version 9 Progress Oracle DataServer Enhancements ....................................................................22

Skipping Schema Verification.............................................................................................................22Debugging DataServer Applications....................................................................................................22

Debug SQL.....................................................................................................................................23Debug Extended .............................................................................................................................23Debug Cursor.................................................................................................................................24Debug Databind.............................................................................................................................25Debug Performance .......................................................................................................................26Debug Summary.............................................................................................................................27Debug Verbose...............................................................................................................................27

Appendix A............................................................................................................................................30


December, 1998 Page 1

Executive Summary

The past decade has seen many companies invest a significant amount of both time and resources intoestablishing corporate database standards. With hardware, operating systems and networking productsgiving way to open technologies, those same companies are frustrated in their efforts to grow by beinginextricably bound to application suppliers who provide solutions that run only on their chosen database.

A single database system today is capable of acting as the source for a variety of applications, fromtraditional on-line transaction processing (OLTP) and decision support systems (DSS), to todays currentlyhot technologies like data mining and internet transaction processing (ITP). Customers want highperforming solutions, and they want them to fit in with their existing operating environments, withouthaving to duplicate data to a wide variety of different database management systems.

Progress Software Corporation's (PSC) DataServer technology allows applications created with theProgress 4GL or Progress WebSpeed development environments to connect to a variety of non-Progress data sources. The DataServer accepts the request for data from the application, translates it into aformat and syntax suitable for the underlying database, and passes the request on. The data source thenaccepts the request, processes it as if it were a native client, and sends the information back to theDataServer. The DataServer will then adjust the result set into the format expected by the applicationbefore passing it on.

This paper will help you create high performance applications with the Progress 4GL and WebSpeedtoolsets to integrate with an Oracle relational database management system (RDBMS). The focus of thispaper is on Progress tools and technology. It explains how the Progress Oracle DataServer supports thedevelopment and delivery of high performance applications on an Oracle database.

Progress provides you with the tools to build mission-critical applications for a wide variety of deploymentconfigurations, without changing the application logic. This allows developers to focus on solving businessproblems, not reacting to changes in the computing infrastructure.



Introduction

Creating an application to run efficiently over an Oracle relational database management system (RDBMS)requires the integration of a number of technologies: the development toolset used to create the application,the underlying Oracle database technology, a knowledge of operating systems and networkedenvironments, and the connectivity software used for access to the Oracle database.

The Progress 4GL and WebSpeed development tools are tightly integrated with the Progress RDBMS,however, the Progress Oracle DataServer allows you to use these toolsets to develop applications that canbe deployed with an Oracle RDBMS. The Progress Oracle DataServer provides optimized databaseconnectivity to the Oracle database. This connectivity technology, however, does require thoroughunderstanding. While the Progress 4GL and WebSpeed toolsets make it easy to develop on-line transactionprocessing (OLTP) and internet transaction processing (ITP) applications, subtle differences in the Oracleand Progress databases make it necessary for developers to be mindful of their data source during theapplication development phase. New development work can be undertaken so that resulting applicationscan run equally well over either data manager. Application developers who have existing Progress 4GL orWebSpeed applications may find that some parts of their application logic may need to be rewritten to caterto these database differences.

High Performance vs. Database IndependenceWhen creating a database independent application, developers look for features that are common among alldatabase managers, to avoid having to re-code applications for each different data source. This can oftenlead to the sacrifice of many features native to an RDBMS (such as word-index capabilities, storedprocedures, or index optimizations). A high performance application on the other hand, will make use ofthese features and any other means available to them in order to obtain maximum performance.

The Progress DataServer technology, when combined with the Progress 4GL and WebSpeed developmenttoolsets, offers a complete environment in which to build applications that provide high performance in adatabase independent environment.

This document aims to highlight some of the issues that developers should be aware of when using theProgress Oracle DataServer to design high performance, database independent applications with theProgress 4GL or WebSpeed toolsets accessing an Oracle database.



DataServer Configurations

There are four possible configurations when using the Progress Oracle DataServer. Details of eachconfiguration are given below.

Local DataServer and Local Oracle DatabaseFigure 1 shows a local DataServer configuration where all the Progress software modules run on a singlemachine. In this case, the Oracle database is also local. This configuration is used most often with terminal-based users and where batch mode processing is required.

Figure 1: Local DataServer and Local Oracle Database Configuration

Local DataServer and Remote Oracle DatabaseFigure 2 shows a local DataServer accessing an Oracle database on another machine through SQL*Netor Net8 (Oracles networking software). Net8 can be used instead of SQL*Net when accessing anOracle8 database. In this configuration there are no Progress processes running on the Oracle RDBMSmachine. This configuration is often used when high performance connectivity is required across a LANor WAN, and there is no requirement for 4GL-based batch processing on Machine 2.

Figure 2: Local DataServer and Remote Oracle Database Configuration

Machine 2

Oracle

ProgressClient

Progress OracleDataServer

SQL*Netor Net8

OracleNetworking

SchemaHolder

SQL*Netor Net8

Machine 1

SchemaHolder

Machine 1

Oracle

Progress OracleDataServer

ProgressClient



Remote DataServer and Local Oracle DatabaseFigure 3 shows a configuration where a client accesses a remote Progress Oracle DataServer throughProgress networking. Here, the Oracle database and the DataServer are running on the same machine.(Note that the schema holder can be located on either the client or the server.) This hybrid environment isoften used when a combination of client/server and host-based processing needs to occur against the Oracledatabase.

Figure 3: Remote DataServer and Local Oracle Database Configuration

Remote DataServer and Remote Oracle DatabaseFigure 4 shows a configuration for a client using remote Progress Oracle DataServer, and accessing anOracle database remote to the DataServer. This configuration could be used when a combination of localand remote clients are required to access an Oracle database on a platform not supported by Progress.

Figure 4: Remote DataServer and Remote Oracle Database Configuration

SQL*Net or Net8 vs. Progress NetworkingThe decision whether to use SQL*Net, Net8 or Progress Networking is influenced by many factors. Apartfrom the deployment flexibility shown in the above configurations, consideration needs to be given tocurrent implementations on client and server platforms. If the Oracle database to be accessed resides on anoperating system not supported by PSC, (such as IBM's OS/390), you can only get to that database byputting the DataServer on a client or middle-tier machine, and using either SQL*Net or Net8 networkingsoftware to get across to the Oracle database. Also, it may be possible that networking communications(either SQL*Net, Net8, or Progress Networking) have already been set up between the client and servermachines. In this instance, introducing new networking stacks on both machines may merely introduceunwanted (and unnecessary) processing overhead.

Informal benchmarking has shown that there are minimal performance differences between using SQL*Netand Progress Networking to get to an Oracle database. In all deployment situations, however, you shouldindividually test your own configurations for the best possible solution for your environment.

OracleProgress OracleDataServer

SchemaHolder Machine 2Machine 1

ProgressClient

SchemaHolder Progress

Networking

Machine 1

ProgressClient

SchemaHolder

Machine 2Progress Oracle

DataServer

SQL*Netor Net8

Machine 3

Oracle

SQL*Netor Net8

OracleNetworking

ProgressNetworking

SchemaHolder



Database Design

Because of the inherent differences between the Progress and Oracle relational database managers, careneeds to be taken when designing a database architecture for Oracle to be accessed by a Progress-basedapplication. The following sections discuss the differences between the Progress and Oracle data managers,and how the DataServer resolves them.

Naming ConventionsThe Oracle database management system has certain naming conventions that must be adhered to fornaming database objects such as tables, columns, sequences, indexes, etc. These conventions forbid the useof some special characters that are otherwise acceptable in a Progress RDBMS. The Oracle productdocumentation will offer more details on characters to be avoided. As a general rule, avoid the use ofhyphens (-) and percent signs (%) in all object names.

Be mindful of any limits on the length of object names within the Oracle database (Progress has amaximum of 32 per table name, Oracle only 30) remembering that the Progress Oracle DataServer mayneed to append extra characters to an object name to support extended Progress 4GL compatibility. Ingeneral, try and limit your object names to 25 characters.

The Oracle database management system has its own set of reserved words that cannot be used to namedatabase objects. Avoid the use of these reserved words (as well as all Progress reserved words) whennaming objects in an Oracle database.

Please refer to the Progress Oracle DataServer Guide for further information.

Database LimitationsDepending on the version of the Oracle RDBMS, there may be certain physical limits imposed by thedatabase that can cause problems when converting a Progress database to this database managementsystem. One example of a particularly problematic limitation is Oracle7 s limit of 254 columns in asingle table. (This limitation has been increased to 1,000 columns in Oracle8.) There are several instanceswhere an equivalent Oracle table will require more columns than its Progress equivalent, such as toaccommodate Progress arrays, case-insensitive indexes, and RECID values. These scenarios are outlined inmore detail below. Appendix A contains a sample Progress 4GL program to calculate the number ofcolumns a Progress table would need in an equivalent Oracle table.

For further information on other limits, please refer to the Progress Oracle DataServer Guide, and yourOracle documentation.

Data TypesThe Oracle data manager has specific data types that vary from those of the Progress database. TheProgress Oracle DataServer translates these data types as closely as possible into Progress equivalents.When a particular data type has more than one valid Progress equivalent, the DataServer supplies a defaultdata type. The Progress schema holder contains these Progress data type mappings for each underlyingcolumn. You can manually change the default data type mapping in the schema holder using the ProgressData Dictionary. One particular example is the single digit data type NUMBER(1) in Oracle. This can mapto a single digit INTEGER data type (9(1)), or a LOGICAL data type in Progress.

For further details on Oracle data types and their equivalent Progress mappings, please refer to the ProgressOracle DataServer Guide.

Additional Database Objects RequiredIn order to make the Progress 4GL 100% compatible with the Oracle database, the Progress OracleDataServer requires that additional columns, indexes and sequences be created in the Oracle database:



If Progress arrays are used within an application, a separate column will need to be created in anOracle table for every element of the array.

If case-insensitive indexes are used within a Progress database, a secondary column and additionalindex need to be created in the Oracle database to support case-insensitive indexed retrieval.

If Progress RECIDs are used within an application, additional columns and sequences must be createdin Oracle to support their use.

These additional database objects can be created automatically when using the Progress-to-Oracleconversion utility, protoora. This utility is described in more detail later in this document.

Each of these scenarios is described in more detail later on in this document. These extra columns andindexes are masked from the developer or end user by use of the Progress schema holder.

Please refer to the Progress Oracle DataServer Guide for further information.

Please note that the creation of multiple fields for array representation, the addition of columns to supportcase insensitive indexing, and RECID columns for scrolling demand close investigation because of limits tothe number of columns per table and the number of components per index imposed by the Oracle7RDBMS. Appendix A contains a sample Progress 4GL program to calculate the number of columns aProgress table would need in an equivalent Oracle table.

ArraysThe Oracle data manager does not support arrays in the way the Progress RDBMS does. However, theProgress Oracle DataServer allows you to extend this array support into an Oracle database. As an example,a Progress array of 12 elements would be implemented in Oracle by creating 12 distinct fields in a certainorder, and with a specific naming convention (outlined in the Progress Oracle DataServer Guide). TheProgress Oracle DataServer will then recognize these fields as forming an array, which the 4GL can accessin its normal fashion.

Please note that the creation of multiple fields for array representation demands close investigation becauseof limits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix A contains asample Progress 4GL program to calculate the number of columns a Progress table would need in anequivalent Oracle table.

Case-Insensitive IndexesBy default, all character indexes defined in a Progress database will be case-insensitive (for example, theletter a is equivalent to A in a sorting algorithm). The Oracle RDBMS does not provide case-insensitive indexing. Therefore, as an example, the letter a will sort differently than its uppercaseequivalent A. The Progress Oracle DataServer can mask this difference by supporting the use of aspecially named column in the Oracle table (storing only uppercase values of the original column), and anindex on that column. If this table is to be updated by non-Progress applications, then an Oracle databasetrigger should also be created to populate this shadow column with an uppercase value of the originalcolumn.

Please refer to the Progress Oracle DataServer Guide for more information on the naming conventions ofthese columns and methods for populating them.

Please note that the addition of columns to support case-insensitive indexing demands close investigationbecause of limits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix Acontains a sample Progress 4GL program to calculate the number of columns a Progress table would needin an equivalent Oracle table.

RECIDsThe Progress Oracle DataServer will support RECID functionality in an Oracle database through the use ofan additional unique integer column on the table (called PROGRESS_RECID). This additional column will



also require an index, and a specially named sequence to populate it. The Progress Oracle DataServer willautomatically increment the sequence, populate the PROGRESS_RECID field, and modify the index whennew records are added to the table through the Progress 4GL interface. If records are to be added to thetable from outside of a Progress environment, the PROGRESS_RECID field will need to be updatedmanually. An Oracle database trigger is best suited to automating this process. Refer to the ApplicationDesign section of this whitepaper for a further discussion of using ROWIDs and RECIDs.

Please note that the creation of PROGRESS_RECID columns demands close investigation because oflimits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix A contains a sampleProgress 4GL program to calculate the number of columns a Progress table would need in an equivalentOracle table.

Word IndexesDue to technical differences between the Oracle and Progress RDBMSs, word indexes are not supportedwith the Progress Oracle DataServer. One possible workaround for this problem involves keeping thecolumn to be word indexed in a separate Progress database with links to the originating record in the Oracledata manager.

Unknown Values / NULLs / Zero-Length Character StringsThe Oracle RDBMS does not support the concept of unknown values (represented as the ? value) as itapplies to a Progress database. The Progress Oracle DataServer extends Oracles functionality by allowingfor this unknown value. This is done by mapping the Progress unknown value to a NULL or a zero-lengthcharacter string in the Oracle database. This could have implications to unique indexing of existing data, asOracle allows only one NULL value per unique index.

Please refer to the Progress Oracle DataServer Guide for full details on how unknown values are handled.

Fixed vs. Variable Length Character Strings in OracleThe Progress RDBMS stores character data in variable length format. This means that a 20 character stringwill always be stored as 20 bytes in the database (when using single byte character sets), while a 16character string will always be stored in 16 bytes, regardless of how the column is defined in the table.Oracle allows both variable and fixed length string storage. If a column in Oracle is defined as type CHARwith 18 characters, then it will store 18 characters, no more and no less. Hence, our 20 character string willbe truncated to 18 characters, and our 16 character string will contain two trailing blanks. Oracle also hasthe VARCHAR2 dataype that allows a column to be defined as being of variable length up to a user-defined maximum limit. This means that any character strings longer than the specified maximum will betruncated. Therefore, a VARCHAR2 column with a maximum length of 18 characters will truncate our 20character string to 18 characters when stored in the Oracle database, but the 16 character string will remain16 characters in length.

Trailing BlanksOracle handles trailing blanks differently than Progress, even when the field is defined as a VARCHAR2character string. This presents problems, particularly when using a SUBSTRING function to obtain a stringto store in the database. This string will be padded with blanks by Oracle if it is not as long as theSUBSTRING definition. This is not a problem when running an application against a Progress database. Asan example, if we use the SUBSTRING(4,4) function on the character string YELLOW, Progress willreturn the three character string LOW. Oracle however, will return the four character string LOW (note one trailing blank space).

As a general rule, it is good practice to trim trailing blanks from character strings before assigning them tothe database.



Progress To Oracle Database Conversion UtilityProgress provides a suite of utilities to convert a Progress database to an equivalent Oracle7 or Oracle8database. You should understand how these utilities work before using them. The utilities will createRECID columns and shadow fields for case-insensitive indexes when necessary, convert arrays in theProgress database to multiple fields in Oracle, determine maximum field lengths for Oracle CHAR andVARCHAR2 datatypes based on the Data Dictionary display formats from the Progress table, and more.Please refer to the Progress Oracle DataServer Guide for more details on these utilities.

The Progress Data Dictionary provides default display masking for formatting character data, so that amaximum length can be applied to the data being displayed (though it does not affect the data being storedin the database). This display format in Progress is optional and has a default value of 8 characters. Whenconverting a Progress database to Oracle, the conversion utility will use this display format to determine amaximum length for the variable length column in Oracle. This default is usually too small to store somecharacter data. In order to work around this, the DataServer will modify the SQL CREATE TABLEstatement for all fields that have a display format of 8 characters to create a maximum column length of 30characters in Oracle. If this length is still not sufficient, the offending character string display formats canbe modified in the Data Dictionary, or the SQL code generated by the conversion utility can be manuallyedited before running the SQL script to create the objects in your Oracle database.

You may also wish to take advantage of functionality provided by the Oracle database (such as tablespaces)to determine optimal data storage and data access configurations. Please refer to your Oracledocumentation to determine how to configure data file creation and placement. In Version 9, the ProgressOracle DataServer allows you to specify tablespace names for tables and indexes generated by theconversion utility. Please refer to the Progress Oracle DataServer Guide for further information.

Please note that the creation of multiple fields for array representation, the addition of columns to supportcase insensitive indexing, and RECID columns for scrolling demand close investigation because of limits tothe number of columns per table and the number of components per index imposed by the Oracle7RDBMS. Appendix A contains a sample Progress 4GL program to calculate the number of columns aProgress table would need in an equivalent Oracle table.



Application Design

The Progress 4GL may behave differently when accessing an Oracle database than it would when accessinga Progress-based one. The following sections discuss these behavioral differences, how the DataServerresolves them, and techniques that should be implemented in application design to allow for both highperformance and database independence.

Unsupported SyntaxDue to inherent differences between the Oracle and Progress RDBMSs, there are some Progress 4GLstatements and functions that do not behave as expected, or will not work with the Progress OracleDataServer. Please refer to the Progress Oracle DataServer Guide for the latest information onunsupported Progress 4GL functionality.

Utilizing Oracle-Specific FunctionalityIn order to potentially improve performance by taking advantage of Oracle technology, the Progress OracleDataServer offers support for several Oracle-specific features including the following:

Stored Procedures

The Progress Oracle DataServer supports the use of Oracle PL/SQL stored procedures, storedfunctions, and packages. These Oracle objects can be called directly from the Progress 4GL viathe RUN STORED-PROC command. By running stored procedures, processing is moved offthe Progress client, onto the database server machine. Stored procedures are useful in reducingnetwork traffic when aggregations of large numbers of records need to be performed, or whenperforming mass modifications to database records.

Native Oracle SQL Syntax Support

The Progress Oracle DataServer provides a function called send-sql-statement that can beused to send native Oracle SQL (utilizing either SQL*Plus or PL/SQL syntax) directly to theunderlying Oracle database. This may be useful in situations where functions or syntaxavailable to the Oracle database manager would be beneficial to the application, or whenapplication processing is better suited to being executed on the server. This SQL syntax will beignored by the Progress compiler in order to support the different Oracle SQL dialects, and assuch, the SQL string may be an arbitrary expression that can only be evaluated at run-time.Therefore, syntax errors will not be detected until application run-time.

Please refer to the Progress Oracle DataServer Guide for more details on using the send-sql-statement stored procedure.

Optimizer Hints

The Oracle database allows the passing of hints to the Oracle optimizer to determine (amongother things) which index to use in resolving a query. The Progress Oracle DataServer supportsthe use of these index hints. In cases where performance might be improved by hinting anindex to Oracle, these hints should be used within the Progress 4GL syntax.

Please refer to the Progress Oracle DataServer Guide for more details on how to use Oraclehints.

TransactionsThe Oracle data manager handles transaction rollback and recovery through its own internal mechanisms,however, Progress 4GL transaction scoping rules still apply.



In Progress, transactions end at the end of the outermost block where an update takes place. When atransaction that updates an Oracle database ends successfully, the Progress Oracle DataServer sends aCOMMIT message to the Oracle data manger. If the transaction is interrupted, Progress sends aROLLBACK message to the Oracle RDBMS.

If you modify data in more than one database in a single transaction (for example, a Progress database andan Oracle database), Progress uses a two-phase commit protocol to minimize the chance of databasecorruption wherever possible. When using distributed Oracle databases, the changes to the Oracle databaseare performed first using Oracles own two-phase commit protocol, then the changes to the Progressdatabase are committed.

Please refer to the Progress Oracle DataServer Guide for more details on using the two-phase commitprotocol.

Stored Procedures and Transaction Scoping

When Oracle stored procedures are called from a Progress procedure, different transactionscoping rules apply. A database modification made through an Oracle stored procedure in asubtransaction will not be rolled back if the main Progress transaction in which it is run isundone. For example, if you are updating records and run a stored procedure in the middle ofthe transaction, and then issue a ROLLBACK statement, the ROLLBACK will not affect anyof the operations executed by the stored procedure, as the stored procedure has its owntransaction scope within the Oracle database management system.

Constraint Violations / Trigger Execution

The Oracle RDBMS will ensure that any Oracle database constraints and database triggers willnot be executed until the record is written to the database. If this isnt handled before thetransaction end (i.e. using either the VALIDATE or RELEASE Progress 4GL statements), theuser may not be able to gain control of the user interface.

If a user attempts to insert or update a column in a unique index, other users attempting toperform a similar update may have to wait until the first user either commits the transaction (inwhich case, the second user will receive a constraint violation), or rolls back the changes (inwhich case the second user will proceed). This is native Oracle RDBMS behavior, and cannotbe circumvented.

TriggersIf applications outside of the Progress environment are accessing the same Oracle tables as a Progress-based application through the Progress Oracle DataServer, then these native applications will only beaffected by Oracles database triggers. If implemented, Progress client triggers will fire in addition to theseOracle database triggers only for Progress-based applications. If there are both Progress client triggers andOracle database triggers, the Progress client triggers will fire before the Oracle database triggers.

You can restrict Progress client triggers from executing when using Oracle databases with the DBTYPEfunction. For example, the following code would only fire a trigger when running on a Progress database:

IF DBTYPE(dbname) = "PROGRESS" THEN DO:{triggers.i}END.

Record LockingBoth the Progress and Oracle databases implement record level locks. However, there are differences in thetypes of locks that can be taken out on a record. These differences are described in more detail below. Ingeneral, it is best to use optimistic record locking to mask these differences. Optimistic locking involvesreading records with NO-LOCK, and re-reading them again at update time with an exclusive lock. This willmean the records are locked for the shortest time possible.



No SHARE-LOCK Support in Oracle

The Progress RDBMS supports the concept of a SHARE-LOCK that is not directly availablein the Oracle database manager. If you are using SHARE-LOCKs within your application,Progress cannot guarantee that a record in your Oracle database is actually locked at all. Youshould implement optimistic locking techniques to reduce data concurrency problems. SpecifyNO-LOCK on record reads wherever possible, as this gives the most scope for internaloptimization and allows you to take advantage of field lists in Version 8 and above of theProgress Oracle DataServer. At time of record update, re-read the record with anEXCLUSIVE-LOCK, and if the two record values are the same, you can proceed to update therecord.

If you need to use an EXCLUSIVE-LOCK, you should hold the lock for as short a time aspossible to reduce locking contention.

The following 4GL code illustrates an example of optimistic locking performed manuallywithin an application.

DEFINE TEMP-TABLE changecust LIKE customer.FIND FIRST customer /* add WHERE criteria here */.IF AVAILABLE customerTHEN DO: /* copy the info to a work area */ BUFFER-COPY customer TO changecust NO-ERROR. /* All update processing should occur to changecust, not customer. Then, at commit time, re-read the record. */ FIND CURRENT customer EXCLUSIVE-LOCK. /* Compare to the customer value before any changes were made. */ IF CURRENT-CHANGED customer THEN DO: MESSAGE "Record changed by another user.". UNDO, RETRY. END. ELSE BUFFER-COPY changecust TO customer.END.

Please refer to the Progress Oracle DataServer Guide for more details on locking techniques.

Automatic Optimistic Locking Support

The Progress Oracle DataServer does not perform optimistic locking by default. With Version9 of the Progress Oracle DataServer, a new DataServer startup parameter (-Dsrv optimistic) isavailable to force the DataServer to use optimistic locking as the default when modifyingrecords.

Cursor RepositioningProgress uses cursors to keep track of where it is within a table. A cursor is like a pointer to consecutiverecords in a table. For example, Progress uses cursors when it processes statements that return a set ofrecords (such as the FOR EACH or OPEN QUERY statements). Progress maintains cursor positioningacross queries. The Progress Oracle DataServer supports this behavior for tables in Oracle that have aunique index on a mandatory integer column or tables that contain the PROGRESS_RECID column.



When a FIND FIRST/LAST statement is issued, Oracle builds a result set that might include every recordin a table. Performance will improve if the statement is qualified with a WHERE clause to reduce the sizeof the result set (however this still will not perform as well as a FOR EACH or OPEN QUERY statement).

Cursor repositioning behaves with the Progress Oracle DataServer as it does with Progress databases,except when an Oracle database fails to find a record. In this case, the cursor in a Progress database islocated after the last record that was read. In the Oracle database, a failed search does not affect the cursorif a single index is used.

For example, assume a result is made up of customer records 1, 2, 3, 4 and 5, and the cursor is positioned atthe last record (i.e. customer number 5).

If a FIND NEXT customer statement is issued (which uses a single index), the cursor moves as follows:

Progress Database: Oracle Database:

Regardless of which data source is used, the Progress 4GL functionality behaves consistently when thisoccurs. The following statement, for example:

IF AVAILABLE customerTHEN DISPLAY customer.ELSE MESSAGE "No customer record found".

will display the message No customer record found in each of the above situations, regardless of wherethe cursor is positioned.

RECIDs and ROWIDsThe Progress Oracle DataServer will support RECID functionality in an Oracle database through the use ofan additional unique indexed integer column on the table (often called PROGRESS_RECID). Theseadditional columns also require indexes and sequences to populate them.

A far better strategy for Progress-based applications (Version 8 and above), is to use the ROWID function.The ROWID function performs in a more consistent manner across Progress and Oracle databases, as wellas eliminating the need for a PROGRESS_RECID column (although it will use it if one is available). Note,however, that the ROWID function causes a newly created record to be written to the Oracle databaseearlier than it would to a Progress database. If you do not assign values to all fields that are defined asmandatory in Oracle for a record, the ROWID function will fail.

By default, the Progress Oracle DataServer designates a column to support the ROWID function. Itevaluates the indexes available for a table and selects one in the following order:

1. PROGRESS_RECID column

If a PROGRESS_RECID column is selected, then both the RECID andROWID Progress 4GL functions can be used in a Progress 4GL program.

cursor

1 2 3 4 5 1 2 3 4 5

cursor(unchanged)

1 2 3 4 5

cursor



2. Unique index on a single, mandatory, NUMBER column with precision



If a record with a cust-num of 111 already exists in the database, the Progress database will return theError Creating Record message, otherwise the record is created as per requested, and displayed from thexcust buffer. However, when using the Progress Oracle DataServer, the customer record will not be visiblein the xcust buffer, as the record will not be written back to the Oracle database until the end of thisprocedure. In order to emulate the behavior expected of a Progress database, the procedure can be modifiedas follows to run against Oracle:

DEFINE BUFFER xcust FOR customer.CREATE customer.ASSIGN customer.cust-num = 111 NO-ERROR.VALIDATE customer NO-ERROR.IF ERROR-STATUS:ERRORTHEN DO: MESSAGE "Error Creating Record".END.ELSE DO: FIND xcust WHERE xcust.cust-num = 111. DISPLAY xcust.END.

The VALIDATE statement forces the record to be written to the Oracle database immediately. The NO-ERROR option ensures that user-defined error processing is invoked. The RELEASE customer NO-ERROR statement can also be used here, but it has the side effect of deleting the record from the clientbuffers. The application would have to refetch the record from the database if it needs to access it again.

Ordering of RecordsThe Progress 4GLs advanced data retrieval statements, FIND table-nameand FOR EACH table-name, coupled with the Progress RDBMS, guarantee that records are returned in aspecific order to the client. There may be instances where the Oracle database manager returns aninconsistent sort order. If your application depends on sorted data, you should always explicitly specifydesired sort order and index criteria in your Progress 4GL statement. This can create performanceoverhead, so it should only be used when the sort order is critical.

Query TuningThe Progress Oracle DataServer provides several features to application developers to fine-tune queries tobe sent to Oracle. Further details on all the following options can be found in the Progress OracleDataServer Guide.

Field Lists

A feature introduced in the Version 8 Progress Oracle DataServer is the option of specifyingfield lists for a query. This allows the Oracle database manager to only send back to the clientthose fields of the record that were requested in the query (rather than every column in therecord). This can dramatically decrease the amount of network traffic in a client/serverenvironment, when records are read. It can also improve performance (to a lesser extent) inhost-based processing environments.

Field lists will only work with FOR EACH or OPEN QUERY statements. In order to takeadvantage of these performance improvements, it is recommended that all FIND statements beconverted to equivalent FOR EACH or OPEN QUERY statements wherever possible.

Lookahead Cursors

The Progress Oracle DataServer caches results sets from the Oracle database to enhanceperformance. It caches as much data as fits in its allocated cache size. Depending on what kindof cursor a query is using the DataServer caches row identifiers or entire records:



Standard cursors The DataServer caches row identifiers for the results set. When arecord needs to be read from the results set, its row identifier is retrieved from the cacheand a new database query is generated to access the entire record.

Lookahead cursors The DataServer caches complete records (or partial records asspecified by a field list). Lookahead cursors fetch as many records as can fit in theallocated cache, limiting the number of database accesses, and thereby improvingperformance. When a record is required, its values are simply retrieved from the cache.This can lead to data consistency problems if a records value in the database was changedby another user after a lookahead cursor was used to read its value.

Using lookahead cursors results in behavior that is different from Progress because they do notsee any changes made to the records in the cache. Specify QUERY-TUNING NO-LOOKAHEAD for behavior that is consistent with Progress (but be aware that performancemay suffer as a consequence).

Progress 4GL vs. SQL

The Progress Oracle DataServer allows you to use different approaches for querying an Oracledatabase. Your application might be able to take advantage of these approaches depending onthe kind of query you are writing and the kind of data you are accessing. These approaches are:

Progress 4GL The DataServer generates optimal PL/SQL for DEFINE QUERY andFOR EACH statements, but you can use the QUERY-TUNING option to customize thequeries that the DataServer passes to Oracle.

Progress SQL SELECT When you use a SQL SELECT statement in a Progressprocedure, the DataServer passes the SQL directly to Oracle. This approach can improveperformance, especially when counting records, and allows you to access certain types ofdata more effectively, such as aggregates.

Oracle PL/SQL or SQL*Plus If you want to use specialized query syntax supportedonly by Oracle's PL/SQL or SQL*Plus, you can use RUN-STORED-PROC send-sql-statement to send the syntax to Oracle.

When retrieving a large number of records using a FOR EACH NO-LOCK or OPENQUERY statement, best performance is obtained by using the lookahead cursor and field listoptions.

Progress/SQL SELECT statements are best for more complex queries (those with subqueries,GROUP BY or HAVING clauses) and queries that perform aggregate functions. TheseProgress/SQL SELECT statements are passed directly to the data manager using ProgressSEND-

SQL functionality on the server. (For the remainder of this document, this technique is termedSQL SELECT pass-through.)

In Progress Version 8.2B and higher, SQL SELECT pass-through also makes use of Oraclebind variables so the SQL code generated by the DataServer is reusable, thereby reducingprocessing time. The SQL that is sent to Oracle using the send-sql-statement stored proceduredoes not use bind variables.

FOR EACH and OPEN QUERY statements (when used with the NO-LOCK andLOOKAHEAD options) tend to perform better than the send-sql-statement stored procedure,because they use array fetches to minimize the number of accesses to the database. Also, ifProgress networking is used, the DataServer will pack multiple rows per network message.

The Progress send-sql-statement stored procedure and Progress/SQL SELECT pass-throughstatements use a single row buffer to fetch records into, and a single result row per networkmessage. The send-sql-statement stored procedure is also useful for massive updates, providedthey do not occur in a subtransaction that needs to be rolled back.



Join-By-SQLDB

Another query tuning option introduced in Progress Version 8 is the ability to direct the Oracledatabase manager to perform a querys join on the server. This is preferable to the defaultaction of sending two result sets down to the client (very costly in a networked environment)and having that client (often a less powerful machine than the server) perform the join.

This JOIN-BY-SQLDB option (in either a FOR EACH or OPEN QUERY statement) shouldperform better than a send-sql-statement stored procedure join for three major reasons:

1. JOIN-BY-SQLDB will do an array fetch.

2. JOIN-BY-SQLDB will ship multiple result rows in a single network message.

3. JOIN-BY-SQLDB will eliminate redundant information.

For example, consider a customer table with exactly 2 customers, each with 10,000 orders, andthe following 4GL code:

FOR EACH customer, EACH order OF customer: . . . .END.

If the server performs the join, the client will receive the first customer, all of their 10,000order rows, and then the second customer and their 10,000 order rows. If this join is performedwith a send-sql-statement stored procedure (or Progress/SQL SELECT pass-through), 20,000result rows will be shipped to the client. Each of the first 10,000 result rows will contain all ofthe columns from the customer table with the values for the first customer duplicated 10,000times. This will be followed by a similar arrangement for the second customer and their orders.

Error MessagingMany of Oracles error messages do not provide clear descriptions of the problems being encountered. Ifyour application will run against both Progress and Oracle RDBMSs, you may want to consider handlingerror messages through Progress to provide consistent behavior across both Progress and Oracle databases.

Distributed and Batch Processing with an Oracle DatabaseProgress 4GL batch programs or Progress AppServer programs have the same restrictions that apply tointeractive client Progress 4GL programs noted throughout this document. If any batch programs are toperform mass updates or deletes, you may wish to investigate the use of stored procedures as this willimprove performance (due to reduced messaging). If any batch processing is to occur, careful considerationmust be given to the DataServer configuration, as the Progress Oracle DataServer would be required on thebatch or application server, instead of the client machine.

Mass Database ModificationsDue to the amount of network traffic that is involved in ensuring compatibility with the Progress OracleDataServer, mass modifications (e.g. repeated inserts, updates or deletes) of an Oracle database are bestsuited to being executed from within an Oracle stored procedure (using the Progress send-sql-statementstored procedure to execute it).

Oracle Query ResolutionAll query resolution will be performed by the Oracle optimizer. The Progress Oracle DataServer willgenerate index hints on queries where appropriate before sending them to Oracle, however, care should betaken when selecting the Oracle optimization method, as all hints will be ignored when using Oracles rule-based query optimization.



INDEXED-REPOSITION SupportThe INDEXED-REPOSITION option of the OPEN QUERY statement is only supported by Version 9 (andabove) of the Progress Oracle DataServer. In order for applications accessing an Oracle database to use thisfunctionality, the query must be defined as SCROLLING, and the table must support the ROWID function.The INDEXED-REPOSITION phrase is not supported on a view that does not have a selectable ROWID.

Refer to Section 5.7 for more information on using ROWIDs with the Progress Oracle DataServer.



Deployment Considerations

Once an application has been created with the Progress Oracle DataServer, there are several deploymentfactors that can affect the application's performance and the DataServer's administration. The followingsections discuss these different options and how they influence the application execution environment.

Building Progress ExecutablesThe UNIX installations of the Progress Oracle DataServer (prior to Version 9) require you to build a set ofnew Progress executables to incorporate the appropriate Oracle libraries. The exact executables that need tobe built depend upon the configuration required. As of Version 9, the Progress Oracle DataServer providespre-built executables (one set for Oracle7, one for Oracle8) linking in Oracle objects installed in sharedlibraries, no longer requiring that the executables be built manually on platforms where Oracle supplies ashared library.

Please refer to the Progress Oracle DataServer Guide for additional information on determining when newexecutables need to be created.

Schema HoldersThe schema holder contains information about the data definitions of an Oracle database. This informationincludes a description of Oracles structure, the tables, the fields within the tables, and the indexes. Theschema holder contains no user-application data. The Progress Oracle DataServer accesses the schemaholder only when it compiles procedures and at the beginning of a run-time session when loading datadefinitions into memory.

As a schema holder is normally run in read-only mode, concurrent access to it by multiple users is notnecessary. The schema holder may also be able to store Progress objects required by applications. Forexample, the RBREPORT table accessed by the Progress Report Builder could be stored within the schemaholder, without requiring a separate database connection. (In this instance, however, the schema holdercannot be connected to in read-only mode.)

For performance reasons, schema holders are best placed locally on the client rather than centrally on theserver (although this difference is much less noticeable when using a fast Ethernet connection as opposedto 10BaseT configuration).

If a schema holder is desired on a server (for maintenance reasons), it is possible to use the cache databaseconnection parameter to keep a cached copy of the schema holder on the clients local disk, for fasterconnection times. Refer to the Progress System Administration Guide for further details on the cacheparameter.

Oracle Database Changes and the Schema HolderIf the structure of the underlying Oracle database schema changes in any way (for example, adding a tableor view, or modifying the table by adding a new column), the Progress schema holder must be updated toreflect those changes.

Utilities are provided with the Progress Oracle DataServer to verify that the schemas for the Oracledatabase and the schema holder match, or to automatically update them if they dont. Refer to the ProgressOracle DataServer Guide for more details on these utilities.

Incremental Schema Difference FileAs of Progress Version 9, the Progress Oracle DataServer offers a utility for converting a Progress .df file(containing incremental changes made to a Progress schema) into a .sql file. This .sql file contains thesechanges in a format suitable for execution against an Oracle database. This .sql file can then be run againstthe Oracle tables to replicate the schema changes. This utility can also optionally create a delta.df file that



can be applied directly to the existing schema holder. This will allow all formatting information previouslyapplied to the schema holder to be retained for unaffected objects.

Code Recompilation Due to Schema ChangesOften, a central database is accessed by more than one application. These applications will typicallyshare the data in the database tables, without concern for other applications. Oracles concurrencytechniques ensure that consistency is maintained at the data level, regardless of the application. However,there may be situations where one application requires changes to be made to an existing table structurethat is referenced by other applications (for example, adding, deleting or renaming columns). Often, in aProgress environment, such data object changes will force recompilation of all Progress code accessing thisobject. This is due to a different CRC (cyclic redundancy check) value being calculated on that object afterthe change. This recompilation phase is an inconvenience, especially when such changes were caused by adifferent application and do not affect the application requiring recompilation.

This issue can be avoided with the Oracle database with the use of Oracle views. By creating a view of thetable containing only those columns required by the application, any changes made to the underlying table,as long as they do not affect the views definition, will be transparent to the application. As the view isbased on a single table, all normal Progress functionality can be performed on this view as though it werethe original table. Assume the following customer table definition as an example:

cust_num name credit_limit sales_rep(integer) (char) (decimal) (char)

1 Lift Line Skiing 5,000.00 BBB2 Sails Afloat 2,300.00 ARP. . . .. . . .

If we create a view (called, for example, v_customer), based on the above customer table, and defined asthe following:

cust_num name credit_limit sales_rep(integer) (char) (decimal) (char)

our application can now access the data through this view as though it were the original table (which,essentially, it is). To mask the differences in object naming (the tables name is customer, and the view,v_customer), we can change the name of the view in the Progress schema holder to customer. The mappingto the view remains the same, and our application will not need to be changed.

What happens when a third-party application requires a change to the structure of our base customer table?The answer would depend on the types of changes occurring. The following chart specifies the types ofchanges possible on a table structure, and whether or not the application needs recompilation under thosecircumstances.



Change Description Referenced inView?

RecompilationNeeded?

Adding a column No NoAdding a column Yes YesDropping a column No NoDropping a column Yes YesAdding an index No NoAdding an index Yes NoDropping an index No NoDropping an index Yes No

Creating a view does not affect indexing and query resolution. Indexes behave just as they would if youwere accessing the table directly.

Please note that if a column is added to the underlying table (and this column is not reflected in the view),and you attempt to undo the delete of a row in this view from within a subtransaction, the undo will fail.The Progress Oracle DataServer will generate an error and rollback the entire transaction.

Refer to the Progress Oracle DataServer Guide for more details on using Oracle views.

Startup ParametersYou should be aware of, and test your applications with, the DataServer (-Dsrv) connection parameter andits various options. The following options are available for use with the Progress Oracle DataServer:

qt_bind_where / qt_no_bind_where

Specifies whether the DataServer uses Oracle bind variables for values in WHERE clauses.

qt_cache_size

Specifies the size of the cache (in bytes or records) for information used by lookahead orstandard cursors.

qt_debug / qt_no_debug

Specifies whether the DataServer should print debugging information that it generates for thequery to the dataserv.lg file.

qt_lookahead / qt_no_lookahead

Specifies whether the DataServer uses lookahead or standard cursors.

optimistic

Specifies whether the DataServer is to use optimistic locking techniques as the default whenlocking records.

skip-schema-check

Specifies the DataServer is to bypass verifying schema definitions match between Oracledatabase and the schema holder.

Refer to the Progress Oracle DataServer Guide for more details on these parameters.

Migrating Multiple Progress DatabasesAdditional consideration should be given if your current application requires multiple Progress databases.You must determine how you will handle this in Oracle. Will you have one large database or will you keepyour existing database architecture? One large Oracle database may result in conflicts over tables and/or



fields with a common naming convention. Having many Oracle databases requires extra processingresources, as well as the use of SQL*Net or Net8 for connectivity.

Progress Runtime LicensesThe Progress Oracle DataServer is available as a runtime only license. A Progress client license isnecessary if the application is on a machine remote to the DataServer. However there are a few issues thatmust be considered in a runtime environment.

Database Conversion Utilities

The Progress to Oracle Database Conversion Utility is not immediately available with theruntime version of the Progress Oracle DataServer. This utility is provided in encrypted sourcecode format that can only be executed when the client is started with the -rx startup option.

Please refer to the Progress System Administration Reference for more information on the -rxclient startup option.

DataServer and Database Administration Utilities

The utilities generally used for DataServer administration under the Data Administration orData Dictionary tools will not be immediately available in a run-time environment. Theseutilities are provided in encrypted source code format to avoid end-users inadvertentlymodifying the database. To view these utilities with a run-time license, start up the client withthe -rx option.

Please refer to the Progress System Administration Reference for more information on the -rxclient startup option.



Troubleshooting and Performance Tuning

The Progress Oracle DataServer provides several features and utilities to allow application developers tosuccessfully debug programs and fine-tune application execution.

The following sections outline these utilities and enhancements, and how they can be used in applicationdevelopment and deployment environments.

Query/Browse PerformanceThe DEFINE BROWSE statement relies on a unique record identifier for forward and backward scrolling,hence a valid ROWID or RECID should be made available for that table.

Version 7 Progress Oracle DataServer Performance

The largest area of concern surrounding performance involves querying large sets of data. AGET LAST QUERY statement will cause a complete set of RECIDs to be gathered beforerepositioning the query at the last record (Note: this is no different than what happens with aProgress database today). Depending on the situation it can be faster to reopen the query inreverse order.

Another technique would be to obtain the ROWID of the last row by using a FIND statement,and then repositioning the query to that ROWID. Regardless of the technique used, it isimportant that all browsers be tested thoroughly.

Version 8 Progress Oracle DataServer Enhancements

Progress Version 8 introduced tremendous performance enhancements specifically designed toaddress performance-related concerns. These enhancements include Field Lists and LookaheadCursors which are described in more detail in the Application Design section of thiswhitepaper.

Version 9 Progress Oracle DataServer Enhancements

Progress Version 9 has improved performance of the DataServer by adding features such asoptimistic locking, skip schema check and INDEXED-REPOSITION support. Each of theseare described in more detail below, and in the Application Design section of this whitepaper.

Skipping Schema VerificationWhen executing .r-code, the Progress Oracle DataServer checks the data definitions of the Oracle databaseto make sure they match the schema definitions in the schema holder. If they do not match, the DataServerreturns an error. Unmatched definitions can result in the corruption of your Oracle database. However,verifying the definitions is time consuming in a product scenario. The -Dsrv skip-schema-check startupparameter bypasses the checking of schema definitions. Use this parameter with caution, as it will notdetect discrepancies between the schema in the schema holder and the data definitions in the Oracledatabase. If it continues to process queries, inserts, and deletions, the Oracle database might becomecorrupted.

Debugging DataServer ApplicationsThe Version 8 Progress Oracle DataServer introduced the ability to print debugging information aboutqueries made to Oracle generated by the DataServer. This information is captured in the dataserv.lg file.Seven different levels of debugging information can be captured (along with the default of no information).



Debug SQL

This option prints out the SQL code that the DataServer executes against the Oracle DBMS.For example, the following 4GL code:

FIND state "NH" NO-ERROR.FOR EACH customer FIELDS (name) NO-LOCK, EACH order fields () OF customer NO-LOCK:END.

will generate the following qt_debug,SQL information in the dataserv.lg file:

06:41:39 OCI call oparse sqlcrc = 1858606:41:39 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:41:39 OCI call oparse sqlcrc = 1640206:41:39 SELECT T0.progress_recid unique_int_0, T0.CUST_NUM, T0.U##NAME, T0.NAME,T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0, SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM = T0.CUST_NUM)

Debug Extended

This option prints out additional information to the DEBUG SQL option, such as the executionof cursors, and array processing statistics.

The following 4GL program (as above):

FIND state "NH" NO-ERROR.FOR EACH customer FIELDS (name) NO-LOCK, EACH order fields () OF customer NO-LOCK:

END.

will produce the following output when used with qt_debug,extended:

06:41:44 OCI call oopen cc = 106:41:44 OCI call oparse sqlcrc = 1858606:41:44 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid

FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:41:44 OCI call oexfet 06:41:44 omru 06:41:44 OCI call oopen cc = 206:41:44 OCI call oparse sqlcrc = 1640206:41:44 SELECT T0.progress_recid unique_int_0,T0.CUST_NUM,T0.U##NAME,T0.NAME, T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0, SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM = T0.CUST_NUM)06:41:44 OCI call oexfet 06:41:45 omru 06:41:45 omru 06:41:45 Cursor Rows processed 20706:41:45 Number of array fetches 306:41:45 Number of rows fetched 20706:41:45 Number of array rows 7806:41:45 Number of array columns 606:41:45 Number of tables 206:41:45 Space for one row 10406:41:45 Requested cache size 819206:41:45 Actual cache size used 811206:41:45 OCI call oclose cc = 306:41:4506:41:45 Cursor Rows processed 006:41:45 OCI call oclose cc = 2



Debug Cursor

This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 18835with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by theDataServer, along with detailed information about cursor usage (such as opening and closingof cursors).



END.

will produce the following output when used with qt_debug,cursor:

06:41:46 OCI call oopen cc = 106:41:46 OCI call oparse sqlcrc = 1858606:41:46 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:41:46 OCI call oexfet 06:41:46 OCI retr oexfet rc = 140306:41:46 omru 06:41:46 OCI call oopen cc = 206:41:46 OCI call oparse sqlcrc = 1640206:41:46 SELECT T0.progress_recid unique_int_0, T0.CUST_NUM, T0.U##NAME, T0.NAME, T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0, SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM = T0.CUST_NUM)06:41:46 OCI call oexfet 06:41:47 omru 06:41:47 omru 06:41:47 Cursor oparse: 1 (0 kyr)06:41:47 Cursor oexec : 0 (0 kyr)06:41:47 Cursor oexfet: 1 (0 kyr)06:41:47 Cursor ofetch: 0 (0 kyr)06:41:47 Cursor ofen : 2 (0 kyr)06:41:47 Cursor obnd* : 0 (0 kyr)06:41:47 Cursor odefin: 6 (0 kyr)06:41:4706:41:47 Cursor Rows processed 20706:41:47 Number of array fetches 306:41:47 Number of rows fetched 20706:41:47 Number of array rows 7806:41:47 Number of array columns 606:41:47 Number of tables 206:41:47 Space for one row 10406:41:47 Requested cache size 819206:41:47 Actual cache size used 811206:41:47 OCI call oclose cc = 306:41:47 Cursor oparse: 1 (0 kyr)06:41:47 Cursor oexec : 0 (0 kyr)06:41:47 Cursor oexfet: 1 (0 kyr)06:41:47 Cursor ofetch: 0 (0 kyr)06:41:47 Cursor ofen : 0 (0 kyr)06:41:47 Cursor obnd* : 1 (0 kyr)06:41:47 Cursor odefin: 1 (0 kyr)06:41:47



06:41:47 Cursor Rows processed 006:41:47 OCI call oclose cc = 206:41:47 OCI call oexec : 206:41:47 OCI call odefin: 706:41:47 OCI call oopen : 306:41:47 OCI call oclose: 206:41:47 OCI call obndrn: 106:41:47 OCI call oparse: 406:41:47 OCI call oexfet: 206:41:47 OCI call ofen : 2

Debug Databind

This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 1029with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by theDataServer, along with information about OCI bind variables and parameters passed to Oracle.



END.

will produce the following output when used with qt_debug,databind:

06:41:51 OCI call oparse sqlcrc = 1858606:41:51 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:41:51 OCI call obndrn 06:41:51 OCI parm obndrn 06:41:51 type 5 var:1 addr: 0x6dd08c size 32 value: 'NH'06:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 3 var :1 addr: 0x6dd0e4 size 406:41:51 OCI call oparse sqlcrc = 1640206:41:51 SELECT T0.progress_recid unique_int_0, T0.CUST_NUM, T0.U##NAME,T0.NAME, T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0,SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM =T0.CUST_NUM)06:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 3 var :1 addr: 0x6e5350 size 406:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 5 var :2 addr: 0x6e5488 size 2606:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 5 var :3 addr: 0x6e5c74 size 2206:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 5 var :4 addr: 0x6e6328 size 2206:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 3 var :5 addr: 0x6e69dc size 406:41:51 OCI call odefin 06:41:51 OCI parm odefin 06:41:51 type 5 var :6 addr: 0x6e6b14 size 26



Debug Performance

This option (available with theVersion 9 Progress Oracle DataServer, and as DEBUG 55775with the Version 8 Progress Oracle DataServer only) prints out the SQL generated by theDataServer, along with information about cursor usage (such as opening and closing ofcursors), and timings (in mircoseconds) for Oracle SQL execution.


FIND state "NH" NO-ERROR.FOR EACH customer FIELDS (name) NO-LOCK, EACH order fields () OF customer NO-LOCK:END.

will produce the following output when used with qt_debug,performance:

06:41:56 OCI call oopen cc = 106:41:56 OCI retr oopen rc = 0 (2246 us)06:41:56 OCI call oparse sqlcrc = 1858606:41:56 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:41:56 OCI retr oparse rc = 0 (2262 us)06:41:56 OCI call obndrn 06:41:56 OCI retr obndrn rc = 0 (927 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (769 us)06:41:56 OCI call oexfet 06:41:56 OCI retr oexfet rc = 1403 (5889 us)06:41:56 omru 06:41:56 OCI call oopen cc = 206:41:56 OCI retr oopen rc = 0 (1975 us)06:41:56 OCI call oparse sqlcrc = 1640206:41:56 SELECT T0.progress_recidunique_int_0,T0.CUST_NUM,T0.U##NAME,T0.NAME, T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0,SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM =T0.CUST_NUM)06:41:56 OCI retr oparse rc = 0 (2941 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (883 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (810 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (769 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (763 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (767 us)06:41:56 OCI call odefin 06:41:56 OCI retr odefin rc = 0 (863 us)06:41:56 OCI call oexfet 06:41:56 OCI retr oexfet rc = 0 (55993 us)06:41:56 OCI call ofen 06:41:56 OCI retr ofen rc = 0 (46923 us)06:41:56 OCI call ofen 06:41:56 OCI retr ofen rc = 1403 (33092 us)06:41:56 omru 06:41:56 omru 06:41:5606:41:56 Cursor oparse: 1 (2941 us)06:41:56 Cursor oexec : 0 (0 us)06:41:56 Cursor oexfet: 1 (55993 us)06:41:56 Cursor ofetch: 0 (0 us)06:41:56 Cursor ofen : 2 (80015 us)06:41:56 Cursor obnd* : 0 (0 us)06:41:56 Cursor odefin: 6 (4855 us)06:41:5606:41:56 Cursor Rows processed 207



06:41:56 Number of array fetches 306:41:56 Number of rows fetched 20706:41:56 Number of array rows 7806:41:56 Number of array columns 606:41:56 Number of tables 206:41:56 Space for one row 10406:41:56 Requested cache size 819206:41:56 Actual cache size used 811206:41:56 OCI call oclose cc = 306:41:56 OCI retr oclose rc = 0 (2405 us)06:41:5606:41:56 Cursor oparse: 1 (2262 us)06:41:56 Cursor oexec : 0 (0 us)06:41:56 Cursor oexfet: 1 (5889 us)06:41:56 Cursor ofetch: 0 (0 us)06:41:56 Cursor ofen : 0 (0 us)06:41:56 Cursor obnd* : 1 (927 us)06:41:56 Cursor odefin: 1 (769 us)06:41:5606:41:56 Cursor Rows processed 006:41:56 OCI call oclose cc = 206:41:56 OCI retr oclose rc = 0 (2248 us)06:41:56 OCI call oexec : 206:41:56 OCI call odefin: 706:41:56 OCI call oopen : 306:41:56 OCI call oclose: 206:41:56 OCI call obndrn: 106:41:56 OCI call oparse: 406:41:56 OCI call oexfet: 206:41:56 OCI call ofen : 2

Debug Summary

This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG1073797455 with the Version Progress Oracle DataServer only) gives information on cursorsand timing in summary form as a Progress data (.d) file.

Debug Verbose

This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 122879with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by theDataServer, array processing statistics, information about cursor usage (such as opening andclosing of cursors), along with information about OCI bind variables and parameters passed toOracle, and timings (in mircoseconds) for Oracle SQL execution.



END.

will produce the following output when used with qt_debug,verbose:

06:42:01 orgetnext06:42:01 new 0x006:42:01 OCI call oopen cc = 106:42:01 OCI retr oopen rc = 0 (1938 us)06:42:01 Calling idbuf_init from cursor_start06:42:01 new 0x006:42:01 cursor_start06:42:01 new 0x206:42:01 Query flags table 0:06:42:01 WHERE COMPAT06:42:01 HAS_RID IDXHINT06:42:01 Query flag2 table 0:06:42:01 SLO_CSR06:42:01 IGN_FL BIG_RNF



06:42:01 Query flag3 table 0:06:42:01 NCL_SEL06:42:01 OCI call oparse sqlcrc = 1858606:42:01 SELECT /*+ INDEX_ASC(T0 STATE##STATE) */ progress_recid FROM SPORTS.STATE T0 WHERE (U##STATE = upper(:1)) order by U##STATE06:42:01 OCI retr oparse rc = 0 (2232 us)06:42:01 OCI call obndrn 06:42:01 OCI parm obndrn 06:42:01 type 5 var:1 addr: 0x6dd458 size 32 value: 'NH'06:42:01 OCI retr obnrn rc = 0 (2232 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 3 var :1 addr: 0x6dd4c4 size 406:42:01 OCI retr odefin rc = 0 (2105 us)06:42:01 OCI call oexfet 06:42:01 OCI retr oexfet rc = 1403 (6082 us)06:42:01 cursor_fetch OC_DIR_FORW06:42:01 NL 0x2206:42:01 omru 06:42:01 OCI call oopen cc = 206:42:01 OCI retr oopen rc = 0 (2125 us)06:42:01 Query flags table 0:06:42:01 HAS_RID NATDATE06:42:01 Query flag2 table 0:06:42:01 ARY_FET ARY_MSG06:42:01 FLD_LST JOIN_SV BIG_RNF06:42:01 Query flag3 table 0:06:42:01 NCL_SEL06:42:01 Query flags table 1:06:42:01 WHERE COMPAT06:42:01 HAS_RID NATDATE06:42:01 Query flag2 table 1:06:42:01 ARY_FET ARY_MSG06:42:01 FLD_LST BIG_RNF06:42:01 Query flag3 table 1:06:42:01 NCL_SEL06:42:01 OCI call oparse sqlcrc = 1640206:42:01 SELECT T0.progress_recid unique_int_0, T0.CUST_NUM, T0.U##NAME,T0.NAME, T1.progress_recid unique_int_1, T1.CUST_NUM FROM SPORTS.CUSTOMER T0, SPORTS.ORDER_ T1 WHERE (T1.CUST_NUM =T0.CUST_NUM)06:42:01 OCI retr oparse rc = 0 (2927 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 3 var :1 addr: 0x6e5b30 size 406:42:01 OCI retr odefin rc = 0 (2222 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 5 var :2 addr: 0x6e5c68 size 2606:42:01 OCI retr odefin rc = 0 (2116 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 5 var :3 addr: 0x6e6454 size 2206:42:01 OCI retr odefin rc = 0 (2107 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 5 var :4 addr: 0x6e6b08 size 2206:42:01 OCI retr odefin rc = 0 (2104 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 3 var :5 addr: 0x6e71bc size 406:42:01 OCI retr odefin rc = 0 (2243 us)06:42:01 OCI call odefin 06:42:01 OCI parm odefin 06:42:01 type 5 var :6 addr: 0x6e72f4 size 2606:42:01 OCI retr odefin rc = 0 (2109 us)06:42:01 OCI call oexfet 06:42:01 OCI retr oexfet rc = 0 (56932 us)06:42:01 OCI call ofen 06:42:01 OCI retr ofen rc = 0 (47531 us)



06:42:01 OCI call ofen 06:42:02 OCI retr ofen rc = 1403 (32269 us)06:42:02 omru 06:42:02 omru 06:42:02 Cursor oparse: 1 (2927 us)06:42:02 Cursor oexec : 0 (0 us)06:42:02 Cursor oexfet: 1 (56932 us)06:42:02 Cursor ofetch: 0 (0 us)06:42:02 Cursor ofen : 2 (79800 us)06:42:02 Cursor obnd* : 0 (0 us)06:42:02 Cursor odefin: 6 (12901 us)06:42:02 Cursor Rows processed 20706:42:02 Number of array fetches 306:42:02 Number of rows fetched 20706:42:02 Number of array rows 7806:42:02 Number of array columns 606:42:02 Number of tables 206:42:02 Space for one row 10406:42:02 Requested cache size 819206:42:02 Actual cache size used 811206:42:02 OCI call oclose cc = 306:42:02 OCI retr oclose rc = 0 (2263 us)06:42:02 Cursor oparse: 1 (2232 us)06:42:02 Cursor oexec : 0 (0 us)06:42:02 Cursor oexfet: 1 (6082 us)06:42:02 Cursor ofetch: 0 (0 us)06:42:02 Cursor ofen : 0 (0 us)06:42:02 Cursor obnd* : 1 (2232 us)06:42:02 Cursor odefin: 1 (2105 us)06:42:02 Cursor Rows processed 006:42:02 OCI call oclose cc = 206:42:02 OCI retr oclose rc = 0 (2156 us)06:42:02 OCI call oexec : 206:42:02 OCI call odefin: 706:42:02 OCI call oopen : 306:42:02 OCI call oclose: 206:42:02 OCI call obndrn: 106:42:02 OCI call oparse: 406:42:02 OCI call oexfet: 206:42:02 OCI call ofen : 206:42:02 (pid 25267) LOCAL Oracle USER pdb: oldbn ldb: oldbn Logoff from dataserver db as user sports/*****. (2690)



Appendix A

Sample 4GL Program To Calculate The Number Of Fields Required For A Progress Table in anOracle Database

DEFINE VARIABLE c AS INTEGER NO-UNDO.FOR EACH _file WHERE NOT _file._file-name BEGINS "_": /* Initialize one field for the progress_recid column. */ c = 1. FOR EACH _field OF _file:

/* Add a column for every field, and a new column for every extent within a field. */ c = c + (IF _field._extent > 0 THEN _field._extent ELSE 1).

/* If an indexed field is case insensitive add a column for its uppercase value. */ IF (_field._data.type = "character") AND (NOT _field._fld-case) AND (CAN-FIND(_index-field OF _field)) THEN c = c + 1. END. DISPLAY _file._file-name FORMAT "X(32)" " table will need " c " fields" WITH NO-LABELS.END.

Progress and WebSpeeed are registered trademarks of Progress Software Corporation. Progress AppServer is a trademark of Progress SoftwareCorporation. Oracle is a registered trademark of Oracle Corporation. All other trademarks and registered trademarks, marked and not marked, are theproperty of their respective owners.

Copyright 1998 Progress Software CorporationAll rights reserved.

oracle dataserver

Documents