[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 574: sizeof(): Parameter must be an array or an object that implements Countable
[phpBB Debug] PHP Warning: in file [ROOT]/phpbb/session.php on line 630: sizeof(): Parameter must be an array or an object that implements Countable
Russian Progress User Group • V9 Relative Path Databases FAQ
Страница 1 из 1

V9 Relative Path Databases FAQ

Добавлено: 20 июл 2005, 09:33
dmi
V9 Relative Path Databases FAQ
------------------------------
KnowledgeBase number: 19027

Creation Date: 12-Aug-99

Modified Date: 18-Oct-99

This document applies to: Progress Version 9 RDBMS

Author: D.Britton Johnston

Summary:
This Knowledgebase discusses the methods and questions regarding
relative path databases under Progress Version 9.

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: But what about example databases like sports? It appears to be a
relative path database and have multiple areas?

A: Our sample databases like sports are special cases, we chose to
make our example databases follow our recommendations to keep schema
and application data in different areas and we also made them
relative. Our expectation is these are for demo and sample use only.
If you want to create a useful relative path database start with the
empty database.

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 a 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

References To Written Documentation or Other KnowledgeBase Documents:
Progress Version 9 System Administration Reference Manual
Progress Version 9 System Administration Guide