Migration 8.2b to 9.1b

sck

New Member
Can anyone give me some hints, on what's the best way to migrate 8.2b databases to 9.1b.

convert, dump&reload?

how should the structure of the 9.1b multivolume look like (areas, blocksize....)?

are there problems with V9 DB's with relative paths?

Thnx for your feedback!
 
There is a convert util.

Most of it is all documented when you get the 9.1b docs.

We managed it all no problem with not to much effort.
 

phirst

New Member
I have tried both methods for converting V8 db's to v9.
The conversion tool (proutil -C conv89) seems to me the best approach.
It's certainly a lot quicker and surer.
Convert the v8 db into a simple multi-volume (1 data and 1 bi extent) and trunc that bi before hand.

As for multi-volume db's, you have to be very careful.

OK the path names are a bit of a pain, but there are easily changed. Update that .st file and do a "prostrct repair".

Progress says that you should not put tables in the schema area. So let's do what Progress says...
Example .st file, I created my table areas (none of which are a fixed size. Extent sizes are customer specific, you will have do some serious table stats to come up with the best db extent sizes), this is a development db.

# .bi
b G:\Progress\demo379\Bd\soc001.b1
# leave the schema area alone
d "Schema Area":6,32 G:\Progress\demo379\Bd\soc001.d1
# I divided my tables into 5 groups
d "achat":7,128 G:\Progress\demo379\Bd\soc001_7.d1
d "vente":8,128 G:\Progress\demo379\Bd\soc001_8.d1
d "compta":9,128 G:\Progress\demo379\Bd\soc001_9.d1
d "tiers":10,128 G:\Progress\demo379\Bd\soc001_10.d1
d "eripro":11,128 G:\Progress\demo379\Bd\soc001_11.d1

I created a batch file to move the tables into the right table area:
proutil soc001.db -C tablemove blfo achat achat
proutil soc001.db -C tablemove article vente vente
...

If you use a relative path name in the .st file, Progress records the FULL path name in the .db file.
If you are not sure of the path name Progress uses, use "prostrct list", this recreates the .st file with the data stored in the .db.
ALWAYS DO THIS after moving a db from one directory to another, it doesn't cost anything and it can save you a lot of time.

Hope this helps.
 

Chris Kelleher

Administrator
Staff member
As far as converting your database from version 8 to 9, I would just use the proutil -C conv89 command, it only takes a minute to run, and is the easiest way to convert. You could also do a dump and reload, however I would only do this if you have a need to reorganize the database.

After you run the conversion, all of your data will be in the "Schema Area" by default. I would follow the great instructions phirst posted for moving things to different database areas.

For information about relative path name databases, there is some very good information by Britt Johnson available here: http://www.fast4gl.com/files/files/download.php?id=21

Info useful for anyone doing development with V9 databases. I've
been asked a few questions about this lately and thought this might
answer most of them.

Britt...

Technical Director
Progress Software Corporation


V9 Relative Path Databases FAQ
------------------------------

Q: What happened to single-volume and multi-volume databases in V9?

A: One of the features left behind with V9 was the notion of
single-volume and multi-volume databases.

With V9 there is no such thing as single-volume or multi-volume
databases and in fact we made a point of cleaning up all the
documentation to make sure that concept was gone. This distinction
was removed due to some of the implementation work around ASA, we
wanted to cleanup the code that opened a database and remove the
redundancy of having two different flavors of databases with
different layouts and file formats. Those differences made building
administration utilities more complex and in some cases resulted in
a great deal of duplicate code. As a result two implementations
that were expensive to keep in line were collapsed into a single
implementation for opening a database and addressing blocks within
a database. The end result is a cleaner implementation with lower
maintenance costs for us and less complexity and better reliability
for our customers.

Q: Why was the use of single-volume databases not recommended?

A: For production environments, single volume databases were a support
nightmare because it was easy to misplace the BI file (often via the
-g switch) Also when customers filled up the database to 2GB, it
was a complex and time consuming process to get them on track with
a multi-volume database.

