Latest Posts

Oracle Enterprise Manager 13c Release 4 – Time to Upgrade – First Experiences

The roll-out of the newest Oracle Enterprise Manager 13 Release 4 is a few days old, about time to try out the upgrade process in my ESXi lab environment.

First: This blog post about the OEM upgrade process is based on my own experience.

Software

https://www.oracle.com/enterprise-manager/downloads/cloud-control-downloads.html

Documents

https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emupg/index.html

The Environment

  • Oracle Enterprise Manager 13.3 running on Oracle Linux 7.6 – OEM Patchlevel January 2020 – Non-HA
  • Oracle Enterprise Edition Repository 19.6.0 Single Tenant Database 
  • Oracle Restart / ASM 19.6.0
  • Additional Oracle Linux Server with 19.3.0 Container Databases
  • All targets up and running
  • My Oracle Support connected
  • Software staged directory in /u01/app/oracle/stage/em13cr4 and permission changed to execute bin file (chmod u+x em13400_linux64.bin).

Prerequisites

It’s important to verify the changed prerequisites – Chapter 3 – Prerequisites for Upgrading to Enterprise Manager Cloud Control 13c Release 4 – I had do disable all adaptive features in the repository pluggable database:

Restart the database after the changed settings.From my view this sentence here is wrong is the documentation (my database has version 19.6.0):

If your Management Repository is using Oracle Database 12.2 or higher, none of these parameters need to be set. 

Why? If these parameters are not set, the installer refuses working.

EMKEY Copy Requirements

The Key was copied to the repository. It well be removed after the successful upgrade.

Run Installer

Start the Oracle Universal Installer

The OMS is down now (emctl stop oms -all). Start the installer.

My Oracle Support Details

I am a registered user in My Oracle Support, I get enough information every week… I don’t enable this checkbox.

Software Updates

At the moment, there are no updates available. Maybe in future there will be any patches available for auto apply during the installation/upgrade process.

Installation Type

Upgrade an existing Enterprise Manager system, this one is my existing installation.

 

Installation Details

Enter a new Middleware Home Location.

Database Connection Details

Enter the SYS and SYSMAN password of the running repository. DDMP (Deferred Data Migration) Jobs are enabled. According the documentation, these jobs are running in the background when the OEM is starting up during the upgrade process to convert old data to the new format. If you have a huge amount of data in your earlier release, then the upgrade can take longer. You can run this job – if disabled – later as Post Upgrade Tasks.

Warnings

I will change to SHA communication later.

The repository has 19.6.0, all required patches are included.

I confirm that the JVMD engine is stopped, this has happened by stopping the OMS.

I had to stop the agent which was running on the management server.

Fix Parameter Settings by the Installer

For my environment, I let the installer fix this settings.

Plug-in Upgrade

Here we see the already installed plugins, they will be upgraded too.

Select Plug-ins

I don’t ant to install additional plug-ins.

Extend WebLogic Server Domain

Enter the password for the weblogic user and define the OMS Instance Base Location.

Enterprise Manager Shared Location Details

My Oracle Enterprise Manager doesn’t run in a high availability setup, I don’t need any shared location.

Port Configuration Details

I use the settings from the existing installation.

Review

Let’s start the upgrade!

Repository Upgrade failed

The upgrade process fails at the step where the repository has to be upgraded.

View Log – ORA-01950

When I scroll up the provided log from the installer, I see this error message here:

The schema manager logfile located in the 13.4 subdirectory $ORACLE_HOME/sysman/log/schemamanager confirms this error.

At this point, this is curious, because in 13.3, there were no objects of the SYSMAN in the USERS tablespace. All objects are located in OEM tablespaces with the MGMT prefix. Here is a list of objects in a repository where an Oracle Enterprise Manager 13c Release 3 is up and running.

The solution is simple. Just grant the permissions for the USERS tablespace to SYSMAN and retry the installation progress.But, don’t ask me why SYSMAN creates now objects in USERS…

After a while, you can see new created tables and indexes in tablespace USERS for user SYSMAN.

The repository upgrade step runs fine now, the whole upgrade process continuous.

Finish

After while, yes we did it, the root script execution is the last task. 

Script execution.

The Enterprise Manager is now running with Release 4.

About Enterprise Manager

Next steps are

  • upgrade the Oracle agents
  • uninstall the old OEM software –  btw, the installer already detaches the old ORACLE_HOME from Oracle’s central inventory for you and removes the emkey from the repository 🙂

