Dave
One of the reasons the agent was completely rebuilt with 12c was because of the
restart issues you referred to below, so it might be worthwhile investigating a
migration to 12c as a longer term scenario.
Coming back to your question on the primary / standby config, the only way EM
can handle this for you is if both primary and standby are managed by the same
agents. As a single agent cannot communicate to multiple OMS's, Courtney's
original comment that this could not be done with multiple EM's is correct - as
I would expect. :)
Now, the other alternative is to have two agents monitoring each database. I
have seen that done - for example, when Platinum Services is monitoring an
environment and a customer still wants to monitor it as well. However, that
can get VERY messy very quickly (who responds to alerts, who patches, etc.
etc.) so I wouldn't advise that set up. Even in that case, I'm not sure what
you want can be done. It MIGHT be able to be done that way, but I'd want to
see some serious testing before I'd rely on it, and as I say it would open a
whole lot of other issues as well.
Pete
Pete Sharman
Database Architect, DBaaS / DBLM
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
Email: pete.sharman@xxxxxxxxxx Twitter: @SharmanPete LinkedIn:
au.linkedin.com/in/petesharman
Website: petewhodidnottweet.com
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
"Oh no, it's not, it's much harder than that!"
Bruce Pihlamae, long term Oracle DBA
-----Original Message-----
From: Herring, David [mailto:HerringD@xxxxxxx]
Sent: Tuesday, June 2, 2015 4:31 AM
To: Peter Sharman; oracle-l@xxxxxxxxxxxxx
Cc: Courtney Llamas
Subject: RE: EM DG switchover across EM repositories?
Sure, I'll check the link. My reasoning is that we have a number of
installations in both the UK and US, many with either OGG or DG configured.
The line between the 2 locations is limited and closely monitored. We've had a
few situations when loads have been heaviest on the app side in terms of
changes that log ships failed and for whatever reason an automatic attempt
wasn't made to retrieve the log so we had to do it manually. This isn't the
direct reason of why we have 2 different EMs but more an example of line issues
and why limiting traffic is so important. I can make all the recommendations
of why it's necessary to increase bandwidth but I'm at the mercy of those who
pay for it.
In addition to the above example, we have under 11g registered both UK and US
targets in an 11g EM in the UK. Unfortunately those US agents would frequently
require restarts due to communication problems. Maybe issues like this are
resolved under 12c and if so, great but my hope was to eliminate as much as
possible any trans-atlantic traffic as it related to EM. Now if I can't avoid
that when wanting full DG capabilities then I'll accept that and continue with
work-arounds as necessary.
Pete, do you know for sure that want I'm hoping for won't work, that both
primary and standby need to be in the same EM?
Regards,
Dave
Dave Herring
DBA
103 JFK Parkway
Short Hills, New Jersey 07078
Mobile 630.441.4404
dnb.com
-----Original Message-----
From: Peter Sharman [mailto:pete.sharman@xxxxxxxxxx]
Sent: Monday, June 01, 2015 1:16 PM
To: Herring, David; oracle-l@xxxxxxxxxxxxx
Cc: Courtney Llamas
Subject: RE: EM DG switchover across EM repositories?
Though the question should be asked, what's the reason for having two EM
repositories in the first place? There are valid reasons for doing that, but
more often than not the reasons people have it set up that way is often a
misunderstanding of EM capabilities. See
http://dbasushi.com/one-em-to-rule-them-all for a good coverage of that.
Pete
Pete Sharman
Database Architect, DBaaS / DBLM
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
Email: pete.sharman@xxxxxxxxxx Twitter: @SharmanPete LinkedIn:
au.linkedin.com/in/petesharman
Website: petewhodidnottweet.com
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
"Oh no, it's not, it's much harder than that!"
Bruce Pihlamae, long term Oracle DBA
-----Original Message-----
From: Courtney Llamas
Sent: Tuesday, June 2, 2015 3:03 AM
To: HerringD@xxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: EM DG switchover across EM repositories?
Both targets would need to be in the same EM repository for EM to handle this
switchover.
-----Original Message-----
From: Herring, David [mailto:HerringD@xxxxxxx]
Sent: Monday, June 01, 2015 11:33 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: EM DG switchover across EM repositories?
Folks,
Does anyone know if it's possible to perform a Data Guard switchover (from
within EM) from primary to physical standby where each is registered in a
different EM repository? We have DG configured so that the primary dbs are in
the UK and the physical standbys are in the US. The UK targets are registered
with a UK repository and the US targets are registered with a US repository.
Ideally we'd use EM for the switchover but I haven't been able to confirm if
this is possible or not using separate EM repositories.
Obviously actually performing the test will show me but I've been asked to draw
up all the steps and tests ahead of time, get everything ready and meet various
project plan deadlines with all this BEFORE doing anything, which is why it's
critical for me to know ahead of time if it's even possible. I didn't see any
references to doing this with separate EM repositories in the doc and while I
have an SR open with Oracle for confirmation, I'm struggling in getting them to
understand my question.
The configuration consistents of multiple 2 to 4-node RACs on each side (UK and
US), database ver is 11.2.0.4. The complexity for now is that the US dbs are
registered in a 12c repository whereas the UK dbs are registered in a 11g
repository. Once FW rules are pushed tomorrow night I should be able to move
those 11g-registered dbs to a 12c repository in the UK.
Thx.
Dave
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
