¿Cuál es la diferencia entre Oracle RAC y Oracle SE2HA?

¿Está pensando en actualizar a Oracle Database 19c? Una actualización a 19c proporciona a su empresa acceso al soporte principal de Oracle y una serie de nuevas funciones para ayudar a mejorar el rendimiento, mejorar la seguridad y ampliar la funcionalidad. 

Como puede que sepa o no, Oracle RAC ya no admite la creación de entornos de alta disponibilidad en Oracle 19c Standard Edition . Afortunadamente, existe una ruta de migración a SE2HA que ofrece una alta disponibilidad similar en Oracle Standard Edition. 

En el siguiente artículo, definimos las características de Oracle RAC y Oracle SE2HA y sus diferencias para ayudarlo a decidir qué opción es la adecuada para su negocio. ¡Vamos a sumergirnos!

¿Cuáles son las características de Oracle SE2HA?

1) Instancia única de base de datos activa (en ejecución) en un nodo
La base de datos es una instancia única y solo puede ejecutarse en un nodo a la vez. Si el nodo activo falla, Oracle Grid conmutará por error la instancia de SE2HA al nodo pasivo disponible. Luego, Oracle Grid inicia la instancia en un nodo pasivo. 

Grid requiere algo de tiempo para hacer esto y la aplicación no se volverá a conectar de inmediato. En este caso, deberá estar preparado para esto cuando configure su aplicación.

2) La pila de cuadrícula de Oracle está activa en todo momento en ambos nodos
La pila de cuadrícula está activa en todo momento en ambos nodos. La instancia de la base de datos es activa/pasiva.

3) Sin límite de socket por nodo
Aunque no hay límite de socket por nodo en SE2HA (un límite de socket por nodo en RAC), aún existe el límite general para SE2, 16 subprocesos. Por lo tanto, su base de datos SE2HA puede usar un máximo de 16 subprocesos en lugar de 32 subprocesos cuando usa ambos nodos en RAC.

4) El nodo inactivo no requiere una licencia de Oracle
Si bien solo puede usar los recursos de hardware de un solo nodo, el nodo inactivo no requiere una licencia de Oracle utilizando la "regla de conmutación por error de 10 días". Consulte este blog perspicaz de Oracle .  

5) No se requiere usar el inicio local de Oracle en cada nodo
Dado que una instancia nunca se ejecuta en ambos nodos, ya no es necesario que use el inicio local de Oracle en cada nodo y almacene su base de datos en ASM. 

6) Migración extremadamente fácil
Migrar a SE2HA es simple porque SE2HA usa la misma pila de Oracle Grid que Oracle RAC y la configuración de la red es la misma que Oracle RAC. 

¿Qué es Oracle RAC y cuáles son las características de Oracle RAC?

1) Oracle RAC tiene una instancia de base de datos activa (en ejecución) en cada nodo
Si cualquiera de los dos nodos deja de funcionar, una instancia activa en el nodo restante está inmediatamente lista para aceptar cualquier reconexión desde la aplicación. Los usuarios y las aplicaciones experimentarán la desconexión, pero la reconexión debería ser exitosa al instante. 

2) Limitación de un socket por nodo
Para RAC en SE2, existe una limitación de un socket por nodo (a menos que se use ODA).

3) Límite de 16 subprocesos por instancia
Para SE2, en todos los tipos de instancias (RAC, Single, SE2HA), se impone un límite de 16 subprocesos por instancia.

4) Utilizar los recursos de hardware de ambos nodos
Puede conectar una aplicación a ambos nodos, de modo que pueda utilizar los recursos de hardware de ambos nodos: hasta 32 subprocesos (límite de 16 subprocesos por instancia) más la memoria de ambos servidores. 

Es ventajoso para algunas aplicaciones y una desventaja para otras. La aplicación debe diseñarse teniendo en cuenta RAC, o puede sufrir problemas de rendimiento cuando se conecta a dos nodos.

5) Oracle Home está en cada nodo localmente; Bases de datos en almacenamiento ASM compartido
Es una práctica común tener Oracle localmente en cada nodo y bases de datos en almacenamiento ASM compartido.

Para RAC, si alguno de los dos nodos deja de funcionar, una instancia activa en el nodo restante está inmediatamente lista para aceptar cualquier reconexión desde la aplicación. Por otro lado, para SE2HA, Oracle Grid inicia la instancia en un nodo pasivo, pero la aplicación tardará unos minutos en volver a conectarse.

Puede conservar la capacidad de conmutación por error entre nodos con SE2HA , aunque los beneficios de rendimiento de RAC ya no están disponibles porque no puede utilizar el hardware del segundo nodo. Algo a tener en cuenta: no hay limitación de hardware de 'límite de 1 socket por nodo en RAC' en SE2HA. 

Es esencial tener en cuenta que ni RAC ni SE2HA ofrecen funcionalidad de recuperación ante desastres. 

Este cambio de licencia de Oracle está en línea con los segmentos de mercado EE y SE2: si necesita rendimiento, probablemente necesite EE y todas sus características. Standard Edition (y SE2HA) sigue siendo una excelente base para muchas empresas, y los 16 subprocesos deberían ser más que adecuados para la mayoría de las aplicaciones. 

Determinar cuál es mejor para su negocio: Oracle RAC u Oracle SE2HA

