SAP ASE: La Base de Datos Antes Conocida Como Sybase

En el dinámico mundo del software empresarial, las adquisiciones y la evolución tecnológica son constantes. Una de las historias más relevantes en el ámbito de las bases de datos es la de Sybase, una compañía que, tras su adquisición por parte de SAP, se transformó y potenció para convertirse en lo que hoy conocemos como SAP Adaptive Server Enterprise (SAP ASE). Esta base de datos relacional tiene una rica historia y sigue siendo un pilar fundamental para muchas organizaciones que confían en las soluciones de SAP.

SAP adquirió Sybase, Inc. en 2010 con un objetivo claro: acelerar el alcance de sus soluciones a través de plataformas móviles y ayudar a las empresas a gestionar y analizar información y procesos de negocio en cualquier dispositivo. Esta unión estratégica no solo amplió la presencia de SAP en el mercado móvil, sino que también fortaleció su oferta de plataforma de datos. Al combinar la potencia de la tecnología in-memory con las soluciones de Sybase, SAP buscaba ofrecer una plataforma de datos robusta para lograr una mayor agilidad empresarial.

¿Qué es SAP ASE? El Legado de Sybase SQL Server

Lo que originalmente se conocía como Sybase SQL Server, y que popularmente aún se refiere como Sybase DB o Sybase ASE, es ahora oficialmente SAP Adaptive Server Enterprise. Se trata de un servidor de base de datos de modelo relacional que fue desarrollado inicialmente por Sybase Corporation. Su historia está entrelazada con otros grandes nombres de la industria del software.

En 1988, Sybase, Microsoft y Ashton-Tate colaboraron en el desarrollo de una versión de SQL Server para OS/2. Aunque Ashton-Tate se retiró posteriormente, Microsoft continuó y adaptó el sistema a Windows NT. Cuando el acuerdo expiró en 1993, Microsoft adquirió una licencia para el código fuente y comenzó a vender este producto como Microsoft SQL Server. Debido a esta historia compartida, MS SQL Server y Sybase SQL Server (ahora SAP ASE) comparten muchas características y peculiaridades de sintaxis, aunque evolucionaron por caminos separados.

Una Mirada al Pasado: La Evolución de Sybase/SAP ASE

La historia de esta base de datos se remonta a 1987, cuando Sybase Corporation lanzó su primer sistema de gestión de bases de datos relacionales, inicialmente comercializado bajo el nombre Sybase SQL Server. Su creador, Bob Epstein, trajo consigo ideas innovadoras de hardware de bases de datos, apostando por el potencial del software de bases de datos ejecutándose en hardware estándar.

Una característica clave que hizo que Sybase SQL Server fuera atractivo desde el principio fue su alto rendimiento. Esto se lograba gracias a características de diseño como las escrituras de log compartidas, los índices agrupados y un bajo consumo de memoria por usuario. Como resultado, ofrecía un buen rendimiento "listo para usar".

Repasemos algunas de sus versiones clave y las características que introdujeron:

