jueves, 1 de diciembre de 2016

RMAN Table Point In Time Recovery (PITR) in Oracle Database 12c Release 1 (12.1)

RMAN Table Point In Time Recovery (PITR) in Oracle Database 12c Release 1 (12.1)

In previous releases point in time recovery of a table or table partition was only possible by manually creating a point in time clone of the database, retrieving the table using data pump, then removing the clone. Oracle 12c includes a new RMAN feature which performs all these steps, initiated from a single command.
Related articles.

Setup

To demonstrate this, we need to create a table to do a PITR on. This example assumes you are running in archivelog mode and have adequate backups in place to allow a recovery via a point in time clone. For such a recent modification, using a flashback query would be more appropriate, but this serves the purpose for this test.
CONN / AS SYSDBA

CREATE USER test IDENTIFIED BY test
  QUOTA UNLIMITED ON users;

GRANT CREATE SESSION, CREATE TABLE TO test;

CONN test/test

CREATE TABLE t1 (id NUMBER);
INSERT INTO t1 VALUES (1);
COMMIT;
Check the current SCN.
CONN / AS SYSDBA

SELECT DBMS_FLASHBACK.get_system_change_number FROM dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 1853267

SQL>
Add some more data since the SCN was checked.
CONN test/test

INSERT INTO t1 VALUES (2);
COMMIT;

SELECT * FROM t1;

        ID
----------
         1
         2

SQL> 
Exit from SQL*Plus and log in to RMAN as a root user with SYSDBA or SYSBACKUP privilege.

Table Point In Time Recovery (PITR)

Log in to RMAN as a user with SYSDBA or SYSBACKUP privilege.
$ rman target=/
Issue the RECOVER TABLE command, giving a suitable AUXILIARY DESTINATION location for the auxiliary database. In the following example the REMAP TABLE clause is used to give the recovered table a new name.
RECOVER TABLE 'TEST'.'T1'
  UNTIL SCN 1853267
  AUXILIARY DESTINATION '/u01/aux'  
  REMAP TABLE 'TEST'.'T1':'T1_PREV';


RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…'
  AUXILIARY DESTINATION '/u01/tablerecovery'
  DATAPUMP DESTINATION '/u01/dpump'
  DUMP FILE 'tablename.dmp'
  NOTABLEIMPORT   
REMAP TABLE 'username.tablename': 'username.new_table_name'; 


The output from this command is shown here. It's rather long, but it clearly shows the creation of the clone and the data pump export and import operations. Once the operation is complete, we can see the T1_PREV table has been created and contains the data as it was when the SCN was captured.
sqlplus test/test

SELECT * FROM t1_prev;

 ID
----------
  1

SQL> 

Table Point In Time Recovery (PITR) to Dump File

Rather than completing the whole recovery, you can just stop at the point where the recovered table is in a data pump dump file, which you can import manually at a later time. The following example uses the DATAPUMP DESTINATION, DUMP FILE and NOTABLEIMPORT clauses to achieve this.
RECOVER TABLE 'TEST'.'T1'
  UNTIL SCN 1853267
  AUXILIARY DESTINATION '/u01/aux'
  DATAPUMP DESTINATION '/u01/export'
  DUMP FILE 'test_t1_prev.dmp'
  NOTABLEIMPORT;
The output from this command is shown here. Once the operation is complete, we can see the resulting dump file in the specified directory.
$ ls -al /u01/export
total 120
drwxr-xr-x. 2 oracle oinstall   4096 Dec 26 17:33 .
drwxrwxr-x. 5 oracle oinstall   4096 Dec 26 12:30 ..
-rw-r-----. 1 oracle oinstall 114688 Dec 26 17:34 test_t1_prev.dmp
$

lunes, 31 de octubre de 2016

+ASM CHECK ALL REPAIR


 

SQL> alter diskgroup DG_DATA check all repair;

SQL>alter diskgroup DG_FRA check all repair;
SQL> alter diskgroup DG_DATA rebalance power 11 nowait;

 

miércoles, 14 de septiembre de 2016

REPORT_SQL_MONITOR

Oracle 11g automatically monitors SQL statements if they are run in parallel, or consume 5 or more seconds of CPU or I/O in a single execution. This allows resource intensive SQL to be monitored as it is executing, as well as giving access to detailed information about queries once they are complete.
SQL monitoring requires the STATISTICS_LEVEL parameter to be set to 'TYPICAL' or 'ALL', and the CONTROL_MANAGEMENT_PACK_ACCESS parameter set to 'DIAGNOSTIC+TUNING'.
SQL> CONN / AS SYSDBA
Connected.
SQL> SHOW PARAMETER statistics_level

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
statistics_level       string  TYPICAL

SQL> SHOW PARAMETER control_management_pack_access

NAME         TYPE  VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access      string  DIAGNOSTIC+TUNING

SQL>

MONITOR Hint

The MONITOR hint switches on SQL monitoring for statements that would not otherwise initiate it.
SELECT /*+ MONITOR */ d.dname, WM_CONCAT(e.ename) AS employees
FROM   emp e
       JOIN dept d ON e.deptno = d.deptno
GROUP BY d.dname
ORDER BY d.dname;
If you have long running statements you don't want to monitor, use the NO_MONITOR hint to prevent them being monitored.

REPORT_SQL_MONITOR

The REPORT_SQL_MONITOR function is used to return a SQL monitoring report for a specific SQL statement. The SQL statement can be identified using a variety of parameters, but it will typically be identified using the SQL_ID parameter.
The function can accept many optional parameters, shown here, but most of the time you will probably only use the following.
  • SQL_ID - The SQL_ID of the query of interest. When NULL (the default) the last monitored statement is targeted.
  • SQL_EXEC_ID - When the SQL_ID is specified, the SQL_EXEC_ID indicates the individual execution of interest. When NULL (the default) the most recent execution of the statement targeted by the SQL_ID is assumed.
  • REPORT_LEVEL - The amount of information displayed in the report. The basic allowed values are 'NONE', 'BASIC', 'TYPICAL' or 'ALL', but the information displayed can be modified further by adding (+) or subtracting (-) named report sections (eg. 'BASIC +PLAN +BINDS' or 'ALL -PLAN'). This is similar to the way DBMS_XPLAN output can be tailored in the later releases. I almost always use 'ALL'.
  • TYPE - The format used to display the report ('TEXT', 'HTML', 'XML' or 'ACTIVE'). The 'ACTIVE' setting is new to Oracle 11g Release 2 and displays the output using HTML and Flash, similar to the way it is shown in Enterprise Manager.
  • SESSION_ID - Targets a subset of queries based on the specified SID. Use SYS_CONTEXT('USERENV','SID') for the current session.
The report accesses several dynamic performance views, so you will most likely access it from a privileged user, or a user granted the SELECT_CATALOG_ROLE role.
To see it in action, first we make sure we have a monitored statement to work with.
CONN scott/tiger

SELECT /*+ MONITOR */ d.dname, WM_CONCAT(e.ename) AS employees
FROM   emp e
       JOIN dept d ON e.deptno = d.deptno
GROUP BY d.dname
ORDER BY d.dname;
Monitored statements can be identified using the V$SQL_MONITOR view. This view was present in Oracle 11g Release 1, but has additional columns in Oracle 11g Release 2, making it much more useful. It contains an entry for each execution monitored, so it can contain multiple entries for individual SQL statements.
CONN / AS SYSDBA

-- 11gR1
SELECT sql_id, status
FROM   v$sql_monitor;

SQL_ID       STATUS
------------- -------------------
526mvccm5nfy4 DONE (ALL ROWS)

SQL>

-- 11gR2
SET LINESIZE 200
COLUMN sql_text FORMAT A80

SELECT sql_id, status, sql_text
FROM   v$sql_monitor
WHERE  username = 'SCOTT';

SQL_ID        STATUS              SQL_TEXT
------------- ------------------- --------------------------------------------------------------------------------
526mvccm5nfy4 DONE (ALL ROWS)     SELECT /*+ MONITOR */ d.dname, WM_CONCAT(e.ename) AS employees
                                  FROM   emp e
                                         JOIN dept d ON e.deptno = d.deptno
                                  GROUP BY d.dname
                                  ORDER BY d.dname

SQL>
Once the SQL_ID is identified, we can generate a report using the REPORT_SQL_MONITOR function.
SET LONG 1000000
SET LONGCHUNKSIZE 1000000
SET LINESIZE 1000
SET PAGESIZE 0
SET TRIM ON
SET TRIMSPOOL ON
SET ECHO OFF
SET FEEDBACK OFF

SPOOL /host/report_sql_monitor.htm
SELECT DBMS_SQLTUNE.report_sql_monitor(
  sql_id       => '526mvccm5nfy4',
  type         => 'HTML',
  report_level => 'ALL') AS report
FROM dual;
SPOOL OFF
Examples of the output for each available TYPE are displayed below.
  • TEXT
  • HTML
  • XML
  • ACTIVE - Active HTML available in 11gR2 requires a download of Javascript libraries and a Flash movie from an Oracle website, so must be used on a PC connected to the internet, unless you download the relevant libraries and use the BASE_PATH parameter in the function call to identify their location.
In Oracle 12c, the REPORT_SQL_MONITOR function is now found in the DBMS_SQL_MONITOR package.

REPORT_SQL_MONITOR_LIST

The REPORT_SQL_MONITOR_LIST function was added in Oracle 11g Release 2 to generate a summary screen, similar to that on the "Monitored SQL Executions" page of Enterprise Manager. There are a number of parameters to filer the content of the report (shown here), but most of the time you will probably only use the TYPE and REPORT_LEVEL parameters, similar to those in the REPORT_SQL_MONITOR function. The query below shows how the function can be used.
SET LONG 1000000
SET LONGCHUNKSIZE 1000000
SET LINESIZE 1000
SET PAGESIZE 0
SET TRIM ON
SET TRIMSPOOL ON
SET ECHO OFF
SET FEEDBACK OFF

SPOOL /host/report_sql_monitor_list.htm
SELECT DBMS_SQLTUNE.report_sql_monitor_list(
  type         => 'HTML',
  report_level => 'ALL') AS report
FROM dual;
SPOOL OFF
Examples of the output for each available TYPE are displayed below.
  • TEXT
  • HTML
  • XML
  • ACTIVE - Active HTML is not currently supported, but the parameter list, specifically the BASE_PATH, suggest it will be supported in future.
In Oracle 12c, the REPORT_SQL_MONITOR_LIST function is now found in the DBMS_SQL_MONITOR package.

viernes, 19 de agosto de 2016

RMAN TABLA Perdida de Tabla

Perdida de Tabla

Para el presente caso la tabla será premeditadamente borrada. Tal como fue mencionada en la parte inicial del artículo, el caso que estamos desarrollando es el planteamiento de recuperación en caso de que una tabla sea accidentalmente borrada, corrupta, etc y la misma necesite ser recuperada/restaurada a un determinado punto del tiempo, disponiendo para la tarea un backup de la BBDD realizado con RMAN.
sandbox1(orawiss):/home/oracle>sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Wed Jun 26 14:45:21 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

SQL> alter session set container=ORAWISS12C;

Session altered.

SQL> DROP TABLE wissem.test_rec PURGE;

Table dropped.

SQL> select * from wissem.test_rec;
select * from wissem.test_rec
                     *
ERROR at line 1:
ORA-00942: table or view does not exist

SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options
sandbox1(orawiss):/home/oracle>

Sintaxis
Antes de la ejecución veamos la sintaxis del comando a ser utilizado:
RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…'
  AUXILIARY DESTINATION '/u01/tablerecovery'
  DATAPUMP DESTINATION '/u01/dpump'
  DUMP FILE 'tablename.dmp'
  NOTABLEIMPORT   
REMAP TABLE 'username.tablename': 'username.new_table_name'; 

TABLE username.tablename: Tabla objeto de recuperación
UNTIL TIME 'TIMESTAMP…': Tiempo hasta el cual se establecerá la recuperación de la tabla
AUXILIARY DESTINATION: Directorio de alojamiento para la BBDD Auxiliar a ser creada
DATAPUMP DESTINATION: Directorio de alojamiento para el “Data Pump export dump file” a ser generado
DUMP FILE: Nombre de “Data Pump export dump file” a ser generado
NOTABLEIMPORT: Opción de control para establecer el posible restaurado de la tabla y/o particiones en la BBDD “Target”
REMAP TABLE 'username.tablename': 'username.new_table_name': Opción para renombrar la tabla a restaurar en la BBDD “Target”
Ejecución
En la presente ejecución la clausula “NOTABLEIMPORT” no esta presente en la conformación del comando “RECOVER TABLE”. Cuando la mencionada clausula es omitida, el proceso importa de forma automática la tabla en la BBDD “Target”.
sandbox1(orawiss):/home/oracle>rman

