Migrate an IBM Db2 Database to Oracle Cloud

Convert an IBM Db2 (LUW) database to Oracle Autonomous Data Warehouse in Oracle Cloud Infrastructure to take advantage of the expanded capabilities offered with Oracle PL/SQL and an autonomous database. An autonomous database scales elastically and delivers fast query performance without high-overhead database administration.

Architecture

In this architecture, data and metadata are migrated from an on-premises IBM Db2 Database deployment to an Oracle Autonomous Data Warehouse. You can use Oracle Cloud Infrastructure FastConnect or IPSec VPN for private connectivity between your on-premises data center and Oracle Cloud Infrastructure (OCI).

The following diagram illustrates this reference architecture.

Description of ibmdb-adb.png follows
Description of the illustration ibmdb-adb.png

ibmdb-adb-oracle.zip

The on-premises data center shown in this architecture has the following components:

  • Customer-premises equipment (CPE)

    CPE is the on-premises endpoint for the VPN Connect or Oracle Cloud Infrastructure FastConnect interconnection between the on-premises data center and the virtual cloud network (VCN) in Oracle Cloud Infrastructure.

  • IBM Db2 Database

    IBM Db2 Database (also known as Db2 for Linux, UNIX, and Windows, or Db2 LUW Database) Version 11.5.5 is a third-party RDBMS used to build large-scale data warehousing applications. a third-party RDBMS used to build large-scale data warehousing applications.

  • Oracle SQL Developer

    Oracle SQL Developer is a development environment that simplifies the development and management of Oracle Database. It offers a complete end-to-end development of your PL/SQL applications, a worksheet for running queries and scripts, a DBA console for managing the database, a reports interface, a complete data modeling solution, integrated Oracle REST Data Services, and a migration platform for moving your 3rd party databases to Oracle, such as IBM Db2 to Oracle.

    Oracle SQL Developer is certified to run on all supported Oracle Databases.

  • SQL Loader

    SQL*Loader loads data from external files into tables of an Oracle Database. SQL*Loader uses the field specifications in the control file to interpret the format of the datafile, parse the input data, and populate the bind arrays that correspond to a SQL INSERT statement using that data. The Oracle Database accepts the data and executes the INSERT statement to store the data in the database.

  • Export utility

    The Export program utility bulk copies data between an instance of IBM Db2 Database and a data file in a user-specified format. The export utility can be used to export data out of tables into data files.

The Oracle Cloud Infrastructure side of the architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Compartment

    Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.

  • Cloud Guard

    You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

  • Availability domain

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domain

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

    Every Compute instance is deployed in a VCN that can be segmented into subnets.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Bastion host or Bastion service

    This architecture uses a bastion host. However, you can use either a bastion host or Oracle Cloud Infrastructure Bastion service:

    • Bastion host

      The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

    • Bastion service

      Oracle Cloud Infrastructure Bastion provides restricted and time-limited secure access to resources that don't have public endpoints and that require strict resource access controls, such as bare metal and virtual machines, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Container Engine for Kubernetes (OKE), and any other resource that allows Secure Shell Protocol (SSH) access. With Oracle Cloud Infrastructure Bastion service, you can enable access to private hosts without deploying and maintaining a jump host. In addition, you gain improved security posture with identity-based permissions and a centralized, audited, and time-bound SSH session. Oracle Cloud Infrastructure Bastion removes the need for a public IP for bastion access, eliminating the hassle and potential attack surface when providing remote access.

  • Autonomous database

    Oracle Cloud Infrastructure autonomous databases are fully managed, preconfigured database environments that you can use for transaction processing and data warehousing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

  • Object storage

    Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

Recommendations

Use the following recommendations as a starting point to design an architecture to convert an IBM Db2 database to an Oracle Autonomous Data Warehouse. Your requirements might differ from the architecture described here.
  • Oracle Autonomous Data Warehouse

    Start with two OCPUs and one TB of storage, and enable autoscaling. This configuration ensures optimum price and performance.

  • Oracle Cloud Infrastructure File Storage

    Oracle Cloud Infrastructure File Storage service provides a durable, scalable, secure, enterprise-grade network file system. For a database size in tera bytes (TB), it's recommended to connect to a File Storage service file system on the source database server host as an NFS mount.

  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect Object Storage buckets that have visibility set to public.

    Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

  • Security Zones

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

Considerations

Consider the following points when deploying this reference architecture.

  • Scalability and Cost

    As long as autoscaling is enabled, you don't need to manage scaling manually for your autonomous data warehouse. Autoscaling also ensures optimum price and performance.

  • Availability

    Your autonomous database is backed up automatically, and the backups are retained for 60 days. You can also create manual backups to supplement the automatic backups. Manual backups are stored in a bucket that you create in Oracle Cloud Infrastructure Object Storage. You can restore and recover the database to any point-in-time during the retention period. When you initiate a point-in-time recovery, Oracle Autonomous Data Warehouse determines and uses the backup that enables faster recovery.

  • Access Control

    Define suitable policies in Oracle Cloud Infrastructure Identity and Access Management (IAM) to control who can access your resources in the cloud and the actions that they can perform.

Explore More

Learn more about migrating from IBM Db2 to an autonomous database in Oracle Cloud.

Review these additional resources: