Gathering Important Application Information for Oracle Cloud Migration

Many organizations are looking into migrating their applications to Oracle cloud and with time their numbers are only going to be increased. There are many ways to migrate your application to Oracle cloud, but they all have one common important phase called application discovery. Application discovery is a process where you collect in-depth information about your source environment for a purpose of Cloud migration. There is a lot already published about public cloud migrations, but very little information is available about application discovery process. Cloud application discovery process is one of the most important initial phases for any cloud migration. This phase will not only help you see if your application is a good fit for public cloud, it will also help you reduce road blocks and technical issues during the actual migration. If you have a complete detailed discovery of your application before the migration, it will also help you plan migration project and reduce post migration issues. 

General Application Questions: –

Here are some sample questions that you can ask during your initial contact with application team.   

  1. What is the name & version of the application?
  2. Who are the IT owners of target application?
  3. What type of database and version used by this application?
  4. Who is the technical subject matter expert for this application?
  5. Is this a vendor or in-house build application?
  6. Does this application use or mange compliance data like PCI or HIPPA?
  7. Can you provide us any architectural documents for this application?
  8. Does this application have a DR or load balance solution built-in?
  9. Is there a middleware component to this application (WebLogic or WebSphere)?  
  10. Who are the business users and owner of this application?           

It’s important to provide background to the target audience like explaining reason for this contact. This initial contact can lead to very important feedback like “This application is already retired” or “This application can never move to cloud for ABC reasons”. Ideally, you will use collected information and architectural documents to get ready for the deep dive into the upcoming discovery steps.

Detail Application Questions: –

Here are examples of some details that you can gather for each section of your detail application discovery phase:

  • Application components:
    • Is there a middle component of application? If yes, detail.
    • Is there a DR for this application? If yes, detail.
    • Is there a Load balance component to this application?  If yes, detail.
  • Application dependency:
    • Is there a dependency with other applications? If yes, detail.
    • Is this an internal or customer facing application?  
    • Is this application part of group maintenance window? If yes, detail.
  • Networking Detail:
    • Is this application sensitive to network bandwidth? Large data transfer?
    • What are Firewall rules needed for this application?
    • Is there any large amount of data transfer happening to or from the application?
  • Database information:
    • What type of database/version is used by the application?
    • What is the size and growth rate of application database?
    • What is the RPO/RTO for the database?  
  • Application Support:
    • Is this a vendor application with support contract in-place? If yes, detail
    • Who is supporting this application? what are their names? 
    • Is this application certified to run from Oracle public cloud? 
  • Storage Detail:
    • How much total storage is used by target application?
    • What type of storage used by target application? NFS, Flash, SAN
    • Is IOP/s required by this application or database?
  • Hostname information:
    • How many hosts use this application and what are the details?
    • What are the OS types used by target application?
    • Can we upgrade or change underlying operating system if not available in Oracle Cloud?
  • Risks / Issues:
    • Is there a compliance requirement for this application?
    • Do you need to re-architect or make code changes for Cloud migration?
    • Is there a risk to migrate application from physical to virtual hosts?  

Hardware Profiling for Oracle Cloud Migration

Hardware & network profiling is another important phase of application discovery process regardless of end goal, which can be used for public cloud migration or data center migration. It includes capturing statistics about hardware usage like CPU utilization, memory usage, network bandwidth, data transfer and IOPS.  Capturing hardware statistics are important since it will be used for capacity planning and provisioning hardware resources to Oracle public cloud for target application. Any miscalculation on this part can lead to under provisioning of hardware resources in Oracle Public cloud which can cause the application to perform poorly after migration.


Oracle Enterprise Manager

Hardware statistics can be gathered using many methods depending on the operating systems and existing monitoring tools. Many organizations have already deployed robust monitoring and alerting tools like Oracle Enterprise Manager, OS watcher to monitor their systems. You should be able to gather most of the required information from existing reports and logs. Additionally, you can also install user define shell or Oracle PL/SQL scripts to gather rest of the information. One also should not ignore the importance of firewall, gathering network traffic and firewall information as they are crucial in developing a secured network in Oracle cloud environment.    

