Orachangeuser fail during Change manager synchronization wizard

Question

Here is the story:
I have a schema and I want to duplicate it,
and alter some features.
So I launch Change Manager, Create a comparsion between my
reference schema and my empty, target schema.
I then use Tools - Synchronization Wizard, select all objects,
and it generates a change plan for me.
So far, so good.
When I run the plan script,
it displays an error after every attempt to "change user".
The error displayed is
"orachangeuser failed for sys".
I ask myself "What is orachangeuser, and why is it trying to change
the user to my target schema's user?"
Anyway, if I ignore the errors, and press "CONTINUE", it finished just fine.
Only problem is I must press "CONTINUE" once for every orachangeuser, which
is annoying.
So I edit the script.
Before, proc cmchangeuser looked like this:
# CM Priv - change all orachangeuser to call cmchangeuser.
proc cmchangeuser {cur name} {
global current_user
if {$name == $current_user} {
} else {
orachangeuser $cur $name
set current_user $name
After I change it, to gut the orachangeuser part, it looks like this
# CM Priv - change all orachangeuser to call cmchangeuser.
proc cmchangeuser {cur name} {
global current_user
set current_user $name
Then I run the script and it works.
Does anybody know what is going on here?
Is orachangeuser an obsolete thing?
I'm using Oracle Enterprise Manager 9.2.0.1.0 in standalone
mode on a Personal Oracle Instance.
The weird thing is that I seem to recall getting such sycnhronization scripts to work
just fine on this
machine a week ago.
And if I choose just ONE table from the dozens in the schema,
it also works fine, executing the orachangeuser command.
thanks,
David Kreth Allen
Minneapolis, MN

Answer 1

Isn't it also true that in a stretched DAG with even numbered nodes, the PAM needs to be in the same site as the active DAG node?  If the connection between both nodes goes down, and the PAM is in the "passive" site, the primary node will
dismount the databases since it can't check with the PAM to make sure its safe for it to be up.  
In a even-numbered node stretched DAG, the PAM changes to the DR/passive site everytime a failover occurs, but doesn't automatically switch back when you reactivate the primary node.