EXIST, NOT EXIST, IN , NOT IN

Son iguales??? hay diferencias????

EXIST e IN, son sustituibles semánticamente, pero en cuanto a performance hay que analizar cual se debe utilizar:

Dependerá del cada caso en particular, pero como regla general podemos utilizar la cantidad de filas que tienen las tablas en la consulta.

Si la tabla de la sub consulta tiene muchas filas y la de “afuera” es chica se debe utilizar EXIST, por otro lado si la tabla de “afuera” es grande y la de “adentro” es chica se debe utilizar IN.

En cuanto a Not EXIST y NOT IN la cosa es diferente: NO SON SEMANTICAMENTE IGUALES ya que los NULLs en la subconsulta producen diferencias (serán semánticamente iguales si la sub consulta no devuelve NULLS).

En cuanto a la performance NOT IN, si hay nulls, es el enemigo!!! Es totalmente ineficiente… es necesario cambiarlo por NOT EXIST!

Por qué NOT IN y NOT EXIST no son iguales semánticamente cuando hay nulos?

Eso queda para el siguiente post :D
Pero vayan sabiendo que no es lo mismo..y tienen que utilizar Not Exist !!!

Como saber hace cuanto tiempo que esta levantada nuestra base ?

Asi como el valor de UPTIME para los sysadmin, el tiempo que tenemos la base sin caidas puede ser un elemento de orgullo para un DBA.

Asi que ya saben.. para levantarnos la moral , o no :( , viendo el uptime de la base :

SELECT to_char(startup_time,'DD-MON-YYYY HH24:MI:SS') "DB Startup Time"
FROM sys.v_$instance;

Dar todos los privilegios a un usuario sobre un ROL

Por qué ??????? POR QUE NO PUEDO DARLE TODOS LOS PRIVILEGIOS A UN USUARIO DE UNA ?????????

Esto es una pregunta que pasa todo el tiempo!!!!

Es muy comun tener un usuario "aplicacion" donde creo todos los objetos.. es decir es el schema owner (o dueño de esquema) y luego querer que otros usuarios, usuarios de verdad, se conecten y puedan acceder a todos los objetos del usuario "aplicacion" !!!!!

Entonces porque no puedo hacer GRANT ALL schema_name TO pepe!!!!!!!

bueno... no entiendo porque pero la forma de hacerlo es darle los privs de a uno.. aca va una forma "FACIL" de hacerlo:


FOR x IN (SELECT table_name FROM dba_tables WHERE owner=<>)
LOOP
EXECUTE IMMEDIATE 'GRANT SELECT ON <>.' x.table_name ' TO <>';
END LOOP;

Luego que le dimos todos los privs a un rol...le damos ese rol al usuario que geremos
grant rol_name to usuer_name

y por utlimo.. para que el usuario no tenga que poner el nombre del esquema antes de cada tabla.. le podemos decir que el current_schema del usuario es el del usuario "aplicacion" para eso hacemos un trigger que ejecute luego que se conecte.. el famoso after_logon:

CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/

obviamente hay gente que sabe y de alli sale la info:

http://forums.oracle.com/forums/thread.jspa?threadID=936165
http://www.oracle-base.com/articles/misc/SchemaOwnersAndApplicationUsers.php

ver script de creacion de un objeto -- dbms_metadata

Muchas veces necesitamos saber saber como crear un objeto.

Tipicamente las vistas es un objeto que comunmente queremos saber como fue creado, para saber cual es la sentencia sql que ejecuta.

para saber la sentencia ddl que permite crear un objeto se puede consular el paquete dbms_metadata
principalmente el metodo get_ddl. Que recibe 3 parametros (en una de sus invocaciones)

1 - tipo de objeto, en los ejemplos se muestra para los objetos TABLE y VIEW
2 - El nombre del objeto, en el ejemplo, TABLA1 y P (nombre de la vista)
3- El esquma donde se encuentra el objeto , en el ejemplo , SCOOT Y USUARIO

ES IMPORTANTE QUE TODOS LOS NOMBRES TIENEN QUE ESTAR EN MAYUSCULAS YA QUE SON STRING Y ORACLE LOS GUARDA CON MAYUSCULAS.


como es un paquete no se puede ejecutar asi nomas, hay 2 formas basicas:
cargar el resultado en la tabla DUAL:

select dbms_metadata.get_ddl('TABLE','TABLA1','SCOTT') from dual;

O hacer un script que escriba en la consola:

begin
dbms_output.put_line(dbms_metadata.get_ddl('VIEW','P','USUARIO'));
end;
/

ORA-01031: insufficient privileges - al conectarse o al levantar (startup) la Base

el error ORA-01031: insufficient privileges puede darse en 2 circunstancias principalmente,

Una, cuando queremos crear/consultar, etc un objeto, en ese caso deberemos darle permisos de para crear/consultar, etc. A través de la sentencias GRANT …..

Pero también nos puede dar problemas al tratar de conectarse a la base o al tratar de levantarla. Si pasa eso es posiblemente porque el usuario no pertenezca al grupo ora_dba si estamos trabajando en Windows o dba si estamos en LINUX.

En Windows se soluciona de la siguiente manera:

c:> net localgroup ora_dba JuanPerez /add

¿Cuando fue la ultima vez que se realizo una operación de ddl sobre una tabla?

Recordemos que una operación de DLL o Data DefinitionLanguage es aquella que modifica la estructura, es decir:

CREATE
ALTER
DROP

Para saber cual el la fecha de creacion o cuando fue la ultima vez que se realizo una operación DDL sobre una tabla se puede realizar la siguente consulta.

select OBJECT_NAME, CREATED, LAST_DDL_TIME from user_objects where object_type='TABLE'

A que tablespace pertenece una tabla ???

Algo muy util cuando queremos achicar o reducir el espacio de nuetros datafiles o tablespaces es saber en que tablespace estan creados nuestros objetos,
es decir:
Las tablas (x ejemplo) se crean en un tablespace, el cual si no se especifica al momento de la creación se crearan en el tablespace que tiene por defecto el usuario, como es no pasa muchas veces, es bueno poder ubicar nuestros objetos.

para ello esta SQL es fundamental.


select tablespace_name,
owner ,
segment_name objeto,
file_id,
block_id,
CEIL(blocks*4/1024) MBytes
from dba_extents where owner='DOSNEW'

PD: cambiar DOSNEW por el nombre del usuario/esquema