Application Profiling for Oracle Cloud Migration

Application profiling is an important phase for Oracle cloud migration , it’s design to gather in-depth information about the target application. Based on the information that is collected during the initial contacts, you can initiate application profiling phase. Information gathered during this phase can be used for migration planning and provisioning hardware resources for Oracle public cloud. This phase will also help you determine if all the application components are available in Oracle public cloud like load balancer, remote DR solution and storage replication. Depending on the application type, you might need to dig into the application code to see if that can be fork lifted to Oracle public cloud without making any changes, as sometimes application code contains hostnames and IP addresses. Similarly, understanding application logic and data set can be equality import for upcoming migration. If target application ingests or provides huge amount of data to other applications in the organization, this can present as a challenge for migration because of network bandwidth and transfer charges. Additionally, if this application contains PCI or HIPPA compliance related data, this will require more scrutiny and approvals from compliance department.

It’s also important to gather all test scripts for target application. Review test scripts to determine if they can be used during the migration for testing application performance and functionality. If test scripts are not available or are incomplete, this should be marked as a risk for migration to Oracle cloud. Finally, capture application performance statistics for all critical processes and queries so they can be used as baseline for upcoming migration.   

There are many profiling tools available in the market now a days but here is the list some Oracle profiling tools you can use for application and data profiling based on your needs. 

  1. Oracle SQL Developer
  2. Oracle Developer Studio
  3. The NetBeans Profiler 
  4. The HPROF Profiler
  5. The Optimizeit Profiler
  6. The Wily Introscope Profiler
  7. The JProbe Profiler
  8. Oracle SQL Profiler

Overview of Application Discovery process for Oracle Cloud migration

Many organizations are looking into migrating their applications to Oracle cloud and with time their numbers are only going to be increased. There are many ways to migrate your application to Oracle cloud, but they all have one common important phase called application discovery. Application discovery is a process where you collect in-depth information about your source environment for a purpose of Cloud migration. There is a lot already published about public cloud migrations but very little information is available about application discovery process. Cloud application discovery process is one of the most important initial phases for any cloud migration. This phase will not only help you see if your application is a good fit for public cloud, it will also help you reduce road blocks and technical issues during the actual migration. If you have a complete detailed discovery of your application before the migration, it will also help you plan migration project and reduce post migration issues.   

As mentioned earlier, application discovery process involves gathering detailed information about the target application. This may include conducting interviews with application users & developers, application & data profiling and hardware & network profiling. Application discovery process usually start with interviewing technical and business users to help them understand application functionality, logic and flow of the target application. You can also start application profiling while you are conducting interviews, this process will involve using many techniques and tools to gather application components, dependencies, security, data and compliance information about the target environment. Similarly, you will need to profile existing hardware and network to map out target environments to services and resources available in Oracle public cloud. It’s important to note that Oracle Public cloud is enterprise cloud offering many application components as a platform for services like Load Balancer, DBaaS, GoldenGate, Business intelligence etc. I will recommend that you analyze and compare all your application components to see if you can replace any of your application component with Oracle cloud service to decrease the cost and increase availability. 

It is also important to understand that there are few application discovery tools offered by cloud vendors which can facilitate application discovery process. But we found that those tools were not helpful in many situations since very few customers will let you connect to their production systems using those tools. Keeping that in mind, this article is mostly focused on manual process and steps to complete application discovery process while referencing many Oracle and third-party tools as needed. Additionally, application discovery process is almost the same for any public cloud migration, but this article will focus on Oracle public cloud.

Do you need detail application discovery for Oracle cloud migration?

Many of you must be wondering why we need a detailed discovery process for Oracle cloud migration. Why not just do a Proof of Concept (POC) for the target application to assess feasibility of Oracle cloud migration and iron out migration issues along the way. Based on my experience, POC for Oracle cloud migration will only work for one or two applications, this approach will not work if you are looking to migrate a group of applications. Additionally, POC will require more upfront cost and resources versus application discovery process. Finally, it will take longer to discover if target application is a good fit for Oracle public cloud through POC versus application discovery process.

