Internet Features   «Prev  Next»

Lesson 1

Browser-Based Administration with Oracle Enterprise Manager 24ai

Objective: Explain the Enterprise Manager web architecture and identify the prerequisites for securely accessing its console and managing supported Oracle AI Database 26ai targets.

Oracle Enterprise Manager 24ai provides a browser-based console for centralized monitoring and administration. Administrators use it to inspect supported databases and hosts, review monitored conditions, and run authorized management operations. The console is already a web application; it does not need to be converted into one.

Enterprise Manager 24ai and Oracle AI Database 26ai are separate products with separate release numbers. A database installation does not automatically provide a Cloud Control management deployment. Enterprise Manager can manage supported on-premises, cloud, and hybrid environments; hosting it on Oracle Cloud Infrastructure (OCI) is an option rather than a requirement.

Oracle Enterprise Manager Database Express (EM Express) is desupported in Oracle AI Database 26ai. Older instructions for enabling an embedded database console through XDB ports are therefore not the setup procedure for this module. Here, the browser connects to the Enterprise Manager management infrastructure.

How the Management Components Work Together

Enterprise Manager components and responsibilities
ComponentResponsibility
Browser consolePresents management pages to an authenticated Enterprise Manager administrator.
Oracle Management Service (OMS)Provides the management application, processes information from agents, and coordinates operations.
Oracle Management RepositoryStores management configuration and information in a supported Oracle database.
Oracle Management AgentMonitors configured targets and performs supported management work on the managed host.
Management plug-insProvide capabilities for particular target types, including Oracle Database.

Administrators interact with the console, while agents collect target information and communicate with OMS. OMS uses the repository to maintain management data. Browser access and agent communication use separate network paths that must both be configured appropriately.

A managed target does not have to reside on the OMS host. The repository also has a different purpose from an application's business database: it holds Enterprise Manager's management information. Repository availability is a dependency of the management system.

Access an Existing Console

Obtain the published HTTPS console URL from the Enterprise Manager administrator or installation records. Its general form is:

https://<management-host>:<console-https-port>/em

Replace both placeholders with the configured values. A deployment may publish a load-balancer address rather than an individual OMS hostname. The browser console port is distinct from the agent upload port and the WebLogic administration endpoint. Do not assume that an old EM Express URL identifies this console.

An authorized administrator on the OMS host can inspect the configuration using the OMS installation's emctl executable. This example is an operating-system command, not SQL:

# Replace the path with the actual OMS home.
/path/to/oms_home/bin/emctl status oms -details

Run it using the authorized OMS software-owner account and respond securely to any credential prompt. The output includes status and console address information. Use the deployment's published endpoint when a front-end address differs from the individual OMS address.

  1. Connect from an authorized network and open the published HTTPS URL.
  2. Verify that the browser trusts the certificate for the expected hostname. Resolve certificate errors rather than routinely bypassing them.
  3. Sign in with your assigned Enterprise Manager administrator account.
  4. Open an authorized target and check its availability and the freshness of its monitoring information.

A console login is different from a database SYSDBA connection. Enterprise Manager roles and target privileges determine what the administrator can see and do. Successful sign-in does not grant unrestricted access to every managed system.

Prepare Oracle 26ai Targets for Monitoring

Before adding a target, verify the supported combination of Enterprise Manager release update, database plug-in, agent, database release, and operating system. Feature support can vary by update. Certification of a database as a managed target does not establish certification of that same release as the management repository.

Preparing a target generally involves these activities:

  1. Obtain access to a supported Enterprise Manager deployment.
  2. Configure the necessary agents, plug-ins, and secure network communication.
  3. Discover and add the intended targets using the supported workflow.
  4. Configure appropriate monitoring credentials and test connectivity.
  5. Confirm target availability and recent metric collection.

CDBs, PDBs, listeners, and hosts have distinct monitoring contexts. Verify which targets were discovered and configured rather than assuming that adding a database completes every related target setup. Some management capabilities require appropriate licenses or management packs.

Distinguish Administrator, Monitoring, and Job Credentials

The administrator account identifies the person using Enterprise Manager. Monitoring credentials allow collection of information from a target. Job credentials authorize a particular database or host operation. These purposes may require different accounts and privileges.

Named credentials let Enterprise Manager store reusable credential definitions with controlled access. Configure their ownership and permitted use according to the intended operation. A monitoring account should not receive broad administrative privileges merely because a separate maintenance job needs them.

For an initial job, choose a supported information-gathering task on a test target. Check the target, credentials, schedule, and required privileges before submitting it, then review completion status and output. An Enterprise Manager job and a database DBMS_SCHEDULER job are separate mechanisms, even when both schedule administrative work.

Connect Metrics, Incidents, and Notifications

A metric measures a monitored condition. Thresholds identify conditions that warrant attention. For example, a tablespace-space metric may cross a configured warning threshold. The resulting event can be processed by an incident rule that creates or manages an incident and notifies the responsible administrator.

Choose thresholds that fit the workload and metric definition. Investigate capacity, growth, and available storage rather than assuming that every space warning requires the same action. An incident provides a way to track the response; it does not itself resolve the underlying condition.

Email notifications require mail-service configuration, recipient details, and applicable rules or schedules. Test mail delivery separately from the rule that selects events for notification. Creating a database user or OS job account does not configure email delivery.

Planned maintenance can use appropriately configured blackouts or notification blackouts. Their effects differ, so select the required monitoring and notification behavior deliberately. Metric alerts are not row-level auditing or a mechanism that automatically emails every change to business data.

Diagnose the Failing Component

When the console is unreachable, check the published address, DNS, routing, permitted network access, certificate trust, OMS health, and repository dependencies. A database listener command does not start OMS, and a target database restart is not a general remedy for a browser connection problem.

If the console works but target data is stale, inspect agent health, communication, collection errors, and monitoring credentials. If monitoring works but email is missing, inspect rule selection and the notification delivery path.

A target database can be down while the management console remains accessible. Conversely, an inaccessible console does not prove that the target database is down. Diagnose the affected component before following the site's approved restart or recovery procedure.

Module Objectives

By the end of this module, you should be able to:

  1. Explain the roles of the console, OMS, repository, agents, and plug-ins.
  2. Identify and securely access the configured Enterprise Manager HTTPS endpoint.
  3. Distinguish administrator privileges, monitoring credentials, and job credentials.
  4. Describe target discovery and verify that monitoring information is current.
  5. Configure appropriate supported jobs and review execution results.
  6. Explain how metric thresholds, incident rules, and notification configuration work together.

The next lesson examines the prerequisites and access configuration for the Enterprise Manager browser console.

Oracle Documentation


SEMrush Software 1 SEMrush Banner 1