Today, I'm pleased to have a guest blogger, Senior Principal Product Manager, Brian Spendolini. Brian's blog below is going to provide you with some technical best practices for migrating your Oracle Database to Oracle's Database Cloud Service.
When Oracle set out to create our PaaS cloud, more specifically the Database Cloud Service, a particular element was at the forefront. The software in the cloud had to be the same software that our customers are using on premises. There had to be no difference whatsoever. The same tools, skills and software you use to manage, monitor and tune your on-premises databases had to seamlessly and transparently move between platforms. A DBA should be able to monitor a cloud database just as they would with an on premises database with no exceptions. Oracle’s database cloud enables you to create an enterprise class, highly available database in less than an hour, and manage this database just as you would on premises.
With this same software in the cloud as on premises paradigm, Oracle’s Database cloud allows migration and data loading with the ease you are familiar with. To start, all Oracle Database Enterprise Cloud Service instances give you access to the operating system as well as SQL*Net access. This enables users and systems with the correct access to stage and load data into the database using multiple methods. SQL*Loader is the most basic, allowing data loading from a local file or via SQL*Net.
The original database export and import utility can be used today to move on-premises databases into the cloud
Superseding import/export in Oracle 10gR1 was data pump. Oracle Data Pump enables very high-speed movement of data and metadata from one database to another, much faster than the original import/export tools. As for data pump, features such as exporting and importing over a network and the ability to restart jobs help to make this a perfect fit for moving data to the Oracle Cloud. Other features such as the ability to estimate how much space an export job would consume without actually performing the export will help on cost estimates for purchasing cloud storage.
If the source database is an 8i or greater database, then transportable tablespaces give you a very fast method for moving your database to the cloud, all you need to do is move the metadata and the datafile. Also Starting with Oracle9i, the transported tablespaces are not required to be of the same block size as the destination database, helping with the migration process.
Another important aspect of transportable tablespaces is that you can migrate across OS platforms. To check on what platforms you can migrate to, in your database check the V$TRANSPORTABLE_PLATFORM table. The V$TRANSPORTABLE_PLATFORM view lets you see the platforms that are supported and to determine each platform's endian format. What is endianness? It’s the way computers store multibyte data-types. Think of it this way; If the platform is Big endian, it will store the number 2134 as 2134. On a little endian platform, it will store it as 4312. This is simplifying it a bit, but you can see the basic issue we have. If the source and cloud database endianness match, then you can move the tablespaces to the cloud platform with no conversion necessary. If the endianness does not match, then an additional step is required. You can perform this step on the source or cloud database to convert the tablespace being transported to the target endian format. Doc ID 371556.1 on support.oracle.com will guide you through this process. Also remember, when using transportable tablespaces, the source and the target databases must use compatible database character sets and source and the target databases must use compatible national character sets.
With the latest cloud release, we can now create databases from a customers’ on premises backup with a single click. The Oracle Database cloud now includes a feature to create or replace an existing database with a backup from our database backup service. Just tell the UI where the backup lives and the cloud takes care of the rest. The database will be created, then replaced with that backup from the cloud. This jumpstarts many use cases such as disaster recovery in the cloud using Data Guard as well as a test/development environment from a backup of production which is on premises.
The last method of migrating to the cloud we will discuss in this article is moving PDBs. With 12c, Oracle introduced the concept of a multitenant architecture allowing database to function as a multitenant container database (CDB). Within this CDB, we can have one, zero, or multiple pluggable databases (PDBs). The multitenant feature represents one of the biggest architectural changes in the Oracle Database. This grouping of multiple PDBs into a single CDB allows us to manage, patch, upgrade and backup all of our databases as a single unit allowing us to consolidate multiple databases into one.
So how does the Oracle Cloud utilize the multitenant feature? To start, built right into Oracle SQL Developer is the ability to move local PDBs straight into the Oracle Cloud. As long as that PDB is on the same instance as SQL Developer, we can unplug, copy and plug that PDB into a cloud 12c database with a single click of a button. This is a great way to move development and test instances into the cloud quickly and easily.
With Enterprise Manager 12cR5 and 13c, we can do even more with PDBs and the Oracle Cloud. Enterprise Manager (EM) has the facilities to remotely move any 12c PDB in your monitored fleet to the Oracle Cloud. Not only can we move these PDBs to the cloud, but we can also move from the cloud back to an on premises 12c database. Using the data masking and subsetting pack, EM will mask or scramble sensitive data as it is moved from an on premises PDB to the oracle cloud. Want an even quicker way to migrate PDBs? Use the PDB remote cloning feature to clone a PDB instantly over a database link.
Back to the original thought, seeing the software in the Oracle Database Cloud is the same as on premises, all the tools and features that existed in previous versions as well as current versions of the database will continue to work, no need to purchase anything extra or retrain on a cloud specific variant. And this this familiarity, we can leverage your existing skills and knowledge to make this migration to the Oracle Database Cloud even easier. For more information please take a look at the resources provided below.
Senior Principal Product Manager
Follow Us On Social Media: