WEBVTT

00:00:08.300 --> 00:00:10.189
Buenas tardes, Carla, ¿cómo estás?

00:00:10.620 --> 00:00:13.160
¡Hola! ¿Cómo estás? ¿Cómo estás?

00:00:13.500 --> 00:00:14.800
¿Cómo pensaría yo para ti?

00:00:14.840 --> 00:00:17.660
Siempre estoy bien. Yo
siempre feliz y a tope.

00:00:18.260 --> 00:00:19.649
Muy bien, feliz y a tope.

00:00:19.700 --> 00:00:23.720
O sea, sí, yo que hablo contigo
siempre te veo feliz y te veo a tope.

00:00:24.760 --> 00:00:27.680
Sí, también a veces engaño
porque hablo muchísimo.

00:00:29.040 --> 00:00:31.100
La mujer esta, yo no sé qué desayuno.

00:00:31.380 --> 00:00:35.260
Lo del café Database me viene genial
porque entre que soy cafetera y que siempre estoy

00:00:35.300 --> 00:00:38.700
acelerada... Muy bien,
pues ¿sabéis qué pasa?

00:00:38.760 --> 00:00:44.800
Que yo me decía soy simpaticotónico lo
cual significa que a mí yo por ejemplo el café

00:00:44.800 --> 00:00:50.100
me relaja si estoy nervioso tengo que tomar
café porque entonces todo aquello que es

00:00:50.100 --> 00:00:55.820
excitante, relaja ala, tontería
del día bueno, lo recetaban para

00:00:57.320 --> 00:01:03.640
TDAH, bueno hiperactividad hace años,
recuerdo pues mira, he cumplido 40

00:01:06.720 --> 00:01:13.360
De mis 10 que recordaba que sí que
recetaban a los niños por hiperactividad que estoy

00:01:13.360 --> 00:01:18.720
en días un poco barbaridad hasta cierto
punto no lo sé no soy médico no voy a poner a

00:01:18.720 --> 00:01:26.040
no voy a razonar sobre algo que no
conozco pero la medicación eran excitantes

00:01:26.040 --> 00:01:30.200
o sea le decía Pues dale Coca -Cola
o las pastillas Tenían cafeína

00:01:31.700 --> 00:01:34.680
Lo recuerdo, ¿eh? Sí, sí, sí, sí, sí.

00:01:34.680 --> 00:01:36.400
Pues así estamos, así estamos.

00:01:36.820 --> 00:01:38.780
Acelerados, dos acelerados, ¿vale?

00:01:39.320 --> 00:01:44.180
Como decía Ronald Vargas, Ronald Vargas me
decía: Es que tú eres un trimo muy rápido.

00:01:44.180 --> 00:01:49.820
Tienes que, cuando tienes un entrevistado,
a lo mejor, o un invitado que es así, un poco

00:01:49.820 --> 00:01:52.300
más slow, ¿sabes? Es
como un contraste, ¿no?

00:01:52.340 --> 00:01:54.729
Alguien habla tranquilo,
yo, ¡venga, vamos!

00:01:55.280 --> 00:01:58.420
Entonces, Carla, venga, venga, vamos
a meterle caña aquí, la 23 ahí.

00:01:58.460 --> 00:02:00.627
Bueno, voy a poner un poco en contexto.

00:02:00.720 --> 00:02:05.700
Como Carla es de Ace Associates y yo soy
Ace Pro, a nosotros, a los seis, nos dan dentro

00:02:05.700 --> 00:02:08.460
del programa Ace una serie de charlas,
digamos que en principio son...

00:02:08.500 --> 00:02:13.840
Las charlas son confidenciales, nosotros
tenemos PowerPoints y tenemos toda una presentación

00:02:13.840 --> 00:02:18.560
de producto de todo lo que se
viene, pero no podemos compartirlo.

00:02:18.580 --> 00:02:24.020
No podemos compartir ni los vídeos que nos
pasan, son unos vídeos privados, además nos

00:02:24.020 --> 00:02:25.980
dicen que son solamente...

00:02:27.300 --> 00:02:32.060
Información para que nosotros tengamos
conocimiento de lo que se viene de nuevo, si podemos

00:02:32.100 --> 00:02:39.160
hablar, pero no podemos compartir ni
código, ni podemos compartir pantallazos, ni podemos

00:02:39.160 --> 00:02:41.760
compartir esos vídeos,
esas presentaciones.

00:02:41.760 --> 00:02:47.620
¿Qué pasa? Que claro, pues que Carly y yo
llevamos tiempo hablando, decir, oye, ¿y lo

00:02:47.620 --> 00:02:49.509
que se viene nuevo, tú qué opinas?

00:02:49.800 --> 00:02:53.400
Y hemos estado comentando la jugada y hemos
dicho, venga, vamos a tomarnos un café y

00:02:53.440 --> 00:02:59.100
vamos a hablar de lo que se viene
para 23 en RAC y Data Guard.

00:02:59.900 --> 00:03:02.067
¿Qué te parece? ¿Cómo lo ves tú, Carla?

00:03:02.700 --> 00:03:07.840
Sí, era lo que habíamos comentado, que
además la visión, que creo que lo van a entender

00:03:08.260 --> 00:03:13.560
por cómo hablamos o cómo vamos a
desarrollar esta charla, es que es un café entre DBAs.

00:03:14.140 --> 00:03:16.520
Claro, pero siempre es
así, siempre es así.

00:03:16.560 --> 00:03:23.320
Sí, bueno, pero yo creo que para la 23
tiene que ser un poquito más café, porque ya sabemos

00:03:23.320 --> 00:03:25.560
que todavía no la tenemos para probar.

00:03:25.560 --> 00:03:27.380
Iba a soltar el chascarrillo.

00:03:29.160 --> 00:03:34.140
Pero ya te comenté 23, ahí 23 no hay.

00:03:34.140 --> 00:03:41.300
No hay Estamos esperando la 23 on
-premise Y siempre se va alargando

00:03:41.300 --> 00:03:46.380
Digamos como, esto es como Te voy a poner
una comparación un poco estúpida Cuando yo

00:03:46.380 --> 00:03:52.540
hacía natación Cuando yo hacía natación,
era pequeño, como un niño El monitor, el cabrón

00:03:52.540 --> 00:03:57.200
Me decía, tírate y nada Hasta que llegues
al palito Y el tío me iba desplazando el palito

00:03:57.240 --> 00:04:01.480
Y yo iba nadando y el palito cada vez
estaba más lejos Pues eso pasa un poco con la nueva

00:04:01.520 --> 00:04:08.530
23 Ahí Van alargando el
soporte Pero la on -premise No

00:04:08.530 --> 00:04:15.630
llega A ver, yo sinceramente estoy
esperando Ya la 25 directamente Si hay La

00:04:15.630 --> 00:04:19.970
23 ya No tiene mucho
sentido 20D y yo, ¿no?

00:04:20.970 --> 00:04:23.330
Caramba, que estamos con
la certificación de 23.

00:04:23.370 --> 00:04:26.570
Ahí, o sea, si de pronto
le cambian el nombre...

00:04:27.510 --> 00:04:29.121
Bueno, yo me esperaría la 25.

00:04:31.280 --> 00:04:32.840
No, no, no, es broma, es broma.

00:04:32.880 --> 00:04:35.047
Yo supongo que sí que saldrá, espero...

00:04:35.360 --> 00:04:36.920
Bueno, no sé, espero este año.

00:04:36.960 --> 00:04:42.480
La última noticia que tenía era que iba a
ser en junio de este año, que además que salía

00:04:42.480 --> 00:04:44.600
la 23. Era la cuarta, ¿no?

00:04:44.640 --> 00:04:52.060
La 23 .4, ¿no? Y primer semestre y primer
semestre, así que bueno, vamos a ir

00:04:52.060 --> 00:04:57.660
comentando cositas. ¿Qué te parece si las
cosas, porque hemos compartido así unos pantallazos,

00:04:57.740 --> 00:05:03.920
¿qué te parece si vamos ahí haciendo
vistazo de cositas que nos han contado y que nos

00:05:03.920 --> 00:05:07.320
parece? Vale, yo empezaría
por la parte de RAC.

00:05:07.440 --> 00:05:10.120
Sí que voy anticipando venga, anticipa.

00:05:10.380 --> 00:05:17.160
Voy anticipando. ¿No hay
demasiada funcionalidad nueva?

00:05:18.320 --> 00:05:22.760
Pero las que podemos extraer son
interesantes, hay alguna interesante, ¿vale?

00:05:22.840 --> 00:05:28.220
Pero no vamos a venir, yo voy a ser
sincera, no voy a venir aquí a decir que hay 10 distintas.

00:05:28.980 --> 00:05:36.180
Bueno, hay poquillo para escarbar,
pero lo poquillo que hay a mí me parece

00:05:36.180 --> 00:05:38.260
bastante interesante, no te voy a engañar.

00:05:38.300 --> 00:05:40.940
Bueno y necesario, desde
mi punto de vista, ¿eh?

00:05:40.980 --> 00:05:45.600
Bueno y necesario. Sí, desarrollamos si
quieres cuando vayamos pegando un vistazo.

00:05:45.600 --> 00:05:47.860
Pues venga, vamos al lío.

00:05:47.880 --> 00:05:49.491
¿En qué empezamos? ¿Por rack?

00:05:49.620 --> 00:05:52.000
Sí, yo empezaría por rack, casi, sí.

00:05:52.440 --> 00:05:55.700
Muy bien, venga. Te dejo a
ti la primera, venga, dime

00:05:57.600 --> 00:05:59.860
Funcionalidad primera vale,

00:06:00.840 --> 00:06:05.540
me pareció interesante la verdad,
el two -stage rolling patches, ¿no?

00:06:05.600 --> 00:06:11.420
Que al final es cuando tú tienes
un parche que es no -rolling, ¿no?

00:06:11.740 --> 00:06:17.940
Que al final tienes que aplicar en modo no
-rolling te va a permitir que tú puedas dejarlo

00:06:17.940 --> 00:06:19.496
aplicado a nivel de binarios

00:06:20.980 --> 00:06:26.280
Y cuando tengas aplicado en todos, por
ejemplo, un rack en todos los nodos, bueno, por

00:06:26.280 --> 00:06:32.750
ejemplo, no, en un rack en todos los nodos
con un comando SQL, tú lo habilitas, o sea,

00:06:32.750 --> 00:06:36.670
que esa operación no rolling, puedes irla
desarrollando y en el momento que lo tengas,

00:06:36.710 --> 00:06:40.154
pum, va, le dices a la base de
datos, aquí lo tenemos, chicos.

00:06:42.300 --> 00:06:49.440
Esa es muy buena porque si lo que es el
parcheo de la infraestructura del grid

00:06:49.440 --> 00:06:56.440
es delicadito en inglés venga como lo
has dicho en inglés hay es que estoy

00:06:56.440 --> 00:06:59.560
yendo a clases de inglés y Y me
estoy esforzando en pronunciar, ¿eh?

00:06:59.600 --> 00:07:01.380
Ay, yo me pongo nerviosa.

00:07:01.980 --> 00:07:04.360
Two -stage rolling patching.

00:07:05.480 --> 00:07:11.020
Patches. Sí, sería la funcionalidad
es two -stage rolling patching.

00:07:11.080 --> 00:07:17.020
Sería hacer el rolling patching,
pero digamos como en dos fases, ¿no?

00:07:17.120 --> 00:07:19.400
En una primera fase que salís de
estudio y actualizas las rutinas.

00:07:19.440 --> 00:07:22.900
Luego la otra en la que cuando
ya está todo, entonces conmuta.

00:07:23.020 --> 00:07:28.800
Esta hacía falta, ¿no? Que tampoco le
vi nunca sentido y ahí voy a soltar ya.

00:07:28.860 --> 00:07:30.916
Yo creo que es una evolución natural.

00:07:31.060 --> 00:07:37.780
Hoy en día para un entorno de alta
disponibilidad, un no rolling, a mí no me encaja y

00:07:37.780 --> 00:07:41.440
creo que no es donde debería
ir la línea de parcheo.

00:07:42.200 --> 00:07:45.589
Lo aplaudo, lo aplaudo porque
al final no es lo que queremos.

00:07:47.400 --> 00:07:52.820
Pero sí, o sea, me gusta, me gusta y
pienso que es a donde deberían ir todos los parches.

00:07:53.600 --> 00:07:59.640
Sí, a mí me parece es una forma de asentar
el rolling el rolling patching a no quedarte

00:07:59.640 --> 00:08:03.160
con el patching a medias, en las manos

