Migrate to the Oracle Database Cloud Service

On the 6th of October the Oracle Cloud Day 2015 takes place in The Netherlands. iAdvise is proud to be a bronze sponsor on what promises to be a day filled with interesting sessions.

One of the main topics will be the Oracle Database Cloud service. In this blog post, which was published in the OGh Visie earlier this year, you can read what the Oracle Database Cloud Service is, which configuration possibilities there are and what steps are needed to migrate.

Oracle Database Cloud Service

Suppose you want to start with the Oracle Database Cloud Service tomorrow, what options are there? What services are there, and what do they do? Below you will find the 3 services available. In the future, Managed Database as a Service will be added to these services.

Database Schema Service

Interesting to know is that, already since 2012, you can use the Oracle Cloud, namely through the Oracle Database Cloud Schema Service (ODCSS).  It was – and still is- possible to get a database schema in the Oracle Cloud, on an 11g database that is fully managed by Oracle. You can connect to this schema through: SQL Developer, RESTful Web Services, Oracle Java Cloud or
Oracle APEX.oracle_database_cloud_scheme_service

However, there are some limitations. You have no SQL*Net access, so you can only use SQL Developer (or APEX) to connect to your cloud database schema. You can do this through a so-called “Cloud Connection”, but need to know that you can only browse and load/unload data. So, not really convenient for development purposes. In addition, you cannot “connect” multiple schemas with each other, and packages such as: utl_smtp, utl_ftp and features as VPD (Virtual Private Database) are not available.

If you don’t mind these limitations, ODCSS is a very budget-friendly solution. Starting at $175 per month, you have an Oracle database in the cloud with 5GB storage available

Virtual image

Are you looking for a cloud environment where you can install and manage your databases yourself, then the virtual image option might be something for you. You get a dedicated VM on which you can install an 11g or 12c database, either manually or through the Database Configuration Assistant (DBCA). Unlike with the ODCSS, you have SQL*net access and full access to the VM.

You get the choice whether you want to pay per hour or per month. From $400/month or $0,672/hour you can get started with SE 1.

Database as a Service

If you choose the Database as a Service, you have the same possibilities as with the virtual image option, but in addition you have a number of nice tools at your disposal. So you can create a database instance in 4 easy steps thanks to Oracle’s automatic provisioning system. In addition, you have a number of cloud tools to maintain and monitor your database very easily.

You can start with the Database as a Service for a SE1 database from $600/month or $1,008/hour.

Setting Up the Oracle Cloud Database as a Service

Database instance

For the creation of an Oracle database you have a simple wizard. This initiates the automatic provisioning of your database.  The provisioning ensures that your database is installed with cloud tooling technology and it configures the backup facilities.


The 4 steps that you must follow are:

  1. Choose your service: Virtual image or Oracle Database Cloud Service
    How do you want to pay: hourly or monthly?
  2. Choose your database version: 11gR2 or 12c?
  3. Choose your edition: SE1, EE, EE High performance, EE Extreme performance
  4. Choose the name of your instance, your compute shape (number of CPUs) and connect an SSH key to access to your VM.  Set a number of database configurations: how much storage you need, SID, and – in the future also a possible – a fail over database. If you also choose for Backup and Recovery, you select the storage container here.
    Then simply confirm, and you’re done! Fifteen minutes later you have a fully functioning database instance in the Oracle Cloud and access to a dedicated VM.


Backup & Recovery

When you choose the Oracle Cloud Database as a Service, you also have the necessary cloud tooling technology to simply set up the desired backup options.

If you’re only interested in a local backup, then the block store only option will do. During the provisioning of the VM, some additional disk space will be configured for the backup, by default 1.7 times the required database data volume. Through a combination of the familiar Oracle RMAN and classic system management tools, nicely packaged in a command line API, not only your database but also important system files are added to the local backup.

If you want full protection for your VM, then your best option is to choose the block store and cloud storage option. This option presupposes that Oracle Cloud Storage as a Service is purchased and configured. With a few simple commands, you will then be able to restore your full VM instance, including system files and configured Oracle database, into a new VM.

Both systems follow a series of Oracle’s best-practice guidelines and can be expanded and adapted to suit your needs.

Do you want your on-premise Oracle database(s) or Oracle database(s) that were created in an Oracle Cloud Database – Virtual image instance, also to be backed up in the Oracle Cloud, then you can set this up via the Oracle Cloud Backup as a Service. This service only relates to the storage of Oracle database backups. Do you also want to back up other types of data in the Oracle Cloud – for example, important system files – then you can do the setup through the Oracle Cloud Storage as a Service. In that case you are responsible for setting up the necessary backup policy.

Access rules

Who has which access to the Oracle Cloud Database as a Service?

Each Compute Cloud Service VM, child to the Oracle Cloud Database as a Service, is shielded from the angry world through so-called access rules. These are firewall rules that check the access to the VM specific protocols, such as HTTP(S), SSH or SQL * Net access. In these rules you define what source groups of VMs (network groups) or lists of IP addresses on a specific protocol may connect within a certain target group of VM(s).

When creating an Oracle Cloud Database as a Service instance, by default, 7 Oracle Compute Cloud Service access rules are created. These access rules control access to SSH (port 22), Enterprise Manager Database Control (port 1158), Enterprise Manager Database Express 12c (port 5500), Database listener (port 1521), Glassfish Server admin console (port 4848), HTTP (port 80) and HTTPS (port 443). The last one is necessary for accessing the Oracle REST Data Services, Oracle APEX and Oracle Cloud on-instance database monitor.

Only the SSH access is standard enabled. The other access rules must be explicitly enabled after creation.


Migrate to the Oracle Cloud