• Sybase SQL Server 4.2 (1992): Introdujo internacionalización, localización y soporte para sistemas de multiprocesamiento simétrico (SMP).
• Sybase SQL Server 10.0 (1993): Tras la separación del acuerdo de desarrollo conjunto con Microsoft, Sybase lanzó System 10. Esta familia de productos incluía, además del servidor de base de datos (SQL Server 10.0), componentes como Back-up Server, Replication Server (para sitios replicados), Navigation Server (un servidor paralelo shared nothing), APIs Open Client/Server, SQL Monitor, SA Companion y OmniSQL Gateway.
• Sybase SQL Server 11.0 (1995): Una nueva iteración del motor de base de datos.
• Sybase SQL Server 11.5 (1996): Marcó un hito al cambiar el nombre a Adaptive Server Enterprise (ASE) para diferenciarlo de Microsoft SQL Server. Añadió prefetching asíncrono, la expresión CASE en SQL, optimizaciones del uso de índices descendentes y el Logical Process Manager para priorización.
• ASE 11.9.2 (1998): Mejoró el soporte para bloqueo a nivel de página y fila, introdujo joins distribuidos y un rendimiento SMP mejorado. Se añadieron índices descendentes, la opción de concurrencia readpast y el aislamiento de transacciones repeatable read.
• ASE 12.0 (1999): Añadió soporte para Java, alta disponibilidad (HA) y gestión de transacciones distribuidas (DTM). Se introdujeron los merge joins, además de los nested loop joins existentes, y particiones de caché para mejorar el rendimiento.
• ASE 12.5 (2001): Incorporó asignación dinámica de memoria, un contenedor EJB, soporte para XML, SSL (Secure Sockets Layer) y LDAP. También se añadieron backups comprimidos, soporte para unichar UTF-16 y múltiples tamaños de página lógica (2K, 4K, 8K, 16K).
• ASE 15.0 (2005): Una versión mayor que incluyó soporte para particionar filas de tablas en dispositivos de disco individuales y "columnas virtuales" calculadas solo cuando son necesarias. Muchos parámetros estáticos se hicieron dinámicos, mejorando el rendimiento y reduciendo el tiempo de inactividad.
• ASE 15.5 (2010): Lanzada poco antes de la adquisición por SAP. Añadió soporte para bases de datos in-memory y de durabilidad relajada, gestión de transacciones distribuidas en clústeres shared-disk, compresión más rápida para backups y soporte para IBM Tivoli Storage Manager. También se incluyeron resolución de nombres diferida para procedimientos almacenados, cifrado de contraseñas FIPS 140-2, transferencia de datos incremental, tipos de datos bigdatetime y bigtime, y grupos tempdb.
• ASE 15.7 (2011): Lanzada bajo la propiedad de SAP. Incluyó nuevas características de seguridad, un nuevo kernel basado en hilos, compresión para objetos grandes (LOB) y datos regulares, autenticación Kerberos End-to-End CIS, control dual de claves de cifrado, arranque desatendido seguro, perfiles de inicio de sesión, ALTER... modify owner, contraseñas externas y texto oculto. También se añadieron Abstract Plans en Cached Statements, Shrink Log Space, LOBs In-Row Off-Row, uso de LOBs en procedimientos almacenados, select for update, columnas no materializadas y no nulas con valor por defecto, DDL completamente recuperable, comando merge y filas de longitud variable expandida.
• ASE 16 (2014): Esta versión introdujo bloqueo de particiones, soporte CIS para HANA, límites de consulta relajados, optimización de planes de consulta con Star Joins, asignación dinámica de hilos, mejoras en los operadores Sort y Hash Join, auditoría de texto completo, auditoría de comprobaciones de autorización en procedimientos almacenados, funcionalidad create or replace, estadísticas de ejecución y plan en HTML, compresión de índices, cifrado completo de base de datos, mejoras en bloqueo y latencia en tiempo de ejecución, soporte para múltiples triggers, eliminación de datos residuales, seguimiento del historial de configuración, comprobaciones CRC para dump database y cálculo de la tasa de crecimiento del log de transacciones.

Esta cronología muestra cómo SAP ASE ha evolucionado continuamente, incorporando características avanzadas para satisfacer las crecientes demandas del entorno empresarial.

Gestión Esencial: Copias de Seguridad de SAP ASE en SAP (Azure)

Mantener la integridad y disponibilidad de los datos es crucial. La copia de seguridad es una tarea fundamental. A continuación, se detalla el proceso para realizar copias de seguridad de bases de datos SAP ASE (Sybase) que se ejecutan en máquinas virtuales de Azure utilizando Azure Backup, basándonos en la información proporcionada.

Antes de configurar la copia de seguridad, hay una serie de requisitos previos:

• Identificar o crear un Recovery Services vault en la misma región y suscripción que la VM de SAP ASE.
• Permitir conectividad de la VM a Internet para alcanzar Azure.
• La longitud combinada del nombre de la VM del servidor SAP ASE y el nombre del Resource Group no debe exceder 84 caracteres (para VMs ARM).
• La VM debe tener Python >= 3.6.15 (se recomienda 3.10) y el módulo 'requests' de Python instalado.
• Se debe ejecutar el script de pre-registro de configuración de SAP ASE (como usuario root) en la máquina virtual donde está instalado ASE. Este script prepara el sistema ASE para la copia de seguridad.
• Si se usan Private Endpoints, ejecutar el script de pre-registro con el parámetro -sn o --skip-network-checks.
• Asignar privilegios y configuraciones específicos para la operación de copia de seguridad al usuario de la base de datos, como `oper_role`, `map external file`, `own any database`. La opción `allow incremental dumps` para la base de datos debe ser `True` y `trunc log on chkpt` debe estar deshabilitada.
• Asignar roles de Azure, como `Virtual Machine Contributor`, a la entidad de seguridad (usuario, grupo o service principal) para permitir la configuración de la protección.

