How to move progress database to different OS

Migrating databases between server platforms is sometimes possible using a Progress database copy utility. However, changing database servers often requires a data dump & load from the original server to the new server. The following Progress Knowledgebase entry describes how to determine if the server types are compatible for a database copy process or if a data dump and load is required.

INTRODUCTION:
=============
Customers often ask about PROGRESS database portability: under what
circumstances can a PROGRESS database be moved from one platform to
another? This Technical Support Knowledgebase entry provides
guidelines to follow when copying a database created under one
operating system to a different environment.

Migrating databases between platforms without performing
some sort of dump and load is NOT supported by PROGRESS.
While it may appear that databases are compatible, databases
compatibility has *NEVER* been tested by development, therefore
the results may be unpredictable.

The following information is being provided as a best effort to assist
in determining compatibility across platforms for a db. This is only
a guideline. Porting a db from one platform to another is supported
by Technical Support when the migration was performed using a dump
and load process only.

WHY YOU NEED TO KNOW THIS:
==========================
There are generally three circumstances when you may need to know
whether you can port the database file itself (.db file) from one
environment to another:

- When you are upgrading your hardware/operating system
environment from one type of machine to another;
- When your production system has failed and emergency
available disk space is on another machine;
- When you are deploying from a development environment
to a production environment and the two environments
do not have matching hardware and operating system.

By copying the database in its original state, you may be able to
avoid performing a dump and reload of your definitions and data
files, and thus save time and disk space.

In all cases, however, you MUST have a copy of the specific
version of PROGRESS software for the target machine, and the
two environments must be within the same major release of
the PROGRESS product (version 6.3 to version 6.3, version 7.3 to 7.3,
or version 8.2 to 8.2). The application .r code must be compiled
native to the target machine, or there must be a session-compiling
(PADS or 4GL/RDBMS) license in order to access the database
on the new platform.

PROCEDURAL APPROACH:
====================
PROGRESS databases fall into 8 different types:

4 different database blocksizes * 2 different byte orders = 8 types

Blocksize=4096: NT
Blocksize=2048: PYRAMID, ATT3B5, NIXDORF, SEQUENT, APOLLO
Blocksize=1024: VAX, AXP and everyone else
Blocksize= 512: DOS, OS/2, NetWare, MS-WINDOWS

Byte order 1: VAX & INTEL, mostly
Byte order 2: most of the rest

You can tell which class your database belongs to by examining the
2 bytes at offset 16 and 17 in the first block. Those bytes contain
a binary integer in the native byte order. The integer is slightly
larger than the database block size.

Two databases in the same class (same database blocksize and same byte
order) are usually compatible.

ONLINE PROCEDURES OR UTILITIES:
===============================
In order to determine whether the source and target machines use
the same database type, you will need to analyze the master block
of the source database (the one you would like to copy) and any
database that already resides on the target machine, such as a
copy of the empty.db in the PROGRESS software directory.

To analyze the source database, follow these steps.

1. Shut down the database server if it is running.
proshut
2. Truncate the before image file.
proutil -C truncate bi
3. Dump the master block of the database.
proutil -C dbrpr

You will be presented with a menu called:
DATABASE REPAIR MENU

Select #4, Dump Block.
Enter dbkey: 32
File name: 32.dmp
Quit.

Offsets 0 to 15 appear on the first (0000) line of
the 32.dmp file. Offsets 16 and 17 appear in the
first column of the second (0010) line. Below is
the output of the dump from the demo database on a SUN4.

# BLOCK REPAIR UTILITIES
# DATABASE = /users/ts/demo.db
# DBKEY = 32
# BLOCK NUM = 1


>0000 0000 0020 017F 0001 0000 0000 0000 05C3
>0010 043F 0002 000A 0000 0000 0140 0000 10F2
>0020 0000 0A40 0000 04A0 0000 0006 0000 0073
>0030 0000 0000 0000 0000 0000 0000 0000 0000
>0040 2BE8 3386 0000 0000 0000 0000 0000 0000

043F = (15 * 1) + (3 * 16) + (4 * 256) + (0 * 4096) = 1087

The hex value "043F" translates to decimal 1087.
Thus, this information tells you that the SUN4
is forward-byte, 1024-byte based database.


The next example is from a SEQUENT.

# BLOCK REPAIR UTILITIES
# DATABASE = /users/ts/demo.db
# DBKEY = 32
# BLOCK NUM = 1


>0000 2000 0000 017F 0100 0000 0000 AE01 0000
>0010 4008 0200 0A00 0100 C000 0000 F502 0000
>0020 0018 0000 E017 0000 0100 0000 0100 0000
>0030 0000 0000 0000 0000 0000 0000 0000 0000
>0040 CF7E E52B 0000 0000 0000 0000 0000 0000

The hex value "4008" must be byte-swapped, since
the SEQUENT is an INTEL chip-based machine. So
the 16th and 17th bytes are swapped, and "4008"
becomes "0840".

0840 = (0 * 1) + (4 * 16) + (8 * 256) + (0 * 4096) = 2112.

Thus, the hex value "0840" gets translated to
decimal 2112. This information tells you
that the SEQUENT is a byte-swapped, 2048-byte
based database.

4. Repeat this step for a database on the target
machine. If offsets 16 and 17 are the same on
both machines, you will usually be successful
accessing the database under the target machine.

There are, occasionally, some problems if two machines in the same
class have different alignment requirements, but we try our absolute
best to avoid that. One example of this was SUN3 and SUN4 database
are NOT compatible in V6. In any case, the alignment problems are
ALWAYS confined to the 1st block of the database (control info,
free chain anchors, etc).

The alignment problems never affect the data themselves.

Before image files usually do not suffer from these alignment
problems (although the blocksize and byte order must match). Before
trying to move a database file from one platform environment to a
different operating system platform, always remember to truncate the
.bi and disable after-imaging before moving the database.

Remember also to perform a full backup before moving the database.

SUMMARY
=========

If the source and destination server database blocksize and byte order
are the same, the databases are usually compatible and you can move the source
database between servers using Progress procopy or prodb commands across the
network.

The only really sure way to know if two machines are database compatible is to try
it out. Copying the demo database from the source machine and attempting to
access it on the target machine will let you know whether the two environments are compatible.

If the database blocksize and byte order are not compatible, then you must create
a new, empty database on the target server, dump the data from the source server,
move the dumped data files to the target server, then load the data into the new
database.

The safest way to move to another server:

Moving to another machine, different platform:
1. Need same Progress version for new machine.
2. Need same MFG/PRO version for new machine.
3. Load Progress and MFG/PRO onto new machine.
4. Dump data from old machine.
5. Load data into database on new machine.

To move to another machine, same platform:
1. This is a direct port and new software is not necessary.

REFERENCES TO WRITTEN DOCUMENTATION:
====================================
PROGRESS System Administration Guide: See the section
"Dumping and Loading a Database".
PROGRESS Developer's Toolkit.

Unix-based databases can also be interpreted using the Unix dd
command.

To dump the database master block under Unix, use the
following command:

dd if= bs=1k count=1 | od -x +0x0 >filename

dd Convert and copy a file

if Input Filename (use the PROGRESS database file name)

bs Block Size for input and output (indicate your
system's block size)

count Number of blocks to dump (dump the first block only)

od Octal dump

-x Interpret words in hex

+0 Offset is zero

x0 Continue for one block[@more@]