How to Change the Oracle OEM Domain in a URL

 How to Change the Oracle OEM Domain in a URL

Oracle Enterprise Manager (OEM) is a robust tool used for monitoring and managing Oracle environments. Occasionally, you may need to update the domain name in the OEM URL, such as when transitioning to a new network, updating a Fully Qualified Domain Name (FQDN), or integrating with new DNS settings. This blog outlines the step-by-step process to change the domain name in the OEM URL.

Why Change the OEM Domain?

There are several reasons you might need to update the domain in the OEM URL:

• Network migration: Moving OEM to a new network.

• Domain standardization: Aligning with organizational naming conventions.

• SSL updates: Adopting a new domain for secure connections.

For example, changing the URL from 

https://oem.old-domain.com:7801/em   to 

https://oem.new-domain.com:7801/em.

Steps to Change the Domain

Step 1: Update Hostname in Configuration Files

1. Locate the OEM Configuration Directory: Navigate to the configuration directory in your Oracle Management Service (OMS) installation:

   cd $OMS_HOME/sysman/config

2. Modify the emoms.properties File: Open the emoms.properties file:

   vi emoms.properties

   Update the URL to reflect the new domain:

   oracle.sysman.eml.mntr.emdURL=https://<new-domain>:<port>/emd/main

   Save and exit the file.

3. Check the emomslogging.properties File: Review this file for any references to the old domain and update them if needed.

4. Backup Configuration Files: Before proceeding further, ensure that you back up all configuration files in the directory:

   cp *.properties /backup/location/

---

Step 2: Update the WebLogic Server Configuration

1. Access the WebLogic Admin Console: Navigate to the WebLogic Admin Console at:

   http://<current-domain>:7001/console

   Log in using your WebLogic admin credentials.

2. Update the Server URL:

   • Go to Servers > AdminServer > Protocols > HTTP.

   • Update the Listen Address to the new FQDN.

   • Save and apply the changes.

3. Restart WebLogic Services: Stop and restart the WebLogic Admin and Managed Servers:

   $DOMAIN_HOME/bin/stopWebLogic.sh
   $DOMAIN_HOME/bin/startWebLogic.sh

4. Verify Changes in WebLogic Logs: Monitor the WebLogic logs to ensure there are no errors during the restart:

   tail -f $DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log

---

Step 3: Update the Repository Information

1. Stop OMS:

   $OMS_HOME/bin/emctl stop oms

2. Update the OMS Configuration: Run the following command to update the domain name in the repository:

   $OMS_HOME/bin/emctl config oms -repos_pwd <repository_password>

3. Restart OMS:

   $OMS_HOME/bin/emctl start oms

4. Synchronize Agents: Ensure that all OEM agents are synchronized with the new domain by reconfiguring them:

   <AGENT_HOME>/bin/emctl stop agent
   <AGENT_HOME>/bin/emctl clearstate
   <AGENT_HOME>/bin/emctl start agent

---

Step 4: Validate the New URL

1. Access the New OEM URL: Open a browser and visit:

   https://<new-domain>:<port>/em

   Ensure the page loads correctly.

2. Test Agent Connectivity: Verify that all agents can communicate with the new OMS URL:

   <AGENT_HOME>/bin/emctl status agent
   <AGENT_HOME>/bin/emctl upload

3. Validate Reporting: Test report generation and dashboard views to ensure the changes did not disrupt critical OEM functionality.

---

Step 5: Update DNS and SSL Certificates (if Applicable)

1. Update DNS Records: Ensure the new domain is mapped to the OEM server's IP address in the DNS system.

2. Regenerate SSL Certificates: If SSL is enabled, regenerate certificates with the new domain name using Oracle Wallet Manager or a tool like OpenSSL. Replace the old certificates on the server.

3. Restart HTTPS Services: After updating SSL certificates, restart HTTPS services to apply changes:

   $OMS_HOME/bin/emctl secure oms -remove
   $OMS_HOME/bin/emctl secure oms -enable

