On Oracle Database, Multitenant feature will be turning 9 in July, but it’s not yet widely deployed as most of the databases are still running on non-CDB architecture. With 19c, Multitenant is now mature and free if you stick to a maximum of 3 PDBs per CDB. If the benefits of Multitenant are not obvious at first glance, it’s a game changer when it comes to future migrations.

Migration without Multitenant

It’s been decades that migration is done by mostly choosing between these 2 methods:

• in-place upgrade of the database files by connecting them to a new DB home and running the catalog upgrade
• export data from source DB to a dumpfile and import this dumpfile into a newly created database already running the target version

The first option is fast, as soon as you stay on the same server, but after years using this method you still keep the old database structure with its legacy configurations, which is not so good. I remember, several years ago, working on an Exadata and not being able to use modern features because database files came from an old 8i or 9i.

The second migration option is the most popular and pretty clean, but rather slow because it’s based on DDL and DML statements. And you first need to identify schemas and dependencies you’d like to migrate. It’s easier to do a full export/import operation, but it generates a lot of errors you must analyze and solve. It’s because dictionary metadata and objects metadata are mixed, and importing dictionary metadata in a new database is not possible as dictionary already exists. But DBAs get used to this.

A third option is a combination of both: exporting objects metadata only and copying selected datafiles to the new database. It’s called Transportable Tablespaces, but it also needs schemas and dependencies analysis, and it only works if every segment resides in its expected tablespace.

Purpose of a container in Multitenant

A container database (CDB) will not be as important as a non-container database (non-CDB). It’s important as long as pluggable databases (PDBs) are running inside. But as your PDBs are easily movable, at some point you will move them. And the old container becomes useless. One of the reasons of moving these PDBs is migrating them to a newer version.

This is why your container shouldn’t have a name related to the applications it runs. The PDB has its own name, and the associated service will follow the PDB when you move it to another container.

Imagine you are preparing the 23c migration of the 3 PDBs in your 19c container C1917TST. You will create a new C2301TST container, with the same settings as C1917TST, move the PDB to this new container, and your migration is done. You can then delete the old container. Let’s test this.

Testing a migration from 19c to 21c

The 23c is the next long term release, but it’s not yet available. So the tests will be done with the current innovation release: 21c.

Migrating a PDB to a newer version could be limited to unplugging the database and plugging it into a new container. In this example, source CDB is 19c, and target will be 21c.

I’m pretty sure it will work fine, but as I’m using multitenant, I can duplicate my PDB and I will safely migrate the copy instead. If something goes wrong, I still have my original PDB with its original name in the source CDB.

. oraenv <<< CDB19C1
sqlplus / as sysdba
create pluggable database JRQDUP from JRQO4D;
alter pluggable database JRQDUP open;
...
alter pluggable database JRQDUP save state;
alter pluggable database JRQDUP close immediate;

Now let’s unplug this PDB and remove it from the source CDB:

alter pluggable database JRQDUP unplug into '/home/oracle/jrqdup.xml';
drop pluggable database JRQDUP keep datafiles;
exit

Let’s plug it into the new container. The MOVE option is used to move the datafiles to the correct subfolder:

. oraenv <<< CDB21C4
create pluggable database JRQDUP using '/home/oracle/jrqdup.xml' MOVE;
alter pluggable database JRQDUP open;
...

Opening this PDB is not immediate, let’s have a look at what’s happening in another sqlplus session:

show pdbs
    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 JRQDUP			  MIGRATE    YES

PDB is first opened in restricted mode to do the upgrade of the metadata.

Once finished, my PDB is automatically opened in normal mode:

show pdbs
    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 JRQDUP			  READ WRITE NO

And that’s it. Upgrade of the PDB is automatic when opening the database.

Next step would be stopping and dropping the source PDB and renaming the new one if you want to keep its original name.

Conclusion

With Multitenant, it’s very easy to migrate to a newer version. Just unplug the PDB you want to migrate from the old container and plug it into the new one, and Oracle will do the migration job.

L’article Migration with Multitenant: how easy it is! est apparu en premier sur dbi Blog.

