- Se incorporó
- 15 Enero 2004
- Mensajes
- 11.752
Esto no da para nota breve, es un thread descargo y en una de esas hay un colega que me de un consejo o me diga
Esta es la historia bien resumida .
A grosso modo, Oracle Database históricamente tiene dos ediciones para utilizar en empresas: la Standard y la Enterprise (no cuento la express, es juguete). La diferencia de precios es mucha pero si tienes un sistema transaccional de la puta madre la versión Enterprise vale cada puto peso porque incluye muchas características de contingencia, rendimiento y monitoreo.
La base de datos Oracle tiene una modalidad Activo-Activo pero de verdad llamada Real Application Cluster o RAC para sus amigos. Esta permite tener dos servidores (físicos o virtuales, da igual) que funcionan como una sola base de datos y si se muere un servidor el otro automáticamente toma los requerimientos sin que el administrador tenga que apretar ninguna huevada. Es suuuuper útil y a uno como sysadmin le da mucha tranquilidad para los procesos críticos.
Hasta la versión 11g de la base de datos, la modalidad RAC la podías utilizar con la edición Standard. Con eso tenías una plataforma con Alta Disponibilidad a muy bajo precio y sin limitación de cores o threads.
Luego, en la versión 12c de la base de datos Oracle dijo
"ya, descontinuamos la versión Standard pero te ofrecemos la Standard 2 al mismo precio, peeeeeroooo si quieres hacer Alta Disponibilidad con RAC vas a tener que utilizar UN SOCKET por servidor y 16 hilos de procesos en total".
y uno queda así
porque si uno quiere hacer el upgrade de 11g a 12c con manteniendo la versión barata Standard y además con Alta Disponibilidad, vas a tener que limitar tu poder de procesamiento.
Puta, ya, que se le va a hacer. Uno se arremanga los pantalones y se acomoda porque es eso o quedarse sin Alta Disponibilidad o pagar una trillonada por Enterprise.
Pero ahora con la versión 19c dijeron
"La funcionalidad de Alta Disponibilidad RAC no va más en Standard 2"
y uno
Supongo que por las quejas, Oracle sacó una opción llamada Standard Edition High Availability. Conceptualmente hablando, no es una Alta Disponibilidad sino más bien una opción de resilencia en que uno manualmente puede levantar la base de datos en otro servidor que tenías preparado de antemano si es que tu servidor principal llega a tener una falla o por mantenimiento y a nivel de punto de conexión es transparente para los servidores de aplicaciones (lo cual es super bueno), pero igual implica bajar-encender la base de datos con lo que todas las conexiones de los servidores de aplicaciones hacia la base de datos se pierden igual.
Ah, y la utilización de un servidor secundario sólo lo puedes hacer 10 días al año.
¿y qué opciones van quedando para tener una Alta Disponibilidad real sin tener que vender el riñón?
Virtualización pero con el software de Oracle, ya que Oracle te mete susto comercial si vas a meter tu base de datos a una granja VMware.
Eso sería. Ahora me voy a comprar un completo para llorar.
Esta es la historia bien resumida .
A grosso modo, Oracle Database históricamente tiene dos ediciones para utilizar en empresas: la Standard y la Enterprise (no cuento la express, es juguete). La diferencia de precios es mucha pero si tienes un sistema transaccional de la puta madre la versión Enterprise vale cada puto peso porque incluye muchas características de contingencia, rendimiento y monitoreo.
La base de datos Oracle tiene una modalidad Activo-Activo pero de verdad llamada Real Application Cluster o RAC para sus amigos. Esta permite tener dos servidores (físicos o virtuales, da igual) que funcionan como una sola base de datos y si se muere un servidor el otro automáticamente toma los requerimientos sin que el administrador tenga que apretar ninguna huevada. Es suuuuper útil y a uno como sysadmin le da mucha tranquilidad para los procesos críticos.
Hasta la versión 11g de la base de datos, la modalidad RAC la podías utilizar con la edición Standard. Con eso tenías una plataforma con Alta Disponibilidad a muy bajo precio y sin limitación de cores o threads.
Luego, en la versión 12c de la base de datos Oracle dijo
"ya, descontinuamos la versión Standard pero te ofrecemos la Standard 2 al mismo precio, peeeeeroooo si quieres hacer Alta Disponibilidad con RAC vas a tener que utilizar UN SOCKET por servidor y 16 hilos de procesos en total".
y uno queda así
porque si uno quiere hacer el upgrade de 11g a 12c con manteniendo la versión barata Standard y además con Alta Disponibilidad, vas a tener que limitar tu poder de procesamiento.Puta, ya, que se le va a hacer. Uno se arremanga los pantalones y se acomoda porque es eso o quedarse sin Alta Disponibilidad o pagar una trillonada por Enterprise.
Pero ahora con la versión 19c dijeron
"La funcionalidad de Alta Disponibilidad RAC no va más en Standard 2"
y uno
Supongo que por las quejas, Oracle sacó una opción llamada Standard Edition High Availability. Conceptualmente hablando, no es una Alta Disponibilidad sino más bien una opción de resilencia en que uno manualmente puede levantar la base de datos en otro servidor que tenías preparado de antemano si es que tu servidor principal llega a tener una falla o por mantenimiento y a nivel de punto de conexión es transparente para los servidores de aplicaciones (lo cual es super bueno), pero igual implica bajar-encender la base de datos con lo que todas las conexiones de los servidores de aplicaciones hacia la base de datos se pierden igual.
Ah, y la utilización de un servidor secundario sólo lo puedes hacer 10 días al año.
¿y qué opciones van quedando para tener una Alta Disponibilidad real sin tener que vender el riñón?
Virtualización pero con el software de Oracle, ya que Oracle te mete susto comercial si vas a meter tu base de datos a una granja VMware.
Eso sería. Ahora me voy a comprar un completo para llorar.
Última modificación:
