Pregunta a Gpuig
Hola:
Tengo una pregunta, la cual, creo es bastante extraña.
Tengo una tabla de oracle, con un campo Long, el cual como todos sabemos no es susceptible de ser reconstruido. Además las querys que acceden a dicha tabla generan mucho redo con lo que el archive log de la tabla (producción
) Es demasiado para ser asumido por una Streamer de una AIX. ¿Cuál sería la fórmula para poder asumir el redo de la tabla sin tener que archivar el redo resultante de las transacciones que acceden a la tabla?. Tengo serias dudas sobre como solucionar el tema.
Gracias.
´
Pietrof
Tengo una pregunta, la cual, creo es bastante extraña.
Tengo una tabla de oracle, con un campo Long, el cual como todos sabemos no es susceptible de ser reconstruido. Además las querys que acceden a dicha tabla generan mucho redo con lo que el archive log de la tabla (producción
) Es demasiado para ser asumido por una Streamer de una AIX. ¿Cuál sería la fórmula para poder asumir el redo de la tabla sin tener que archivar el redo resultante de las transacciones que acceden a la tabla?. Tengo serias dudas sobre como solucionar el tema.
Gracias.
´
Pietrof
1 respuesta
Respuesta
1
Sobre todo no dices con que release de Oracle trabajas. En cualquier caso es igual, olvidate de los LONG si puedes y pasate a los LOB. Las opciones UNRECOVERABLE y NOLOGGING son muy restrictivas en la BBDD y no aplican a transacciones normales de tipo INSERT (solo con Direct Path) DELETE o UPDATE.
Otra opción que tienes es aumentar el numero de redo logs en juego para que el archiver trabaje más tranquilo y sin tantas prisas.
Cuantos más detalles y a más bajo nivel mes des, más te podre ayudar. No se porque, la gente que escribe en esta web no da detalles de nada y espera que le arreglen las cosas con solo escribir 3 o 4 lineas :-(
Otra opción que tienes es aumentar el numero de redo logs en juego para que el archiver trabaje más tranquilo y sin tantas prisas.
Cuantos más detalles y a más bajo nivel mes des, más te podre ayudar. No se porque, la gente que escribe en esta web no da detalles de nada y espera que le arreglen las cosas con solo escribir 3 o 4 lineas :-(
Tienes razón a cerca de que la gente no da muchos detalles a cerca de lo que rodea al problema, más inri tiene que yo también soy DBA ORACLE y la gente me hace preguntas y digo lo mismo... que escriban más... perdona por no haber escrito más.
En realidad ese tema lo conocía, lo de NOLOGGING, pero me da un poco de miedo fiarme con respecto a la tabla en cuestión... que por cierto tiene + de 2 gb y 26 millones de registros.. fiarme de la export. Hago copias en caliente y en frio(nocturnas), a parte de exportaciones diarias, pero realmente el problema es que esa tabla en concreto es muy tansaccional, es decir se updatea, inserta, borra (y porque no hay más...) muchas veces a lo largo del día, y por tanto genera un volumen de redo que está empezando a ser un tanto peligroso... de hecho ya se ha dado el caso de tener que copiarlo a cinta 2 veces en un día... en fin ... y no se me concede por el momento más discos.. osea que estoy un poco en la cuerda floja. El sistema tiene un total de 600Gb, en RAID 0 + 1, y la base de datos llega a los 125Gb, una de ellas, también tengo más B.DE en este servidor y 10 B.DE más en otro, pero esas no son el problema. En fin, solo quería saber si conocías algún "truco", o alguna técnica por la cual se pueda manejar, o hacer más llevadero este tema. En ocasiones yo he podido ayudar a otros colegas en alguna cuestión en concreto de Backup`s en Unix, y otras veces otros colegas me han ayudado a mi con alguna técnica desarrollada por ellos, o cosas por el estilo, y de ahí viene la pregunta.
Por cierto tu crees que si lograse Particionar (ponerme de acuerdo con desarrollo...), la tabla, podría llegar a contrarrestar el redo generado, ya que si configo discernir los datos por años, por ejemplo, actuaría como varias tablas, ¿o simplemente nos interesa la amplitud de registro a la hora de tener en cuenta el sistema de Archivado de ORACLE?.
Un Saludo y espero tu respuesta, soy experto de oracle también aquí en "todoexpertos" y me llamo pedrito12.
Un saludo
Pedro
En realidad ese tema lo conocía, lo de NOLOGGING, pero me da un poco de miedo fiarme con respecto a la tabla en cuestión... que por cierto tiene + de 2 gb y 26 millones de registros.. fiarme de la export. Hago copias en caliente y en frio(nocturnas), a parte de exportaciones diarias, pero realmente el problema es que esa tabla en concreto es muy tansaccional, es decir se updatea, inserta, borra (y porque no hay más...) muchas veces a lo largo del día, y por tanto genera un volumen de redo que está empezando a ser un tanto peligroso... de hecho ya se ha dado el caso de tener que copiarlo a cinta 2 veces en un día... en fin ... y no se me concede por el momento más discos.. osea que estoy un poco en la cuerda floja. El sistema tiene un total de 600Gb, en RAID 0 + 1, y la base de datos llega a los 125Gb, una de ellas, también tengo más B.DE en este servidor y 10 B.DE más en otro, pero esas no son el problema. En fin, solo quería saber si conocías algún "truco", o alguna técnica por la cual se pueda manejar, o hacer más llevadero este tema. En ocasiones yo he podido ayudar a otros colegas en alguna cuestión en concreto de Backup`s en Unix, y otras veces otros colegas me han ayudado a mi con alguna técnica desarrollada por ellos, o cosas por el estilo, y de ahí viene la pregunta.
Por cierto tu crees que si lograse Particionar (ponerme de acuerdo con desarrollo...), la tabla, podría llegar a contrarrestar el redo generado, ya que si configo discernir los datos por años, por ejemplo, actuaría como varias tablas, ¿o simplemente nos interesa la amplitud de registro a la hora de tener en cuenta el sistema de Archivado de ORACLE?.
Un Saludo y espero tu respuesta, soy experto de oracle también aquí en "todoexpertos" y me llamo pedrito12.
Un saludo
Pedro