Oracle - Mover todos los objetos de un usuario de tablespac

Hola compañeros, necesito mover todos los objetos de un usuario de un tablespace al tablespace asignado por defecto al usuario, no me vale la importacion ya que en el DMP viene donde se importará el objeto y quiero otro tablespace diferente, lo del tablespace por defecto no funciona si existe el original, gracias

Mensaje 1 de 2
Hola Satxa:

Por que no intentas hacer un export del esquema (Usuario) que requieres, posteriormente con la utilería import y con tu archivo DUMP de volcado binario hacen indexfile, editas el archivo de salida filtrando los comentarios y cambias todos tus segmentos del "TABLESPACE ORIGEN" al "TABLESPACE DESTINO".

De esta forma tendras un script el cual puedes ejecutar desde SQLPLUS y ejecutarlo, de esta forma tendrás la nueva alojación de los segmentos en el Tablespace que deseas.

Dices que no te funciona el tablespace por Defecto, esto no puede ocurrir, a menos que cuando se llegara a crear un segmento, puedas indicarle a que tablespace tiene que estar alojado, te recomiendo que para este caso, a todos los usuarios (excepto lo que desees adminsitrar) limites a que solo escriban en un solo tablespace dejando sin "quota" de escritura a ningun tablespace mas que el "Tablespace Destino" (sin privilegios).

Mensaje 2 de 2

Si sigues la recomendacion que te ofrezco, los pasos a seguir son los siguientes:

antes que nada un export full a la base de datos y un coldbackup

1)Export del OWNER (Dueño de los objetos)
2)Import con parámetro de "INDEXFILE"
3)Editas el archivo de salida, remueves comentarios y los rows exportados, buscas y cambias el tablespace que no deseas por el que va a ser el tablespace final
4)remueves todos los segmentos del OWNER
5)Recreas los segmentos con el script que creaste en tu import.
6)import del OWNER del paso 1
7)Alteras el usuario con el Default tablespace fianl
8)Alteras el usuario o todos los usuarios que no sean administradores con quota de 0 bytes por cada Tablespace a excepcion del TS final.

Con esto tendras un control total.

Saludos

Jorge-DBA

Perdona que te corrija, Jorge.
No ahce falta hacer un indexfile y cambiar el fichero, si el usuario es propietario de muchos objetos, la tarea puede ser muy ardua e imposible...ademas de que puedes equivocarte facilmente en el intento.
Unicamente le tienes que asignar el tablespace destino, como tablespace por defecto al usuario y quitarle las quotas en el resto de tablespaces de la BD, o sea, que solo tenga permisos para escribir en el tablespace que te interese.
Antes de importar, prueba a crear una tabla en otro tablespace y comprobaras que te la crea en el que tiene el usuario asignado por defecto.

Hola saioa:

La solucion que ofreces es buena para un RDBMS de Oracle donde no existe el TABLESPASPACE origen, de esta manera, la importacion NO alojará la los segmentos nuevamente en el tablespace origen, sino en el que tiene el usuario por DEFECTO (Default), en tu exposición, si se decide restringir al usuario por QUOTA al mismo y existe el Tablespace origen, provocará un error sobre que no puede importar los segmentos por que no hay privilegios de escritura ya que el import estará validando que existe dicho TS para recrear nuevamente los segmentos con el storage correspondiente.

Si en el issue presentado no existiera el TABLESAPACE en la base de datos, la solucion que ofrece saioa sería bastante buena, por el contrario si se requiriera el Tablespace origen por que existieran otros segmentos de diferentes usuarios, la solción sería realizar la recomendación que expuse.

Saludos.

Jorge-DBA

No, no , no

Si hace tu recomendacion tendria que poner el objeto fuera de linea mientras e hace eso y no es muy saludable que digamos ya que hay mucha interaccion y muy facil cometer errores (tiene razon SAIOA) lo mejor que puede hacer es una reconstruccion, alter table move, alter index rebuild, de manera que asi quedan las cosas disponibles y tendra muy poco margen de error.

