Oracle 12c New Features : Deshabilitar el logging al momento de importar una tabla



Existe una nueva característica en Oracle 12c , relacionada con el hecho de evitar crear entradas en los archivos de redolog cuando se realiza el import de una tabla, esto se hace mediante un parámetro que se llama TRANSFORM en el impdp, el cual puede venir con un conjunto de valores, uno de esos valores es el que vamos a mostrar ahora



Al momento de realizar un import podemos eliminar la posibilidad de generar entradas en el redo, colocando a todos los objetos del import en opción de NOLOGGING, esto se hace mediante el siguiente parámetro y su correspondiente valor

TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y


Con lo anterior se efectúa una DDL sobre los objetos a importar los cuales quedan en modo NOLOGGING y una vez terminado el import los objetos vuelven a quedar en estado LOGGING (el cambio de NOLOGGING y LOGGING es para evitar la generación de redo) , con esto el proceso total de importación de un objeto es más rápido y por ende generará menos carga a la base de datos.

Los objetos que quedan expuestos a este cambio de modalidad , son solamente los índices y las tablas


Ejemplo práctico al ejecutar un import

impdp system/oracle1@prod12c directory=DATA_PUMP_DIR dumpfile=TABLA1_01.DMP tables=SYSTEM.objetos TRANSFORM=DISABLE_ARCHIVE_LOGGING