Recovery Manager: Release 12.1.0.1.0 - Production on Wed Jun 26 15:28:04 2013

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

RMAN> CONNECT TARGET "sys AS SYSBACKUP";

target database Password:
connected to target database: ORAWISS (DBID=3257067578)

RMAN> RECOVER TABLE WISSEM.TEST_REC OF PLUGGABLE DATABASE ORAWISS12C UNTIL TIME 
"to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')" AUXILIARY DESTINATION 
'/tmp' DATAPUMP DESTINATION '/tmp' DUMP FILE 'tst_dump2.dmp';

Starting recover at 06/26/2013 15:28:37
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=272 device type=DISK
RMAN-05026: WARNING: presuming following set of tablespaces applies to specified 
Point-in-Time

List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1

Creating automatic instance, with SID='AAxr'

initialization parameters used for automatic instance:
db_name=ORAWISS
db_unique_name=AAxr_pitr_ORAWISS12C_ORAWISS
compatible=12.1.0.0.0
db_block_size=8192
db_files=200
sga_target=1G
processes=80
diagnostic_dest=/opt/app/oracle
db_create_file_dest=/tmp
log_archive_dest_1='location=/tmp'
enable_pluggable_database=true
_clone_one_pdb_recovery=true
#No auxiliary parameter file used

starting up automatic instance ORAWISS

Oracle instance started

Total System Global Area    1068937216 bytes

Fixed Size                     2296576 bytes
Variable Size                281019648 bytes
Database Buffers             780140544 bytes
Redo Buffers                   5480448 bytes
Automatic instance created

contents of Memory Script:
{
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# restore the controlfile
restore clone controlfile;
# mount the controlfile
sql clone 'alter database mount clone database';
# archive current online log
sql 'alter system archive log current';
}
executing Memory Script

executing command: SET until clause

Starting restore at 06/26/2013 15:28:50
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=82 device type=DISK

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece 
+DATA/ORAWISS/AUTOBACKUP/2013_06_26/s_819125085.301.819125085
channel ORA_AUX_DISK_1: piece 
handle=+DATA/ORAWISS/AUTOBACKUP/2013_06_26/s_819125085.301.819125085 
tag=TAG20130626T144445
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:07
output file name=/tmp/ORAWISS/controlfile/o1_mf_8wpj7slx_.ctl
Finished restore at 06/26/2013 15:28:58

sql statement: alter database mount clone database

sql statement: alter system archive log current

contents of Memory Script:
{
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# set destinations for recovery set and auxiliary set datafiles
set newname for clone datafile  1 to new;
set newname for clone datafile  4 to new;
set newname for clone datafile  3 to new;
set newname for clone datafile  8 to new;
set newname for clone datafile  9 to new;
set newname for clone tempfile  1 to new;
set newname for clone tempfile  3 to new;
# switch all tempfiles
switch clone tempfile all;
# restore the tablespaces in the recovery set and the auxiliary set
restore clone datafile  1, 4, 3, 8, 9;
switch clone datafile all;
}
executing Memory Script

executing command: SET until clause

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

renamed tempfile 1 to /tmp/ORAWISS/datafile/o1_mf_temp_%u_.tmp in control file
renamed tempfile 3 to /tmp/ORAWISS/datafile/o1_mf_temp_%u_.tmp in control file

Starting restore at 06/26/2013 15:29:04
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to 
/tmp/ORAWISS/datafile/o1_mf_system_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to 
/tmp/ORAWISS/datafile/o1_mf_undotbs1_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to 
/tmp/ORAWISS/datafile/o1_mf_sysaux_%u_.dbf
channel ORA_AUX_DISK_1: reading from backup piece 
+DATA/ORAWISS/BACKUPSET/2013_06_26/nnndf0_tag20130626t123856_0.282.819117537
channel ORA_AUX_DISK_1: piece 
handle=+DATA/ORAWISS/BACKUPSET/2013_06_26/nnndf0_tag20130626t123856_0.282.819117537
 tag=TAG20130626T123856
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:15
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00008 to 
/tmp/ORAWISS/datafile/o1_mf_system_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00009 to 
/tmp/ORAWISS/datafile/o1_mf_sysaux_%u_.dbf
channel ORA_AUX_DISK_1: reading from backup piece 
+DATA/ORAWISS/E011004AA64F0CF9E0433514DA0A096B/BACKUPSET/2013_06_26/nnndf0_tag20130
626t144437_0.298.819125079
channel ORA_AUX_DISK_1: piece 
handle=+DATA/ORAWISS/E011004AA64F0CF9E0433514DA0A096B/BACKUPSET/2013_06_26/nnndf0_t
ag20130626t144437_0.298.819125079 tag=TAG20130626T144437
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 06/26/2013 15:29:27

datafile 1 switched to datafile copy
input datafile copy RECID=8 STAMP=819127767 file 
name=/tmp/ORAWISS/datafile/o1_mf_system_8wpj8191_.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=9 STAMP=819127767 file 
name=/tmp/ORAWISS/datafile/o1_mf_undotbs1_8wpj819j_.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=10 STAMP=819127767 file 
name=/tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8199_.dbf
datafile 8 switched to datafile copy
input datafile copy RECID=11 STAMP=819127767 file 
name=/tmp/ORAWISS/datafile/o1_mf_system_8wpj8jf1_.dbf
datafile 9 switched to datafile copy
input datafile copy RECID=12 STAMP=819127767 file 
name=/tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8jdt_.dbf

contents of Memory Script:
{
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# online the datafiles restored or switched
sql clone "alter database datafile  1 online";
sql clone "alter database datafile  4 online";
sql clone "alter database datafile  3 online";
sql clone 'ORAWISS12C' "alter database datafile
 8 online";
sql clone 'ORAWISS12C' "alter database datafile
 9 online";
# recover and open database read only
recover clone database tablespace  "SYSTEM", "UNDOTBS1", "SYSAUX", 
"ORAWISS12C":"SYSTEM", "ORAWISS12C":"SYSAUX";
sql clone 'alter database open read only';
}
executing Memory Script

executing command: SET until clause

sql statement: alter database datafile  1 online

sql statement: alter database datafile  4 online

sql statement: alter database datafile  3 online

sql statement: alter database datafile  8 online

sql statement: alter database datafile  9 online

Starting recover at 06/26/2013 15:29:28
using channel ORA_AUX_DISK_1

starting media recovery

archived log for thread 1 with sequence 15 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_15.279.819117567
archived log for thread 1 with sequence 16 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_16.278.819123911
archived log for thread 1 with sequence 17 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_17.294.819123955
archived log for thread 1 with sequence 18 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_18.296.819123981
archived log for thread 1 with sequence 19 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_19.295.819124251
archived log for thread 1 with sequence 20 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_20.297.819124297
archived log for thread 1 with sequence 21 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_21.299.819124453
archived log for thread 1 with sequence 22 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_22.286.819125213
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_15.279.819117567 thread=1 
sequence=15
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_16.278.819123911 thread=1 
sequence=16
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_17.294.819123955 thread=1 
sequence=17
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_18.296.819123981 thread=1 
sequence=18
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_19.295.819124251 thread=1 
sequence=19
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_20.297.819124297 thread=1 
sequence=20
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_21.299.819124453 thread=1 
sequence=21
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_22.286.819125213 thread=1 
sequence=22
media recovery complete, elapsed time: 00:00:04
Finished recover at 06/26/2013 15:29:34

sql statement: alter database open read only

contents of Memory Script:
{
sql clone 'alter pluggable database  ORAWISS12C open read only';
}
executing Memory Script

sql statement: alter pluggable database  ORAWISS12C open read only

contents of Memory Script:
{
   sql clone "create spfile from memory";
   shutdown clone immediate;
   startup clone nomount;
   sql clone "alter system set  control_files =
  ''/tmp/ORAWISS/controlfile/o1_mf_8wpj7slx_.ctl'' comment=
 ''RMAN set'' scope=spfile";
   shutdown clone immediate;
   startup clone nomount;
# mount database
sql clone 'alter database mount clone database';
}
executing Memory Script

sql statement: create spfile from memory

database closed
database dismounted
Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area    1068937216 bytes

Fixed Size                     2296576 bytes
Variable Size                285213952 bytes
Database Buffers             775946240 bytes
Redo Buffers                   5480448 bytes

sql statement: alter system set  control_files =   
''/tmp/ORAWISS/controlfile/o1_mf_8wpj7slx_.ctl'' comment= ''RMAN set'' scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area    1068937216 bytes

Fixed Size                     2296576 bytes
Variable Size                285213952 bytes
Database Buffers             775946240 bytes
Redo Buffers                   5480448 bytes

sql statement: alter database mount clone database

contents of Memory Script:
{
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# set destinations for recovery set and auxiliary set datafiles
set newname for datafile  13 to new;
# restore the tablespaces in the recovery set and the auxiliary set
restore clone datafile  13;
switch clone datafile all;
}
executing Memory Script

executing command: SET until clause

executing command: SET NEWNAME

Starting restore at 06/26/2013 15:30:08
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=15 device type=DISK

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00013 to 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/datafile/o1_mf_tbs_rec_%u_.dbf
channel ORA_AUX_DISK_1: reading from backup piece 
+DATA/ORAWISS/E011004AA64F0CF9E0433514DA0A096B/BACKUPSET/2013_06_26/nnndf0_tag20130
626t144437_0.298.819125079
channel ORA_AUX_DISK_1: piece 
handle=+DATA/ORAWISS/E011004AA64F0CF9E0433514DA0A096B/BACKUPSET/2013_06_26/nnndf0_t
ag20130626t144437_0.298.819125079 tag=TAG20130626T144437
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 06/26/2013 15:30:10

datafile 13 switched to datafile copy
input datafile copy RECID=14 STAMP=819127810 file 
name=/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/datafile/o1_mf_tbs_rec_8wpjb1c3_.dbf

contents of Memory Script:
{
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# online the datafiles restored or switched
sql clone 'ORAWISS12C' "alter database datafile
 13 online";
# recover and open resetlogs
recover clone database tablespace  "ORAWISS12C":"TBS_REC", "SYSTEM", "UNDOTBS1", 
"SYSAUX", "ORAWISS12C":"SYSTEM", "ORAWISS12C":"SYSAUX" delete archivelog;
alter clone database open resetlogs;
}
executing Memory Script

executing command: SET until clause

sql statement: alter database datafile  13 online

Starting recover at 06/26/2013 15:30:10
using channel ORA_AUX_DISK_1

starting media recovery

archived log for thread 1 with sequence 22 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_22.286.819125213
archived log file 
name=+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_22.286.819125213 thread=1 
sequence=22
media recovery complete, elapsed time: 00:00:00
Finished recover at 06/26/2013 15:30:11

database opened

contents of Memory Script:
{
sql clone 'alter pluggable database  ORAWISS12C open';
}
executing Memory Script

sql statement: alter pluggable database  ORAWISS12C open

contents of Memory Script:
{
# create directory for datapump import
sql 'ORAWISS12C' "create or replace directory
TSPITR_DIROBJ_DPDIR as ''
/tmp''";
# create directory for datapump export
sql clone 'ORAWISS12C' "create or replace directory
TSPITR_DIROBJ_DPDIR as ''
/tmp''";
}
executing Memory Script

sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''/tmp''

sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''/tmp''

Performing export of tables...
   EXPDP> Starting "SYS"."TSPITR_EXP_AAxr_wgmi":
   EXPDP> Estimate in progress using BLOCKS method...
   EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
   EXPDP> Total estimation using BLOCKS method: 64 KB
   EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
   EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
   EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
   EXPDP> . . exported "WISSEM"."TEST_REC"              5.031 KB       1 rows
   EXPDP> Master table "SYS"."TSPITR_EXP_AAxr_wgmi" successfully loaded/unloaded
   EXPDP> ******************************************************************************
   EXPDP> Dump file set for SYS.TSPITR_EXP_AAxr_wgmi is:
   EXPDP>   /tmp/tst_dump2.dmp
   EXPDP> Job "SYS"."TSPITR_EXP_AAxr_wgmi" successfully completed at Wed Jun 26 
   15:30:51 2013 elapsed 0 00:00:22
Export completed

contents of Memory Script:
{
# shutdown clone before import
shutdown clone abort
}
executing Memory Script

Oracle instance shut down

