RollBack Segment
Estoy en un proyecto de migración hacia oracle 10g y estoy en la parte de hacer el import, pero resulta que se realiza muy lento, estuve mirando algunas páginas y recomiendan poner los rollback segment offline pero he estado tratando de hacer esto con la instrucción ALTER ROLLBACK SEGMENT "_SYSSMU1$" OFFLINE y no se le cambia el estado, ese rollback son de los los que creo oracle durante la instalación.
Por otra parte cree un rollback de la siguiente manera:
create public rollback segment pruebarb
Tablespace rbs
Y me dice que lo crea pero cuando consulto la tabla dba_rollback_segs este no aparece.
Hago lo mismo en Oracle 8 que es la base que quiero migrar hasta 10g y funciona normalmente es decir creo el rollback y si lo consulto aparece normalmente en la tabla, y también les puedo cambiar el estado.
Quisiera saber que puede estar sucediendo, el por que no cambian de estado los RBS y por que cuando los creo no aparecen en la tabla dba_rollback_segs
Por otra parte cree un rollback de la siguiente manera:
create public rollback segment pruebarb
Tablespace rbs
Y me dice que lo crea pero cuando consulto la tabla dba_rollback_segs este no aparece.
Hago lo mismo en Oracle 8 que es la base que quiero migrar hasta 10g y funciona normalmente es decir creo el rollback y si lo consulto aparece normalmente en la tabla, y también les puedo cambiar el estado.
Quisiera saber que puede estar sucediendo, el por que no cambian de estado los RBS y por que cuando los creo no aparecen en la tabla dba_rollback_segs
2 Respuestas
Respuesta de oracledisect
2
Aquí unos consejos para mejorar la velocidad:
1) Regresa tu BD a modo no archive, de esta forma te ahorraras el trabajo y carga en disco de copiar los redo logs a archives
2) Incrementa el numero de db_writer_processes hasta la mitad de lo posible en tu servidor
3) Verifica que sort_area_size sea lo suficientemente grande como para disminuir el uso del tablespace temporal
4) Evita que los datafiles compartan espacio con los temp files (datafiles del tablespace temporal)
5) Usar los parametros commit=y, statistics=none y buffer del import (mira el manual para una descripcion de ellos)
Suerte
Ignacio
http://oracledisect.blogspot.com
1) Regresa tu BD a modo no archive, de esta forma te ahorraras el trabajo y carga en disco de copiar los redo logs a archives
2) Incrementa el numero de db_writer_processes hasta la mitad de lo posible en tu servidor
3) Verifica que sort_area_size sea lo suficientemente grande como para disminuir el uso del tablespace temporal
4) Evita que los datafiles compartan espacio con los temp files (datafiles del tablespace temporal)
5) Usar los parametros commit=y, statistics=none y buffer del import (mira el manual para una descripcion de ellos)
Suerte
Ignacio
http://oracledisect.blogspot.com
Respuesta de neosys
2
Ten en cuenta que los antiguamente llamados 'rollback segments', desde la 9i han sido substituidos por los 'undo segments'.
Respecto a que en el proceso de importación de datos (supongo que usas el import) hay más factores que pueden afectar al bajo rendimiento.
Como pueden ser el que tengas habilitadas las 'constraints', creados indices, view, es materializadas o algún trigger de BB. DD. Entre tablas ...
De momento te recomendaría que usases el import de forma mejorada antes de modificar temas de rollback, es o undo segments (ya que estos perjudican si las transacciones o unidades transaccionales son muy voluminosas).
Olvidate por un momento de eso y haz una cosa más efectiva. Primero, desactivaría 'solo en el momento de la importación' el modo de ARCHIVELOG de tu instancia. Ya que en caso de necesidad de recuperación ya cuentas con la imagen en los ficheros exports (*. Dmp).
Para ello existe tambien un 'parámetro indocumentado que es : "_disable_logging=TRUE"', con eso evitas las operaciones que se realizan contra el ARCHIVER y los REDO LOGS.
Define los parámetros "commit=n y buffer=64000", aunque el poner 'commit=n' hará que tire de los segmentos de rollback es más eficiente en tiempo. Y lo que marca mucho la diferencia es el determinar un número alto para el valor del parámetro 'buffer', puedes conseguir hasta más de un 45% de beneficio en rendimiento.
Tampoco indiques que te cargue las estadísticas.
Incrementa temporalmente el 'db_block_size', para luego reestablecerlo al tamaño deseado por las necesidades de tu sistema. P.e. Ponlo a 'db_32k_block_size', siempre que tu Sistema Operativo lo permita.
Si tienes indices y aún no has creado la los objetos, utiliza 'indexes=n'. Y una vez cargados los datos. Creas el fichero de indices con la opcion del 'import' - 'indexfile=mis_indices.sql' incrementando la anteriormente llamada 'sort_area_size' la cual en estas últimas versiones no tiene efecto directo, ya que tienes que incrementar la 'pga_aggregate_target' a un valor considerable. (esto lo puedes hacer desde el sql*plus, por ejemplo, indicando : alter system set pga_aggregate_target=200m; y ejecutando el fichero de creación de indices 'mis_indices.sql'. Tamaño en Bytes y en función de los recursos de memoria de que dispongas. Restableciendo el valor inicial que tenias antes después de crear los indices.
Volviendo al tema de la creación de los Segmentos de Rollback, ¿estás seguro de que al crearlo no te dio ningún error? Porque debería de aparecer en la vista del diccionario que mencionas.
De todas formas se suele hacer esta operativa para que Oracle coja ese segmento grande que has creado para poder soportar la carga de información de cada una de las tablas que vas a importar. ¿Tan voluminosas son?
Si es así, y aunque sería interesante saber porque no te sale en la vista el rollback creado. Coloca en la instrucción import el commit=y. Creo que con las otras modificaciones no notaras el impacto. A no ser, que cuando hagas la carga te de un error de que no hay espacio suficiente en el rolback segment X.
Entonces ya intentaríamos ver que pasa con más profundidad.
De momento intenta realizar la carga de la forma que te he indicado y me cuentas que tal.
Si luego quieres ... o ves que sigue yendo lento (cosa que me extrañaría, con las opciones que te he indicado) ya entraríamos a lo de definir un rollback segment largo único para este proceso.
Respecto a que en el proceso de importación de datos (supongo que usas el import) hay más factores que pueden afectar al bajo rendimiento.
Como pueden ser el que tengas habilitadas las 'constraints', creados indices, view, es materializadas o algún trigger de BB. DD. Entre tablas ...
De momento te recomendaría que usases el import de forma mejorada antes de modificar temas de rollback, es o undo segments (ya que estos perjudican si las transacciones o unidades transaccionales son muy voluminosas).
Olvidate por un momento de eso y haz una cosa más efectiva. Primero, desactivaría 'solo en el momento de la importación' el modo de ARCHIVELOG de tu instancia. Ya que en caso de necesidad de recuperación ya cuentas con la imagen en los ficheros exports (*. Dmp).
Para ello existe tambien un 'parámetro indocumentado que es : "_disable_logging=TRUE"', con eso evitas las operaciones que se realizan contra el ARCHIVER y los REDO LOGS.
Define los parámetros "commit=n y buffer=64000", aunque el poner 'commit=n' hará que tire de los segmentos de rollback es más eficiente en tiempo. Y lo que marca mucho la diferencia es el determinar un número alto para el valor del parámetro 'buffer', puedes conseguir hasta más de un 45% de beneficio en rendimiento.
Tampoco indiques que te cargue las estadísticas.
Incrementa temporalmente el 'db_block_size', para luego reestablecerlo al tamaño deseado por las necesidades de tu sistema. P.e. Ponlo a 'db_32k_block_size', siempre que tu Sistema Operativo lo permita.
Si tienes indices y aún no has creado la los objetos, utiliza 'indexes=n'. Y una vez cargados los datos. Creas el fichero de indices con la opcion del 'import' - 'indexfile=mis_indices.sql' incrementando la anteriormente llamada 'sort_area_size' la cual en estas últimas versiones no tiene efecto directo, ya que tienes que incrementar la 'pga_aggregate_target' a un valor considerable. (esto lo puedes hacer desde el sql*plus, por ejemplo, indicando : alter system set pga_aggregate_target=200m; y ejecutando el fichero de creación de indices 'mis_indices.sql'. Tamaño en Bytes y en función de los recursos de memoria de que dispongas. Restableciendo el valor inicial que tenias antes después de crear los indices.
Volviendo al tema de la creación de los Segmentos de Rollback, ¿estás seguro de que al crearlo no te dio ningún error? Porque debería de aparecer en la vista del diccionario que mencionas.
De todas formas se suele hacer esta operativa para que Oracle coja ese segmento grande que has creado para poder soportar la carga de información de cada una de las tablas que vas a importar. ¿Tan voluminosas son?
Si es así, y aunque sería interesante saber porque no te sale en la vista el rollback creado. Coloca en la instrucción import el commit=y. Creo que con las otras modificaciones no notaras el impacto. A no ser, que cuando hagas la carga te de un error de que no hay espacio suficiente en el rolback segment X.
Entonces ya intentaríamos ver que pasa con más profundidad.
De momento intenta realizar la carga de la forma que te he indicado y me cuentas que tal.
Si luego quieres ... o ves que sigue yendo lento (cosa que me extrañaría, con las opciones que te he indicado) ya entraríamos a lo de definir un rollback segment largo único para este proceso.
Hola neosys
Ya se me han aclarado muchas cosas con tu respuesta y aprendido otras que no sabia, pero me han quedado algunas dudas
¿Dónde puedo configurar el parámetro _disable_logging, por que lo he buscado en mi init.ora y no lo encuentro, acaso tengo que agregarlo?
Otra pregunta es, como se que archivo init.ora esta usando Oracle, ¿tengo la version 10g?
Gracias por la ayuda que me puedas prestar a cerca de esto.
Ya se me han aclarado muchas cosas con tu respuesta y aprendido otras que no sabia, pero me han quedado algunas dudas
¿Dónde puedo configurar el parámetro _disable_logging, por que lo he buscado en mi init.ora y no lo encuentro, acaso tengo que agregarlo?
Otra pregunta es, como se que archivo init.ora esta usando Oracle, ¿tengo la version 10g?
Gracias por la ayuda que me puedas prestar a cerca de esto.
Me consuela como mínimo el haberte podido aclarar determinadas ideas.
Respecto a la variable del 'init. Ora' o del pfile. Ora como no está documentada, tienes que definirla.
De todas formas, puedes emular la misma casuística conectándote como administrador y ejecutando -previo al import- :
alter database noarchivelog;
Para luego volverla a activar -una vez pasado el proceso de importación- :
alter database archivelog;
Respecto a la otra pregunta, es muy fácil. Primero tienes que saber el 'SID' con el que estás trabajando. Para ello o te conectas al 'sqlplus' como dba y escribes :
SQL> show parameter instance_name
(Conectado a la 10g).
También lo puedes ver en las variables de entorno : $ORACLE_SID en unix o %ORACLE_SID% en Windows.
Un Saludo
Y verifica con alguna prueba puntual la carga de una tabla por ejemplo. De la forma normal.
Luego haces un 'TRUNCATE TABLE ...' y la vuelves a apuntar con algunas modificaciones de las tantas que te he explicado. Por ejemplo lo de los parámetros del -import-.
Toma los tiempos ... Y así progresivamente.
Verás como todo se soluciona a la perfección.
Respecto a la variable del 'init. Ora' o del pfile. Ora como no está documentada, tienes que definirla.
De todas formas, puedes emular la misma casuística conectándote como administrador y ejecutando -previo al import- :
alter database noarchivelog;
Para luego volverla a activar -una vez pasado el proceso de importación- :
alter database archivelog;
Respecto a la otra pregunta, es muy fácil. Primero tienes que saber el 'SID' con el que estás trabajando. Para ello o te conectas al 'sqlplus' como dba y escribes :
SQL> show parameter instance_name
(Conectado a la 10g).
También lo puedes ver en las variables de entorno : $ORACLE_SID en unix o %ORACLE_SID% en Windows.
Un Saludo
Y verifica con alguna prueba puntual la carga de una tabla por ejemplo. De la forma normal.
Luego haces un 'TRUNCATE TABLE ...' y la vuelves a apuntar con algunas modificaciones de las tantas que te he explicado. Por ejemplo lo de los parámetros del -import-.
Toma los tiempos ... Y así progresivamente.
Verás como todo se soluciona a la perfección.
Neosys, Muchas Gracias por su ayuda, la verdad el import si ando muchísimo, pero muchísimo más rapido, lo único fue que al final me dio fue un error de archivo de export corrupto, por lo que realize el export nuevamente así como el import con todos los cambios que me recomendaste y corrió perfecto, muchas GRACIAS nuevamente.