00:08:04.080 --> 00:08:11.340
Sí, es como un parche al no rolling o sea,
un parche del parche vamos a mejorar el

00:08:11.340 --> 00:08:15.800
rolling Sí, pero está muy bien, es decir
vamos haciendo rolling de todo es decir, cuando

00:08:15.840 --> 00:08:20.280
todo entonces está parcheado entonces hacemos
la conmutación con el flip patching al

00:08:20.320 --> 00:08:23.320
management y todo esto Esto
es un poco ahora claro que va.

00:08:23.360 --> 00:08:27.220
Es decir, no parchees
sobre el binario real.

00:08:27.500 --> 00:08:32.080
Lo puedes hacer con un single distance,
con un binario real y si tienes tiempo de parada

00:08:32.120 --> 00:08:35.480
no pasa nada y haces rollback del
parche y no hay ningún problema.

00:08:35.520 --> 00:08:40.780
Pero con rack, esto empieza a ser serio
que tengas dos, tres nodos parcheados, entonces

00:08:40.780 --> 00:08:47.340
el quinto el quinto, el sexto cascan, no
puedes se te queda el rolling a medias

00:08:49.000 --> 00:08:53.540
Uff, yo creo que eso era uno de los
deberes, como dices, tu tarea pendiente.

00:08:55.370 --> 00:08:57.870
Sí, pero necesaria, pero muy bien, ¿no?

00:08:58.410 --> 00:09:02.577
Ah, sí, claro, por supuesto, hay que
aplaudirlas, mejor hay que aplaudirlas

00:09:04.400 --> 00:09:07.200
Vale, pasamos si quieres a
la siguiente ¿Qué te parece?

00:09:07.240 --> 00:09:12.320
Las vamos comentando La gente que
sepáis Podéis participar si queréis

00:09:13.280 --> 00:09:17.620
Si Si alguien quiere subir a comentar con
nosotros Puede pedirnos, pero mientras tanto

00:09:17.660 --> 00:09:22.820
aquí Carla y yo tenemos carrete y un
montón de cosas para Para contar de estas De estas

00:09:22.820 --> 00:09:25.720
charlas que nos presentan
a nosotros ¿Vale?

00:09:25.820 --> 00:09:27.820
Seguimos Esa funcionalidad
me gusta mucho, ¿eh?

00:09:27.860 --> 00:09:31.420
El TwoStage Me gusta, me gusta Mi pH

00:09:33.570 --> 00:09:35.630
Sigue, otra tuya favorita.

00:09:35.630 --> 00:09:39.250
Voy haciendo mientras tanto
capturas de pantalla, vale.

00:09:40.580 --> 00:09:46.900
¿Capturas de pantalla? Yo capturo
pantalla, porque así pues guardo un poco, pues la gente

00:09:46.900 --> 00:09:48.380
que hay y todo. Ah, vale.

00:09:48.380 --> 00:09:53.280
Hay gente que nos escuchará en el podcast,
pero esto lo estamos grabando en directo,

00:09:53.280 --> 00:09:59.440
en el Discord de Café de Atavés, en el
canal de La Cafetería, y estamos con audiencia.

00:09:59.440 --> 00:10:03.800
Es decir, hay personas invitadas
escuchándonos en directo que si pueden levantar la mano

00:10:03.840 --> 00:10:10.640
y quieren participar o escribir en el chat
nos pueden hacer preguntas y unirse a nosotros.

00:10:12.340 --> 00:10:15.260
Así que venga, dispárale, Carla.

00:10:15.260 --> 00:10:18.280
Vale, funcionaría, que
me parece interesante.

00:10:19.380 --> 00:10:23.500
Voy a intentar pronunciar súper bien para
que esté orgulloso en mi profe inglés.

00:10:23.540 --> 00:10:29.540
Venga, Single Server Rolling
Database maintenance, ¿qué tal?

00:10:29.540 --> 00:10:39.340
Vale, aquí lo que
tenemos es todo parchear,

00:10:39.380 --> 00:10:41.080
por ejemplo, realizar
una tarea mantenimiento.

00:10:41.120 --> 00:10:47.760
Tú puedes levantar, ¿no?, una instancia en
paralelo en el mismo servidor que va a dar

00:10:47.760 --> 00:10:52.320
servicio hasta que acabe la tarea
mantenimiento, o sea, vas a tener menos tiempo de corte,

00:10:52.360 --> 00:10:56.920
¿no?, porque que estás dando servicio
y después se hace como un switch, ¿no?

00:10:56.920 --> 00:11:01.380
Me parece bonito, bien pensado.

00:11:01.380 --> 00:11:08.850
Tengo que buscar también, bueno, la
parte útil, ¿no?, que yo al final, a

00:11:08.850 --> 00:11:14.890
ver, lo que tenemos es requisitos, vale,
tienes que tener la licencia de raguán, no,

00:11:14.890 --> 00:11:21.600
no, aquí podemos jugar un poquillo, ¿no?,
con él la la licencia que al final, bueno,

00:11:21.680 --> 00:11:29.030
10 días del failover. Tú, al final,
para licenciar, pues tienes esos 10 días

00:11:29.030 --> 00:11:31.230
que un segundo te cuenta como un día.

00:11:31.430 --> 00:11:37.410
Esto suelo comentarlo bastante porque
hay gente que no acaba, ¿sabes?

00:11:37.630 --> 00:11:39.030
Cuentan que es un día completo, pero no.

00:11:39.070 --> 00:11:40.903
Un segundo te cuenta como un día.

00:11:41.490 --> 00:11:44.546
¡Oh! Yo no lo sabía. ¿Un
segundo te cuenta como un día?

00:11:44.610 --> 00:11:45.870
O sea, a partir del segundo.

00:11:45.910 --> 00:11:48.390
O sea, tú en el momento que lo
empiezas a utilizar, ya es un día.

00:11:48.430 --> 00:11:50.819
¿Lo utilices una hora
o lo utilices las 24?

00:11:51.150 --> 00:11:56.750
No es acumulativo. Hay gente que dice,
bueno, 10 días al final, 24 horas por día de 240

00:11:56.750 --> 00:12:01.090
horas. No. En el momento que levantas ese
mismo día, ya está, te ha contado un día entero.

00:12:01.130 --> 00:12:04.290
Utilices un segundo, 10, 5 o 5 horas.

00:12:05.420 --> 00:12:11.140
¿Vale? ¿Pero qué le encuentro?

00:12:11.300 --> 00:12:16.820
Jolín, recursos. Yo al final, si estoy
levantando una instancia en paralelo, al final

00:12:16.820 --> 00:12:19.264
es como una base de
datos, pero en paralelo,

00:12:19.580 --> 00:12:24.040
Yo, si tengo un consumo de CPU de X, si
tengo un consumo de memoria de X, pues claro,

00:12:24.080 --> 00:12:28.360
en el peor de los escenarios
puedes tener que duplicar, ¿no?

00:12:28.640 --> 00:12:31.740
No llega a duplicar porque estás dando
servicio por la otra, pero bueno, yo poniéndome

00:12:31.780 --> 00:12:34.947
un poquillo lo peor, pasa a
consumir más recursos, ¿vale?

00:12:35.940 --> 00:12:42.300
Contando con la licencia y recursos al final
la infraestructura yo pienso que tiende

00:12:42.300 --> 00:12:48.180
a ir a sobredimensionamiento me parece muy
bien y yo lo apoyo no cada vez es todo un

00:12:48.180 --> 00:12:55.310
poquito más barato digamos y vale es una
de las funcionalidades a mí me parece más

00:12:55.310 --> 00:13:01.050
interesante para un servidor vale sin el
Instance o que tengas una base de datos levantada

00:13:01.050 --> 00:13:07.800
en un servidor esta modalidad la tenemos
para RAC, podemos hacer lo mismo con RAC

00:13:08.720 --> 00:13:15.400
voy a compartir mi visión si me gustaría,
si alguien tiene algo que aportar o le gustaría

00:13:15.400 --> 00:13:22.500
debatir o, bueno, que aporten yo para
RAC no le veo sentido yo al final estoy

00:13:22.500 --> 00:13:25.333
dando servicio, pues
imagínate cuatro o cinco nodos

00:13:25.720 --> 00:13:33.040
¿de qué me sirve? Parchear levantando
una instancia temporal en uno

00:13:33.040 --> 00:13:37.484
de los nodos, cuando tengo otros cuatro,
tres, dos o los que sean dando servicio

00:13:39.020 --> 00:13:41.720
Pero bueno, ahí lo dejo, yo creo que sería

00:13:43.280 --> 00:13:48.520
Tendría que buscar un caso aislado en el
que, no sé, me podría ser de interés, pero ahora

00:13:48.520 --> 00:13:54.200
mismo no lo encuentro quizás con gestión
de recursos, sí claro, yo entiendo

00:13:55.380 --> 00:14:00.980
que a lo que va es. Es más al tema de
rendimiento de recursos, sino al tema de disponibilidad.

00:14:01.120 --> 00:14:06.300
Que tú puedas estar parcheando mientras
ese nodo sigue estando disponible y sigue dando

00:14:06.300 --> 00:14:09.020
servicio, ¿vale? Porque...

00:14:10.120 --> 00:14:13.100
Tú al final vas echando
nodo por nodo, ¿no?

00:14:13.620 --> 00:14:16.580
Entonces, al final dan
servicio el resto de los nodos.

00:14:16.620 --> 00:14:19.540
Tú tienes que jugar con el movimiento
de servicios, pero bueno...

00:14:19.580 --> 00:14:22.360
Sería como un rolling en cada nodo, ¿no?

00:14:22.420 --> 00:14:28.230
O sea, sí. Sí, sí. Yo creo, mira, a veces
pasa, por ejemplo, con los rolling patches,

00:14:28.390 --> 00:14:31.870
por ejemplo, imagínate un rack que, no racks
a lo mejor de 20 nodos, sino racks a lo

00:14:31.910 --> 00:14:39.050
mejor de 3. La carga de un nodo
para repartirla en los otros dos

00:14:39.050 --> 00:14:41.090
es como muy pesada, ¿vale?

00:14:41.130 --> 00:14:47.130
Es decir, se está llevando pues un tercio,
digamos, bueno, la mitad de un servidor se

00:14:47.130 --> 00:14:50.730
la llevan, es decir, es todo un tercio
de la carga repartido entre dos.

00:14:50.770 --> 00:14:52.190
Puede ser muy, muy, muy duro.

00:14:52.230 --> 00:14:59.260
Si tú, por ejemplo, haces ese local
rolling database maintenance, que te hace,

00:14:59.360 --> 00:15:06.600
te levanta la otra instancia en el mismo
nodo, te está dando el servicio, digamos,

00:15:06.620 --> 00:15:13.400
con esa instancia temporal en el nodo
mientras tú haces el mantenimiento Del parqueo.

00:15:13.400 --> 00:15:18.120
Yo pensaba al principio igual, pero
vamos a pensar en un entorno real, ¿no?

00:15:18.320 --> 00:15:25.740
Al final, si tú no puedes soportar
la carga en los dos, tres o nodos

00:15:25.740 --> 00:15:32.170
supervivientes, o sea, los que no estás
parcheando, ¿por qué tienes recursos en el nodo

00:15:32.170 --> 00:15:34.250
que estás parcheando para
levantar una estancia paralela?

00:15:34.290 --> 00:15:36.810
No, porque yo al final voy
a necesitar CPU y memoria.

00:15:36.850 --> 00:15:41.860
Yo al final veo que si no puedes sobrevivir
con los otros nodos es porque tienes una

00:15:41.860 --> 00:15:44.380
congestión de recursos, ¿no?

00:15:44.480 --> 00:15:49.640
Y si la tengo, la tengo para levantar una
instancia paralela en el nodo que estoy parcheando.

00:15:49.680 --> 00:15:51.069
No sé si me explico bien.

00:15:52.180 --> 00:15:57.820
Sí, sí. Claro, no le… De alguna forma
estás diciendo, claro, los otros dos nodos tienes

00:15:57.820 --> 00:16:02.020
que tener suficiente para sostener la carga
de ese tercer nodo a medida que se hace.

00:16:02.060 --> 00:16:05.600
Sí, y además que soy muy partidaria.

00:16:05.880 --> 00:16:13.090
A la hora de dimensionar un rack, los
recursos TPU y memoria, yo soy muy

00:16:13.090 --> 00:16:16.710
partidaria, pues imagínate,
tienes cinco nodos, ¿no?

00:16:17.350 --> 00:16:21.572
Dimensionar siempre pensando que te vas
a quedar con uno que es de servicio.

