blog

Últimamente hemos recibido varias preguntas de diferentes clientes respecto a las diferencias entre las versiones Enterprise y Standard de Oracle Database, básicamente para saber cuál de estas ediciones encaja mejor con sus necesidades.

Usando un símil con los taladros, la Enterprise Edition sería un taladro potente, que podemos usar en cualquier superficie (ladrillo, hormigón, madera, metal) que atornilla/desatornilla y al que podemos conectar multitud de complementos que nos permitirán trabajar más rápidamente, con más precisión o realizando tareas que quizá podrían haber obligado a comprar otras herramientas (como lijar o cortar). Este sería el taladro imprescindible en la caja de herramientas de un buen carpintero, cerrajero, paleta, etc.

Por otra parte, si en casa colgamos algún cuadro de vez en cuando, necesitamos un taladro que permita taladrar muros y madera fácilmente, que sea práctico y fiable. Esta sería la versión Standard Edition del taladro, que no debería faltar en la caja de herramientas de ningún manitas.

Entrando un poco más en detalle, antes de nada aclarar que en este post no tengo intención hacer lista detallada de todas las diferencias entre ambas versiones, únicamente comentaré las más relevantes o que he detectado como más útiles en el día a día con nuestros clientes. Indicar también que no entraré en diferenciar las versiones XE (gratuita), Standard Edition y Standard Edition One pues ya las explicamos en este post.

A modo de recordatorio: algunas de las opciones o packs de Oracle Database Enterprise Edition, que comentaré a continuación, requieren ser licenciadas por separado de la BBDD.

El punto de partida obligado, para conocer en detalle las diferencias entre todas las versiones de Oracle Database, es esta página web de Oracle.

Desde mi punto de vista destacaría en Oracle Database Enterprise Edition:

• La primera funcionalidad que destaca en una Enterprise Edition (EE en adelante) sobre una Standard Edition (SE en adelante) es, en mi opinión, la posibilidad de utilizar los packs de Diagnostics y de Tuning. Nos ofrecen la mayor y más detallada cantidad de información sobre el funcionamiento de la BBDD que os podáis imaginar (existen otros productos que hacen cosas parecidas, pero ninguno que los llegue a igualar), así como la posibilidad de ajustar de manera automática el rendimiento de nuestras sentencias SQL. En la SE no existe la opción de usar estas funcionalidades, lo que implica tener que controlar el estado y ajustar el rendimiento del gestor de manera tradicional (trazas de selects, vistas dinámicas V$ o herramientas como statspack -que se basa en las dos anteriores-).
• Otra funcionalidad presente sólo en EE, y que creo que es importante y se tiene poco en cuenta, es el paralelismo. En EE una única sentencia SQL puede paralelizarse y usar varias CPU’s/cores de manera simultánea, mejorando notablemente el tiempo de respuesta en algunos casos. En SE no es posible paralelizar y una sentencia SQL no puede usar al mismo tiempo más de 1 CPU/core.
• La siguiente funcionalidad importante, o incluso imprescindible en algunos casos, sería el particionado (que es otra opción solo disponible en EE). Mediante particionado podremos trabajar de manera mucho más eficiente con grandes volúmenes de datos. La técnica consiste en repartir los datos según alguna regla (por fechas, rangos, hash) en diferentes tablas que llamaremos particiones (cada una sólo contiene los datos que cumplen cierta condición, p.e. un determinado mes o día, un cierto rango o cierto hash). El usuario verá todas las particiones como una única tabla (el particionado le es trasparente) y al realizar operaciones sobre esta tabla la BBDD realmente solo accederá a las particiones donde sabe que encontrará los datos que buscamos (nos despreocupamos, es automático). El particionado también es muy útil para historificar datos, ya que podemos intercambiar particiones entre diferentes tablas. En SE todo este tipo de funcionalidades las tendremos que simular mediante programación o con operaciones manuales que normalmente requieren paradas de mantenimiento o son mucho mas lentas.
• Otra funcionalidad digna de mención es la referida al control de recursos. En SE podemos crear perfiles, mediante los cuales limitar el consumo de recursos de los usuarios; por ejemplo podemos evitar que una sesión consuma más de una determinada CPU o que este inactiva más de determinado tiempo, en tales casos la sesión será desconectada. En EE vamos más allá y disponemos de un Gestor de Recursos, con él podremos decidir mediante un sistema de prioridades quién puede disponer de CPU y en qué porcentaje frente al resto (permite “repartir la CPU” según nos convenga). Una sesión que llegue al límite de la CPU asignada no podrá usar más y tendrá que esperar (no será desconectada) hasta que disponga nuevamente de tiempo asignado.
• Otra diferencia importante entre EE y SE es la de poder disponer de una BBDD Standby (copia física bit a bit de la principal) que nos proporcionará una solución de Disaster Recovery robusta y eficiente que puede llegar a asegurar una pérdida de datos cero en caso de desastre. Las BBDD Standby han aumentado en funcionalidades y rendimiento con cada nueva versión de la BBDD: en versión 11g podemos usar la Standby también como entorno de pruebas, aplicando cambios y al final de estos “rebobinando” la BBDD para dejarla nuevamente como Standby; la podemos usar como entorno “puente” en migraciones y upgrades; podemos tenerla “abierta en solo lectura” (mientras sigue actuando como Standby) para poder hacer el reporting o lanzar selects en ella descargando de trabajo la principal (esto último requiere licenciar la opción Active Data Guard). La versión SE no dispone de Standby y, si bien existen soluciones parecidas manuales (acostumbran a ser “recovers” continuados realizados mediante tareas programadas), quedan muy lejos de las funcionalidades que aporta Oracle Data Guard.
• Tanto la EE como la SE disponen de Flashback Query, esto es, pueden lanzar sentencias SQL para ver los datos en un momento del pasado. Pero las opciones de Flashback Table, Flashback Database (rebobinar la BBDD) y Flashback Transaction Query sólo están disponibles en la EE.
• En el apartado de auditoria estándar (control de accesos de usuarios, accesos a tablas y acciones realizadas) las funcionalidades son idénticas entre una BBDD EE y una SE. No obstante, si queremos ir más allá y hacer cosas de tipo “auditar sólo si se accede a cierta columna consultando datos que superen unas ciertas condiciones y desde unos terminales concretos” tendremos que usar la opción Fine Grained Auditing presente solo en EE.
• Otra opción existente sólo en EE es la Virtual Private Database, que permite que 2 usuarios distintos vean datos diferentes accediendo a una misma tabla con la misma select. La propia BBDD hace un “filtrado” de los datos que puede ver/modificar el usuario según unas reglas establecidas previamente, esto permite controlar de manera muy detallada el acceso a los datos independientemente de cómo se conecten los usuarios. En SE esto se puede realizar programándolo dentro de la aplicación, pero se tiene que evitar que los usuarios accedan mediante otras aplicaciones no controladas (que no dispongan de los filtros pertinentes).
• Operaciones online y compresión son otros puntos fuertes específicos de la BBDD EE. Podemos reorganizar y/o modificar de forma online (con usuarios trabajando) tablas e índices. Los tipos avanzados de compresión de tablas, índices, exports y backups de RMAN también son posibles sólo en la EE (en algunos casos se requiere licencia separada).
• Finalmente tenemos Real Application Testing, que nos permite “grabar” las acciones realizadas por los usuarios en una BBDD y repetirlos en otra. Con esto podemos probar de manera “real” qué pasaría si cambiamos de servidor, si realizamos una modificación en la aplicación, si aplicamos un parche o si subimos de versión la BBDD, comprobando la mejora obtenida o detectando y permitiendo solucionar, con anterioridad a la puesta en producción, los problemas que puedan aparecer.

Como contrapartida, el punto fuerte de la versión Standard Edition es su menor coste, no sólo por ser más económicas las licencias (tanto de tipo NUP como de tipo Processor) sino también por el método usado para licenciar, ya que licenciaremos “sockets” en vez de “cores”, como explicábamos en este post.
Por ejemplo, para un servidor con 2 CPU’s Intel x86 Octacore:

• En EE tendremos que comprar licencias para 8 Processors (16 cores en total x 0,5 que es el factor de conversión para arquitectura Intel x86) o como mínimo para 200 NUP’s (mínimo de 25 NUP’s por cada Processor).
• En SE tendremos que comprar licencias para 2 Processors (el servidor dispone de 2 sockets) o como mínimo para 5 NUP’s (compra mínima).

Notar que no es posible licenciar maquinas con más de 4 Sockets con Standard Edition.

Espero que toda esta información os ayude a decidir si precisáis o no la versión Enterpise de Oracle Database, para cubrir vuestras necesidades.