Have you decided to use the Oracle Database Cloud Service? Nice, but now you probably want to know what steps are needed to get your current on-premise environment in the cloud. And that happens to be one of the strengths of the Oracle Cloud: because you have full access to your dedicated cloud VM, you can tackle the migration in different ways.

For the migration of OraEvents (an application we build for Oracle) we used the classical method: an Oracle Data Pump export (expdp) of the on-premise database and an import (impdp) into the cloud database. The steps we went through are:

  • Expdp of the database schema
  • Copy the expdp DATA_PUMP_DIR directory to the Oracle database
  • Preparing the database – create new tablespaces, user schemas and assign the necessary rights
  • Import the expdp into the new database schema
  • Export and import of APEX workspace and applications
  • Copy the APEX images in the default DocumentRoot of the Glassfish server running the ORDS
  • Ready for testing!


If you decide to migrate to the Oracle Cloud today, you have a range of options available to ensure that your cloud database is more than just a replacement for you on-premise database. The automatic provisioning, powerful cloud tooling and integrated systems offer a great extra value. Because migrating to the cloud is very similar to a classic migration, there are no major objections from a technical perspective. The Oracle Cloud is ready. Now, it’s up to us!

Migrate your MS Access data to an Oracle database using the ETL Tool Talend

APEX is promoted as the perfect replacement for MS Access applications. One thing you should consider though is how you migrate your data to the Oracle database. In APEX there is a handy tool called the Data Workshop that can be used for this. You first export your Excel files from the MS Access database, and then follow the data upload wizard to import the data into identical tables. Since you are not always working with a 1-1 relationship, you will most likely have to write some PL/SQL to get all the data in the right tables.


The downside is that you will need to repeat this process when you go into production. This is not a big problem if you only have one table to migrate. But if you have multiple tables and/ or your users also want new data during tests and trainings, you will spend a lot of time exporting and importing Excel files.

A recent APEX project for a client required a large data migration from MS Access Databases to the Oracle database. Because we would require fresh data on several points in the development process we decided to use the ETL Open Source Tool Talend. We got impressed of how intuitive the tool is, it only took a few days before we were familiar with the tool. Once you get the hang of it, you can write (or should I say draw) migrations of tables in no time. We needed to migrate from an MS Access database but the tool supports a wide range of databases and documents to import your data from. In total we migrated around 30-40 tables to our Oracle database.

Let’s have a closer look at one of our migration jobs.


At the left we see our MS Access database. Each tAccessInput component will get data from one table. After that we join the tables in our tMap_1 component. The reason we don’t just write our joins in one component, is because this way we can really see how many rows every table returns.

On the bottom we have some Oracle Database input connections. They will join the persons of our MS Access Database with the persons in our Oracle Database based on the National registration number. After that we write our data to our Oracle Database. You may notice that we have two lines going to Excel files. This is our error logging; we use this to log the rows that did not find a match. In our first Excel for example we write persons that did not find a match in our Oracle Database.

This is just one example, in total about 20 jobs were built. During the development we also had to deal with certain calculations or convert data. For most things there was a component ready to use and if there wasn’t you could always write a Java expression in the tMap items.

I hope I convinced you of the benefits of using Talend as a migration tool for APEX projects, because we will certainly use this tool again!

OOW 2010: Moving forms to ADF

When working with Oracle Forms these days and you’re not satisfied with the application anymore, there are some possibilities you can do:

  • upgrade
  • modernize
  • integrate
  • migrate

On our OOW session tomorrow(Oracle Forms in the Middle of Middleware, 1pm, Marriott Marquis Room: Salon 9), we will talk about the first three possibilities, upgrade, modernize and integrate.

But today I went to the session of Grant Ronald: Moving from Oracle Forms to Java and Oracle Application Development Framework
A session about migrating Oracle Forms to ADF.
The strategy of oracle is NOT desupporting Oracle Forms, on the contrary, they’re working on new features for 11g R2.

But when you consider migrating, do it for the right reasons.
Three kinds of reasons: the good, the bad and the ugly

Reasons to choose for migration can be

  • forms doesn’t meet the requirements anymore
  • there’s need for re-development
  • adopt leading edge, modern technologies

Reasons NOT to choose for migration:

  • there’s a heavy forms investment you don’t want to throw away
  • happy with data entry (and to my opinion forms is one of the best choices for data entry applications)

Wrong reasons:

  • forms will be desupported -> A clear answer of Grant Ronald: THIS IS NOT THE CASE!
  • upgrading your forms application will result in big problems
  • rewriting the application will save $$$

So migration is an option for your forms application, but Grant stated it several times in his session: DO IT FOR THE RIGHT REASON.

About migrating forms to ADF…
The technologies look similar…
Grant made a comparison between a dish washer and a washing machine.
Both have the same measurements, do similar things(wash something and dry it), etc.
But who puts his clothing in a dish washer?  Or cups and glasses in a washing machine?
So thechnologies look similar, but are different:

  • Java applet <> HTML/javascript
  • PL/SQL <> Java
  • Stateful <> stateless
  • No separation of UI and data elements <> seperate UI and data elements

Do not ignore those differences when looking at migration!

ADF is a framework and does a lot of things for you(like log on to the database, you don’t have to write the code) which is pretty nice.
But hey, Forms does also things for you, it’s also a framework.

You can build applications in ADF that look like forms application and have the same behaviour, but is that the reason to migrate, to work the same way?

When migrating there are some more challenges, eg reusability of table/views, procedures/functions, PLL, triggers.  What about forms built-in functions?

So, of course migration is an option for your Oracle Forms application, but ask yourself a question: Why migrate?
Take a look at all the options, before going to migrate.  It’s not an easy path to walk…

Check also the paper Grant wrote about migrating: Migrating Oracle Forms to Fusion: myth or magic bullet