Summary

This is a lab environment, not a huge setup with hundreds of targets. But we can see here two important points for the upgrade process. a) read the manual and disable all adaptive features, even when you have an 19c database and b) user SYSMAN needs permission on the USERS tablespace. This is very unusual and should be corrected from my side. But now, enjoy Oracle Enterprise Manager 13c Release 4!

Oracle Cloud Infrastructure – Change a Compute Instance Shape – Tested

There is a new feature available in Oracle Cloud infrastructure since the 13th of January 2020, now you can change the shape of a Compute instance. It replaces all the manual steps like stopping the existing instance, create a new one, attach the block device etc. – this is a short summary how it works.

From the OCI Release Notes :

You can change the shape of a virtual machine (VM) instance without having to rebuild your instances or redeploy your applications. This lets you scale up your Compute resources for increased performance, or scale down to reduce cost. 

My existing Compute Instance

The existing machine has the shape VM-Standard2.1 – one OCPU and 15GB of memory.

Change the Shape

Actions – Change Shape

Select the new shape – for the test case I selected VM-Standard2.2 – press Change Shape.

On Compute instance level, you can verify the work request UpdateInstance.

In the details of the work request, the progress is visible.

After tree minutes, the machine runs with the new shape and is ready to use.

Summary

Changing and existing Compute shape is a feature what I have waited for since the beginning of OCI, after a few minutes the instance is back again with the new shape. I hope Oracle will now implement it for DBaaS too in the next weeks.

MV2ADB – One-Click Move of your Data into OCI Autonomous Databases – Auto Operation

In the previous blog post MV2ADB – One-Click Move of your Data into OCI Autonomous Databases – Step by Step I wrote about the new Oracle Cloud Infrastructure tool to transfer local data into Autonomous Databases step by step. There you see how to install and configure mv2adb and how to transfer your data to ADB step by step.

The auto operation parameter is now “all in one”, one parameter and all required steps like export, transfer etc. are done fully automated.

Prerequisites

  • mv2adb rpm package installed, always get the newest version from My Oracle Support (Doc ID 2463574.1)
  • HTTP/SQL*Net Connectivity from the on premises server to the Autonomous Database
  • Autonomous Database Wallet (can be downloaded from the ATP main page)
  • Instant Client with Basic Package, SQL*Plus Package and Data Pump, SQL*Loader and Workload Replay Client – if there is an existing RDBMS installation 18.3 or higher, you can use it
  • Java executable – same like above, you can use the RDBMS installation too
  • Perl Release 5.10 or above
  • Optional: Oracle OCI Command Line Interface – https://docs.cloud.oracle.com/iaas/Content/API/Concepts/cliconcepts.htm installed and configured

Let’s go – we transfer the local HR Schema to ADB fully automated

Example with parameter OCIC=true – visible in the output lines where the OCI bucket upload is done.

Verification

Summary

The auto function completely eliminates the manual steps to upload your data into an Autonomous Database steps. And in case of any error, you have the same logfiles like you do it step by step. Great!

#ilikeit

MV2ADB – One-Click Move of your Data into OCI Autonomous Databases – Step by Step

There is a new Oracle Cloud Infrastructure tool available called MV2ADB(ADB) MV2ADB: move data to Autonomous Database in “one-click” (Doc ID 2463574.1). All steps which have to be executed manually to transfer data into an Autonomous Database are now automated:

  • Advisor for local schemas
  • Oracle Data Pump local export
  • Transfer into Oracle Cloud Infrastructure Object Store
  • Create Autonomous Database Credentials to get access on the Object Store
  • Oracle Data Pump local import
  • Verify Oracle Data Pump import logfile

The data transfer job can be done fully automated or step by step (autonomus schema advisor, export data, create bucket, upload dump files etc.). In this blog post I describe the manual steps.

How it works

Image from My Oracle Support Note 2463574.1:

 

 

 

 

 

 

 

 

 

 

 

Prerequisites

  • mv2adb rpm package installed, always download the newest version from My Oracle Support (Doc ID 2463574.1)
  • HTTP/SQL*Net Connectivity from the on premises server to the Autonomous Database
  • Autonomous Database Wallet (can be downloaded from the ATP main page)
  • Instant Client with Basic Package, SQL*Plus Package and Data Pump, SQL*Loader and Workload Replay Client – if there is an existing RDBMS installation 18.3 or higher, you can use it
  • Java executable – same like above, you can use the RDBMS installation too
  • Perl Release 5.10 or above
  • Optional: Oracle OCI Command Line Interface – https://docs.cloud.oracle.com/iaas/Content/API/Concepts/cliconcepts.htm installed and configured

