SQL> alter diskgroup DG_DATA check all
repair;
SQL>alter diskgroup DG_FRA check all repair;
SQL>alter diskgroup DG_FRA check all repair;
SQL> alter diskgroup DG_DATA rebalance power
11 nowait;
lunes, 31 de octubre de 2016
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
The function can accept many optional parameters, shown here, but most of the time you will probably only use the following.
To see it in action, first we make sure we have a monitored statement to work with.
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
TheMONITOR 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
TheREPORT_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- TheSQL_IDof the query of interest. When NULL (the default) the last monitored statement is targeted.SQL_EXEC_ID- When theSQL_IDis specified, theSQL_EXEC_IDindicates the individual execution of interest. When NULL (the default) the most recent execution of the statement targeted by theSQL_IDis 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. UseSYS_CONTEXT('USERENV','SID')for the current session.
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 OFFExamples 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_PATHparameter 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
TheREPORT_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 OFFExamples 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”
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=alwaysDivise 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 datostst11g:/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 recomendacionesSQL> @/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.sqlArribados 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”
“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” )
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”
“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” |
|
| 2.- Fase de “Upgrade” |
|
| 3.- Fase de “Post-Upgrade” |
|
“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 anteriores | Es 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ón | Sus 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 BBDD | Es 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 superiores | La 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.
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”…
| Objetivo/Descripcion de escenario de “Upgrade” |
|
| Versión de manejador en el Origen |
|
| Versión de manejador en el Destino |
|
| Sistema Operativo Origen |
|
| Sistema Operativo Destino |
|
| Herramienta(s) a ser utilizadas |
|
| Nombre de BBDD Origen |
|
| Nombre de BBDD Destino |
|
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”
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
Chequeo de Pre-requisitos con el uso del “Pre-Upgrade Information Tool” explicado al principio del articulo.
“Pre Upgrade Utility” ejecutado en conjunto con chequeos previos.
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”
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”
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.
Especificación de si se desea la ejecución de “Custom Scripts” previo o posterior al “Upgrade”
Especificar si se desea “OEM Express” ( Nuevo en “12c” ) o registrar la BBDD en un “EM Cloud Control” existente.
Escogencia de posible movimiento de “Datafiles” y/o “Fast Recovery Area” como parte del “Upgrade”
Escogencia del “Listener” en el cual la BBDD se ha de registrar. De manera natural se ha de escoger el del nuevo “12c Home”
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.
”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”..
Los botones “Activity Log” & “Alert Log” pueden ser presionados para el monitoreo de las actividades.
“Upgrade” listo al 100%
“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
Suscribirse a:
Entradas (Atom)