Si busca crear entornos de alta disponibilidad, tiene la opción de decidir entre usar el nuevo reemplazo de SE2HA o actualizar a Oracle Enterprise Edition.

En última instancia, si SE2HA es adecuado para usted se reduce a dos preguntas clave y simples:
a) ¿Son adecuados 16 subprocesos de base de datos (sesiones activas) para mi aplicación?
b) ¿Puedo aceptar que mi aplicación tarde unos minutos en volver a conectarse al nodo pasivo si falla el nodo activo?

Si respondió afirmativamente a estas preguntas, SE2HA es un reemplazo de RAC adecuado para usted. 

Conclusión

Para resumir en una oración: SE2HA es un buen reemplazo de RAC para usted si: (1) 16 subprocesos de base de datos (sesiones activas) para su aplicación son adecuados y (2) el tiempo de reconexión para aplicaciones de unos pocos minutos sin pérdida de datos también es aceptable .   

¿Cuenta su organización con un plan en caso de que un desastre (corte de energía, error humano, etc.) afecte su almacenamiento compartido o toda la instalación? Mientras planifica su ruta de actualización de RAC, le sugerimos que se tome el tiempo para revisar su plan de recuperación ante desastres. Una solución DR ( como StandbyMP ) puede proporcionar una conmutación por error rápida (RTO), una pérdida mínima de datos (RPO) y una excelente resistencia a todos los desastres.

En el próximo blog: Agregue resiliencia a los clústeres de Oracle SE2HA (o RAC) con recuperación ante desastres , lo guiaremos a través de la necesidad y los beneficios de una solución DR y cómo puede expandir su clúster SE2HA con la funcionalidad DR.

La gente a menudo pregunta sobre las diferencias entre la copia en bloque y la replicación. Adjuntamos un gran vídeo sobre la copia en bloque frente al envío de registros. El vídeo es corto y sencillo. Si bien no cubre todos los detalles minuciosos de la copia de bloques, sí destaca algunas de las diferencias muy importantes entre estos dos métodos diferentes de recuperación ante desastres.

El vídeo comienza destacando que los cambios realizados en la base de datos principal se cambian en varias áreas. Cuando un usuario actualiza los datos en la base de datos de en SQL Server o en Oracle. En Oracle esos cambios de datos se realizan en los archivos de datos reales, para deshacer los archivos de datos de tablespace y en los registros de rehacer de Oracle.

Sí, Oracle en realidad cambia de bloque en tres lugares diferentes. Eventualmente, esos cambios en los REDO LOGS se copian en un registro de archivo. Esos mismos datos residen en cuatro lugares diferentes.

Oracle hace esto porque perder datos es terriblemente malo y Oracle quiere asegurarse de que puedas recuperarte de los bloqueos. Los REDO LOGS se llaman así porque pueden "rehacer" los datos si hay un problema.

La copia en bloque a menudo se considera "similar a un zombi". No sabe la diferencia y copia todos los cambios realizados. Esto puede dar lugar a que los datos se transfieran 3-4 veces desde el sitio principal al sitio de espera. Contraste esto con el método de LOG SHIPPING. Solo se envían los ARCHIVE LOGS. Todos los cambios en la base de datos terminan en los ARCHIVE LOGS, por lo que no hay necesidad de enviar cambios redundantes. Esto significa que en lugares con ancho de banda restringido o bases de datos que son extremadamente grandes, puede ahorrar costos de red considerables.

Estos métodos de copia de bloques son a menudo una solución de "todo o nada". El peligro radica en el hecho de que si hubiera una corrupción de los datos en el sitio primario, eso se transferiría directamente al sitio secundario. Esto sería tanto por corrupción lógica de los datos como por corrupción física por fallos de hardware. Con el método LOG SHIPPING, puede hacer que la base de datos en STANDBY esté en un "tiempo configurado" detrás de la principal. Podrías construir un retraso de 2-3 horas si esa es la preferencia. Esto a menudo te daría tiempo para detener cualquier corrupción lógica antes de que llegara al sitio secundario.

La corrupción física a menudo se detiene en su camino, ya que cuando los registros se envían al sitio secundario, el software de Oracle se asegura de que los registros de archivo no estén dañados antes de que se apliquen a la base de datos de espera, lo que garantiza que ninguna corrupción física se extienda desde el sitio principal hasta el sitio de espera.

Los métodos de copia en bloque a menudo requieren una red de área de almacenamiento (SAN). El LOG SHIPPING no requiere una SAN en ninguno de los dos lados y a menudo puede usar una amplia variedad de dispositivos de almacenamiento. Las SAN también pueden ser muy caras, mientras que el LOG SHIPPING suele tener varias opciones. Al igual que una SAN, todo el mecanismo de copia en bloque puede ser un producto de software muy caro. Muchas herramientas de copia en bloque no son necesariamente compatibles con todos los diferentes proveedores de la nube disponibles en la actualidad.

Los métodos de envío de registros o LOG SHIPPING ofrecen opciones en sitio, híbridas o en la nube. Y tal vez la última "mejor" razón por la que el LOG SHIPPING es superior a la copia en bloque es que el método de LOG SHIPPING es el mismo que utilizan los propios proveedores. Oracle utiliza el LOG SHIPPING para su producto integrado Oracle Data Guard para la recuperación ante desastres. Estos productos se construyen pensando en Oracle y en LOGS, en lugar de solo una herramienta de copia de zombis.

https://dbvisit.com/blog/block-or-not