00:16:22.680 --> 00:16:25.800
O sea, siempre, al final
un rack está para eso, ¿no?

00:16:25.840 --> 00:16:29.280
Yo tengo que dar servicio con los nodos
que quedan supervivientes, vamos a ponerlos en

00:16:29.320 --> 00:16:34.420
el peor escenario, caigan todos menos
uno, por lo menos a nivel de memoria, ¿no?

00:16:34.460 --> 00:16:37.500
Tú tienes que garantizar que puedes
dar servicio siempre con uno.

00:16:37.540 --> 00:16:45.170
Y en este caso, yo te digo, creo que
no lo utilizaré, no le debo mucho

00:16:45.170 --> 00:16:48.470
ahí para rascar, pero si a alguien se le
ocurre un escenario, por favor comentarlo, porque

00:16:48.510 --> 00:16:54.980
me parece interesante. Al final hay que
abrir miras y puede haber casos y casos.

00:16:55.280 --> 00:16:59.480
Vamos, nosotros, creo que estarás conmigo,
no conocemos todos los escenarios del mundo.

00:16:59.520 --> 00:17:03.140
Al final lo aprendes. No,
claro, pero es lo que dices tú.

00:17:03.140 --> 00:17:06.000
Cuando nosotros nos ponemos a ser rigurosos
y estamos diciendo, oye, sí, que tenemos

00:17:06.040 --> 00:17:09.480
un rack de tantos nodos, pero esto
significa que dos se pueden caer.

00:17:09.520 --> 00:17:11.600
Uy, no, no, ya tenemos
las máquinas a tope.

00:17:11.640 --> 00:17:16.840
Bueno, teniendo las máquinas a tope, pues
si se caen, más a tope van a estar, ¿no?

00:17:17.040 --> 00:17:20.720
Claro, sí, tiene que ser
capaz de poder sobrevivir.

00:17:20.720 --> 00:17:24.109
Para mí, siempre hay que pensar
en el peor caso, con un nodo.

00:17:25.740 --> 00:17:27.540
Yo... Pero estoy muy conservadora, ¿eh?

00:17:27.580 --> 00:17:33.460
Yo soy... Hay casos y casos, sí, también a
nivel de licenciamiento, lo que sea, pero

00:17:33.460 --> 00:17:36.760
bueno, si se puede tener
en cuenta y se puede,

00:17:37.760 --> 00:17:41.940
bueno, se lo puede permitir la
compañía que sea, es interesante.

00:17:41.940 --> 00:17:46.920
Si tiene que poder dar servicio con menos
infraestructura de la que hay, porque para

00:17:46.920 --> 00:17:49.160
eso precisamente estamos
hablando de data disponible.

00:17:49.200 --> 00:17:54.380
Sí, es que jugando también con
virtualización, yo me pongo en el caso de, bueno, es el

00:17:54.380 --> 00:17:56.040
que vivo un poco, de KVM.

00:17:57.860 --> 00:18:01.700
De poder llegar a un punto diciendo, mira,
me han caído dos nodos, poder dimensionar

00:18:01.740 --> 00:18:04.200
yo, ¿no? Al final, físico
entre comillas, ¿no?

00:18:04.240 --> 00:18:08.320
Le damos más recursos a la
máquina virtual durante X tiempo.

00:18:08.460 --> 00:18:12.516
Al final te entra un poquillo en
licencia, pero bueno, que es otra pelea.

00:18:13.210 --> 00:18:19.490
¿Pero dónde iba? Esta funcionalidad para
RAC la verdad me parece súper bonita.

00:18:19.510 --> 00:18:25.860
Es interesante. Me cuesta
ver en caja si la encajaría.

00:18:25.860 --> 00:18:28.260
Ya tenemos dos, ya tenemos dos.

00:18:28.260 --> 00:18:32.140
Estamos hablando de New Features en
RAC de 23, ya tenemos dos, ¿vale?

00:18:32.540 --> 00:18:35.580
El Two Stage Rolling Packing.

00:18:36.680 --> 00:18:40.560
Te voy a poner en contacto con mi
profe inglés para que le digas, mira.

00:18:40.600 --> 00:18:43.520
Bueno, sí, sí, sí. Sí, sí, sí.

00:18:45.480 --> 00:18:46.940
Venga, siguiente. ¿Qué vas a hablar?

00:18:46.980 --> 00:18:48.758
¿Del Fast Start Reconfiguration?

00:18:49.440 --> 00:18:52.560
No, tenía apuntado el Smart
Connection Rebalancing.

00:18:53.400 --> 00:18:54.540
Venga, pues hala, tírale.

00:18:54.580 --> 00:18:58.120
Esta me gusta mucho y además en
la compañía en la que trabajo.

00:18:59.060 --> 00:19:06.100
Una base de datos muy transaccional,
que siempre sabemos que tiene sensors

00:19:06.100 --> 00:19:10.489
muy intensivos. Imagínate un rack en el
que te están entrando por varios nodos.

00:19:11.580 --> 00:19:16.440
Lo que hace, pues imagínate, te entra un
índice, nodo 1, otro en el nodo 3, otro en el

00:19:16.440 --> 00:19:21.980
nodo 4, claro, y los bloques tenemos
tráfico entre los nodos para enterarse de qué está

00:19:21.980 --> 00:19:26.647
pasando aquí entre uno y otro, bueno, creo
que es que ya conocemos un poquillo todos

00:19:27.060 --> 00:19:31.880
cómo va, vale, lo que hace esta
funcionalidad, y ya digo, para mí es la estrella, esto

00:19:31.880 --> 00:19:37.020
me gusta mucho, que es Que redirige

00:19:38.360 --> 00:19:44.300
Sesiones que están corriendo cargadas de
trabajo sobre los mismos objetos para que vayan

00:19:44.300 --> 00:19:47.560
a la misma instancia
sin interrupción sabes

00:19:48.740 --> 00:19:55.800
que este es precioso a mí me gusta mucho
sí porque ese es una de las es una de las patas

00:19:55.800 --> 00:20:01.140
cojas siempre del rack de cuando por
interconexas teniendo remastering ahí de bloques

00:20:01.140 --> 00:20:08.400
ahí es exacto esa es bonita está a mí me
gusta mucho yo está para mí sería la estrella

00:20:08.400 --> 00:20:12.680
pero bueno también en mi escenario vale yo
siempre estoy pensando en mi escenario particular

00:20:12.720 --> 00:20:18.640
lo que me puede aplicar y éstas se echaba
de menos hay que ver cómo funciona vale como

00:20:18.640 --> 00:20:25.800
digo creo que tú tampoco no lo hemos
probado no si no porque 23 rack

00:20:25.800 --> 00:20:33.260
claro o como es probado en off y seguramente
bueno esa data bueno en el sistema y

00:20:33.260 --> 00:20:37.420
podría probar si yo en mi
caso no No, yo no tengo.

00:20:37.600 --> 00:20:39.600
Me gustaría probarlo, pero no tengo.

00:20:44.410 --> 00:20:46.710
Vale, creo que nos quedó claro.

00:20:46.750 --> 00:20:50.250
No sé si alguien tiene alguna
duda o algo así para comentar.

00:20:50.290 --> 00:20:52.623
Yo creo que se nos han notado emocionados.

00:20:54.250 --> 00:20:59.170
Este café es un café muy de vea duros.

00:21:00.430 --> 00:21:05.450
Pero ahí estáis. Pero queremos hablar
también en lenguaje humano, como decías tú, dos

00:21:05.450 --> 00:21:08.590
de veas tomándose un café, que
si alguien dice, oye, ¿y esto?

00:21:08.630 --> 00:21:14.180
Pues levantáis la mano, comentamos y
entramos un poco más al detalle, ¿vale?

00:21:14.220 --> 00:21:18.240
Los que estéis escuchando en el podcast,
pues no vais a poder preguntar, pero es lo que

00:21:18.280 --> 00:21:19.780
tiene que estar en directo.

00:21:21.960 --> 00:21:25.300
Bueno, la funcionalidad esa que te decía
yo, de la que te hablaba de hecho, tírale tú

00:21:25.340 --> 00:21:27.680
con la tuya, la del Fast
Start Reconfiguration.

00:21:27.720 --> 00:21:29.740
Ahí está, la siguiente, sí.

00:21:30.890 --> 00:21:33.510
Estoy un poco moscadilla con esto.

00:21:34.440 --> 00:21:36.360
¿Por qué? Tiene buena pinta, ¿eh?

00:21:36.740 --> 00:21:43.880
Sí, tiene buena pinta, pero a nivel técnico,
al final es de recovery is faster, ¿no?

00:21:44.680 --> 00:21:48.040
Sí, sí. Muy guay, pero no tengo detalle.

00:21:48.660 --> 00:21:53.100
¿Arranca a trabajar con bloques limpios
de forma inmediata, digamos, no?

00:21:53.240 --> 00:21:58.940
Faster Start Recuperation permite que el
trabajo que arranque en bloques limpios.

00:21:59.680 --> 00:22:04.240
Sí, aplica a todos. Nos muestra una
gráfica que nos han puesto, nos han puesto una gráfica...

00:22:04.280 --> 00:22:09.160
es que cuando nos ponen gráficas y no nos
ponen las métricas, a mí esto es como...

00:22:09.160 --> 00:22:12.700
yo soy muy de... Por eso estoy
medio moscavilla, ¿sabes?

00:22:12.700 --> 00:22:18.460
Claro, claro. Mira, hay un libro, no tiene
nada que ver con informática, que se llama

00:22:19.640 --> 00:22:25.120
The Visual Display of Quantitative
Information, de Eduard Tafti, que no está traducido

00:22:25.120 --> 00:22:28.820
al español, pero que lo que dice es que
cuando te presentan un gráfico no te presentan

00:22:28.860 --> 00:22:35.940
métricas, te ponen por ejemplo una gráfica
y hay un pico muy grande y el otro pico muy

00:22:35.940 --> 00:22:37.496
rápido, ¿en qué está medido?

00:22:37.560 --> 00:22:40.260
¿Qué medida? Estamos hablando de

00:22:41.320 --> 00:22:48.380
segundos, ¿de qué? SQL execution per
seconds, un gráfico que nos dice, en

00:22:48.380 --> 00:22:54.420
19 ahí hay un tiempo de reconfiguración
cuando hay un instance crash cuando hay una instancia

00:22:54.420 --> 00:23:00.620
que para y arranca y todo un tiempo de
reconfiguración y en la gráfica nos muestran y

00:23:00.620 --> 00:23:05.500
en 23 ahí el tiempo se reduce 6
veces más rápido es decir, tenemos

00:23:07.240 --> 00:23:09.560
Bueno, esto como está medido, ¿vale?

00:23:10.140 --> 00:23:15.380
Efectivamente, sí que dice que 6 veces más
rápido comparado con 19 y el recovery, ¿no?

00:23:15.900 --> 00:23:18.620
3 cuartas partes el tiempo, bueno, sí.

00:23:21.100 --> 00:23:27.820
Hay que verlo en funcionamiento, en
principio es bonito también, pero ya te digo no tenemos

00:23:27.820 --> 00:23:30.542
mucho más detalle y no sé
qué decirte, la verdad.

00:23:30.800 --> 00:23:36.940
Claro, la frase que tenemos nosotros aquí
en la charla que nos dijeron, no nos han explicado

00:23:36.940 --> 00:23:40.380
cómo funciona la funcionalidad
por dentro con las tripas, ¿vale?

00:23:40.420 --> 00:23:42.364
Pero la definición literal nos dice

00:23:43.000 --> 00:23:48.320
digamos Reconfiguración,
arranque rápido, Fast Start, ¿no?

00:23:48.360 --> 00:23:54.760
Lo que te dice en vez de pausar el trabajo
para hacer la reconfiguración y el instance

00:23:54.760 --> 00:24:02.280
recovery en un instance crash lo que hace
es inicia la reconfiguración permitiéndote

00:24:02.280 --> 00:24:04.520
trabajar con bloques
limpios de forma inmediata.

00:24:04.560 --> 00:24:11.570
Es decir, como que de alguna forma hay
como un deal, como estamos no retrasando,

00:24:11.570 --> 00:24:19.570
estamos dando el entorno
antes de que el instant

00:24:19.570 --> 00:24:23.140
recovery complete. ¿Correcto?

00:24:23.180 --> 00:24:27.060
Ahí es donde entramos. Yo me imagino
un entorno muy, muy transaccional.

00:24:27.100 --> 00:24:34.410
Habría que verlo. Sí, hay veces que,
claro, hay veces que, oye, que ahí ya tenemos, ya