Oracle 12.2 is released and we will have to upgrade. And in this blog we are going to talk about upgrading to oracle 12.2 using the dbupgrade utility.

Of course the dbua tool is still available and can be also used.

Oracle Database 12.1 introduced the Parallel Upgrade Utility, catctl.pl. This utility reduces the total amount of time it takes to perform an upgrade by loading the database dictionary in parallel, and by using multiple SQL processes to upgrade the database.

In Oracle 12.1 catcpl.pl had to be run using perl like
$ORACLE_HOME/perl/bin/perl catctl.pl -n 8 -l /home/oracle catupgrd.log
Starting with Oracle 12.2, we can use dbupgrade utility which starts up catctl.pl instead to run it from perl.

In this article we will describe the steps for upgrade using dbupgrade.

The first step is to run the preupgrade information tool preupgrade.jar tool which replaced the preupgrd.sql and utluppkg.sql scripts. This tool can be run from operating system command line. Remember that in 12.1, the Pre-Upgrade Information Tool was run within SQL*Plus as a SQL file.

Following environment variables must be set. Indeed ORACLE_HOME must point to the earlier release.

[oracle@serveroracle ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1
[oracle@serveroracle ~]$ export ORACLE_BASE=/u01/app/oracle
[oracle@serveroracle ~]$ export ORACLE_SID=ORCL
[oracle@serveroracle ~]$ export PATH=.:$ORACLE_HOME/bin:$PATH

The preupgrade.jar file is located to the oracle 12.2 $ORACLE_HOME/rdbms/admin. We can execute it using the TERMINAL or FILE options. The TERMINAL option will send output in the terminal and with FILE we will have the output in a file.

oracle@serveroracle:~[ORCL] $ORACLE_HOME/jdk/bin/java -jar /u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/preupgrade.jar TERMINAL TEXT
Report generated by Oracle Database Pre-Upgrade Information Tool Version
12.2.0.1.0
Upgrade-To version: 12.2.0.1.0
=======================================
Status of the database prior to upgrade
=======================================
Database Name: ORCL
Container Name: ORCL
Container ID: 0
Version: 12.1.0.2.0
Compatible: 12.1.0.2.0
Blocksize: 8192
Platform: Linux x86 64-bit
Timezone File: 18
Database log mode: ARCHIVELOG
Readonly: FALSE
Edition: EE
...
...
...
Preupgrade generated files:
/u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql
/u01/app/oracle/cfgtoollogs/ORCL/preupgrade/postupgrade_fixups.sql
oracle@serveroracle:~[ORCL]

As specified if we want the output in a file, we can use the option FILE instead of TERMINAL. The output directory is $ORACLE_BASE/cfgtoollogs/$ORACLE_SID

[oracle@serveroracle ~]$ $ORACLE_HOME/jdk/bin/java -jar /u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/preupgrade.jar FILE TEXT
Preupgrade generated files:
/u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade.log
/u01/app/oracle/cfgtoollogs/ORCL/preupgrade/preupgrade_fixups.sql
/u01/app/oracle/cfgtoollogs/ORCL/preupgrade/postupgrade_fixups.sql
[oracle@serveroracle ~]$

Once the execution done, the tool will identify possible issues during the upgrade and will also generate 2 scripts
 preupgrade_fixups.sql: fixes issues that an automated script can fix safely. This script must be run before the upgrade
 postupgrade_fixups.sql: fixes the upgrade issues that can be automatically fixed after the upgrade.
For all other issues we have to manually fix them.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> @preupgrade_fixups.sql

Once done we are ready to run the dbupgrade utility.

Prepare the environment

oracle@serveroracle:/home/oracle/ [rdbm12201] which dbupgrade
/u01/app/oracle/product/12.2.0.1/dbhome_1/bin/dbupgrade
oracle@serveroracle:/home/oracle/ [rdbm12201] echo $ORACLE_HOME
/u01/app/oracle/product/12.2.0.1/dbhome_1
oracle@serveroracle:/home/oracle/ [rdbm12201] export ORACLE_SID=ORCL

Copy the parameter file to the oracle 12.2 ORACLE_HOME/dbs

oracle@serveroracle:/home/oracle/ [ORCL] cp /u01/app/oracle/product/12.1.0/dbhome_1/dbs/spfileORCL.ora /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/
oracle@serveroracle:/home/oracle/ [ORCL]

Start the database in the new environment in an upgrade mode

oracle@serveroracle:/home/oracle/ [ORCL] which sqlplus
/u01/app/oracle/product/12.2.0.1/dbhome_1/bin/sqlplus
oracle@serveroracle:/home/oracle/ [ORCL] sqlplus
SQL*Plus: Release 12.2.0.1.0 Production on Thu May 4 16:24:22 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup upgrade
ORACLE instance started.
Total System Global Area 394264576 bytes
Fixed Size 8621136 bytes
Variable Size 293602224 bytes
Database Buffers 83886080 bytes
Redo Buffers 8155136 bytes
Database mounted.
Database opened.
SQL>

And then run the dbupgrade utility

oracle@serveroracle:/home/oracle/upgrade/ [ORCL] dbupgrade -n 2 -l /home/oracle/upgrade
Argument list for [/u01/app/oracle/product/12.2.0.1/dbhome_1/rdbms/admin/catctl.pl]
Run in c = 0
Do not run in C = 0
Input Directory d = 0
Echo OFF e = 1
Simulate E = 0
Forced cleanup F = 0
Log Id i = 0
Child Process I = 0
Log Dir l = /home/oracle/upgrade
Priority List Name L = 0
Upgrade Mode active M = 0
SQL Process Count n = 2
SQL PDB Process Count N = 0
Open Mode Normal o = 0
Start Phase p = 0
End Phase P = 0
Reverse Order r = 0
AutoUpgrade Resume R = 0
Script s = 0
Serial Run S = 0
RO User Tablespaces T = 0
Display Phases y = 0
Debug catcon.pm z = 0
Debug catctl.pl Z = 0
catctl.pl VERSION: [12.2.0.1.0]
STATUS: [production]
BUILD: [RDBMS_12.2.0.1.0_LINUX.X64_170125]
...
...
...
LOG FILES: (/home/oracle/upgrade/catupgrd*.log)
Upgrade Summary Report Located in:
/home/oracle/upgrade/upg_summary.log
Grand Total Upgrade Time: [0d:1h:38m:21s]
oracle@serveroracle:/home/oracle/upgrade/ [ORCL]

Once the upgraded finished without errors, we can run the postupgrade_fixups.sql.

SQL*Plus: Release 12.2.0.1.0 Production on Thu May 4 23:17:10 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> @postupgrade_fixups.sql


Hope that this article will help

L’article Upgrade to Oracle 12.2 with dbupgrade utility est apparu en premier sur dbi Blog.

Analysis

I began checking why the diagnostic directory was growing so fast. And I found out that all 11g databases – the new one and all the other ones – reported the message below each second in the database alert.log file.

WARNING: Oracle executable binary mismatch detected.
Binary of new process does not match binary which started instance
issue alter system set "_disable_image_check" = true to disable these messages

This problem occured because during the database upgrade procedure, DBUA recompiles the Oracle binary executable. Thus all databases using this Oracle executable file send WARNINGS that the executable was recompiled.

oracle@chbsslcmdbdb1:~/app/oracle/product/11.2.0.2/bin/ [DBACT411] ls -lrt
 ....
 -rwxr-xr-x 1 oracle dba      3771 Oct 28  2010 emagentdeploy.pl
 -rwxr-xr-x 1 oracle dba      6299 Oct 28  2010 dbca
 -rwxr-xr-x 1 oracle dba      3552 Oct 28  2010 db2gc
 -rwsr-s--x 1 oracle dba 228886356 Jun  9 09:59 oracle

How to fix this problem

A restart from all affected database must be done.

My recommendation

When you upgrade an 11g database on a server where you still have a 11g database running that you can not restart: Install a new ORACLE_HOME and this problem will only affect your new database which can be fixed with a simple restart of the database.

L’article Take care while upgrading your Oracle DB with “DBUA” est apparu en premier sur dbi Blog.