Kbase 11431: Determining a Multi-Volume Database Strategy
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Determining a Multi-Volume Database Strategy
INTRODUCTION:
=============
This Technical Support KnowledgeBase entry outlines three different
strategies for going from a single-volume database to a multi-volume
database. Once you have determined a suitable strategy, you implement
it in a test environment. When that is successful, you can then
apply it to the production environment. In this way, you have a hands
on knowledge of going from single-volume to multi-volume, and you
minimize the likelihood of problems due to a lack of understanding of
the process.
WHY YOU NEED TO KNOW THIS:
===========================
PROGRESS has a current limitation of a 2 GB for a database file.
This means that a single file (.bi, .db, .lg, etc.) cannot grow
greater then 2 GB without dire consequence (i.e. loss of database
information).
When designing a database, future growth of the database should be
a major consideration. A strategy should be in place for the event
of a single-volume database reaching the 2 GB limit. PROGRESS
strongly recommends that you implement this strategy by the time
the database file reaches 1.5 GB If the database reaches or exceeds 2
GB it might be unrecoverable.
PROCEDURAL APPROACH:
====================
I. The most expeditious strategy is to use PROGRESS/COPY or PROCOPY.
This method requires TOTAL disk space amounting to at least
twice the size of the current single-volume database. Explicitly,
Total required disk space = current single-volume database size
+ new multi-volume database size.
This method is the fastest in terms of performance,
as the i/o is disk to disk.
1. Backup the current database.
PROGRESS/BACKUP (PROBACKUP) or a good operating system backup.
2. Create a new VOID multi-volume structure.
When determining the number of extents, take into
consideration the number of drives you'll use and the
number of controllers, then, evenly balance the extents
between them. Put the .BI and temporary files on
their own drive whenever possible.
In this way, you optimize performance for the database.
Follow these steps to create a new void multi-volume
structure.
a. Create structure file.
b. Create the VOID multi-volume structure.
VMS: PROGRESS/STRUCTURE/CREATE=descrfile.st dbname
UNIX, DOS, O/S2: prostrct create dbname descrfile.st
3. Back up the new VOID multi-volume structure.
4. Populate the new multivolume structure:
VMS: PROGRESS/COPY source target on VMS
UNIX, DOS, O/S2: procopy source target on UNIX,DOS,O/S2
5. Back up your new populated multi-volume structure.
If you did a probkup in step 1, skip this step.
II. Another strategy is to restore a single-volume
backup into a new void multi-volume structure with PRORESTORE.
Use this method when disk space is at a minimum.
Total disk space necessary is the new multi-volume size, or the
current single-volume size, whichever is greater.
1. Back up the current database using the PROBKUP utility.
VMS: PROGRESS/BACKUP dbname device-name
UNIX: probkup dbname /dev/rrm/0m
DOS,O/S2: probkup dbname a:\filename
2. As a safeguard, make a GOOD operating system backup as well.
3. Delete the database.
4. Create a new multi-volume void structure.
(See strategy I for details.)
5. Restore PROBKUP into the new multi-volume structure.
VMS: PROGRESS/RESTORE dbname devicename
UNIX: prorest dbname /dev/rrm/0m
DOS,O/S2: prorest dbname a:\filename
III. You could also convert an existing single-volume database
into a multi-volume database.
Use this strategy when you don't have enough disk space for the
single-volume database and the multi-volume database to reside on
your system at the same time. It is riskier than the second
strategy discussed - if this method fails or is stopped in the
middle of execution, the database might be damaged. Make sure
that you have a good backup before implementing this strategy.
1. Truncate the before-image file.
2. Back up the current database. Use PROGRESS PROBKUP or the
operating system utility, or both.
3. Convert the single-volume database into a single data extent
multi-volume database.
The database.db file is renamed database.d1, a single data extent
of variable length. The database structure file, database.db,
becomes the "table of contents" for the entire database.
This file contains a "map" of where Progress can find the
extents for this database.
VMS: PROGRESS/STRUCTURE/CONVERT dbname
UNIX, DOS, O/S2: prostrct convert dbname
4. Add extents in consideration of future growth.
Determine the additional extent requirements, and define the
extents in a new structure description file, newfile.st. Then use
the following command to append the extents of the .st file
to the multi-volume database.
VMS: PROGRESS/STRUCTURE/ADD=newfile.st dbname
UNIX, DOS, O/S2: prostrct add dbname newfile.st
REFERENCES TO WRITTEN DOCUMENTATION:
====================================
System Administration II - Chapters 4, 6 and 7
Progress Software Technical Support Note # 11431