Kbase P123000: How to upgrade Fathom / OpenEdge Replication target database from 10.0B or 10.1A to 10.1B?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/02/2008 |
|
Status: Verified
GOAL:
How to upgrade Fathom / OpenEdge Replication target database from 10.0B to 10.1B?
GOAL:
How to upgrade Fathom / OpenEdge Replication target database from 10.1A to 10.1B?
GOAL:
Considerations upgrading Fathom Replication to OpenEdge 10.1B
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge Replication 10.x
Fathom Replication 3.0A
FIX:
When upgrading to OpenEdge 10.1B it is necessary to disable AI (hence replication), due to changes that have been implemented for 64-bit datatypes and dbkeys. AI cannot contain old notes (10.0x/10.1A type) and new notes (10.1B type) - which is why disabling / enabling of AI is required.
Both the source and target system must be using OpenEdge 10.1B. There is no method to convert a target database to OpenEdge 10.1B without invalidating the replication setup. This is due to the conversion process to an OpenEdge 10.1B database requiring a truncation of the BI file.
A backup of the converted source database (10.1B) must therefore be restored to the target system (10.1B) and the new target database must then be enabled as a replication target database.
Steps:
[Source] pre 10.1B environment
0) take an online probkup of source prior to upgrading
$ probkup source source00.bak
1) stop the source database
$ proshut source -by
2) disable replication
$ rfutil source -C disablesitereplication source
3) disable AI
$ proutil source -C aimage end
4) truncate BI
$ proutil source -C truncate bi
5) if this is a pre OpenEdge 10 database (ie Progress 9.x, 8.x) a database conversion is necessary. Please refer to the Database Administration Guide and reference for the appropriate conversion utilities (proutil -C [conv910 | conv89])
Notes on source.db structure:
A) If there are any resident two-phase-commit extents, now is a good time to remove the .tl extent as 2PHASE is invalid with OER.
$ prostrct remove source tl
$ prostrct list source source.st
B) Review the current ai extent structure are still sufficient in number and size, we recommend that FIXED ai extents are used on replication-enabled databases.
C) Changes to the source structure need to be reflected in the target structure when the source backup is eventually restored (prorest) to the target environment. Where the target database structure may have more extents than the source database in any given area it cannot have missing areas (with the exception of ai files which are not an absolute requirement).
[Source] OpenEdge 10.1B environment
1) proserve/proshut .. this is just to set the 10.1B version update
If using Type II Storage Areas, consider running the OpenEdge 10.1B 'record fixup' option of: dbtool source, Option 9, option 6.
This is to ensure that there are no records or fragments smaller than 10-bytes in the source database. If there are, the utility will re-create them with the OpenEdge 10 header. Otherwise, it can cause problems later with the 64-bit recids introduced to 10.1B. Please refer to Solution P123869 - "10.1B Database crashes with System error 822"
Note: this utility can also be run ONLINE later, where any changes will be replicated to the target, assuming the need for 64-bit keys are not needed before then.
2) add ai extents, if needed:
$ rfutil source -C mark backedup
$ prostrct add source source_ai.st
** Suggest adding FIXED ai extents as opposed to variable extents **
3) enable after-imaging:
$ rfutil source -C aimage begin -G 0
4) enable the ai archiver deamon (if required)
$ rfutil source -C aiarchiver enable
5) Start the source db under OpenEdge 10.1B
proserve source -S 4500 -B 10000 -L 10000 -spin 50000 -pica 4096 -bibufs 30 -aibufs 45 -aistall -bithold 75000 -bistall [-aiarcdir D:\101B\WRK\repl\source\ais -aiarcinterval 1800 ] -shmsegsize 128 -pinshm
[Source] 10.1B - enable replication online once the target envionment is ready:
The source database is still running ...
make sure the source.repl.properties file in place includin.g the "defer-agent-startup=1440" parameter.
make sure there are NO source.repl.recovery files remaining from the previous replication environment.
6) enable replication online (same cmd)
$ proutil source -C enablesitereplication "source"
Note, without the quotes on "source"
7) take an online probkup with the -REPLTargetCreation parameter (is case sensitive)
$ probkup online source source_b -REPLTargetCreation
NOTE: Do not perform additional online backups against the source until the target database is up and running.
Transfer the online backup to target machine with the appropriate checks on maintaining time-stamps and verification on full filesize transfer (checksum, md5 etc)
[Target] 10.1B environment
Again, make sure there are no target.repl.recovery files remaining from the previous replication environment
make sure that the target.st file is the same as the source.st file
make sure the target.repl.properties file in place
1) Restore target:
$ prorest target source_b
2) Disable the ai archiver deamon on target (if previously enabled)
$ rfutil target -C aiarchiver disable
3) Enable the database as a replication enabled target database
$ proutil target -C enablesitereplication "target"
Note, without the quotes on "target"
4) Start the target database
$ proserve target -S 4501 -B 10000 -L 20000 -spin 50000 -bibufs 30 -pica 4096 shmsegsize 128 -DBService replagent
[Source] OpenEdge 10.1B environment
5) Start the replication server
$ dsrutil source -C restart server
Note: The next time the source database is started, ensure that the appropriate startup command is added: -DBService replserver.