OEM(Oracle Enterpise Manager):

Transcription

1 OEM(Oracle Enterpise Manager): Oracle Enterprise Manager is Oracle system management tool through which you can: Administer,diagnose and tune mul:ple databases. Distribute so>ware to mul:pe servers and clients. Schedule jobs on mul:ple databases. Oracle Enterprise manager acts as central point of control for managing database systems. Below are the components of OEM: Oracle Management Agent (Agent): As implied by the name, this is a piece of so>ware installed on a host. This so>ware runs on the host and collects informa:on about the targets on the host. The agent can also be configured to monitor targets on remote hosts. The collected data is then passed onto the management service.agents connects to target database as DBSNMP and ASM instance as ASMSNMP. Oracle Management Service (OMS): This is the brain of the OEM. This is a J2EE web applica:on that provides the management func:onality. It acts as the centralized management solu:on and also acts as the server to which all the management agents upload the collected data. Only for gridcontrol/clod control.in 10g Oracle applica:on server was used for OMS and in 11g its weblogic. OEM Console: This is the user interface that exposes all the management func:onali:es to the end user of OEM. It's the interface through which the OEM and the end user communicate with each other. Oracle Management Repository: This is the central repository that is used by the OMS to store all data. It hosts the complex schema that is used by the OMS to provide the management func:onality.sysman schema is used to store the repository. By Default sys,system,sysman can loginto OEM. If you want to add users please click on setup and then on the le> click on Administrators and then you can create the users. OEM can be configued as dbcontrol or gridcontrol/cloud control. In Dbcontrol agent,console and repository are on the same host. In gridcontrol/cloud control on targets agents will be running and OMS server will be running on the OMS server and has 1 repository for all the targets.

2 In DB control: To create repository: $]emca repos create To configure dbcontrol: $]emca config dbcontrol db To drop repository: $]emctl repos drop To deconfig dbcontrol: $]emca deconfig dbcontrol db To check the agent status: $]emctl status/start/stop agent To check the dbconsole status: $]emctl status/start/stop dbconsole If there are any issues with agent we can try to clear agent state: $]emctl clearstate agent To verify agent is able to upload inormahon to repository: $]emctl upload agent. Database control

3 Grid control/cloud Control: In Grid control we need to start OMS to bringup the OMS and WebHer: $]$OEM_HOME/oem/bin/emctl start/stop/status oms On Targets we will start OEM agents: $]$AGENT_HOME/core/<agent-version>/bin/emctl start/stop/status/clearstate agent. To create blackout and stop blackout $AGENT_HOME/core/<agent-version>/bin/emctl start <blackout-name> -nodelevel $AGENT_HOME/core/<agent-version>/bin/emctl stop <blackout-name> To look at HTTP server status : $]/u02/app/oracle/product/12c/gc_inst/webtierih1/bin/opmnctl status l/stop/start To verify whether target host is able to communicate with OMS: $]emctl pingoms To upload to OMS from agent host: $]emctl upload agent Database control vs grid control: The big advantage of Grid Control over Database Control is, obviously, the ability to manage mul:ple databases with one tool. With Grid Control it is much easier to manage all of your databases uniformly. You can apply consistent monitoring rules to all databases. If you have certain DBAs responsible for only certain databases you can create Groups of databases. If you have a rota:ng on-call schedule you can configure the No:fica:on Rules to alert the proper person in case of a problem. You can submit jobs to mul:ple databases at once and even apply patches to mul:ple databases at once. If you have scheduled maintenance coming up, you can create a Blackout for all the databases on a host at one :me. Database control comes pre-installed with RDBMS installa:on and easy to maintain. Where as grid control requires to buy license. With grid control we have overhead of maintaining OMS server,oms database and OEM agents. We need to patch the agents and OMS periodically to fix the bugs.

4 Grid Control/Clod control

5 LocaHons of logfiles to trouble shoot the issues: 1. Agent logfiles will be present under $AGENT_HOME/sysman/log. gcagent.log and emctl.log are the important files to troubleshoot issue. 2. OMS logs are under <EM_INSTANCE_BASE>/em/<OMS_NAME>/sysman/log /u01/app/oracle/gc_inst/em/emgc_oms1/sysman/log a. emoms.trc this is most important trace file that contains oms ac:ons and errors. b. emoms.log - It has oms star:ng/stopping/any error when it generates an error. c. emctl.log - emctl commands are logged in this file 3. Weblogic Server - Since em applica:on run inside weblogic server. So these logs are o>en very important and contain useful info. <EM_INSTANCE_BASE>/user_projects/domains/<domain_name>/servers/<SERVER_NAME>/logs/ <SERVER_NAME>.out /u01/app/oracle/gc_inst/user_projects/domains/gcdomain/servers/emgc_oms1/logs/emgc_oms1.out 4. WebTier logs can be found under <EM_INSTANCE_BASE>/<web:er_instance_name>/diagnos:cs/logs/OHS/<ohs_name> /u01/app/oracle/gc_inst/webtierih1/diagnos:cs/logs/ohs/ohs1 5. OPMN log <EM_INSTANCE_BASE>/<web:er_instance_name>/diagnos:cs/logs/OPMN/<opmn_name> /u01/app/oracle/gc_inst/webtierih1/diagnos:cs/logs/opmn/opmn1