De hecho, con la recomendacion que estoy dando la tarea estaria terminada en unos cuantos minutos, sin errores.

Saludes

Mensaje 1 de 3
Harold:

Recuerda que para mover tablas con campo LONG a LONG RAW tienes que recrear la estructura, pareciera que lo que indicas es muy simple pero no lo es asi, mas que para índices y tablas con particiones, de esta forma si puedes moverlas a Tablespace diferentes, si intentas mover la tabla con este tipo de dato Oracle responde con el error ORA-00997, para mover tablas organizadas por índice tienes que reorganizar la tabla.

Mensaje 2 de 3

Ejemplo:
SQL> drop table j;
Tabla borrada.
SQL> create table j (uno varchar2(1)) tablespace users;
Tabla creada.
SQL> desc j
Nombre ¿Nulo? Tipo
----------------------------------------- -------- ----------------------------
UNO VARCHAR2(1)
SQL> select table_name, tablespace_name
2 from user_tables
3 where table_name like 'J';
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
J USERS
SQL> alter table j move TABLESPACE TOOLS;
Tabla modificada.
SQL> select table_name, tablespace_name
2 from user_tables
3 where table_name like 'J';
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
J TOOLS
SQL> alter table j add (dos long);
Tabla modificada.
SQL> desc j
Nombre ¿Nulo? Tipo
----------------------------------------- -------- ----------------------------
UNO VARCHAR2(1)
DOS LONG
SQL> alter table j move TABLESPACE USERS;
alter table j move TABLESPACE USERS
*
ERROR en línea 1:
ORA-00997: uso no válido del tipo de dato LONG

SQL>

Mesaje 3 de 3

Envío información de Oracle Support.

fact: Oracle Server - Enterprise Edition
symptom: Moving tables to another tablespace fails
symptom: ALTER TABLE <tablename> MOVE TABLESPACE <tablespacename&
gt; fails
symptom: ORA-00997: illegal use of LONG datatype
symptom: Table contains a LONG or LONG RAW column
cause: The ALTER TABLE ... MOVE command cannot be used to move a table
containing a LONG or LONG RAW column.

fix:
Perform following steps to move the table to another tablespace:

1. Export the table.
2. Recreate the table in the new tablespace.
3. Import the table.

The ALTER TABLE ... MOVE command cannot be used to move a table containing a
LONG or LONG RAW column. This is documented in the Oracle9i SQL Reference
manual.

En el mensaje 1 de 1 en la linea

"Recuerda que para mover tablas con campo LONG a LONG RAW"

quice decir:

"Recuerda que para mover tablas con campo LONG ó LONG RAW"

Ok, en eso tienes razon, pero eso es en el caso de las tablas que tenga ese tipo de datos (no creo que sean muchas y si acaso las tiene), en todo caso si las tuviera, solamente estaria moviendo 1 tabla no todo el esquema.

Para mi es mejor hacer el alter table y en el caso que no se pueda recrear con exp/imp.

Harold:

Haz trabajado con las llamadas VLDB (VERY LARGE DATABASE)?, he trabajado con bases de datos Oracle de mas de 40 TERABYTES de información, y creeme, cuando existen aplicaciones que requieren multiples tablas con tipos de datos que no hace tan facil el pasar un tablespace origen a uno destino, todo depende del diseño de las aplicaciones requiriendo diferentes tipos de tablas con grandes volumenes de informacion, he tenido experiencias donde me he encontrado con hasta mas de 80 tablas con campos LONG y LONRAW.

Saludos Jorge-DBA

Esta bien, como quieras. igual pienso que la forma mas eficiente de hacerlo es con un alter (las que apliquen logicamente), da menos margen de error, ademas no creo que sea el caso del que origino la pregunta. pero en fin...

PD. SI he trabajado en BD grandes en distintas plataformas y versiones de oracle desde hace mucho rato ya

Saludes