Oracle Cloud

Get your Oracle 18c Instance in the Oracle Infrastructure Cloud OCI Classic

Do you want to work with Oracle 18c in the Oracle Cloud but the database version is not selectable in the webinterface? You can create an 18c instance in the command-line interface with the PaaS Service Manager (psm). The installation is very well described here, for example you need Python and OpenSSL. My personal installation of the psm executable runs in the Windows 10 integrated Ubuntu system.

Link to the PaaS Service Manager: https://docs.oracle.com/en/cloud/paas/java-cloud/pscli/abouit-paas-service-manager-command-line-interface.html

After the successful psm setup, you can create an DBaaS instance with this command

The file db18c-ee.json contains all the information you need to create an 18c instance. Here is my example – I have created a cloud storage container called dbcsbackup in advance because I want to use the OCI backup service.

Some minutes later you can login by terminal and user SQL*Plus. Oracle 18c: Here we are!

And in the OCI dashboard it looks fine too.

Addtional Info: If you want a Standard Edition, just replace the line “edition”: “SE”, happy 18c.

 

Oracle Cloud Infrastructure Storage Software Appliance – Installation and Configuration

The Oracle Cloud Infrastructure Storage Software Appliance – also known as Oracle Storage Cloud Software Appliance OSCSA – acts as a gateway between classic storage and the Oracle Cloud Infrastructure Object Storage Service. The appliance can be installed on an on-premises Linux system or in an Oracle Compute Cloud machine and runs in a Docker container. It offers a local cache where clients can place their files before the OSCSA moves them into the Storage Service. The communication between a client with a filesystem to the OSCSA works with NFSv4, from the OSCSA to the Object Storage Service, Oracle is using their REST interface. Traffic from the OSCSA to and from the Oracle cloud can be encrypted and compressed.

In this blog post first I will show you how you can install and configure the OSCSA in an on-premises environment. In a second step I configure an on-premises database server which uses the Object Storage Service as Oracle RMAN backup location.

Key Features

  • Compression and Exncryption
  • File Versioning
  • End-to-end Data Integrity with Checksum Verification
  • Support for Data Archival (Oracle Storage Archive Class)
  • Pin files to the appliance cache for faster access

Where to get the OSCSA and more Information

Requirements

  • Two dual-core CPUs (4-core CPUs recommended)
  • Minimum memory requirements (based on the maximum number of files that can be uploaded to the appliance filesystem):
    • 16 GB for filesystems up to 1 million files
    • 32 GB for filesystems up to 5 million files
    • 64 GB for filesystems up to 10 million file
  • Minimum disk size required to install Docker: 10 GB
  • Oracle Linux 7 with UEK Release 4 or later
  • Docker 1.12.6
  • NFS version 4.0

The installation and configuration of the required Oracle Linux components OL7 with UEK4, Docker and NFS is very well described in the “Using Oracle…” guide. Please take a look in the guide, it’s straight forward. The OSCSA installer does not start when the requirements are not fullfilled. 

My Test Environment

OSCSA breitenbach.martinberger.local Oracle Linux 7.4 100GB Storage
Database Server zuchwil.martinberger.local Oracle Linux 7.4 Oracle RDBMS 12.1.0.2
Traditional Cloud Account cloud.oracle.com Zone EM2 Oracle Cloud Infrastructure Object Storage Classic

Firewall

Port 32771 (Appliance Web Interface) ,  32772 (NFS) and 32773 (REST) have to be opened on the appliance machine. If you don’t want to use these port numbers, you can set them during the installation process. Execute as user root:

File Content

All installation steps are executed as OS user root. The Oracle Storage Cloud Software Appliance Software Release 16.3.1.3 is available on my local machine in folder /stage. The extracted OSCSA file contains a file called OSCSA_GATEWAY_README.txt where you can get more information about the installation and configuration possibilities like proxy etc.

Installation

The installation starts by executing oscsa-install.sh. I have added the parameter -a = advanced so I am able to set ports for NFS, Administrative Web Interface and REST. Oracle recommends for the cache storage a minimal size. I have ignored that for my test environment.

Appliance Start

Now the Oracle Storage Cloud Software Appliance can be started. A server reboot is not problem. The docker image will be started after server startup automatically.

 

Configure a OSCSA FileSystem in the Appliance Web Interface

In this step, the OSCSA will be connected to the Oracle Cloud. At the moment, no <OSCSA FileSystem name> is configured. An OSCSA  filesystem is like a namespace containing a set of data. Now we can log in into the Appliance Web Interface to create our first Object Storage filesystem. URL for the interface is https://<servername>:<port>. The port for the interface was set during the installation process.  

