Kbase P4759: Relative Path Database FAQ
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Verified
GOAL:
What is a Relative Path Database
GOAL:
What are the differences between a Relative and Absolute Path Database?
GOAL:
What happened to single-volume and multi-volume databases in Progress 9.x?
GOAL:
Why was the use of single-volume databases not recommended?
GOAL:
Why did we get into this mess in the first place?
GOAL:
What was good about single-volume databases?
GOAL:
How is a Progress 9.x relative path database different from a Progress 8.x single-volume database?
GOAL:
How is a relative path database created?
GOAL:
But what about example databases like sports? It appears to be a relative path database and have multiple areas?
GOAL:
How to make the relative path empty database useful?
GOAL:
When should a relative path database be used?
GOAL:
When does a relative path database become a absolute or fixed path database?
GOAL:
What happens when an absolute pathname database is copied?
GOAL:
Any examples of how relative path databases have been used?
FACT(s) (Environment):
Progress 9.x
FIX:
Q: What happened to single-volume and multi-volume databases in Progress 9.x?
A: One of the features left behind with Progress 9.x was the notion of single-volume and multi-volume databases.
With Progress 9.x there is no such thing as single-volume or multi-volume databases and in fact a point was made 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, the code that opened a database was cleaned up and the redundancy of having two different flavors of databases with different layouts and file formats was removed. 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 Progress and less complexity and better reliability the 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 the database was filled to 2GB, it was a complex and time consuming process to convert to a multi-volume database.
Starting with Progress 6.3, Progress explicitly started recommending that single-volume databases not be used for production systems. In Progress 8.x timeframe Progress started declaring that single-volume databases would not be available as a feature in Progress 9.x.
Q: Why did we get into this mess in the first place?
A: It is helpful to understand the history behind database structure.
In Progress 5.x, a database was only allowed to be a single file and in fact that worked fine except on DOS where the FAT file system 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 Progress 6.x 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 unexpectedly during the copy operation, or the copy operation did not get all the necessary pieces. Still, having the ability to copy a database was convenient 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 Progress 9.x to support these requirements called a Relative Path Database.
Q: What is a Relative Path Database?
A relative path database is a Progress 9.x 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 A.rea (.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 Progress 9.x 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 Progress 9.x relative path database different from a Progress 8.x single-volume database?
A: A relative path database is a full function Progress 9.x 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 assumptions 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 prostrct 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 to make the relative path empty database useful?
A: Use standard te.chniques 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 a relative path database be used?
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 an absolute pathname database is copied?
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 identical 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 can be made into a relative path database. Please refer to Solution P125711, "How to convert an absolute path database&n.bsp;into a relative path database?".