00:24:34.410 --> 00:24:42.150
tenemos ganancia, contamos que va a
arrancar bien y todo, pero, vale, es decir, ese Fast

00:24:42.150 --> 00:24:45.490
Instance Recovery, uf, a veces
da un poquito de miedo, ¿eh?

00:24:45.490 --> 00:24:49.268
Cuando decimos, ¿no? Empiezas a
trabajar ya, aunque no haya acabado.

00:24:49.880 --> 00:24:51.860
Sí, pero tienen que tender, ¿no?

00:24:51.900 --> 00:24:57.840
Yo creo que los avances que nos pueden
proporcionar, al final siempre tienes que tender

00:24:57.840 --> 00:25:02.560
a ir más rápido. Me parecía raro cambiar
de una versión a otra en la que me digan, pues

00:25:02.600 --> 00:25:05.322
no, seguimos igual, tendrás
que darme una mejora.

00:25:06.240 --> 00:25:13.040
Bueno, hay que probarlo. Bueno, pero por
lo menos a lo mejor es algo que se puede habilitar

00:25:13.040 --> 00:25:16.720
o deshabilitar, a lo mejor es un modo
que se puede poner o quitar, ¿vale?

00:25:16.760 --> 00:25:18.320
Pienso que por lo que ve.

00:25:18.320 --> 00:25:21.209
Bueno, por lo que habíamos
visto en la presentación.

00:25:21.780 --> 00:25:24.240
Yo pienso que es inherente
ya a la nueva versión.

00:25:24.280 --> 00:25:28.100
Sí, Ya va a estar la
configuración manual, sí.

00:25:28.580 --> 00:25:34.040
Estamos hablando, estamos hablando de
funcionalidades que nos han contado, nos han dado

00:25:34.040 --> 00:25:38.980
una charla, pero no hemos
visto muchas tripas en esto.

00:25:38.980 --> 00:25:45.900
No hemos visto mucho comando, muchas
gráficas de lo bien que va a ir, y nosotros, pues,

00:25:46.500 --> 00:25:50.620
como nos estamos tomando un café,
pues podemos criticar, no, hombre.

00:25:50.620 --> 00:25:55.780
A mí me gustaría, y creo que vamos
por lo mismo, tener algún tipo de dato

00:25:56.720 --> 00:26:02.960
o destripar un poquito el caso que da
al final a la gráfica que nos presentan.

00:26:03.680 --> 00:26:06.240
Pero bueno, en principio, guay.

00:26:06.240 --> 00:26:09.880
Muy bien, seguimos con RAC,
que seguimos aún con RAC.

00:26:09.880 --> 00:26:11.280
Luego tenemos que ir a ver Data Guard.

00:26:11.320 --> 00:26:14.340
Sí, vamos bien de tiempo, ¿no?

00:26:14.660 --> 00:26:22.960
Sí, sí, sí. Yo tengo apuntado,

00:26:23.040 --> 00:26:28.280
a ver si coincidimos, Rackfast
Plugable Database Open.

00:26:29.640 --> 00:26:37.500
También, veremos uno de los casos de dos
veces más rápido, porque puede abrir una

00:26:37.500 --> 00:26:41.080
PDB en paralelo, los nodos, ¿vale?

00:26:41.220 --> 00:26:42.740
Bien, dos veces más rápido.

00:26:42.740 --> 00:26:50.220
bueno Eso es está bien que vayan que se
vayan haciendo en paralelo las pdb si

00:26:50.220 --> 00:26:57.320
si logres en sí Bien pues mira estaba
yo de chulita tienes alguna más

00:26:57.320 --> 00:27:02.820
apuntada de rap porque yo creo déjame
mirar no hemos tocado todas las que tenía apuntadas

00:27:02.820 --> 00:27:07.800
que me parecían más interesantes no tengo
engañar si tienes alguna a mayores es el modelo

00:27:07.800 --> 00:27:15.810
yo me estaba mirando la parte de
ese primary crs de hang lo de el

00:27:15.810 --> 00:27:23.410
clip que el de prime maría y cuando hay un
mal funcionamiento del crs de principal dice

00:27:23.410 --> 00:27:29.650
que dice el local o ahora ahora que es más
de carlos de tec en el normal y ti entonces

00:27:29.650 --> 00:27:36.690
no puede arrancar un cds porque el primario
está está mal funcionando y entonces

00:27:36.690 --> 00:27:41.790
dice la solución digamos, es matar
el el primer ICRSD en el nodo 1, ¿no?

00:27:42.210 --> 00:27:46.010
Entonces lo que dicen
es que hay como es el

00:27:47.310 --> 00:27:49.930
El Transition Storage Failure, ¿no?

00:27:49.950 --> 00:27:53.150
Que hace como un remount del Disk Group y

00:27:55.350 --> 00:27:59.290
¿Te lo tienes claro? Yo lo vi y no me quedó
muy claro, ¿sabes a lo que me refiero?

00:27:59.330 --> 00:28:02.570
Ay, no, la verdad que no tenía apuntado y

00:28:04.160 --> 00:28:07.810
Vale, que es como... Vale,
lo que dije es algo así.

00:28:07.810 --> 00:28:14.670
Sí, como que tenemos el CRSD, el Cluster
Ready Service Diamond, por ejemplo, colgado,

00:28:14.690 --> 00:28:16.634
¿no? Que está funcionando mal, ¿no?

00:28:17.250 --> 00:28:21.730
Entonces, lo que dice es que, claro,
no puedes arrancarlo de nuevo, ¿vale?

00:28:21.750 --> 00:28:28.870
Porque el demonio está colgado,
¿no?, y que lo que hace es, digamos,

00:28:28.970 --> 00:28:36.180
como una relocación de
ese proceso, es decir, lo

00:28:36.180 --> 00:28:43.800
levanta como dos veces, lo levanta
bien y entonces mata, digamos,

00:28:44.000 --> 00:28:52.400
en otro nodo y mata en el nodo
principal el demonio de CRS.

00:28:53.190 --> 00:28:59.200
Digo esto esto ya es técnico técnico, pero
no tenemos ningún comando, tenemos ningún

00:28:59.200 --> 00:29:02.200
comando ni que eso que hace ni ni nada.

00:29:02.200 --> 00:29:04.920
Sí, pero al final estás fastidiado, ¿no?

00:29:04.920 --> 00:29:11.780
Si está fallando en un nodo, vas a tener
muchas veces con el resto de los nodos que le

00:29:11.780 --> 00:29:18.300
van a hacer, pues ha quedado pocho y toca,
digamos, es como ser de inicio, es ese kit

00:29:18.300 --> 00:29:22.940
es como que te permite arrancar
a arrancar lo secundario,

00:29:23.880 --> 00:29:31.680
funcionar y luego Y luego matarlo yo para
mí tienes los nodos supervivientes no, bueno

00:29:32.220 --> 00:29:36.880
le pegaron un vistacillo, la verdad que no
no lo vi, no te voy a engañar esa te la voy

00:29:36.920 --> 00:29:40.976
a preguntar a ti, digo yo ¿estás segura
que Carraquí le va a sacar punta?

00:29:41.180 --> 00:29:46.900
Sí, no lo vi si tengo un problema con un
nodo del clúster, tengo el resto al final depende

00:29:46.900 --> 00:29:52.280
del problema que tenga pero si puedes dar
servicio en el resto de nodos, podemos sobrevivir

00:29:52.280 --> 00:29:57.900
y sin uno y no veo esa necesidad de que al
final o sea, sin tener mucho más detalle porque

00:29:58.820 --> 00:30:05.100
no lo sé Sí, claro, el tema también es
como de ahí depende la instancia SM y todo, si

00:30:05.100 --> 00:30:08.620
tú lo tienes caído, tú sí
necesitas de alguna forma

00:30:09.560 --> 00:30:15.680
arrancar Ah, vale, pero tenemos ahí que es
como flex SM que al final lo tenemos hoy en

00:30:15.680 --> 00:30:22.980
día, ¿no? Te cae una instancia de SM en
este caso y que puede hacer a otra del clúster,

00:30:23.120 --> 00:30:28.060
no lo sé, pues mira me lo voy a apuntar
para mirar esto nos lo tienen que dar un poco

00:30:28.060 --> 00:30:31.320
más más detallado, pero
bueno lo mismo, fíjate

00:30:34.900 --> 00:30:37.700
Fallos, no, malfunction del FlexASM

00:30:38.660 --> 00:30:41.460
supone Digamos, pues eso.

00:30:43.680 --> 00:30:48.860
El restar del listener, pero que digamos
como que todo esto forma parte de un

00:30:49.940 --> 00:30:57.200
de una funcionalidad que se llama el
monitoring y el autocorrect states sabes

00:30:59.290 --> 00:31:06.290
Esto que estoy diciendo del flex de
que se queda pocho el el el ocrs, que

00:31:06.290 --> 00:31:13.410
es que todo esto es como esos procesos de
monitorización de autocorregir, no, que

00:31:13.410 --> 00:31:18.750
te lo vuelve a arrancar o tal, como que,
según dicen, en 23 lo han mejorado lo han mejorado

00:31:18.750 --> 00:31:20.630
de forma que si se te queda el

00:31:22.050 --> 00:31:27.210
Demonio se te queda pocho en primaria te
arranca uno a auxiliar y entonces te mata el

00:31:27.210 --> 00:31:29.350
primario si el flex se queda

00:31:31.190 --> 00:31:38.950
Si tú digamos no puedes arrancar el ASP
te hace como un remontado del disgroup si

00:31:38.950 --> 00:31:44.630
hay un nodo por ejemplo que no tiene la
instancia, te hace como ese intento remontado.

00:31:44.690 --> 00:31:50.470
El listener del ASM que te da problemas
con la funcionalidad del FlexASM, que también,

00:31:50.570 --> 00:31:54.770
que te hace automáticamente como
un restart del listener de ASM.

00:31:55.240 --> 00:32:00.340
A ver, y vuelvo a lo que tú me decías,
Carla, es decir, son cosas que no son en sí una

00:32:00.340 --> 00:32:04.860
new feature, sino es una
mejora de que funciona mejor.

00:32:06.060 --> 00:32:10.100
Todo este paquete de diagnóstico de

00:32:12.820 --> 00:32:18.260
Comprobación del clúster y del demonio y
todo esto que funciona de una forma más robusta,

00:32:18.260 --> 00:32:24.060
detecta cuando se queda mal, se repara,
se arranca, rearranca el flex, no sé

00:32:26.740 --> 00:32:31.020
Sabemos que dice que lo va
a hacer, pero no sabemos.

00:32:32.940 --> 00:32:37.220
No sabemos los detalles, no sabemos
los comandos bueno, los comandos sí,

00:32:38.290 --> 00:32:44.270
pero insisto esto lo dicen como que es
mejora de que funciona mejor no es una new feature

00:32:44.270 --> 00:32:51.290
en sí sino es como un improvement no como
como que yo no estoy encontrando está

00:32:51.290 --> 00:32:56.870
mirando en paralelo porque la verdad no
ese pantalla justo no lo tengo no lo tenía apuntado

00:32:56.870 --> 00:33:02.000
para ver si entendía un poquillo más hacia
el funcionamiento yo pienso que sea nivel

00:33:02.000 --> 00:33:09.180
más que nada por el anunciado de
monitorización y estados de los recursos

00:33:09.180 --> 00:33:13.120
Que yo tenga un problema en un nodo, que
no porque ya se ha colgado yo no sea consciente

00:33:13.160 --> 00:33:16.700
de que hay ese problema, sino que
desde otro nodo hagas el chequeo.

00:33:16.740 --> 00:33:21.180
Pienso, buscando, bueno, puede
ser interesante también, sí.

00:33:22.160 --> 00:33:27.780
La definición de lo que acabo de decir, que
he dicho muchas cosas así en una, sería,

00:33:28.000 --> 00:33:32.460
hemos mejorado en la 23 ahí, ¿vale?

00:33:32.500 --> 00:33:37.060
La monitorización y la autocorrección
de los estados de los recursos.

00:33:37.780 --> 00:33:43.860
Que algo se queda puesto lo arrancamos
automáticamente con una con uno con un demonio

00:33:43.860 --> 00:33:49.100
auxiliar y matamos el primero que se pierde
el asm y un disco que no está montado en

00:33:49.100 --> 00:33:56.300
un nodo intentamos intentar montar el que
el diseño no intenta para el diseño de ese

00:33:56.300 --> 00:34:01.160
me lo vuelvo a arrancar es decir como que
han mejorado esas autocorrecciones de para