For the connection to the cloud, you need to know your Identity Domain, Username, Password and REST Storage Endpoint URL. The FileSystem name will be reused later for the NFS mount.

Create a FileSystem called OCIClassicStorage01

Enter Domain, Username, Password and REST Storage Endpoint URL. Below this screenshot you can see where you find the URL in your Traditional Cloud Account.

Here you can see the REST URL.

Click on Validate

If the account informations are verified, you are able to enable compression and encryption. I have enable encryption here. Click Save.

The OSCSA storage is now ready to synchronize with the cloud. Click Connect.

Now you can see the the connection between the Oracle Storage Cloud Software Appliance and the Oracle Cloud Infrastructure Object Storage Service is ready.

In the Traditonal Cloud Account in the Storage Classic dashboard is a new object storage filesystem available.

Connect the Database Server to the Oracle Storage Cloud Software Appliance

Let’s connect the database server to the OSCSA to store data in the Object Storage Service. First we check again on the OSCSA server if the service is running.

On the database server a new mountpoint will be created.

We mount the OSCSA with NFS v4 to the local server. This entry can be added later to autofs or whatever you use to automatically mount an NFS filesystem. Permission of the mountpoint is drwxrwxrwx – so everybody can write into it at the moment.

Check.

Execute an Oracle RMAN Backup to the Cloud

A new subdirectory on the NFS mountpoint will be created.

Start Oracle Recovery Manager RMAN database backup.

The backup files are created locally in the specified mountpoint directory.

At the moment where the backup sets are arrived on the mountpoint, the OSCSA begins to encrypt  (this was my selections during filesystem creation) and transfer them into the Oracle Cloud. This is visible in the Appliance Web Interface.

Now the files are uploaded into the Oracle Cloud. This can be verified in the Traditional Cloud Account in the specific filesystem. The files are encrypted and have file names like 10101-v1, 10103-v1 etc.

 

Anything else?

Sure, this was just a basic overview how to configure the on-premises Oracle Storage Cloud Software Appliance. There are many more features like retrieve data, cloud access via command line, preserve filesystem cache, create directory permissions, set user permissons, monitor the appliance, backup the appliance, encryption key handling, use the archive storage and so on which are worth to spend more time for investigation in the future.

Summary

The Oracle Storage Cloud Software Appliance is a nice piece of software which helps you to use the Oracle Cloud Infrastructure Object Storage Service. The appliance is easy to install and configure, local encryption is possible and the documentation is very good. Database Backups and Database Export a perfect candidates for this service. The price is hot, $0.0204 per GB for the first TB, and $0.0201 per GB for the next 49TB.

Thumbs up!

Oracle 12.2 – New Features I like – Part 1: Multitenant “Hot Clones”

I like the Oracle Multitenant architecture which was introduced in 12.1. But the concept to clone a source database to multiple copies in a small step had one big problem.  In Oracle 12.1, to clone a pluggable database the source database had to be in state read-only.

In 12.2 is it not longer necessary to set the source pluggable database in state read-only, the source database has not to be modified to create a clone. Oracle calls it in the documentation “Hot Clone”.

Link to the official Oracle documentation: https://docs.oracle.com/database/122/ADMIN/creating-and-removing-pdbs-with-sql-plus.htm#ADMIN13584

Here is a clone of the pluggable database PDB1 into PDB2 in the Oracle Database Cloud Service.

Verify existing Pluggable Databases and States – PDB1 is in state READ-WRITE

Verify if Oracle Managed Files are in use

Using Oracle Managed Files makes the file name convert much easier. You don’t have to care about files and directories. Like the feature says, Oracle is managing that for you.

Create TEMP directory

Is it a bug or is it a feature? The directory for the temporary datafile will not be created, we have to do it manually.

Error message when the directory is not created in advanced when a clone is started:

Clone PDB1 into PDB2

Attention: Databases in the Oracle Database Cloud Service are created “Secure by Default”, that means that Transparent Data Encryption (TDE) is enabled. This is why I need the KEYSTORE INDENTIFIED BY command in line 6.

Verify PDB2 state

The cloned PDB2 is in state MOUNTED after the clone procedure.

Open PDB2

Now the pluggable database PDB2 is ready to use, just open it. For more information how TDE works in a multitenant environment (export key etc.) take a look here: http://docs.oracle.com/database/122/ASOAG/using-transparent-data-encryption-with-other-oracle-features.htm#ASOAG10353