Seguro que a todos los que trabajais con Oracle (o con Sap y como base de datos Oracle como es mi caso), os ha surgido la necesidad de replicar una base de datos productiva (o de un entorno de pruebas), en otro sistema. En mi caso, trabajando con Sap, regularmente realizo una copia de la base de datos real en el sistema de desarrollo (integración), para que la pruebas de los cambios, desarrollos o parametrizaciones sean lo mas completas posibles (y lo mas fáciles posible de cara al usuario si dispone de los datos "reales" más actualizados).
Acabo de terminar la instalación de un nuevo entorno de desarrollo Sap (por un cambio de hardware), en el que hemos aprovechado para hacer una replica del sistema productivo a nivel de base de datos. Os voy a explicar los pasos seguidos por si alguno de vosotros tiene la misma necesidad, aunque seguro que hay otras formas de hacerlo (export de base de datos, utilizando RMAN, etc). En mi caso, he partido de un backup Online (aunque es recomendable realizarlo con uno Offline), y he copiado una base de datos que se llama MG1 en otra en una máquina distinta que se llama DE1. El procedimiento que os voy a explicar esta validado con Oracle 9i... 

El modo archivelog de una base de datos Oracle protege contra la pérdida de datos cuando se produce un fallo en el medio físico y es el primer paso para poder hacer copias de seguridad(en caliente!!) con rman. Para poner la base de datos en modo archivelog (sin usar la flash recovery area) debemos hacer básicamente dos cosas, añadir dos parámetros nuevos al fichero de configuración, reiniciar la base de datos y cambiar el modo trabajo a archivelog.

Como poner la base de datos Oracle 10g en modo archivelog

1. Editamos el init.ora para añadir los siguientes parámetros
   *.log_archive_dest='/ejemplo/backup/'
   *.log_archive_format='SID_%r_%t_%s'
   .....

Con MySQL, cuando se eliminan registros de una tabla, el espacio no se reasigna automáticamente. El problema de esto es que si en una tabla se realizan operaciones de DELETE, el espacio físico de la tabla va quedando cada vez más fragmentado. En MySQL, disponemos del comando OPTIMIZE TABLE para poder realizar sobre cualquier tabla una optimización que, entre otras cosas, realiza una defragmentación automática de la tabla..

Nos ponemos en situación
En nuestro entorno es posible que necesitemos disponer de dos replicas de una/s base de datos en entornos diferenciados (el clásico ejemplo sería producción y test). Para decidir como lo hacemos las preguntas más comunes que nos debemos hacer son:

-¿Este nuevo entorno será temporal? ¿Contiene bases de datos grande en cuanto a volumen y/o la carga que debe soportar es elevada(aunque sea test)?
-¿Dispongo de la versión de desarrollo de SqlServer2008? Que solo está a tu alcance si tienes una suscripción Msdn...
-¿Dispongo de un servidor adicional?...

MySQL, al igual que la mayoría de gestores de bases de datos, permite modificar fácilmente sus parámetros que controlan tamaños de memoria dedicados a determinadas tareas, utilización de recursos, límites de concurrencia, etc.

Ajustando adecuadamente estos parámetros se pueden obtener muchas mejoras de rendimiento, sobretodo si el servidor/es de la base de datos no va sobrado de recursos, y si por la parte de optimización SQL no se puede mejorar mucho más.