WEBVTT 00:00:09.680 --> 00:00:11.402 Buenas tardes, Facundo por fin. 00:00:12.000 --> 00:00:14.200 Sí, buenas tardes ¿Cómo estás, Javier? 00:00:15.420 --> 00:00:19.760 Estamos empezando con 40 minutos de retraso, aunque a quien lo esté escuchando esto del 00:00:19.800 --> 00:00:21.520 podcast le va a dar bastante igual. 00:00:21.560 --> 00:00:25.900 Pero teníamos previsto empezar a las 4, son las 4 .40 y justo ahora acabamos de resolver 00:00:25.940 --> 00:00:29.980 los problemas de micro y de escucharnos, no escucharnos que teníamos hasta ahora. 00:00:30.020 --> 00:00:32.000 Madre mía, qué desastre ¿A que sí? 00:00:32.360 --> 00:00:35.880 Bueno, unos problemas hasta técnicos, pero ya estamos aquí. 00:00:36.400 --> 00:00:41.400 Claro, como no son temas de oracle, pues temas de micrófono son más difíciles de resolver. 00:00:41.680 --> 00:00:44.610 Bueno, qué bien, por fin. 00:00:45.210 --> 00:00:46.877 ¿Qué tal Facundo? ¿Cómo estás? 00:00:47.380 --> 00:00:54.060 Muy bien, muy bien. Yo me preparé el mate cocido acá en Buenos Aires. 00:00:54.540 --> 00:00:56.262 Ah, eso lo puse es el mediodía. 00:00:56.400 --> 00:00:57.980 Sí, sí, sí, lo vi, lo vi. 00:00:59.120 --> 00:01:06.580 Bueno, acá estamos preparados para charlar sobre este producto Que se llama ZDM 00:01:06.580 --> 00:01:09.220 o Zero Downtime Migration 00:01:10.890 --> 00:01:16.210 Que es un producto muy bueno, muy bueno, a mí me gustó mucho 00:01:17.270 --> 00:01:19.690 Si querés empezamos Javier Sí, 00:01:20.840 --> 00:01:26.020 bueno, yo iba de la audiencia, de las personas que tenemos en la audiencia Yo sé, por 00:01:26.020 --> 00:01:30.960 ejemplo, David, que es uno de los que está ahí él lo va a sufrir en sus carnes porque 00:01:30.960 --> 00:01:36.580 suben toda su arquitectura, la mayor parte de su arquitectura de la empresa la suben 00:01:36.580 --> 00:01:40.400 a la nube y era uno de los temas que teníamos en la mentoría de Café de Atrevis que tenemos 00:01:40.440 --> 00:01:47.340 ahí caliente, estamos hablando de de la parte online la migración online la migración 00:01:47.340 --> 00:01:54.260 offline qué componentes entraban en cada una de las configuraciones lo del appliance 00:01:54.260 --> 00:01:57.204 también, o sea que tenemos el tema este muy calentito 00:01:58.340 --> 00:02:05.360 Bueno, fenómeno. Este tema le va a servir mucho a David porque se va 00:02:05.360 --> 00:02:07.640 a ahorrar muchos dolores de cabeza. 00:02:10.640 --> 00:02:12.029 Pues venga, vamos a ello. 00:02:12.100 --> 00:02:17.080 Vamos a ver. ¿Cuánto de cero es el cero? 00:02:17.080 --> 00:02:18.524 Sería la primera pregunta. 00:02:19.020 --> 00:02:20.560 ¿Cuánto de cero es el cero downtime? 00:02:20.600 --> 00:02:26.520 Y bueno, eso va a depender, entiendo yo, de cómo uno lo mire. 00:02:27.020 --> 00:02:34.340 Si uno lo mira solo en la capa nuestra de base de datos o 00:02:34.340 --> 00:02:38.480 levanta un poquito la mirada y lo mira en 00:02:40.340 --> 00:02:44.040 Las distintas capas que tiene la arquitectura. 00:02:44.040 --> 00:02:50.040 Porque en definitiva, nosotros hacemos los trabajos, pero lo que importa es la experiencia 00:02:50.040 --> 00:02:55.300 del usuario. Entonces, por más que nosotros hagamos una migración con un corte de servicio 00:02:55.300 --> 00:03:02.540 de un minuto, si después una persona tiene que ir a las aplicaciones y 00:03:02.540 --> 00:03:08.990 ir modificando las cadenas de conexiones y eso le lleva 30 minutos, bueno, al usuario 00:03:08.990 --> 00:03:11.150 le impacta esos 30 minutos, ¿no? 00:03:11.150 --> 00:03:18.840 Entonces, dependiendo de cómo se mire, podemos llegar a casi un cero downtime, ¿sí 00:03:18.840 --> 00:03:24.240 o no? O podríamos tener muchos minutos de downtime. 00:03:24.240 --> 00:03:31.940 Pero bueno, yo tengo algunos tips que usamos en nuestro trabajo, que después 00:03:31.940 --> 00:03:38.350 les puedo ir mencionando, para tratar de ese corte de servicio a nivel capa de base de 00:03:38.350 --> 00:03:44.390 datos y a nivel aplicaciones, lo podamos reducir a la mínima expresión. 00:03:46.570 --> 00:03:53.240 Pero bueno, me gustaría contar que este producto es un producto de desarrollo Oracle 00:03:53.240 --> 00:03:58.610 El referente de este producto es Ricardo González, que es el Product Manager 00:04:01.670 --> 00:04:03.730 ¿Y para qué sirve este producto? 00:04:03.990 --> 00:04:10.990 Bueno, para migrar Pero tiene restricciones, no podemos usarlo para cualquier 00:04:10.990 --> 00:04:15.360 migración La primera restricción son los destinos. 00:04:16.280 --> 00:04:22.660 Este producto se puede usar para migrar base de datos hacia destinos de la nube, como 00:04:22.660 --> 00:04:30.040 puede ser el database service, base de datos Oracle, que 00:04:30.040 --> 00:04:36.140 estén en Exadata, en la nube, que puede ser en infraestructura dedicada o cloud customer. 00:04:36.140 --> 00:04:41.920 Customer, ¿sí? Cloud Customer significa que te traen el equipo, ¿sí? 00:04:41.980 --> 00:04:48.680 El hardware, el exata a tu centro de cómputos y está físicamente ahí, o sea, los datos 00:04:48.680 --> 00:04:50.920 vos los tenés en tu centro de cómputos, ¿sí? 00:04:50.960 --> 00:04:53.100 Pero se maneja como si fuera la nube. 00:04:53.100 --> 00:05:00.250 Otro destino que pueden ser las bases autónomas tanto la transaccionar la que se le dice 00:05:00.250 --> 00:05:04.010 ATP como la de Data Warehouse, la ADW y 00:05:04.970 --> 00:05:10.610 algo que me llamó la atención, que ayer estuve cuando repasé este tema, es que también 00:05:10.610 --> 00:05:15.450 se puede usar como destino un exadata común on -premise ¿Ah? 00:05:16.170 --> 00:05:22.670 Oh, que buena esta Eso está muy bueno, sí Esta no la sabía yo Ahora, por ejemplo, si 00:05:22.670 --> 00:05:29.050 vos querés migrar a un clúster que vos armaste con BimWare en tu empresa, ahí no podés, 00:05:29.150 --> 00:05:33.650 no te funciona. Esa es la primera restricción. 00:05:36.090 --> 00:05:43.300 Bueno, y este producto, como vos bien decías, te permite emigrar en cuatro modalidades. 00:05:44.600 --> 00:05:48.510 Primero vamos a hacer la diferencia de dos. 00:05:49.520 --> 00:05:52.480 Lógico y físico, ¿no? Exacto. 00:05:52.960 --> 00:06:00.300 Bueno, podemos hacer migraciones físicas o lógicas y dentro de cada una, online u offline. 00:06:02.680 --> 00:06:09.910 La diferencia entre online y offline es el tiempo de corte, de 00:06:09.910 --> 00:06:11.510 la ventana de corte que vas a necesitar. 00:06:11.550 --> 00:06:13.750 Cuando vos lo haces offline, ¿qué haces? 00:06:13.790 --> 00:06:20.090 Parás todos los sistemas, parás todas las bases, te dedicas a migrar el tiempo que vos 00:06:20.090 --> 00:06:25.230 necesites Y una vez que terminás, volvés a levantar los sistemas y la base. 00:06:26.650 --> 00:06:32.290 Entonces, si vos estás trabajando en una empresa que te permite tener paradas de servicios 00:06:32.290 --> 00:06:39.390 amplias, dependiendo del tamaño de tu base y demás, podrías 00:06:39.390 --> 00:06:45.880 usar la offline. Pero si estás trabajando en empresas como la mía, que no te permiten 00:06:45.880 --> 00:06:51.600 tener cortes de servicios amplios, siempre te vas a tener que dirigir a la opción de 00:06:51.600 --> 00:06:58.520 online para minimizar el corte de servicio vale aquí aquí facundo aquí nos encontramos 00:06:58.520 --> 00:07:05.940 con el primer oxymoron cero downtime offline son términos 00:07:05.940 --> 00:07:13.230 contradictorios entre sí no exactamente aquí claro yo lo que lo que veíamos 00:07:13.230 --> 00:07:20.950 en el tema de online y offline vale y la parte también lógica o física es que más 00:07:20.950 --> 00:07:28.050 o menos lo que voy añadiendo también yo de lo mío no es que si si vas a hacerlo 00:07:28.050 --> 00:07:35.570 digamos a nivel lógico que utilices golden gate para ir a tapar para hacerlo online 00:07:35.570 --> 00:07:40.950 si es golden gate sincronizas el destino y propagas toda la actividad y si no si es offline 00:07:40.950 --> 00:07:45.830 datapump entonces aquí me vino la primera es decir hombre cero downtime si tengo que 00:07:45.830 --> 00:07:51.390 parar los servicios hacer un datapump a destino e importar hombre cero cero downtime 00:07:51.390 --> 00:07:58.590 aquí hay bastante bastante downtime exactamente en la parte física igual pero bueno así 00:07:58.590 --> 00:08:04.550 se llama el producto así se llama el producto si lo que pasa que el producto tiende más 00:08:04.550 --> 00:08:11.790 a a aprovechar las bondades de los tipos De migraciones online y ahí voy a 00:08:11.790 --> 00:08:17.650 comentar algo interesante sobre uno de los tipos que vos mencionaste recién. 00:08:18.190 --> 00:08:21.870 La migración lógica online, ¿qué 00:08:22.900 --> 00:08:28.200 hace? Utiliza primero el data pump como para hacer la carga inicial y después utiliza 00:08:28.200 --> 00:08:32.240 un golden gate para ir manteniendo la base de destino actualizada. 00:08:32.240 --> 00:08:39.980 Entonces, después, cuando uno coordina la ventana de corte, bueno, ahí se 00:08:40.490 --> 00:08:47.720 le indica al ZDM que ya puede hacer, digamos, el switch y listo, 00:08:47.720 --> 00:08:49.331 tenés la migración terminada. 00:08:49.740 --> 00:08:55.880 Pero, nombramos otro producto acá, el GoldenGate, ¿verdad? 00:08:56.240 --> 00:09:01.860 Claro y si vos trabajás en una empresa que no tiene GoldenGate, ¿lo podés usar este 00:09:01.860 --> 00:09:04.400 producto? ¿Te gusta? Sí, lo podés usar. 00:09:04.620 --> 00:09:11.920 ¿Por qué? Porque ahora que te brinda una versión, digamos, mínima 00:09:11.920 --> 00:09:17.520 y específica para este producto de GoldenGate, que vos la podés descargar gratuitamente 00:09:17.520 --> 00:09:25.240 y creo, si no recuerdo mal, que te la dejan usar por 180 días o un tiempo determinado. 00:09:26.440 --> 00:09:34.010 Entonces los que no tengan en su empresa licenciado GoldenGate igual pueden usar 00:09:34.010 --> 00:09:41.440 esta metodología Sin coste sin coste 00:09:41.440 --> 00:09:48.450 exactamente Y cuál es la ventaja de este producto, el ZDM 00:09:48.450 --> 00:09:54.590 es que todo lo que hacíamos los DBA años atrás que lo hacíamos manualmente por ejemplo 00:09:54.590 --> 00:09:58.790 si vamos a la migración lógica ¿Qué creábamos? 00:09:58.830 --> 00:10:01.070 La base nueva ¿Qué hacíamos? 00:10:01.110 --> 00:10:03.870 El datapump, el export, el import. 00:10:04.470 --> 00:10:11.800 ¿Qué teníamos que crear? Los extractores de GoldenGate, los replicadores para luego mantenerse 00:10:11.800 --> 00:10:14.580 actualizadas. ¿Qué después hacíamos? 00:10:14.580 --> 00:10:19.440 El switch. Bueno, todas esas tareas te las hace automática. 00:10:19.440 --> 00:10:26.380 Y antes del switch, digamos que cortábamos, abríamos el destino para que probaran con 00:10:26.380 --> 00:10:33.160 un restore point, probaban, rebobinábamos, volvíamos a sincronizar GoldenGate, se reparaban 00:10:33.160 --> 00:10:39.280 ciertas cosas en origen. Así una migración de estas de cero downtime a mí me podía llevar 00:10:39.280 --> 00:10:46.480 tres meses. Es decir a preparar cortar hacer una simulación que prueban en destino volvemos 00:10:46.480 --> 00:10:51.540 a re sincronizar otra vez vamos a parar así varias veces mientras van probando aplicaciones 00:10:51.540 --> 00:10:58.760 aquí también hay que probar la nube que está funcionando en nube y lo 00:10:58.760 --> 00:11:03.900 mismo con la migración física lo que te hace por atrás vamos a hablar más de la online 00:11:03.900 --> 00:11:09.280 la offline lo que te hace por atrás este producto te hace Hace un backup, todas las piezas 00:11:09.280 --> 00:11:15.460 de backup lo guarda en un backup location, digamos, que tiene que ser visto tanto por 00:11:15.460 --> 00:11:18.571 el origen como el destino, y después te hace un restore. 00:11:19.360 --> 00:11:26.370 Pero en la física online, lo que te hace por atrás es, te crea un 00:11:26.370 --> 00:11:33.230 dataguard en línea, sin usar piezas de backup, y después te hace el switchover. 00:11:33.230 --> 00:11:40.910 Ver si esas tareas también los delante las sigamos todas a mano creábamos el atacar todo 00:11:40.910 --> 00:11:48.180 todo a mano Y bueno como si queremos usar z m que tenemos que hacer bueno tenemos 00:11:48.180 --> 00:11:54.680 que ingresar a la página de este producto que después lo vamos a dejar javier si te parece 00:11:54.680 --> 00:12:02.200 el link lo podemos compartir para que que lo que voy a 00:12:02.200 --> 00:12:10.540 crear un canal que se llame 0 0 y ponemos 00:12:10.540 --> 00:12:17.610 la información en bueno entonces uno que tiene que hacer uno necesita primero 00:12:17.610 --> 00:12:25.630 un servidor con pocos recursos si no no no tiene muchos requerimientos se 00:12:25.950 --> 00:12:32.330 instala a partir de un Oracle Linux 7, se le tiene que instalar ciertos paquetitos que 00:12:32.330 --> 00:12:39.960 necesita, ciertos RPM, se le crea un usuario del sistema operativo propio, se 00:12:40.440 --> 00:12:45.950 descarga el instalador de Oracle, se lo descomprime y se lo instala. 00:12:46.090 --> 00:12:53.620 Es muy sencillo, eso lo pueden encontrar en los manuales que están paso a paso, no requiere, 00:12:53.680 --> 00:13:01.160 no tiene muchas complicaciones y ese servidor lo que necesita es tener una 00:13:01.160 --> 00:13:08.320 conexión ssh sin contraseña hacia el servidor de base 00:13:08.320 --> 00:13:14.240 de datos origen y hacia el servidor de base de datos destino si después 00:13:15.390 --> 00:13:23.340 ese ese programita digamos se levanta sigue el z m y se levanta como un servicio en 00:13:23.340 --> 00:13:25.720 linux y queda ahí corriendo 00:13:27.040 --> 00:13:32.930 Entonces lo que tenemos que tener en cuenta bueno primero la restricción que hablamos 00:13:32.930 --> 00:13:40.060 al principio del destino sí y después algo interesante fíjate que los 00:13:40.060 --> 00:13:47.020 destinos generalmente de la nube son todas bases de datos encriptadas con TD transparent 00:13:47.020 --> 00:13:54.340 data encryption entonces si Si vos querés mirar una base que vos tenés on -premise y 00:13:54.340 --> 00:13:56.440 esa base no tiene encriptación, 00:13:57.730 --> 00:14:04.250 Ahí vas a tener que hacer algunos pasos extras para poner la encriptación antes de emigrarla. 00:14:06.760 --> 00:14:09.140 Bueno, después, una vez que... 00:14:09.660 --> 00:14:12.140 Eso es interesante, ténganlo en cuenta. 00:14:13.670 --> 00:14:16.570 Eso también, se busca en la documentación y ya está todo. 00:14:16.610 --> 00:14:21.990 Y después, bueno, es cuestión de preparar 00:14:23.650 --> 00:14:29.030 El programa para que funcione, si se crea un response file, un archivo de parámetros, 00:14:29.150 --> 00:14:36.530 donde uno le va configurando los valores que necesita cada parámetro, según 00:14:36.530 --> 00:14:41.370 el tipo de migración que quiera usar, física, lógica, online, offline. 00:14:41.370 --> 00:14:48.660 Y bueno, y el ZM viene con unos comandos propios que 00:14:49.100 --> 00:14:55.360 uno tiene que aprender a usar pero quédense tranquilos que es mucho más sencillo aprender 00:14:55.360 --> 00:15:02.160 a usar ZM que tener que andar haciendo todos los pasos que hacíamos antes manualmente 00:15:02.160 --> 00:15:09.620 nosotros y bueno, se 00:15:09.620 --> 00:15:16.980 van ejecutando esos comandos y el producto primero chequea que todo lo que necesita 00:15:16.980 --> 00:15:24.220 esté bien, tanto de origen como destino, te informa que está bien y después vos podés 00:15:24.220 --> 00:15:29.800 lanzar el comando que realmente hace la migración. 00:15:30.620 --> 00:15:37.810 Ese comando que uno puede ejecutar, si uno utiliza un argumento, 00:15:37.810 --> 00:15:42.830 que es guión del medio eval, Eval, ¿para qué sirve? 00:15:43.230 --> 00:15:48.950 Evalúa que la migración, digamos, se pueda hacer bien. 00:15:49.030 --> 00:15:53.950 Es decir, te hace como un chequeo de todos los prerequisitos. 00:15:53.950 --> 00:15:55.728 Claro, como un pre -check sería. 00:15:56.350 --> 00:16:03.730 Y acá algo interesante si vos estás usando la migración física online 00:16:03.730 --> 00:16:11.400 y vos tirás el comando para que el ZDM realice la migración, lo 00:16:11.400 --> 00:16:17.340 que va a hacer el ZDM va a preparar, primero va a chequear todos los requisitos, si está 00:16:17.340 --> 00:16:22.240 todo bien, va a preparar su Data Guard y una vez que esté todo el Data Guard sincronizado, 00:16:22.340 --> 00:16:25.840 En ese momento te va a hacer el switchover y te lo va a migrar. 00:16:25.970 --> 00:16:29.150 Entonces, cuidado acá. ¿Por qué? 00:16:29.490 --> 00:16:31.530 Nosotros en nuestra empresa, ¿qué hacemos? 00:16:31.570 --> 00:16:38.790 Cuando lanzamos el comando, queremos que chequee todos los requisitos, que armen el ATGAR, 00:16:38.830 --> 00:16:41.970 pero no queremos que en ese momento nos haga el switchover. 00:16:42.010 --> 00:16:46.830 Porque el switchover lo tenemos que decidir nosotros cuando hacerlo, cuando nosotros 00:16:46.830 --> 00:16:49.010 conseguimos la ventana para hacerlo. 00:16:50.120 --> 00:16:57.170 Entonces, el ZDM te brinda un parámetro donde el DBA le puede indicar, 00:16:58.260 --> 00:17:05.370 bueno, mira, avanza todo lo que tengas que avanzar hasta el punto 00:17:05.370 --> 00:17:06.981 previo a hacer el switchover. 00:17:08.410 --> 00:17:15.590 Entonces, El ZDM realiza todos sus pasos, te crea la tagar, te lo deja sincronizado 00:17:15.590 --> 00:17:24.440 y frena. Entonces, eso puede estar días, semanas, hasta que vos conseguís 00:17:24.440 --> 00:17:29.680 la ventana de corte, supongamos un domingo a la madrugada. 00:17:29.900 --> 00:17:36.000 Entonces, te conectás en ese momento y en ese momento le decís al ZDM, mira, continúa. 00:17:36.000 --> 00:17:42.700 Sí, se le ejecuta el comando y el ZM en ese momento realiza el switchover y todos los 00:17:42.700 --> 00:17:44.089 pasos que le faltan, ¿no? 00:17:45.100 --> 00:17:46.860 Aplicar el redo pendiente, ¿no? 00:17:47.700 --> 00:17:53.880 Claro o lo mantiene como un data guard caliente que va propagando a la nube a medida 00:17:53.880 --> 00:17:57.720 que va avanzando. No, lo mantiene como un data guard caliente, sí. 00:17:57.780 --> 00:18:01.360 Vos constantemente tenés tu base de destino sincronizada. 00:18:01.360 --> 00:18:06.960 Sí, sí, sí y es más, Javier, esto es algo que probamos en mi trabajo. 00:18:07.360 --> 00:18:14.660 Si vos tenés, suponete, una base, no sé, 19 .3 en 00:18:15.080 --> 00:18:22.700 tu lugar on -premise, y migrás a la nube que tiene, no sé, 19 .15. 00:18:22.700 --> 00:18:29.460 15 bueno, este producto automáticamente cuando termina de hacer el switchover y termina 00:18:29.460 --> 00:18:33.800 de hacer sus tareas, una de las tareas posteriores es que te ejecuta el data patch. 00:18:33.840 --> 00:18:37.120 Entonces te la lleva a la versión que tiene el destino. 00:18:37.340 --> 00:18:44.780 Todo automático es muy bueno y es más cuando vos ejecutas 00:18:44.780 --> 00:18:51.440 el comando del ZM bueno, como dijimos tiene muchos pasos que realiza, si falla en un 00:18:51.440 --> 00:18:58.480 paso Te permite a vos Solucionarlo porque bueno, te 00:18:58.480 --> 00:19:02.640 va dejando un log de todo lo que va haciendo, vos podés encontrar la falla, solucionarlo 00:19:02.680 --> 00:19:09.780 y decirle que reanude del paso que estaba no es que empieza todo de cero de 00:19:09.910 --> 00:19:13.810 nuevo, eso es otra linda ventaja es 00:19:15.180 --> 00:19:20.780 Que claro aquí tenemos que mirar también el tema de la appliance y de los volúmenes que 00:19:20.780 --> 00:19:24.720 estamos moviendo porque muchas veces subir a la nube cuando estamos hablando a lo mejor 00:19:24.760 --> 00:19:32.520 nada sea datos que son 10 teras dejar que vaya subiendo todo esto con el ZDM por internet 00:19:32.520 --> 00:19:39.000 que suba y que propague estamos hablando de unos tiempos considerables 00:19:40.940 --> 00:19:46.060 Si en uno de estos pasos falla y tienes que volver a empezar de nuevo dices, madre mía, 00:19:46.060 --> 00:19:51.640 espera esta migración se va a derribar por lo menos la parte de copia, de propagación 00:19:51.640 --> 00:19:53.584 que pueda continuar a partir de ahí 00:19:55.180 --> 00:19:56.840 Exacto pero pinta muy bien 00:19:58.440 --> 00:20:04.900 La verdad que a nosotros nos gustó mucho el producto porque 00:20:06.200 --> 00:20:10.900 Nos automatiza varias de las tareas que nosotros hacíamos a mano anteriormente 00:20:13.010 --> 00:20:20.010 Este tiene sus cositas en que uno bueno tiene que leer bien la documentación cumplir 00:20:20.010 --> 00:20:26.430 con todo lo que todo lo que requiere pero una vez que eso está configurado que se configura 00:20:26.430 --> 00:20:35.260 una vez sola después uno puede ir migrando las bases a medida que lo necesite y la 00:20:35.260 --> 00:20:42.750 verdad que que funciona bien incluso ayer estaba repasando y actualmente está disponible 00:20:42.750 --> 00:20:49.910 la última versión del z m que las 21 .4 así que le fueron agregando algunas algunas características 00:20:49.910 --> 00:20:56.920 nuevas y demás este pero si la verdad que 00:20:56.920 --> 00:21:04.180 a nosotros nos gustó lo usamos generalmente nosotros usamos la migración física online 00:21:04.180 --> 00:21:09.960 si es decir la que nos crea un data guard y cuando después nosotros le decimos 00:21:11.090 --> 00:21:18.500 hace el switch over y volviendo al tema del valor 0 00:21:18.500 --> 00:21:25.520 downtime lo que nosotros venimos haciendo hace varios 00:21:25.520 --> 00:21:32.930 años en Las cadenas de conexiones si de los blogs y de las aplicaciones 00:21:32.930 --> 00:21:39.810 en vez de que figure la scan, vieron que nosotros en la cadena de conexión en el atributo 00:21:39.810 --> 00:21:47.190 host le ponemos el valor de la scan lo que nosotros empezamos a hacer es crear un 00:21:47.190 --> 00:21:51.850 alias en el DNS. Entonces, ¿qué hacemos? 00:21:52.110 --> 00:21:59.120 Le pedimos a la administración, al administrador de los DNS que cree 00:22:00.240 --> 00:22:02.620 un nombre que apunte a una scan. 00:22:04.030 --> 00:22:10.410 Ese nombre lo ponemos lo ponemos en las cadenas de conexión entonces el día que nosotros 00:22:10.410 --> 00:22:17.430 migramos no necesitamos una persona que se conecte data sur por data sur o 00:22:17.430 --> 00:22:24.450 servidor por servidor a cambiar el valor del 00:22:24.450 --> 00:22:30.400 host de cada cadena de conexión lo que hacemos necesitamos una sola persona que es la 00:22:30.400 --> 00:22:37.820 persona que administra el DNS y le decimos que el nombre, el alias, lo reapunte a 00:22:37.820 --> 00:22:40.820 la nueva scan. ¿Me explico? 00:22:41.080 --> 00:22:48.260 Entonces, con eso nos ahorramos mucho tiempo de corte de las aplicaciones. 00:22:49.590 --> 00:22:56.030 Es un solo cambio que impacta en todos los lados donde tienen ese nombre. 00:22:56.030 --> 00:22:59.740 Hombre. Qué bueno a ver, pero aquí estamos hablando 00:23:01.780 --> 00:23:06.280 De tener, de subir, digamos, hacer el Zero Data Migration solamente de componentes de 00:23:06.320 --> 00:23:09.220 base de datos. Cuando hay que subir, digamos, 00:23:10.140 --> 00:23:15.260 a WebLogic y todo esto, tenemos que hacerlo por otro procedimiento, ¿no? 00:23:16.020 --> 00:23:21.820 Claro, si no este producto, el ZDM, es solo para migrar base de datos, correcto. 00:23:22.880 --> 00:23:24.991 Solo para la capa de la base de datos. 00:23:25.080 --> 00:23:28.820 Yo tengo algunas preguntas aquí, aquí, por ejemplo, ya que vamos al tema de Data Guard 00:23:28.860 --> 00:23:33.804 y GoldenGate, que son las dos partes que a lo mejor como administradores más hemos hecho, 00:23:34.280 --> 00:23:39.140 como dices tú, tediosas, configurándolo todo a mano y todo esto, en esta automatización 00:23:39.140 --> 00:23:44.060 que si no le dices que pare, digamos, te lo migra todo, te lo arranca, te lo levanta 00:23:44.060 --> 00:23:48.200 y te hace switchover, ¿cómo se gestiona el tema de 00:23:49.500 --> 00:23:55.100 Hacer la subida parcial, pero el tema de simular pruebas, ¿no? 00:23:57.160 --> 00:24:01.860 Tú haces, por ejemplo, con el Data Guard haces el Zero Dump Migration, te quedas a punto 00:24:01.900 --> 00:24:05.920 digamos de que has subido toda la infraestructura a la nube y te quedas a punto de hacer 00:24:05.960 --> 00:24:10.160 el switchover y dices, bueno podemos abrir esta infraestructura para que la gente la 00:24:10.200 --> 00:24:16.220 pruebe en la nube con un restore point, para que prueben y tal y después rebobinar y 00:24:16.220 --> 00:24:20.840 volver a sincronizar esa parte la tienes que hacer manual o el Zero Dump Migration te 00:24:20.880 --> 00:24:27.440 permite hacer una Hacer eso de alguna forma, es decir, abrir en prueba o 00:24:29.360 --> 00:24:33.471 Resincronizar, es decir, continuar la sincronización a partir de un punto? 00:24:34.450 --> 00:24:37.250 ¿Cómo las pruebas, para que la gente probara? 00:24:38.090 --> 00:24:44.610 Claro, mira, de lo que yo conozco y en base a mi experiencia, esa parte uno la tiene 00:24:44.610 --> 00:24:51.660 que hacer manual, ¿no? Vos lo podrías hacer todo manual y dejar, lo 00:24:51.660 --> 00:24:58.210 que sí, tenés que dejar siempre el de atacar sincronizado no y después si decirle acepta 00:24:58.210 --> 00:25:06.030 m bueno ahora si continúa y que te haga el switch over no pero si esas partes de para 00:25:06.030 --> 00:25:13.190 probar tendrían que seguir siendo manual al menos no conozco que el producto te brinde 00:25:13.190 --> 00:25:20.170 algo algo así no entiendo que no porque esa parte si si es como muy manual, ¿no? 00:25:20.590 --> 00:25:24.590 Parar el Automatic Recovery, ¿no? 00:25:25.390 --> 00:25:30.150 Claro. Pero vos pensás, a ver, que este producto está diseñado para la migración. 00:25:30.880 --> 00:25:32.769 Para todo el proceso de migración. 00:25:33.770 --> 00:25:35.750 Claro, pero hay que probarlo también, ¿eh? 00:25:35.790 --> 00:25:39.930 Desde inicio a fin, ¿eh? Porque te deja todo, todo prolijo. 00:25:41.150 --> 00:25:46.070 Claro pero hay que probar también, por lo que decías al principio, no solamente la parte 00:25:46.070 --> 00:25:47.681 de ASEATO, sino también parte 00:25:48.350 --> 00:25:49.794 aplicaciones, situaciones, 00:25:50.770 --> 00:25:52.610 Tiempos de respuesta, lo que sea. 00:25:52.710 --> 00:25:58.790 De pronto a lo mejor por el hecho de estar en la nube o algo, pues aparecen problemas 00:25:58.790 --> 00:26:02.730 de bases de datos que de pronto llaman a servicios externos o lo que sea. 00:26:02.770 --> 00:26:07.048 Llamadas estas que tendrán que probar antes de hacer la migración definitiva. 00:26:07.160 --> 00:26:12.140 Pero bueno, al final, aunque lo tengas que hacer a mano, te está quitando pero un montón 00:26:12.140 --> 00:26:19.260 de trabajo. Incluso más javier nosotros a veces hemos usado 00:26:19.260 --> 00:26:26.360 este producto solo para crear un data card digamos nuestro objetivo no era migrar era 00:26:26.360 --> 00:26:31.680 crear un data card entonces le decíamos a z m hace todo hasta el punto de ser switch 00:26:31.680 --> 00:26:38.720 over y una vez que el producto terminaba lo dejábamos nunca hacíamos el switch over 00:26:39.080 --> 00:26:46.320 pero bueno la verdad que está orientado a la migración de punta a punta el 00:26:46.320 --> 00:26:52.700 objetivo es que al final vaya a la nube no vaya a un exadata o te refieres a un cloud 00:26:52.700 --> 00:27:00.130 on -premise un club privado cuando hiciste esto sí mira el destino 00:27:00.130 --> 00:27:07.720 puede ser cualquier servicio base de datos de la nube o el exadata 00:27:07.720 --> 00:27:12.630 creado al customer o incluso un exadata on -premise 00:27:14.190 --> 00:27:19.470 Esos son los destinos Si vos tenés otro destino Directamente el producto no te va a funcionar 00:27:19.470 --> 00:27:22.450 Porque es una de las primeras Validaciones que hace 00:27:24.800 --> 00:27:31.540 Interesante Para la parte a lo mejor De pruebas, si se podría hacer El zero downtime 00:27:31.540 --> 00:27:36.620 directamente Con Solamente con RMAN ¿No? 00:27:37.300 --> 00:27:43.760 Es decir No necesitas a lo mejor una sincronización Total al punto Actual, sino simplemente 00:27:43.760 --> 00:27:51.060 hacer un duplicado con R -Mani que se pruebe, aunque no sea el tiempo reciente es decir, 00:27:51.080 --> 00:27:53.858 a lo mejor se pueden utilizar las cuatro formas de 00:27:55.200 --> 00:28:00.930 Migrar con Datapump o con GoldenGate por ejemplo, en los entornos de desarrollo no necesitamos 00:28:00.930 --> 00:28:05.670 montar GoldenGate y todo esto, es decir se puede parar un entorno de desarrollo y dejar 00:28:05.710 --> 00:28:09.850 que el Datapump propague cuando no es un gran volumen Sí, 00:28:10.910 --> 00:28:17.510 lo único ahí ten en cuenta Javier que Porque si vas a usar el método offline, por ejemplo, 00:28:17.510 --> 00:28:24.570 el físico, vas a necesitar un lugar intermedio que sea visto tanto 00:28:24.570 --> 00:28:30.780 por el origen como por el destino para dejar las piezas de backup. 00:28:32.720 --> 00:28:38.720 Puede ser, no sé, si vas a la nube, puede ser un object storage que vos dejas ahí las 00:28:38.720 --> 00:28:42.900 piezas de backup del origen y el destino las lee desde ahí. 00:28:42.900 --> 00:28:49.240 Sí, era una de las cosas que hablábamos Pero eso es dinero Eso después No puedes dejarlo 00:28:49.240 --> 00:28:56.280 meses y meses Eso, claro Por ejemplo, nosotros que Para hacer 00:28:56.280 --> 00:29:01.980 algunas pruebas de este producto Al principio, migrábamos Desde un Exadata Cloud Customer 00:29:01.980 --> 00:29:07.740 A otro Como eso estaba en nuestro centro de cómputos No nos convenía tener Un object 00:29:07.740 --> 00:29:09.940 storage en la nube Bueno, ¿qué hicimos? 00:29:10.000 --> 00:29:11.920 Preparamos un directorio NFS 00:29:13.700 --> 00:29:20.740 Que era un directorio en el servidor Donde se alojaba ZDM Que era visto por ambos Exadata 00:29:20.740 --> 00:29:28.230 Entonces se guardaban ahí Las piezas de backup, los archivos que hagan falta Y 00:29:28.230 --> 00:29:35.470 se veía Pero yo viendo esto Yo les sugiero que vayan 00:29:35.470 --> 00:29:44.000 por Por el método online Porque se van a ahorrar de tener este lugarcito 00:29:44.000 --> 00:29:51.660 para guardar los archivos ese es un trucazo con el 00:29:52.880 --> 00:29:59.060 Online te ahorras un almacenamiento intermedio considerable, es que si estamos hablando 00:29:59.060 --> 00:30:05.380 de grandes volúmenes que esa era la otra cosa que te quería preguntar en volúmenes el 00:30:05.380 --> 00:30:13.100 tema de la appliance Oracle te proporciona Cuando se 00:30:13.100 --> 00:30:19.740 trata de un determinado volumen de datos, estamos hablando de datos de 10 teras, poner 00:30:19.740 --> 00:30:26.220 el Zero Downtime Migration y dejar que por SSH, digamos, se vaya propagando, se vaya 00:30:26.220 --> 00:30:33.160 migrando toda la infraestructura y estimamos que a lo mejor va a estar tres semanas subiendo 00:30:33.160 --> 00:30:40.630 datos. Digamos como que no es muy estar esperado 00:30:40.630 --> 00:30:45.610 tres semanas que termine de emigrar no entonces que una aclaración ahí javier dime si 00:30:45.610 --> 00:30:51.990 cuando vos haces la migración física la conexión no es por ssh si tanto el origen como 00:30:51.990 --> 00:30:59.090 el destino se conectan por sql net sí y ahí mediante esa línea de 00:30:59.090 --> 00:31:03.770 de comunicación se va creando el data guard a bueno vale pero si seguimos viendo por 00:31:03.770 --> 00:31:09.210 claro si seguimos viendo por internet pero si diciendo así si es que vos cuando vas a 00:31:09.210 --> 00:31:16.110 la nube tenés que tener digamos una buena conexión ahí sí creo que existen algo así como 00:31:16.110 --> 00:31:22.890 unas vpn es privadas que te brindan un buen ancho de banda dependiendo del país donde 00:31:22.890 --> 00:31:29.270 estés no pero si tiene que tener tener una buena conexión, porque eso, si tenéis que 00:31:29.270 --> 00:31:34.530 migrar base de 20 teras, 30 teras, te va a llevar sus horas o sus días. 00:31:34.710 --> 00:31:40.570 Sí, sí, sí claro, pero estaba buscando el documento, lo habíamos comentado esto con uno 00:31:40.570 --> 00:31:46.190 de los alumnos, a partir de un determinado volumen, cuando Oracle te dice, si tú prevés 00:31:46.190 --> 00:31:51.970 que vas a estar más de dos semanas subiendo por la red, digamos, toda la infraestructura 00:31:51.970 --> 00:31:57.410 o en esa migración te va a llevar muchísimo más tiempo oracle te da la playa que voy 00:31:57.410 --> 00:32:03.250 a buscar el documento sabes para que es la máquina que te dan la máquina para que tú 00:32:03.250 --> 00:32:10.410 la enchufes directamente de cero downtime La tengas en local se te propaga todo en desde 00:32:10.410 --> 00:32:17.730 tu propia red in situ y digamos que los los portes de mensajería hasta la región de 00:32:17.730 --> 00:32:24.910 cloud de esa máquina de esa playa van incluidos O sea, no tiene coste y es gratis. 00:32:26.290 --> 00:32:32.650 Para que traslades todo a su nube y a su infraestructura, te pone todas las facilidades 00:32:32.650 --> 00:32:37.150 y no te cobra nada. Cuando estamos hablando ya de ciertos volúmenes, decir, hombre, si 00:32:37.190 --> 00:32:42.150 me vas a traer 10 teras aquí y vamos a pagar cloud por 10 teras, pues hombre, claro que 00:32:42.150 --> 00:32:47.520 sí, te lo facilito. No te vas a tener que subir por internet toda la máquina. 00:32:47.520 --> 00:32:49.798 ¿Has llegado a utilizar la Playance esta? 00:32:50.000 --> 00:32:56.560 ¿Has llegado a manejar un volumen como para que te saliera a cuenta utilizar esta Playance? 00:32:57.480 --> 00:33:00.580 No, no, eso ahí no tengo experiencia. 00:33:01.950 --> 00:33:06.390 Pues no sé, es interesante porque lo estuve mirando, estoy mirando, estoy buscando el 00:33:06.430 --> 00:33:09.050 documento, a ver si lo encuentro. 00:33:09.110 --> 00:33:14.710 Además, mira, David, que está la audiencia, si lo tienes a mano y nos lo compartes, pues 00:33:14.710 --> 00:33:17.770 mejor, porque ya no lo encuentro. 00:33:17.970 --> 00:33:25.490 Pues es interesante por eso, porque digamos que te facilita las cosas 00:33:25.490 --> 00:33:32.670 en el sentido de que ya se encarga Oracle de enchufar esa appliance en la región 00:33:32.670 --> 00:33:39.810 OCI, que sea, y a partir de ahí ya te continúa la parte 00:33:39.810 --> 00:33:45.870 de la migración ahorrándote mucho tiempo. 00:33:45.870 --> 00:33:53.390 De hecho, es algo así como, vamos a tardar menos si te mando una máquina, la 00:33:53.390 --> 00:34:00.710 usas, la llenas en tu sitio y la mandamos por mensajero que no si la mandamos 00:34:00.710 --> 00:34:05.270 por internet. Mira vos, no, no, eso no lo conocía. 00:34:05.270 --> 00:34:12.460 Pues Es muy interesante luego lo buscaré y si te parece lo compartimos 00:34:12.460 --> 00:34:19.540 en la... En el canal en el canal, sí, porque además este tipo de cosas son 00:34:19.640 --> 00:34:26.580 interesantes una de las cosas que aparecía en la certificación de OCI te habla mucho 00:34:26.580 --> 00:34:33.140 de eso muy enfocado a que no sea un problema venirte a la nube si estamos hablando de 00:34:33.140 --> 00:34:39.600 grandes volúmenes, por tamaño no va a ser incluso fíjate Javier ahora que desarrollas 00:34:39.600 --> 00:34:47.240 este producto digamos como para facilitarte que vayas a la nube claro justamente 00:34:47.240 --> 00:34:53.800 para mi es por eso la restricción de que no podés usarlo para cualquier destino se 00:34:55.110 --> 00:34:56.990 Llama data transfer appliance 00:34:59.170 --> 00:35:06.340 Yo Voy a dejar después en el canal podemos dejar los links a este 00:35:06.340 --> 00:35:13.360 producto porque Así que ahí tiene unos gráficos muy, muy buenos donde muestra 00:35:13.360 --> 00:35:19.520 de forma gráfica los diferentes tipos de migraciones y qué componentes usa y demás. 00:35:19.800 --> 00:35:25.750 Se ve como más claro por ahí que si uno lo explica verbalmente. 00:35:26.570 --> 00:35:29.210 Exacto pues mira, vamos a ponerlo en el grupo. 00:35:29.350 --> 00:35:30.970 Vamos a ir poniendo estas cosas. 00:35:31.010 --> 00:35:39.170 Yo pongo en el canal, voy a poner la documentación al Data 00:35:39.170 --> 00:35:44.070 Transfer, ¿vale? A este Data Transfer Appliance, ¿vale? 00:35:44.070 --> 00:35:49.710 Explica un poquito cómo va y voy a voy a leer vale dice hombre claro si tienes que mover 00:35:49.710 --> 00:35:56.990 petabytes vale de un data center a cloud pues hombre dice moverlo 00:35:56.990 --> 00:36:04.350 por la internet pública no es no es factible por los costes de red porque la conectividad 00:36:04.350 --> 00:36:11.550 pues del todo fiable internet puede tener cortes y tal y long transfer times vale cuando 00:36:11.550 --> 00:36:16.390 deberías utilizar la data plans te te dice, ¿puedes utilizar Data Transfer para subir 00:36:17.410 --> 00:36:22.150 cientos de trabajos? Yo creo que a partir de 10, 15, 20 ya puede ser 00:36:24.570 --> 00:36:29.690 Conveniente dice, nuestra recomendación es que consideres utilizar Data Transfer si subes 00:36:29.690 --> 00:36:31.710 a través de un internet público 00:36:32.730 --> 00:36:36.690 una subida de datos que te va a llevar más, ¿no? 00:36:36.730 --> 00:36:41.610 De una o dos semanas ah, claro, son subidas muy, muy... 00:36:41.610 --> 00:36:48.130 Claro, son subidas pero fíjate, he pasado la documentación de las Frequently Asked Questions 00:36:48.130 --> 00:36:55.290 de las FAQ porque bueno está muy bien aparte que no tiene coste te dice los 00:36:55.290 --> 00:37:02.670 requisitos Que estás subiendo a la nube te explica un poco cómo funciona 00:37:03.790 --> 00:37:11.410 está muy interesante muy interesante y no sé si llega a costes cuánto cuesta y 00:37:11.410 --> 00:37:18.670 te dice, mira Mira, los usuarios de OCI pueden utilizar el Data Transfer Appliance for 00:37:18.670 --> 00:37:23.390 free. Ah, muy bien claro, que comentabas vos, sin costo. 00:37:23.710 --> 00:37:27.210 Claro, pero sin costo es porque te vienes tú a mi casa, ¿me entiendes? 00:37:27.250 --> 00:37:34.430 Claro es, vente, tráete la cena, que vamos a pasar largo 00:37:34.430 --> 00:37:38.770 tiempo. Claro, porque además entiendo que Oracle también aplica este principio, ¿no? 00:37:38.810 --> 00:37:43.830 Cuanto más volumen estés transfiriendo a la nube, más pesado es después llevártelo de 00:37:43.830 --> 00:37:49.490 allí o más implicación tiene el abandonar la nube. 00:37:50.220 --> 00:37:55.000 Pero muy Interesante, muy interesante. 00:37:55.000 --> 00:38:00.460 Los que estáis en la audiencia podéis participar, como bien sabéis, simplemente que levantéis 00:38:00.460 --> 00:38:07.640 la mano, os subimos aquí al escenario y podéis preguntar 00:38:07.640 --> 00:38:13.220 lo que quieras, que dentro de nuestro conocimiento y dentro de nuestra ignorancia haremos 00:38:13.380 --> 00:38:20.410 lo mejor que podamos. Pues oye, cambia mucho la 00:38:20.410 --> 00:38:25.850 escena esto yo he hecho, claro, todas las meditaciones que he hecho cuando ha habido 00:38:25.850 --> 00:38:31.670 un componente de entre comillas de casi cero downtime, porque Oracle siempre ha dicho 00:38:31.670 --> 00:38:38.370 el almos zero siempre ha utilizado el almos el almos zero downtime yo recuerdo eso, es 00:38:38.370 --> 00:38:44.930 decir, las que sí se han podido hacer a nivel el mínimo tiempo tenía que ser mínimo sí 00:38:44.930 --> 00:38:51.480 la hice con GoldenGate si las hacía con GoldenGate teniendo en cuenta que era cortar 00:38:51.480 --> 00:38:57.690 en un sitio y continuar en el otro y cuando era físico por ejemplo, que podías contar 00:38:57.690 --> 00:39:03.830 con misma plataforma Muchas veces cuando hay cambio de plataforma 00:39:05.380 --> 00:39:10.200 De arquitectura en destino, si te tienes que ir a Data Pump a GoldenGate 00:39:11.960 --> 00:39:18.980 Hace algunos años Claro, hace unos años Nosotros tuvimos que emigrar Desde servidores 00:39:18.980 --> 00:39:24.540 A y X Ahora que Linux Y ahí es un cambio de plataforma Y de Endian 00:39:25.820 --> 00:39:32.440 Exactamente Entonces ahí no nos quedó otra A ver, había negocios Que sí nos permitían 00:39:32.440 --> 00:39:39.280 tener No sé, una ventana de corte De una o dos horas Entonces tal vez ahí con hacer Un 00:39:39.280 --> 00:39:46.300 export -import ya era suficiente Pero había negocios que no, que nos decían máximo 10 00:39:46.300 --> 00:39:54.030 minutos de corte. Entonces ahí no nos quedaba otra que hacer el Spore Import junto con 00:39:54.030 --> 00:40:01.060 GoldenGate. Para los que no conocen este método, lo que se hace es, a ver, 00:40:01.080 --> 00:40:02.100 ¿para qué sirve GoldenGate? 00:40:02.140 --> 00:40:08.940 Primero vamos a explicar resumidamente golden gate sirve para replicar transacciones 00:40:08.940 --> 00:40:15.400 desde un origen a un destino si entonces lo que uno hace es activa el golden gate si 00:40:15.400 --> 00:40:21.880 extrae las transacciones de la base origen hace un export de la base origen si todo esto 00:40:21.880 --> 00:40:28.210 en línea sin parar nada se prepara la base destino se hace el importe la base destino 00:40:28.210 --> 00:40:35.350 y con el golden gate se crea un un replicador que empieza a replicar todas las transacciones 00:40:36.030 --> 00:40:42.610 que fue Extrayendo del origen entonces así, uno tiene la base de destino 00:40:43.630 --> 00:40:46.250 como si fuera un espejo de la base de origen. 00:40:46.350 --> 00:40:52.950 En definitiva, es lo que hace Horace en la Tagar, digamos, pero, en este caso, con distintas 00:40:52.950 --> 00:40:54.839 arquitecturas y distintos endings. 00:40:55.450 --> 00:41:00.690 Y de aquí, bueno, sí iba a añadir, digamos, la diferencia de una cosa idea otra es que 00:41:00.690 --> 00:41:05.210 en golden game por ejemplo no tienes por qué por qué subirlo a lo mejor todo puedes subir 00:41:05.250 --> 00:41:12.670 a lo mejor un esquema o dos esquemas claro incluso hacer una transformación 00:41:12.670 --> 00:41:18.730 incluso puedes hacer incluso alguna transformación en destino o omitir algunas tablas 00:41:18.730 --> 00:41:22.810 o en destino puedes tener otras tablas distinto sea puedes tener otros esquemas distintos 00:41:22.850 --> 00:41:26.770 puedes estar moviendo solamente una aplicación dentro de una base de datos más grande 00:41:26.810 --> 00:41:30.770 a nivel físico con Data Guard te estás llevando toda la infraestructura de base de datos 00:41:30.810 --> 00:41:36.450 digamos todo el servidor de base de datos cuando a lo mejor únicamente necesitas mover 00:41:36.450 --> 00:41:42.630 una aplicación que son dos o tres esquemas a nivel consistente tenés esa consistencia 00:41:42.630 --> 00:41:49.690 a nivel lógico es más práctico siempre lo lógico es como que te da más flexibilidad para 00:41:49.690 --> 00:41:56.970 que vos puedas hacer distintas tareas lo físico es tal cual está la base se mira todo 00:41:56.970 --> 00:42:03.900 tal cual entonces bueno con este método no le permite hacer estas migraciones con diferente 00:42:03.900 --> 00:42:11.200 Arquitectura india ni demás este sí hay veces que no 00:42:11.200 --> 00:42:18.880 te queda otra opción que hacerlo lógico que para mí es más mucho más trabajoso pero 00:42:18.880 --> 00:42:25.480 bueno cuando te toca con escenario así no no tenés otra alternativa ahora si podés usar 00:42:25.480 --> 00:42:32.320 siempre que puedas usar la migración física sólo lo recomiendo porque es es menos trabajosa 00:42:32.320 --> 00:42:39.580 no y después en el corte haces un switch over que te dura 12 minutos y ya tenés tu 00:42:39.580 --> 00:42:46.700 base que era standby ahora productiva muy muy rápido y 00:42:47.400 --> 00:42:53.440 muy seguro, ¿no? También claro, a nivel lógico, otra ventaja que tiene es que puedes 00:42:53.440 --> 00:42:58.160 utilizarlo para cambiar de versión, no solamente de arquitectura, de pasar de Aix a Linux, 00:42:58.200 --> 00:43:05.280 no puedes cambiar, puedes hacer una subida de versión, puedes subir de 12 a 19, en 00:43:05.280 --> 00:43:09.080 vez de subir el destino a 19 y pues puedes simplemente 00:43:09.990 --> 00:43:16.190 el origen es 19 pero propagas las transacciones, todos los cambios a un destino si el 00:43:16.190 --> 00:43:22.990 origen es 12 a un destino que sea 19 y en ese corte, en esa conmutación del origen al 00:43:22.990 --> 00:43:24.934 destino ya el destino ya está en 19 00:43:25.460 --> 00:43:30.620 Claro, ahí harías una migración con Upgrade en un solo paso Exacto, exacto 00:43:31.760 --> 00:43:35.000 Migración con Upgrade, a lo mejor cambio plataforma, cuando tienes que hacer muchas cosas 00:43:35.040 --> 00:43:41.520 de estas juntas, pues a veces te echas más a cuenta hacerlo a nivel lógico y te ahorras 00:43:41.520 --> 00:43:48.260 y te ahorras mucho Y una pregunta, ¿cómo va el tema de migrar a Multitenant? 00:43:49.300 --> 00:43:54.940 Porque el origen en la documentación para utilizar 0Data Migration es que el origen debe 00:43:54.940 --> 00:44:02.860 ser por lo menos 11. Y el paso de 12s 00:44:02.860 --> 00:44:10.420 que estén en OCDB, no multitenan, o 11s que aún es la arquitectura anterior, ¿cómo 00:44:10.420 --> 00:44:18.000 se ve esto? Mira, yo supongo, Javier, la verdad que nunca, hasta 00:44:18.000 --> 00:44:23.860 el momento nunca me tocó hacer una miración así con ZDM, pero yo supongo que ahí estarías 00:44:23.860 --> 00:44:27.120 limitado a usar el método lógico. 00:44:27.620 --> 00:44:33.490 Lógico, claro. Sí, sí, yo supongo que sería de esa manera. 00:44:35.260 --> 00:44:37.880 Claro, volvemos un poco a lo que estamos hablando antes. 00:44:37.920 --> 00:44:40.880 Si tienes que hacer cambio de, 00:44:42.060 --> 00:44:48.630 por llamarlo, de escenario, de on -premise a nube, a lo mejor estás pasando de un origen 00:44:48.630 --> 00:44:55.670 Aix o a Linux, ahora Linux, y estás cambiando a lo mejor incluso de Endian, 00:44:55.750 --> 00:45:01.430 y estás cambiando de versión, y estás cambiando, pues quizá en esos sentidos, pues la 00:45:01.490 --> 00:45:09.770 migración lógica, el zero downtime migración en el modo online lógico y golden gate exacto 00:45:09.770 --> 00:45:16.790 y mira no se me ocurrió para compartir un tip supongamos que vos sos un dba 00:45:16.790 --> 00:45:23.220 que trabaja en una empresa que no tiene el licenciado golden gate no entonces tendrías 00:45:23.220 --> 00:45:27.800 que no sé pasar de 11 a 19 en la nube entonces 00:45:29.040 --> 00:45:35.660 Single and gay bueno no podrías hacer una migración online con poco corte de servicio. 00:45:36.220 --> 00:45:43.610 Pero si usas ZDM, donde te viene incluido GoldenGate por un tiempo, 00:45:43.670 --> 00:45:47.750 por unos meses, sin costo, ahí se te abre otra oportunidad. 00:45:47.950 --> 00:45:55.100 Lo podrías hacer. Cuidado 00:45:55.100 --> 00:45:57.200 ahí, a tenerlo en cuenta. 00:45:57.420 --> 00:46:02.270 Porque Porque de repente una migración que hoy vos no podés hacer porque tu empresa no 00:46:02.270 --> 00:46:03.881 tiene licenciado GoldenGate, 00:46:05.210 --> 00:46:09.990 Si empezás a investigar ZDM, se te abre la posibilidad de sí hacerlo. 00:46:13.000 --> 00:46:16.140 Pero el destino debe ser nube. 00:46:16.440 --> 00:46:18.180 El destino siempre tiene que ser nube. 00:46:18.220 --> 00:46:20.720 Sí, sí, sí exactamente o Exadata on -premise. 00:46:20.820 --> 00:46:24.550 O Cloud at Customer sí, Eso sí. 00:46:25.850 --> 00:46:32.760 Correcto es que GoldenGate es un producto que empezó siendo muy asequible, porque de 00:46:32.760 --> 00:46:35.060 hecho lo compraron para... 00:46:35.060 --> 00:46:39.440 En realidad GoldenGate no fue desarrollado originalmente por Oracle. 00:46:40.620 --> 00:46:47.240 GoldenGate se compró porque Oracle tenía el ODI, el Oracle Data Integration, y dijo, 00:46:47.400 --> 00:46:52.240 bueno, pues a ver, ¿cuáles de los productos de la competencia puedo comprar para comprar 00:46:52.280 --> 00:46:55.560 cuota de mercado y para dejar morir esos productos? 00:46:56.360 --> 00:47:00.720 Y compró GoldenGate, que era un middleware, que no solo era para Oracle, porque la ventaja 00:47:00.760 --> 00:47:03.220 de GoldenGate no es solamente... 00:47:03.220 --> 00:47:09.040 Fíjate, hablando de cosas para los que sí podría utilizar ese GoldenGate licenciado, 00:47:09.380 --> 00:47:14.120 podrías utilizarlo para mover una de las datos Oracle a un destino que no sea Oracle, 00:47:15.220 --> 00:47:20.740 porque GoldenGate es un middleware que, como funciona a extraer las transacciones en 00:47:20.740 --> 00:47:27.230 origen al nivel de SQL, Lo que ha cambiado el SQL, esos inserts, subdates, deletes, son 00:47:27.230 --> 00:47:32.910 de las tablas. Y con la finalidad de poder propagarlo a otro entorno, como middleware, 00:47:33.030 --> 00:47:36.308 sirve también como integrador entre diferentes plataformas. 00:47:36.710 --> 00:47:42.630 Y está contando la historia de los de GoldenGate porque el equipo de GoldenGate digamos 00:47:42.630 --> 00:47:49.370 que se dejó comprar por Oracle Oracle lo compró, pero una vez ya comprados, pelearon 00:47:49.370 --> 00:47:52.926 mucho para decir oye, oye, perdona, pero es que nuestro producto 00:47:53.670 --> 00:47:58.090 Sigue siendo, o sea, muy interesante para vosotros, para todo el tema de integración 00:47:58.130 --> 00:48:03.610 para ser un componente válido de OCI, entonces lo metieron como parte, del ODI, perdona 00:48:03.610 --> 00:48:08.730 Entonces lo metieron como parte del Oracle Data Integrator y mucha gente lo usó. 00:48:08.870 --> 00:48:14.970 Y al principio la licencia GoldenGate no era muy cara, pero ahora es uno de los productos 00:48:14.970 --> 00:48:21.690 estrella porque Oracle, para vender, que digamos, tiene compatibilidad o tiene integración 00:48:21.690 --> 00:48:28.470 con un montón de arquitecturas distintas, de bases de datos, de fabricantes distintos, 00:48:28.870 --> 00:48:32.250 el caballo de batalla que utiliza para poner por delante es GoldenGate. 00:48:32.290 --> 00:48:39.890 Y la verdad que es otro producto maravilloso por la flexibilidad 00:48:39.890 --> 00:48:47.490 que tiene y que podés mover transacciones de distintas marcas de bases de datos sí 00:48:47.490 --> 00:48:53.610 sí la verdad que es muy bueno y te ayuda para también hacer migraciones con bajo corte 00:48:53.610 --> 00:49:01.230 de servicio que cada vez más se se necesitan migraciones con poco 00:49:01.230 --> 00:49:06.090 corte de servicio. Ni hablar cuando tenés base de datos de varios teras, ¿no? 00:49:06.800 --> 00:49:11.280 Claro, claro, claro pero va a tener mucho recorrido GoldenGate. 00:49:11.680 --> 00:49:17.840 GoldenGate cada vez, en cada versión, integran más los módulos nativos de GoldenGate, 00:49:18.000 --> 00:49:20.920 los procesos de extracción... 00:49:20.920 --> 00:49:27.960 Porque antes GoldenGate era un software, era un software externo al Oracle 00:49:28.020 --> 00:49:32.540 Home, a los escenarios. Tú instalabas GoldenGate en el Directorio que tú querías y ahí 00:49:32.580 --> 00:49:39.020 estaba, era una aplicación que se conectaba como cliente a la base de datos y hacía extracción. 00:49:39.720 --> 00:49:46.900 Con los extractores ya internos en la base de datos, toda esa generación de 00:49:46.900 --> 00:49:50.280 las transacciones que están sucediendo en la base de datos se están haciendo internas. 00:49:50.320 --> 00:49:56.280 Entonces Oracle está dando mucha salida a integrar cada vez GoldenGate muchísimo más 00:49:56.280 --> 00:50:02.900 en el núcleo no como un componente externo sino un componente nativo tal cual, ese cambio 00:50:02.900 --> 00:50:05.678 que vos decís me parece que es el cambio de cuando 00:50:07.030 --> 00:50:12.770 Pasaron los componentes tanto el extractor como el replicador a ser de clásicos a integrados 00:50:12.770 --> 00:50:19.830 sí, el integrado, exacto y toda la paquetería y los parámetros de GoldenGate 00:50:19.830 --> 00:50:25.190 de habilitar el GoldenGate a nivel de base de datos y todo sí, sí, sí, sí, ahí es cuando 00:50:25.810 --> 00:50:27.866 dijeron, bueno, vale, venga, va, pues 00:50:28.690 --> 00:50:33.700 Lo incorporamos lo incorporamos al núcleo, y si algo entra en el núcleo es muy difícil 00:50:33.700 --> 00:50:39.360 que se vaya como producto y suele ser más eficiente también 00:50:40.640 --> 00:50:46.920 Sí, porque además, claro, todo el soporte lo cuida mucho más, forma parte del motor así 00:50:46.920 --> 00:50:53.660 como, a lo mejor, en Data Guard digamos, pocos cambios más hay en el En el Data Guard tal 00:50:53.660 --> 00:51:01.040 cual, el Data Guard de 12, de 19, poco cambio hay ahí en esa sincronización, 00:51:01.220 --> 00:51:08.740 en ese stand -by activo. Pocas cosas hay no hay cambios estructurales 00:51:08.740 --> 00:51:16.080 en algo que ya lleva funcionando desde 12, ya ha funcionado muy 00:51:16.150 --> 00:51:23.230 de motor, muy de núcleo. Sí, tiene pinta, tiene pinta, 00:51:23.310 --> 00:51:28.750 que sigue, que sigue. Pues muy bien, tú tienes alguna, ahora ya hablando curiosidades, 00:51:28.910 --> 00:51:33.030 ¿tienes alguna migración de estas así en vista? 00:51:33.370 --> 00:51:37.490 ¿Tienes algunas en agenda para subir dentro de poco? 00:51:38.220 --> 00:51:42.540 ¿Para subir a la nube dentro de poco? 00:51:42.620 --> 00:51:49.140 No, pero sí hemos hecho años anteriores. 00:51:50.410 --> 00:51:58.950 Ahora tenemos que hacer algunas migraciones, pero para sacar algunas bases de un 00:51:58.950 --> 00:52:00.430 exadata viejo que tenemos. 00:52:00.430 --> 00:52:07.610 Este así que bueno ahí vamos a tener un año entretenido 00:52:07.610 --> 00:52:15.110 porque son bastantes son bastante base y pero en cuanto ya tengamos 00:52:15.110 --> 00:52:19.510 para hacer alguna migración a este tipo de destinos 00:52:21.190 --> 00:52:24.070 Nosotros en mi equipo de trabajo 00:52:25.250 --> 00:52:29.390 ni lo dudamos ya usamos el ZDM 00:52:31.340 --> 00:52:38.980 Porque la verdad que cuando te das cuenta el tiempo y el esfuerzo que te ahorra es 00:52:38.980 --> 00:52:42.960 cuando decís, bueno, esto vale la pena valió la pena aprenderlo 00:52:45.050 --> 00:52:46.606 Bueno y tanto, además es que 00:52:47.630 --> 00:52:52.970 es decir, a eso también se le va a dar mucha continuidad a todas las migraciones a la 00:52:52.970 --> 00:53:00.150 nube es que muchas empresas están planteando también es a nivel de costes y todo pero 00:53:00.150 --> 00:53:07.360 también hay otras que se están resistiendo a ya 00:53:07.360 --> 00:53:14.010 subiremos más adelante bueno para Para esas empresas que están resistiendo, yo lo que 00:53:14.010 --> 00:53:21.440 les sugiero, Vean y tengan en cuenta 00:53:21.440 --> 00:53:24.600 los servicios Cloud Acustomer, ¿no? 00:53:24.620 --> 00:53:26.940 Por ejemplo, el Exadata Cloud Acustomer. 00:53:27.040 --> 00:53:31.800 ¿Por qué? Porque los datos quedan en tu centro de cómputos, ¿sí? 00:53:31.860 --> 00:53:34.916 Porque el hardware te lo traen a tu centro de cómputos. 00:53:35.590 --> 00:53:40.380 Y se administra desde la nube, desde OSI, ¿sí? 00:53:40.380 --> 00:53:48.540 Por ejemplo, nosotros aplicamos parches a los VM Cluster, a las bases, todo desde OSI, 00:53:48.560 --> 00:53:54.480 desde la web de la nube. Porque sí, yo soy consciente que hay muchas empresas que no 00:53:54.480 --> 00:53:58.960 pueden sacar los datos de su centro de cómputos o de su país. 00:53:59.900 --> 00:54:04.100 Porque hay leyes internas que no lo permiten. 00:54:04.100 --> 00:54:07.700 Entonces si están en ese caso pueden 00:54:09.020 --> 00:54:16.560 Tener en cuenta esa opción que es muy buena es muy buena, después bueno es otro 00:54:16.560 --> 00:54:24.240 tema analizar los costos y demás pero es una posibilidad la verdad 00:54:26.290 --> 00:54:33.770 Sí como costos a cuánto se va, un cloud privado tiene que ser con exadata con máquinas 00:54:33.770 --> 00:54:41.340 y no sé vamos a analizarlo pues 00:54:41.340 --> 00:54:49.100 muy bien muy bien a ver a mí a mí me parece muy interesante el digamos 00:54:49.100 --> 00:54:56.240 estos los mecanismos de subir a la nube y subirlo con un poco 00:54:56.240 --> 00:55:04.080 una forma un poco guiada porque sí que las migraciones entre ya en una misma mismo 00:55:04.080 --> 00:55:10.100 en premios que obligaban a hacerte muchas cosas a muy a mano con cosas que dices por 00:55:10.100 --> 00:55:14.580 ejemplo montar una tagar dices oye por favor mira que debería haber una forma fácil desde 00:55:14.620 --> 00:55:19.980 cloud control de que el data gar se pudiera hacer sin más o menos ningún ningún problema 00:55:19.980 --> 00:55:25.840 y es algo que yo llevo por ejemplo desde el país manager desde la versión 8 y siempre 00:55:25.840 --> 00:55:28.500 Siempre viendo a ver qué se hacía todo. 00:55:29.560 --> 00:55:36.600 Montar un Data Guard, montarlo con Enterprise Manager y todo, es 00:55:36.600 --> 00:55:41.020 difícil. Es difícil que funcionara el despliegue y todo. 00:55:41.500 --> 00:55:47.560 Si para nube han montado un componente que lo sube y lo sube bien, pues genial. 00:55:48.540 --> 00:55:55.080 Sí, o incluso, Javier, cuando uno lo hacía manual, viste que, bueno, es muy artesanal 00:55:55.080 --> 00:55:56.920 y tenés muchos, muchos pasos. 00:55:56.920 --> 00:56:02.960 De repente te olvidaste o te confundiste en un paso y por ahí te fallaba. 00:56:02.960 --> 00:56:10.510 Acá lo bueno de ZDM que te realiza tantos tantos chequeos que es 00:56:10.510 --> 00:56:12.790 muy difícil que después te falle 00:56:14.410 --> 00:56:19.780 Entonces es como que te aseguras que después el switchover te va a salir bien que te 00:56:19.780 --> 00:56:23.391 va a quedar todo prolijo que te va a quedar aplicar el data patch 00:56:25.840 --> 00:56:33.980 La verdad es no solo es lo bueno lo que automatiza sino que realiza 00:56:33.980 --> 00:56:37.280 un montón un montón de chequeos bueno 00:56:38.460 --> 00:56:46.060 qué Bueno qué bueno qué bueno pues no sé vaya repaso lo hemos pegado al producto 00:56:46.060 --> 00:56:53.060 no ya toda la plataforma sí sí sí vamos vamos a dejar los 00:56:53.060 --> 00:56:58.620 links también para que la gente lo pueda lo pueda leer pueda ver estos gráficos que yo 00:56:58.620 --> 00:57:05.740 te te comentaba este y después bueno los invitamos a que a que se animen a 00:57:05.740 --> 00:57:12.970 investigarlo a conocerlo el producto no no es difícil 00:57:12.970 --> 00:57:18.950 de utilizar si recuerden que hay que bajar un instalador instalarlo en un servidor por 00:57:18.950 --> 00:57:26.010 aquel y 17 instalar algunos paquetitos rpm subir el servicio y ya lo lo tienen 00:57:26.010 --> 00:57:31.810 no no es mucho más que eso este después configurar las conexiones sh tanto al origen 00:57:31.810 --> 00:57:39.010 como al destino hay un manual paso a paso este así que 00:57:39.010 --> 00:57:47.500 próxima migración que tengan que tengan que pasar a la nube oa un ex data local 00:57:47.500 --> 00:57:54.720 on -premise que tengan en cuenta tengan en cuenta porque es un Un buen 00:57:54.720 --> 00:58:02.250 producto que le va a facilitar La tarea Es verdad, resuelve mucho Y recuerdo 00:58:02.250 --> 00:58:06.490 En el servidor de Discord hemos abierto un canal Que se llama Zero Downtime Migration 00:58:06.530 --> 00:58:12.830 Donde ahí podemos ir subiendo Subiendo cosas He encontrado un tutorial bastante Bastante 00:58:12.830 --> 00:58:19.880 bajo De, a ver Ah, También Javier Hay 00:58:19.880 --> 00:58:24.580 un video de YouTube Del Product Manager De Ricardo González 00:58:25.760 --> 00:58:31.620 de este producto, así que lo voy a buscar y voy a poner el link ahí también, porque él, 00:58:31.640 --> 00:58:34.480 bueno, él que es el padre del producto 00:58:36.380 --> 00:58:43.910 Lo explica muy bien Ah, que bien Mira, pongo yo aquí un tutorial también, ¿vale? 00:58:44.330 --> 00:58:50.510 Sí, perfecto, lo ponemos en ese en ese canal En ese canal, sí, sí En ese canal de Zero 00:58:50.510 --> 00:58:54.066 Downtime Migration Aquí, a ver, voy a poner tutorial tutorial... 00:58:55.880 --> 00:58:59.790 Y bueno, pues para todos los que estéis escuchando todo esto desde el podcast, y para 00:58:59.830 --> 00:59:01.530 los que estéis ahí, pues ya sabéis. 00:59:01.570 --> 00:59:08.370 Si tenéis cosas a preguntar y todo eso, pues el canal lo podemos mantener activo para 00:59:08.370 --> 00:59:11.730 dudas, preguntas, curiosidades, cositas, así. 00:59:13.730 --> 00:59:21.070 ¿Sí? Pues, oye, Facundo, ha sido un placer esta 00:59:21.070 --> 00:59:23.890 charla. Igualmente, igualmente para mí. 00:59:23.990 --> 00:59:29.250 Está bueno hablar de estos productos que van saliendo que son nuevos 00:59:30.630 --> 00:59:36.550 Porque así entre toda la comunidad nos vamos manteniendo, digamos, actualizados ¿no? 00:59:37.430 --> 00:59:42.710 Claro, y tanto, claro que sí y además es que así sabemos de primera mano siempre que 00:59:44.750 --> 00:59:49.650 Que funciona a partir de alguien que lo ha probado y ya se ha peleado con ello Claro, 00:59:49.650 --> 00:59:53.330 claro Tomándonos un cafecito 00:59:55.710 --> 01:00:02.820 Bueno pues nada dejamos aquí el episodio lo subiré en breve 01:00:02.820 --> 01:00:09.970 y te mando un abrazo fuerte de aquí argentina igualmente javier un 01:00:09.970 --> 01:00:17.810 abrazo para vos bueno y para todos los que nos hayan escuchado y esperemos que les 01:00:17.810 --> 01:00:21.050 sea útil, ¿no? Claro que sí, claro que sí. 01:00:21.110 --> 01:00:26.650 Gracias a todos por escucharnos, así que hasta el próximo, hasta el próximo episodio.