Kbase 20634: Storage Areas in a Nutshell
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/09/2009 |
|
Status: Unverified
GOAL:
Storage Areas in a Nutshell
GOAL:
What are Storage Areas
FACT(s) (Environment):
Progress 9.X
OpenEdge 10.x
FIX:
Storage areas are both a logical and physical thing. Think of them as being somewhat equivalent to combining several Version 8.x multi-volume databases into a single database and managing them as one. Use of storage areas is optional, and for simple, small databases you should not bother with them.
Storage areas are a logical grouping of database objects (for example, indexes and tables). These objects are related by virtue of the fact that they are together in the same area. You decide what to put in what area.
Storage areas are a physical thing, in that you assign storage space to areas by defining at least one and possibly more "extents" in them.
An extent is a disk file or a UNIX raw partition. Objects in the area use the disk space that is contained in the extents.
Until Version 9.1C, extents are limited in size to 2.1 GB.
There are several different types of storage areas. Here are the major ones:
- The control area.
This area is contained within a single .db file. It contains the _area table and the _area-extent table that are lists of the storage areas in the database and the extents that are defined for them respectively. The control area always
exists and must have one extent. Without it, the database cannot find any of the others. This area is small and there is no reason to add more extents to it.
- The primary recovery area.
This is where the transaction log (the before-image file) is stored. This area is not optional and you cannot put anything into it. The primary recovery area must have at least one extent, and you can define additional extents for it.
- Data areas.
Data areas are user-defined areas that can contain whatever indexes and tables you put into them. You must have at least one data area. You might want to define more to make management of large databases easier, or to be able to control what database objects are stored on what disks for performance reasons. Do not worry about adding more areas to a small database.
- Secondary recovery areas.
These are used by the optional after-image journaling subsystem. You do not need to define secondary recovery areas if you do not use the after-image capability.
If you convert from Version 8.x, there are a few points you should be aware of:
- Since Version 9.x, all databases are multi-volume.
There are no single-volume databases. A Version 9.x database contains the following 4 files at a minimum:
- .db file. (that contains the locations of all other files.)
- One primary recovery before-image (BI) extent.
- One data extent.
- The text event log.
So, for a database named "foo", you have the following files:
foo.db
foo.b1 <---- that's a digit "one", not the letter "ell".
foo.d1
foo.lg
- Before you run the Version 8.x to 9.x conversion utility, you must have a multi-volume database.
This means you must change any single-volume database into a multi-volume database first.
There is a Version 8.x utility that can change a single-volume database into a multi-volume database.
Other ways to accomplish the same thing are PROCOPY, backup and restore, and dump and load.
The Version 8.x to 9.x conversion utility is quite fast and only takes a few seconds.
- There is no more -g parameter.
- There is no more -a parameter except for rfutil for rolling forward.
- If you use any of the simple conversion methods, you get a Version 9 database similar to your Version 8 database (with the same database block size and with everything in one storage area).