All data in the HRWEST schema is for east coast employees, and all data for the HRSOUTH schema is for the west coast employees.  The HRWEST schema is updated on the hrwestrh7 VM and the data is replicated using GoldenGate (one way) to hrsouthrh7.  Similarly, the data from the HRSOUTH schema is replicated (one way) to the hrwestrh7 VM.

In this first article, will cover the implementation of a GoldenGate hub in the environment described above.  In the second part, we will discuss how to enable the schemas for bi-directional replication.

Among the uses of a GoldenGate hub is the movement of Oracle data to Amazon Web Services (AWS).   There are several steps unique to that process that we are not covering here, but we will cover in a future post.

Step one is to install the Oracle client on the database hub server.  The name of that server in this environment is presplaycld.

The first step is to install the most recent Oracle client on the GoldenGate hub server, choosing the administrator installation. In a hub configuration, GoldenGate is installed only on the hub server, it is not installed on the database servers.  The Oracle client is installed on the hub server.  We will be using the thick client.

This blog forgoes covering the steps for the remainder of the client installation.  Select the defaults after choosing administrator.

Next, install the GoldenGate software.  Follow the instructions for the most recent version of GoldenGate, and install it in the directory listed below (for ease of installation and to follow along with this blog):

/u01/app/oracle/product/12.1.0/gghome

Also for ease of use, define the GoldenGate home directory as GGHOME in a Linux system variable at system start, or use an Oracle user login.  Put the line ‘export GGHOME=/u01/app/oracle/product/12.1.0/gghome_1’ in the .bash_profile to set it at user login, or in the file /etc/profile (to set system wide).

Next, put the client home directory in /etc/oratab:

client:/u01/app/oracle/product/12.1.0/client:N

Next, our tnsnames entries:

HRWESTDB =
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCP)(HOST = hrwestrh7)(PORT = 1521))
 (CONNECT_DATA =
 (SERVICE_NAME = WEST)
 )
 )

HRSOUTHDB =
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCP)(HOST = hrsouthrh7)(PORT = 1521))
 (CONNECT_DATA =
 (SERVICE_NAME = SOUTH)
 )
 )

The above entries go in this file on the hub server:

/u01/app/oracle/product/12.1.0/client/network/admin/tnsnames.ora

Define the TNS_ADMIN directory to point to the directory containing the tnsnames.ora file at either the system or the user login level as described above.

export TNS_ADMIN= /u01/app/oracle/product/12.1.0/client/network/admin

Now lets begin.

1) Set the environment.

. oraenv

ORACLE_SID= [oracle] client

The Oracle base remains unchanged at /u01/app/oracle

Note that setting the environment is required because GoldenGate needs various files binaries from the client installation in order to access remote Oracle databases.

2) Go the GoldenGate installation directory and start the set up process.

[oracle@presplaycld ]$ cd $GGHOME

[oracle@presplaycld gghome]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
 Version 12.3.0.1.0 OGGCORE_12.3.0.1.0_PLATFORMS_170721.0154_FBO
 Linux, x64, 64bit (optimized), Oracle 12c on Jul 21 2017 23:31:13
 Operating system character set identified as UTF-8.

Copyright (C) 1995, 2017, Oracle and/or its affiliates. All rights reserved.

GGSCI (presplaycld) > create subdirs

Creating subdirectories under current directory /u01/app/oracle/product/12.3/gghome

Parameter file                 /u01/app/oracle/product/12.3/gghome/dirprm: created.
 Report file                    /u01/app/oracle/product/12.3/gghome/dirrpt: created.
 Checkpoint file                /u01/app/oracle/product/12.3/gghome/dirchk: created.
 Process status files           /u01/app/oracle/product/12.3/gghome/dirpcs: created.
 SQL script files               /u01/app/oracle/product/12.3/gghome/dirsql: created.
 Database definitions files     /u01/app/oracle/product/12.3/gghome/dirdef: created.
 Extract data files             /u01/app/oracle/product/12.3/gghome/dirdat: created.
 Temporary files                /u01/app/oracle/product/12.3/gghome/dirtmp: created.
 Credential store files         /u01/app/oracle/product/12.3/gghome/dircrd: created.
 Masterkey wallet files         /u01/app/oracle/product/12.3/gghome/dirwlt: created.
 Dump files                     /u01/app/oracle/product/12.3/gghome/dirdmp: created.

