We are running on One system approach,
What is "One system approach"? What does that even mean?
what are the best options to reduce the downtime?
Downtime of what? your database? Your OEM
also, what are the steps to backout?
Should be in the installation docs.
Since you are talking of "OEM upgrade", I presume you mean some version of Grid Control. (The term OEM is a bit generic and is often used to also refer to the single-database version, aka 'dbcontrol')
In short, you question is pretty vague and so cannot be answered with any confidence or precision. Please provide more detail on exactly what product you want to "upgrade", what version you want to upgrade from/to, and some description of the landscape you are running.
I should have admitted that - i am new to OEM!
1. We are planning to upgrade OEM infrastrcture "from 11 & 12.x to 188.8.131.52"
2. What is "One system approach"? What does that even mean?
i am referring to this doc. one system is - one OEM infrastructure ( management agent, oms & repo DB).
3. Downtime of what? your database?
Yes, the OEM itself
Another additional question to this list
1. we are currently using OEM for monitoring, we have separate prod OEM infra & non prod OEM infra. is this recommonded by oracle ? if yes why, if not what is recommonded by oracle & why?
There are two methods to upgrade from 11g to 12c -- one system and two system.
One System basically is a traditional upgrade performed on the existing EM system. You must upgrade all agents before hand, which can be difficult if you have many agents. Basically you shut down Em 11g, upgrade it, and you're effectively down until the upgrade completes and the agents start communicating over the 12c agent.
Two System agent is a way to minimize downtime. Basically you take a copy (backup/restore) of your repository database, then you upgrade the copy (new oms server = extra hardware available). Then you go thru a process of switching over the agents. If you have a very busy system or lots of agents, this is a good choice! The flexibility to have both 11g and 12c up and running for a while, and switchover the agents in batches is also a great way to ensure that things are working the way you want before you cutover all agents.
I would suggest watching some of the resources available on the Oracle Learning Library - https://apex.oracle.com/pls/apex/f?p=44785:141:0::::P141_PAGE_ID,P141_SECTION_ID:16,93 and on OTN - http://www.oracle.com/technetwork/oem/install-upgrade/index.html .
As far as one system or two, that really depends. Ideally most customers like to have one system that monitors all their targets. A single pane of glass. There are some reasons why customers might choose to split their environments.
1. Some customers have requirements to segregate non-prod and prod by separate networks, others just like to keep them apart for management reasons.
2. Another reason is to have a test bed, if you have a large environment splitting pro/non-pro allows a better Test of any patches/changes for agent load and target load.
What ever option you choose, It is recommended to have a development/sandbox env where you test patches/changes before applying to production.
Here is a link to the 12cR3 documentation set:
Since you are new to EM, I suggest you start reading some of these manuals. Specifically the Upgrade Guide therein. Most of your upgrade questions will be answered there.
Other question i have is -
In a one system method, there is always an outage. But, what in a Primary & DR environement
1.Is there a dependency between Primary & DR as OEM is concerned?
2. If there is no depedency - can we use two system approach between Primary & DR?
The 1-system upgrade remains the same for the primary OMS and for any other additional OMS you can use add OMS procedure to create clone of first OMS.