Category: Oracle 12c

Oracle 12c New Features : Ejecución de sentencias SQL a través de RMAN



Una nueva característica de RMAN es la posibilidad de ejecutar las sentencias SQL a través del mismo PROMPT de RMAN.


Simplemente una escena de culto :)

Antes de Oracle 12c , las sentencias SQL se tenían que ejecutar ocupando el string sql y no todas las sentencias podían ser ejecutadas , un ejemplo de ello.

sql 'alter system checkpoint';


Pues bien , desde ahora no es necesario ocupar el string sql , se puede colocar la sentencia directamente , algunos ejemplos de las sentencias que se pueden ejecutar .

Podemos realizar un Switch logfile

RMAN> alter system switch logfile;

Statement processed


Crear tablas

RMAN> create table b (campo1 number);

Statement processed


Insertarle valores o ejecutar cualquier DML

RMAN> insert into b values (1);

Statement processed


Terminar las transacciones

RMAN> commit;

Statement processed


Crear usuarios

RMAN> create user test identified by test;

Statement processed


Consultar el diccionario de datos

RMAN> select * from v$instance;


O simplemente bajar y subir nuestra base de datos (Esto depende de los privilegios que posea el usuario)

RMAN> startup force

Oracle instance started
database mounted
database opened

Total System Global Area 521936896 bytes

Fixed Size 2404552 bytes
Variable Size 415239992 bytes
Database Buffers 96468992 bytes
Redo Buffers 7823360 bytes


La ejecución de un script mediante rman se puede hacer de la siguiente forma :

rman target usuario/password@string_de_conexion @script_a_ejecutar


Donde script_a_ejecutar puede ser lo que ustedes quieran y el resultado de ese script, lo pueden ver realizando la siguiente consulta

select * from v$rman_output;


Espero les sirva...

by Ligarius
23.08.13. 06:43:18. 250 words, 3420 views. Categories: Oracle 12c, RMAN (Recovery Manager) ,

Oracle 12c New Features : Invisible Columns



En Oracle 12c nace una nueva característica la de convertir columnas a INVISIBLES, la verdad y considerando todos los contras que tiene, no me parece que sea muy útil....quizás se amolde a alguna necesidad muy particular.. A continuación les explico los alcances de las columnas invisibles B)



Cualquier columna de alguna tabla Oracle se puede dejar INVISIBLE , esto implica que la columna no será usada de manera habitual , las operaciones que no consideran la columna INVISIBLE son las siguientes :

- SELECT * FROM
- Comando DESCRIBE en SQL*Plus
- El tipo de datos %ROWTYPE en una declaración de Pl/Sql


Una columna que se deje como INVISIBLE se puede dejar como visible nuevamente mediante el comando ALTER TABLE Ejemplos de lo mencionado :


Creamos una tabla y le indicamos que una de sus columnas será INVISIBLE

Create table t1
(campo1 number ,
campo2 number ,
campo3 varchar2(100),
campo4 number INVISIBLE
)


Si realizamos un DESCRIBE de la tabla no aparecerá la columna que dejamos como inválida

ORACLE> desc t1
 Name                                              Null?    Type
 ------------------------------------------------- -------- ---------
 CAMPO1                                                     NUMBER
 CAMPO2                                                     NUMBER
 CAMPO3                                                     VARCHAR2(100)


Como podemos ver no aparece la columna INVISIBLE, está columna la podemos ver a través de SQL*Plus si realizamos el seteo con SET COLINVISIBLE ON

ORACLE> set colinvisible on
ORACLE> desc t1
 Name                                              Null?    Type
 ------------------------------------------------- -------- ---------
 CAMPO1                                                     NUMBER
 CAMPO2                                                     NUMBER
 CAMPO3                                                     VARCHAR2(100)
 CAMPO4 (INVISIBLE)                                         NUMBER


Si insertamos datos en la tabla con la columna invisible, le tenemos que indicar explicitamente que insertamos datos en esa columna

ORACLE> insert into t1 (campo1, campo2 , campo3 , campo4 ) values (1,2,'a',4);

1 row created.


Si insertamos datos, sin indicarle que lo haremos en una de sus columnas invisibles , pues aparece un error

ORACLE> insert into t1 values (1,2,'a',4);
insert into t1 values (1,2,'a',4)
*
ERROR at line 1:
ORA-00913: too many values