GGSCI (presplaycld) > edit param mgr

PORT 7865

GGSCI (presplaycld) > start mgr
 Manager started.

Next, we set up the credentialstore.

GGSCI (presplaycld) > add credentialstore

Credential store created in /u01/app/oracle/product/12.3/gghome/dircrd/.

GGSCI (presplaycld) > alter credentialstore add user ggadmin@hrsouthdb password ggadmin alias ggadmine

Credential store in /u01/app/oracle/product/12.3/gghome/dircrd/ altered.

GSCI (presplaycld) > alter credentialstore add user ggadmin@hrsouthdb password ggadmin alias ggadminw

Credential store in /u01/app/oracle/product/12.3/gghome/dircrd/ altered.

3) Configure the databases for GoldenGate.

On each database do the following.

Create the ggadmin user, grant privileges, and configure the database as shown below (in SQLPLUS):

alter database add supplemental log data
 alter system set enable_goldengate_replication=true scope=both;
 create tablespace ggs_data datafile '/u01/app/oracle/oradata/ggdemo/ggs_data01.dbf'
 size 1024m autoextend on;
 create user ggadmin identified by ggadmin default tablespace ggs_data
 temporary tablespace temp;
 grant connect,resource,create session, alter session to
 ggadmin;
 grant select any dictionary, select any table,create table to
 ggadmin;
 grant alter any table to ggadmin;
 grant execute on utl_file to ggadmin;
 grant flashback any table to ggadmin;
 grant execute on dbms_flashback to ggadmin;
 @marker_setup.sql
 @ddl_setup.sql
 @role_setup.sql
 @ddl_enable.sql
 @sequence.sql
 EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(‘GGADMIN’);
 grant ggs_ggsuser_role to ggadmin;
 @ddl_enable
 shutdown immediate;
 startup mount;
 alter database archivelog;
 alter database flashback on;
 alter database open;
 alter database add supplemental log data;
 alter database force logging;
 grant EXECUTE on dbms_logmnr_d to GGADMIN;
 grant SELECT on sys.logmnr_buildlog to GGADMIN;
 GRANT EXECUTE ON UTL_FILE TO  GGADMIN;
 grant EXEMPT ACCESS POLICY to GGADMIN;

4) Go back to ggsci to set up the replication.

ggsci > dblogin useridalias ggadmine

ggsci as ggadmin@hrwestdb > add schematrandata hrwest ALLCOLS

ggsci as ggadmin@hrwestdb > add schematrandata hrsouth ALLCOLS

ggsci as ggadmin@hrwestdb > edit params extehre

extract extehre
 exttrail ./dirdat/ee
 tranlogoptions IntegratedParams (max_sga_size 256)
 discardfile ./dirrpt/silext01.dsc, append megabytes 50
 logallsupcols
 updaterecordformat compact
 reportcount every 2 hours, rate
 useridalias ggadmine
 tabe HRWEST.*;

ggsci as ggadmin@hrwestdb > register extract extehre database

2017-11-29 17:11:40  INFO    OGG-02003  Extract extehre successfully registered with database at SCN 1980353.<= Record this for future use.

GGSCI (presplaycld as ggadmin@hrwestdb) 8> add extract extehre, integrated tranlog, begin now
 EXTRACT (Integrated) added.

GGSCI (presplaycld as ggadmin@hrwestdb) 26> ADD EXTTRAIL ./dirdat/ee, EXTRACT extehre
 EXTTRAIL added.

GGSCI (presplaycld as ggadmin@hrwestdb) 27> start extract extehre

Sending START request to MANAGER ...
 EXTRACT extehre starting

At this point, the data from the HRWEST schema is being replicated from the HRWEST database, but is not as yet being applied to the HRSOUTH database.  The next step is to import the initial data into the HRSOUTH database.  We need to import all data prior to the start of replication.  Datapump is one method for building this initial load as described below:

1 – In the HRSOUTH database, create a database link that points to HRWEST.

SQL> Create database link hrwest connect to system identified by system using ‘hrwest’;

2 – Create a SQLPLUS directory for datapump to use.  In this case, I used HOMEDIR: SQL> Create directory homedir as ‘/home/oracle’;

3 – Use the datapump network link option to load the data:

impdp directory=homedir schemas=hrwest table_exists_action=replace network_link=hrwest flashback_scn=1980352 (one less than the SCN recorded from above)

4 – The data will be imported into the HRSOUTHDB.

Now we are ready to configure the replicat.  This applies the changes being captured using the extract.

Connect to the hrsouth database as ggadmin from ggsci:

ggsci> dblogin useridalias ggadminw

GGSCI (presplaycld as ggadmin@hrsouthdb) > add schematrandata hrwest ALLCOLS

GGSCI (presplaycld as ggadmin@hrsouthdb) > add schematrandata hrsouth ALLCOLS

GGSCI (presplaycld as ggadmin@hrsouthdb) > add replicat wesrepe integrated exttrail ./dirdat/ee  <= remember, this is the same as the exttrail declared for the extract.
 REPLICAT (Integrated) added.

edit params wesrepe

replicat wesrepe
 ASSUMETARGETDEFS
 DISCARDFILE ./dirrpt/weserep01.dsc
 DDL INCLUDE ALL
 USERIDALIAS ggadminw
 REPORTCOUNT EVERY 1 HOURS, RATE
 MAP HRWEST.*, TARGET HRWEST.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start replicat wesrepe

At this point, replication should be working from HRWESTDB to HRSOUTHDB.  Be sure to run updates in HRWESTDB to verify that everything is working correctly.

Now, follow the same process to replicate the HRSOUTH schema from HRSOUTHDB to HRWESTDB.

We are already connected to HRSOUTHDB, so we can define the extract here:

ggsci as ggadmin@hrwestdb > register extract extwhre database

2017-11-29 17:11:40  INFO    OGG-02003  Extract extwhrw successfully registered with database at SCN 1980353.<= Record this for future use.

GGSCI (presplaycld as ggadmin@hrsouthdb) > add extract extwhrw, integrated tranlog, begin now
 EXTRACT (Integrated) added.

GGSCI (presplaycld as ggadmin@hrsouthdb) > ADD EXTTRAIL ./dirdat/we, EXTRACT extwhrw
 EXTTRAIL added.

GGSCI (presplaycld as ggadmin@hrsouthdb) > edit params extwhrw

extract extwhrw
 exttrail ./dirdat/ww
 tranlogoptions IntegratedParams (max_sga_size 256)
 discardfile ./dirrpt/orcext01.dsc, append megabytes 50
 logallsupcols
 updaterecordformat compact
 reportcount every 2 hours, rate
 useridalias ggadmino
 table HRSOUTH.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start extract extwhrw

Now set up the replicat:

1. In the HRWEST database, create a database link that points to HRSOUTH.

SQL> Create database link HRSOUTH connect to system identified by system using ‘hrsouth’;

2. Create a SQLPLUS directory for datapump to use.  In this case, I used HOMEDIR: SQL> Create directory homedir as ‘/home/oracle’;
3. Use the datapump network link option to load the data:

impdp directory=homedir schemas=hrsouth table_exists_action=replace network_link=hrsouth flashback_scn=1980352 (one less than the SCN recorded from above)

4. The data will be imported into the HRWESTDB.

Now we are ready to configure the replicat:

GGSCI (presplaycld as ggadmin@hrwestdb) >dblogin useridalias ggadmine

GGSCI (presplaycld as ggadmin@hrwestdb) > add schematrandata hrsouth ALLCOLS

GGSCI (presplaycld as ggadmin@hrwestdb) > add replicat easrepw integrated exttrail ./dirdat/we  <= remember this is the same as the exttrail declared for the extract.
 REPLICAT (Integrated) added.

edit params easrepw

replicat easrepw
 ASSUMETARGETDEFS
 DISCARDFILE ./dirrpt/easrepw01.dsc
 DDL INCLUDE ALL
 USERIDALIAS ggadmine
 REPORTCOUNT EVERY 1 HOURS, RATE
 MAP HRSOUTH.*, TARGET HRSOUTH.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start replicat easrepw

At this point, we have replication running from HRSOUTHDB, schema HRSOUTH, to HRWESTDB. Schema HRWEST is replicating from HRWESTDB to HRSOUTHDB.  We are using a GoldenGate hub server, on a third system, to manage the replication process.

Please note that you will need to run updates in each schema in order to verify that everything is working properly.

In part two, we will make the necessary changes to allow for multi-master replication, in case we need to be able to run it in both databases.

Please note: this blog contains code examples provided for your reference. All sample code is provided for illustrative purposes only. Use of information appearing in this blog is solely at your own risk. Please read our full disclaimer for details.

Share with your network

Description:-

In this article let us configure Oracle 12cR1 One Node RAC. Below is the server details we are going to configure.

High Level Steps:-
1) Pre-requisites for RAC Installation
2) SSH Configuration and running runcluvfy
3) Grid Infrastructure Installation
4) Database Binaries Installation
5) One Node RAC Database Creation

Pre-requisites for RAC Installation:-

Below is the ip-details of the public, private, virtual and scan configuration.

$ cat /etc/hosts

127.0.0.1      localhost.localdomain       localhost

#Public IP
192.168.1.211  prodrac101.oracledbwr.com   prodrac101
192.168.1.212  prodrac102.oracledbwr.com   prodrac102

#Private IP
192.168.2.211  prodprv101.oracledbwr.com   prodprv101
192.168.2.212  prodprv102.oracledbwr.com   prodprv102

#Virtual IP
192.168.1.214  prodvip101.oracledbwr.com   prodvip101
192.168.1.215  prodvip102.oracledbwr.com   prodvip102

#Scan IP
192.168.1.218  prodscn101.oracledbwr.com  prodscn101
192.168.1.219  prodscn101.oracledbwr.com  prodscn101
192.168.1.220  prodscn101.oracledbwr.com  prodscn101

The pre-requisites steps involved in One Node RAC installation is similar to normal two node RAC installation. You can refer here for the OS configuration and pre-requisites need to be done for One Node RAC installation(Follow upto Step 79 for OS configuration and pre-requisites).

SSH Configuration and running runcluvfy:-

Login into NODE1/NODE2 as oracle:

$ cd <path-to-grid-software>/sshsetup
$ ./sshUserSetup.sh -user oracle -hosts "prodrac101 prodrac102" -noPromptPassphrase

Run the above command in both the servers of the cluster we are going to configure One Node RAC.

Once the ssh is configured successfully, execute the runcluvfy to check whether all the pre-requisite for RAC installation has been done perfectly.

$ cd <path-to-grid-software>/
$ ./runcluvfy.sh stage -pre crsinst -n prodrac101,prodrac102 -r 12cR1 -orainv oinstall -fixup -verbose

Please check here for the cluvfy output.

Grid Infrastructure Installation:-

When the cluvfy completed successfully, follow the below steps for the Oracle 12cR1 grid installation. Go to the unzipped directory of the grid software and start the grid installation by executing the runInstaller.

$ cd <path-to-grid-software>/
$ ./runInstaller

Oracle finished the job in just 4 hours, without taking down the applications the servers ran, by using Oracle’s own automation technology.

The technology involved is at the heart of Oracle Autonomous Linux, which the company announced at Oracle OpenWorld 2019 in San Francisco last month. Oracle has been using Autonomous Linux to run its own Generation 2 Cloud infrastructure, and now it is available at no cost to Oracle Cloud customers.

Besides the speed of patching, the other benefit is that it’s done automatically, without hands-on work by systems administrators, developers, or security operations staff, says Wim Coekaerts, senior vice president for operating systems and virtualization engineering at Oracle.

“Oracle Autonomous Linux lets us apply patches and do all the low-level mundane management for you on a running system,” he says. “We lock the machine for only a microsecond. You don’t see it, the application doesn’t see it, the end user doesn’t see it.”

The last things most CIOs, CTOs, chief information security officers, and even developers want to worry about are patching their server operating systems, whether they have a hundred servers or hundreds of thousands. That type of maintenance can slow down a business, especially if the maintenance requires shutting down the software running on that server.

A delay is doubly worrying when the reason for the patch is to handle a software or hardware vulnerability. In those instances, delays create an opportunity for malicious operators to strike. If an organization traditionally applies updates to its servers every three months, for example, and a zero-day vulnerability comes out just after that update, the company is vulnerable for months. When updates require a lengthy process, companies are reluctant to do it more frequently.

Not with Autonomous Linux, says Coekaerts, which can patch itself quickly after a vulnerability is found and the patch is applied by Oracle. “And the customer doesn’t even see the impact,” he says. Combined with Oracle Cloud Infrastructure’s other cost advantages, he expects customers to see a significant total cost of ownership savings compared to other Linux versions that run either on-premises or in the cloud.

Underneath the Autonomous Linux service is Oracle Linux, which remains binary compatible with Red Hat Enterprise Linux. Therefore, software that runs on RHEL will run on Oracle Autonomous Linux in Oracle Cloud Infrastructure without change.

How Autonomous Linux Works

What does Oracle Autonomous Linux tune, patch, and maintain? Everything from the Linux kernel to key user-space libraries, Coekaerts says.

For example, one valuable feature of the platform, he says, is a bit of fingerprint code that is designed to enable Oracle Linux to detect attempts to exploit patched vulnerabilities. Called Known Exploit Detection, this feature passes telemetry up to Oracle OS Management Services to describe the attempted attack, says Coekaerts: “We can send a notification to the customer saying, ‘Hey, somebody was trying to use this known exploit.’” Security administrators might want to know, after all, if a bad actor has gained access to a user account or is otherwise trying to launch an attack.

Oracle Autonomous Linux is included with Oracle Cloud Infrastructure compute services at no additional charge.

Coekaerts emphasized that Oracle Autonomous Linux is designed to deliver performance tuning, bug fixes, and vulnerability patching without rebooting or customer action. The autonomous process doesn’t automatically install major feature updates of Linux, such as those that might change its version number. That’s because such updates could potentially affect how applications run on the server, Coekaerts says, so customers can authorize Oracle to install those major updates after they’ve tested the update with their specific applications and system configurations. “Oracle Autonomous Linux is a stable operating system release, and we focus on keeping it that way,” says Coekaerts.

Ultimately, Oracle Autonomous Linux is for every CISO who wants to worry less about keeping their cloud operating systems safe, every CIO or CTO who wants to get out of the business of managing patches and performance tuning, and every developer who simply want to run, test, or deploy applications without having to administer Linux. “Oracle Autonomous Linux just keeps running, and you’re good to go,” Coekaerts says.

Per Technology Group analysis, a merger of Amazon and Oracle could unlock significant value. While the idea may sound very ambitious, in order to keep itself at the top of the cloud technology food-chain, Oracle may be the best acquisition Amazon could ever make. We detail why Amazon could acquire Oracle, and also estimate how much a potential deal could be worth in an interactive dashboard. Our estimate is based on Oracle’s standalone value as well as its value as a part of the combined entity with Amazon. You can modify any of the key drivers to visualize the impact of changes on the potential acquisition price.

Related: Is $20 Billion in Google Cloud Revenue Possible by 2020?

Why we think Amazon can acquire Oracle

Overview of the Two Companies:

• Amazon was possibly the first vendor to have created the public cloud ecosystem in mid-2000s, but Oracle has been in the database business for nearly 40 years.
• The idea of Amazon Web Services was to have infrastructure that could be rent out to customers who wanted lower bills for their storage and compute requirements. Per Technology Group estimates, AWS commands an enterprise value of $493 billion at an EV/EBITDA of 27x (2020 EBITDA of $18 billion).
• Oracle was late to the game with its first generation of cloud offerings failing and the company subsequently investing heavily in development to bring to market its Gen 2 cloud. Per Technology Group estimates, Oracle should have an enterprise value of $251 billion at an EV/EBITDA of 12.7x (2020 EBITDA of $20 billion).
• AWS’s approach was creating a product and then have users adopt it. Oracle has had that user base for a long time and was unable to service the need that AWS was able to cater to. The result was AWS today commands over 40% in the public cloud market with Oracle not even in the top 5, despite Oracle running nearly 50% of the world’s databases.

