Status: Verified
GOAL:
Can a probkup of Type I areas be prorest into a Type II Storage Area ?
GOAL:
After conv910, can the converted database then be procopied into a new database structure with the new Type II Storage Areas ?
GOAL:
Can Progress 9.x Storage Areas be prorested into a new database structure with mirror Type II Storage Areas ?
GOAL:
How to move tables into a Type ii Storage Area ?
GOAL:
How to move tables to the new areas as part of a migration strategy ?
GOAL:
Can a backup of Type I areas be restored into a Type II Storage Area structure ?
GOAL:
Can TypeI database be copied to a Type II database?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.1x
OpenEdge 10.x
FIX:
Tables currently in a Type I Storage Area cannot be restored into a Type II Storage Area structure with a prorest of a previous probkup.
Neither can Type I Storage Area structured database be procopied into a mirror Type II Storage Area structure with the procopy utility.
Type II Storage are only available to newly created areas, Type I areas cannot be "converted" to Type II Storage Areas.
So for example;
- a Progress 9.x database that has been conv910 will not immediately be able take advantage of the OpenEdge 10 Storage Area architecture.
- a probkup of a conv910 database that is prorested into the new Type II structure, will fail.
- a probkup of a version 10 database with Type I and Type II areas, can only be prorested to an exact Type I Type II area structure, ie not inter-changeable.
To take advantage of the new Type II architecture, either:
1) Add new Type II Storage Area(s) to the OpenEdge 10.x database and then tablemove selected tables from their Type I area to the new Type II area:
a.) $ prostrct add dbname asa2.st
Where:
# asa2.st
d "Data AreaI.2":9,256;8 . f 1048576
d "Data AreaI.2":9,256;8 .
d "Data AreaII.2":10,128;64 . v 1048576
d "Data AreaIII.2":11,64;512 . v 1048576
#
d "Index Area":11,1;8 . f 524288
d "Index Area":11,1;8
b.) $ proutil dbname -C tablemove tablename <tablearea> <indexarea>
** NOTE: since OpenEdge 10.1A areas can be added ONLINE with the "prostrct addonline dbname asa1.st"
- or -
2) Create a new database structure and load into it as follows:
a) Through the Database Administration Tool, dump the data definitions (.df) data (.d) and Sequence Current Values, User Table (if appropriate)
b) Create a Bulk Load Descriptor File: dbname.fd
c) After a detailed tabanalys, define your new structure file (dbname.st)
Example:
# OE 10 ASA2 Storage Areas
b /usr2/db f 100000
b /usr2/db
#
d "Schema Area":6,32 .
#
d "Data AreaI.1":7,256;64 . f 10240
d "Data AreaI.1":7,256;64 .
#
d "Data AreaII.1":8,128;8 . f 10240
d "Data AreaII.1":8,128;8 .
#
d "Data AreaII.2":9,64;512 . f 1048576
d "Data AreaII.2":9,64;512 . v 1048576
#
d "Index AreaI":11,1;8 . f 524288
d "Index AreaI":11,1;8 .
Refer to Progress Solution P81745, "Are there any guidelines for the new blocks per cluster setting with Progress OpenEdge 10.X?"
d) Create your new database structure:
$ prostrct create dbname dbname.st -blocksize 8192
$ procopy $DLC/empty8 dbname
$ proutil dbname -C truncate bi -bi 16384 -biblocksize 8
e) Instead of editing the current the .df to change every table / index to it's new Type II Storage Area, use the proutil -C tablemove utility, which is really FAST if there are no data loaded yet and avoids user entry error when editing the existing .df file for the new areas:
i) Load the dbname.df through Database Administration Tool
[with a run-time license] $ pro dbname -p _admin.p -rx
[with a development license] $ pro dbname -p _admin.p
Admin -> Load Data and Definitions -> Data Definitions File (.df)
ii) Exit the Data Administration tool and move each table / index to it's new storage area with:
$ proutil dbname -C tablemove tablename <tablearea> <indexarea>
(Refer to Progress Solution P13813, "How to create a script for a tablemove" to automate this step)
iii) Go to the directory where you copied all the .d's and load the tables with bulkload:
$ proutil <directory to database>/dbname -C bulkload dbname.fd -i -B 10240 -G 0
This is the dbname.fd bulkload descriptor file that you created when dumping (Step b).
When running w.ith no integrity -i, if the operation fails, you need to start again, but it's much faster than a Data Dictionary load.
Bulkload is an offline utility, it will be much faster than ASCII load because we DON'T build the indexes at the same time. We do that afterwards and we've GREATLY improved the idxbuild utility since 9.1D07
Since we've changed the Schema that these tables must be in, they will be loaded where we've said that they must go with the tablemove previously.
f) At this point, take a temporary backup of your database:
$ probkup dbname dbname.bak
g) Run a full idxbuild and on completion and then take a new backup:
$ proutil <dbname> -C idxbuild ALL -B 10240 -TB 24 -TM 32 -SG 48 -thread 1 -threadnum 4
$ probkup dbname dbname.bak.