Descargue el PDF – Newsletter – Noviembre 2013

Newsletter – Noviembre 2013
Movimiento ONLINE de Archivos de
Datos en Oracle 12c
Contenido
Página:
1 Movimiento ONLINE de
Por Ing. Manuel Carrillo
[email protected]
Archivos de Datos en Oracle
12c
3 Duplicación de Base de
Datos sin Conectarse al
Origen o al Catálogo de
RMAN en Oracle 11.2
5 Diagnóstico de Bajo
En versiones anteriores a 12c, si se quería mover un archivo de datos a otra
ubicación, ya sea en ASM o en sistema de archivos, era necesario colocar el
tablespace correspondiente en modo "OFFLINE", copiar el archivo físicamente,
renombrar el archivo lógicamente, y por último regresar el tablespace a modo
"ONLINE".
Esta operación crea un escenario de "no disponibilidad" para algunas aplicaciones
o usuarios que necesiten acceder a la información que está siendo movida. A partir
de Oracle Database 12c ya no es necesario pasar por la fase "OFFLINE".
5a. Ave. 5-55 Zona14,Edificio Euro Plaza Torre II, Nivel 12
Rendimiento
de Aplicaciones
Teléfono:
(502)2364-5300Fax:
(502)2364-5311
Como ejemplo, se crea un tablespace TEST:
con trcsess y tkprof
[email protected]
SQL> create tablespace ts_test datafile
'/u01/app/oracle/oradata/test_1.dbf' size 100M;
Editores Generales
Tablespace created.
Francisco Barrundia
Luego se crea una tabla y se inserta un registro:
Alejandro Lau
Debbie Morán
Pagina 1/10
SQL> create table tab_test (id integer) tablespace ts_test;
Table created.
Autores
Contribuyentes
SQL> insert into tab_test values (1);
1 row created.
Manuel Carrillo
Augusto López
SQL> commit;
Alejandro Lau
Commit complete.
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 1
Para mover el archivo de datos ejecutamos la siguiente instrucción, sin necesidad de colocar
"OFFLINE" el tablespace:
SQL> alter database move datafile '/u01/app/oracle/oradata/test_1.dbf' to
'/u01/app/oracle/oradata/test_2.dbf';
Database altered.
SQL> select * from tab_test;
ID
---------1
El contenido del alert.log es el siguiente:
Wed Sep 04 15:40:01 2013
create tablespace test datafile '/u01/app/oracle/oradata/test_1.dbf' size
100M
Completed: create tablespace test datafile
'/u01/app/oracle/oradata/test_1.dbf' size 100M
alter database move datafile '/u01/app/oracle/oradata/test_1.dbf' to
'/u01/app/oracle/oradata/test_2.dbf'
Wed Sep 04 15:41:50 2013
Moving datafile /u01/app/oracle/oradata/test_1.dbf (14) to
/u01/app/oracle/oradata/test_2.dbf
Move operation committed for file /u01/app/oracle/oradata/test_2.dbf
Completed: alter database move datafile
'/u01/app/oracle/oradata/test_1.dbf' to
'/u01/app/oracle/oradata/test_2.dbf'
Físicamente se puede ver el archivo de datos que ha sido movido:
[oracle@rac1 admin]$ cd /u01/app/oracle/oradata/
[oracle@rac1 oradata]$ ls -l test*
-rw-r----- 1 oracle oinstall 104865792 Jun 26 15:41 test_2.dbf
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 2
Duplicación de Base de Datos sin Conectarse
al Origen o al Catálogo de RMAN en Oracle 11.2
Por Ing. Augusto López
[email protected]
En versiones previas a Oracle Database 11.2, para duplicar una base de datos se requiere una
conexión a la base de datos a duplicar (target) o al catálogo de recovery manager (rman). En la
versión 11.2 de Oracle Database esto ya no es necesario. Esta funcionalidad recibe el nombre de
duplicación basada en respaldos.
Escenario




Instancia y base de datos a duplicar: prod
Servidor origen: srvprod
Respaldos de la base de datos en /prod/backups
Base de datos está en modo ARCHIVELOG y usa spfile.