Performing import of tables...
   IMPDP> Master table "SYSBACKUP"."TSPITR_IMP_AAxr_yzka" successfully 
   loaded/unloaded
   IMPDP> Starting "SYSBACKUP"."TSPITR_IMP_AAxr_yzka":
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
   IMPDP> . . imported "WISSEM"."TEST_REC"          5.031 KB       1 rows
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
   IMPDP> Job "SYSBACKUP"."TSPITR_IMP_AAxr_yzka" successfully completed at Wed Jun 
   26 15:31:23 2013 elapsed 0 00:00:08
Import completed

Removing automatic instance
Automatic instance removed
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_temp_8wpj92wr_.tmp deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_temp_8wpj8zhc_.tmp deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_3_8wpjb4l3_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_2_8wpjb49s_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_1_8wpjb434_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/datafile/o1_mf_tbs_rec_8wpjb1c3_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8jdt_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_system_8wpj8jf1_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8199_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_undotbs1_8wpj819j_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_system_8wpj8191_.dbf deleted
auxiliary instance file /tmp/ORAWISS/controlfile/o1_mf_8wpj7slx_.ctl deleted
auxiliary instance file tst_dump2.dmp deleted
Finished recover at 06/26/2013 15:31:28

RMAN> exit

Verificado de resultado
La tabla que fue anteriormente borrada fue recuperada por el proceso.
Recovery Manager complete.
sandbox1(orawiss):/home/oracle>sqlplus /  as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Wed Jun 26 15:31:36 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options

SQL> alter session set container=ORAWISS12C;

Session altered.

SQL> select * from wissem.test_rec;

        ID
----------
         1

SQL>

Durante la ejecución se pudieron observar detalles importantes que harán que usted como lector pueda entender los procesos internos realizados. Veamos detalles del mismo:
• Ejecución del comando “RECOVER TABLE”
RMAN> RECOVER TABLE WISSEM.TEST_REC OF PLUGGABLE DATABASE ORAWISS12C UNTIL TIME 
"to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')" AUXILIARY DESTINATION 
'/tmp' DATAPUMP DESTINATION '/tmp' DUMP FILE 'tst_dump2.dmp';

• Establecimiento de Parámetros de Inicialización para la Instancia Auxiliar con bajo consumo de recursos
initialization parameters used for automatic instance:
db_name=ORAWISS
db_unique_name=AAxr_pitr_ORAWISS12C_ORAWISS
compatible=12.1.0.0.0
db_block_size=8192
db_files=200
sga_target=1G
processes=80
diagnostic_dest=/opt/app/oracle
db_create_file_dest=/tmp
log_archive_dest_1='location=/tmp'
enable_pluggable_database=true
_clone_one_pdb_recovery=true

• Restaurado de “Controlfiles” para iniciar el proceso de recuperación
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# restore the controlfile
restore clone controlfile;
# mount the controlfile

• Proceso de Restauración de “Tablespaces”
# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# set destinations for recovery set and auxiliary set datafiles
set newname for clone datafile  1 to new;
set newname for clone datafile  4 to new;
set newname for clone datafile  3 to new;
set newname for clone datafile  8 to new;
set newname for clone datafile  9 to new;
set newname for clone tempfile  1 to new;
set newname for clone tempfile  3 to new;
# switch all tempfiles
switch clone tempfile all;
# restore the tablespaces in the recovery set and the auxiliary set
restore clone datafile  1, 4, 3, 8, 9;
switch clone datafile all;

• Restaurado de “Datafiles” en la ruta indicada por el parámetro “AUXILIARY DESTINATION”
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to 
/tmp/ORAWISS/datafile/o1_mf_system_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to 
/tmp/ORAWISS/datafile/o1_mf_undotbs1_%u_.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to 
/tmp/ORAWISS/datafile/o1_mf_sysaux_%u_.dbf

• Recuperación “Until Time” de la BBDD Auxiliar
Starting recover at 06/26/2013 15:23:16
using channel ORA_AUX_DISK_1

starting media recovery

archived log for thread 1 with sequence 15 is already on disk as file 
+DATA/ORAWISS/ARCHIVELOG/2013_06_26/thread_1_seq_15.279.819117567
…

# set requested point in time
set until  time "to_date('2013-06-26:14:45:00','YYYY-MM-DD:HH24:MI:SS')";
# set destinations for recovery set and auxiliary set datafiles
set newname for datafile  13 to new;
# restore the tablespaces in the recovery set and the auxiliary set
restore clone datafile  13;
switch clone datafile all;

• Generación del “Data Pump export dump file”
sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''/tmp''

Performing export of tables...
 EXPDP> Starting "SYS"."TSPITR_EXP_AAxr_wgmi":
 EXPDP> Estimate in progress using BLOCKS method...
 EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
 EXPDP> Total estimation using BLOCKS method: 64 KB
 EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
 EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
 EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
 EXPDP> . . exported "WISSEM"."TEST_REC"           5.031 KB       1 rows
 EXPDP> Master table "SYS"."TSPITR_EXP_AAxr_wgmi" successfully loaded/unloaded
 EXPDP> *****************************************************************
 EXPDP> Dump file set for SYS.TSPITR_EXP_AAxr_wgmi is:
 EXPDP>   /tmp/tst_dump2.dmp
 EXPDP> Job "SYS"."TSPITR_EXP_AAxr_wgmi" successfully completed at Wed Jun 26 
 15:30:51 2013 elapsed 0 00:00:22
Export completed

“Data Pump export dump file” resultante: EXPDP> /tmp/tst_dump2.dmp
• “Import” automático de la tabla en la BBDD “Target”
Performing import of tables...
   IMPDP> Master table "SYSBACKUP"."TSPITR_IMP_AAxr_yzka" successfully 
   loaded/unloaded
   IMPDP> Starting "SYSBACKUP"."TSPITR_IMP_AAxr_yzka":
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
   IMPDP> . . imported "WISSEM"."TEST_REC"           5.031 KB       1 rows
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
   IMPDP> Job "SYSBACKUP"."TSPITR_IMP_AAxr_yzka" successfully completed at Wed 
   Jun 26 15:31:23 2013 elapsed 0 00:00:08
Import completed

• Remoción automática de los componentes de la BBDD “Auxiliar”
Removing automatic instance
Automatic instance removed
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_temp_8wpj92wr_.tmp deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_temp_8wpj8zhc_.tmp deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_3_8wpjb4l3_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_2_8wpjb49s_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/onlinelog/o1_mf_1_8wpjb434_.log deleted
auxiliary instance file 
/tmp/AAXR_PITR_ORAWISS12C_ORAWISS/datafile/o1_mf_tbs_rec_8wpjb1c3_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8jdt_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_system_8wpj8jf1_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_sysaux_8wpj8199_.dbf deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_undotbs1_8wpj819j_.dbf 
deleted
auxiliary instance file /tmp/ORAWISS/datafile/o1_mf_system_8wpj8191_.dbf deleted
auxiliary instance file /tmp/ORAWISS/controlfile/o1_mf_8wpj7slx_.ctl deleted
auxiliary instance file tst_dump2.dmp deleted
Finished recover at 06/26/2013 15:31:28

Conclusiones
Tal como se ha señalado en el desarrollo del artículo, esta nueva característica nos brinda la facilidad de recuperar tablas y/o particiones de tablas con un proceso directo haciendo uso optimo de recursos como: disco, memoria y otros relacionados con el proceso.
El comando “RECOVER TABLE” no solo tiene impacto en la acción directa que realiza, sino también en como lograra cambiar en concepto del papel que juegan los respaldos lógicos que muchas empresas llevaban a cabo para prevenir la posible recuperación de objetos sin tener que restaurar la BBDD completa.
Antes de finalizar el presente artículo veamos cuadro comparativo de las ventajas que posee el nuevo “RECOVER TABLE” con respecto a TSPITR ( Tablespace Point-in-Time Recovery )

martes, 2 de agosto de 2016

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )

Por Joel Pérez y Javier Ruiz (OCP)
Publicado en Enero 2014
Indice
1. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
2. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )
3. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )
4. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )

Continuamos…
En el origen ( 11gR2 ) creamos un directorio para alojar los “Export Dump Files” and “RMAN files”
$mkdir -p /orabkup/dbtest1/dpdump

    
Creando directorio en la BBDD origen para el “Export Job”
SQL>create directory "EXP_DATA_PUMP_DIR"  as '/orabkup/dbtest1/dpdump/';

    
En la base de datos origen se establecen en modo “Read Only” los “Tablespaces” que contienen la “Data” de aplicación ( “USERS” & “SOE” )
SQL> alter tablespace USERS read only;
SQL> alter tablespace SOE read only;


Ejecución de “Full Export” en la BBDD origen con el establecimiento del parámetro “VERSION=12” y el “TRANSPORTABLE=ALWAYS”
$expdp \'sys/temp1234 AS SYSDBA\' full=y job_name=EXPORT_DEV2DB 
dumpfile=datapump_dev2db.dmp DIRECTORY=EXP_DATA_PUMP_DIR 
LOGFILE=export_datapump_dev2db.log VERSION=12 transportable=always

Divise con atención que el “feedback” de la actividad de “Export” indica de forma explicita cuales son “Tablespaces” a exportar y sus respectivos “Datafiles”

Ejecución de “RMAN” para respaldar fisicamente los “Datafile” en “filesystem”. Dicho respaldo se pudiera realizar con diversas técnicas, para el caso presente lo realizaremos con “CONVERT DATAFILE”
$rman target /
run
{
CONVERT DATAFILE '+DATADG/dbtest1/datafile/soe.262.814263143'  
DB_FILE_NAME_CONVERT="+DATADG/dbtest1/datafile/soe.262.814263143","/orabkup/dbtest1
/dpdump/soe.262.814263143" FORMAT='/orabkup/dbtest1/dpdump/soe.262.814263143';
CONVERT DATAFILE '+DATADG/dbtest1/datafile/users.260.814258995'  
DB_FILE_NAME_CONVERT="+DATADG/dbtest1/datafile/users.260.814258995","/orabkup/dbtes
t1/dpdump/users.260.814258995" 
FORMAT='/orabkup/dbtest1/dpdump/users.260.814258995';
} 

    
En el origen los “Tablespaces” pueden retornar a modo “Read-Write”
SQL> alter tablespace USERS read write;
SQL> alter tablespace SOE read write;

    
Creación de Directorio en el “Target Server”
$mkdir -p /orabkup/dbtest1

    
Transferencia de Archivos del “Source Server” al “Target Server”
  • “Datafiles”
  • “Export Dump Files”
$scp -r dpdump oracle@alpddbs002:/orabkup/dbtest1/


En el destino nos conectamos con una “CDB” previamente creada y procedemos a crear una “PDB” para nuestro escenario. Como nuestro objetivo es crear una “PDB” vacía ( respecto a “Tablespaces” de “Data” ) y adecuada para la tarea entonces procedemos a crearla con el siguiente “SQL Statement”

“Feedback” en el “Alert log file” durante y posterior a la creación de nuestra target “PDB” “dev2db”. El “PDB id” otorgado a nuestra “PDB” es “5”, numero que utilizaremos con referencia para visualizar información mas adelante

Apertura de la “PDB dev2db”
SQL> Alter pluggable database dev2db open read write;

    
Visualizando nuestra “PDB dev2db” en modo “Read-Write”, fecha de apertura, medida en “MB” y su respectivo “PDB id”

Desde el “CBD” revisión de los “Datafiles” de la “PDB dev2db”. Tal como puede observarse posee solo 2 “Datafiles” pertenecientes a los 2 “Tablespaces” base de una “PDB”

Creación de Directorio ASM para el almacenamiento de “Datafiles”
$asmcmd -p
ASMCMD>cd dg01
ASMCMD>mkdir DEV2DB


Llegados a este punto utilizaremos “RMAN” para restaurar al “ASM Target” los “Datafiles” traídos desde “Solaris”.
$rman
RMAN>CONNECT TARGET sys/temp1234@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=alpddbs002)(PORT=1521))(CONNECT_DATA=(SID=testdbs)))
RMAN>run
{
CONVERT DATAFILE '/orabkup/dbtest1/dpdump/soe.262.814263143'  
DB_FILE_NAME_CONVERT="/orabkup/dbtest1/dpdump/soe.262.814263143",
"+DG01/dev2db/soe_data_1" FORMAT='+DG01/dev2db/soe_data_1';
CONVERT DATAFILE '/orabkup/dbtest1/dpdump/users.260.814258995'  
DB_FILE_NAME_CONVERT="/orabkup/dbtest1/dpdump/users.260.814258995",
"+DG01/dev2db/users_data_1" FORMAT='+DG01/dev2db/users_data_1';
}