00:34:01.160 --> 00:34:02.820
que el rack sea mucho Más estable.

00:34:02.860 --> 00:34:07.460
No es una new feature en sí, pero es como
un hemos trabajado en mejorar todo esto.

00:34:09.730 --> 00:34:11.530
¿Sí? Ah, sí, interesante, sí.

00:34:12.300 --> 00:34:16.620
¿Tenías algo tú por ahí? Justo en
esa feature no hice los deberes, ¿eh?

00:34:16.620 --> 00:34:21.820
No te voy a engañar. Bueno, pero
estamos comenzando aquí cada uno.

00:34:21.940 --> 00:34:25.280
Además es que voy a decir una cosa: muchas
veces cuando preparamos el episodio casi siempre

00:34:25.320 --> 00:34:31.160
nos alineamos un poquito, pues aquí ha
sido como un ve mirando tú, voy mirando yo y vamos

00:34:31.160 --> 00:34:33.438
compartiendo, vamos comentando la jugada.

00:34:34.990 --> 00:34:38.650
¿Qué tienes más por ahí? ¿Rack?

00:34:38.710 --> 00:34:41.110
Poco más. Poco más, no, nada más.

00:34:43.040 --> 00:34:45.540
Esta sorpresa. Y ya está.

00:34:45.540 --> 00:34:47.540
Ahora si quieres pasamos a VR.

00:34:47.540 --> 00:34:51.280
Vamos a Data Guard. Bueno,
yo te iba a decir una.

00:34:51.280 --> 00:34:54.240
¿Tienes alguna más? Ah, venga, dispara.

00:34:54.240 --> 00:34:56.960
También en estas. Han mejorado.

00:34:56.960 --> 00:35:00.000
La detección, la resolución.

00:35:00.000 --> 00:35:07.120
De Memory Leaks. Se identifican
y se terminan procesos de memory

00:35:07.120 --> 00:35:12.740
leaking, el uso de memoria se calcula en
base del número de recursos el número de nodos

00:35:12.740 --> 00:35:19.060
del cluster, el umbral de los memory leaks
no es estático pero se calcula dinámicamente

00:35:19.060 --> 00:35:26.160
según un análisis predictivo y dice los
algoritmos de predicción diferencian entre leaks

00:35:26.160 --> 00:35:30.560
y en necesidad de incrementar la memoria
cuando tenemos nuevos recursos como como instancias,

00:35:30.600 --> 00:35:36.620
PDBs y todo esto. Y esto, dice, monitorea
todos los procesos de la Gran Infraestructura

00:35:36.620 --> 00:35:43.960
Home, sin contar el OCSSD y
el ONMD, y el comando CRSCTL

00:35:46.000 --> 00:35:49.270
Getautorecover -all. ¿Qué te parece?

00:35:50.720 --> 00:35:55.860
Bien, al final... Tenemos ahí, con el
autorecover, tendríamos ahí, pues bueno, problema

00:35:55.860 --> 00:35:58.760
en el modo y qué es lo que...

00:35:58.760 --> 00:36:06.880
tipo de problemas detecta y descripción y
se está enable con el get autorecover all trsctl

00:36:06.880 --> 00:36:10.040
get autorecover all y nos aparece ahí

00:36:12.060 --> 00:36:17.360
Nocterdisc group montado en el ASM, asm
list of resources offline, nos aparecería la

00:36:17.360 --> 00:36:21.580
lista de descripción de
problemas y en qué modo están.

00:36:21.580 --> 00:36:26.260
¿Qué te parece? Ahí te he
sorprendido, es que ahí

00:36:27.640 --> 00:36:32.520
Y veo que tenemos que, bueno, al final
separamos un poquito, ¿no?, lo que son new features

00:36:32.560 --> 00:36:36.540
y mejoras. Mejoras, muchísimas.

00:36:36.560 --> 00:36:40.960
Queremos muchas, muchas. Me vuelvo,
claro, me vuelvo a cómo has arrancado.

00:36:41.000 --> 00:36:46.740
Has arrancado el podcast diciendo, más
que new features, es new improvements.

00:36:47.360 --> 00:36:50.280
New improvements. Enhancements.

00:36:51.720 --> 00:36:55.160
Sí, sí, sí, sí, sí. Muy
bien, muy bien, muy bien.

00:36:55.220 --> 00:36:57.609
Bueno, abandonamos RAC.
¿Nos vamos a tagar?

00:36:58.880 --> 00:37:01.420
Vale, ¿o querías decir algo más de Rack?

00:37:01.420 --> 00:37:04.364
Bueno, porque yo veo cosas
Oracle Rack en containers.

00:37:05.820 --> 00:37:08.800
No sé si alguien está
interesado en contenedores.

00:37:09.900 --> 00:37:15.960
Bueno, pues están diciendo que Podman, las
imágenes permiten Clusters de Rack en Oracle

00:37:15.960 --> 00:37:20.660
Linux 8. Y que tienen
una release de 23 ahí.

00:37:21.280 --> 00:37:24.740
Para imágenes de Podman. Que
se distribuyen por GitHub.

00:37:24.740 --> 00:37:28.220
Y por el Oracle Container
Registry y bueno,

00:37:29.160 --> 00:37:33.020
sí, sí, contenedores es una de las cosas
que tengo pendientes, tengo el libro de Sean

00:37:33.060 --> 00:37:40.240
Scott que hicimos intercambio de libros
sin saberlo, sin saberlo le dije Sean, cuando

00:37:40.240 --> 00:37:43.840
tú quieres aprender español te he traído
mi libro, y él me dijo así pues yo te he traído

00:37:43.880 --> 00:37:49.960
el mío, y me ha traído el suyo firmado y
yo le dije el mío, fue un intercambio de libros,

00:37:49.960 --> 00:37:52.340
y el suyo es Oracle and Docker, entonces

00:37:53.700 --> 00:37:59.220
Tengo pendiente, se me parece interesante,
lo había planteado yo para casa.

00:37:59.220 --> 00:38:06.280
Yo tengo un PC que está destinado a
laboratorios y al final me parecía más ágil y

00:38:06.280 --> 00:38:11.600
más rápido por contenedores que no andar
con la máquina virtual para arriba y para abajo.

00:38:11.600 --> 00:38:16.780
Bueno, es interesante, cuando
nos veamos me lo regalas,

00:38:17.840 --> 00:38:20.940
me lo regalas no, el que te regaló él.

00:38:21.680 --> 00:38:25.600
Sí, sí, sí. Muy bien, pues muy bien.

00:38:25.600 --> 00:38:27.711
Venga, seguimos, ¿vamos con Data Guard?

00:38:28.160 --> 00:38:35.240
Vale, vamos allí. Si alguien tiene alguna
pregunta sobre RAC, yo creo que están pensando:

00:38:35.340 --> 00:38:37.396
"Me tenéis saturado de tanto hablar".

00:38:40.680 --> 00:38:43.940
Vamos al Data Guard. Vamos al Data Guard.

00:38:43.940 --> 00:38:46.580
Yo con Data Guard te
diría también lo mismo.

00:38:47.500 --> 00:38:49.640
Hay menos. Menos cosilla.

00:38:50.890 --> 00:38:58.280
Pero bueno, puede ser interesante alguna
heredada de la 21 vale no tenemos tampoco mucho

00:38:58.280 --> 00:39:05.660
a new features así que parece que alguna
mejora como debe ser no al final como decían

00:39:05.660 --> 00:39:10.920
en una empresa en la que trabaje si coges
un procedimiento lo sigue si no lo mejoras

00:39:10.920 --> 00:39:15.000
es que algo va mal no siempre tienes que
intentar pasar igual con las versiones de oracle

00:39:15.040 --> 00:39:22.440
no buscar la mejora bueno pero bien que
lo haga mejor hay Hay margen de mejora,

00:39:22.440 --> 00:39:26.040
¿eh? Hay margen de mejora, o sea,
está bien que desarrollen, ¿eh?

00:39:26.080 --> 00:39:27.460
Pero hay margen de mejora ahí.

00:39:27.500 --> 00:39:29.056
A ver con Mr wonderful, ¿eh?

00:39:29.100 --> 00:39:31.100
Siempre se puede si quieres, puedes.

00:39:31.420 --> 00:39:34.300
Última decir, Active Data, ya iba
a ir para Active Data Guard, ¿vale?

00:39:34.340 --> 00:39:40.240
Pero bueno, dime, venga, funcionalidad
nueva que te guste a ti de Data Guard que tengas

00:39:40.240 --> 00:39:47.810
ahí. ¿Empiezo yo? Claro, te
iba a decir que al final lo

00:39:47.810 --> 00:39:53.190
que tengo apuntado, para mí la estrella,
la superestrella es el de atacar por PDB.

00:39:53.190 --> 00:39:57.100
Ah, bueno, esperada, esperada y ansiada.

00:39:58.000 --> 00:40:03.240
Yo te iba a decir el Zero
Application Downtime para Upgrades.

00:40:05.330 --> 00:40:11.670
Sí, pero te voy a hablar un
poquito de memoria ¿Para RAC, vale?

00:40:12.090 --> 00:40:13.590
¿Se puede aplicar en RAC?

00:40:13.910 --> 00:40:21.190
¿Sí? Igual le estoy inventándome Debería
porque lo que te dice Es que te lo

00:40:21.190 --> 00:40:24.150
haces El hacer application
downtime ya es con Con

00:40:25.680 --> 00:40:33.020
Application continuity Que es como
que la aplicación continúa En Se va

00:40:33.020 --> 00:40:37.120
balanceando Y con tag,
transparent Si, transparent

00:40:38.300 --> 00:40:40.411
Transparent application continuity Si,

00:40:41.560 --> 00:40:49.000
sigo peleando Hoy en día un poquillo con
ello no vale para sentar flavia dice oracle

00:40:49.000 --> 00:40:56.340
de atacar pdb con bugs bueno
es que lo de los bugs claro

00:40:56.720 --> 00:41:04.990
ahí estamos ahí estamos
metiéndole de beta testing a

00:41:04.990 --> 00:41:09.210
todas estas cosas si me tiene yo siempre
dije toda la gente que me conoce dice que a

00:41:09.250 --> 00:41:13.610
mí deberían contratarme de tester porque
más que sistema que que me encuentro.

00:41:14.030 --> 00:41:19.050
Ya os digo, de tag me encontré uno
así grandote y ya está corregido.

00:41:21.000 --> 00:41:27.400
Añádelos a Leis, que cuando tú descubres
un bug y lo resuelves, nos da puntos para Leis.

00:41:27.820 --> 00:41:31.820
Sí, pero resolver no entraba en mi...

00:41:32.500 --> 00:41:35.444
Al final era meterse las
tripas un poco en el código.

00:41:35.500 --> 00:41:38.340
No, un parche que afecta código.

00:41:38.720 --> 00:41:46.380
No, ayudar a Oracle a resolver
un bug, ayudar es un punto bueno,

00:41:46.480 --> 00:41:53.600
si diesen puntos por encontrar te
digo, yo lo hago el Ace Master of

00:41:53.600 --> 00:41:57.480
the Universe Pero a mí
me llaman en plan broma

00:41:58.820 --> 00:42:01.000
¿Conocéis los dibujos Ladybug?

00:42:02.220 --> 00:42:07.340
Sí, Ladybug, a mí me llaman
Ladybug, sí, beso la vida, sí, sí,

00:42:08.320 --> 00:42:11.320
bueno, es que llegó Holly
a hablarla otra vez.

00:42:12.860 --> 00:42:19.660
Dime tú la tuya, cuál era la que decías,
perdona, Data Guard a nivel de PDB.

00:42:20.300 --> 00:42:26.200
Data Guard a nivel de PDB, exacto, que
Flavio nos ha apuntado aquí también: cuidado con

00:42:26.200 --> 00:42:30.500
los bugs, tenemos también aquí.

00:42:31.920 --> 00:42:37.820
Transiciones de roles más rápidas en Data
Guard en un switchover y en un fileover dice

00:42:37.820 --> 00:42:45.900
entre un 50 % 185 % más rápido al
hacer la transición de roles testado

00:42:45.900 --> 00:42:53.480
con una versión 23 .5 comparando
23 .5 de Oracle 23 ahí, con

00:42:53.480 --> 00:42:58.650
un 19, dice Bueno, mucho, ¿no?

00:42:58.650 --> 00:43:04.190
Sí, yo es un poco más de lo mismo al final
no lo tengo apuntado, cosillas para comentar