Rationale #1: Customers will get the security of Gen 2’s architecture and AWS’s customer service, leading to a differentiated product versus competition

• AWS’s early mover advantage may now be waning on account of competition in the market from Microsoft Azure (which has become the underlying fabric of Microsoft’s B2B and B2C offerings), Google Cloud (under its new chief) and IBM’s cloud offerings (post the Red Hat deal).
• Another factor weighing against the incumbent cloud leaders is the drying up of the low hanging workloads that could have been migrated to the cloud. The remaining workloads are mostly mission critical and have high security requirements.
• Another factor that goes against AWS in this contest are the list of data breaches that have occurred at AWS customers such as Capital One, Malido Air etc. During Oracle’s annual analyst meet, Larry Ellison was vocal about how Gen 2’s architecture could have avoided such breaches.

Rationale #2: AWS is yet to create a credible database alternative to Oracle. Bringing Oracle’s database on AWS could make the combination the de facto choice for start-ups and enterprises alike

• Oracle has been trying to move its databases to the Oracle cloud, the company’s software growth has not been able to offset declines in its other businesses.
• On the other hand, AWS has had a preferred partnership with VMware to bring AWS to on-premise systems (where Oracle and Microsoft have a leadership position).
• Considering that Oracle wants customers to move to a cloud and AWS wants on-premise customers to expand into, we think Oracle and AWS represent a good complementary pair.

Based on our revenue and EBITDA forecasts for Amazon and Oracle, and our estimates for potential gains as a combined entity, we believe that there Amazon can profitably acquire Oracle for a figure that is at a substantial premium to its current market cap.

What are the risks and hurdles to a potential combination?

A merger between the two tech giants comes with its own set of risks and hurdles though, including:

1. History of rivalry:

• AWS’s Andy Jassy and Oracle’s Larry Ellison have been embroiled in a war of words about each other’s products and operational strategies for years.
• However, during Oracle’s 2019 analyst day event Ellison appeared to be more respectful of AWS

2. Technology stack combination considerations:

• Oracle’s Gen 2 cloud separates the client and cloud control computers, while AWS runs a huge distributed system.
• The cost of integrating the two system and applying Oracle’s autonomous database capabilities to AWS’s offerings could pose a technology challenge due to the size of the combined customer base and their diverse requirements.

3. Anti-competitive concerns:

• With a share of well over 40% in the public cloud market and over 50% in the database market, the combined entity is likely to attract a lot of regulatory scrutiny in terms of how it will affect competition.

4. The sheer size of the deal:

• We value Amazon’s AWS division at $493 billion and Oracle at $250 billion.
• At an estimated valuation of just under $1.1 trillion, Amazon is the larger company by a substantial margin
• Keeping Amazon’s growing presence in several nascent industries, a merger will essentially bring Oracle under AWS’s fold.
• Amazon will have to cough up a significant premium to Oracle’s current market value in order to finalize a deal.

Oracle GoldenGate Foundation Suite is a set of advanced management tools for managing GoldenGate life-cycle in the enterprise. Oracle GoldenGate’s premium management tools include GoldenGate Studio, GoldenGate Management Pack and GoldenGate Veridata. It helps in life-cycle management areas such as design, development, deployment, testing, monitoring, administration and governance across various teams.

What’s New in Oracle GoldenGate Veridata 12.2.1.4.0?

• Generate Repair SQL file for Oracle database
• Repository Purge data
• DBCS, ADW, ATP Cloud services certified for comparison end-points
• Oracle on-premises database 19.3 certified for comparison end-points, and repository
• SQL Server 2014, 2016, 2017 certified for repository

What’s New in Oracle GoldenGate Studio 12.2.1.4.0?

• View and edit the big data property files
• Provide access to view the parameter, report and error log files
• Reverse engineering supports the SQLEXEC parameter
• Parameter, report files path can be set through property inspector
• Certification of GoldenGate 19.1 Classic
• Oracle DBCS 18.3, on-premises database 12.2.0.1, 18, 19.1 certified as a source, target, and RCU.

