Upgrade Hol Instructions 2828570 PDF
Upgrade Hol Instructions 2828570 PDF
[optional]:
4. Work with Multitenant databases and implement new Oracle Database 12c features
Before you can start you may have to setup a few things and make yourself familiar with the environment
1
Setup Tasks
Keyboard Layout 3. If you'd like to do more general changes please enter the KDE
CONTROL CENTER by CLICKing on the penguin in the left bottom
The default keyboard layout may be German or US English. If you would like a corner:
different layout, then you can add another keyboard as follows:
1. Login to the Linux desktop (user/password are both “oracle”)
2. If you want to change the keyboard's layout (default is: US) to German
please just CLICK ONCE on the tiny "US" symbol next to the clock:
2
!!! IMPORTANT !!! THINGS TO KNOW AND UNDERSTAND !!!
All passwords are set to: oracle
Switch environments for instance: . cdb2 (type in on shell prompt: <dot> <blank> cdb2)
There is an environment variable $OH12 defined for convenience. This points to the 12.1.0.2 Oracle Home, and is
used several times in part 1 of the lab.
Dark gray background, white characters mean: Execute on the command prompt (OS shell)
Light gray background, black characters mean: Execute in SQL*Plus
3
HOW TO COPY/PASTE WITH THE OKULAR PDF VIEWER
This VM includes the okular PDF reader, which is available in the Linux distribution. In order to copy/paste with
okular, you need to use the “Select Tool.” If you have these instructions open within the VM, then you can see the
select tool at the top of the window. It is the box with the dashed outline as shown here:
Once you choose the Select Tool, this will be the default unless you change it. Then you can select an area and copy
the selection as text. Choose the Text -> “Copy to Clipboard” option as in this example from the first steps in the lab:
4
IMPORTANT !!! System Overview - The numbers on the picture describe part 1-4 of the Hands-On-Lab !!!
5
HOL – Part 1– Upgrade the Oracle 11.2.0.4 database UPGR to Oracle Database 12.1.0.2
Database files location: /oradata/UPGR
Initialization parameter and password file location: /u01/app/oracle/product/11.2.0/dbs
Listener configuration: /u01/app/oracle/product/12.1.0.2/network/admin
You will use the new pre-upgrade check script preupgrd.sql which will examine your UPGR database. This script is shipped with the
new Oracle 12c home in /u01/app/oracle/product/12.1.0.2/rdbms/admin
You will then prepare your UPGR database for the upgrade to Oracle Database 12c and upgrade it. The database will stay in place and
doesn’t get moved to another location.
Remarks:
For this hands-on lab we have provided easy commands to switch environments! You can switch between environments on the bash
shell prompt typing ((don’t type “$>“!!!) in every Terminal/xterm:
6
SID: UPGR – Oracle 11.2.0.4 home SID: UPGR – Oracle 12.1.0.2 home
$> . upgr $> . upgr12
<dot> <space> upgr for the Oracle 11.2.0.4 environment with <dot> <space> upgr12 for the Oracle 12c environment with
your database to be upgraded (SID: UPGR) your database to be upgraded (SID: UPGR)
*** START HERE *** Command Line Upgrade from Oracle 11.2.0.4 to Oracle 12.1.0.2 ***
In this section you’ll execute the new preupgrd.sql check script, verify the output, execute some commands and a fixup script and
prepare a new spfile for the upgrade. Then you’ll copy the spfile and the password file to the new Oracle Database 12c home.
2. Run the new preupgrade check script preupgrd.sql, in your 11.2.0.4 environment – it will generate
3 files:
@$OH12/rdbms/admin/preupgrd.sql
3. Verify the preupgrade.log and make necessary changes
Open a 2nd xterm (right mouse click è Konsole ...):
less /u01/app/oracle/cfgtoollogs/UPGR/preupgrade/preupgrade.log
7
The 11.2.0.4 database has the OLAP Catalog (AMD) component installed, and this component is no
longer included in Oracle Database starting with Oracle Database 12c.
Remove the OLAP Catalog (AMD) component using the script from the 12.1.0.2 Oracle Home ($OH12):
@$OH12/olap/admin/catnoamd.sql
commit;
The preupgrade log includes a message about moving audit data from system.aud$ to sys.aud$ because
Oracle Label Security is installed.
Move the AUD$ table now using the olspreupgrade.sql script from the Oracle Database 12c
home from SYSTEM to SYS:
@$OH12/rdbms/admin/olspreupgrade.sql
Prepare your spfile for the 12c upgrade according to the output from preupgrade.log:
(Please note: Best Practice would be to edit the init.ora for the upgrade manually. You could do so – the
way we propose here is just a shortcut avoiding manual edit steps)
create pfile from spfile;
alter system set processes=300 scope=spfile;
Raise COMPATIBILE for the upgrade, so that we can use this database later in part 2 of the lab.
cp $ORACLE_HOME/dbs/orapwUPGR $OH12/dbs/
9
SID: UPGR SID: UPGR
Oracle 11.2.0.4 home Oracle 12.1.0.2 home
Execute all parallel upgrade steps
Now you’ll upgrade your UPGR database to Oracle Database 12c using the new parallel upgrade scripts.
Furthermore you’ll recompile and check for invalid objects before/after the upgrade.
1. Open an xterm (Terminal icon) -
(right mouse click è Konsole ...)
. upgr12
sqlplus / as sysdba
2. Bring the UPGR database into UPGRADE mode
startup upgrade
exit
3. Upgrade the UPGR database with the parallel upgrade script
Start the new parallel upgrade – it will be driven by a PERL script catctl.pl outside of SQL*Plus and execute
in 4 parallel threads – in maximum you could run with 8 parallel threads by specifying the parameter
option -n 8
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
You will now see that as many as 73 phases will be listed – some can act in parallel, other require serial
execution. This will now take up to 15-30 minutes depending on your system. If you wonder about the
RESTART phases: those happen if timing dependencies make it necessary to rerun a certain action. The
logfiles will be written by default into the directory from which you started catctl.pl,
$ORACLE_HOME/rdbms/admin
10
Once the upgrade is finished it will shutdown the database and in the next phase you’ll restart it in normal
mode.
IF YOUR MACHINE IS WELL EQUIPPED WITH RAM/CPU YOU MAY DO TASKS
IN PARALLEL AND START WITH PART 3 (FULL TRANSPORTABLE EXPORT).
GOTO PAGE 15 – HOL PART 3
11
3. Execute the postupgrade_fixups.sql:
@/u01/app/oracle/cfgtoollogs/UPGR/preupgrade/postupgrade_fixups.sql
4. Adjust Time Zone settings – you may look into the scripts taken from MOS Note: 1509653.1 before
executing them:
@/home/oracle/DST/DST_prepare.sql
@/home/oracle/DST/DST_adjust.sql
exit
12
HOL – Part 2 – Plug in UPGR into CDB2, an Oracle Database 12.1.0.2 container database
Database files location: /oradata/UPGR
Initialization parameter and password file location: /u01/app/oracle/product/12.1.0.2/dbs
Listener configuration: /u01/app/oracle/product/12.1.0.2/network/admin
Applications and clients will connect to the PDB just as they would connect to a non-CDB. The entire CDB/PDB shares one SGA, one set
of background processes, one redo log stream.
In HOL Part 2 you will plug in the already upgraded UPGR database as a new pluggable database PDB1 into the already existing
Container Database CDB2. The data files of UPGR will stay in place.
SID: UPGR – Oracle 12.1.0.2 home SID: CDB2 – Oracle 12.1.0.2 home
$> . upgr12 $> . cdb2
<dot> <space> upgr12 for the Oracle 12.1.0.2 environment <dot> <space> cdb2 for the Oracle 12c environment connecting
with your database to be plugged in later (SID: UPGR) to the Container Database (SID: CDB2)
13
*** START HERE *** Plug in UPGR into CDB2 ***
In this section an XML description file for UPGR will be created and used to plug UPGR into CDB2 as new PDB1. Finally sanity operations
will have to be done to assimilate UPGR finally as PDB2.
Please note: There's no ALTER PLUGGABLE DATABASE … RECONVERT command available. To migrate a database back into a stand-
alone database either Data Pump, Transportable Tablespaces or similar techniques will need to be used.
14
SET SERVEROUTPUT ON
DECLARE
compatible CONSTANT VARCHAR2(3) := CASE
DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file => '/tmp/pdb1.xml',
pdb_name => 'PDB1') WHEN TRUE THEN 'YES' ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(compatible);
END;
/
4. Now plug in the database with its new name PDB1 – from this point there’s no UPGR database anymore.
In a real world environment you would have a backup or use a backup/copy to plug in. In our lab the
database UPGR will stay in place and become PDB1 as part of CDB2.
Please use the proposed naming as the TNS setup has been done already.
Use the NOCOPY option for this lab to avoid additional 2-3 minutes copy time
15
16
HOL – Part 3 – Migrate FTEX database with Full Transportable Export/Import into PDB2
Database files location: /oradata/FTEX
Pluggable database files location: /oradata/CDB2/pdb2
Initialization parameter and password file location: /u01/app/oracle/product/11.2.0.4/dbs
Listener configuration: /u01/app/oracle/product/12.1.0.2/network/admin
Your task in HOL Part 3 will be to use Full Transportable Export/Import to migrate the existing Oracle 11.2.0.4 database FTEX into a
new PDB2 which will belong to the container database CDB2. Please stay with the proposed names (PDB2) as the TNS setup has been
set up already to allow connections etc.
This feature works independent of Oracle Multitenant and platform and can be used to migrate cross Endianness as well. Source
database version has to be at least Oracle 11.2.0.3, target version needs to be at least Oracle 12.1.0.1. For cross-platform migrations
RMAN backups with CONVERT operations will be necessary.
SID: FTEX – Oracle 11.2.0.4 home SID: CDB2 – Oracle 12.1.0.2 home
$> . ftex $> . cdb2
<dot> <space> ftex for the Oracle 11.2.0.4 environment with <dot> <space> cdb2 for the Oracle 12c environment connecting
your database to be plugged in later (SID: FTEX) to the Container Database (SID: CDB2)
17
*** START HERE *** Migrate FTEX with Full Transportable Export/Import into PDB2 ***
The first task in the lab will be to provide an empty database – something we would do for a full import or for transportable
tablespaces as well. But in this specific case we want to consolidate, and therefore pre-create an empty PDB2 (a Pluggable Database)
inside the already existing CDB2 (the Container Database).
startup [ONLY ISSUE THIS COMMAND IF YOU ARE STILL RUNNING HOL PART1]
3. Create a directory object and a database link inside the PDB2 – you will need this for the full
transport operation - the directory /oradata/CDB2/mydir has been precreated as well for Data
Pump
create directory mydir as '/oradata/CDB2/mydir';
grant read, write on directory mydir to system;
create public database link SOURCEDB connect to system identified by
oracle using 'FTEX';
exit
19
2. Start the FTEX database and switch data tablespaces (here: USERS) into read-only mode:
startup
alter tablespace users read only;
exit
3. Copy the files to the target location
cp /oradata/FTEX/users01.dbf /oradata/CDB2/pdb2
21
[optional]
HOL – Part 4 – Create PDB3 in Oracle 12.1.0.1 and upgrade via plug out/in to Oracle 12.1.0.2
Database files location: /oradata/CDB1/pdb3
Pluggable database files location: /oradata/CDB2/pdb3
Initialization parameter and password file location: /u01/app/oracle/product/12.1.0.1/dbs
Listener configuration: /u01/app/oracle/product/12.1.0.2/network/admin
In this part of the HOL a new PDB will be created in an Oracle 12.1.0.1 CDB1 and upgraded via unplug/plugin into the Oracle 12.1.0.2
CDB2.
SID: CDB1 – Oracle 12.1.0.1 home SID: CDB2 – Oracle 12.1.0.2 home
$> . cdb1 $> . cdb2
<dot> <space> cdb1 for the Oracle 12.1.0.1 environment with <dot> <space> cdb2 for the Oracle 12c environment connecting
your database to be plugged in later (SID: CDB1) to the Container Database (SID: CDB2)
22
*** START HERE *** Create PDB3, upgrade it to Oracle 12.1.0.2 via plug out/in ***
The first task in the lab will be to provide an empty database – something we would do for a full import or for transportable
tablespaces as well. But in this specific case we want to consolidate, and therefore pre-create an empty PDB2 (a Pluggable Database)
inside the already existing CDB2 (the Container Database).
2. Start the CDB1 container database – it has no PDBs yet (except for PDB$SEED):
startup
3. Create a new pluggable database PDB3 and start it:
create pluggable database PDB3 admin user adm identified by adm
file_name_convert=( '/oradata/CDB1/pdbseed', '/oradata/CDB1/pdb3');
This will take 1-2 minutes.
alter session set container=pdb3;
startup
shutdown immediate
exit
2. Execute the Plug In Check and check PDB_PLUG_IN_VIOLATIONS when the result of the plug in check is
"NO":
SET SERVEROUTPUT ON
DECLARE
compatible CONSTANT VARCHAR2(3) := CASE
DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
pdb_descr_file => '/tmp/pdb3.xml',
pdb_name => 'PDB3')
WHEN TRUE THEN 'YES' ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(compatible);
END;
/
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -c 'PDB3' catupgrd.sql
25
5. Recompile after upgrade
sqlplus / as sysdba
exit
You'll see that each table HOL within a certain PDB is visible to the CDB$ROOT. But if you'd repeat the exercise within each of the
PDBs you'll see just the contents on a PDB level. Recognize the CON_ID which represents where an object exists.
If you have further questions you may please download the +500 slide deck containing almost everything about
upgrades and migrations. And always feel free to contact us directly.
http://blogs.oracle.com/UPGRADE
Thanks and successful upgrades!
Roy Swonger & Mike Dietrich & The Database Upgrade Team
28