00:43:04.190 --> 00:43:09.590
pero estamos un poquito la misma que
antes, pues tenemos la gráfica y ahí hay que probarlo

00:43:09.590 --> 00:43:15.950
hay que verlo tantas veces más rápidos y
mira tenía apuntado también tag no transpar

00:43:15.950 --> 00:43:23.820
en application continuity también decía
más fiable y más rápido que nunca así

00:43:24.050 --> 00:43:31.550
bien yo lo aplaudo además
que lo uso no está guay

00:43:31.550 --> 00:43:38.480
pero al final es eso son mejoras pero
bueno que es lo que decíamos hay que mejorar hay

00:43:38.480 --> 00:43:45.560
hay que mejorar las versiones y tenía
apuntado poca cosa más o sea que me pareciese súper

00:43:45.560 --> 00:43:51.290
interesante era eso él el de pagar
por pdb y tenemos que también

00:43:53.750 --> 00:44:00.050
Preparación automática de la primaria para
un entorno de atacar vale ya existía en 21

00:44:00.050 --> 00:44:02.930
pero Pero bueno, es una mejora.

00:44:03.450 --> 00:44:10.390
Claro, hay que tener en cuenta que para 23
son las pruebas que se, o sea, o las evoluciones

00:44:10.390 --> 00:44:15.390
que se hicieron en 21, cuáles han sido las
que han continuado, pero quizá a lo mejor

00:44:15.390 --> 00:44:19.110
también lo interesante de esa que me acabas
de decir, es decir, que esa han hecho un

00:44:19.150 --> 00:44:24.020
backport a 19c. Yo es que
soy tan vieja escuela.

00:44:27.320 --> 00:44:33.300
Para verlo porque al final me da la
sensación que no tengo control de esa preparación

00:44:33.300 --> 00:44:38.940
pero cuando la funcionalidad dice que puedes
puedes definir en el observer tiempo es

00:44:38.940 --> 00:44:46.480
definir prioridades es distinta de la que
comentó a cuál dices tú es preparación automática

00:44:46.480 --> 00:44:53.860
de un entorno me adelantado si es

00:44:53.860 --> 00:44:59.000
la que vas a comentar ahora mira la tenía
apuntada también como bonita que se me gustaba

00:44:59.000 --> 00:45:03.520
también nuestras prioridades para el fast
start failover cuando te la tuya no lo voy

00:45:03.560 --> 00:45:10.650
a la mía también de 21
vales sí pero eso que no te

00:45:10.650 --> 00:45:12.330
gusta de esa está muy Ah, no, no.

00:45:12.370 --> 00:45:14.550
No digo que me guste ¿Prepare
database for dataguard?

00:45:14.590 --> 00:45:17.310
Dices, ostras, que gracias.

00:45:20.330 --> 00:45:21.670
Soy gallega, ya lo sabes.

00:45:21.710 --> 00:45:28.770
Depende depende, vale la funcionalidad
es que tú puedes configurar

00:45:28.770 --> 00:45:33.030
o puedes preparar la base de datos
para que se configure para dataguard.

00:45:33.250 --> 00:45:36.670
Entonces, el comando, aquí si tenemos el
comando, el comando sería prepare database for

00:45:36.710 --> 00:45:41.470
dataguard. Es ese comando se pondría en el
en el data guard en el broker en el broker

00:45:41.470 --> 00:45:48.520
manager entonces tú dices el perdatáis ford
atagar le dices with unique name con el

00:45:48.520 --> 00:45:54.820
recovery file de es el recovery file the
size el los broker conflict files el conflicto

00:45:54.820 --> 00:46:02.660
el 1 el conflicto el 2 vale y
el digamos exacto entonces según

00:46:02.720 --> 00:46:09.800
la según la publicidad es el primer dato
es for for dar te prepara la base de

00:46:09.800 --> 00:46:17.680
datos para para jolín para atacar
bien bonito es lo que sí pero

00:46:17.680 --> 00:46:23.200
tengo que ver qué es lo que es lo que no
me queda muy claro no he visto que es lo que

00:46:23.200 --> 00:46:27.980
modifica qué parámetros modifica, porque
al final cada maestrillo con su librillo yo

00:46:27.980 --> 00:46:33.340
tengo X parámetros que me gustan,
que suelo establecer, y al final

00:46:34.320 --> 00:46:40.100
veo que esta preparación es un poco básica
por lo que veo en la presentación que al final

00:46:40.100 --> 00:46:47.140
le dices, bueno unique name el
recovery file el recovery file de

00:46:47.140 --> 00:46:52.720
size y la configuración de broker pero
está bien que por lo menos ya tengas una

00:46:54.880 --> 00:47:00.380
Mira lo que dice Flavio Flavio
dice que tiene un post en su blog.

00:47:00.860 --> 00:47:05.380
Flavio también es ace
tiene un post en su blog.

00:47:05.460 --> 00:47:10.020
Si quieres pon aquí el enlace y si quieres
unirte a nosotros y contarnos algo más, bienvenido

00:47:10.060 --> 00:47:15.140
eres. Eres ahora que le vas a
dar 23 ahí, it's too simple.

00:47:15.380 --> 00:47:17.700
It's too simple si tiene café, solo.

00:47:18.900 --> 00:47:21.340
Sí, si tienes café, te subimos a hablar.

00:47:21.500 --> 00:47:24.860
Y si no, pues... Si no, no lo inventamos.

00:47:26.080 --> 00:47:27.960
Sí, bueno, pero no, vamos a leer tú.

00:47:28.000 --> 00:47:31.380
Venga, pues hala, sube
a hablar y nos cuentas.

00:47:31.540 --> 00:47:36.280
Y mientras sube a hablar Flavio, digo el
otro, que era el que yo estaba diciendo.

00:47:36.740 --> 00:47:40.520
En el Observer, tú puedes jugar
con la prioridad del Observer.

00:47:40.820 --> 00:47:47.400
Puedes. Es decir, que el observer preste
atención más al primary, al standby, preste

00:47:47.400 --> 00:47:48.680
atención más a uno a otro.

00:47:48.720 --> 00:47:53.980
Pero lo que quiero decir es que en estas
nuevas funcionalidades que nos cuentan de 23,

00:47:54.220 --> 00:48:00.340
que muchas evidentemente ya han sido
probadas y muchas han salido ya en 21, esta es una

00:48:00.340 --> 00:48:06.460
de las que nos dicen que en enero
de 2025 se hace un backport a 19.

00:48:06.460 --> 00:48:13.700
Es decir, ciertas funcionalidades, las
blockchain tables y todo eso fueron

00:48:13.700 --> 00:48:21.040
novedades de 21 que dijeron, bueno, pero
es que esto ya lo podemos trasladarlo a la

00:48:21.040 --> 00:48:25.000
nueva release upgrade, podemos hacer
un backport a la versión anterior.

00:48:25.000 --> 00:48:32.240
No, pues está lo de poder jugar con la
prioridad del observer está está definida

00:48:32.240 --> 00:48:39.740
para 25 de enero así que tenía
apuntada una presentación

00:48:39.740 --> 00:48:44.600
que había y lo que bueno me parecía bastante
interesante voy a hablar un poquillo de

00:48:44.600 --> 00:48:49.580
memoria vale no podías tener hasta cinco
lo que al final tiene siempre se observa que

00:48:49.580 --> 00:48:55.700
está de árbitro no y tú poder definir pues
cuando más cuando tienes le veo más sentido

00:48:55.700 --> 00:49:00.500
cuando tienes datacenters lo que estaba
está distribuido poder Dar prioridad

00:49:03.260 --> 00:49:10.360
A distancias de los servers es está bien
y tiene también unas vistas nuevas que

00:49:10.360 --> 00:49:15.800
bueno dar un poquillo más de información y
más más bonito el dato, pero bueno si está

00:49:15.800 --> 00:49:19.356
está Está interesante. También,
como decimos, viene desde la 21.

00:49:20.580 --> 00:49:22.420
Flavio, ¿qué tal? Bienvenido.

00:49:22.920 --> 00:49:25.120
Hola. ¿Cómo andas? ¿Cómo estás?

00:49:26.940 --> 00:49:29.540
Bueno, bien, bien, bien.
Vi por ahí la sesión.

00:49:29.860 --> 00:49:33.500
Dije, bueno, voy a conectar
a ver si me entero de algo.

00:49:34.320 --> 00:49:36.098
Pero bueno, entré un poco tarde.

00:49:37.020 --> 00:49:40.220
Muy bien. Cuéntanos,
estamos viendo tu blog.

00:49:40.320 --> 00:49:42.280
Vamos a ver un poquito de publicidad.

00:49:42.320 --> 00:49:49.880
Tu blog se llama... Hay algunas cosas
interesantes con el tema del Prepare

00:49:49.880 --> 00:49:55.540
Database for Data Guard, pero yo creo que
una de las cosas más relevantes, estuvieron

00:49:55.540 --> 00:50:01.680
comentando ustedes que sí, es cierto que
al final muchas de estas cosas están incluidas

00:50:01.680 --> 00:50:04.980
en la versión 21. Esto,
por ejemplo, está en la 21.

00:50:05.520 --> 00:50:12.520
¿Qué pasa? Que en la 21, pues a lo mejor
cuando ejecutabas este comandillo en el

00:50:12.520 --> 00:50:17.640
broker, Pues si no tenías alguna configuración,
como el modo archivado, por ejemplo,

00:50:17.780 --> 00:50:21.650
en la primaria, pues te podía petar, ¿no?

00:50:21.710 --> 00:50:26.270
Porque te iba a reiniciar la instancia
de la base de datos y no te avisaba.

00:50:26.370 --> 00:50:29.092
Lo hacía, digamos...
¿Reiniciaba siempre, verdad?

00:50:29.430 --> 00:50:31.350
¿Cómo? Reiniciaba siempre.

00:50:31.750 --> 00:50:38.110
Que lo ejecutabas... Sí, sí, no te
preguntábamos, lo ejecutabas y si no tenías el modo

00:50:38.110 --> 00:50:43.090
archivado, pues a llorar un poco, porque
te iba a reiniciar la instancia de la base de

00:50:43.090 --> 00:50:44.550
datos para establecerlo, ¿no?

00:50:44.590 --> 00:50:51.170
Entonces, ahora en la 23 es cierto que sí
que te hace esa validación y si no le fuerzas

00:50:51.170 --> 00:50:58.170
de alguna forma o no le confirmas
ese posible reinicio porque

00:50:58.170 --> 00:51:03.710
lo necesita, pues no lo va a hacer,
Te lo va a mostrar por la terminal.

00:51:03.710 --> 00:51:09.470
Bueno, te va a decir, oye, que hay que
reiniciar la base de datos para poder establecer

00:51:09.470 --> 00:51:10.770
el modo archivado y todo lo demás, ¿no?

00:51:10.810 --> 00:51:16.310
Entonces ya tienes, de alguna forma, esa
opción de restart, como lo llaman allí, ¿no?

00:51:16.350 --> 00:51:18.850
Para que pueda establecer esos parámetros.

00:51:19.030 --> 00:51:23.070
Entonces han ido, de alguna
forma, obviamente, mejorando, ¿no?

00:51:23.090 --> 00:51:25.990
Que es lo que suele suceder.

00:51:26.030 --> 00:51:29.590
En este caso no sería como una new feature,
sino que sería como un improvement, ¿no?

00:51:29.630 --> 00:51:31.610
De esa funcionalidad que estaba en 21.

00:51:31.650 --> 00:51:38.930
Y luego, los parámetros que éste establece,
pues están más que nada relacionados

00:51:38.930 --> 00:51:43.610
a la arquitectura MAA, que es la de
Maximum Availability Architecture, ¿no?

00:52:02.210 --> 00:52:04.270
Minimizar ese tipo de eventos, ¿no?

00:52:04.670 --> 00:52:09.710
Qué sé yo, el flashback retention,
todo ese tipo de cosas, ¿no?

00:52:11.290 --> 00:52:18.420
Pero sí. Cuando decía que tenía que
verlo un poquito funcionar, porque

00:52:18.420 --> 00:52:22.520
al final, con un comando, yo
estoy muy controladora, ¿no?

00:52:24.000 --> 00:52:26.800
No tengo conocimiento hoy en día,
que lo estás aclarando muy bien, ¿no?

00:52:26.840 --> 00:52:31.820
De qué toca por detrás como decía, al final
los DBAs tenemos nuestros parámetros que

00:52:31.820 --> 00:52:36.640
nos gustan que atendemos a esas recomendaciones
o por experiencia, lo que sea por lo

