Feedback
Did this article resolve your question/issue?

   

Article

Upgrading an OpenEdge database from version 10.x to 11.x with conv1011

« Go Back

Information

 
TitleUpgrading an OpenEdge database from version 10.x to 11.x with conv1011
URL Name000031654
Article Number000152292
EnvironmentProduct: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Other: RDBMS, migration
Question/Problem Description
How to upgrade an OpenEdge database from version 10.x to 11.x with conv1011.
How long does upgrading with the conv1011 utility take?
Considerations before starting a database Major version migration
Any pre conv1011 sanity checks to assure a successful migration?
How to migrate a database to OpenEdge 11 when OpenEdge 10 is not installed?
When the database is migrated to OpenEdge 11 can OpenEdge 10 clients still connect?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution
The following Steps outline upgrading a database from OpenEdge 10.x to 11.x using the conv1011 utility when the migration is between major Progress/OpenEdge versions on the same supported Operating System.  An OpenEdge database has to use a dump and load strategy to migrate to a different Operating System.

The conv1011 Major Version database migration utility updates:
  • The version for only the Master Block in the .d1 extent and the Control Area (.db) extent block.
  • Updates an older database major release version to a newer major release version's meta-schema.
  • Enables the 64-bit DBKEYS and Large keys features if they were not previously activate
  • It is not necessary to update VST's when upgrading a major version with conv utilities, as these are updated as part the conv<> routines

Before starting any database major version migration: 

To assure a successful migration, there are a number of pre-conversion checks to take care of:

1. It is highly recommended to scan the OpenEdge database(s) before migrating to higher version 2. If this database was ever a pre-10.1B database where 64-bit dbkey support was introduced, run DBTOOL Option #6 "Record Fixup" specifically only at the Area or Table level prior to conversion. 3.  If you're using word-break tables, UTF-8 (for example) review the following Articles.  The OpenEdge 10 and 11 environments need to be the same and proutil must use the correct database collation, -cpinternal -cpoll etc  4.  It is imperative you have a verified backup before conversion. Should there be any failure the failed-conversion database is inaccessible: 
Open failed. Database unusable due to partial conversion. (1115)
 
5.  It is highly recommended to use the latest OpenEdge 11.7.5 (or later) for conversion purposes. Amongst others, this assures historic conv1011 migration failure issues are ruled out with product fixes.  For example: 6.  Non-withstanding, 'migration time' is also the ideal time to consider undertaking long-outstanding admin tasks on the database like:
  • What can be archived (how much of the TB database data is needed?)
  • Re-structuring (Type II Areas, better rpb settings, moving application objects out of the Schema Area)


A.  Migration when the OpenEdge 10.x install exists on the same machine where OpenEdge 11.x is installed:

1.  Run the OpenEdge 10.x PROENV script (DLC/bin/proenv) to set the environment to use the version 10.x tailored environment variables and installed executables:
  • Navigate to the folder where the database Control Area (dbname.db) is located
2.   Backup and verify the version 10.x database
 $   probkup dbname dbname10.bkp
$   prorest dbname dbname.bkp -vf

Optionally archive any after-image extents that have not already been archived should they be required for an OpenEdge 10 roll forward environment.

3.   If the the version 10.x database is enabled for OpenEdge Replication, AIMGT, AI, two-phase commit, these must be disabled prior to converting the database. While conv1011 disables AI it leaves AIMGT enabled.
$   echo y | proutil dbname -C disablesitereplication source
$   rfutil dbname  -C aimage end
$   proutil dbname -C 2phase end
$   proutil dbname -C truncate bi -G 0

4.   Stop all cron/batch jobs that usually touch this database or anything else that touches the files on disk during the conversion

5.   Run the OpenEdge 11.x PROENV script to set the environment to use the version 11.x tailored environment variables and installed executables:
  • Navigate to the folder where the database Control Area (dbname.db) is located
  • Convert the version 10 database to 11. 
 $   proutil dbname -C conv1011

Backup the OpenEdge 11 database:
$   probkup dbname dbname11.bkp
$   prorest dbname dbname11.bkp -vf

B. Migration when OpenEdge 10.x does not exist on the machine where OpenEdge 11.x is installed:

OpenEdge 11 contains OpenEdge 10 executables for utility access to the version 10 database prior to conversion.

Read the README file in the version 11 installation for using 101 or 102 database utilities: 
<DLC directory>/bin/101dbutils/README (only for version 10.1A) 
<DLC directory>/bin/102dbutils/README (for version 10.1B up to version 10.2B)

For example:  Prior to running conv1011 to migrate the database with the OpenEdge 11 PROUTIL executable
 
  • An OpenEdge 10 PROBKUP volume can be restored prior to conversion with:
<DLC directory>/bin/102dbutils/102b05_dbutil prorest dbname dbname.bak
  • After an OS copy of the OpenEdge 10 database files, the database structure can be repaired with:
<DLC directory>/bin/102dbutils/102b05_dbutil prostrct list dbname
<DLC directory>/bin/102dbutils/102b05_dbutil prostrct repair dbname dbname.st
  • The OpenEdge 10 bi file can be truncated with:
<DLC directory>/bin/102dbutils/102b05_dbutil dbname -C truncate bi
  • The OpenEdge 10 database can be backed up with:
<DLC directory>/bin/102dbutils/102b05_dbutil probkup dbname dbname.bak
 
After applying the steps above, run $ proutil dbname -C conv1011 to convert the database from version 10 to version 11. This proutil can be executed from the <DLC directory> of version 11.

It is important to note these executables will fail when the database to be converted is enabled for any features that require a specific OpenEdge license ( TDE, OER, MT, TP) or is enabled for features only an Enterprise Database license provides such as largefiles.

The purpose of the *dbutils directory is to allow DBA's the capability to use the new installation to perform necessary steps to migrate older databases, when the prior version is not installed on the server where the migration is taking place, by being able to run basic _dbutil instruction from the command line. These do not provide rights to perform operations against a large file enabled database which requires an Enterprise Database License:
  • In Progress 9 and earlier, the progress.cfg included in the 91dbutils is a Query Results license
  • Since OpenEdge 10 the NameServer license is provided in the *dbutils progress.cfg
  • Since OpenEdge 12 a license file (progress.cfg) is not provided with in the DLC/bin/*dbutil directory.  These prior-version utilities will use the current OpenEdge 12 licenses. By default the from dlc/progress.cfg is used otherwise set the PROCFG environment variable. For example refer to Articles:
Workaround
Notes
Last Modified Date7/2/2020 12:25 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.