Creación de Directorio en la “PDB dev2db” para operación de “Import”
SQL>CREATE DIRECTORY "IMP_DATA_PUMP_DIR" AS '/orabkup/dbtest1/dpdump/';

    
“Import full” en el cual comprobaremos la funcionalidad objeto del articulo. Para el caso presente renombraremos el “Tablespace” “SOE” a “SOE_DATA” para ejemplificar que a través de esta actividad es oportunidad ideal para renombrar “Tablespaces” si asi fuese deseado.
$/orabase/product/12.1.0/db_1/bin/impdp  \'sys/temp1234@"
(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = alpddbs002)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dev2db)(INSTANCE_NAME=testdbs)))" 
AS SYSDBA\'  full=y dumpfile=datapump_dev2db.dmp DIRECTORY=IMP_DATA_PUMP_DIR 
LOGFILE=import_datapump_dev2db.log VERSION=12 TRANSPORT_DATAFILES=+DG01/dev2db/
soe_data_1,+DG01/dev2db/users_data_1 job_name=imp_dev2db parallel=2 
REMAP_TABLESPACE='SOE':'SOE_DATA'

“Feedback” en el “Alert log” donde se visualiza el “plugging” de los “Tablespaces” transportados:
  • “SOE_DATA”
  • “USERS”

Nos conectamos a la “PDB dev2db” y visualizamos el resultado del transporte realizado enteramente a través de las siguientes pantallas



Y con esto hemos realizado un “Upgrade” con la nueva característica “Full Transportable Export/Import”.

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )

Por Joel Pérez y Mahir M. Quluzade (OCP)
Publicado en Enero 2014
Indice
1. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
2. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )
3. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )
4. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )

Iniciemos esta tercera parte…
Reconocimiento de BBDD origen “ldb11g” ( version 11.2.0.3 ) y creación de “Tablespace” con “Data” de aplicación
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb11g
[oracle@oel62-x64 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 29 11:05:56 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select banner from v$version;  

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE	11.2.0.3.0	Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL> 
SQL> select name from v$tablespace;

NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
USERS
TEMP

SQL> select name from  v$datafile; 

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/ldb11g/system01.dbf
/u01/app/oracle/oradata/ldb11g/sysaux01.dbf
/u01/app/oracle/oradata/ldb11g/undotbs01.dbf
/u01/app/oracle/oradata/ldb11g/users01.dbf

SQL>  
SQL> create tablespace APPDATA1 datafile '/u01/app/oracle/oradata/ldb11g/appdata101.dbf' 
size 10M autoextend  on next 10M;

Tablespace created.

SQL> alter tablespace APPDATA1 add datafile '/u01/app/oracle/oradata/ldb11g/appdata102.dbf' 
size 10M autoextend on next 10M;

Tablespace altered.

SQL> create user user1 identified by  user1
    2  default tablespace appdata1
    3  quota unlimited on appdata1; 

User created.

SQL> grant create session, resource, dba to user1;

Grant succeeded.

SQL> create or replace directory UPGDIR as '/tmp/upgrade';

Directory created.

SQL> connect user1/user1 
Connected.
SQL> 
SQL> create table t (n number);

Table created.

SQL> insert into t values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from t; 

	 N
-------------------------------
	 1

    
Reconocimiento de la BBDD destino, la cual se encuentra en version “12c” con “Tablespaces” y estructura por defecto.
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb12c
[oracle@oel62-x64 ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 29 11:12:26 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> select cdb, name from v$database;

CDB NAME
--- ---------
NO  LDB12C

SQL> select banner from  v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE	12.1.0.1.0	Production
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production

SQL> select name from v$tablespace;

NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
USERS
TEMP

    
Establecimiento de “Tablespaces” con “Data” de aplicación en modo “Read-Only”. Para el presente caso solo tenemos un solo “Tablespace” con datos de aplicación
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb11g
[oracle@oel62-x64 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 29 11:16:13 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter tablespace APPDATA1 read only;

Tablespace altered.

    
Ejecución de “Export full” de la base de datos origen excluyendo elementos que pudieran generar conflictos en el transporte de datos al destino. Para el presente caso excluiremos el “Tablespace Users” el cual comúnmente conforma parte de los “Tablespaces” por defecto de una base de datos y el schema “APEX_030200” el cual fui incluido en este ejemplo solo para dar una muestra extendida del concepto de excluir elementos en el proceso. La combinación de parámetros clave para la utilizar la nueva característica “Full Transportable Export/Import” son los siguientes:
“FULL=Y TRANSPORTABLE=ALWAYS VERSION=12”
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb11g
[oracle@oel62-x64 ~]$ expdp directory=UPGDIR dumpfile=appdata1_dump.dmp logfile=appdata1_exp.log full=Y 
transportable=always version=12 exclude=TABLESPACE:\"= \'USERS\'\" 
exclude=SCHEMA:\"= \'APEX_030200\'\" 

Export: Release 11.2.0.3.0 - Production on Mon Jul 29 11:57:53 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Username: system
Password: 

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_FULL_01":  system/******** directory=UPGDIR dumpfile=appdata1_dump.dmp 
logfile=appdata1_exp.log full=Y transportable=always version=12 exclude=TABLESPACE:"= exclude= exclude
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/PLUGTS_FULL/FULL/PLUGTS_TABLESPACE
Processing object type DATABASE_EXPORT/PLUGTS_FULL/PLUGTS_BLK
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/TABLE_DATA
Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA
…

. . exported "SYSTEM"."REPCAT$_TEMPLATE_TARGETS"             0 KB       0 rows
. . exported "SYSTEM"."REPCAT$_USER_AUTHORIZATIONS"          0 KB       0 rows
. . exported "SYSTEM"."REPCAT$_USER_PARM_VALUES"             0 KB       0 rows
. . exported "SYSTEM"."SQLPLUS_PRODUCT_PROFILE"              0 KB       0 rows
Master table "SYSTEM"."SYS_EXPORT_FULL_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_FULL_01 is:
  /tmp/upgrade/appdata1_dump.dmp
******************************************************************************
Datafiles required for transportable tablespace APPDATA1:
  /u01/app/oracle/oradata/ldb11g/appdata102.dbf
  /u01/app/oracle/oradata/ldb11g/appdata101.dbf
Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at 12:02:59

    
Copia de “Datafiles” a la locación destino:
[oracle@oel62-x64 ~]$ cd /u01/app/oracle/oradata/ldb11g/
[oracle@oel62-x64 ldb11g]$ ls -l
total 1644340
-rw-r----- 1 oracle oinstall  10493952 Jul 29 11:16 appdata101.dbf
-rw-r----- 1 oracle oinstall  10493952 Jul 29 11:16 appdata102.dbf
-rw-r----- 1 oracle oinstall   9748480 Jul 29 12:31 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Jul 29 11:23 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Jul 29 12:00 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Jul 29 12:31 redo03.log
-rw-r----- 1 oracle oinstall 587210752 Jul 29 12:31 sysaux01.dbf
-rw-r----- 1 oracle oinstall 807411712 Jul 29 12:31 system01.dbf
-rw-r----- 1 oracle oinstall  39854080 Jul 29 12:19 temp01.dbf
-rw-r----- 1 oracle oinstall  94380032 Jul 29 12:31 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Jul 29 12:06 users01.dbf
[oracle@oel62-x64 ldb11g]$ cp appdata* $ORACLE_BASE/oradata/ldb12c
[oracle@oel62-x64 ldb11g]$ cd ../ldb12c/
[oracle@oel62-x64 ldb12c]$ ls -l
total 1969732
-rw-r----- 1 oracle oinstall  10493952 Jul 29 12:32 appdata101.dbf
-rw-r----- 1 oracle oinstall  10493952 Jul 29 12:32 appdata102.dbf
-rw-r----- 1 oracle oinstall  10043392 Jul 29 12:32 control01.ctl
-rw-r----- 1 oracle oinstall  52429312 Jul 29 12:23 redo01.log
-rw-r----- 1 oracle oinstall  52429312 Jul 29 12:30 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Jul 29 12:23 redo03.log
-rw-r----- 1 oracle oinstall 765468672 Jul 29 12:30 sysaux01.dbf
-rw-r----- 1 oracle oinstall 817897472 Jul 29 12:30 system01.dbf
-rw-r----- 1 oracle oinstall  91234304 Jul 29 12:30 temp01.dbf
-rw-r----- 1 oracle oinstall 162537472 Jul 29 12:28 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Jul 29 12:23 users01.dbf
[oracle@oel62-x64 ldb12c]$ 

    
Creación de directorio en la base de datos destino e “Import” full. Los errores reportados al final de proceso se debe a la coincidencia de objetos del diccionario de datos pero no representan errores que conlleven a una incorrecta ejecución del proceso.
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb12c
[oracle@oel62-x64 ~]$ impdp full=Y directory=UPGDIR dumpfile=appdata1_dump.dmp 
logfile=appdata1_imp.log transport_datafiles='/u01/app/oracle/oradata/ldb12c/appdata101.dbf',
'/u01/app/oracle/oradata/ldb12c/appdata102.dbf'

Import: Release 12.1.0.1.0 - Production on Mon Jul 29 12:33:08 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

Username: system 
Password: 

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01":  system/******** full=Y directory=UPGDIR 
dumpfile=appdata1_dump.dmp logfile=appdata1_imp.log transport_datafiles=/u01/app/oracle/
oradata/ldb12c/appdata101.dbf,/u01/app/oracle/oradata/ldb12c/appdata102.dbf 
Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/PRE_INSTANCE_IMPCALLOUT/MARKER
Processing object type DATABASE_EXPORT/PLUGTS_FULL/PLUGTS_BLK
Processing object type DATABASE_EXPORT/TABLESPACE
ORA-31684: Object type TABLESPACE:"UNDOTBS1" already exists
ORA-31684: Object type TABLESPACE:"TEMP" already exists
Processing object type DATABASE_EXPORT/PROFILE
Processing object type DATABASE_EXPORT/SYS_USER/USER
Processing object type DATABASE_EXPORT/SCHEMA/USER
ORA-31684: Object type USER:"OUTLN" already exists
ORA-31684: Object type USER:"ORDDATA" already exists
ORA-31684: Object type USER:"OLAPSYS" already exists
ORA-31684: Object type USER:"MDDATA" already exists
ORA-31684: Object type USER:"SPATIAL_WFS_ADMIN_USR" already exists
ORA-31684: Object type USER:"SPATIAL_CSW_ADMIN_USR" already exists
ORA-31684: Object type USER:"FLOWS_FILES" already exists
ORA-31684: Object type USER:"APEX_PUBLIC_USER" already exists
ORA-31684: Object type USER:"SCOTT" already exists
Processing object type DATABASE_EXPORT/ROLE
ORA-31684: Object type ROLE:"SELECT_CATALOG_ROLE" already exists
ORA-31684: Object type ROLE:"EXECUTE_CATALOG_ROLE" already exists
ORA-31684: Object type ROLE:"DELETE_CATALOG_ROLE" already exists
ORA-31684: Object type ROLE:"DBFS_ROLE" already exists
ORA-31684: Object type ROLE:"AQ_ADMINISTRATOR_ROLE" already exists
ORA-31684: Object type ROLE:"AQ_USER_ROLE" already exists
ORA-31684: Object type ROLE:"ADM_PARALLEL_EXECUTE_TASK" already exists
ORA-31684: Object type ROLE:"GATHER_SYSTEM_STATISTICS" already exists
ORA-31684: Object type ROLE:"RECOVERY_CATALOG_OWNER" already exists
ORA-31684: Object type ROLE:"SCHEDULER_ADMIN" already exists
ORA-31684: Object type ROLE:"HS_ADMIN_SELECT_ROLE" already exists
ORA-31684: Object type ROLE:"HS_ADMIN_EXECUTE_ROLE" already exists
ORA-31684: Object type ROLE:"HS_ADMIN_ROLE" already exists
ORA-31684: Object type ROLE:"GLOBAL_AQ_USER_ROLE" already exists
ORA-31684: Object type ROLE:"OEM_ADVISOR" already exists
ORA-31684: Object type ROLE:"OEM_MONITOR" already exists
ORA-31684: Object type ROLE:"WM_ADMIN_ROLE" already exists
ORA-31684: Object type ROLE:"JAVAUSERPRIV" already exists
ORA-31684: Object type ROLE:"JAVAIDPRIV" already exists
ORA-31684: Object type ROLE:"JAVASYSPRIV" already exists
ORA-31684: Object type ROLE:"JAVADEBUGPRIV" already exists
ORA-31684: Object type ROLE:"EJBCLIENT" already exists
ORA-31684: Object type ROLE:"JMXSERVER" already exists
ORA-31684: Object type ROLE:"JAVA_ADMIN" already exists
ORA-31684: Object type ROLE:"JAVA_DEPLOY" already exists
ORA-31684: Object type ROLE:"CTXAPP" already exists
ORA-31684: Object type ROLE:"XDBADMIN" already exists
ORA-31684: Object type ROLE:"XDB_SET_INVOKER" already exists
ORA-31684: Object type ROLE:"AUTHENTICATEDUSER" already exists
ORA-31684: Object type ROLE:"XDB_WEBSERVICES" already exists
ORA-31684: Object type ROLE:"XDB_WEBSERVICES_WITH_PUBLIC" already exists
ORA-31684: Object type ROLE:"XDB_WEBSERVICES_OVER_HTTP" already exists
ORA-31684: Object type ROLE:"ORDADMIN" already exists
ORA-31684: Object type ROLE:"OLAP_XS_ADMIN" already exists
ORA-31684: Object type ROLE:"OLAP_DBA" already exists
ORA-31684: Object type ROLE:"OLAP_USER" already exists
ORA-31684: Object type ROLE:"SPATIAL_WFS_ADMIN" already exists
ORA-31684: Object type ROLE:"WFS_USR_ROLE" already exists
ORA-31684: Object type ROLE:"SPATIAL_CSW_ADMIN" already exists
ORA-31684: Object type ROLE:"CSW_USR_ROLE" already exists
ORA-31684: Object type ROLE:"APEX_ADMINISTRATOR_ROLE" already exists
Processing object type DATABASE_EXPORT/GRANT/SYSTEM_GRANT/PROC_SYSTEM_GRANT
…

ORA-39082: Object type PACKAGE BODY:"SYSMAN"."MGMT_TARGET_UPDATE" created with compilation warnings
ORA-39082: Object type PACKAGE BODY:"SYSMAN"."MGMT_TIME_SYNC" created with compilation warnings
ORA-39082: Object type PACKAGE BODY:"SYSMAN"."MGMT_USER" created with compilation warnings
ORA-39082: Object type PACKAGE BODY:"SYSMAN"."MGMT_VIEW_PRIV" created with compilation warnings
ORA-39082: Object type TRIGGER:"SYSMAN"."MGMT_CREDS_INS_UPD" created with compilation warnings
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 515 error(s) at Mon Jul 29 12:50:50 2013 
elapsed 0 00:17:31

    
Chequeo final de los datos de aplicacion
[oracle@oel62-x64 ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome
[oracle@oel62-x64 ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@oel62-x64 ~]$ export ORACLE_SID=ldb12c
[oracle@oel62-x64 ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 29 12:55:34 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> connect user1/user1
Connected.

SQL> select *  from t;

	 N
-------------------------------
	 1

SQL>

    
Si se desease realizar el mismo procedimiento entre plataformas distintas lo único que habría que adicionar al procedimiento expuesto es convertir los “Datafiles” a la plataforma destino antes de realizar el “Full Import”. La conversión se puede realizar en el origen o destino. Este seria un ejemplo de cómo podríamos convertir los “Datafiles” en el destino:
[oracle@oel62-ora12c ~]$ export ORACLE_SID=ldb12c2
[oracle@oel62-ora12c ~]$ rman

Recovery Manager: Release 12.1.0.1.0 - Production on Mon Jul 29 14:01:18 2013

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

RMAN> connect target "sys as sysbackup";

target database Password: 
connected to target database: LDB12C2 (DBID=3477471046)

RMAN> CONVERT DATAFILE 
     2>	'/tmp/Upgrade2/APPDATA201.DBF', 
     3>	'/tmp/Upgrade2/APPDATA202.DBF' 
     4> DB_FILE_NAME_CONVERT 
     5> '/tmp/Upgrade2','/u01/app/oracle/oradata/ldb12c2'
     6> FROM PLATFORM 'Microsoft Windows x86 64-bit';

Starting conversion at target at 29-JUL-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting datafile conversion
input file name=/tmp/Upgrade2/APPDATA201.DBF
converted datafile=/u01/app/oracle/oradata/ldb12c2/APPDATA201.DBF
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile conversion
input file name=/tmp/Upgrade2/APPDATA202.DBF
converted datafile=/u01/app/oracle/oradata/ldb12c2/APPDATA202.DBF
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
Finished conversion at target at 29-JUL-13

    
De esta manera hemos probado la funcionalidad de la nueva característica: “Full Transportable Export/Import”

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )

Por Joel Pérez y Wissem El Khlifi
Publicado en enero 2014
Indice
1. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
2. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )
3. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )
4. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )

...Una vez que poseemos el “Backup” de la base de datos, iniciemos por establecer un directorio en el cual coloquemos los “scripts” de “Pre-Upgrade”. Tal como se puede apreciar, los scripts “preupgrd.sql” & “utluppkg.sql” son provenientes del “Home Oracle Database 12c”
$ mkdir -p /home/oracle/forupgrading
$ cp /u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/preupgrd.sql 
  /home/oracle/forupgrading
$ cp /u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/utluppkg.sql 
  /home/oracle/forupgrading

Ejecución de “script preupgrd.sql”. Nótese la generación de los siguientes archivos:

  • “Log”:  preupgrade.log
  • “Pre-Upgrade Fixups Script”:  preupgrade_fixups.sql
  • “Post Upgrade Fixups Script”:  postupgrade_fixups.sql
$ export ORACLE_SID=tst11g
$ ORAENV_ASK=NO
$ . oraenv
$ ORAENV_ASK=YES
$ cd /home/oracle/forupgrading
$ sqlplus / as sysdba

SQL> @preupgrd.sql
Loading Pre-Upgrade Package...
Executing Pre-Upgrade Checks...
Pre-Upgrade Checks Complete.
      ************************************************************

Results of the checks are located at:
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade.log

Pre-Upgrade Fixup Script (run in source database environment):
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade_fixups.sql

Post-Upgrade Fixup Script (run shortly after upgrade):
 /u01/app/oracle/cfgtoollogs/tst11g/preupgrade/postupgrade_fixups.sql

      ************************************************************

         Fixup scripts must be reviewed prior to being executed.

      ************************************************************

      ************************************************************
                   ====>> USER ACTION REQUIRED  <<====
      ************************************************************

 The following are *** ERROR LEVEL CONDITIONS *** that must be addressed
                    prior to attempting your upgrade.
            Failure to do so will result in a failed upgrade.

           You MUST resolve the above errors prior to upgrade

      ************************************************************

SQL>

    
Ejecución del “Script” generado:  preupgrade_fixups.sql  el cual emite recomendaciones para un exitoso y rápido “Upgrade”
SQL> @/u01/app/oracle/cfgtoollogs/tst11g/preupgrade/preupgrade_fixups.sql
Pre-Upgrade Fixup Script Generated on 2013-07-24 15:00:32  Version: 12.1.0.1 Build: 006
Beginning Pre-Upgrade Fixups...

PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     DEFAULT_PROCESS_COUNT
Check Summary: Verify min process count is not too low
Fix Summary:   Review and increase if needed, your PROCESSES value.
**********************************************************************
Fixup Returned Information:
WARNING: --> Process Count may be too low

     Database has a maximum process count of 150 which is lower than the
     default value of 300 for this release.
     You should update your processes value prior to the upgrade
     to a value of at least 300.
     For example:
        ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
     or update your init.ora file.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     EM_PRESENT
Check Summary: Check if Enterprise Manager is present
Fix Summary:   Execute emremove.sql prior to upgrade.
**********************************************************************
Fixup Returned Information:
WARNING: --> Enterprise Manager Database Control repository found in the database

     In Oracle Database 12c, Database Control is removed during
     the upgrade. To save time during the Upgrade, this action
     can be done prior to upgrading using the following steps after
     copying rdbms/admin/emremove.sql from the new Oracle home
   - Stop EM Database Control:
    $> emctl stop dbconsole

   - Connect to the Database using the SYS account AS SYSDBA:

   SET ECHO ON;
   SET SERVEROUTPUT ON;
   @emremove.sql
     Without the set echo and serveroutput commands you will not
     be able to follow the progress of the script.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     DBMS_LDAP_DEPENDENCIES_EXIST
Check Summary: Check for dependency on DBMS_LDAP package
Fix Summary:   Network Objects must be reviewed manually.
**********************************************************************
Fixup Returned Information:
WARNING: --> Existing DBMS_LDAP dependent objects

     Database contains schemas with objects dependent on DBMS_LDAP package.
     Refer to the Upgrade Guide for instructions to configure Network ACLs.
     USER APEX_030200 has dependent objects.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
Check Tag:     AMD_EXISTS
Check Summary: Check to see if AMD is present in the database
Fix Summary:   Manually execute ORACLE_HOME/oraolap/admin/catnoamd.sql 
script to remove OLAP.
**********************************************************************
Fixup Returned Information:
INFORMATION: --> OLAP Catalog(AMD) exists in database

     Starting with Oracle Database 12c, OLAP is desupported.
     If you are not using the OLAP Catalog component and want
     to remove it, then execute the
     ORACLE_HOME/oraolap/admin/catnoamd.sql script before or
     after the upgrade.
**********************************************************************


PL/SQL procedure successfully completed.


**********************************************************************
                      [Pre-Upgrade Recommendations]
**********************************************************************


PL/SQL procedure successfully completed.

                        *****************************************
                        ********* Dictionary Statistics *********
                        *****************************************

Please gather dictionary statistics 24 hours prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
    EXECUTE dbms_stats.gather_dictionary_stats;

^^^ MANUAL ACTION SUGGESTED ^^^


PL/SQL procedure successfully completed.


           **************************************************
                ************* Fixup Summary ************

 4 fixup routines generated INFORMATIONAL messages that should be reviewed.


PL/SQL procedure successfully completed.

**************** Pre-Upgrade Fixup Script Complete *********************

PL/SQL procedure successfully completed.

SQL>

    
Cambios sugeridos:
ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE;

SET ECHO ON;
SET SERVEROUTPUT ON;
-- emremove.sql scrip located in the 12c home.
@/u01/app/oracle/product/12.1.0.1/db_1/rdbms/admin/emremove.sql

-- Removing this before the upgrade will result in the errors shown below.
-- These errors are not show-stoppers, but if you want a cleaner run through,
-- remove this feature after the upgrade.
@?/olap/admin/catnoamd.sql

EXECUTE dbms_stats.gather_dictionary_stats;

-- Shutdown the database.
SHUTDOWN IMMEDIATE;

Copia del archivo de parámetro y “passwordfile” al nuevo “Home 12c”
$ cp /u01/app/oracle/product/11.2.0.3/db_1/dbs/spfiletst11g.ora 
/u01/app/oracle/product/12.1.0.1/db_1/dbs
$ cp /u01/app/oracle/product/11.2.0.3/db_1/dbs/orapwtst11g 
/u01/app/oracle/product/12.1.0.1/db_1/dbs

    
Editar archivo “/etc/oratab” para realizar el cambio en la referencia del home de la base de datos
tst11g:/u01/app/oracle/product/12.1.0.1/db_1:Y

    
“Startup” de la base de datos en modo “Upgrade”
$ sqlplus / as sysdba

SQL> STARTUP UPGRADE;
SQL> EXIT;

    
Ejecución del “Parallel Upgrade Utility”
$ cd $ORACLE_HOME/rdbms/admin
$ $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql

    
Una vez ejecutado el “Parallel Upgrade Utility”, verifiquemos el resumen de la actividad
$ sqlplus / as sysdba

SQL> STARTUP;
SQL> @utlu121s.sql
.
Oracle Database 12.1 Post-Upgrade Status Tool           07-24-2013 17:24:18
.
Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS
.
Oracle Server
.                                      UPGRADED      12.1.0.1.0  00:16:48
JServer JAVA Virtual Machine
.                                         VALID      12.1.0.1.0  00:04:47
Oracle Workspace Manager
.                                         VALID      12.1.0.1.0  00:01:17
OLAP Analytic Workspace
.                                         VALID      12.1.0.1.0  00:00:53
.                                         VALID      12.1.0.1.0  00:00:46
Oracle XDK
.                                         VALID      12.1.0.1.0  00:00:48
Oracle Text
.                                         VALID      12.1.0.1.0  00:01:07
Oracle XML Database
.                                         VALID      12.1.0.1.0  00:04:35
Oracle Database Java Packages
.                                         VALID      12.1.0.1.0  00:00:22
Oracle Multimedia
.                                         VALID      12.1.0.1.0  00:02:42
Spatial
.                                         VALID      12.1.0.1.0  00:06:21
Oracle Application Express
.                                         VALID     4.2.0.00.27  00:25:28
Final Actions
.                                                                00:02:47
Total Upgrade Time: 01:09:24

PL/SQL procedure successfully completed.

SQL>

    
Ejecución del “script catuppst.sql” para determinar si hubiese que realizar un “fix” posterior. La ejecución del mismo generara contenido de “fixes” a realizarse en el archivo “postupgrade_fixups.sql”
SQL> @catuppst.sql

    
Ejecutar el mismo si tuviese recomendaciones
SQL> @/u01/app/oracle/cfgtoollogs/tst11g/preupgrade/postupgrade_fixups.sql

    
Representa una buena práctica y asegurado de resultados la ejecución de los siguientes “scripts”
-- The following item is probably included in your postupgrade_fixups.sql script.
EXECUTE DBMS_STATS.gather_fixed_objects_stats;

-- Recompile invalid objects.
@utlrp.sql

-- Check for newly invalid objects.
@utluiobj.sql

-- Run again to check the final outcome of the upgrade.
@utlu121s.sql

Arribados a este punto ya tenemos nuestra base de datos actualizada en versión “12.1.0.1.0”
$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Wed Jul 26 12:34:56 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> SELECT name, open_mode FROM v$database;

NAME      OPEN_MODE
--------- --------------------
TST11G      READ WRITE

SQL>

    
Conclusión
Llegados a este punto la BBDD estaría actualizada a la nueva versión “12c” y lista para su uso. El “Upgrade” a través del “Command-line Upgrade Utility” es un proceso no complejo. Se puede llevar a cabo para escenarios donde ambos manejadores se encuentren en el mismo “Hardware Server” o separados. Para este escenario se recomienda:
  • Duplicar la BBDD de producción en el mismo servidor de producción a través de alguno de los tantos métodos de duplicación de BBDD Oracle. Es altamente recomendable utilizar un método de duplicado físico tales como: “RMAN Duplicate” u otros de manera de tener una copia de la BBDD con la misma distribución física respecto a la BBDD de producción (  distribución bloque a bloque ).
  • La actividad de “Upgrade” implicara un “Application Downtime” que estará basado en diversos factores, entre los cuales uno de los mas importantes es el rendimiento del “Hardware Server” ( CPU, Memoria, etc ) donde se realizara la actividad, por lo tanto no hay mejor “Hardware Server” ideal para realizar estas pre-pruebas de “Upgrade” mas que en el mismo servidor donde se realizara la actividad real de “Upgrade”, a excepción de si se poseen servidores con soluciones “Data Guard Server” o “Manual Standby Server” ( leer detalles de este punto en el penúltimo “ítem” ). Esto ( el duplicado de BBDD de producción “in site” )  pudiera conllevar riesgos con respecto a la BBDD de producción si el “DBA” no posee alta experiencia en Duplicados de BBDD en un mismo servidor. Muchos clientes optan por solicitar un servidor con las mismas características o cualquier solución que les conlleve a no trabajar directamente en el servidor de producción y tener el resultado lo mas parecido posible a cuando se realice la actividad directamente en producción. En dado caso se estaría incurriendo en un precio de gestión paralela por no poseer en el “task” manos expertas para ello.
  • Muchas empresas optan por realizar los ejercicios de “Upgrade” en el o los servidores con soluciones “Data Guard” o “Manual Standby”. Si el servidor a ser utilizado posee las mismas características del servidor de producción estaría justificable la estrategia o inclusive el “Upgrade” real se podría realizar en estos servidores mencionados “Data Guard Server” o “Manual Standby Server”. Esto ofrece una gran ventaja ya que el procedimiento no se realizara directamente sobre la BBDD origen de producción sino en una copia físicamente igual con inclusive el mismo nombre. Una de las principales ventajas esta basada en que si el “Upgrade” obtuviera algún problema de ejecución, la actividad podría ser pospuesta pero la BBDD original estaría intacta por lo tanto se podrían restablecer las operaciones de producción de forma inmediata.
  • Es aconsejable que siempre se persigan los siguientes objetivos:
    • Realizar las actividades de “Upgrade” en el o los servidor(es) reales donde se llevara a cabo finalmente la actividad para tener la certeza de los tiempos esperados para el momento del “Upgrade” real
    • Trazar una estrategia en la cual se resguarde al 100% la BBDD de producción
    • Trazar una estrategia en la cual la BBDD de producción pueda retornar a sus actividades de forma casi inmediata en caso de que el proceso de “Upgrade” real llegara a fallar
    • Y por supuesto realizar todo tipo de pruebas de funcionalidad y rendimiento con una base de datos piloto actualizada a la nueva versión antes de llevar a cabo el “Upgrade” real de producción
  • En líneas generales, el “DBA” siempre debe trazar estrategias para escenarios satisfactorios o no satisfactorios en la actividad, de manera de garantizar el servicio del cliente en la versión superior u original.

Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )


Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )

Por Joel Pérez & Wissem El Khlifi
Publicado en diciembre 2013
Indice
1. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte I )
2. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte II )
3. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte III )
4. Oracle Database 12c: “Upgrade” a “Oracle Database 12c” ( Parte IV )
“Database12c” la nueva versión de manejador de base de datos de “Oracle Corporation”, nosotros los tecnólogos Oracle nos preguntábamos “que mas…” podría Oracle adicionar como nuevas características?, de que forma Oracle nos iba a sorprender esta vez y como siempre, las nuevas características y nueva arquitectura no solo nos sorprenden sino que una vez mas nos llevan a otra era…, “Cloud Computing”…
Personalmente he tenido la oportunidad de trabajar con tecnología Oracle como DBA desde su versión 8. “8”i la era del internet, “9i” la era del internet con mayores elementos, recuerdo que uno de los componentes de mayor importancia fue la presentación de RAC9i “la era naciente de RAC…”, “10g” nos sorprendió con el concepto de ASM… y filosofía “Grid Computing”, 11g & 11g R2 sobre todo por sus mejoras de alto nivel relacionadas con RAC & Data Guard…, 12c… Cloud Computing, nuevas características… mas de 500 las cuales iremos cubriendo gradualmente a través de artículos y otros elementos de ayuda.
“Upgrade”… para mi Joel Pérez en conjunto con Wissem El Khlifi es un tanto difícil iniciar esta serie de artículos de “Upgrade” ya que esta afamada tarea posee tantas posibles direcciones, alternativas, herramientas, modos de aplicación, etc… que tuvimos que sentarnos un preciado momento en Barcelona,España para organizar como íbamos a desplegar tanto información en la menor cantidad de artículos posible.
Entremos en materia... bien podríamos afirmar que la historia de las probidades, flexibilidades y alternativas de “Upgrades” de base de datos ( BBDDs ) Oracle ha ido en aumento a través de sus versiones. Sin embargo existe un hito muy particular que dista a “Oracle Database 12c” de las versiones anteriores y son las posibilidades de gran alcance que ahora posee el manejador para operaciones de tipo “Cross-Platform” en general: Transporte de Tablespaces, Datafiles & Bases de Datos. Las alternativas de “Upgrade” a partir de “Oracle Database 12c” son mayores lo cual impacta positivamente en los clientes que desean realizar “Upgrade” de sus bases de datos sin el mayor impacto posible en sus actividades de negocios.
Si la escogencia de “paths” de “Upgrade” antes se podría haber considerado una caja de 1000 caminos ahora hay que adicionar unos 500 mas debido a que a partir de “Oracle Database 12c” no solo tenemos que pensar en el “Path” y modo de “Upgrade” sino también escoger a que nueva arquitectura iremos: Non-CDB ( “Non-Container Database” ) o PDB ( “Pluggable Database” ). Los conceptos de ambas podrán ser mayormente aclarados en nuestro articulo: Oracle Database 12c: “Oracle Multitenant” ( Parte I ). Uno de los principalmente beneficiados en todo este proceso es el cliente, ya que el “Software” & Compania “Oracle” ha colocado en disponibilidad una vez mas un “Release” lleno de nuevas alternativas para hacer que la administración de una base de datos “Oracle” sea mas un placer que un requisito del mercado de tener lo mejor de lo mejor en manejador de BBDD.
La pregunta de los clientes siempre es basada en: “Upgrade” o no “Upgrade”…?, podríamos escribir miles de líneas al respecto pero uno de los motivos mas importantes y decisivos por lo cuales los clientes siempre deciden llevar a cabo el “Upgrade” de sus bases de datos a una nueva versión es para poder contar con las nuevas características, “Oracle Database 12c” incluye excelentes nuevos”Features” como: “Oracle Multitenant Option”, “Oracle Active Data Guard Far Sync”, mejoras en “Information Lifecycle Management”, nuevos tipos de datos y mas.
Nota: La palabra que utilizaremos a lo largo del artículo para referirnos a “Upgrade” es “Upgrade” mas no la palabra “Migracion” aunque parecen términos sinónimos, realmente en contexto “Oracle” no lo es. La palabra “Migracion” es utilizada en contexto “Oracle” para el movimiento de datos de una base de datos No-Oracle a una BBDD Oracle. Más cuando nos referimos a “Upgrade”, lo estamos realizando en un contexto de movimiento de datos de BBDDs “Oracle” a BBDDs “Oracle”.
“Database Upgrade”: el acto de llevar a cabo “Upgrades” en bases de datos “Oracle” envuelve una actividad de modificar el diccionario de datos para que el mismo sea compatible con la versión del “Oracle Database Software”. Las típicas acciones que pueden ser parte de un “Oracle Database Upgrade” son las siguientes:
  • Adicionado, Borrado o modificación de columnas en tablas y vistas de “System”
  • Creación de nuevos “Packages” o “Procedures”
  • Modificación de “Packages” o “Procedures” de “System” existentes
  • Creación, Modificación o borrado de usuarios de bases de datos, roles y privilegios
  • Y modificación de “Data” particular utilizada por los “Oracle Database Components”