00:52:36.640 --> 00:52:42.380
que estás comentando lo cubre lo cubre, en
este caso sí, cubre un mínimo o sea, cubre

00:52:42.380 --> 00:52:49.400
un mínimo recomendado por lo que establece
en este caso el soporte para el modelo

00:52:49.400 --> 00:52:56.760
de la arquitectura que yo creo que
cubrirá el 90%, ya bueno, habrá

00:52:56.760 --> 00:53:03.600
algún 10 % por allí que que tendría que
haber algún cambio pero lo cierto es que lo básico

00:53:03.600 --> 00:53:09.440
para que funcione se entiende que lo básico
para que funcione es un poco más, porque

00:53:09.440 --> 00:53:15.960
no necesariamente Por ejemplo, tener un
flashback habilitado no es un requisito para

00:53:16.700 --> 00:53:22.720
establecer un recargar, ahora quieres
hacer una registración, obviamente te va a servir,

00:53:22.900 --> 00:53:29.760
si haces un failover, etcétera, pero no es
no es lo mínimo que necesitas para poder crear

00:53:29.760 --> 00:53:35.580
un Data Guard es ahora, es lo que
recomiendan ellos, entonces esas son cosas que establece

00:53:35.580 --> 00:53:42.820
este Prepare for Data Guard en el
broker, pero que también al final puedes

00:53:42.820 --> 00:53:50.400
hacer un cambio posteriormente, pero lo
mínimo y lo recomendado necesario te lo ayuda

00:53:50.400 --> 00:53:56.640
de alguna forma a gestionar y así, por
experiencia, si lo has probado, si no pasa nada,

00:53:56.640 --> 00:53:58.940
yo te digo, no lo he probado.

00:53:58.940 --> 00:54:05.500
Sí, sí, sí, lo he hecho, ¿aplica para solo
singeristas o por ejemplo con Rack también

00:54:05.500 --> 00:54:12.920
aplicaría? Sí, con Rack
también, efectivamente, no es

00:54:12.920 --> 00:54:19.160
una digamos, tiene
Algunas cosillas solamente

00:54:20.080 --> 00:54:26.330
en consideración, pero que sí que
funciona, sin, vamos, sin ningún problema.

00:54:27.130 --> 00:54:33.830
Podríamos dejar sin el restar preparado a
esa parametrización para después en un momento

00:54:33.830 --> 00:54:37.730
en el que podemos planificar un
reinicio y ya está, ya aplica.

00:54:37.730 --> 00:54:44.200
Muy bien, eso es así. Necesito establecer
ciertos parámetros que realmente requieren

00:54:44.200 --> 00:54:49.440
reinicio de la base de datos de la
asignación de la base de datos, pues obviamente no

00:54:49.440 --> 00:54:53.680
lo va, al momento de ejecutar el comando
te va a avisar y no lo va a hacer.

00:54:55.240 --> 00:55:00.680
Tampoco te va a hacer, te va a modificar
solamente de alguna forma los parámetros que

00:55:00.680 --> 00:55:05.200
no, que no son estáticos, que no requieren
reinicio, pero lo que esté dependiente para

00:55:05.240 --> 00:55:10.200
que pueda hacerlo, el usuario,
en este caso, el DBA, tendrá que

00:55:11.240 --> 00:55:15.730
mandarle, pues el, el
keyword ese de restart para

00:55:16.710 --> 00:55:22.160
confirmarle, es una forma de protección
simplemente, confirmarle de que, que va a poder

00:55:22.160 --> 00:55:25.880
hacer el reinicio de la base de datos,
que tiene tu consentimiento, vamos.

00:55:25.920 --> 00:55:33.050
Es que yo recuerdo cuando había salido
en la 21, comentar así con colegas, y

00:55:33.050 --> 00:55:36.750
llevarse todos el mismo susto al principio,
al final, siempre eran entornos de test,

00:55:36.790 --> 00:55:39.123
¿vale? Diciendo, ¡Jolín, qué mal me vivió!

00:55:40.230 --> 00:55:46.930
Claro, sí, en el 21 no estaba en vivo, en
el 21 simplemente iba al lío, iba y lo hacía.

00:55:47.630 --> 00:55:52.430
Microinfarto, pero bueno, al final siempre
probamos en entornos previos, que es como

00:55:52.430 --> 00:55:58.590
tiene que ser. No, pero yo recuerdo reírnos,
no de los microinfartos le llamamos.

00:55:59.590 --> 00:56:01.090
Ay, que me la he reivindicado.

00:56:01.130 --> 00:56:06.270
Fabio, cuéntanos entonces alguna
funcionalidad tuya favorita de Data Guard.

00:56:07.880 --> 00:56:14.140
Pues, a ver, yo hice un chiste con lo del
Data Guard de PDB porque yo creo que es una

00:56:14.140 --> 00:56:19.560
de las funcionalidades es que de alguna
forma más llama la atención cuando bueno, o algunos

00:56:19.560 --> 00:56:26.720
clientes el tema de Multitenant
cuando empezó era bastante

00:56:28.060 --> 00:56:33.620
Al principio como que nadie quería ir
allí, ahora obviamente te obliga porque ya no hay

00:56:33.620 --> 00:56:39.420
otro tipo de arquitectura, entonces lo que
sucede es que cuando vas a ciertos clientes

00:56:39.420 --> 00:56:44.880
que tienen una consolidación importante
porque tienen un ex -adata o lo que sea pues

00:56:44.880 --> 00:56:46.880
tienen contenedores con Muchas PDBs.

00:56:47.280 --> 00:56:51.860
Y el inconveniente que tiene eso, al
final, es que si no haces una buena arquitectura

00:56:51.900 --> 00:56:58.080
y necesitas hacer algún switchover o lo
que sea, todas tus aplicaciones que están dentro

00:56:58.080 --> 00:56:59.780
de esa continuidad serán afectadas.

00:56:59.820 --> 00:57:06.700
Entonces, empiezas a sacar un poco la
consolidación y al final también tienes tus pros

00:57:06.700 --> 00:57:13.580
y tus contras. Por un lado, la
consolidación te permite usar mejor los recursos de tus

00:57:13.580 --> 00:57:20.650
servidores. Si empiezas a separar otra
vez, entonces ya necesitas más recursos a

00:57:20.650 --> 00:57:25.130
nivel de memoria, etcétera, porque ya no
estás consolidado, estás perdiendo esa capacidad

00:57:25.170 --> 00:57:30.890
de consolidación. Pero luego te facilita
el tema de las transiciones de los roles, las

00:57:30.890 --> 00:57:33.057
pruebas que tengas que hacer, etcétera.

00:57:33.240 --> 00:57:40.220
¿qué pasa? Viene Oracle y ahora comenta
este tema del Data Guard de PDB que pudiese de

00:57:40.220 --> 00:57:46.810
alguna forma resolver esa problemática y
mantener el tema de la consolidación pero lo

00:57:46.810 --> 00:57:53.480
cierto es que todavía tiene tiene algunas
cosas que no terminan de cerrar y por ejemplo

00:57:53.480 --> 00:57:57.400
en mi experiencia con el Data
Guard con PDB Una de las razones

00:57:58.710 --> 00:58:04.310
Que a mi todavía no, yo creo que estarán
trabajando en ello de hecho estuve comentando

00:58:04.310 --> 00:58:11.150
un poco con Ludovico que es el Product
Manager que lleva todo este tema de de la arquitectura

00:58:11.150 --> 00:58:17.220
de Maximum Availability y todo esto es que
cuando tú estableces esa configuración de

00:58:17.220 --> 00:58:22.060
IPDB y haces un cambio
de rol y todo lo demás

00:58:24.230 --> 00:58:31.380
Tienes un, tienes dos problemas, uno
está relacionado con TD, que al final

00:58:32.140 --> 00:58:38.160
tendría, como son dos contenedoras
totalmente independientes al final, aquí la transición

00:58:38.160 --> 00:58:44.400
del rol lo hace ser la PDB, pero una
contenedora y la otra no están de alguna forma relacionadas,

00:58:44.400 --> 00:58:48.789
pero sí que tienen que tener las claves
de encriptación para que tú puedas pues

00:58:50.700 --> 00:58:57.700
Establecer esas transiciones, entonces
necesitas la encryption key de la CDB y la

00:58:57.700 --> 00:59:01.200
encryption key de tu PDB, tanto
en el origen como en el destino.

00:59:01.240 --> 00:59:06.670
Y si no lo haces, puedes tener esos
problemas a la hora del cambio de rol.

00:59:06.670 --> 00:59:13.740
Y el otro problema que tiene es que, por
ejemplo, si quieres tener una configuración

00:59:13.740 --> 00:59:20.720
de tener tu PDB en reroll y todo lo demás
para de alguna forma beneficiarte de lo que

00:59:20.720 --> 00:59:27.840
sería la TIC Data Guard, hay un pequeño
problema allí que no puedes crear

00:59:27.840 --> 00:59:35.220
en tu PDB primaria los stand -by
redo logs hasta que no haces la

00:59:35.220 --> 00:59:42.260
transición del roll. Es una limitación
que ahora tiene todavía 23 y que no

00:59:42.260 --> 00:59:49.320
lo han solucionado. O sea, tú ahora mismo
no puedes configurar tu PDB primaria y tu PDB

00:59:49.320 --> 00:59:56.200
secundaria, las dos con Standby Reload,
hasta que no haces al menos el primer switchover.

00:59:56.200 --> 01:00:02.680
Entonces haces el primer switchover, agregas
esos stand -by re -blogs y luego ahí ya

01:00:02.680 --> 01:00:08.140
los tienes para tus próximas, para tus
próximas transiciones de roles, pero en el primero

01:00:08.140 --> 01:00:11.480
no lo tienes, es una
limitación que tienes, ¿vale?

01:00:11.520 --> 01:00:17.740
Tú eso, pues no sé, yo pensaba que era
algún tipo de bug que había, pero no, es una limitación

01:00:17.740 --> 01:00:23.000
que todavía no, no me solucionó, al menos
en el 23 .4 cuando lo probé en su momento,

01:00:23.200 --> 01:00:30.280
¿no? Y Y después, no sé, puede haber otras

01:00:30.280 --> 01:00:32.420
más por allí que ahora mismo no recuerdo.

01:00:32.460 --> 01:00:38.540
Yo tengo una lista una lista de cositas
que cuando las vi dije, mira qué bien, me gusta.

01:00:39.900 --> 01:00:43.520
Voy diciéndolas y me decís qué os parecen.

01:00:45.780 --> 01:00:51.040
Una, la API de PLSQL para el Data Guard
Broker, para la gestión del broker.

01:00:52.170 --> 01:00:58.430
Sí. Lo dije en la sesión pasada, yo tengo
una idea que es que cuando Oracle mete cosas

01:00:58.430 --> 01:01:03.650
en el núcleo, cuando se trae al diccionario,
cuando se trae a los supply packages de

01:01:03.650 --> 01:01:09.730
PL -SQL APIs para gestionar con el data
pump, con el SQL ladder, con el broker, con lo

01:01:09.730 --> 01:01:14.530
que sea, es porque está asentando mucho
dentro del núcleo toda una funcionalidad y eso

01:01:14.530 --> 01:01:17.919
tira para adelante y eso eso no
va a ir más que a mejor, ¿no?

01:01:18.030 --> 01:01:22.810
Es decir, acercarse toda la gestión
del broker a API me gusta muchísimo.

01:01:23.780 --> 01:01:28.080
¿Qué os parece esta? Os voy diciendo las
que me gustan y luego me decís cuáles os gustan

01:01:28.120 --> 01:01:33.280
más. Sí, la tenía apuntada y es un caso de
uso, también lo veo específico, pero especificaba,

01:01:33.320 --> 01:01:35.320
¿verdad? Más de 30 nuevas funciones.

01:01:36.020 --> 01:01:44.040
Sí, dicen, ¿no? Sigo, gestión del Data
Guard desde el SQLCL, desde la consola

01:01:44.040 --> 01:01:49.020
SQLCL. Siempre lo voy a defender
porque yo soy muy SQLCL lover.

01:01:49.020 --> 01:01:52.300
Yo le saco mucho partido,
sí que lo admito.

01:01:52.300 --> 01:01:55.920
Sí. Bueno. Es una actura pendiente

01:01:57.640 --> 01:02:03.820
Pruébalo, pruébalo Tengo que perder la
virginidad con el SQLCL Uf, vas a alucinar Se

01:02:03.820 --> 01:02:10.860
te abre un mundo nuevo Y Kaskis, le tengo
tanto Tanto agarre al SQL Plus Y le tenía tanto