Starting with V6.3, Progress explicitly started recommending that
customers not use single-volume databases for production systems.
And in V8 timeframe started declaring that single-volume databases
would not be available as a feature in V9.

Q: Why did we get into this mess in the first place?

A: It is helpful to understand the history behind database structure.
In V5, a database was only allowed to be a single file and in fact
that worked fine except on DOS where the FAT fileystem caused
serious performance issues with files larger than 8MB. So the
notion of a multi-volume database was created and a way to convert
from a single to multi-volume database was developed. The expectation
at the time was that multi-volume would only be used on DOS to
workaround the performance issues, but it became very clear that as
systems started scaling up that the ability to use multiple disks for
the database was important. In later V6 releases, most production
systems were implemented with multi-volume databases because of the
additional safety, performance and flexibility they provided.

Q: What was good about single-volume databases?

A: One of the nice things about single-volume databases was the ability
to copy a database via simple OS tools. However, using an OS copy
command on a database could easily produce a resulting copy that was
corrupt either because the source database changed unexpectly during the
copy operation, or the copy operation did not get all the neccessary
pieces. Still, having the ability to copy a database was convienient
when doing application development with "toy" development databases that
need to be moved around or moved from one machine to another. The
ability to copy a database is useful when building automated testing
(although prodb or procopy can work fine in most cases). Finally, it is
also useful to be able to copy a database from a CD onto a customer
system when doing a demo or product install. Progress built a feature
into V9 to support these requirements called a Relative Path Database.

Q: What is a Relative Path Database?

