Kbase P136699: Where will AI extents be re-created when a Storage Area is located as the last entry in the .st file
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
30/10/2008 |
|
Status: Verified
GOAL:
Where will AI extents be re-created when a Storage Area is located as the last entry in the .st file ?
GOAL:
Can ai extents be assigned explicit Storage Area numbers?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
This Solution is perhaps best explained by way of example. While 'data' Storage Area numbering can be defined by appending the relevant Storage Area number to the structure definition, After-image files cannot.
Assume there are 3 After-Image extents defined in the existing database structure and another Storage Area has been added at a later stage AFTER these.
Example: dbname.st file
<Storage Areas 6-11 then ..>
d "Misc":12,128;8 D:\101B\WRK\dbname_12.d1 f 128000 << AREA 12
d "Misc":12,128;8 D:\101B\WRK\dbname_12.d2
a D:\101B\WRK\dbname.a1 f 20480 << AREA 13
a D:\101B\WRK\dbname.a2 v 40960 << AREA 14
a D:\101B\WRK\dbname.a3 << AREA 15
d "Newt":17,128;1 D:\101B\WRK\dbname_17.d1 f 128000 << AREA 17
## NOTE, each After-Image extent effectively takes one Storage Area number slot for itself in a 1:1 ratio, where data Storage Areas are 1 Storage Area number slot to many extents.
If all the After-Image extents are subsequently removed then recreated:
- after disabling after-imaging and removing the After-Image extents, they are removed.
- after adding them back they will be added into the next-available Storage Area slots.
Example: Assume 5 After-Image extents are re-created. The next-available Storage Area slot is Area 13, the resulting structure will be:
<Storage Areas 6-11 then ..>
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d1 f 128000 << AREA 12
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d2
a D:\101B\WRK\dbname.a1 v 40960 << AREA 13
a D:\101B\WRK\dbname.a2 v 40960 << AREA 14
a D:\101B\WRK\dbname.a3 v 40960 << AREA 15
a D:\101B\WRK\dbname.a4 v 40960 << AREA 16
d "Newt":17,128;8 D:\101B\WRK\dbname_17.d1 f 128000 << AREA 17
a D:\101B\WRK\dbname.a5 v 40960 << AREA 18
It is not absolutely necessary for the last Storage Area after the current After-Image files to first be removed before the After-Image's are added back. However, this depends on the intent. If the After-Image files sho.uld be AFTER the other Storage Areas, then they need to be removed along with the existing ai files, then added back before the ai files.
Example:
<Storage Areas 6-11 then ..>
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d1 f 128000 << AREA 12
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d2
d "Newt":13,128;8 D:\101B\WRK\dbname_13.d1 f 128000 << AREA 13
a D:\101B\WRK\dbname.a1 v 40960 << AREA 14
a D:\101B\WRK\dbname.a2 v 40960 << AREA 15
a D:\101B\WRK\dbname.a3 v 40960 << AREA 16
a D:\101B\WRK\dbname.a4 v 40960 << AREA 17
a D:\101B\WRK\dbname.a5 v 40960 << AREA 18
Should this be the intent, it is perhaps therfore advisable to also add x-dummy Storage Areas after the last Storage Area, in order to reserve Storage Area slots for potential future database structure changes. When the needed structure change is necessary, the placeholder Storage Area can first be removed easily (it has neither schema nor data) with the 'prostrct remove' utility, then the required area can be added with the necessary records-per-block and Type I or Type II definitions using that placeholder Storage Area number.
Example:
<Storage Areas 6-11 then ..>
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d1 f 128000 << AREA 12
d "Misc":12,128;1 D:\101B\WRK\dbname_12.d2
d "Newt":13,128;8 D:\101B\WRK\dbname_13.d1 f 128000 << AREA 13
d "PLCHOLD1":14,1;1 D:\101B\WRK\dbname_14.d1 << AREA 14
d "PLCHOLD2":15,1;1 D:\101B\WRK\dbname_15.d1 << AREA 15
a D:\101B\WRK\dbname.a1 v 40960 << AREA 16
a D:\101B\WRK\dbname.a2 v 40960 << AREA 17
a D:\101B\WRK\dbname.a3 v 40960 << AREA 18
a D:\101B\WRK\dbname.a4 v 40960 . << AREA 19
a D:\101B\WRK\dbname.a5 v 40960 << AREA 20
Please note however, it does not make any difference to the after-image processing or sequences if After-Image extents are 'between' other Storage Areas. This is purely a 'tidy-ordering' of database structure so that any end-user database, "Area 13" IS the "Newt" Storage Area for example.
Another approach is to consider the placement of AI extents and the possibility that more AI extents may be needed in the future, at initial database structure design. Where the Storage Area numbering is configured as follows:
- The first defined Storage Area starts at Area 100 (for example)
- All AI files will therefore be added sequentially immediately after the "Schema Area":6
<< bi area >>
<< Schema Area >>
<< ai areas (7 to max 93) >>
<< other areas (100 - 994 >>
Further considerations:
1. If database is enabled for Replication, replication will first need to be disabled and finally the target database will need to be re-baselined
2. Removing non-After-Image Storage Areas needs consideration if they contain database objects (tables, indexes, lobs) eg: tablemove or dump&load
3. After-Image extents will get added to the end of the current EXTENT list, not necessarily to the end of the sequence list.
Please refer to Progress Solution: P71887, "Unable to switch to new ai extent after adding a new ai extent to the database".
.