mv2adb – Options

Configuration File

The mv2adb install process provides an example of a configuration file – here is my version with OCI CLI enabled. Take care and read the example and the comments. At this point, thanks to Ruggero Citton from Oracle’s Cloud Innovation and Solution Engineering Team for his great support to find my configuration mistake. If you dont’ want to use the configuration file, all parameters can be attached to the mv2db command.

All passwords have to be encrypted with the mv2adb encpass command ind advance.

For the parameter OCI_PASSWORD, you have to create an OCI Authentification Token first in the console or by CLI and encrypt the provided password.

In this configuration file, I use the OCI CLI. In this example we transfer the Oracle demo schema HR. Take care about the Expdp/Impdp Parameters, if you want to encrypt the Data Pump export files, you need an additional Advanced Security Option ASO. No license? Just comment it out or let the parameters blank.

 

 

Let’s go – we transfer the local HR Schema to ADB

18/12/2019: At the moment I have some trouble with the automated function which is doing all steps at one (option auto)  – this is under investigation.

0. Advisor

It executes the ADB Schema Advisor. This advisor provides information if your data can be transferred into the cloud and which database objects are problematic. If you want to know more, take a look at this My Oracle Support Note: Oracle Autonomous Database Schema Advisor (Doc ID 2462677.1) Excerpt from the output with the hint that user defined tablespaces are not allowed in an ADB environment (If you want to verify it: The manually executed CREATE TABLESPACE command results into ORA-01031: insufficient privileges).

In the background, a temporary user called ADB_ADVISOR is created to analyse the data (Script @/opt/mv2adb/utils/install_adb_advisor.sql). The user will be dropped automatically after the run.

1. Create an OCI Object Storage Bucket called ocibucket01

2. Execute the local Oracle Data Pump Export

3. Upload the Data Pump Export Files into the OCI Bucket

4. Import the Data

5. Verification

X. Troubleshooting

Logs for all steps are available in the installation sub folder. There you can find all excuted commands, detailed error messages.

My ToDo List for next MV2ADB Blog Post

  • Clarification of the license situation, if the export to the cloud has to be encrypted, Advanced Security Option is required, maybe a special license solution like compression for the OCI backup service is planned.
  • Execution of steps without a parameter file.
  • Transfer data without OCI CLI pre-installed.

Summary

The Oracle Cloud Infrastructure MV2ADB is a great tool to make data moves into the OCI Autonomous Database much easier. I like the concept, a small configuration file, passwords are all encrypted and the logs are very detailed. The advisor is helpful to identify conflict in advance.

#ilikeit

OCI Database Backup Service Configuration – Avoid 401 Unauthorized Error

While I a preparing new exercises for an Oracle Cloud Infrastructure training, I ran into an issue while configuring the Oracle Database Backup Service for the Object Storage. The OCI backup module installer returns an error 401.

My Environment

  • Oracle Linux 7 Virtual Box Machine
  • Oracle 19c RDBMS

Backup Service Module Installation Error

The installation was done according the documenation https://docs.oracle.com/en/cloud/paas/db-backup-cloud/csdbb/oracle-database-cloud-backup-module-oci.html

Error Message – java.io.IOException: testConnection: 401 Unauthorized

What I have verified:

  • Private key format and permissions
  • OCIDs
  • FingerPrint

But all of them were correct. There is no My Oracle Support note available about this error together with Oracle Database Backup Service. But after some more investigation, I found this note here: EBSCloudBackup.pl Failed When Performing Database Tier Upload Task (Doc ID 2588278.1) – bingo! This note described exactly my case with the cloud backup. The machine time is wrong!

My actual Machine Time and Date

The timezone CEST is correct. But wait, here in Kestenholz at the famous Jurasüdfuss / Switzerland, we have 14:38 local time. The virtual machine was 2 hours “in the future”. Let’s install the NTP service deamon.

NTP Installation and Configuration

Now the time is right:

OCI Backup Configuration – 2nd Try

Now the oci_installer.jar runs fine and the configuration will be created. Et voilà.

Lesson learned

Take care about time and date settings when you build virtual machines for testing purposes. And aways install a time service like NTP or chrony.