Si ejecutamos un SELECT sobre la tabla también le debemos indicar la columna invisible, pues un SELECT * FROM no mostrará la columna

ORACLE> select * from t1; --> A pesar de que ejecutamos un SELECT * , no aparece la columna INVISIBLE

    CAMPO1;    CAMPO2;CAMPO3
----------;----------;--------
         1;         2;a


ORACLE> select campo1 , campo2 , campo3 , campo4 from t1;

    CAMPO1;    CAMPO2;CAMPO3      ;    CAMPO4
----------;----------;------------;----------
         1;         2;a           ;         4


Los comandos para dejar VISIBLE o INVISIBLE una columna

alter table t1 modify campo4 invisible;
alter table t1 modify campo4 visible;


Restricciones :
- Las tablas externas no pueden tener columnas invisibles
- Las tablas en cluster no pueden tener columnas invisibles
-

Inconvenientes :
- Cada vez que se lleva a cabo el ocultamiento de una columna se le cambia el orden en que se visualiza cuando se ejecuta un DESCRIBE
He acá un ejemplo :

Creamos la tabla y hacemos un describe para visualizar el orden de las columnas

  1  Create table t2
  2  (campo1 number ,
  3  campo2 number ,
  4  campo3 varchar2(100),
  5  campo4 number invisible
  6* )
ORACLE> /

Table created.

ORACLE> desc t2
 Name                   Null?    Type
 --------------------   ------- ----------
 CAMPO1                         NUMBER
 CAMPO2                         NUMBER
 CAMPO3                         VARCHAR2(100)
 CAMPO4 (INVISIBLE)             NUMBER  
Nota : Se aprecia el orden de las columnas


 ORACLE> alter table t2 modify campo1 invisible;

Table altered.

ORACLE> desc t2
 Name                       Null?    Type
 -------------------------- -------- --------
 CAMPO2                              NUMBER
 CAMPO3                              VARCHAR2(100)
 CAMPO1 (INVISIBLE)                  NUMBER
 CAMPO4 (INVISIBLE)                  NUMBER
Nota : Cambia el orden de las columnas

ORACLE> alter table t2 modify campo1 visible;

Table altered.

ORACLE> desc t2
 Name                  Null?    Type
 --------------------- -------- --------
 CAMPO2                         NUMBER
 CAMPO3                         VARCHAR2(100)
 CAMPO1                         NUMBER
 CAMPO4 (INVISIBLE)             NUMBER
Nota : Las columnas siguen en el orden en que quedaron


Como dato importante, sobre este tipo de columnas se pueden crear índices y estos no se verán afectados y el optimizador seguirá tomando en cuenta estás columnas, aunque estén como INVISIBLES


Es una característica que existe, pero la verdad....no encuentro que sea muy útil, es más , creo que puede ser perjudicial para nuestras aplicaciones



by Ligarius
13.08.13. 13:59:18. 626 words, 3565 views. Categories: Oracle 12c ,

Oracle 12c New Features : Aumento de largo en columnas VARCHAR2, NVARCHAR2 y RAW



En Oracle 12c existe una nueva funcionalidad relacionada al largo que le podemos asignar a un campo varchar2, nvarchar2 o raw.


PD : Quito , Ecuador.... ya pronto iremos para esos lugares :)




Para versiones anteriores a 12c, sólo podíamos asignar hasta 4000 bytes , he acá un ejemplo

SQL> create table a (campo1 varchar2(4000));

Table created.


Pero si queriamos asignar un valor mayor, nos reclama por el largo para ese tipo de datos

SQL> create table b (campo1 varchar2(4001));
create table b (campo1 varchar2(4001))
*
ERROR at line 1:
ORA-00910: specified length too long for its datatype


En Oracle12c se puede ampliar el valor del largo de los tipos de campo varchar2, nvarchar2 y raw , hasta los 32Kb , para realizar esto se debe modificar una variable de inicio llamada MAX_STRING_SIZE.


La aplicación de este cambio requiere un pequeño análisis y algunos puntos a tener en cuenta, como por ejemplo