---

Verification

1. Monitor Logs for Errors: Check the OEM logs for any errors during or after the update:

   tail -f $OMS_HOME/sysman/log/emctl.log

2. Validate with RMAN: Run an RMAN validation to ensure no issues in agent communication:

   RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

3. Perform a Full System Health Check:

   • Run a database diagnostic check using OEM.

   • Confirm all critical alerts and notifications are working as expected.

---

Best Practices to Prevent Future Issues

• Backup Configuration Files Regularly: Always take a backup before making any configuration changes.

• Monitor Undo Tablespace and Redo Logs: Maintain sufficient space to avoid database corruption during recovery.

• Apply Oracle Patches: Keep your Oracle environment updated with the latest patches.

• Document Changes: Maintain detailed documentation of all changes made to facilitate troubleshooting and audits.

---

By following these steps, you can seamlessly change the domain name in the Oracle OEM URL while ensuring minimal disruption to monitoring and management activities. 

Step by step to resolve ORA-600 4194 4193 4197 on database crash (Doc ID 1428786.1)

 Step by step to resolve ORA-600 4194 4193 4197 on database crash (Doc ID 1428786.1)

The following error is occurring in the alert.log right before the database crashes.

ORA-00600: internal error code, arguments: [4194], [#], [#], [], [], [], [], []

This error indicates that a mismatch has been detected between redo records and rollback (undo) records.

ARGUMENTS:

Arg [a] - Maximum Undo record number in Undo block
Arg [b] - Undo record number from Redo block

Since we are adding a new undo record to our undo block, we would expect that the new record number is equal to the maximum record number in the undo block plus one. Before Oracle can add a new undo record to the undo block it validates that this is correct. If this validation fails, then an ORA-600 [4194] will be triggered.

This issue generally occurs when there is a power outage or hardware failure that initially crashes the database. On startup, the database does the normal roll forward (redo) and then rollback (undo), this is where the error is generated on the rollback.

This also can be cause by the following defect

Bug 8240762 Abstract: Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] after SHRINK

Details:
Undo corruption may be caused after a shrink and the same undo block may be used
for two different transactions causing several internal errors like:
ORA-600 [4193] / ORA-600 [4194] for new transactions
ORA-600 [4137] for a transaction rollback.

Solution

----------

Best practice to create a new undo tablespace.
This method includes segment check.

1. Create pfile from spfile to edit
SQL> Create pfile='/tmp/initsid.ora' from spfile;

2. Shutdown the instance

3. set the following parameters in the pfile /tmp/initsid.ora
    undo_management = manual
    event = '10513 trace name context forever, level 2'

4. SQL>>startup restrict pfile='/tmp/initsid.ora'

5. SQL>select tablespace_name, status, segment_name from dba_rollback_segs where status != 'OFFLINE';

This is critical - we are looking for all undo segments to be offline - System will always be online.

If any are 'PARTLY AVAILABLE' or 'NEEDS RECOVERY' - Please open an issue with Oracle Support or update the current SR.  There are many options from this moment and Oracle Support Analyst can offer different solutions for the bad undo segments.

If all offline then continue to the next step

6. Create new undo tablespace - example
SQL>create undo tablespace <new undo tablespace> datafile <datafile> size 2000M;

7. Drop old undo tablespace
SQL>drop tablespace <old undo tablespace> including contents and datafiles;

8. SQL>shutdown immediate;

9 SQL>startup nomount;  --> Using your Original spfile

10. Modify the spfile with the new undo tablespace name

SQL> Alter system set undo_tablespace = '<new tablespace created in step 6>' scope=spfile;

11. SQL>shutdown immediate;

12. SQL>startup;  --> Using spfile
 


The reason we create a new undo tablespace first is to use new undo segment numbers that are higher then the current segments being used.  This way when a transaction goes to do block clean-out the reference to that undo segment does not exist and continues with the block clean-out.