En esta entrada vamos a realizar la primera parte de la instalaci贸n de un SQL Server 2022 en cl煤ster de dos nodos con un grupo de alta disponibilidad Always On.
La tarea es compleja y si es la primera vez que te enfrentas a ella puedes tener dudas que no sepas resolver. En mi caso, siguiendo este documento de trabajo un par de veces, he conseguido dominar este tipo de instalaciones sin problemas.
Voy a explicar cada tarea paso a paso.
F谩cil y sencillo.
Si al ejecutarlo tienes alguna duda, me dejas un comentario y te ayudo encantado.
He dividido la instalaci贸n en tres partes:
- Creaci贸n del Cl煤ster Windows (esta entrada)
- Instalaci贸n y configuraci贸n de SQL Server 2022
- Creaci贸n de grupo de alta disponibilidad Always On
Esta primera parte est谩 divida en tres secciones:
隆Comenzamos! 鈻讹笍
Leer art铆culo completo
Ayer me toc贸 afrontar una tarea sencilla, de las del d铆a a d铆a. Algo que para cualquier DBA es de primero de primaria. Borrar unas filas de una tabla.
Aparentemente, algo muy sencillo.
- Primero, una select para ver lo que hay en la tabla
- Segundo, montamos una select para seleccionar lo que vamos a borrar y estar seguros antes de ejecutar el delete.
- Tercero, como uno es inseguro por naturaleza, hace una copia de la tabla por si acaso (create table NOMBRETABLA as select * from TABLAORIGEN).
- Cuarto, ya preparados y asegurados, ejecutamos el delete.
- Quinto, un commit, que confirme bien que hemos borrado los registros.
- Sexto y 煤ltimo paso, volver a hacer el primer select para verificar que hemos borrado los datos.
F谩cil no? Una tarea r谩pida, de las que a veces se agradecen para descansar un poco la cabeza y no tener que pensar demasiado.
Hoy, me dicen si realmente he ejecutado el borrado, que parece que los registros no se han borrado, que siguen ah铆.
What? Como es posible? 馃槺 Juro y perjuro que los he borrado.
Compruebo, y efectivamente, ah铆 est谩n. NO ES POSIBLE. Los registros siguen en la tabla. 馃槨
Repito el mismo procedimiento, vuelvo a montar las consultas (porque algo tan simple, para qu茅 lo iba a guardar?) ejecuto todo, vuelvo a comprobar, y los datos, efectivamente, ya no est谩n.
Antes de confirmar de nuevo que los he vuelto a borrar, he preferido ser m谩s conservador y esperar.
TACH脕N!! Al esperar un rato, vuelvo a comprobar, y ah铆 est谩n de nuevo, los registros han vuelto a aparecer en la tabla.
Leer art铆culo completo
Esta semana, a ra铆z de estar trabajando en una migraci贸n mediante mecanismo de TTS (Transport Tablespaces) de una versi贸n 11.1.0.7 a 19c nos hemos topado con un error que no hab铆a ocurrido anteriormente en otras migraciones del mismo tipo.
El Error
released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/28/2024 13:05:21
ORA-19870: error al restaurar parte de la copia de seguridad /home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_bbdd_fs33h9ng_1_1
ORA-19638: el archivo /oracle/base_datos/datos01/datafile01.dbf no es lo bastante actual para aplicar esta copia de seguridad incremental
ORA-19642: el SCN de inicio de la copia de seguridad incremental es 13503408614611
Leer art铆culo completo
