Porting/delpoy/migrate db to different platform block size
INTRODUCTION:
=============
This Kbase entry is designed to address the question regarding
Progress database portability across platforms.
Migrating databases between platforms without performing some sort of
dump and load is NOT supported by PROGRESS. While it may appear that
databases are compatable, databases compatability 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 a database 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 6.3, version 7.3 to 7.3). The application .r code must be
compiled native to the target machine, or there must be a
session-compiling (4GL/RDBMS or Provision) 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 <dbname>
2. Truncate the before image file.
proutil <dbname> -C truncate bi -G 0
3. Dump the master block of the database.
proutil <dbname> -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) and 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.
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=<dbname.db> 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
Prior to moving a database from one platform to another, it is
recommended to perform a full backup.
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 databases are not compatible and you need to perform a dump and
load, you can do this either via the data dictionary, a bulkload or a
binary dump and load if in Progress version 8.2+.
REFERENCES TO WRITTEN DOCUMENTATION:
====================================
PROGRESS System Administration:
"Dumping and Loading a Database".
PROGRESS Developer's Toolkit.
Progress Software Technical Support Note # 11930