A relative path database is a V9 feature. Relative path databases
result when a database is created from an empty database without using
an explicit structure file. The resulting database has all of its
component areas (Control Area (.db), Recovery Area (.b1), Schema Area
(.d1), and Event Log (.lg) located in the same directory each with a
single variable length extent. A relative path database has most of the
properties associated with an old single volume database in that it can
be copied with an OS command, is made up of a minimum of files and is in
general the simplest form of a V9 database.

For most purposes, the fact that a database can even be relative path
is a non-issue. For example, most customers in a production environment
do not need to concern themselves with this nuance and should not. In
fact we strongly recommend that no attempt be made to provide relative
pathname databases for production environment and they be used only for
specialized situations.

Q: How is a V9 relative path database different from a V8
single-volume database.

A: A relative path database is a full function V9 database in every
way. It can have extents or areas added to it with no conversion
process. A single-volume database required a conversion process or a
backup/restore into a void structure to allow structure changes.

A relative path database must always include its control area and
recovery log when moved/copied. Single-volume databases with a
truncated BI file could effectively be considered a single file
database (.db only). That single file could be copied and then the
resulting database opened in its new location with the BI file
dynamically created. While this was simple, it was so simple that users
often got
confused and forgot the BI file was important. This was the root of
many serious support issues with single-volume databases that left
customers with what appeared to be corrupt databases, mismatched
timestamps. In many cases the customer simply misplaced or lost the
required BI file because of complex scripts that made incorrect
assuptions about what files were important.

Q: How is a relative path database created?

A: A relative path database must be created from an empty
database the prodb command, for example:

$ prodb mydb empty
Database copied from /dlc/empty. (1365)

Once created, it will remain relative pathname unless it has its
structure changed. The resulting relative path database can be seen by
using a prostruct list command:

$ prostrct list mydb
Area Name: Control Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: ./mydb.db

Area Name: Primary Recovery Area, Type 3, Block Size 8192, Extents 1
Ext # 1, Type VARIABLE, Size 0, Name: ./mydb.b1

Area Name: Schema Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: ./mydb.d1

Notice the period (dot) at the start of each extent name - that
indicates a relative path. In addition, if you query the physical
schema tables like:

FOR EACH _AREAEXTENT: DISPLAY _AREAEXTENT.

Extent-type Extent-attrib Extent-system Extent-size Extent-path
----------- ------------- ------------- ----------- -----------
1 0 0 0 ./mydb.db
6 0 0 0 ./mydb.b1
5 0 0 0 ./mydb.d1

The extent paths are stored with relative path names. This means the
database files (in this case mydb.db, mydb.b1, mydb.d1) can be
moved to any directory together and the database will still open.

Q: How do I make the relative path empty database useful?

A: Use standard techniques for loading schema into the database.
As long as the structure is not changed (areas or extents added),
the database will remain relative path name.

Q: When should I use relative path database?

A: If you have a specialized need to be able to copy a database with OS
tools, such as when installing a demo or the master database associated
with a new application you may use a relative path database to help with
a solution. For developers who want to manipulate their "toy"
development databases it can be a useful feature.

Q: When does a relative path database become a absolute or fixed
path database?

A: Any time the structure is changed. For example if the database
is copied using procopy, when procopy creates the target structure
the resulting database copy will not be relative path database.

If an extent is added to an existing area (it would be a .b2 or
.d2 file), the existing relative paths would be made absolute.
If an area was added to the database such as an area for user
data, the existing areas would become absolute pathname
databases.

Q: What happens when I copy an absolute pathname database?

A: We expect all databases in production use will be absolute path
databases and require using probkup or procopy to backup or copy
the database to insulate the copy process from the details of the
underlying files and their locations. When OS commands are used the
user or script must have detailed and accurate knowledge of the
underlying files and their locations to be successful and be aware of
any and all changes that take place. There are explicit utilities to
repair the physical structure to match the actual pathnames associated
with various areas and extents of the database via prostrct repair and
prostrct builddb. See the product documentation for more details on how
to use those utilities.

Q: Any examples of how relative path databases have been used?

A: When doing development and when it was necessary to move working
directory from one disk to a new disk it was possible to copy the
complete directory tree and the "toy" development databases in the
tree were able to be opened even though the absolute pathnames
changed.

During development a database needed to be opened across a network
(this is not a supported production configuration). The drives the
database was located on (C: on the local machine, a mapped drive G:
on the remote machine) were different on each machine. A relative
path database allowed opening the files over a network even with
different pathnames.

A test environment copied the intermediate results of a failed test
off to a specific location so it could be later inspected and the
original location was cleaned up to make room for another test. The
copied databases could be opened without requiring any fixup on
behalf of the QA engineer because they were relative path databases.

Another example is during a benchmark it was necessary to setup 16
idential application server machines. The application server machines
had a database that contained read-only data kept in a database on
the local application server machine (to help with performance).
Those local databases were created as absolute path database to allow
them to be simply copied onto each system - it saved time configuring
the systems.

Q: I have an absolute pathname database and I need to make it a
relative pathname database, how do I do it?

A: Keep in mind a relative pathname database must be the simplest
structure (i.e. one data area which is the schema area and a single
variable length extent in that area) and less than 2GB of data. If
the database meets that criteria it is easy to make it into a relative
path database (check first it might already be one!). First let's
show that we have an absolute path database:

$ ls
mydemo.b1 mydemo.d1 mydemo.db mydemo.lg

$ prostrct list mydemo
Area Name: Control Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: /db/mydemo.db

Area Name: Primary Recovery Area, Type 3, Block Size 8192, Extents 1
Ext # 1, Type VARIABLE, Size 0, Name: /db/mydemo.b1

Area Name: Schema Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: /db/mydemo.d1

It is a absolute path database as expected. Now, let's turn it into
a relative path database, get ready this might get complicated:

$ prodb mydemo2 empty
Database copied from /dlc/empty. (1365)

$ procopy mydemo mydemo2
...Copy complete. (6722)
Database copied from mydemo. (1365)

That's it! Finally, verify that the new database, mydemo2 in
this case, is a relative path database:

$ prostrct list mydemo2
Area Name: Control Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: ./mydemo2.db

Area Name: Primary Recovery Area, Type 3, Block Size 8192, Extents 1
Ext # 1, Type VARIABLE, Size 0, Name: ./mydemo2.b1

Area Name: Schema Area, Type 6, Block Size 1024, Extents 1,
Records/Block 32
Ext # 1, Type VARIABLE, Size 0, Name: ./mydemo2.d1

Hope this helps,
-Chris
 
Top