¿Cómo copio y renombro una ba se de datos oracle?
Aver si me puedes orientar Necesito crear una copia de una base de datos de oracle 9i
con otro nombre para poder accesar la original y también poder accesar la copia para pruebas en la misma pc, Según lo que he investigado no puedo tenerlas con el mismo nombre en la misma pc
resultado seria algo así
PC1 se conecta remotamente a BD1
Y también
PC1 se conecta localmente a Copia_BD1
Se que debo hacer una copia físicamente de los archivos
pero me falta algunos pasos
para configurar la copia de la base de datos como archivos init. Ora
control files y todo esa configuración
con otro nombre para poder accesar la original y también poder accesar la copia para pruebas en la misma pc, Según lo que he investigado no puedo tenerlas con el mismo nombre en la misma pc
resultado seria algo así
PC1 se conecta remotamente a BD1
Y también
PC1 se conecta localmente a Copia_BD1
Se que debo hacer una copia físicamente de los archivos
pero me falta algunos pasos
para configurar la copia de la base de datos como archivos init. Ora
control files y todo esa configuración
1 Respuesta
Respuesta de neosys
1
Ante todo no es necesario dar la gracias -aunque es de agradecer-. Aquí estoy con el objetivo de colaborar desinteresadamente a todo el que necesita ayuda, por tanto no es necesario que me des las gracias.
He estado releyendo tu pregunta una y otra vez y he llegado a la siguiente conclusión :
- Mejor que indicarme una solución de antemano, ¿por qué no explicarme el porque quieres duplicar una instancia Oracle? ¿Cuál es el objetivo? ¿Para qué lo necesitas? (Si es algo confidencial me lo puedes enviar como respuesta privada).
- Sobre la solución que tu propones es posible y factible. De hecho no se trata más que hacer las llamadas COPIAS DE SEGURIDAD INTEGRAS y restaurarla en otra instancia de BB. DD. Pero eso sólo se realiza cuando ha ocurrido un fallo general en todo el disco y este tiene que ser sustituido por otro. Normalmente se realizan 'backup, es en caliente' y es para recuperaciones en caso de errores no tan críticos y con la finalidad de reconstruir a partir de una base y tirando de los REDO LOG ARCHIVER, s.
- Para colmo, encima la propuesta que me haces es la de copia física de ficheros y aunque a veces se realiza para tener la base sobre la cual reconstruir, creo que en tu caso no es necesario.
Por favor, indicame para que deseas tener una copia de una Instancia completa. En todos los detalles que te he mencionado. Ya que creo que para lo que necesites -intuyo- no es necesaria la realización de los pasos que me detallas y hay soluciones muchísimo más simples.
Comentame cual es el problema y te daré soluciones alternativas. Aunque si al explicármelo la mejor forma es hacer lo que plateas, no dudaré en enviarte un manual (ya que aquí habría muy poco espacio) para indicarte como hacer la solución que me propones. Pero sólo si es necesario.
Espero que entiendas mi razonamiento. Pero la solución que me comentas podría ser como matar moscas a cañonazos. Explicame que es lo que necesitas y en función de ello te remito la solución.
Un Saludo (espero que lo entiendas ... y no es ninguna critica, al contrario, se trata de una aportación).
Ramón
Spain
He estado releyendo tu pregunta una y otra vez y he llegado a la siguiente conclusión :
- Mejor que indicarme una solución de antemano, ¿por qué no explicarme el porque quieres duplicar una instancia Oracle? ¿Cuál es el objetivo? ¿Para qué lo necesitas? (Si es algo confidencial me lo puedes enviar como respuesta privada).
- Sobre la solución que tu propones es posible y factible. De hecho no se trata más que hacer las llamadas COPIAS DE SEGURIDAD INTEGRAS y restaurarla en otra instancia de BB. DD. Pero eso sólo se realiza cuando ha ocurrido un fallo general en todo el disco y este tiene que ser sustituido por otro. Normalmente se realizan 'backup, es en caliente' y es para recuperaciones en caso de errores no tan críticos y con la finalidad de reconstruir a partir de una base y tirando de los REDO LOG ARCHIVER, s.
- Para colmo, encima la propuesta que me haces es la de copia física de ficheros y aunque a veces se realiza para tener la base sobre la cual reconstruir, creo que en tu caso no es necesario.
Por favor, indicame para que deseas tener una copia de una Instancia completa. En todos los detalles que te he mencionado. Ya que creo que para lo que necesites -intuyo- no es necesaria la realización de los pasos que me detallas y hay soluciones muchísimo más simples.
Comentame cual es el problema y te daré soluciones alternativas. Aunque si al explicármelo la mejor forma es hacer lo que plateas, no dudaré en enviarte un manual (ya que aquí habría muy poco espacio) para indicarte como hacer la solución que me propones. Pero sólo si es necesario.
Espero que entiendas mi razonamiento. Pero la solución que me comentas podría ser como matar moscas a cañonazos. Explicame que es lo que necesitas y en función de ello te remito la solución.
Un Saludo (espero que lo entiendas ... y no es ninguna critica, al contrario, se trata de una aportación).
Ramón
Spain
Si entendí lo de las Gracias Experto, pero si quieres solo tomalo como protocolo.
Lo que pasa, a ver si me puedo explicar como veras soy novato en esto de oracle y por ello quiero despejar esa duda y ponerla en practica; ya que la solución que tengo de copiar físicamente la instancia surgió por lo siguiente:
Tengo una base de datos que esta trabajando bien localmente; pero para obtener los reportes anuales que se requiere que sean de otra maquina (remotamente), tarda varios minutos en procesarse; instale la instancia completa en mi pc para y el reporte anual lo genera en 2 minutos con 50 segundos; para esto ya he regeneradoindices de la base de datos original y sigue tardando mucho tiempo al solicitar el reporte remotamente. De manera que la idea que tengo es tener una copia de la instancia localmente para pruebas y obtención de reportes de información no actualizada pero me sirve para reportes de años anteriores 2007, 2006, 2005, etc. Pero en esa misma pc necesito tener la conexión a la base de datos original para manipular la información que se esta actualizando día con día pero no se requiere de varios minutos para obtenerla y como según lo que entiendo no puedo tener 2 conexiones a la misma instancia del mismo nombre
Que se ejecuten desde una pc, por eso tengo la idea que deba ser copia de la misma instancia pero con otro nombre para poderme conectar remotamente para tener la información actual o conectarme localmente para tener la información antigua pero que sea rapido al generar los rerportes.
Lo que pasa, a ver si me puedo explicar como veras soy novato en esto de oracle y por ello quiero despejar esa duda y ponerla en practica; ya que la solución que tengo de copiar físicamente la instancia surgió por lo siguiente:
Tengo una base de datos que esta trabajando bien localmente; pero para obtener los reportes anuales que se requiere que sean de otra maquina (remotamente), tarda varios minutos en procesarse; instale la instancia completa en mi pc para y el reporte anual lo genera en 2 minutos con 50 segundos; para esto ya he regeneradoindices de la base de datos original y sigue tardando mucho tiempo al solicitar el reporte remotamente. De manera que la idea que tengo es tener una copia de la instancia localmente para pruebas y obtención de reportes de información no actualizada pero me sirve para reportes de años anteriores 2007, 2006, 2005, etc. Pero en esa misma pc necesito tener la conexión a la base de datos original para manipular la información que se esta actualizando día con día pero no se requiere de varios minutos para obtenerla y como según lo que entiendo no puedo tener 2 conexiones a la misma instancia del mismo nombre
Que se ejecuten desde una pc, por eso tengo la idea que deba ser copia de la misma instancia pero con otro nombre para poderme conectar remotamente para tener la información actual o conectarme localmente para tener la información antigua pero que sea rapido al generar los rerportes.
Ante todo disculpa por haber tardado tanto en contestarte. He estado bastante liado en un tema y me ocupaba casi todo el tiempo. Ya sabes lo que es el oficio.
En referencia a lo que me estás indicando, no es necesario el tener en tu PC la BB. DD. Duplicada (en el caso de que tengas recursos, tanto de CPU, como de disco, como de memoria).
De todas formas y como insistes tanto en que esa es la solución, haré dos cosas : una, te insto a la página web de un colega donde te explica paso por paso como duplicar una BB.DD.. Este es el link :
http://oraclexperto.blogspot.com/2005/07/copiar-una-base-de-datos.html
Por otra parte te doy mi visión particular que no pasa por temas tan GRANDES como el duplicado de BB. DD.
1.- La primera premisa es : Si un Report ejecutado en tu máquina con el MISMO VOLUMEN DE DATOS que existe en la BB. DD. Local y en la remota tarda más ... Y lo estás ejecutando con Report Server (es decir, haces una llamada URL del 'report_servlet' y el report está en la máquina remota, el problema se puede dividir en dos :
a). Que en el servido remoto los recursos son muy escasos, ya que lo tienes que compartir con todos los usuarios que intervengan en la aplicación o aplicaciones.
b). Tienes un 'serio problema' en la Red. La comunicación entre tu máquina y el servidor es muy lenta.
- Piensa que cuando lo ejecutas en tu PC, lo haces en local, y no existe más usuario que tu. Que consumes todos los recursos. Los recursos son exclusivos para tu Report.
Siempre teniendo en cuenta que el volumen de datos es igual en ambas BB. DD.!
2.- Tema de acceso a los datos :
¿Me has indicado que tienes una 9i. Cuáles el método definido para el optimizador? El de REGLAS -'RULE'-, el de COSTES -COST-' o 'CHOOSE' (que elige uno de los antes definidos en función de si tienes generadas estadísticas o no). Porque espero que no tengas 'FIRST_ROWS'!
Verifícalo mirando el parámetro de las dos Instancias desde sqlplus 'siendo dba' con :
SQL> show parameters OPTIMIZER_MODE
y
SQL> show parameters OPT%
Si es por Reglas, 'RULE' ... uff! Oracle las elimina en la 10g y recomienda en la 9i el uso de generación de estadísticas e ir por costes. Que se puede hacer si estas en modo 'CHOOSE' o en 'COST'. Pero tienes que tener generadas las estadísticas de los Objetos con STORAGE de la BB. DD.
Si no sabes como hacerlo, te lo indicaría.
Para tener más información de que es lo que te puede estar pasando, sabes hacer 'EXPLAIN PLAN', ¿s?
Lo digo para que veas como se comporta las sentencias de tu Report en el servidor local y que plan de ejecución tienes en el remoto.
Para ello tienes que tener acceso a la tabla 'PLAN_TABLE' y ejecutar las sentencias de tu report en las dos máquinas ...
Puedes hacer desde sql*plus :
SQL> set autotrace on
SQL> set timing on
SQL> Tu sentencia básica de SQL del Report (la que crees más costosa).
Compara entonces el tipo de Plan de acceso que te da cada una de las instancias, y ya está. Si ves diferencias, se debe a que o no se están ejecutando las estadísticas habituales, o que el modo del optimizador (y otros parámetros asociados al comportamiento de este) son diferentes o que el volumen de datos no es el mismo!
Enviame las trazas ...
Si crees que no puedes sacar la sentencia más pesada del Report y aislarla, entonces hay otra solución :
Mirarlo con un fichero de traza que genera tu report. Para ello tienes que tener el parámetro de la instancia : TIMED_STATISTICS igual a TRUE y USER_DUMP_DEST co nel valor del directorio donde dejará el fichero de traza (llamado <numero_de_sesion. trc>.
Antes, coge el Report y en el trigguer de BEFORE-REPORT escribe lo siguiente :
srw.do_sql(' ALTER SESSION SET SQL_TRACE TRUE');
Lo compilas ... etc.
Cuando se ejecute, generará un fichero con extensión '*. Trc' en el directorio donde has indicado en la variable anterior.
Coges y le das permisos de lectura y en la linea de comando escribe :
tkprof <ruta_del_fichero_trc>/nombre_del_fichero_trc.trc salida.txt explain=nombre_usurio_propietario_de_las_tablas@nodo_de _BD
Y, voilà, tienes el fichero salida.txt, ahí tendrás toda la información referente a las consultas que hace tu Report dándote todo tipo de medidas en tiempo y consumo y además el Plan de acceso de todo lo que ejecuta el report.
Haz lo mismo en los dos entornos, y veras las diferencias (o mandamenlo por PRIVADO, o por mail, indicándome tu mail en una Respuesta por Privado).
Esta es la mejor forma de saber como actúan los distintos servidores y de paso te metes un poco en el mundillo de optimización de rendimietos de oracle.
Te recomiendo esta opción!
3.- En lugar de crearte dos instancias en la misma máquina, create solo el usuario que tiene las tablas que vas a consultar :
Haces un 'export' del usuario remoto. Y el fichero '*. Dmp' que te genera, te lo traes a local o haces el 'import' desde allí (recuerda que el nuevo usuario que te creas en tu instancia local le des el nombre de usuario_remoto o algo así ... ¿ok?). Asegurate de que no tiene ningún objeto.
Luego en el 'import' recuerda de poner en los parámetros del import : FROM_USER=usuario_origen TO_USER=usuario_local_que_has_creado IGNORE=Y
Y de esta forma en otro usuario y sin necesidad de crearte una réplica ... tienes cargados todos los datos que necesitas. Entonces, sólo tienes que conectarte al Report con este nuevo usuario.
4.- 'db_link', s : No te lo recomiendo y si además tienes problemas en la red, pero te lo comento.
Puedes crear un objeto llamado DATABASE LINK que comunica a las dos instancias. De forma que si en sql*plus una vez creado haces : select * from tabla_remota@nombre_del_database_link podrás ver la información de las tablas de la BB. DD. Remotas desde tu instancia local. Luego te creas un sinónimo para no tener que escribir tabla_remota@nombre_del_database_link por tabla_normal (eso en un usuario nuevo, ya que sino, el nombre de la tabla ya existiría en tu usuario normal.
Lo habitual en estos casos es crearse 'Materialized View, s' con sus 'Log correspondientes' y automáticamente (cuando tu lo decides -se indica en la definición de este objeto-) hace copia de las ultimas acciones hechas en remoto sobre tu vista materializada 'on-line'.
----
Como ves, hay muchas cosas que se pueden hacer. YO TE RECOMENDARÍA EL HACER LO DEL EXPALIN PLAN (Plan de acceso) en una de las dos formas que te he dicho (sonsacando la select más potente y viendo la traza o bien a través del TKPROF). OPCIÓN 2.
De esta forma descubrirás técnicas de optimización de sentencias SQL y el comportamiento del motor de BB. DD. Que tiene Oracle.
Bueno si tienes alguna duda o especificación detallada de como hacer alguno de los casos, no tienes más que comentármelo. Y te indicaré paso a paso como hacerlo.
Pero aunque tengas la curiosidad de duplicar BB. DD., s o Instancias, ante este problema es como "matar moscas a cañonazos" y encima del riesgo que supone. Podría ser que no encontrases el porqué te pasa el problema que me indicas.
Y ya sabes ... Si tienes que preguntarme algo y lo quieres hacer en privado, por tema de confidencialidad o por envío de datos o por ser un tema extenso, mejor me mandas tu dirección de correo en una 'Respuesta Privada' y te contesto así.
Luego, si lo arreglamos, ya escribiremos aquí información para compartirla con todos, pero más resumida y sin datos particulares de tu información.
Un Saludo y espero noticias tuyas!
Ramón
Barcelona
Spain
En referencia a lo que me estás indicando, no es necesario el tener en tu PC la BB. DD. Duplicada (en el caso de que tengas recursos, tanto de CPU, como de disco, como de memoria).
De todas formas y como insistes tanto en que esa es la solución, haré dos cosas : una, te insto a la página web de un colega donde te explica paso por paso como duplicar una BB.DD.. Este es el link :
http://oraclexperto.blogspot.com/2005/07/copiar-una-base-de-datos.html
Por otra parte te doy mi visión particular que no pasa por temas tan GRANDES como el duplicado de BB. DD.
1.- La primera premisa es : Si un Report ejecutado en tu máquina con el MISMO VOLUMEN DE DATOS que existe en la BB. DD. Local y en la remota tarda más ... Y lo estás ejecutando con Report Server (es decir, haces una llamada URL del 'report_servlet' y el report está en la máquina remota, el problema se puede dividir en dos :
a). Que en el servido remoto los recursos son muy escasos, ya que lo tienes que compartir con todos los usuarios que intervengan en la aplicación o aplicaciones.
b). Tienes un 'serio problema' en la Red. La comunicación entre tu máquina y el servidor es muy lenta.
- Piensa que cuando lo ejecutas en tu PC, lo haces en local, y no existe más usuario que tu. Que consumes todos los recursos. Los recursos son exclusivos para tu Report.
Siempre teniendo en cuenta que el volumen de datos es igual en ambas BB. DD.!
2.- Tema de acceso a los datos :
¿Me has indicado que tienes una 9i. Cuáles el método definido para el optimizador? El de REGLAS -'RULE'-, el de COSTES -COST-' o 'CHOOSE' (que elige uno de los antes definidos en función de si tienes generadas estadísticas o no). Porque espero que no tengas 'FIRST_ROWS'!
Verifícalo mirando el parámetro de las dos Instancias desde sqlplus 'siendo dba' con :
SQL> show parameters OPTIMIZER_MODE
y
SQL> show parameters OPT%
Si es por Reglas, 'RULE' ... uff! Oracle las elimina en la 10g y recomienda en la 9i el uso de generación de estadísticas e ir por costes. Que se puede hacer si estas en modo 'CHOOSE' o en 'COST'. Pero tienes que tener generadas las estadísticas de los Objetos con STORAGE de la BB. DD.
Si no sabes como hacerlo, te lo indicaría.
Para tener más información de que es lo que te puede estar pasando, sabes hacer 'EXPLAIN PLAN', ¿s?
Lo digo para que veas como se comporta las sentencias de tu Report en el servidor local y que plan de ejecución tienes en el remoto.
Para ello tienes que tener acceso a la tabla 'PLAN_TABLE' y ejecutar las sentencias de tu report en las dos máquinas ...
Puedes hacer desde sql*plus :
SQL> set autotrace on
SQL> set timing on
SQL> Tu sentencia básica de SQL del Report (la que crees más costosa).
Compara entonces el tipo de Plan de acceso que te da cada una de las instancias, y ya está. Si ves diferencias, se debe a que o no se están ejecutando las estadísticas habituales, o que el modo del optimizador (y otros parámetros asociados al comportamiento de este) son diferentes o que el volumen de datos no es el mismo!
Enviame las trazas ...
Si crees que no puedes sacar la sentencia más pesada del Report y aislarla, entonces hay otra solución :
Mirarlo con un fichero de traza que genera tu report. Para ello tienes que tener el parámetro de la instancia : TIMED_STATISTICS igual a TRUE y USER_DUMP_DEST co nel valor del directorio donde dejará el fichero de traza (llamado <numero_de_sesion. trc>.
Antes, coge el Report y en el trigguer de BEFORE-REPORT escribe lo siguiente :
srw.do_sql(' ALTER SESSION SET SQL_TRACE TRUE');
Lo compilas ... etc.
Cuando se ejecute, generará un fichero con extensión '*. Trc' en el directorio donde has indicado en la variable anterior.
Coges y le das permisos de lectura y en la linea de comando escribe :
tkprof <ruta_del_fichero_trc>/nombre_del_fichero_trc.trc salida.txt explain=nombre_usurio_propietario_de_las_tablas@nodo_de _BD
Y, voilà, tienes el fichero salida.txt, ahí tendrás toda la información referente a las consultas que hace tu Report dándote todo tipo de medidas en tiempo y consumo y además el Plan de acceso de todo lo que ejecuta el report.
Haz lo mismo en los dos entornos, y veras las diferencias (o mandamenlo por PRIVADO, o por mail, indicándome tu mail en una Respuesta por Privado).
Esta es la mejor forma de saber como actúan los distintos servidores y de paso te metes un poco en el mundillo de optimización de rendimietos de oracle.
Te recomiendo esta opción!
3.- En lugar de crearte dos instancias en la misma máquina, create solo el usuario que tiene las tablas que vas a consultar :
Haces un 'export' del usuario remoto. Y el fichero '*. Dmp' que te genera, te lo traes a local o haces el 'import' desde allí (recuerda que el nuevo usuario que te creas en tu instancia local le des el nombre de usuario_remoto o algo así ... ¿ok?). Asegurate de que no tiene ningún objeto.
Luego en el 'import' recuerda de poner en los parámetros del import : FROM_USER=usuario_origen TO_USER=usuario_local_que_has_creado IGNORE=Y
Y de esta forma en otro usuario y sin necesidad de crearte una réplica ... tienes cargados todos los datos que necesitas. Entonces, sólo tienes que conectarte al Report con este nuevo usuario.
4.- 'db_link', s : No te lo recomiendo y si además tienes problemas en la red, pero te lo comento.
Puedes crear un objeto llamado DATABASE LINK que comunica a las dos instancias. De forma que si en sql*plus una vez creado haces : select * from tabla_remota@nombre_del_database_link podrás ver la información de las tablas de la BB. DD. Remotas desde tu instancia local. Luego te creas un sinónimo para no tener que escribir tabla_remota@nombre_del_database_link por tabla_normal (eso en un usuario nuevo, ya que sino, el nombre de la tabla ya existiría en tu usuario normal.
Lo habitual en estos casos es crearse 'Materialized View, s' con sus 'Log correspondientes' y automáticamente (cuando tu lo decides -se indica en la definición de este objeto-) hace copia de las ultimas acciones hechas en remoto sobre tu vista materializada 'on-line'.
----
Como ves, hay muchas cosas que se pueden hacer. YO TE RECOMENDARÍA EL HACER LO DEL EXPALIN PLAN (Plan de acceso) en una de las dos formas que te he dicho (sonsacando la select más potente y viendo la traza o bien a través del TKPROF). OPCIÓN 2.
De esta forma descubrirás técnicas de optimización de sentencias SQL y el comportamiento del motor de BB. DD. Que tiene Oracle.
Bueno si tienes alguna duda o especificación detallada de como hacer alguno de los casos, no tienes más que comentármelo. Y te indicaré paso a paso como hacerlo.
Pero aunque tengas la curiosidad de duplicar BB. DD., s o Instancias, ante este problema es como "matar moscas a cañonazos" y encima del riesgo que supone. Podría ser que no encontrases el porqué te pasa el problema que me indicas.
Y ya sabes ... Si tienes que preguntarme algo y lo quieres hacer en privado, por tema de confidencialidad o por envío de datos o por ser un tema extenso, mejor me mandas tu dirección de correo en una 'Respuesta Privada' y te contesto así.
Luego, si lo arreglamos, ya escribiremos aquí información para compartirla con todos, pero más resumida y sin datos particulares de tu información.
Un Saludo y espero noticias tuyas!
Ramón
Barcelona
Spain