Import: Release 12.1.0.1.0 - Production on Sßb Jul 20 16:00:51 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates. 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
La tabla maestra "SYSTEM"."SYS_IMPORT_TABLE_01" se ha cargado/descargado correctamente
Iniciando "SYSTEM"."SYS_IMPORT_TABLE_01": system/********@prod12c directory=DATA_PUMP_DIR dumpfile=TABLA1_01.DMP tables=SYSTEM.objetos TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y
Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE
Procesando el tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA
. . "SYSTEM"."OBJETOS" 10.38 MB 91011 filas importadas
Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Procesando el tipo de objeto TABLE_EXPORT/TABLE/STATISTICS/MARKER
El trabajo "SYSTEM"."SYS_IMPORT_TABLE_01" ha terminado correctamente en Sßb Jul 20 16:01:00 2013 elapsed 0 00:00:08


Al realizar una consulta a la base de datos, podremos ver que al momento de crearse el objeto queda como NOLOGGING y una vez terminada la carga de datos se pasa a LOGGING

SQL> r
1* select owner , table_name , logging , to_char(sysdate,'dd-mm-yyyy hh24:mi:ss') "Fecha consulta" from dba_tables where table_name like 'OBJETOS'

no rows selected

SQL> r
1* select owner , table_name , logging , to_char(sysdate,'dd-mm-yyyy hh24:mi:ss') "Fecha consulta" from dba_tables where table_name like 'OBJETOS'

OWNER      TABLE_NAME                     LOG Fecha consulta
---------- ------------------------------ --- -------------------
SYSTEM     OBJETOS                        NO  20-07-2013 16:00:55
SYSTEM     OBJETOS                        YES 20-07-2013 16:00:59
SYSTEM     OBJETOS                        YES 20-07-2013 16:01:01

Nota : se muestran 3 registros pues se realizó una iteración de la consulta ;)


Espero les sirva


by Ligarius
20.07.13. 14:16:33. 484 words, 4320 views. Categories: Oracle 12c, Export-Import ,

Oracle 12c New Features : Exportar una vista como tabla (expdp)



En Oracle 12c nace una característica muy novedosa, el hecho de poder exportar la data de una vista y dejarla en un archivo dmp como tabla, o sea, se puede importar nuevamente, esto es extremadamente útil si tenemos tablas demasiado grandes para la conformación de la vista



El nuevo parámetro para exportar una vista como tabla es el parámetro VIEWS_AS_TABLES , que se conforma de la siguiente manera

VIEWS_AS_TABLES=usuario_dueño.nombre_vista:tabla_de_origen


En tabla_de_origen va el nombre de una de las tablas que componen el origen de la vista

El formato para exportar una vista es el siguiente

expdp usuario/password directory=data_pump_dir dumpfile=nombre.dmp VIEWS_AS_TABLES=usuario_dueño.nombre_vista:tabla_de_origen


Un ejemplo práctico

Tenemos la tabla1 y la tabla2 con los siguientes datos

ORACLE> select * from tabla1;

CAMPO1;CAMPO2
----------;--------
1;17/07/13
2;16/07/13
3;15/07/13

ORACLE> select * from tabla2;

CAMPO1;CAMPO3
----------;----------
1;Fecha 1
2;Fecha 2
3;Fecha 3


Creamos una vista con la siguiente estructura

create view v_consolida as
select tabla1.campo1 , tabla2.campo3
from tabla1, tabla2
where tabla1.campo1 = tabla2.campo1;


Y cuando consultamos sus datos aparece lo siguiente

ORACLE> select * from v_consolida;

CAMPO1;CAMPO3
----------;----------
1;Fecha 1
2;Fecha 2
3;Fecha 3


Procedemos a exportar la data de la vista , pero como tabla :>>

expdp system/oracle1@prod12c directory=DATA_PUMP_DIR dumpfile=sys_%u.dmp views_as_tables=sys.v_consolida:tabla2

Export: Release 12.1.0.1.0 - Production on Vie Jul 19 00:01:29 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates. 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
Iniciando "SYSTEM"."SYS_EXPORT_TABLE_03": system/********@prod12c directory=DATA_PUMP_DIR dumpfile=sys_%u.dmp views_as_tables=SYS.v_consolida:tabla2
Estimaci¾n en curso mediante el mÚtodo BLOCKS...
Procesando el tipo de objeto TABLE_EXPORT/VIEWS_AS_TABLES/TABLE_DATA
Estimaci¾n total mediante el mÚtodo BLOCKS: 64 KB
Procesando el tipo de objeto TABLE_EXPORT/VIEWS_AS_TABLES/TABLE
. . "SYS"."V_CONSOLIDA" 5.492 KB 3 filas exportadas
La tabla maestra "SYSTEM"."SYS_EXPORT_TABLE_03" se ha cargado/descargado correctamente
******************************************************************************
El juego de archivos de volcado para SYSTEM.SYS_EXPORT_TABLE_03 es:
C:\APP\INMETRICS-HECTOR\ADMIN\PROD\DPDUMP\SYS_01.DMP
El trabajo "SYSTEM"."SYS_EXPORT_TABLE_03" ha terminado correctamente en Vie Jul 19 00:01:37 2013 elapsed 0 00:00:06


Para importar la data de la vista , que ya se encuenta en el archivo, ocupamos el siguiente comando de impdp

impdp system/oracle1@prod12c directory=DATA_PUMP_DIR dumpfile=SYS_01.dmp tables=sys.v_consolida remap_table=sys.v_consolida:vista2

Import: Release 12.1.0.1.0 - Production on Vie Jul 19 00:06:27 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates. 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
La tabla maestra "SYSTEM"."SYS_IMPORT_TABLE_01" se ha cargado/descargado correctamente
Iniciando "SYSTEM"."SYS_IMPORT_TABLE_01": system/********@prod12c directory=DATA_PUMP_DIR dumpfile=SYS_01.dmp tables=sys.v_consolida remap_table=sys.v_consolida:vista1
Procesando el tipo de objeto TABLE_EXPORT/VIEWS_AS_TABLES/TABLE
Procesando el tipo de objeto TABLE_EXPORT/VIEWS_AS_TABLES/TABLE_DATA
. . "SYS"."VISTA1" 5.492 KB 3 filas importadas
El trabajo "SYSTEM"."SYS_IMPORT_TABLE_01" ha terminado correctamente en Vie Jul 19 00:06:31 2013 elapsed 0 00:00:02

NOTA : Se usa el REMAP_TABLE para cambiar el nombre de la tabla a crear en el import desde SYS.V_CONSOLIDA a VISTA1


Y al consultar la nueva tabla , esta aparece con datos que son iguales a los que tenía la vista

ORACLE> select * from vista1;

CAMPO1;CAMPO3
----------;----------
1;Fecha 1
2;Fecha 2
3;Fecha 3



Algunos errores a tener en cuenta

- Puede aparecer un mensaje de error de la siguiente forma al ejecutar un expdp, esto se debe a la tabla que estamos colocando en el parámetro VIEWS_AS_TABLES

Procesando el tipo de objeto TABLE_EXPORT/VIEWS_AS_TABLES/TABLE
ORA-31693: Fallo del objeto de datos de tabla "SYS"."V_CONSOLIDA" al cargarse/descargarse y se estß saltando debido al error:
ORA-00904: "CAMPO2": identificador no vßlido
La tabla maestra "SYSTEM"."SYS_EXPORT_TABLE_03" se ha cargado/descargado correctamente
******************************************************************************


- Si no se declara una de las tablas de origen , aparece el siguiente mensaje de error ej. parámetro VIEWS_AS_TABLES=SYS.v_consolida

Estimaci¾n total mediante el mÚtodo BLOCKS: 0 KB
ORA-39166: No se ha encontrado el objeto SYS.V_CONSOLIDA.
ORA-31655: no se ha seleccionado ningún objeto de datos ni de metadatos para el trabajo


- Si colocamos todas las tablas que componen la vista ejemplo VIEWS_AS_TABLES=SYS.v_consolida:tabla1,SYS.v_consolida.tabla2, aparece el siguiente mensaje de error (quizás sea un BUG)

ORA-39126: Error fatal inesperado de worker en KUPW$WORKER.MOVE_DATA [TABLE_DATA:"SYS"."V_CONSOLIDA"]
SELECT flags, NVL(target_xml_clob, xml_clob) FROM "SYSTEM"."SYS_EXPORT_TABLE_04" WHERE process_order > 0 AND duplicate = 0 AND object_schema = :1 AND object_name = :2 AND object_type
tition_name IS NULL AND subpartition_name IS NULL
ORA-01422: la recuperaci¾n exacta devuelve un n·mero mayor de filas que el solicitado
ORA-01403: No se ha encontrado ning·n dato


Aunque aún me quedan dudas con esta nueva característica , los invito a probarla, quizás sea de su gusto.

Espero les sirva


by Ligarius
17.07.13. 22:46:49. 890 words, 3543 views. Categories: Oracle 12c ,

Oracle 12c New Features : Movimiento de datafiles ONLINE



En Oracle 11gr2 y versiones más antiguas de Oracle para poder mover un datafile de ubicación , teníamos que dejar el datafile OFFLINE, copiar por sistema operativo o RMAN y hacer un ALTER DATABASE RENAME.

Pues bien , una nueva característica en Oracle 12c, nos permite realizar este movimiento en línea sin que nuestros aplicativos tengan que sufrir una pérdida de servicios.



El formato del comando

ALTER DATABASE MOVE DATAFILE 'origen' to 'destino';

He aquí un ejemplo :

1.- Chequeo mis datafiles, su status y el tamaño (Puede apreciarse que no es instancia productiva :) )

FILE_NAME                                                   ;STATUS   ;        GB
------------------------------------------------------------;---------;----------
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\UNDOTBS01.DBF          ;AVAILABLE;,708007813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSAUX01.DBF           ;AVAILABLE;,693359375
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSTEM01.DBF           ;AVAILABLE; ,76171875
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\USERNEW01.DBF          ;AVAILABLE;,004882813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLE.DBF            ;AVAILABLE;         1


2.- Ejecuto el comando para realizar el movimiento

16:58:00 SQL> alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew011.dbf';

Database altered.

Elapsed: 00:01:27.73

Muestro los tiempos sólo para tener una idea y proyectar algún movimiento a futuro, 1GB en 1,5 minutos app


3.- Vuelvo a consultar mis datafiles y realmente aparece el nuevo datafile y mientras se hacía el movimiento , se puede consultar la tabla y los aplicativos sin problemas.

FILE_NAME                                                   ;STATUS   ;        GB
------------------------------------------------------------;---------;----------
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\UNDOTBS01.DBF          ;AVAILABLE;,708007813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSAUX01.DBF           ;AVAILABLE;,693359375
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\SYSTEM01.DBF           ;AVAILABLE; ,76171875
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\USERNEW01.DBF          ;AVAILABLE;,004882813
C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLENEW01.DBF       ;AVAILABLE;         1


Si quisiera hacer un movimiento de un datafile que se encuentre en modo OFFLINE, daría un error como el que sigue

23:12:55 ORACLE> alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew01.dbf';
alter database move datafile 2 to 'c:\app\inmetrics-hector\oradata\prod\examplenew01.dbf'
*
ERROR at line 1:
ORA-01135: el archivo 2 accedido para LMD/consulta está offline
ORA-01110: archivo de datos 2: 'C:\APP\INMETRICS-HECTOR\ORADATA\PROD\EXAMPLE.DBF'

Elapsed: 00:00:00.15


Algunas consideraciones y observaciones a tener en cuenta :

- Este comando es extremadamente útil para realizar el movimiento de un datafile desde un storage a otro

- Con este comando se puede un datafile desde Filesystem a ASM y viceversa

- Al momento de ejecutar el comando , Oracle genera una copia del datafile en la nueva ruta o con el nuevo nombre que se le indica, una vez completada la instrucción se borra el datafile antiguo, sólo en ambiente Windows el datafile antiguo se deja y se debe eliminar en forma manual

- Se debe considerar el mismo espacio libre que el datafile que se está queriendo mover, dado que Oracle generará una copia del datafile , haciendo el parangón, es como el REBUILD INDEX ONLINE

- Las bases de datos Standby no se ven afectadas por un comando para mover un datafile , ni la primaria se ve afectada cuando se mueve un datafile en la Standby, funcionan como 2 entes diferentes.

- Si queremos ocupar un FLASHBACK hasta antes del cambio del datafile, el datafile seguirá estando en la ruta nueva, pero los datos cambiarán, o sea, el datafile no se reubica en la nueva posición

- Sólo se pueden mover de está forma los datafiles ONLINE, si los datafiles están OFFLINE arroja un error y se tiene que ocupar otro mecanismo

- El tema de performance debiese ser analizado más en profundidad, no creo que el tema sea total y absolutamente inocuo para el aplicativo, por lo menos en las pruebas realizadas, no encontré grandes diferencias de tiempo en las consultas que se ejecutaron antes, durante y después del movimiento del datafile en forma ONLINE.

- Si estamos en un ambiente UNIX, se puede ocupar la claúsula KEEP con lo cual al realizar la copia no se elimina el datafile antiguo, sólo se mantiene en la ruta nueva, el formato del comando

ALTER DATABASE MOVE DATAFILE 'nombre datafile' to 'nueva ruta datafile' KEEP;



by Ligarius
17.07.13. 09:55:05. 670 words, 2560 views. Categories: Tuning / Performance, Oracle 12c ,

Oracle 12c New Features : Último login en SqlPlus



Una de las nuevas características de Oracle está dado por una sutileza en seguridad..

De ahora en adelante cada vez que nos conectemos a Sql*Plus nos dará la última conexión válida , lo cual puede tener algo de significancia para algunas personas... |-|



Está información es almacenada en la tabla SYS.USER$ , la pueden consultar con el siguiente SQL

select name ,
to_char(spare6,'dd-mm-yyyy hh24:mi:ss')
from sys.user$
where name like '&1';


Algunas obervaciones :

- Deben tener cuidado en sacar la diferencia horaria de la hora que muestra la tabla SYS.USER$ , nosotros en Santiago de Chile somos UTC -04:00 , por eso la fecha del campo spare6 muestra 4 horas más.

- Para el usuario SYS , no se muestra la última conexión :|

- Solamente muestra las últimas conexiones a SQL*Plus, si me conecto a RMAN con el mismo usuario, esto no queda registrado como última conexión....malo malo |-|

Espero les sirva

by Ligarius
16.07.13. 22:28:38. 164 words, 3889 views. Categories: Oracle 12c, Sql*Plus ,

Oracle 12c New Features : Columnas con autoincremento (IDENTITY)



En Oracle 12c, se generá un nuevo tipo de columna , conocida como IDENTITY, la gracia de estás columnas es que son autonumérica,o sea, van generando de forma automática una secuencia cada vez que le insertamos un registro.

He aquí un ejemplo básico

CREATE TABLE tabla1 (secuencia NUMBER GENERATED AS IDENTITY ,
fecha date);


Cuando se genera esta tabla , por defecto se genera una secuencia , la cual podemos ver con esta consulta

SELECT sequence_owner||'.'||sequence_name secuencia,
min_value,
max_value,
increment_by,
cycle_flag,
order_flag,
cache_size,
last_number
FROM dba_sequences
WHERE sequence_owner LIKE '%PROD1%';

SECUENCIA                              MIN_VALUE                         MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER
------------------------------------- ---------- --------------------------------- ------------ - - ---------- -----------
PROD1.ISEQ$$_92175                             1      9999999999999999999999999999            1 N N         20      1


Le asignamos un registro a la tabla

SQL> Insert into tabla1 (fecha) values (sysdate);

1 row created.


Con esto veremos como aumenta de forma automática la secuencia

SQL> select * from tabla1;

 SECUENCIA FECHA
---------- --------
         1 15/07/13


Si tratamos de insertar un valor en la columna que es de tipo IDENTITY, arrojará un error

SQL> Insert into tabla1 (secuencia, fecha) values (3,sysdate);
Insert into tabla1 (secuencia, fecha) values (3,sysdate)
*
ERROR at line 1:
ORA-32795: no se puede insertar una columna de identidad siempre generada


Podemos cambiar la definición de la tabla , para así de esta forma poder insertar datos en el campo sin que nos de un error por la autosecuencia

Creamos la tabla

1 CREATE TABLE tabla3 (secuencia NUMBER GENERATED BY DEFAULT AS IDENTITY ,
2* fecha date)
SQL> /

Table created.


Insertamos datos para que se genere la autosecuencia

SQL> insert into tabla3 (fecha) values (sysdate);

1 row created.

SQL> select * from tabla3;

SECUENCIA FECHA
---------- --------
1 15/07/13


Ahora le insertamos datos indicando el campo de forma explícita

SQL> insert into tabla3 (secuencia, fecha) values (2,sysdate);

1 row created.


Y le insertamos datos para que genere la autosecuencia

SQL> insert into tabla3 (fecha) values (sysdate);

1 row created.


Al momento de consultar la tabla, nos podemos dar cuenta que no hubo error, pero se repitio el valor de la secuencia

SQL> select * from tabla3;

 SECUENCIA FECHA
---------- --------
         1 15/07/13
         2 15/07/13
         2 15/07/13


Si el campo que es de tipo IDENTITY le agregamos una PK , el ideal es que el campo IDENTITY no sea creado con BY DEFAULT, pues esto puede provocar que haya una violación de constraints

SQL> alter table tabla3 add constraint tabla3_pk primary key (secuencia);

Table altered.

SQL> insert into tabla3 values (5,sysdate);

1 row created.

SQL> select * from tabla3;

 SECUENCIA FECHA
---------- --------
         5 15/07/13

SQL> insert into tabla3 (fecha) values (sysdate);

1 row created.

SQL> select * from tabla3;

 SECUENCIA FECHA
---------- --------
         5 15/07/13
         3 15/07/13

SQL> insert into tabla3 (fecha) values (sysdate);

1 row created.

SQL> select * from tabla3;

 SECUENCIA FECHA
---------- --------
         4 15/07/13
         5 15/07/13
         3 15/07/13

** Aca se iba a generar el número 5 a través del campo IDENTITY , pero no lo hará dado que se produce una violación de constraints
SQL> insert into tabla3 (fecha) values (sysdate);
insert into tabla3 (fecha) values (sysdate)
*
ERROR at line 1:
ORA-00001: restricción única (PROD1.TABLA3_PK) violada

** Adelantamos la secuencia en forma manual

SQL> select PROD1.ISEQ$$_92179.nextval from dual;

   NEXTVAL 
----------
         6

** Y ahora sí se puede activar la creación del campo mediante el uso de la secuencia
SQL> insert into tabla3 (fecha) values (sysdate);

1 row created.

SQL> select * from tabla3;

 SECUENCIA FECHA
---------- --------
         4 15/07/13
         7 15/07/13
         5 15/07/13
         3 15/07/13


Se debe tener en cuenta que la tabla al tener una columna IDENTITY tiene por debajo una secuencia trabajando, al tener una secuencia trabajando se puede crear la columna IDENTITY tal cual se crea una secuencia, o sea, podría tener una columna que con cada inserción avance de 10 en 10 , que sea un valor cíclico con máximo de 1000 por ejemplo.

CREATE TABLE tabla2 (secuencia NUMBER GENERATED AS IDENTITY (START WITH 100 INCREMENT BY 50) , fecha date);

La anterior tabla tiene un campo IDENTITY generado , que primero inserta 100, después 150, 200,250, etc

Espero les sirva

by Ligarius
15.07.13. 14:11:21. 646 words, 3633 views. Categories: Oracle 12c ,

<< 1 ... 4 5 6 7 8 9 10 11 12 13 14 ... 44 >>