Todas y cada una de estas acciones afectan el diccionario de datos de la BBDD. La modificación de estos objetos no conlleva modificación de código o datos de aplicación mas si la validez de “PL/SQL Program Units” los cuales obtienen des compilación cuando se modifica el diccionario de datos. Dentro de los scripts de cambio del diccionario de datos también se encuentra un extracto que recompila los “PL/SQL Program Units” de aplicación.
“Multitenant Arquitecture”: es la nueva opción para “Oracle Database 12c Enterprise Edition” la cual ayuda a los clientes a reducir costos en el área de “IT” a través de la simplificación, consolidación, aprovisionamiento, “Upgrades” y mas. La nueva arquitectura esta basada en una base de datos “Container” la cual puede albergar muchas BBDDs ( Bases de Datos ) denominadas “Plugaggable Databases”. La arquitectura “Oracle Multitenant” es escalable y aplicable de forma total a soluciones ya conocidas como “RAC ( Oracle Real Application Clusters )” & “Oracle Data Guard”. Una simple BBDD no “Pluggable Database” o bien llamada “Non-CDB” ( “Non Container Database” ) puede ser convertida fácilmente a una BBDD “Pluggable Database” sin afectar su contenido, operación y manejo para las aplicaciones relacionadas con la misma.
En el contexto de “Upgrade”, establecerse en “Oracle Database 12c” bajo esta arquitectura puede conllevar una serie de pasos adicionales los cuales estaremos detallando de forma practica a través de estos artículos.
Selección de un Método: la selección del método es el tramo mas complejo en todo proyecto de “Upgrade”; personalmente el “task” que mayormente llevo a cabo a nivel Internacional, es llevar a cabo “Upgrades”. En la red podemos acceder a la técnica de todos los métodos existentes ( “DBUA: Database Upgrade Assistant”, “Manual Rolling Upgrade”, “Export/Import”, “Oracle Golden Gate”, “Oracle Streams”… y mas… ) sin embargo la escogencia de un método exige conocer muy bien las prestaciones, ventajas y desventajas de cada uno de ellos, en base a experiencia real lo cual conlleva a que el “DBA” tendrá que poseer un “Expertise” bastante amplio en este tipo de tarea para la escogencia del método ideal sin necesidad de realizar la mas mínima prueba en el cliente y/o proyectar las vías alternas en caso de los recursos provean mas bajo rendimiento del promedio esperado. Se consideran “ítems” como los siguientes
  • La escogencia inicia principalmente por el conocimiento del “Downtime” requerido por el cliente
  • Análisis de versión origen y destino, nivel de “patch sets”
  • Análisis de “Endian Formats” de plataformas origen y destino
  • Posible planificación de cambio en: ‘Character sets”, “Partitioning”, “Encryption”, “Compression”…
  • Conocimiento si la técnica a utilizar se vera beneficiada por el uso de paralelismo si el cliente posee licencia “Enterprise Edition”
  • Recursos de los equipos ( Red, Disco, Memoria )
  • Arquitectura de “Backups” en la compañía ( Disco, Cintas, etc… )
  • Tipo de Licencia
  • Tamaño de la base de datos
  • Cuando se escogen métodos lógicos, la naturaleza interna de los objetos de la base de datos
  • Escogencia de la arquitectura final: Non-CDB ( “Non-Container Database” o “PDB” ( “Pluggable Database” )
Y podría seguir una lista de mas 100 “ítems” a escoger, un “Upgrade” es una tarea que requiere de un alto nivel de análisis y “Expertise sobretodo si el mismo se desea realizar en modo “Zero Downtime”…
Siempre expreso en mis conferencias que realizar un “Upgrade” es similar a realizar un traje a la medida: no hay cuerpos iguales ni bases de datos tampoco… todas tienen características únicas que la definen: “ítems” internos, criticidad de negocio, etc..
“Advice”: Como experto, aconsejo a las empresas, jamás dejar en manos no-expertas la responsabilidad de un “Upgrade” de BBDD…
“Upgrade” Directo a “Oracle Database 12c”: un “Upgrade” directo es aquel que es realizado a través de “DBUA” o por línea de comando haciendo uso de los “scripts” de “pre” y “post” “Upgrade”. Los “scripts” de “pre” y “post” “Upgrade” es el fundamento de técnicas de alto nivel como “Manual/Data Guard Rolling Upgrade” y otras. El “Upgrade” directo es soportado bajo las siguientes condiciones de versión del origen:
  • Es soportado para versiones iguales o mayores a 11.2.0.2
  • Para 11.2.0.1 habría que aplicar “Patch” al manejador para ir a 11.2.0.2 o superior o si no desea aplicar “Patch” al manejador se tendría que escoger otro método
  • Es soportado para versión igual a 11.1.0.7
  • Para 11.1.0.6 habría que aplicar “Patch” al manejador para ir a 11.1.0.7. Si no desea aplicar “Patch” al manejador se tendría que escoger otro método
  • Es soportado para versión igual a 10.2.0.5
  • Para 10.2.0.4 habría que aplicar “Patch” al manejador para ir a 10.2.0.5. Si no desea aplicar “Patch” al manejador se tendría que escoger otro método
  • Para todas las versiones “9i” se tendría que utilizar otro método o aplicar “Patch” para ir a una versión directa permitida como: “10.2.0.5”, “11.1.0.7” o “11.2.0.2”
A continuación presentaremos 2 cuadros para visualizar una relación de complejidad, versiones, rapidez, ventajas, desventajas y otras características relacionadas con los siguientes 4 métodos. Antes describiendo en líneas generales la esencia de cada uno.

“Database Upgrade Assistant ( DBUA )”

El “DBUA” es un “Graphical User Interface” (“GUI”) que guía al “DBA” a través del proceso de “Upgrade” presentando una serie de pantallas que permitirán la especificación de opciones para el “Upgrade” de base de datos. Durante el proceso de “Upgrade” el “DBUA” invoca los mismos “scripts” utilizados por la “Command-line Upgrade”. El “DBUA” también lleva a cabo pasos de validación “pre-upgrade” y puede automatizar tareas “post-upgrade”. Utilizando el “DBUA” se puede reducir significativamente la cantidad de esfuerzo manual requerido para realizar un “Upgrade”.
“Command-line Upgrade”
En “Oracle Database 12c” es introducido un nuevo utilitario de línea de comando llamado “catctl.pl”, este utilitario reemplaza el ampliamente conocido: catupgrd.sql de versiones anteriores. El nuevo “Command-line upgrade utility” permite procesamiento paralelo durante el “Upgrade” de la base de datos, resultando en un mejor rendimiento y reducción de “Database Downtime”.
El “Command-line upgrade” sigue los mismos pasos que el “DBUA” y toma los mismos tiempos para realizar las tareas de “Upgrade” respecto a este. Es utilizado de forma directa por los “DBAs” para tomar mayor control de la tarea o en escenarios donde las bases de datos están siendo movidas a nuevos “Hardware Server” en conjunto con la aplicación del proceso de “Upgrade”.
A partir de “Oracle Database 12c” el “Pre-Upgrade Information Tool” ( preupgrd.sql ) automáticamente genera “fixup scripts” para asegurar todos los elementos necesarios para un “Upgrade” exitoso. La fase “Post-upgrade” también ha sido mejorada para las fases de ejecución posteriores al “Upgrade”.
El proceso de “Upgrade” con el “Command-line Upgrade” es llevado a cabo en 3 fases:
Fases
Pasos & Descripciones
1.- Fase “Pre-upgrade”
  • Ejecutar el nuevo “Pre-Upgrade Information Tool” ( preupgrd.sql ) el cual realiza validaciones a la BBDD objeto del “Upgrade”
  • Ejecutar el “script” “preupgrade_fixups.sql” para automáticamente resolver todos los “ítems” señalados por el “Pre-Upgrade Information Tool”
  • Llevar a cabo “Manual Fixups” señalados por el “Pre-Upgrade Information Tool”
2.- Fase de “Upgrade”
  • Ejecucion del “Parallel Upgrade Utility” ( catctl.pl )
3.- Fase de “Post-Upgrade”
  • Ejecución del “script” “postupgrade_fixups.sql” para automáticamente resolver cualquier “ítem” identificado por el “Pre-Upgrade Information Tool”
  • Ejecución del “Post-Upgrade Status Tool” (utlu121s.sql) para visualizar un resumen de los resultados del “Upgrade”
  • Realizar chequeo de los archivos “logs” generados por el “Parallel Upgrade Utility”
  • Recompilar objetos inválidos ejecutando ( utlrp.sql )
  • Verificar el estatus de los objetos recompilados ( utluiobj.sql )

“Full Transportable Export/Import or Transportable Tablespaces”

“Full Transportable Export/Import” es una nueva característica de “Oracle Database 12c” que facilita el movimiento de una base de datos completa utilizando la característica “Transportable Tablespace”. Este automatiza el proceso de movimiento de “Metadata” y es capaz de mover “Data” que reside en “Tablespaces” no transportables como “System” & “Sysaux”. Además es capaz de transportar “Tablespaces” encriptados.
“Transportable Tablespaces” permite una copia de un conjunto de “Tablespaces” de una base de datos a otra. Esta técnica pudiera ser muchísimo mas rápido que el tradicional “Export/Import” de la “Data” de esos correspondientes “Tablespaces” debido a que los “Tablespaces” ( “Datafiles” ) se están copiando físicamente en lugar de interpretar entidades lógicas como registros o índices contenidos en esos archivos. Con la técnica de “Transportable Tablespace” aparte de transportar los “Datafiles” se debe exportar la “Metadata” del mismo a través de “Data Pump export/import”.
“Transportable Tablespace” puede transferir información a otra base de datos que pudiera estar en un sistema operativo distinto o ejecutando en una versión distinta de “Oracle Database Software”. A partir de “Oracle Database 12c” la nueva característica “Full Transportable export/import” combina velocidad de transporte con un marco procedimental mas sencillo para llevar a cabo la tarea.
Es posible utilizar la mencionada técnica para transportar BBDDs a partir de “Oracle Database 11g Release 2 (11.2.0.3)”

Oracle Data Pump Export/Import

“Oracle Data Pump” provee un movimiento de “Data” & “Metadata” de alta velocidad entre bases de datos Oracle. Poseen una extrema flexibilidad y facilidad de uso. Es una opción para trasladar BBDDs de manera muy fácil entre base datos pertenecientes a plataformas o versiones distintas. “Data Pump” puede transferir “Data” desde una fuente en disco o a través de la red. En líneas generales son utilitarios que pueden trasladar “Data” de manera sencilla y versátil.
Original Export/Import
Desde la aparición de “Data Pump Export/Import” en 10g, “Oracle Corp,” ha recomendado su uso en comparación con el “Original Export/Import”, sin embargo es altamente útil para realizar “Upgrades” lógicos desde versiones como “9i”.
Veamos un cuadro de Ventajas y desventajas de las mencionadas herramientas y métodos:
Método
Herramienta
Ventajas
Desventajas
Método 1
DBUA ( “Database Upgrade Assistant” ): esta basado en un utilitario GUI (“Graphical User Interface”) el cual se ha encontrado presente en al menos 4 generaciones de versiones de base de datos previas. El “Upgrade” con el “DBUA” es comúnmente denominado “Upgrade in place” debido a que realiza la operación sobre una BBDD que se encuentre de forma local en el mismo servidor donde se encuentre instalado el “software” de nivel superior, que para el presente caso, seria una versión de “Oracle Database 12c”Posee un asistente de fácil uso indicando todos los pasos a realizar en cada etapa.
Reduce en gran medida esfuerzos manuales.
En el “Wizard” Posee capacidad de ajustar recursos para reducir el tiempo efectivo de “Upgrade”: paralelismo, cantidad de ‘CPUs”, calculo de estadísticas, recompilado de objetos,etc
La BBDD origen debe permanecer en modo “mount” para realizar el procedimiento lo cual anula la posibilidad de un “Rolling Upgrade”.
Es realizado sobre la BBDD origen por lo tanto hay que asegurar previamente un “Backup de la misma lo cual podría extender el “Downtime” del “Upgrade”
Las 2 versiones de manejador ( origen y destino ) deben estar instaladas en el mismo servidor. Esto representa una desventaja para cuando se desean realizar “Upgrades” trasladando la BBDD a otro nuevo hardware.
DBUA no es “restartable” una vez iniciado.
Método 1
“Command-line upgrade scripts”: Para “Oracle Database 12c” es introducido un nuevo utilitario de línea de comando llamado “catctl.pl”, este utilitario reemplaza el ampliamente conocido: catupgrd.sql de versiones anterioresEs uno de los métodos mas efectivos por la versatilidad de controlar al 100% el proceso de “Upgrade” y la posibilidad de combinar este método con filosofías “Zero Downtime” en modo “Rolling Upgrade”Es de grado complejo. El “DBA” necesitara familiarizarse excelentemente bien con el método para saber combinar el mismo con otras técnicas: paralelismo, “flash cards”, etc para disminuir el tiempo de reconstrucción del catalogo
Método 2
“Transportable Tablespaces” ( TTS ) Export/Import: esta basado en el traslado de la “Data” a través del transporte de solo los “Tablespaces” que contienen datos de aplicaciónSus nuevas propiedades permiten realizar el transporte de “Tablespaces” con menores pasos con respecto a versiones anteriores
Existe la posibilidad de movimiento de bases de datos enteras en modo multiplataforma de 11.2.0.3 a 12c con la característica “Full Transportable Export/Import”
El proceso posterior debe lidiar con el traslado físico de los “Datafiles”, “Export” & “Import” de la “Metadata”. Estas características promueven un “Downtime” prolongado si no se utilizan estrategias y recursos adecuados.
Método 3
“Oracle Data Pump Export/Import”: esta basado en un procedimiento de “Export” & “Import” lógico de la BBDDEs un método lógico fácil y de alta consistencia en los detalles de “Import” en comparación al antiguo “Import Utility”.
Es combinable con otros métodos de aceleración como: paralelismo.
El “Export/Import Data Pump” posee propiedades de “stop/resumable/customizing” de la actividad lo cual lo hace flexible y versátil en modo de ejecución.
Excelente para migraciones complejas entre plataformas heterogéneas.
No alcanza tiempos tan bajos para BBDDs de largo alcance como para considerarlo un método “Zero Downtime”
Método 4
“Original Export/Import Utility”: es la versión original de Export/Import ( Utilitarios para movimientos de “Data” en forma lógica )La principal ventaja es que los manejadores de versiones superiores lo poseen aun por motivos de portabilidad con respecto a versiones anteriores lo cual brinda la oportunidad de realizar un “Upgrade” directo de “8i”,”9i” a versiones superioresLa efectividad en el  transporte lógico no es tan exacta, fidedigna y flexible como su sucesor “Oracle Data Pump Export/Import”

Le mostramos el siguiente cuadro con el objetivo de completar y/o adicionar otras variables para la toma de decisiones relacionadas con los 4 métodos explicados en el cuadro anterior. En el podrán ver otras características de los métodos relacionados con: complejidad, velocidad, versión mínima, movimiento a servidores nuevos, cambio de sistema operativo y funcionalidades adicionales tales como: ‘Character sets”, “Partitioning”, “Encryption”, “Compression” y otras.
complejidad, velocidad, versión mínima, servidores nuevos, sistema operativo y funcionalidades
Existen otras soluciones, herramientas y métodos tales como: “Oracle Golden Gate”, “Oracle Streams”, “Rolling Upgrade” con “Oracle Data Guard”, “Manual Rolling Upgrade”, “RMAN Cross-Platform Incremental Backups”, etc las cuales están fuera de orden del análisis del presente articulo. Lo más importante es poder proyectar con toda esta información, lo complejo que puede tornarse la toma de decisión del método a escoger para realizar un “Upgrade”. Desde nuestro punto de vista. El camino efectivo para dominar el arte del “Upgrade” esta basado en los siguientes elementos:
  • Adquirir amplio conocimiento del uso de cada una de las soluciones, métodos y herramientas en bajo, medio y alto nivel de exigencia
  • Experiencia Real de enfrentarse al planteamiento y ejecución de múltiples tareas de “Upgrade” en distintos escenarios, con diversos clientes, con BBDDs de diversos tamaños, con divergencia de recursos, con plataformas distintas, con arquitecturas distintas, etc…. Solo la reflexión de realizar planteamientos reales potenciaran las habilidades en esta área
  • En líneas generales para ser un experto en “Upgrade” es necesario experiencia Real en muchos escenarios reales de “Upgrade”…
Ya estando en contexto de la naturaleza de saber lo concerniente al arte del “Upgrade”, pasemos a desarrollar uno de los tantos escenarios que desplegaremos en esta serie de artículos dedicados al “Upgrade”.
Objetivo/Descripcion de escenario de “Upgrade”
  • “Upgrade” de BBDD en modo “No Zero Downtime”. En modo “No Zero Downtime” el tiempo de “Downtime” puede ser prolongado. Se realizara la actividad en un mismo servidor donde se encuentran los manejadores origen y destinos señalados en este cuadro. Se utilizara como herramienta de “Upgrade”, el “DBUA”, este exige que la BBDD se encuentre en disposición total para la actividad de “Upgrade”, es decir, a partir del momento del inicio de la actividad, el “DBUA” toma posesión de la misma. La BBDD origen se encuentra en modo “No Archive” por lo tanto se tomara un determinado espacio de tiempo para tomar un “Cold Backup” a la misma, en condiciones regulares una BBDD de producción debería siempre estar establecida en Modo “Archive” lo cual implica que pudiera ser objeto de un “Hot Backup” para ahorrar este tiempo de “Downtime” efectuando el “Cold Backup”.
Versión de manejador en el Origen
  • 11.2.0.3
Versión de manejador en el Destino
  • 12.1.0.1.0
Sistema Operativo Origen
  • Linux x86
Sistema Operativo Destino
  • Linux x86
Herramienta(s) a ser utilizadas
  • DBUA
Nombre de BBDD Origen
  • TST11G
Nombre de BBDD Destino
  • TST11G
Iniciemos…

Base de Datos inicial de nombre ( TST11G ), objeto de “Upgrade”:

sandbox1(tst11g):/home/oracle>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Jul 19 17:32:44 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SYS@tst11g SQL>select open_mode , name from v$database;

OPEN_MODE            NAME
-------------------- ---------
READ WRITE           TST11G

SYS@tst11g SQL>
SYS@tst11g SQL>exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
sandbox1(tst11g):/home/oracle>

“Backup” de la BBDD previo al proceso de “Upgrade”. Una de las pantallas del “DBUA” indicara señalar si ya se tenía un “Backup” previo al procedimiento.

Nota: se recomienda el establecimiento de “Controlfile and spfile autobackup” si no se esta utilizando “Recovery Catalog”
sandbox1(tst11g):/jv01/app/oracle/cfgtoollogs/tst11g>rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Fri Jul 19 17:42:05 2013

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

connected to target database: TST11G (DBID=4119453581)

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name TST11G are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/app/oracle/product/11.2.0/db_1/dbs/snapcf_tst11g.f'; # default

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN>

RMAN>  shutdown immediate;

using target database control file instead of recovery catalog
Oracle instance shut down

RMAN> startup mount;

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area     835104768 bytes

Fixed Size                     2232960 bytes
Variable Size                490737024 bytes
Database Buffers             335544320 bytes
Redo Buffers                   6590464 bytes

RMAN>


SYS@tst11g SQL>

Database altered.

RMAN> backup database;

Starting backup at 07/19/2013 17:46:09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_system_8ymc4j4o_.dbf
input datafile file number=00002 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_sysaux_8ymc4vp4_.dbf
input datafile file number=00003 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_undotbs1_8ymc50pn_.dbf
input datafile file number=00004 name=/jv01/app/oracle/oradata/TST11G/datafile/o1_mf_users_8ymc5ml7_.dbf
channel ORA_DISK_1: starting piece 1 at 07/19/2013 17:46:11
channel ORA_DISK_1: finished piece 1 at 07/19/2013 17:46:26
piece handle=/jv01/app/oracle/fast_recovery_area/TST11G/backupset/2013_07_19/o1_mf_nnndf_TAG20130719T174610_8ymdx31m_.bkp tag=TAG20130719T174610 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 07/19/2013 17:46:26

Starting Control File and SPFILE Autobackup at 07/19/2013 17:46:26
piece handle=/jv01/app/oracle/fast_recovery_area/TST11G/autobackup/2013_07_19/o1_mf_s_821209377_8ymdxlkd_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 07/19/2013 17:46:27

RMAN>


RMAN> alter database open;

database opened

RMAN>

Invocado del “DBUA” desde el “Home” “12c”. Escogencia de la opción “Upgrade Oracle Database”
Upgrade Oracle Database
Selección de la base de datos para el “Upgrade”. Nótese todos los detalles de:
• “Source Oracle Home”, “Target Oracle Home”, “Source Oracle Home Release” y otros
Selección de la base de datos
Chequeo de Pre-requisitos con el uso del “Pre-Upgrade Information Tool” explicado al principio del articulo.
Pre-Upgrade Information Tool
“Pre Upgrade Utility” ejecutado en conjunto con chequeos previos.
Pre Upgrade Utility
Establecimiento de Paralelismo para las actividades de “Upgrade” ( Reconstrucción de Catalogo ). En “Upgrade Options” podemos realizar el establecimiento de:
  • Grado de paralelismo para el compilado de objetos posterior al “Upgrade”
  • Escogencia de “Upgrade” del “Timezone Data”
  • Opción de calcular estadísticas previo al “Upgrade”
  • Opción de  establecimiento en modo “Read Only” de “Tablespaces” de “Data”
“Set” de rutas para el “Diagnostic Destinantion” & “ Audit File Destination”
Reconstrucción de Catalogo
Para el presente caso establecimos el parámetro de Paralelismo para el “Upgrade” en 4. Se recomienda que este parámetro sea máximo la cantidad de CPUs del “Hardware Server”
parámetro de Paralelismo
Para el presente caso establecimos el parámetro de Paralelismo para la recopilación de objetos en 2. Se recomienda realizar “test” previos para el valor de este parámetro, es decir, normalmente antes de llevar a cabo un “Upgrade” se realizan múltiples pruebas y ejercicios del método a utilizar. La cantidad de “Program Units” no esta relacionado con el tamaño de BBDD, es decir, se podrán tener BBDDs de no muy alta capacidad pero con gran cantidad de “Program Units y asi sucesivamente. El tener estos en estado valido es parte del “Upgrade” y del “Application Downtime”, entonces se recomienda realizar “tests” previos para la recolección de cuanto se tomaría el recompilado con valor de paralelismo “1”,”2”,”3”,etc.. . Para preparar el ciclo de vida de un “Upgrade” real se recomienda la duplicación de la BBDD de producción y la aplicación en esta ( la BBDD clonada ) en un ambiente lo mas aproximado o igual al ambiente donde será llevado a cabo el “Upgrade” real.
parámetro de Paralelismo
Especificación de si se desea la ejecución de “Custom Scripts” previo o posterior al “Upgrade”
Custom Scripts
Especificar si se desea “OEM Express” ( Nuevo en “12c” ) o registrar la BBDD en un “EM Cloud Control” existente.
OEM Express
Escogencia de posible movimiento de “Datafiles” y/o “Fast Recovery Area” como parte del “Upgrade”
Datafiles
Escogencia del “Listener” en el cual la BBDD se ha de registrar. De manera natural se ha de escoger el del nuevo “12c Home”
Listener
Escogencia del la opción de recuperación de la BBDD para el caso de un “Upgrade” no exitoso. En nuestro caso escogemos la opción “I have my own backup and restore strategy” en base al “Cold Backup” que realizamos al principio del procedimiento, de lo contrario tuviésemos que llevar a cabo un “Backup” bajo las opciones presentes en la pantalla.
recuperación de la BBDD
”Database Upgrade Summary”: en la siguiente pantalla se muestran los components a ser actualizados, los componentes dependen de forma directa a las opciones activadas en la BBDD origen. El estatus “VALID” al lado de cada componente especifica que ya el mismo fue validado para ser actualizado.
Avance del Upgrade
Avance del “Upgrade”..
Avance del Upgrade
Avance del “Upgrade”..
Database Upgrade Summary
Los botones “Activity Log” & “Alert Log” pueden ser presionados para el monitoreo de las actividades.
“Upgrade” listo al 100%
Upgrade listo
“Upgrade Results”
Upgrade Results
“Upgrade Results”
Upgrade Results
“Upgrade Results”
Upgrade Results
Conclusión
Llegados a este punto la BBDD estaría actualizada a la nueva versión “12c” y lista para su uso. El “Upgrade” a través del “DBUA” es un proceso claramente simple, es ideal principalmente cuando el nuevo “Hardware Server” será el mismo de la versión anterior. Para este escenario se recomienda:
  • Duplicar la BBDD de producción en el mismo servidor de producción a través de alguno de los tantos métodos de duplicación de BBDD Oracle. Es altamente recomendable utilizar un método de duplicado físico tales como: “RMAN Duplicate” u otros de manera de tener una copia de la BBDD con la misma distribución física respecto a la BBDD de producción (  distribución bloque a bloque ).
  • La actividad de “Upgrade” implicara un “Application Downtime” que estará basado en diversos factores, entre los cuales uno de los mas importantes es el rendimiento del “Hardware Server” ( CPU, Memoria, etc ) donde se realizara la actividad, por lo tanto no hay mejor “Hardware Server” ideal para realizar estas pre-pruebas de “Upgrade” mas que en el mismo servidor donde se realizara la actividad real de “Upgrade”, a excepción de si se poseen servidores con soluciones “Data Guard Server” o “Manual Standby Server” ( leer detalles de este punto en el penúltimo “ítem” ). Esto ( el duplicado de BBDD de producción “in site” )  pudiera conllevar riesgos con respecto a la BBDD de producción si el “DBA” no posee alta experiencia en Duplicados de BBDD en un mismo servidor. Muchos clientes optan por solicitar un servidor con las mismas características o cualquier solución que les conlleve a no trabajar directamente en el servidor de producción y tener el resultado lo mas parecido posible a cuando se realice la actividad directamente en producción. En dado caso se estaría incurriendo en un precio de gestión paralela por no poseer en el “task” manos expertas para ello.
  • Muchas empresas optan por realizar los ejercicios de “Upgrade” en el o los servidores con soluciones “Data Guard” o “Manual Standby”. Si el servidor a ser utilizado posee las mismas características del servidor de producción estaría justificable la estrategia o inclusive el “Upgrade” real se podría realizar en estos servidores mencionados “Data Guard Server” o “Manual Standby Server”. Esto ofrece una gran ventaja ya que el procedimiento no se realizara directamente sobre la BBDD origen de producción sino en una copia físicamente igual con inclusive el mismo nombre. Una de las principales ventajas esta basada en que si el “Upgrade” obtuviera algún problema de ejecución, la actividad podría ser pospuesta pero la BBDD original estaría intacta por lo tanto se podrían restablecer las operaciones de producción de forma inmediata.
  • Es aconsejable que siempre se persigan los siguientes objetivos:
    • Realizar las actividades de “Upgrade” en el o los servidores reales donde se llevara a cabo finalmente la actividad para tener la certeza de los tiempos esperados para el momento del “Upgrade” real
    • Trazar una estrategia en la cual se resguarde al 100% la BBDD de producción
    • Trazar una estrategia en la cual la BBDD de producción pueda retornar a sus actividades de forma casi inmediata en caso de que el proceso de “Upgrade” real llegara a fallar
    • Y por supuesto realizar todo tipo de pruebas de funcionalidad y rendimiento con una base de datos piloto actualizada a la nueva versión antes de llevar a cabo el “Upgrade” real de producción
  • En líneas generales, el “DBA” siempre debe trazar estrategias para escenarios satisfactorios o no satisfactorios en la actividad, de manera de garantizar el servicio del cliente en la versión superior u original