Instancia y base de datos duplicada: dup
Servidor destino: srvdup
Respaldos para el duplicado están en /dup/backups
La clonación se hace entre servidores de la misma plataforma (arquitectura del CPU y sistema
operativo) y entre versiones iguales del software de base de datos Oracle, instalado en
/u01/app/oracle/product/11.2.0/dbhome_1. Ambas bases de datos se almacenan en ASM en el
diskgroup +DATA.
Procedimiento
1. Generar un respaldo de la base de datos prod y sus archivelogs.
RMAN> backup database format '/prod/backups/db_%U.rman';
RMAN> sql 'alter system archive log current';
RMAN> backup archivelog all format '/prod/backups/arc_%U.rman';
2. Crear un PFILE de la base de datos a duplicar.
SQL> create pfile='/prod/backups/initdup.ora' from spfile;
3. Copiar los backupsets y el PFILE al servidor srvdup.
$ scp /prod/backups/* srvdup:/dup/backups
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 3
4. En srvdup modificar initdup.ora para cambiar los siguientes parámetros:
*.audit_file_dest='/u01/app/oracle/admin/dup/adump' #crear directorio
*.control_files='+DATA'
*.db_create_file_dest='+DATA'
*.db_name='dup'
5. En srvdup generar SPFILE a partir del PFILE.
SQL> create spfile='spfiledup.ora' from pfile='initdup.ora';
6. Crear el archivo de claves para la instancia dup.
$ orapwd file=orapwdup password=miclave
7. Arrancar la instancia dup.
$ export ORACLE_SID=dup
$ sqlplus / as sysdba
$ startup nomount
8. En srvdup hacer la clonación.
$ rman auxiliary /
RMAN> duplicate database to 'dup' backup location '/dup/backups';
Tip Técnico del Mes
¿Puedo determniar cuándo fue creado un objeto dentro de la base de datos, sin necesidad
de habilitar la auditoria?
Efectivamente es posible, con el siguiente query:
SELECT OWNER, OBJECT_NAME, CREATED, LAST_DDL_TIME
FROM DBA_OBJECTS
WHERE OWNER = 'DUEÑO' AND OBJECT_NAME = 'NOMBRE_OBJETO';
Por Lic. Francisco Barrundia
[email protected]
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 4
Diagnóstico de Bajo Rendimiento de
Aplicaciones con trcsess y tkprof
Por Ing. Alejandro Lau
[email protected]
Cuando una aplicación presenta un rendimiento más bajo de lo esperado o de lo normal, se puede
volver muy complicado o imposible determinar la causa, si abordamos el problema con una revisión
manual de código. Este código puede estar "escondido" a simple vista por la complejidad de la
aplicación, ya sea código local o en la base de datos Oracle (procedimientos almacenados,
triggers).
En estos casos, una estrategia más efectiva es generar y analizar uno o más archivos de rastreo
(trace) para la aplicación. Podemos habilitar el rastreo para una sesión específica, para un servicio
de base de datos o para toda la base de datos (esta última no es recomendable). Una vez
generada esta información de rastreo, procesamos el (los) archivo(s) con las herramientas de
Oracle trcsess y tkprof.
Rastreo a nivel de sesión
Si se puede hacer en un ambiente controlado y se tiene una sesión identificada, se sugiere este
procedimiento por su simplicidad.
1. Habilitar rastreo para la sesión identificada:
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(sid,serial);
2. Al terminar la sesión o después de que se haya realizado al menos un ciclo del proceso,
deshabilitar el rastreo. Si la sesión ya concluyó, no es necesario este paso.
EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(sid,serial);
3. Ubicar el archivo generado según el parámetro USER_DUMP_DEST (9i o 10g) o
DIAGNOSTIC_DEST
(11g).
Generalmente,
USER_DUMP_DEST
apunta
a
$ORACLE_BASE/admin/<dbname>/udump
y
DIAGNOSTIC_DEST
apunta
a
$ORACLE_BASE/diag/rdbms/<dbname>/<instancename>/trace. El nombre del archivo
es de la forma <dbname>_ora_######.trc.
4. Utilizando la herramienta tkprof, generamos un archivo de texto a partir del archivo .trc. Esto
simplifica el análisis de la información.
tkprof archivo.trc salida.txt
En el ejemplo anterior, archivo.trc es el archivo generado con el rastreo y salida.txt es
el archivo que genera tkprof.
El archivo generado por tkprof contiene estadísticas y planes de ejecución para cada SQL
ejecutado en la sesión. Acá podemos determinar en dónde está el problema de desempeño.
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 5
Principalmente hay que enfocarse en la columna "elapsed", que indica el tiempo total de
ejecución de la sentencia SQL. Para cada SQL se presenta información similar al siguiente
ejemplo, además del plan de ejecución.
call
count
------- -----Parse
0
Execute
0
Fetch
12968
------- -----total
12968
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.00
0.00
0
0
0
0.00
0.00
0
0
0
2941.94
16031.06
2269457 365439925
2
-------- ---------- ---------- ---------- ---------2941.94
16031.06
2269457 365439925
2
rows
---------0
0
64839200
---------64839200
Misses in library cache during parse: 0
Parsing user id: 49 (???)
Elapsed times include waiting on following events:
Event waited on
Times
---------------------------------------Waited
SQL*Net more data to client
513731
db file scattered read
98547
SQL*Net message from client
12969
SQL*Net message to client
12968
db file sequential read
699291
Disk file operations I/O
10
db file parallel read
80
latch: cache buffers chains
29
latch: In memory undo latch
2
read by other session
2
latch: object queue header operation
48
resmgr:cpu quantum
79
Max. Wait
---------0.07
3.04
33.84
0.00
2.03
0.00
0.70
0.00
0.00
0.15
0.02
0.00
Total Waited
-----------21.58
1961.32
55009.22
0.06
9361.58
0.00
7.93
0.00
0.00
0.22
0.06
0.07
Podemos ver del ejemplo que el tiempo de ejecución (elapsed) es muy alto para la fase Fetch
del SQL. Por las columnas disk, query y row podemos deducir que este SQL está leyendo
muchísima información de disco y memoria. Más abajo en las esperas, vemos que hay muchas
esperas por envío de datos al cliente (SQL*Net more data to client) y por lecturas
secuenciales (db file sequential read).
En este caso conviene analizar el plan de ejecución y determinar si se pueden minimizar los costos
con creación de índices, cálculo de estadísticas, hints, optimización del SQL.
Rastreo a nivel de servicio
Si no es factible identificar una sesión para el rastreo o se quiere habilitar por un período
desatendido, es mejor realizar un rastreo del servicio de base de datos. Este enfoque funciona
mucho mejor si utilizamos un servicio por aplicación, en vez de utilizar el servicio por defecto de la
base de datos. Por ejemplo, si tenemos un servicio test, el plan de acción es el siguiente:
1. Habilitamos rastreo para el servicio test.
EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'test');
2. Luego de un tiempo definido, desactivamos el rastreo.
EXEC DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'test');
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 6
3. A diferencia del rastreo para una sesión, el rastreo a nivel de servicio generará tantos archivos
como sesiones utilicen el servicio. Por esta razón, necesitamos unificar todos estos archivos de
rastreo generados, para luego aplicarles tkprof. En el ejemplo de abajo, buscamos los
archivos de rastreo generados para el servicio test, el 23 de mayo de 2013, generando el
listado a un archivo.
cd $ORACLE_BASE/admin/orcl/udump
grep -lF test *trc | xargs grep -l 2013-05-23 > trcsess-test.sh
4. El listado generado se debe procesar con trcsess, con la finalidad de producir un archivo
unificado de rastreo. Editamos el script trcsess-test.sh y agregamos el comando
trcsess al inicio. Asimismo, pegamos todas las líneas, incluyendo el comando trcsess, de
modo que quede una sola línea en el archivo.
trcsess output=test.trc service=test arch1.trc arch2.trc ... archN.trc
Grabamos y ejecutamos el script:
sh trcsess-test.sh
5. Ahora ya podemos utilizar tkprof sobre el archivo generado test.trc, para generar un
archivo test.txt, similar a salida.txt de la sección anterior:
tkprof test.trc test.txt
Finalmente, procedemos a la revisión y diagnóstico del archivo txt.
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
[email protected]
Página 7