More Information on Oracle GoldenGate Veridata & Studio 12.2.1.4.0

• Download Oracle GoldenGate Veridata, Studio 12.2.1.4.0 from OSDC or  OTN
• Documentation for  Oracle GoldenGate Veridata 12.2.1.4.0
• Documentation for  Oracle GoldenGate Studio 12.2.1.4.0
• Certification Matrix for Oracle GoldenGate Veridata, Studio 12.2.1.4.0
• Installing and Configuring Oracle GoldenGate Veridata 12.2.1.4.0
• Using the Oracle GoldenGate Veridata Command-line Utilities
• Connecting Oracle GoldenGate Veridata to Autonomous Database
• Oracle Data Integration Blog

You may have realized that there are a few techniques missing describing how to do a Database Migration from non-CDB to PDB – Migration with Data Pump is one of them. I will explain the most simple approach of going to Single- or Multitenant. It isn’t the coolest – and it isn’t very fast as soon as your database has a significant size. But it is not complex. And it allows you to move even from very old versions directly into an Oracle 19c PDB – regardless of patch levels or source and destination platform.

High Level Overview

Database Migration from non-CDB to PDB – Migration with Data Pump

Well, I think I don’t need to explain Oracle Data Pump to anybody. At the end of this blog post you will find a long list of links pointing to the documentation and various workarounds. The big advantages of using Data Pump to migrate from a non-CDB into a PDB are:

• Works with every version since Oracle 10.1.0.2
• Works regardless of patch level
• Does not require any upgrade
• Works across all platforms
• Works regardless of encryption
• Allows multiple transformations

But the disadvantages of Data Pump are obvious as well as the duration depends mostly on:

• Amount of data
• Complexity of meta information
• Special data types such as LONG and LOB

I’d call Data Pump the most flexible approach but of course potentially also the slowest of all options.

Process Overview

Using Data Pump either allows you to export into a dump file, and import from this dump file afterwards.

Or you setup a database link from destination to source, and run the import from the destination of the database link using the NETWORK_LINK parameter.

The advantage of using a database link is not-writing a dump file which does not need to be copied over. But not all actions can run in parallel. Plus, not every data type is supported (LONG for instance until 12.2). And your limiting factor is always the source side as Data Pump implicitly calls expdp on the source side. To my experience this can be faster but especially when you work on the same storage or SAN, and you don’t have to move the dump file around, the first approach often works better.

Some Best Practices

There are some recommendations for both approaches:

• Always use a par file
• For a consistent export, use either FLASHBACK_TIME=SYSTIMESTAMP or CONSISTENT=Y (since 11.2)
• Always EXCLUDE=STATISTICS – regather stats in destination is faster, or transport with a STATS table from DBMS_STATS
• Set METRICS=Y and since 12.1, LOGTIME=ALL
• Use PARALLEL=<2x number of cpu cores>
  • Since Oracle 12.2, meta data gets exported in parallel – but not with NETWORK_LINK
• Preallocate STREAMS_POOL_SIZE=128M (or in the range of 64M-256M)
• BasicFile LOB (old 8i LOBs) are always slow
  • Use LOB_STORAGE=SECUREFILE to convert to SecureFile LOBs as part of the migration

Fallback

When you used Data Pump as a migration approach to move from non-CDB to PDB, then I don’t expect you to force a fast fallback scenario in case of failure. The important task is to use the VERSION parameter correctly when you export from the destination PDB. You need to set it to the source’s release in order to export in the format and with the contents, the (old) source will understand when you reimport. Make sure, there’s an empty database waiting in case fallback is important. And don’t cleanup your old source home too early.

Be aware of one major pitfall: The time zone version. As typically your source database has a lower time zone version than the destination, you can migrate “forward” (same or higher version) but not “backwards” (lower version). Hence, in case of fallback you most likely need to apply a DST Time Zone patch to the older home in order to allow Data Pump to import. And make sure you follow the supported configurations setup from MOS Note:553337.1 carefully.