- La variable de inicialización MAX_STRING_SIZE acepta 2 valores, el STANDARD, con el cual los tipos de datos VARCHAR2, NVARCHAR2 y RAW aceptan largos hasta 4000 bytes y el valor EXTENDED que permite que esos tipos de datos lleguen hasta 32Kb.
- Se puede cambiar el parámetro desde STANDARD a EXTENDED, pero no viceversa.
- Cuando se hace la modificación al parámetro MAX_STRING_SIZE , puede ser que queden objetos inválidos por el cambio del largo de ciertos tipos de datos.
* Las tablas con columnas virtuales también podrían verse afectadas, quedando inválidas.
* Vistas y vistas materializadas también podrían verse afectadas.

Un ejemplo práctico de como modificar ese campo

- Bajamos la base de datos

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.


- Reiniciamos la base de datos en modo UPGRADE

SQL> startup upgrade

ORACLE instance started.

Total System Global Area 521936896 bytes
Fixed Size 2404552 bytes
Variable Size 385879864 bytes
Database Buffers 125829120 bytes
Redo Buffers 7823360 bytes
Database mounted.
Database opened.


- Cambiamos el valor del parámetro

SQL> show parameter MAX_STRING

NAME TYPE VALUE
------------------------------------ ----------- -----------------------------
max_string_size string STANDARD

SQL> alter system set MAX_STRING_SIZE='EXTENDED' scope=both;

System altered.

Nota : Si tratamos de cambiar el valor del parámetro y la base de datos no ha sido levantada en modo UPGRADE aparece el siguiente mensaje de error

ORA-14694: database must in UPGRADE mode to begin MAX_STRING_SIZE migration


- Ejecutamos el script de cambio del diccionario de datos (utl32k.sql)

SQL> @?/rdbms/admin/utl32k.sql

Session altered.

DOC>#######################################################################
DOC>#######################################################################
DOC> The following statement will cause an "ORA-01722: invalid number"
DOC> error if the database has not been opened for UPGRADE.
DOC>
DOC> Perform a "SHUTDOWN ABORT" and
DOC> restart using UPGRADE.
DOC>#######################################################################
DOC>#######################################################################
DOC>#

no rows selected

DOC>#######################################################################
DOC>#######################################################################
DOC> The following statement will cause an "ORA-01722: invalid number"
DOC> error if the database does not have compatible >= 12.0.0
DOC>
DOC> Set compatible >= 12.0.0 and retry.
DOC>#######################################################################
DOC>#######################################################################
DOC>#

PL/SQL procedure successfully completed.

Session altered.

1215 rows updated.

Commit complete.

System altered.

PL/SQL procedure successfully completed.

Commit complete.

System altered.

Session altered.

PL/SQL procedure successfully completed.

No errors.

Session altered.

PL/SQL procedure successfully completed.

Commit complete.

Package altered.

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2013-08-12 12:48:20

DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#

PL/SQL procedure successfully completed.

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END 2013-08-12 12:54:52

DOC> The following query reports the number of objects that have compiled
DOC> with errors.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
-------------------
3

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
3

Function created.

PL/SQL procedure successfully completed.

Function dropped.

Warning: XDB now invalid, could not find xdbconfig

PL/SQL procedure successfully completed.

SQL>


- Se reinicia la base de datos en forma normal

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup

ORACLE instance started.

Total System Global Area 521936896 bytes
Fixed Size 2404552 bytes
Variable Size 406851384 bytes
Database Buffers 104857600 bytes
Redo Buffers 7823360 bytes
Database mounted.
Database opened.


- Y desde ahora en adelante, se pueden generar columnas con un tamaño hasta 32767 bytes

SQL> create table t10 (campo1 varchar2(32767));

Table created.


Nota2 : Si tratamos de cambiar el parámetro de EXTENDED a STANDARD aparece un mensaje de error, dado que el cambio es irreversible

SQL> alter system set MAX_STRING_SIZE='STANDARD' scope=both;
alter system set MAX_STRING_SIZE='STANDARD' scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED.

Espero les sirva

by Ligarius
12.08.13. 11:46:00. 1098 words, 2997 views. Categories: Oracle 12c ,

ORA-65093: container database not set up properly



Una de las nuevas características de Oracle 12c es el concepto de Oracle Database Multitenant, en esta arquitectura un componente básico es es el CDB u Oracle Containers Database, la cual contendrá las PDBs o Pluggable Databases.

Si estás tratando de generarlas de forma manual o al levantarla te da el siguiente error

SQL> startup nomount
ORACLE instance started.