El flujo de trabajo del script de pre-registro es el siguiente:

• Crea un grupo necesario para los usuarios del plugin.
• Instala y actualiza paquetes como waagent, Python, curl, unzip, Libicu, PythonXML.
• Verifica el estado de waagent, la conectividad a wireserver e IMDS, y la conectividad TCP a Microsoft Entra ID.
• Confirma si la región geográfica es compatible.
• Verifica el espacio libre para logs, en el directorio waagent y en /opt.
• Valida si la versión de Adaptive Server Enterprise (ASE) es compatible.
• Inicia sesión en la instancia SAP usando las credenciales proporcionadas, habilitando el historial de dumps, necesario para copias de seguridad y restauraciones.
• Asegura que la versión del sistema operativo es compatible.
• Instala y actualiza módulos Python necesarios como requests y cryptography.
• Crea el archivo de configuración de la carga de trabajo.
• Configura los directorios necesarios bajo /opt para las operaciones de copia de seguridad.
• Cifra la contraseña y la almacena de forma segura en la máquina virtual.

Para ejecutar el script de pre-registro, se utilizan comandos bash como descargar el script, convertirlo a formato Unix (`dos2unix`), cambiar permisos (`chmod`), y finalmente ejecutarlo con los parámetros requeridos (`sudo ./<script name> -aw SAPAse --sid <sid> --sid-user <sid-user> --db-port <db-port> --db-user <db-user> --db-host <private-ip-of-vm> --enable-striping <enable-striping>`, etc.), proporcionando la contraseña de la base de datos cuando se solicite.

La creación de un rol personalizado para Azure Backup implica ejecutar una serie de comandos `isql` conectándose a la base de datos como usuarios con diferentes privilegios (sapsso, sapsa) para crear el rol (`create role azurebackup_role`), otorgarle el rol `oper_role`, habilitar permisos granulares (`sp_configure 'enable granular permissions', 1`), otorgar el privilegio `map external file`, añadir un nuevo usuario (`sp_addlogin backupuser, <password>`), otorgar el rol personalizado a ese usuario (`grant role azurebackup_role to backupuser`), establecerlo como rol por defecto (`sp_modifylogin backupuser, "add default role", azurebackup_role`), otorgar el privilegio `own any database` al rol personalizado, habilitar el acceso a archivos (`sp_configure "enable file access", 1`), habilitar backups diferenciales (`sp_dboption <database_name>, 'allow incremental dumps', true`), y deshabilitar `trunc log on chkpt` (`sp_dboption <database_name>, 'trunc log on chkpt', false`).

La conectividad de red es vital. La base de datos SAP ASE en Azure VM requiere conectividad a Azure Backup service, Azure Storage y Microsoft Entra ID. Esto se puede lograr mediante:

• Private endpoints: Permiten backups sobre IPs privadas en la VNet. Tienen costos asociados.
• Service tags (NSG): Fáciles de gestionar, sin costos adicionales, pero dan acceso al servicio completo.
• FQDN tags (Azure Firewall): Fáciles de gestionar, usados con Azure Firewall.
• Permitir acceso a IPs/FQDNs del servicio: Sin costos adicionales, funcionan con cualquier appliance de seguridad, pero pueden requerir acceso a un conjunto amplio de IPs o FQDNs.
• Virtual Network Service Endpoint: Para Azure Storage (plano de datos).
• Network Virtual Appliance: Para todos los servicios, pero puede añadir sobrecarga.

Es posible usar un proxy HTTP para el tráfico de Microsoft Entra ID si no se usan private endpoints o acceso directo, configurando un archivo `ExtensionSettingsOverrides.json`.

