¿Cómo puedo pasar la información de una base de datos a otra?
Estimando
Ante todo y anticipadamente muchas gracias, una consulta tengo una bd de prod y una desarrollo que pasa que a la bd de desarrollo le ingresaron data ahora quiero pasar esa data a producción lo bueno que están en esquemas separados porque en bd tengo varios esquemas lo que iba hacer era lo siguiente:
1ro exp system/clave owner file=file.dmp log=file.log grants=y rows=y stattitics=none
Luego imp
imp system/clave filefile.dmp log=file.log fromuser=schema1 touser schema2
pero tambien puedo pasar solamenta las tablas , exp solamente tablas y imp las tablas.
Ahora no habrá ningún problema ya que bd esta activa o tendría que bajar la bd para proceder que me recomiendas hacer
Ante todo y anticipadamente muchas gracias, una consulta tengo una bd de prod y una desarrollo que pasa que a la bd de desarrollo le ingresaron data ahora quiero pasar esa data a producción lo bueno que están en esquemas separados porque en bd tengo varios esquemas lo que iba hacer era lo siguiente:
1ro exp system/clave owner file=file.dmp log=file.log grants=y rows=y stattitics=none
Luego imp
imp system/clave filefile.dmp log=file.log fromuser=schema1 touser schema2
pero tambien puedo pasar solamenta las tablas , exp solamente tablas y imp las tablas.
Ahora no habrá ningún problema ya que bd esta activa o tendría que bajar la bd para proceder que me recomiendas hacer
1 Respuesta
Respuesta de panzaverde
Es como decís, podes importar sólo las tablas o bien el esquema completo. Si es el esquema completo, lo más sencillo es eliminar el esquema y volver a crear el usuario vacío (con alguna herramienta de extracción de ddl), si no es posible, trata de importar sólo las tablas.
Si las tablas existen, podes truncarlas y le agregás ignore=10
No hay ningún tipo de problemas con la base de datos activa, es más si la base no esta abierta no vas a poder importar nada.
Por otro lado, no te recomiendo que uses imp para pasar cosas de desarrollo a producción porque algo puedes pisar, salvo que lo importes en algún esquema duplicado y te encargas de pasar las cosas "a mano" de ese esquema al real.
Si tu esquema de desarrollo es pepe y lo querés importar en un esquema juan de prod, tendrías que tener creado "juan" y agregarle fromuser=pepe touser=juan para que te haga el mapeo de lo que vas a importar.
Si estás en una versión 10 u 11, te sugiero que veas impdp/expdp que tiene más opciones (como por ejemplo no importar todas las constraints, o la constraint 'X', etc), hacer remapeos respecto a los tablespaces donde van a alojarse, dueños y es más rapido que import "estandar".
Pero volviendo a lo que te comentaba pasar cosas de desarrollo a Prod, tiene que ser un proceso bien a conciencia y controlado, por eso no me convence eso de datos ingresados en desea que se van a importar en prod; si lo que tenés que copiar son filas, podes usar un dblink.
Si las tablas existen, podes truncarlas y le agregás ignore=10
No hay ningún tipo de problemas con la base de datos activa, es más si la base no esta abierta no vas a poder importar nada.
Por otro lado, no te recomiendo que uses imp para pasar cosas de desarrollo a producción porque algo puedes pisar, salvo que lo importes en algún esquema duplicado y te encargas de pasar las cosas "a mano" de ese esquema al real.
Si tu esquema de desarrollo es pepe y lo querés importar en un esquema juan de prod, tendrías que tener creado "juan" y agregarle fromuser=pepe touser=juan para que te haga el mapeo de lo que vas a importar.
Si estás en una versión 10 u 11, te sugiero que veas impdp/expdp que tiene más opciones (como por ejemplo no importar todas las constraints, o la constraint 'X', etc), hacer remapeos respecto a los tablespaces donde van a alojarse, dueños y es más rapido que import "estandar".
Pero volviendo a lo que te comentaba pasar cosas de desarrollo a Prod, tiene que ser un proceso bien a conciencia y controlado, por eso no me convence eso de datos ingresados en desea que se van a importar en prod; si lo que tenés que copiar son filas, podes usar un dblink.
1ro si importo el schema completo previa eliminación y crearacion del usuario vacío pero ahí se van a crear todos los sinónimos, secuencias, procedure y trigger al momento de imp.
2do si trunco la tablas al importar las tabla le agrego ignore=10 ---que hace esto
3ro Porque no me recomiendas pasar con imp a la bd de producción que es lo que pasa comentame por favor porque tengo que tener bastante cuidado con prodruccion
4to Como te comente en el schema por de producción no hay nada de data solo están creadas la tablas ademas nadie se conecta, lo que paso es que en el aplicativo se olvidaron cambiar la ruta a producción, otra cosa el exp de desarrollo pesa más o menos 200k dmp es algo pequeño que han ingresado.
5to Como haría para crear un dblink creo un enlace a la otra bd desarrollo le hago un insert select no es cierto o es otra manera.
Saludos
2do si trunco la tablas al importar las tabla le agrego ignore=10 ---que hace esto
3ro Porque no me recomiendas pasar con imp a la bd de producción que es lo que pasa comentame por favor porque tengo que tener bastante cuidado con prodruccion
4to Como te comente en el schema por de producción no hay nada de data solo están creadas la tablas ademas nadie se conecta, lo que paso es que en el aplicativo se olvidaron cambiar la ruta a producción, otra cosa el exp de desarrollo pesa más o menos 200k dmp es algo pequeño que han ingresado.
5to Como haría para crear un dblink creo un enlace a la otra bd desarrollo le hago un insert select no es cierto o es otra manera.
Saludos
1- Si, se crea todo. No estoy seguro que pasa con la secuencia (con el nro actual). Los sinónimos privados solamente, es decir lo que le pertenece al usuario en cuestión.
2-Perdon es ignore=yes! Para que siga adelante a pesar que las tablas estén creadas, sino da error (ahí podes poner constrainst=N y demás, fíjate con imp help=y
3- Simplemente porque podes tener algún error de procedimientos y pisar algunos datos.
4- Si es así, dale para adelante con el imp del esquema entero, que vas a tener menos problemas, salvo que las definiciones de las tablas y demás sean distintas. Si está todo igual, lo más sencillo es eso. Pero te vas a tener que llevar todo lo que no es del esquema y se necesita, como son todos los objetos del Public (sinónimos públicos por ejemplo) y la parte de roles como hablábamos.
5- Claro create public database link link_desa connect to USUARIO_DESA identified by passssss using 'desa'. 'Desa' es el nombre del alias en el TNSNAMES del servidor de Prod. Pero cuidado con las secuencias, por eso que te comento de las secuencias.
2-Perdon es ignore=yes! Para que siga adelante a pesar que las tablas estén creadas, sino da error (ahí podes poner constrainst=N y demás, fíjate con imp help=y
3- Simplemente porque podes tener algún error de procedimientos y pisar algunos datos.
4- Si es así, dale para adelante con el imp del esquema entero, que vas a tener menos problemas, salvo que las definiciones de las tablas y demás sean distintas. Si está todo igual, lo más sencillo es eso. Pero te vas a tener que llevar todo lo que no es del esquema y se necesita, como son todos los objetos del Public (sinónimos públicos por ejemplo) y la parte de roles como hablábamos.
5- Claro create public database link link_desa connect to USUARIO_DESA identified by passssss using 'desa'. 'Desa' es el nombre del alias en el TNSNAMES del servidor de Prod. Pero cuidado con las secuencias, por eso que te comento de las secuencias.
Una ultima pregunta que cosa no guarda al exp el schema creo que son sinónimos públicos, roles y que otra cosa más explicame por favor.
Y como hago para importar los sinónimos públicos y los roles los creo manualmente explicame por favor
Saludos
Y como hago para importar los sinónimos públicos y los roles los creo manualmente explicame por favor
Saludos
Todo lo que no sea del usuario. Los roles no pertenecen a nadie, los sinónimos pueden ser de un usuario o públicos. No se si hay otro objeto...
Si a los sinónimos vas a tener crearlos manualmente, lo mismo que los roles. En la dba_synonyms.
¿Una duda... qué tan distinta es tu base de datos de desarrollo respecto a la de producción? En cuanto a archivos, el nombre de la base de datos y demás. Te pregunto porque ya que no han puesto del todo en producción la otra db, por ahí podes copiarte la desarrollo y levantar la base completa.
Si a los sinónimos vas a tener crearlos manualmente, lo mismo que los roles. En la dba_synonyms.
¿Una duda... qué tan distinta es tu base de datos de desarrollo respecto a la de producción? En cuanto a archivos, el nombre de la base de datos y demás. Te pregunto porque ya que no han puesto del todo en producción la otra db, por ahí podes copiarte la desarrollo y levantar la base completa.
Pero son muchos synonyms para crear como hago para hacerlo más rapido hay un scrpit que te genere todos los synonyms public quizás en roles es menos, ahora los public donde se guardar, lo que pasa solamente es un schema que tiene poca data en camdio la de producción tiene mucha data.
Si ejecutas esto en el servidor de desarrollo tendrás el script para crear en el otro servidor, si el sinónimo ya existe te dará un error, pero no pasa nada. Si el objeto que referencia el sinónimo no existe, se crea igual pero queda inválido.
SELECT 'CREATE PUBLIC SYNONYM ' || SYNONYM_NAME|| ' FOR ' || TABLE_OWNER ||'.'|| TABLE_NAME ||';'
FROM DBA_SYNONYMS
WHERE OWNER='PUBLIC'
SELECT 'CREATE PUBLIC SYNONYM ' || SYNONYM_NAME|| ' FOR ' || TABLE_OWNER ||'.'|| TABLE_NAME ||';'
FROM DBA_SYNONYMS
WHERE OWNER='PUBLIC'
Hola
Este script me genera solamente el create public synoyms ... pero como hago tengo que copiar y ejecutar todo los create ahora tengo un script que me conseguí en la web pero algunas veces crea los synonyms en otro schema espero me puedas ayudar si quiere te lo envío dame un correo y te lo envío.
Muchas gracias
Este script me genera solamente el create public synoyms ... pero como hago tengo que copiar y ejecutar todo los create ahora tengo un script que me conseguí en la web pero algunas veces crea los synonyms en otro schema espero me puedas ayudar si quiere te lo envío dame un correo y te lo envío.
Muchas gracias
Los sinónimos son públicos o privados, si no se antepone "PUBLIC" en el create synonym, éste se creara como sinónimo privado, es decir un sinónimo que sólo puede ver el dueño del esquema donde se creó.
Fíjate en la consulta que crea el script que te pasé, a ver dónde están creados los sinónimos, la que yo te pasé filtra por owner='PUBLIC', pero de todas maneras si vas a usar un import con el fromuser touser, todo lo que es del usuario se pasa, incluso los sinónimos.
Verificá los objetos que no tenés en producción y que están en desarrollo, a eso lo podes hacer con algún dblink. No te olvides que los sinónimos son sólo un tipo de objeto que quizá no tengas igual, ¿pero qué pasa con los procedimientos y demás?.
Una vez que tenas todo igual, truncas las tablas (deshabilitando restricciones sino no te deja) y luego importas sólo los datos de las tablas con "tables=tabla1, 2, 3" y con ignore=yes.
Fíjate en la consulta que crea el script que te pasé, a ver dónde están creados los sinónimos, la que yo te pasé filtra por owner='PUBLIC', pero de todas maneras si vas a usar un import con el fromuser touser, todo lo que es del usuario se pasa, incluso los sinónimos.
Verificá los objetos que no tenés en producción y que están en desarrollo, a eso lo podes hacer con algún dblink. No te olvides que los sinónimos son sólo un tipo de objeto que quizá no tengas igual, ¿pero qué pasa con los procedimientos y demás?.
Una vez que tenas todo igual, truncas las tablas (deshabilitando restricciones sino no te deja) y luego importas sólo los datos de las tablas con "tables=tabla1, 2, 3" y con ignore=yes.
Lo pasos que sigo para preprara la base de desarrollo son:
1. Exporto todos lo schemas
exp system/xxxx owner=schema file=schema.dmp log=schema.log grants=y rows=y statistc=none.
2. exp los synonims de produccion con un scrip que me genera un txt que luego lo ejecuto en desarrollo.
Ahora en desarrollo
1. Ejecuto el txt de synonms en la bd de desarrollo.
2. Creo todos lo roles manualmente y luego importo todos los schema
imp system/xxx file=schema.dmp log=schema.log full=y grants=y rows=y
3. Si faltan algunos privilegios lo creo manualmente.
Pero acá es donde hay muchos objects, sinónimos sin compilar que luego lo compilo manuamente y muchos no se dejan compilar.
Mi pregunta es la siguiente esta bien mis paso que hago para prepara un ambiente de desarrollo con la experiencia que tienes te parce la correcta hay otro método mejor o siempre voy a tener que crear manualmente muchos cosa que falta que la bd función igual que la producción.
Saludos
1. Exporto todos lo schemas
exp system/xxxx owner=schema file=schema.dmp log=schema.log grants=y rows=y statistc=none.
2. exp los synonims de produccion con un scrip que me genera un txt que luego lo ejecuto en desarrollo.
Ahora en desarrollo
1. Ejecuto el txt de synonms en la bd de desarrollo.
2. Creo todos lo roles manualmente y luego importo todos los schema
imp system/xxx file=schema.dmp log=schema.log full=y grants=y rows=y
3. Si faltan algunos privilegios lo creo manualmente.
Pero acá es donde hay muchos objects, sinónimos sin compilar que luego lo compilo manuamente y muchos no se dejan compilar.
Mi pregunta es la siguiente esta bien mis paso que hago para prepara un ambiente de desarrollo con la experiencia que tienes te parce la correcta hay otro método mejor o siempre voy a tener que crear manualmente muchos cosa que falta que la bd función igual que la producción.
Saludos
En el paso 2 vas a tener que hacer el fromuser=usuariodesa touser=usuarioprod.
Mira no es lo mejor, pero tampoco es muy común que tengas que hacer eso, porque se supone que los cambios que se hacen en desarrollo se pasan de forma controlada a producción y no en forma masiva, y ni hablar de los datos.
Mira para armar un entorno de prueba, en gral tomamos la definición del usuario (y la de los roles) de producción y generamos un script para recrearlo en desarrollo. Después hacemos un imp del esquema entero.
Después los desarrolladores se encargan de los objetos que no están compilados, que en muchos casos no se pueden compilar al momento de la carga por la secuencia en la que se cargaron los objetos de los cual depende. Hasta ahora lo manejamos así y no hay problemas, porque se supone que no varía tanto.
Pero hay que distinguir bien qué es un entorno de desarrollo, uno de prueba y uno de producción.
Normalmente en el de prueba, no vas a tener tantos datos como en producción y quizá si tengas que importar las estadísticas de prod para que el optimizador trate de reaccionar igual. Acá la importación de datos sólo se podría hacer a nivel de tabla porque hay que mantener el código que se está desarrollando.
En un entorno de prueba, normalmente es una copia de producción (ahí podes hacer un imp del esquema) y sólo se aplican los cambios que se hicieron en desarrollo, para ser probados con datos reales, pero esos cambios se hacen a conciencia y no en forma masiva.
Si tienes versions 10 u 11, ahí el impdp/expdp tienen opciones muy interesantes para hacer estas tareas más sencillas y fundamentalmente más rápidas.
Mira no es lo mejor, pero tampoco es muy común que tengas que hacer eso, porque se supone que los cambios que se hacen en desarrollo se pasan de forma controlada a producción y no en forma masiva, y ni hablar de los datos.
Mira para armar un entorno de prueba, en gral tomamos la definición del usuario (y la de los roles) de producción y generamos un script para recrearlo en desarrollo. Después hacemos un imp del esquema entero.
Después los desarrolladores se encargan de los objetos que no están compilados, que en muchos casos no se pueden compilar al momento de la carga por la secuencia en la que se cargaron los objetos de los cual depende. Hasta ahora lo manejamos así y no hay problemas, porque se supone que no varía tanto.
Pero hay que distinguir bien qué es un entorno de desarrollo, uno de prueba y uno de producción.
Normalmente en el de prueba, no vas a tener tantos datos como en producción y quizá si tengas que importar las estadísticas de prod para que el optimizador trate de reaccionar igual. Acá la importación de datos sólo se podría hacer a nivel de tabla porque hay que mantener el código que se está desarrollando.
En un entorno de prueba, normalmente es una copia de producción (ahí podes hacer un imp del esquema) y sólo se aplican los cambios que se hicieron en desarrollo, para ser probados con datos reales, pero esos cambios se hacen a conciencia y no en forma masiva.
Si tienes versions 10 u 11, ahí el impdp/expdp tienen opciones muy interesantes para hacer estas tareas más sencillas y fundamentalmente más rápidas.
¿1ro qué diferencia hay de la manera que lo importo a fromuser to user es?
2do me podrías indicar como recrear el script de las definiciones del usuario y roles porque lo hago manualmente.
Saludos,
2do me podrías indicar como recrear el script de las definiciones del usuario y roles porque lo hago manualmente.
Saludos,
2- Mira estoy usando la consola de administración y no lo hago a mano (uso el crear como ).
1- La verdad que por seguridad (y como siempre importamos esquemas o tablas de terceros), uso el fromuser touser por las dudas, además que te permite importar cosas de usarioX en el esquema del usuarioY.
1- La verdad que por seguridad (y como siempre importamos esquemas o tablas de terceros), uso el fromuser touser por las dudas, además que te permite importar cosas de usarioX en el esquema del usuarioY.
Me estoy confundiendo como lo hago el crear como..
Estoy usando la consola de administración, no estoy usando un script. Cualquier herramienta de administración debe tener esa opción, yo uso la consola del Enterprise Manager (esto en 9i) sino la consola web tipo Grid Control de 10g u 11g.