01:02:10.860 --> 01:02:17.600
cariño al server manager Yo siempre digo
que en SQLCL es un SQL Plus con esteroides y

01:02:17.600 --> 01:02:25.320
además tiene mucha cosilla interesante
que se le puede sacar partido yo esta

01:02:25.320 --> 01:02:31.000
la tenía apuntada pero porque me gustaba
de hecho, si no me equivoco estaba nueva, ¿no?

01:02:31.260 --> 01:02:38.270
Desde 22 .1 la versión
de SQLCL 22 .1 sí, sigo

01:02:38.270 --> 01:02:45.420
otra que me gusta mucho el tema de los
snapshots en Active Data Guard ya no ya no serán

01:02:45.420 --> 01:02:49.760
a través de develings, sino
que se harán a través de RMI.

01:02:49.880 --> 01:02:53.760
Cuando tienes el active de atacar, cuando
tienes la base de datos en redonly en la standby,

01:02:53.800 --> 01:02:55.911
el tema de la gestión de los AWR es un

01:02:56.440 --> 01:03:01.960
coñazo. Ah, AWR, ¿no? El AWR, los snapshots
de AWR Claro, cuando vas a hacer un...

01:03:01.960 --> 01:03:06.460
Entonces claro, porque te dice, estás en
solo lectura aquí no podemos escribir nada Bueno,

01:03:06.500 --> 01:03:11.180
pero configúrate el develing para ir
mirando de la primaria para hacer ese trampantojo,

01:03:11.220 --> 01:03:14.040
¿no? Ah, sí Ah, un rollo, ¿no?

01:03:14.080 --> 01:03:18.460
Entonces yo cuando vi esto me puse muy
contento digo que bien que bien tenemos el tema

01:03:18.500 --> 01:03:25.200
de tenemos resuelto esto de a través de
the link no pues lo hace a través del rm y vale

01:03:25.200 --> 01:03:31.220
con lo cual viendo entonces en data guard
En el activo de tagar podrías hacer crear un

01:03:31.220 --> 01:03:38.390
gran snapshot y podrías, pues eso,
hacerlo directamente, iría a la

01:03:38.390 --> 01:03:41.310
primaria a gestionar lo
que lo que necesites.

01:03:41.310 --> 01:03:49.240
Por ejemplo, también me gustaba mucho, y
bueno, es que luego las otras cosas son por

01:03:49.240 --> 01:03:54.420
tema de belling, habría que mirar porque,
si no me equivoco, también habla de memoria,

01:03:54.420 --> 01:04:02.080
pues un un miraba y sordo
de un SQL y que vayas

01:04:02.080 --> 01:04:03.440
a lanzar también va a través de belling.

01:04:03.480 --> 01:04:08.500
Yo supongo que si no lo ha mencionado seguirá
yendo de esa manera, que también es el

01:04:08.500 --> 01:04:12.060
trapantojo, no? Entiendo que también
va por el remedio también, no?

01:04:12.100 --> 01:04:18.100
O sea, ya no va ya no utiliza el devenir,
va internamente por el remedio, con lo cual,

01:04:18.100 --> 01:04:22.980
claro, es que eso con ese cual idea es que
él es cualidades distinto y todo esto pues

01:04:22.980 --> 01:04:29.260
ahora aún bueno, pero bueno, estas son las
que las que yo las vi y me puse muy contento

01:04:29.260 --> 01:04:36.710
más. Fácil si mira en esta
presentación porque estamos viendo

01:04:36.710 --> 01:04:44.070
esta presentación nos la dio Ludovico a
nosotros, a los tres hizo una parte de Most Wanted,

01:04:44.090 --> 01:04:47.370
de cosas que queremos entonces dice

01:04:49.300 --> 01:04:56.360
El auto -instanciation del Data Guard
per Plugable Database cosas así,

01:04:56.440 --> 01:05:00.820
cosas que ya vendrán no sé, hay

01:05:01.740 --> 01:05:05.760
casi todo van a ser mejoras y improvements

01:05:07.180 --> 01:05:13.080
Y no sé, interesante por lo menos,
que mejore a nivel de robustez, ¿no?

01:05:14.280 --> 01:05:19.460
Yo te voy a apuntar que algún día les diré
yo mira el recover database from service,

01:05:19.720 --> 01:05:21.664
¿no? que se puede hacer incremental

01:05:22.600 --> 01:05:27.100
Yo voy apuntando cosillas que dije el día
que engancha uno lo voy a volver loco que tengo

01:05:27.140 --> 01:05:29.529
aquí mi libreta de
notas esa es buena, ¿eh?

01:05:29.740 --> 01:05:36.620
Ha sido mejorado mucho desde la versión 2
.0 .2 entre recovery y front service no mejoraba

01:05:36.620 --> 01:05:39.953
un montón. Si, pero que pudiste
en incremental sería genial.

01:05:40.700 --> 01:05:45.280
De hecho, con los alumnos de la aventurera
estuvimos viendo este recovery de...

01:05:45.280 --> 01:05:47.420
Ahora tienen uno incremental.

01:05:48.270 --> 01:05:54.840
¿Sí? ¿En 23? No, no, 19 no,
yo antes de 23 ya había uno...

01:05:54.840 --> 01:05:57.507
¿Y dónde...? Sí, yo la
verdad no soy consciente.

01:05:57.820 --> 01:06:03.360
Si puedes restaurar el gap que tú tengas
en la stand -by directamente desde front service.

01:06:05.880 --> 01:06:08.040
No lo conozco, no lo conozco.

01:06:08.040 --> 01:06:11.760
Estamos súper bien, pero nos hemos
pasado un poquito de la hora.

01:06:11.760 --> 01:06:16.160
Yo tengo aquí, si queréis, para cerrar, y
os dejo que hagáis vosotros nuestro cierre,

01:06:16.200 --> 01:06:23.200
que aquí este short term plans
para las para atacar de lo que

01:06:23.200 --> 01:06:28.180
vos tratabais dice que se creen
automáticamente los ten files en la target PDB, están

01:06:28.180 --> 01:06:33.380
están trabajando en ello, vale, que Que
haga un automatic block media recovery del source

01:06:33.380 --> 01:06:37.120
PDB from the target,
del origen de la target.

01:06:38.220 --> 01:06:40.740
El parallel recovery al PDB level.

01:06:41.020 --> 01:06:44.060
Estas son funcionalidades
que tienen a short term.

01:06:44.380 --> 01:06:50.680
Y luego tienen previsto a futuro, pues
esa, la instanciación automática de los data files

01:06:50.680 --> 01:06:56.080
en la target. Y lo que decías tú, la
creación automática de los standby redo logs.

01:06:56.080 --> 01:07:02.420
Esto lo tiene marcado como mejoras a
futuro, están trabajando en ello, lo cual es esa

01:07:02.420 --> 01:07:06.940
me pasó haciendo las pruebas su historia.

01:07:06.940 --> 01:07:14.110
Claro, al final sea el problema que
la limitación pasa realmente porque tú

01:07:14.110 --> 01:07:17.950
los quieres crear, por mucho que los
quieras crear en la primaria, en la PD primaria,

01:07:17.990 --> 01:07:21.630
te dice que es un comando que
no está permitido una PD vejez.

01:07:21.630 --> 01:07:28.690
Eso lo curioso, como que no tiene un
mecanismo de detección de que esa PDB es parte

01:07:28.690 --> 01:07:31.357
de una configuración del
de pagar y por lo tanto

01:07:31.910 --> 01:07:36.990
pues pues no te deja no te deja hacerlo
hasta que haces el switch over y ya Queda como

01:07:36.990 --> 01:07:42.390
una PDB en standby, entonces ahí es cuando
lo termina solucionando, pero en el primer

01:07:42.390 --> 01:07:46.350
switch over vas a tener ese problema, ¿no?

01:07:47.050 --> 01:07:50.390
Sí, sí, sí. Bueno, mejor a la 25 ahí.

01:07:51.200 --> 01:07:58.060
A la 25. Bueno, Carla, Flavio, ¿qué tal?

01:07:58.740 --> 01:08:01.073
¿Qué tal? Se os ha pasado rápido, ¿verdad?

01:08:01.380 --> 01:08:07.420
Ay, a mí, rapidísimo. Bueno, y gracias,
Flavio, por entrar, que ha estado entretenida

01:08:07.420 --> 01:08:11.780
la cosa. Los tres seis de España.

01:08:11.980 --> 01:08:16.910
Aquí estamos, aquí. Falta más gente, ¿no?

01:08:18.090 --> 01:08:22.830
¿Cuántos somos ya? Sí, sí, sí,
somos muchos en España, pero...

01:08:22.830 --> 01:08:26.530
Bueno, cuando debes organizar una
cena, el número es el correcto.

01:08:27.530 --> 01:08:29.030
Claro que sí, claro que sí.

01:08:29.290 --> 01:08:32.130
Oye, pues un placer, Flavio, Carla.

01:08:33.630 --> 01:08:36.150
Igualmente. Y audiencia,
los que habéis estado ahí.

01:08:36.190 --> 01:08:38.023
No habíamos hablado, ¿no, Flavio?

01:08:38.290 --> 01:08:45.020
No, creo que alguna vez estuve en alguna
otra charla, que creo que era cuando estabas

01:08:45.020 --> 01:08:51.410
comentando que habías empezado en el
programa de Oracle Ace en alguna que otra cuando

01:08:51.410 --> 01:08:57.930
puedo conecto Tú fuiste a ACE al poquísimo
también, justo después de Carla me parece,

01:08:58.030 --> 01:08:59.974
justo antes. Sí, sí, sí, yo, bueno.

01:09:01.030 --> 01:09:03.974
Estaba ya, por eso fue que
me conecté, me acuerdo que

01:09:05.040 --> 01:09:07.318
en su momento ya estaba como que me había

01:09:08.060 --> 01:09:11.727
hecho la nominación y, bueno,
estaba esperando un poco ahí el tema

01:09:12.090 --> 01:09:15.470
y después pregunta, ¿llegamos
a coincidir por ahí en el spot?

01:09:15.510 --> 01:09:21.830
A Carla creo que si no la, no sé si llegó
a ir, bueno, no la vi, sí que la vi en persona.

01:09:22.150 --> 01:09:26.850
Deberíamos ir al Madrid,
al de Madrid, ¿no?

01:09:26.950 --> 01:09:31.230
Sí, sí. A ver si podemos vernos allí y con
los que estáis en la audiencia que estéis

01:09:31.270 --> 01:09:34.050
en España, pues, conocernos, si nos veis,

01:09:35.090 --> 01:09:38.590
saludarnos, no sabemos muchas veces
quiénes sois, vosotros nos conocéis a vosotros, pero

01:09:38.630 --> 01:09:44.270
no he dejado las caras, decidnos,
saludarnos, es todo todo nos gusta

01:09:45.590 --> 01:09:48.650
Tocar esa parte humana
con todos, así que...

01:09:49.230 --> 01:09:51.550
A mí es fácil verme. Flavio, Carla, guay.

01:09:51.550 --> 01:09:53.717
Los gritos que vais gritando y ya está.

01:09:54.130 --> 01:09:56.630
Eso soy yo. Qué guay, qué guay.

01:09:56.750 --> 01:10:00.990
Pues... Pues nada, damos por finalizado
este café, este episodio de podcast.

01:10:01.290 --> 01:10:02.730
Lo grabaré, lo subiré a las plataformas.

01:10:02.770 --> 01:10:09.350
Si lo estás escuchando Apple Podcast,
Spotify, iVoox, lo que sea, pues ya lo sabes.

01:10:09.530 --> 01:10:16.570
Los links, el artículo de Flavio y más cosas
en el Discord de Café de Atavés y nada,

01:10:16.730 --> 01:10:20.270
pues hasta la próxima
¿queréis decir algo de cierre?

01:10:20.290 --> 01:10:22.070
Os dejo el cierre a vosotros.

01:10:24.290 --> 01:10:30.090
Por mi parte, nada si tienen algún
feedback o lo que sea, alguna duda relacionada a las

01:10:30.090 --> 01:10:37.110
funcionalidades de B23 relacionadas al
Atagar que hice varios posts a eso pues bienvenido

01:10:37.110 --> 01:10:40.690
En el canal de Atagar he puesto tu post

01:10:42.190 --> 01:10:47.730
Ah, perfecto. Bueno, ya sabéis,
si tenéis alguna duda, a Flavio.

01:10:52.650 --> 01:10:55.380
Pues nada, un abrazo a todos, todas.

01:10:55.960 --> 01:10:57.480
Hasta la próxima.