Espacio de Tablas Transportable en diferentes Plataformas
___________________________________________________
En nuestro ejemplo transportaremos un espacio de tabla llamado TEST. El espacio de tabla debe ser autónomo sin ningún objeto que haga referencia a otros espacios de tabla, por lo que para ello compruebe si el espacio de tabla del sistema operativo es autónomo mediante la consulta siguiente:
EJECUTE dbms_tts.transport_set_check (‘TEST’, TRUE, TRUE);
SELECCIONE * DE transport_set_violations;
Si tiene objetos con referencias cruzadas. Suelte esos objetos del espacio de tabla de PRUEBA (tenga en cuenta que esto se está haciendo en un entorno de prueba para que pueda soltar los objetos con referencias cruzadas fácilmente. No deje caer ningún objeto sin consultar a su DBA senior en un entorno de producción. Nunca se sabe qué objeto tiene qué dependencia. Supongamos que tiene índices en el espacio de tablas de PRUEBA que apuntan a tablas en otro espacio de tablas. Puede mover esos índices de forma segura utilizando el procedimiento pl/sql a continuación:
begin
para c1 in (seleccione index_name a1 de user_indexes)
bucle
ejecutar ‘alter index ‘||c1 inmediato.a1/ / ‘ reconstruir el espacio de tabla en línea < nombre del espacio de tabla>’;
bucle de fin;
fin;
/
Ahora proceda y revise las infracciones de nuevo. Si se produce un error como:
SELECT * FROM transport_set_violations;
VIOLACIONES
—————————
Violación 46 : póngase en contacto con Oracle support
Violación 46 : póngase en contacto con Oracle support
Violación 46 : póngase en contacto con Oracle support
Ejecutar esta consulta para comprobar por qué la violación es tirar el
SELECCIONE la herramienta RECORTAR(OBJ1_OWNER) || ‘, ‘ || TRIM(OBJ1_NAME) || ‘, ‘ ||
TRIM(OBJ1_SUBNAME) || ‘, ‘ || TRIM(OBJ1_TYPE) || ‘, ‘ ||
TRIM(TS1_NAME) || ‘, ‘ || TRIM(OBJ2_OWNER) || ‘, ‘ ||
TRIM(OBJ2_NAME) || ‘, ‘ || TRIM(OBJ2_SUBNAME) || ‘, ‘ ||
TRIM(OBJ2_TYPE) || ‘, ‘ || TRIM(TS2_NAME) || ‘, ‘ ||
TRIM(CONSTRAINT_NAME) || ‘, ‘ || TRIM(LA RAZÓN)
DE PLUGGABLE_SET_CHECK
DONDE MESG_ID=46;
Esto dará salida de cuál es exactamente la violación para el espacio de tabla transportable. Corrija esas violaciones e inicie el procedimiento real para transportar el espacio de tabla. En mi ejemplo, había utilizado el Cifrado Transparente de datos(TDE) para algunas columnas de la base de datos. La consulta informó que no puede usar TT_TBS cuando tiene columnas cifradas. Así que tuve que descifrar las columnas que cifré usando una consulta como.
SELECCIONE * DE dba_encrypted_columns;
MODIFICAR LA TABLA DE MODIFICACIÓN DE la cuenta (DESCIFRAR el titular de la tarjeta);
Después de descifrar las columnas. Seguimos adelante
1. Compruebe la versión ENDIAN tanto de origen como de destino utilizando el siguiente script:
—
— ¿Cuáles son las posibilidades de Plataforma de Espacio de tabla Transportable disponibles?
—
SELECCIONE
platform_name
,endian_format
FROM v$transportable_platform
PEDIDO POR platform_name
;
—
— ¿Cuál es la actual ENDIAN-ness de mi base de datos y plataforma?
—
SELECCIONE
D. nombre
,TP.endian_format
DE
v$transportable_platform TP
,v$database D
DONDE TP.platform_name = D. platform_name
;
informará si el ENDIANO es «pequeño»o » grande». Si el endian es el mismo tanto en el destino como en el origen, no es necesario elegir un espacio de tablas transportable. Simplemente puede exportar el espacio de tabla e importarlo al destino. Si no se procede como abajo
2. Altere el espacio de tabla y póngalo en modo de solo lectura en el origen. En nuestro ejemplo transportaremos un espacio de tabla llamado TEST al servidor de destino.
Prueba DE ALTER TABLESPACE de SOLO LECTURA;
3. ahora exporte los metadatos del espacio de tabla.
##Windows###
exp USERID= ‘system/oracle @ Source AS SYSDBA’ TRANSPORT_TABLESPACE=y TABLESPACES=test FILE = test_repository.dmp log = test_repository.txt
###Unix # # #
exp \ ‘sys / oracle AS SYSDBA \’ TRANSPORT_TABLESPACE = y TABLESPACES = test FILE = test_repository.dmp log = test_repository.txt
Vaya a destino y copie el archivo de descarga a cualquier ubicación junto con los archivos de datos de ese espacio de tabla.
imp \ ‘sys / oracle AS SYSDBA\’ TABLESPACES = test TRANSPORT_TABLESPACE = y FILE = test_repository.archivos de datos dmp = ‘ users_01.dbf’
4. Hasta arriba es para cuando está exportando un espacio de tabla a una máquina con la misma información endian. Si un endian, proceder como a continuación. Convertiremos de Solaris SPARC de 64 bits (GRANDE) a Windows de 32 bits(Pequeño)
5. Convierta los archivos de datos utilizando RMAN y db_file_name_convert
#no utilice este método: En la máquina de origen: Con el nombre de archivo original
RMAN> convertir el espacio de tabla ‘TEST’
a la plataforma ‘ Microsoft Windows IA (32 bits)’
format= ‘/archivos de datos/rmanbkp/%N_%f ‘
paralelismo = 4;
## utilice este método: En la máquina de origen: Con nombre de archivo convertido nombre de archivo
RMAN> convertir el espacio de tabla ‘TEST’
2 >a la plataforma ‘Microsoft Windows IA (32 bits)’
3> db_file_name_convert ‘/datafiles/oradata/SWX’,’/datafiles / rmanbkp ‘
4> paralelismo = 4;
Después de convertir los archivos, se puede encontrar en ‘/datafiles/rmanbkp’. Copie estos archivos convertidos junto con el volcado de metadatos de TT_TBS y póngalos en el servidor de origen y ejecute la importación:
imp USERID= ‘system/password @ target AS SYSDBA’
TRANSPORT_TABLESPACE = y
DATAFILES=’C:\datafiles\test01.DBF», » C:\datafiles\test02.DBF ‘
TABLESPACES = test
FILE = test_repository.dmp
En los casos anteriores, convertimos los archivos en la plataforma de origen. Sin embargo, también puedes hacerlo en la plataforma de destino. Por ejemplo, puede copiar el archivo test01.dbf junto con el volcado de metadatos en una máquina de destino de 32 bits de Windows Server 2003 y convertirlo allí:
RMAN> convertir
2 > archivo de datos «c:/users01.dbf ‘ # # directorio donde colocará su archivo de datos desde el servidor de origen
3> formato ‘c:/datafiles/rmanbkp/%N_%f’ # # directorio donde obtendrá el archivo convertido
4> ;
Este enfoque creará un archivo en el formato especificado en el directorio.
Pero, ¿por qué querría convertir exactamente los archivos de datos en la plataforma de destino? Una de las razones podría ser un tiempo de inactividad más corto, que requiere que los espacios de tabla estén en estado de SOLO LECTURA durante la duración de la copia en el host de destino. Podría duplicar el archivo de datos, hacer que el espacio de tablas sea de solo lectura, romper el tercer espejo e inmediatamente hacer que el espacio de tablas sea de lectura/escritura. Este tercer espejo podría montarse en el sistema de destino y convertirse a su antojo. Esta disposición minimiza la duración durante la cual el espacio de tabla debe permanecer de solo lectura.
Otra razón podría ser el rendimiento. La base de datos OLTP puede estar bajo una carga constante y el uso de la operación de conversión RMAN puede sobrecargar el sistema más de lo deseado. En su lugar, la conversión se puede descargar al servidor del almacén de datos, donde generalmente hay más CPU disponibles para operaciones paralelas.
