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, 3773 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, 3098 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, 5002 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, 3651 views. Categories: Oracle 12c, Instalación ,

Active Session History (ASH) performed an emergency flush



Viendo un Oracle RAC versión 11.2.0.3 me percaté de este error en el archivo de alertas, pues bien lo que hice fue analizarlo un poco, he acá las conclusiones.


Foto de Quito , lugar que conoceré en Noviembre ;)

Este mensaje de warning se produce en versiones desde la 11.2.0.2 de Oracle Enterprise Edition y significa única y exclusivamente que Active Session History para su porción de memoria ASH tiene un tamaño muy pequeño para la cantidad de sesiones activas que se están produciendo, por ende tiene que vaciarla y dejarla en blanco para todos los nuevos registros, con esto se puede información histórica relacionada con el ASH (estadísticas de performance relacionadas a los usuarios)

Este error se puede pasar por alto, ya que indica que hubo un aumento significativo de las sesiones..si el error persiste, se puede realizar algo para evitar que aparezca en el archivo de alertas y gatille todos nuestros procesos de monitoreo.

Error textual desde el archivo de alertas

Tue Jul 23 10:14:38 2013
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring iss
ue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 13421772
8 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query: select total_size,awr_flush_emergency_count from v$ash_info;



Imagen de cantidad de sesiones en una instancia Oracle

Un síntoma relacionado al error, es por ejemplo una alta cantidad de usuarios activos , que va aumentando de forma exponencial.

Si queremos saber cuanto es el tamaño destinado al buffer ASH en memoria, pues podemos ejecutar la siguiente consulta

select total_size/1024/1024 Mb ,
awr_flush_emergency_count
from v$ash_info;

Nos muestra el tamaño del ASH y nos nuestra cuanta veces ha realizado un flush desde esta porción de memoria desde el último Startup

¿Cómo se soluciona este problema?
Para darle una solución al tema, se debe modificar el parámetro oculto _ash_size , pero como recomendación siempre háganlo a través de Soporte de Oracle, ya que como saben , la modificación de parámetros ocultos no está soportada.

El valor que se le debe asignar al parámetro es un 50% del valor actual y el comando sería algo así

alter system set "_ash_size"=valor 50% superior al existente scope=spfile;

Nota1 : Este cambio debe ser realizado con el usuario SYS
Nota2 : El ASH Buffer reside dentro de la Shared Pool


Espero les sirva


by Ligarius
23.07.13. 12:19:33. 442 words, 9538 views. Categories: Tuning / Performance, Oracle11gR2 ,

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