Oracle nos devulve "ORA-00054: recurso ocupado y obtenido con NOWAIT especificado" cuando por ejemplo queremos modificar la estrucutra de una tabla y alguien esta modificandola y no ha realizado commit.
Solucion, matar la session que tiene loqueada la tabla!!! ojo! el usuario perdera todas sus modificaciones!!
La consulta que hay que ejecutar para saber quien esta loqueando tablas para luego hacerle un kill es:
select object_name, o.object_id, sid, serial#, username, machine,osuser, program from user_objects o, v$locked_object l, v$session s
where o.object_id = l.object_id and l.session_id=s.sid
jueves, 21 de mayo de 2009
martes, 14 de abril de 2009
Clonar esquemas
Porque no se puede hacer clonar un schema o cliente de forma facil en oracle ???
no se.. nunca lo enternderé. estimado Juan Oracle.. algo así como clon user to user1 estaria formdiable!!!!
como eso no existe..tenemos que exportar y luego importar...pero no esta taaaannn fácil..
Veamos los detalle:
primero creamos un directorio, esto es porque con Oracle Data Pump es necesario crear el directorio de salida.
conectados com sys
create directory mydir as 'c:\dpdump';
grant read,write on directory mydir to pepe;
luego desde la linea de comando ejecutamos el expdp
expdp asanga/asa directory=mydir dumpfile=salidapepe.dmp schemas=pepe logfile=salidapepe.log
luego como sys (que es mas facil)
importamos el esquema en otro esquema a traves de la maravillosa palabra clava: remap_schemas
impdp directory=mydir dumpfile=salidapepe.dmp logfile=import2pepenew.log remap_schema=pepe:pepenew
mmmm....bueno no es taaannnn fácil si tenemos algunos detalles..Veamos:
si tenemos tipos creados por el objeto pepe necesitamos agregar
transform=oid:n:type en la sentencia del import
impdp directory=mydir dumpfile=salidapepe.dmp logfile=import2pepenew.log remap_schema=pepe:pepenew transform=oid:n:type
obviamente esta es la forma CHANCHA... ya que es como tener 2 tipos number en nuestra base...lo que deberiamos hacer es crear un esquema que solo tenga los tipos..y darle permisos al resto de los esquemas para que lo puedan utilizar.. pero tá..por ahora nos quedamos con la forma chancha !! :D
otra cosa a tener en cuenta es si el usuario tiene privilegios sobre todo si utilizamos STORE PROCEDURES que hacen uso de esos privilegios..
en ese caso.. antes de hacer el import...hay que CREAR EL USUARIO A MANO !!!!
create user pepenew identified by pepenew
Y DARLE LOS PRIVILEGIOS
para obtener los privilegios de pepe.. hay un montón de scripts en la vuelta... yo uso el del gran gurú y mentor pete finnigan que está muy bueno.
grant ...... to pepenew
y después ...solo después... hacemos el import.
y si... ....algo que tienen que ser....
clon user pepe pepenew
se transforma en un dolor de kbza!!! ponete las pilas Juan !!!
no se.. nunca lo enternderé. estimado Juan Oracle.. algo así como clon user to user1 estaria formdiable!!!!
como eso no existe..tenemos que exportar y luego importar...pero no esta taaaannn fácil..
Veamos los detalle:
primero creamos un directorio, esto es porque con Oracle Data Pump es necesario crear el directorio de salida.
conectados com sys
create directory mydir as 'c:\dpdump';
grant read,write on directory mydir to pepe;
luego desde la linea de comando ejecutamos el expdp
expdp asanga/asa directory=mydir dumpfile=salidapepe.dmp schemas=pepe logfile=salidapepe.log
luego como sys (que es mas facil)
importamos el esquema en otro esquema a traves de la maravillosa palabra clava: remap_schemas
impdp directory=mydir dumpfile=salidapepe.dmp logfile=import2pepenew.log remap_schema=pepe:pepenew
mmmm....bueno no es taaannnn fácil si tenemos algunos detalles..Veamos:
si tenemos tipos creados por el objeto pepe necesitamos agregar
transform=oid:n:type en la sentencia del import
impdp directory=mydir dumpfile=salidapepe.dmp logfile=import2pepenew.log remap_schema=pepe:pepenew transform=oid:n:type
obviamente esta es la forma CHANCHA... ya que es como tener 2 tipos number en nuestra base...lo que deberiamos hacer es crear un esquema que solo tenga los tipos..y darle permisos al resto de los esquemas para que lo puedan utilizar.. pero tá..por ahora nos quedamos con la forma chancha !! :D
otra cosa a tener en cuenta es si el usuario tiene privilegios sobre todo si utilizamos STORE PROCEDURES que hacen uso de esos privilegios..
en ese caso.. antes de hacer el import...hay que CREAR EL USUARIO A MANO !!!!
create user pepenew identified by pepenew
Y DARLE LOS PRIVILEGIOS
para obtener los privilegios de pepe.. hay un montón de scripts en la vuelta... yo uso el del gran gurú y mentor pete finnigan que está muy bueno.
grant ...... to pepenew
y después ...solo después... hacemos el import.
y si... ....algo que tienen que ser....
clon user pepe pepenew
se transforma en un dolor de kbza!!! ponete las pilas Juan !!!
lunes, 13 de abril de 2009
Crear Tablas en un Store procedure PL/SQL - ORA-01031: insufficient privileges
Bueno... aquí hay un poblemita, que si bien es muy facil de solucionar es "raro" que luego de tantas versiones siga pasando.... :D
el tema es el siguiente.. Crear un tabla dentro de un Porcedimiento.
si ejecutamos CREATE TABLE pepe (....... desde linea de comando funciona perfectamente...pero si lo hacemos :
script_crear := 'CREATE TABLE PEPE (NUM NUMBER ,DATOS VARCHAR2(50))';
EXECUTE IMMEDIATE script_crear;
Nos devuleve el error:
ORA-01031: insufficient privileges
Solucion: Dar los permisos de forma directa, es decir.
grant create table to usuario.
Por que pasa esto?? bueno el "problemita" se da porque los ROLES no son tomados en los procedimientos PLSQL, es decir si tenemos un permiso obtenido a través de un ROL, este permiso no lo tendremos dentro de los procedimientos o funciones PL/SQL, mmmm bueno, en si... si lo ejecutamos en un bloque anonimo funcionaria pero.. más facil es darle el permiso de forma directa y problema solucionado.
Como siempre hay un buen link, con comentarios de gente que sabe :D
http://forums.oracle.com
el tema es el siguiente.. Crear un tabla dentro de un Porcedimiento.
si ejecutamos CREATE TABLE pepe (....... desde linea de comando funciona perfectamente...pero si lo hacemos :
script_crear := 'CREATE TABLE PEPE (NUM NUMBER ,DATOS VARCHAR2(50))';
EXECUTE IMMEDIATE script_crear;
Nos devuleve el error:
ORA-01031: insufficient privileges
Solucion: Dar los permisos de forma directa, es decir.
grant create table to usuario.
Por que pasa esto?? bueno el "problemita" se da porque los ROLES no son tomados en los procedimientos PLSQL, es decir si tenemos un permiso obtenido a través de un ROL, este permiso no lo tendremos dentro de los procedimientos o funciones PL/SQL, mmmm bueno, en si... si lo ejecutamos en un bloque anonimo funcionaria pero.. más facil es darle el permiso de forma directa y problema solucionado.
Como siempre hay un buen link, con comentarios de gente que sabe :D
http://forums.oracle.com
miércoles, 1 de abril de 2009
ORA-02449 Cuando queremos borrar o truncar una tabla
ORA-02449: claves únicas/primarias en la tabla referidas por claves ajenas
Para saber cueles son FK que apuntan a mi tabla se puede ejecutar la siguiente consulta:
SELECT A.CONSTRAINT_NAME, A.TABLE_NAME, B.COLUMN_NAME,
B.COLUMN_NAME AS REFERENCED_COLUMN_NAME,
B.TABLE_NAME AS REFERENCED_TABLE_NAME
FROM USER_CONSTRAINTS A, USER_CONS_COLUMNS B
WHERE A.CONSTRAINT_TYPE = 'R' AND A.R_CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.TABLE_NAME = 'CUSTOMERS'
pd: cambiar 'CUSTOMERS' por el nombre de la tabla
Para saber cueles son FK que apuntan a mi tabla se puede ejecutar la siguiente consulta:
SELECT A.CONSTRAINT_NAME, A.TABLE_NAME, B.COLUMN_NAME,
B.COLUMN_NAME AS REFERENCED_COLUMN_NAME,
B.TABLE_NAME AS REFERENCED_TABLE_NAME
FROM USER_CONSTRAINTS A, USER_CONS_COLUMNS B
WHERE A.CONSTRAINT_TYPE = 'R' AND A.R_CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.TABLE_NAME = 'CUSTOMERS'
pd: cambiar 'CUSTOMERS' por el nombre de la tabla
martes, 31 de marzo de 2009
Reducir el tamaño de los datafiles
Antes que nada hablemos porque quicieramos reducir el tamaño, pueden pasar 2 cosas:
a) creamos el datafile de un tamaño que nunca vamos a llegar y por eso lo queremos reducir
b) lo creamos autoextend y por lo tanto cuando insertamos aumenta su tamaño, pero luego al borrar las filas o tablas .....NO RECUERA EL TAMAÑO !!!!
Para reducir el tamaño ORACLE proporciona el comando RESIZE, pero ya veremos que no es "muy inteligente".
Para saber cuanto espacio tenemos disponible y candidato a achicar se puede ejecutar la siguiente cosulta:
select dba_data_files.file_id, dba_data_files.file_name , sum(dba_free_space.bytes)/1024/1024 mega
from dba_free_space, dba_data_files
where dba_free_space.file_id = dba_data_files.file_id
group by dba_data_files.file_id, dba_data_files.file_name
y por ejemplo da el siguiente resultado:
3 C:\ORACLE\ORADATA\ORCL\SYSAUX01.DBF 10
5 C:\ORACLE\ORADATA\ORCL\EXAMPLE01.DBF 20
1 C:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF 6,01
2 C:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF 150.3
4 C:\ORACLE\ORADATA\ORCL\USERS01.DBF 100.7
Esta consulta devuleve el espacio libre que hay, por lo que como máximo podrías bajar 100 Mg. y monedas, del datafile users01.dbf
OJO!!!!
En REALIDAD, lo que te devuelve el tamaño libre a partir de todas las HWM (high water mark) de las tablas, es decir el tamaño máximo que tuvieron alguna vez.
Por ejemplo la tabla t tiene 10m de datos y 10mg de “huecos” el espacio libre se calcula como si la tabla tuviera 20m. se entiende?
En otras palabras, se podría bajar 100mg de tu datafile USERS01.DBF. si tener que lidiar con los huecos.
Bueno.. esto es util si NO TENEMOS HUECOS.... cosa que NUNCA PASA !!!!! la vida no puede ser tan sensilla :D
Entonces que hacemos:
Bueno.. existen 2 opciones:
a) el magico "SHRINK" que por desgracia solo aplica a tablas y tablespaces temporales. no a los de datos :(
b) mover los datos a un nuevo datafile y borrar el anterior.
veamos cada una de las opciones
Nota: Si tenes metalink y queres algo más de info, podes ver las siguientes notas de nuestros amigos de ORACLE:
Nota: 1029252.6 - How to Resize a Datafile
Nota: 130866.1 - How to Resolve ORA-03297 When Resizing a Datafile by Finding the Table Highwatermark
Nota: 237654.1 - Resizing a Datafile Returns Error ORA-03297
a) creamos el datafile de un tamaño que nunca vamos a llegar y por eso lo queremos reducir
b) lo creamos autoextend y por lo tanto cuando insertamos aumenta su tamaño, pero luego al borrar las filas o tablas .....NO RECUERA EL TAMAÑO !!!!
Para reducir el tamaño ORACLE proporciona el comando RESIZE, pero ya veremos que no es "muy inteligente".
Para saber cuanto espacio tenemos disponible y candidato a achicar se puede ejecutar la siguiente cosulta:
select dba_data_files.file_id, dba_data_files.file_name , sum(dba_free_space.bytes)/1024/1024 mega
from dba_free_space, dba_data_files
where dba_free_space.file_id = dba_data_files.file_id
group by dba_data_files.file_id, dba_data_files.file_name
y por ejemplo da el siguiente resultado:
3 C:\ORACLE\ORADATA\ORCL\SYSAUX01.DBF 10
5 C:\ORACLE\ORADATA\ORCL\EXAMPLE01.DBF 20
1 C:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF 6,01
2 C:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF 150.3
4 C:\ORACLE\ORADATA\ORCL\USERS01.DBF 100.7
Esta consulta devuleve el espacio libre que hay, por lo que como máximo podrías bajar 100 Mg. y monedas, del datafile users01.dbf
OJO!!!!
En REALIDAD, lo que te devuelve el tamaño libre a partir de todas las HWM (high water mark) de las tablas, es decir el tamaño máximo que tuvieron alguna vez.
Por ejemplo la tabla t tiene 10m de datos y 10mg de “huecos” el espacio libre se calcula como si la tabla tuviera 20m. se entiende?
En otras palabras, se podría bajar 100mg de tu datafile USERS01.DBF. si tener que lidiar con los huecos.
Bueno.. esto es util si NO TENEMOS HUECOS.... cosa que NUNCA PASA !!!!! la vida no puede ser tan sensilla :D
Entonces que hacemos:
Bueno.. existen 2 opciones:
a) el magico "SHRINK" que por desgracia solo aplica a tablas y tablespaces temporales. no a los de datos :(
b) mover los datos a un nuevo datafile y borrar el anterior.
veamos cada una de las opciones
Nota: Si tenes metalink y queres algo más de info, podes ver las siguientes notas de nuestros amigos de ORACLE:
Nota: 1029252.6 - How to Resize a Datafile
Nota: 130866.1 - How to Resolve ORA-03297 When Resizing a Datafile by Finding the Table Highwatermark
Nota: 237654.1 - Resizing a Datafile Returns Error ORA-03297
Suscribirse a:
Entradas (Atom)
