GIOS & Oracle Migration



Upgrading the Database

1 Migrating the Database to Oracle 10g Rel. 2

Upgrading an Oracle Database release will take just 1 or 2 hours - but the preparation steps require some work to be done before and there are a few useful things to implement afterwards to get the most out of Oracle Database 10gR2.

An Oracle Database upgrade happens 'in place' - i.e. the data doesn't get touched, changed or moved.

Be aware that you need to spend the largest amount of time for the preparation steps. Testing is the key word. Not only test just the applications running against the database but keep an eye on performance and save performance key data like execution plans for long-running-queries, overall system performance etc. before doing the upgrade. Utilize the STATSPACK package delivered with each Oracle database release and export the STATSPACK user before the upgrade process.

Check also Metalink Note 161818.1 for any known upgrade related issues and the certification information also available there. Install the desired Oracle software into a new Oracle home directory and apply the newest available patches into it. If the test phase has been finished then do a complete online backup of your Oracle database with RMAN.

The easiest way to go through the upgrade process is using the graphical tool Database Upgrade Assistant (DBUA). This is the Oracle recommended solution for doing the upgrade. Alternatively you can run the upgrade script but DBUA will do all necessary changes and guide you through the whole process.

When DBUA has finished the upgrade then do final upgrade checks and verify that everything is working fine. DBUA will leave the COMPATIBLE parameter in the lowest possible setting in Oracle Database 10gR2: 9.2.0. This means that the new 10g features aren't enabled. To use features like Online Segment Shrink, Flashback and Tuning & Diagnostic capabilities you'll have to change COMPATIBLE to at least 10.2.0 and restart the database.

A few additional steps can be useful:

• changing the tablespace management from dictionary managed to locally managed,

• migrating LONG and LONG RAW data to LOBs,

• utilising and benefiting from Automatic Undo Management.

For an step-by-step guidance have a look at Metalink Note 316889.1

List of Links

Documentation

10g Rel. 2 Upgrade Guide

←

10g Rel. 2 New Features Guide

←

Oracle By Example

Upgrade with DBUA

←  viewlet_swf.html

Important Metalink Notes

10g Rel. 2 Upgrade Checklist

←

10g Rel. 2 Alerts

←

10g Rel. 2 Upgrade with Standby

←

10g Rel. 2 Rolling Upgrade

←

White Papers

10g Rel. 2 Rolling Upgrade

←

10g Rel. 2 TTS Upgrade

←

10g Rel. 2 TTS-OS-Migration

←

2 Some specifics about the Oracle Database Upgrade

When upgrading the Oracle database, you may find some problems in your GIOS code. For example:

• If the Default Value of a Parameter for Functions or Procedures in the Spec and Body Do Not Match

In previous releases, PL/SQL quietly ignored this error and used the default value specified in the spec (ignoring the possibly different value in the body). Also, if there is no default value specified in the spec, and a default value is specified in the body, then the default value in the body is ignored.

In Oracle9i, PL/SQL will flag such discrepancies as errors. It is recommended to fix the code, if such errors are reported, to avoid any possible future bugs.

• Datetime and Interval Data types

When a database is upgraded to Oracle9i, the database time zone is set to the time zone of the environment variable ORA_SDTZ. If ORA_SDTZ is not set, the database time zone is set to the time zone of the operating system clock. If the time zone of the operating system clock is not set or is not valid, the database time zone defaults to UTC (Coordinated Universal Time (formerly known as Greenwich Mean Time (GMT)))

Old Oracle DATE data with time portion can be migrated to either TIMESTAMP to support fractional seconds or TIMESTAMP WITH LOCAL TIME ZONE to support time zone adjustments in addition to fractional seconds without having legacy data rewritten. An ALTER TABLE statement must be explicitly issued to modify a DATE column to a TIMESTAMP column or a TIMESTAMP WITH LOCAL TIME ZONE column.

• SYS Schema Restrictions

In previous versions of the database when a role or user was granted the SELECT ANY TABLE or the EXECUTE ANY PROCEDURE privilege, this applied to SYS owned objects as well as all the others. This is no longer the case; explicit grants must be made to SYS owned objects if access is required to them from other schemas. Granting to a role is not always the solution, SYS objects that are referenced from within a procedure or function may need explicit grants to the Oracle user. An Oracle initialization parameter called 07_DICTIONARY_ACCESSIBILITY is provided to allow installations to negate this change but it would be wise to address the access to SYS owned objects as soon as possible as this parameter maybe withdrawn in future Oracle releases.

• Oracle Optimiser

Oracle9i contains a significant number of optimizer enhancements that are either new or have not been enabled by default in previous releases. Upgrading an existing application to Oracle9i could therefore result in a large number of changes in execution plans. For a mature application, changes in behaviour may introduce an element of risk.

