Consultor Eletrônico

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