Total System Global Area 521936896 bytes
Fixed Size 2404552 bytes
Variable Size 335548216 bytes
Database Buffers 176160768 bytes
Redo Buffers 7823360 bytes

ORA-65093: container database not set up properly


Es porque sencillamente el archivo de inicialización de la instancia CDB , no posee el siguiente parámetro

*.enable_pluggable_database=TRUE


Espero les sirva

by Ligarius
30.07.13. 22:30:06. 111 words, 4861 views. Categories: Oracle 12c ,

Scripts para creación de bases Oracle 12c en forma manual



Este post habla de como crear bases de datos 12c en forma manual , la verdad es muy similar a 11gr2, pero para quienes necesiten ver los pasos a pasos, redacto el post ..


Obs: Bueno, no podía faltar :>>

Para Oracle12c con filesystems

1.- Creación del archivo de inicialización por ejemplo /home/oracle/initprod12c.ora el cual debiese contener los siguientes parámetros

*.control_files='/home/oracle/prod12c/oradata/control01.ctl'
*.db_name='prod12c'
*.instance_name='prod12c'
*.memory_target=1g
*.undo_management = auto
*.db_block_size = 8192
*.diagnostic_dest = '/home/oracle/prod12c/diag'



2.- Se crea los directorios que ocuparemos para nuestra base de datos , con el usuario oracle

$ mkdir -p /home/oracle/prod12c/oradata
$ mkdir -p /home/oracle/prod12c/diag



3.- Levantamos sólo la instancia (startup nomount)

$ export ORACLE_SID=prod12c

$ sqlplus /nolog

SQL> conn / as sysdba

SQL> startup nomount pfile='/home/oracle/initprod12c.ora'



4.- Ejecutamos el comando de creación de base de datos

CREATE DATABASE prod12c
USER SYS IDENTIFIED BY "oracle.,"
USER SYSTEM IDENTIFIED BY "oracle.,"
LOGFILE GROUP 1 ('/home/oracle/prod12c/oradata/redo01a.log') SIZE 50M BLOCKSIZE 512,
GROUP 2 ('/home/oracle/prod12c/oradata/redo02a.log') SIZE 50M BLOCKSIZE 512,
GROUP 3 ('/home/oracle/prod12c/oradata/redo03a.log') SIZE 50M BLOCKSIZE 512
MAXLOGHISTORY 1
MAXLOGFILES 32
MAXLOGMEMBERS 3
MAXDATAFILES 1024
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
EXTENT MANAGEMENT LOCAL
DATAFILE '/home/oracle/prod12c/oradata/system01.dbf'
SIZE 200M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
SYSAUX DATAFILE '/home/oracle/prod12c/oradata/sysaux01.dbf'
SIZE 250M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
DEFAULT TABLESPACE users
DATAFILE '/home/oracle/prod12c/oradata/users01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/home/oracle/prod12c/oradata/temp01.dbf'
SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED
UNDO TABLESPACE undotbs1
DATAFILE '/home/oracle/prod12c/oradata/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
USER_DATA TABLESPACE usertbs
DATAFILE '/home/oracle/prod12c/oradata/usertbs01.dbf'
SIZE 100M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;



5.- Una vez generada la base ejecutamos el scripts catalog.sql y el catproc.sql ambos scripts crean los Stores Procedures para el manejo del motor Oracle y crea todo el diccionario de datos .

SQL> @?/rdbms/admin/catalog.sql

SQL> @?/rdbms/admin/catproc.sql



6.- Creamos el archivo de password

cd $ORACLE_HOME/dbs

$ orapwd file=orapwprod12c password=oracle., entries=5



7.- Creamos el archivo de inicialización como spfile

SQL> create spfile from memory;



8.- Bajamos y subimos la base de datos para que reinicie con spfile

SQL> startup force



9.- Levantamos el listener, teniendo en cuenta que debe estar seteado el ORACLE_HOME y el PATH

lsnrctl start



Bueno, así de sencillo es crear una base de datos en Oracle 12c, casi no cambia de la versión anterior



Otros post relacionados
Creación de base de datos 11gr2 en forma manual
Creación de base de datos 10gr2 en forma manual
Creación de base de datos 9i en forma manual


by Ligarius
28.07.13. 21:17:45. 524 words, 3354 views. Categories: Oracle 12c, Instalación ,

<< 1 2 3 4 5 >>