El proceso de creación de un Recovery Services vault se realiza a través del portal de Azure, especificando suscripción, grupo de recursos, nombre del vault y región. El vault debe estar en la misma región que la fuente de datos. Dentro del vault, se puede habilitar la restauración entre regiones (`Cross Region Restore`).

Para descubrir las bases de datos, se accede al Recovery Services Vault, se selecciona + Backup, se elige SAP ASE (Sybase) en Azure VM como tipo de origen de datos, y se inicia el descubrimiento. Se descarga y ejecuta un script pre-post en las VMs para dar permisos a Azure Backup. Luego, se seleccionan las VMs en el portal y se hace clic en Discover DBs. Azure Backup registra la VM e instala una extensión.

La configuración de la copia de seguridad implica ir a Configure Backup, crear o seleccionar una política de copia de seguridad. La política define la frecuencia (diaria/semanal para full, diaria para diferencial, por log para transaccional) y la retención (mínimo 7 días para cualquier tipo, hasta 99 años para full on-demand). Se configura la política de Full, Diferencial (si se habilita) y Log (si se habilita). Luego, se seleccionan las bases de datos a proteger y se habilita la copia de seguridad.

Para ejecutar una copia de seguridad bajo demanda, se va a Backup items en el vault, se selecciona el tipo de gestión SAP ASE, se ven los detalles de la base de datos y se selecciona Backup now. Se elige el tipo de backup (Full o Diferencial) y se confirma. La retención de un full on-demand es de mínimo 45 días y máximo 99 años; la de un diferencial on-demand sigue la retención de log de la política.

SAP ASE en el Ecosistema SAP

La adquisición de Sybase por parte de SAP en 2010 no solo significó un cambio de nombre y propiedad para la base de datos, sino que la integró profundamente en la estrategia de SAP. SAP ASE se posicionó como una opción de base de datos robusta y fiable para diversas soluciones SAP, complementando otras tecnologías de base de datos dentro del portaficio de SAP, como SAP HANA. Su capacidad para manejar grandes volúmenes de transacciones y su arquitectura escalable la hacen adecuada para cargas de trabajo empresariales críticas.

Preguntas Frecuentes sobre SAP ASE (Sybase)

¿Qué es la base de datos Sybase en SAP?

Sybase era una empresa de software adquirida por SAP en 2010. Su principal producto de base de datos relacional, Sybase SQL Server, ahora se llama SAP Adaptive Server Enterprise (SAP ASE) y es una base de datos clave dentro del portafolio de SAP, utilizada para gestionar y analizar información empresarial.

¿Cómo se llama Sybase ahora?

El producto principal de base de datos de Sybase, Sybase SQL Server, ahora se llama SAP Adaptive Server Enterprise (SAP ASE).

¿SAP es propietaria de Sybase?

Sí, SAP adquirió Sybase, Inc. en julio de 2010. Desde entonces, Sybase opera como una subsidiaria de SAP America, y sus productos, como la base de datos ASE, forman parte del portafolio de SAP.

¿Para qué se utiliza SAP ASE?

SAP ASE se utiliza como un servidor de base de datos relacional de alto rendimiento para aplicaciones empresariales críticas, incluyendo diversas soluciones de SAP. Es conocido por su capacidad para manejar grandes volúmenes de transacciones y su escalabilidad.

Conclusión

La historia de Sybase y su transformación en SAP ASE es un claro ejemplo de cómo las tecnologías evolucionan y se integran en ecosistemas más amplios. SAP ASE, con su legado de rendimiento y fiabilidad, sigue siendo una plataforma de datos vital para muchas organizaciones. Desde sus orígenes como Sybase SQL Server hasta su estado actual como una base de datos adaptativa dentro del portafolio de SAP, ha demostrado su capacidad para evolucionar y ofrecer funcionalidades avanzadas. Comprender su historia, sus características y los procedimientos esenciales como la gestión de copias de seguridad es fundamental para cualquiera que trabaje con esta robusta base de datos en el entorno SAP.

Si quieres conocer otros artículos parecidos a SAP ASE: La Base de Datos Antes Conocida Como Sybase puedes visitar la categoría Bases de datos.