I cannot overstate the importance of performing detail application discovery for Oracle cloud migration.  Application discovery is crucial to migrate all the applications, but level of detail can vary based on criticality of the application. There are many critical phases of Oracle cloud migration like provisioning, testing and migration, which will depend on detailed application discovery process. For example, you will not be able to provision Oracle cloud environment if you have not collected hardware and network information for the target application. Secondly, you will not able to identify any road blocks to the migration beforehand and that can lead to a waste of capital or even failed migration project.

Migrate Databases to Oracle Cloud using Data Pump

Migrating Oracle Databases to Cloud is not any different than migrating databases to any other Host. Oracle database cloud instance is like any other host running on your data center with few exceptions like they are elastic and scalable in nature. Still I thought it will be a good idea to write few blogs about different database migration methods and provide some clarity around this subject.

This blog will be focus on Oracle Data Pump utility. This method is useful when your data set is small (May be few GB) and there are no dependencies between schema’s.  I would say this method is good for schema level migrations and pretty much let you migrate any database version to latest oracle database version. Please follow below steps to migrate databases to Oracle cloud using Data Pump utility.

  1. Check data size and dependencies on source database using following query and make note of tablespace names and their sizes.
select substr(OWNER,1,10),substr(TABLESPACE_NAME,1,10) ,sum(bytes)/1024/1024/1000 "SIZE_IN_GB" from dba_segments where owner not in ('SYS','SYSTEM','APEX_04020','WMSYS','XDB','MDSYS','AUDSYS','DBSNMP','SCOTT') group by owner, TABLESPACE_NAME order by 3 desc,1;SQL>   2    3