Unfortunately, the fallback strategy over a NETWORK_LINK does not work. Even though the below scenario looks promising, you’ll receive an error when you call imdp from the lower version over the DB Link. I’d assume that the VERSION parameter does not get propagated in a way to convince the expdp side to export in 11.2.0.4 format.

This will be the error you’ll receive:

$ impdp system/oracle@ftex network_link=sourcedb version=11.2.0.4 tables=tab1 metrics=y exclude=statistics directory=mydir logfile=pdb2.log

Import: Release 11.2.0.4.0 - Production on Wed Aug 14 20:27:52 2019

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

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39001: invalid argument value
ORA-39169: Local version of 11.2.0.4.0 cannot work with remote version of 19.0.0.0.0.

“For the past 10 years, Exadata has been running the most critical workloads for thousands of customers around the world. Exadata now powers Oracle Autonomous Database and Oracle Cloud Applications,” said Juan Loaiza, executive vice president, Mission-Critical Database Technologies, Oracle. “Today, we are improving the performance and capacity of the platform, and adding a broad range of capabilities based on artificial intelligence and machine learning to further increase Exadata’s advantages.”

With Exadata X8, Oracle introduces unique machine-learning capabilities, including Automatic Indexing, which continuously learns and tunes the database as usage patterns change. Based on technology from Oracle Autonomous Database, the entire process is automatic and improves database performance while eliminating manual tuning. Exadata X8 also includes new automated performance monitoring, which combines artificial intelligence, years of real-world performance triaging experience, and best practices to automatically detect performance issues and determine the root cause without human intervention.

“Across the entire IT infrastructure landscape, when you look at the last 10 years, Oracle Exadata stands out as a key means for Oracle Database users to make the leap from on-premises data centers to the public cloud,” said Carl Olofson, Research Vice President, Data Management Software, IDC. “As the foundation for Oracle Autonomous Database, the new Exadata X8 brings a high degree of machine learning to both cloud and on-premises Oracle Database deployments while requiring minimal user effort to set up. Oracle Exadata and Oracle Recovery Appliance are helping enterprises lower costs, simplify operations, increase security and boost performance for their Oracle Database environments.”

Exadata X8 Platform Innovations and Improved Cost Effectiveness

Exadata X8 state-of-the-art hardware enhancements include the latest Intel Xeon processors and PCIe NVME flash technology to drive performance improvements—a 60 percent increase in I/O throughput for all-Flash storage and a 25 percent increase in IOPS per storage server compared to Exadata X7. Each Exadata X8 storage server now features 60 percent more cores to offload Oracle Database processing and 40 percent higher capacity disk drives to support massive data growth and database consolidation strategies.  These improvements come with no price increase, further improving the cost effectiveness of the Exadata platform.

Additionally, a new, much lower cost extended storage server is available for storing infrequently accessed, older, or regulatory data. At Hadoop/object storage prices, all customer data now receives the benefits of the Exadata scale-out architecture and Oracle Database storage, including application transparency, consistency of operational models, hybrid columnar compression (HCC) and the same security model with encryption across all tiers.

Exadata: 10^th Anniversary

Exadata X8 represents more than 10 years of continuous innovations and deep engineering, and today runs many of the world’s mission-critical applications, including four out of five of the biggest banks, telecoms, and retailers. Seventy seven percent of the Fortune Global 100 run Exadata. Exadata is the foundation for Oracle Autonomous Database, which uses machine learning to provide a self-driving, self-securing, and self-repairing database service that delivers a much more reliable and secure system that makes organizations and developers more productive.

Oracle provides choice and deployment flexibility, enabling customers to use Exadata anywhere—in Oracle Cloud, as the core of Oracle’s unique Exadata Cloud at Customer service, and on-premises.

Oracle Zero Data Loss Recovery Appliance X8

Oracle today also announced the availability of the Oracle Zero Data Loss Recovery Appliance X8, which provides up to 10X faster data recovery of Oracle Database than conventional data deduplication appliances while uniquely providing sub-second recoverability of all transactions. The Oracle Recovery Appliance X8 now features 30 percent larger capacity—nearly a petabyte in a single rack—for the same price.