Customers who wish to minimize execution plan changes can do so by means of the OPTIMIZER_FEATURES_ENABLE initialization parameter. Setting the value of this parameter to an earlier release, for example, release 8.1.7, makes Oracle use only those optimizer features that were enabled by default in that release, something that will reduce the likelihood of changes in execution plans when upgrading from that release.

The Oracle Plan Stability feature can also be used to preserve old behaviour when upgrading to a new release.

Migrating Forms

1 The easy way to Forms Migration

Why migrating?

To get all the benefit from official Oracle Support Service and to use new and productive features, it is necessary to upgrade existing Oracle Forms applications to the latest release (i.e. Forms 10gR2). Because this release is only available in a web-deployed architecture the upgrade process is commonly referred to as ‘Forms Migration to the Web’.

By migrating your applications to WebForms you benefit not only from a lot of new functionality but you are also entitled to get full support services from Oracle like bug fixes, patches etc.

The official statement from Oracle about the long-term strategy concerning Oracle Forms, Reports and Designer can be read in the Tools Statement of Direction:

(

Good preparation is half the work

For a successful migration it is indispensable to have a good preparation and to treat the whole process as an IT project.

It is a good start to visit the Oracle Forms Upgrade Center, a web page with condensed information about migration of Oracle Forms:

(

To get a well-assembled and synchronized environment you should decide which version of which component your future OPUS landscape will consist of.

In that respect you have to align the following components:

- Web Browser

- Java Plug-In (JVM)

- Desktop Operating System

- Oracle Application Server

- Operating System for the Application Server Host

- Oracle Database

- Operating System for the Oracle Database Server Host

The supported combinations for these components (certification) can normally be found in the Certify Section of Oracle Metalink:

(

You should also check the recommendations of CGI for their GIOS/OPUS application.

A permanently updated certification of different browsers and Java Plug-Ins for Oracle Forms can be found under:

( Forms 9.0.4



( Forms 10.1.2.

How to migrate?

Before starting in most cases management would like to know how much effort it will take to migrate the application to WebForms.

So normally you would begin with an analysis of the existing Forms application (forms, menus, library modules).

This can be sometimes difficult when the application is quite old and there is a lack of documentation or developers who have a deeper insight into it.

But there are tools available which can help in such a situation by automatically analyzing modules, counting and documenting functionality and detecting dependencies.

It’s a good idea to categorize existing Forms modules into 3 to 5 different groups based on their size and complexity. In many applications you have only a few very large and complex forms and a lot of small and simple forms to maintain master data. Obviously it is the most difficult task to determine the necessary effort to migrate a typical form per group.

There are some general questions which should be answered first:

1. Under which version of Oracle Forms the application is running at the moment?

2. Was the Forms application developed manually or completely/partially generated by Oracle Designer or Oracle Headstart?

Depending on the answers a decision about the migration path can be taken.

[pic]

Oracle Forms migration path

The picture shows the intermediary steps when migrating from early versions of Oracle Forms. It is a requirement of getting support from Oracle during the migration process but there are a few exceptions to the rule. Direct migration is possible when using the tool PITSS.CON or when the Forms are generated from Oracle Designer.

The biggest part of migration effort is caused by the necessary replacement of functionality which worked in previous versions of Client-Server Forms but doesn’t work anymore with WebForms. So it is mandatory to know which of these obsolete features were used in the Forms application and to define an appropriate replacement if the requirement for them is still valid.

The obsolete features for Oracle Forms 9i/10g are documented in:

(

(

Some migration tools also provide implementations of obsolete features lists to automatically check Forms modules against these features.

The following questions should give an indication that obsolete features were used and a replacement is necessary:

1. Is the Forms application running in character mode?

=> There is no support for character mode anymore in Forms 9i/10g.

2. Are there OS-specific features which were used in the Forms application?

VBX

OLE Container

OCX/ActiveX Controls

Sound Item

=> Required functionality has to be implemented by Java Beans or Pluggable Java Components.

(

3. Are there Oracle Reports called from the Forms application by using the built-in RUN_PRODUCT?

=> RUN_PRODUCT has to be replaced by RUN_REPORT_OBJECT with some modifications in the structure of parameters.

(

(

products/forms/pdf/10g/frm10gsrw10g.pdf

4. Are there still Forms V2 Style Triggers in the Forms application?

=> They will be automatically removed during the upgrade.

5. Were Forms binary modules stored in the database? Was subclassing used between modules?

=> In Forms 9i/10g binary modules can be stored only in file system.

6. Were triggers of type When-Mouse-Move / When-Mouse-Enter / When-Mouse-Leave used?

=> There is no support for these trigger types in WebForms because of the heavy network load they produce.

7. Were any of these routines used in the Forms application:

Host Commands

ORA_FFI

TEXT_IO commands

User Exits

Was the Client’s file system or registry accessed by the Forms application?

=> After the migration these routines will be executed on the Middle Tier and not on the Client. If they should run on the client a replacement by Java Beans or Pluggable Java Components (PJC) is necessary. There are predefined components in WebUtil.

8. Was Oracle Graphics used to display charts in the Forms application?

=> There is no version of Oracle Graphics with 9i/10g anymore. The replacement for charts is the Oracle Business Intelligence Beans (BI Beans). There is no migration path for existing Oracle Graphics 6i charts. As a temporary solution existing charts can be deployed in a separate Oracle Home.

(

9. Are the Forms applications multi-lingual? Was Oracle Translation Builder used to translate the modules?

=> Oracle Translation Builder should be replaced by Oracle TranslationHub.

(

10. Was PVCS or ClearCase used for source code control of the Forms application?

=> There is no predefined integration with both systems in Forms 9i /10g.

As an alternative the Oracle Software Configuration Manager (SCM) can be used, which is part of the Oracle Internet Developer Suite (iDS).

(

11. Were timers used in the Forms application?

=> Timers are still working but should be used rarely because they generate network traffic.

Which Tools to use?

Forms migration requires intellectual effort, but tools can help with repetitive and tedious tasks. By using tools it is possible to save time and provide better software quality.

There are basic tools integrated in the software from Oracle and more sophisticated tools from other vendors which have to be licensed additionally.

Don’t forget to store a backup of your complete application before using these tools because some of them override existing modules without warning.

Let’s start with the tools which are part of the Oracle Developer Suite.

Forms Migration Assistant

It can be used to migrate existing Forms modules (fmb, mmb, pll, olb) to Forms 9i/10g and can be found in the Oracle Home of the Oracle Developer Suite:

• Forms 9i: ifplsqlconv90.bat

• Forms 10g: frmplsqlconv.bat

You can use the program either in interactive mode from the menu or command line (mode=wizard) or in batch mode from the command line.

The tool supports automatic search and replacement of obsolete calls and properties. You can define in the file search_replace.properties what actually has to be replaced.

Hints and warnings are written into a log file.

( How to Use Migration Assistant to Migrate Forms 6i to Forms 9i (Note 209545.1)

( How to Customize the Migration of Forms Using Migration Assistant (Note 209549.1)

You should start with menu (mmb) and library (pll, olb) modules because they are referenced from forms (fmb) modules. Already migrated menu and library modules have to be in the Forms Path (FORMS90_PATH or FORMS_PATH) before migrating the forms modules.

Compile of Forms Modules in the Forms Builder or in Batch

Afterwards the migrated modules can be compiled interactively in the Forms Builder or in batch mode. Errors during compilation have to be analyzed and fixed. Many forms modules without obsolete features can be compiled successfully without the previous migration step.

C or Java Development API

If there is a large number of similar tasks like searches, replacements or modifications you can also use the Forms C or Java Development API to automate these tasks. It requires some deeper knowledge of internal Forms structures and C or Java programming. On the other hand there is a great benefit in using API scripts for certain tasks. More detailed information can be found in the Forms documentation.

Other Tools

There are many tools for migration and maintenance of Forms applications on the market. Here are some of them:

• PITSS.CON from PITSS (en/pcon/tech.htm)

• jform from iMining (iming.de)

• Forms API Master (orcl-)

Especially for large and complex Forms applications the repository-based approach of PITSS.CON gives the developer great power and flexibility.

What happens with obsolete functions?

The most challenging task during migration is to define a replacement for functionality in previous versions of Oracle Forms which will not run anymore or not in the same way in Forms 9i/10g. If there is for example a requirement to process files on the user’s desktop existing built-ins can’t be used for that purpose because they will be executed on the application server tier.

To get the desired functionality in WebForms Java Beans or Pluggable Java Components (PJC) have to be implemented in the Form. With WebUtil Oracle provides a set of components for the web deployment of Oracle Forms.

WebUtil covers functional areas like:

• text I/O on the client

• file selection on the client

• manipulation of files on the client (Copy, Rename, Delete etc.)

• OLE-integration on the client

• file transfer between client, application server and database

• read/write of image files on the client

• C API interface on the client

• asynchronous/synchronous program calls on the client

• manipulation of registry entries

• detection of browser settings

WebUtil is part of the Forms software distribution and is fully supported as part of the product stack. A large part of the configuration is done during the installation of Oracle Application Server Forms Services.

The usage of components from the WebUtil library is quite simple and requires only three steps in the development process:

• attachment of the WebUtil Library (PLL) to the Forms module

• referencing an object group from the WebUtil object library (OLB)

• replace the calls in the Forms module to redirect them to the WebUtil components (example: TEXT_IO have to be replaced by CLIENT_TEXT_IO)

Other relevant information

Besides the already mentioned documents here is a short list of additional information available to Forms customers:

Migrating Forms Applications from Forms 6i (Documentation)

(

Oracle Forms - FAQ

(

with many links to documents and information sources around Oracle Forms.

Forms Forum on OTN

(

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download