SUBSTR(OWN SUBSTR(TAB SIZE_IN_GB

---------- ---------- ----------

SALES       USERS     .6370625
META7     USERS       .611875
APEX_04020 SYSAUX     .193875
ORDDATA    SYSAUX     .0160625
DVSYS       SYSAUX    .0044375
CTXSYS     SYSAUX     .0038125
GSMADMIN_I SYSAUX     .001375
OUTLN     SYSTEM      .0005625
ORDSYS    SYSAUX      .0004375
OJVMSYS    USERS      .000375
LBACSYS    SYSTEM     .0003125
  1. Export all the schema’s using oracle expdp utility. Please note that you also you need database directory , can use existing directory or create new one like i did. For this blog I will only be migrating one schema (Sales). It is best to use compress option, since you will uploading this dump file to Oracle Cloud.
CREATE OR REPLACE DIRECTORY migration AS '/oradata';
GRANT READ, WRITE ON DIRECTORY migration TO sales;

expdp sales/sales schemas=sales directory=migration dumpfile=sales.dmp logfile=sales_expdp.log compression=all
  1. Now on cloud, create target database and size it based on your requirement and make notes data file location using show parameter db_create_file_dest.
[oracle@META7DB META7DB]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvdb3             25G   14G   11G  58% /
tmpfs                 7.3G     0  7.3G   0% /dev/shm
/dev/xvdb1            477M  148M  300M  34% /boot
/dev/xvde1             59G   11G   46G  19% /u01
/dev/mapper/dataVolGroup-lvol0
25G  4.1G   20G  18% /u02
/dev/mapper/fraVolGroup-lvol0
6.8G  3.1G  3.4G  48% /u03
/dev/mapper/redoVolGroup-lvol0
26G  3.4G   21G  14% /u04

[oracle@META7DB META7DB]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Tue Feb 7 16:37:32 2017
Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c EE High Perf Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
and Real Application Testing options

SQL> show parameter db_create_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------

db_create_file_dest                  string      /u02/app/oracle/oradata
  1. Create required user, tablespaces and database directory  based on your requirement. Please note that if you are using container database, set you container before creating user or tablespace.
<ALTER SESSION SET CONTAINER = PDB1;>

create tablespace sales datafile size 1G;
create user sales identified by sales default tablespace sales temporary tablespace temp;
grant create session to sales;
ALTER USER sales QUOTA UNLIMITED ON sales;

CREATE OR REPLACE DIRECTORY migration AS '/u04/app/oracle/migration';
GRANT READ, WRITE ON DIRECTORY migration TO sales;
  1. Copy dump file to oracle clouds instance. This can be achieve many different ways, you can winscip or scp to copy export dump file to oracle cloud instance.
[oracle@oraclenode1 dmp]$ scp -i /backup/lunix_rsa_cloudkey  sales.dmp  oracle@129.144.9.60:/u04/app/oracle/migration
sales.dmp     100%  358MB   1.5MB/s   04:06
  1. Now run oracle import utility to load data into your Oracle Cloud Instance.
[oracle@testdb1 migration]$ impdp sales/sales@pdb1 directory=migration dumpfile=sales.dmp logfile=sales_expdp.log

Import: Release 12.1.0.2.0 - Production on Sat Feb 18 20:51:29 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c EE High Perf Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Master table "SALES"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
import done in AL32UTF8 character set and AL16UTF16 NCHAR character set
export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
WARNING: possible data loss in character set conversions
Starting "SALES"."SYS_IMPORT_FULL_01": sales/********@pdb1 directory=migration dumpfile=sales.dmp logfile=sales_expdp.log
Processing object type SCHEMA_EXPORT/USER
ORA-31684: Object type USER:"SALES" already exists
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "SALES"."UTILIZATION" 12.19 MB 7679886 rows
. . imported "SALES"."UTILIZATION_NOPART" 9.578 MB 6401656 rows
. . imported "SALES"."UTILIZATION_FACT_STAR" 3.925 MB 2559962 rows
. . imported "SALES"."DOBJECTS" 1.718 MB 124714 rows
. . imported "SALES"."DDBA_TAB_PRIVS" 519.8 KB 51649 rows
. . imported "SALES"."DINDEX" 286.1 KB 9560 rows
. . imported "SALES"."REV_MARGIN_F" 132.8 KB 3766 rows
. . imported "SALES"."CALENDER_DIM" 29.25 KB 731 rows
. . imported "SALES"."CALENDER_DIM_BK" 39.48 KB 1096 rows
. . imported "SALES"."CALENDER" 30.87 KB 731 rows
. . imported "SALES"."HW_SALE_F" 38.63 KB 890 rows
. . imported "SALES"."TIME_CALENDAR_DIM" 13.58 KB 365 rows
. . imported "SALES"."CLIENT_DIM" 5.062 KB 10 rows
. . imported "SALES"."CUSTOMER" 5.015 KB 2 rows
. . imported "SALES"."DUSERS" 7.640 KB 50 rows
. . imported "SALES"."EMPLOYEES" 6.421 KB 21 rows
. . imported "SALES"."ORACLE_USERS" 7.625 KB 50 rows
. . imported "SALES"."PRODUCT_DIM" 5.156 KB 6 rows
. . imported "SALES"."PROJECT_DIM" 5.242 KB 12 rows
. . imported "SALES"."REV_MAR_SUM_F" 5.390 KB 2 rows
. . imported "SALES"."SKILLS" 5.312 KB 20 rows
. . imported "SALES"."UTILIZATION_FACT" 5.609 KB 63 rows
. . imported "SALES"."ZIP_DESC" 4.796 KB 2 rows
. . imported "SALES"."SALES_FACT" 0 KB 0 rows
. . imported "SALES"."SKILLS_F" 0 KB 0 rows
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/BITMAP_INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/BITMAP_INDEX/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Job "SALES"."SYS_IMPORT_FULL_01" completed with  error(s) at Sat Feb 18 20:52:24 2017 elapsed 0 00:00:48

  1. Count all the database object and compile any invalid objects in your cloud database to complete your migration.
SQL> SELECT owner,
 object_type,
 object_name,
 status
FROM dba_objects
WHERE status = 'INVALID'
ORDER BY owner, object_type, object_name; 2 3 4 5 6 7

no rows selected