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, 3867 views. Categories: Oracle 12c, RMAN (Recovery Manager) ,

¿Qué es un CRASH RECOVERY o INSTANCE RECOVERY?



¿Qué es un Crash Recovery o un instance Recovery?



Este concepto no es más que la recuperación de una base de datos Oracle sin intervención alguna después de que ha sufrido alguna caída inesperada, este tipo de caidas pueden ser provocadas por un corte de electricidad, desmontaje de un disco donde reside el motor, una eliminación manual de algún proceso background necesario (smon,pmon), un shutdown abort, etc.

Cuando sucede lo anterior, al levantar la base de datos esta por sí sola comienza el proceso de recuperación o crash recovery, pues es el System monitor (SMON) que detecta que Oracle no se bajo de la mejor forma y que algunos datafiles quedaron desincronizados con respecto al último SCN que queda registrado en el controlfile.

Para realizar un Crash Recovery Oracle utiliza la información que se encuentra en los redologs (técnicamente llamados online redologs), para lo anterior Oracle realiza algunos dos pasos importantes :

1.- Rolling Forward : En este proceso en partícular, Oracle va a actualizar todos los datafiles con TODA la información que encuentre en el último redologs utilizado hasta el momento de la caída, cabe recordar que Oracle escribe primero en los redologs y una vez escrito allí comienza a trasladar la información a los datafiles, es por eso que ante una caída abrupta de la base, hay ciertos registros o transacciones que no han sido pasada a los datafiles y que aún se encuentran en los redologs.

2.- Rolling Back : Con el proceso de "Rolling Forward" se pasaron todos los cambios encontrados en el último redolog utilizado hacía los datafiles y por cada cambio se generó una entrada en el tablespace de UNDO, pues bien, NO TODAS las transacciones que se aplicaron en los datafiles fueron "Comiteadas" , o sea, existen algunas transacciones a las cuales se les aplico un Rollback, pero esto Oracle no tiene como saberlo dado que los archivos de redologs son secuenciales, el no sabe si por delante de una transacción cualquiera
viene un commit o un rollback , si se traspaso a los datafiles una transacción que posteriormente se le aplicó un rollback, pues Oracle saca la información anterior desde el tablespace de UNDO, el cual se fue llenando de información a partir del proceso de Rolling Forward.

Cuando el punto 2 finaliza, sólo información realmente comiteada queda en los datafiles y es allí donde la base de datos queda en estado OPEN.

En el punto 1 , Oracle va a aplicar todas las transacciones que se encuentran entre el último Checkpoint que se produjo en la base de datos (que se encuentra marcado dentro del archivo de redolog que estaba en estado CURRENT antes de la caída) y el final del mismo archivo de redolog, está cantidad de información es la que Oracle va a aplicar en los datafiles, esta cantidad de información puede ser controlada mediante un parámetro llamado FAST_START_MTTR_TARGET (la sigla MTTR viene de las palabras MEAN TIME TO RECOVER) , con este parámetro se le busca indicar a Oracle que cantidad de segundos el se debiese demorar en realizar un CRASH RECOVERY, Oracle es capaz mediante formulas internas de convertir esos segundos a cantidad de transacciones.

El máximo valor para el parámetro FAST_START_MTTR_TARGET es 3600 segundos , o sea, que Oracle en el peor de los casos se podría demorar hasta una hora en hacer un CRASH RECOVERY después de una caida abrupta

by Ligarius
20.08.13. 07:42:32. 593 words, 5189 views. Categories: Base de datos, Conceptual ,

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, 4026 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, 3263 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, 5194 views. Categories: Oracle 12c ,

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