Backups y restauraciones en SQL Server (II): modelos de recuperación.

En este segundo artículo vamos a ver los modelos de recuperación existentes en SQL Server y las características principales de cada uno de ellos.




Existen tres modelos de recuperación distintos: Full Recovery, Simple Recovery y Bulk-Logged Recovery (http://msdn.microsoft.com/es-es/library/ms189275(v=sql.90).aspx ). Cada modelo determina como debería comportarse el registro de transacciones, tanto en el uso activo como durante el backup del registro de transacciones.

• Full Recovery (recuperación completa): modelo de recuperación por defecto para una BBDD recién creada. Todo el historial de transacciones se mantiene en el registro de transacciones que deberíamos administrar. Su ventaja es que se puede restaurar hasta el momento en el que una BB.DD. falla, o hasta un punto específico en el tiempo. Su desventaja es que si lo dejamos sin administrar, el registro de transacciones puede crecer rápidamente. Si se llena el disco, lo más probable es que la BB.DD. falle. Este modo no ofrece ningún tipo de mantenimiento automatizado del registro de transacciones. La única forma de limpiar es cambiar al modo de recuperación simple o realizar una copia de seguridad del registro de transacciones.
  
   
• Simple Recovery (recuperación simple): limpia el registro de transacciones activo de las transacciones realizadas durante un checkpoint. Su ventaja es que el registro de transacciones se mantiene y no necesita una administración directa. El inconveniente es que, en caso de desastre, está garantizado un cierto nivel de pérdida de datos. Es imposible restaurar el momento exacto del fallo. A pesar de que este modo de recuperación trunca el registro de transacciones periódicamente, esto no conlleva a que no crezca. Podemos fijar el tamaño del registro de transacciones a un determinado tamaño, pero si se ejecuta una inserción masiva (Bulk Insert), SQL Server lo tratará como una inserción simple. Por tanto, no sirve como respuesta para el mantenimiento de logs por lo que no deberíamos usarlo en BB.DD. en producción.
  
   
• Bulk-Logged Recovery (recuperación de registros masiva): Cuando se utiliza este modelo, el registro de transacciones se comporta exactamente como si se estuviese en modo de recuperación completa, con una excepción: las operaciones masivas se registran mínimamente. Las operaciones masivas incluyen:
  • Importaciones masivas de datos, que se podrían realizar haciendo uso de BCP (Bulk Copy Program), el comando BULK INSERT u OPENWROWSET con la cláusula Bulk.
  • Operaciones LOB (Large OBject), tales como WRITETEXT o UPDATETEXT, para columnas NText o Image.
  • Cláusulas SELECT INTO.
  • CREATE INDEX, ALTER INDEX, ALTER INDEX REBUILD o DBCC REINDEX.
  
      Como todas estas operaciones se registran en el modelo Full Recovery, el registro de transacciones puede crecer enormemente. La ventaja del modelo Bulk-Logged Recovery es que previene de un crecimiento del registro no deseado o imprevisto. Cada vez que se realiza una operación de registro masiva, SQL Server sólo registra los identificadores de las páginas de datos que se han visto afectados. Las páginas SQL Server tienen identificadores internos, así que se puede comprimir un aumento de identificadores de páginas en una pequeña parte del registro.
  Este modelo de recuperación tiene la desventaja de que la recuperación en un punto del tiempo no es técnicamente posible. Sólo podemos restaurar al punto de la última copia de seguridad del registro de transacciones. Será posible recuperar las transacciones masivas siempre y cuando se disponga de un backup del registro de transacciones que las contiene. Por otra parte, mientras que el registro de transacciones activo en este modo es más pequeño, la copia de seguridad del log contiene copias de las páginas modificadas durante el proceso de carga masiva. El resultado son copias del registro de transacciones potencialmente grandes.
  La clave para utilizar este modelo de recuperación de forma efectiva es invocarlo sólo cuando sea necesario, y a continuación, volver al modo de recuperación completa para un punto en el tiempo del backup. Se trata de un procedimiento de riesgo, y para mover entre Bulk-Logged Recovery y Full Recovery, siempre debemos seguir los siguientes pasos:

1. Cambiar de Full Recovery a Bulk-Logged Recovery.
2. Realizar la operación de registro masivo.
3. Una vez completado, volver inmediatamente al modo Full Recovery.
4. Realizar un backup completo de la BB.DD.

En el próximo artículo veremos algo de transact SQL…

Backups y restauraciones en SQL Server (I): Almacenamiento en disco

Vamos a comenzar una serie de artículos destinados a comprender los entresijos básicos de SQL Server. Considero que es crítico comprender cómo almacena SQL Server los datos y los escribe en disco, para comprender los requisitos de cualquier técnica de backup de SQL Server. Tipos de archivo utilizados:

• Ficheros de datos primarios: cada BB.DD. tiene un único fichero de datos primario con la extensión por defecto .MDF. El fichero de datos primario es el único que tiene no sólo la información contenida en la BB.DD. sino también la información sobre la propia BB.DD. Cuando la BB.DD. es creada la ubicación de cada archivo se almacena en la BB.DD. master, pero también se incluye en el fichero de datos primario.
• Fichero de datos secundarios: una BB.DD. también puede tener uno o varios ficheros de datos secundarios que tienen por defecto la extensión .NDF. Generalmente se utilizan para crear espacio de almacenamiento en unidades de disco distintas a la del fichero de datos primario, o para mantener el tamaño de cada fichero de datos individual en un tamaño máximo práctico, por lo general, por cuestiones de portabilidad.
• Registro de transacciones: una BB.DD. debe tener al menos un fichero de registro de transacciones con una extensión por defecto .LDF. El registro o log es imprescindible pues sin un registro de transacciones accesible, no se podría realizar ningún cambio en la BB.DD. Para la mayoría de las BB.DD. en producción es crítico un sistema de copia de seguridad adecuado para el registro de transacciones. Cuando se realiza un cambio en la BB.DD. se hace en el contexto de una transacción: una o más unidades de trabajo que deben tener éxito o fallar en su conjunto.

Cuando se realiza un cambio en la BB.DD. los datos no se escriben directamente en los archivos de datos. En su lugar, el servidor de BB.DD. primero escribe el cambio en el registro de transacciones. Cuando se complete la transacción, se marcará como confirmada en el registro de transacciones. Esto no significa que los datos se muevan desde el registro de transacciones al fichero de datos. Una transacción confirmada sólo significa que todos los elementos de la transacción se han completado satisfactoriamente. El caché de buffer se puede actualizar, pero no necesariamente el fichero de datos. Periódicamente se realiza un punto de control. Esto le indica a SQL Server que se asegure de que todas las transacciones realizadas son escritas en el fichero de datos apropiado.
Los puntos de control pueden realizarse por estos motivos:

• Alguien lanza un comando Checkpoint.
• Se alcanza el intervalo de recuperación configurado en la instancia (ver imagen). Esto indica con qué frecuencia se producen los puntos de control.
• Se realiza una copia de seguridad de la BBDD (en modo de recuperación simple).
• La estructura de archivos de BB.DD. se ve alterada (en modo de recuperación simple).
• El motor de la BB.DD. se ha detenido.

El proceso de escritura de datos a disco se realiza de forma automática, como se indica en el siguiente esquema:

No se escribe directamente a un fichero .mdf o .ndf. Todos los datos primero van al registro de transacciones (.ldf), siguiendo los pasos siguientes:

1. Se ejecuta algún tipo de comando INSERT, UPDATE o DELETE.
2. Los datos se escriben inmediatamente a la caché de log interna.
3. El caché de log actualiza el fichero de log físico (.ldf) y realiza cambios en el buffer caché de datos.
4. El buffer caché de datos se limpia eventualmente y el fichero de datos (.mdf o .ndf) se actualiza.

Cuando se realiza un backup de la BBDD, sólo los datos actuales y los ficheros del registro de transacciones se escriben a disco. Las transacciones realizadas que aún no se han escrito a disco permanecerán en el log de transacciones y se actualizan durante el proceso de recuperación mientras la BBDD se vuelve a conectar. Las transacciones incompletas se revierten durante la recuperación.

En el siguiente artículo veremos los modos de recuperación de SQL Server.

Instalando una nueva versión de Tomcat con Business Objects XI 3.1 bajo Windows.

1. - Instalación de una versión nueva del servidor de aplicaciones Tomcat. La versión del servidor Tomcat que se instala por defecto con Business Objects XI 3.1 es la 5.5.20. Existen diversas mejoras en las versiones 6.x.x por lo que vamos a ver cómo a actualizar Tomcat. Comentar que SAP no proporciona soporte en el caso de que decidamos modificar tanto la versión de Java como la de Tomcat que viene por defecto con Business Objects. En primer lugar vamos a descargarnos la nueva versión de Apache Tomcat desde uno de los repositorios existentes. Podemos encontrar en la web oficial del proyecto, http://tomcat.apache.org/ , los repositorios existentes. Hemos seleccionado el de RedIris por proximidad geográfica: http://apache.rediris.es/ . En nuestro caso, nos hemos descargado la versión 6.0.20.

NOTA: en el momento de publicar este post ya nos podemos descargar la versión 6.0.24 que incluye algunas mejoras para evitar fugas de memoria, en concreto de memoria de tipo PermGen.

En segundo lugar, vamos a comprobar los requisitos de la instalación de esta nueva versión. Comprobamos que es necesario tener instalado Java JRE 5.0 o posterior. Vamos a la consola del servidor en el que vamos a instalar Tomcat, y comprobamos la misma a través del comando:

Java –version

En esta versión de Tomcat que nos proponemos instalar, no nos va a servir de nada modificar nuestras variables de entorno debido a que se utiliza una aplicación para modificar las opciones de Java. Al final de este artículo veremos como modificar los distintos parámetros. Lo siguiente que vamos a comprobar es que no existe un servicio con el mismo nombre al que vamos a instalar. Tenemos que tener en cuenta que el nombre mostrado no tiene por qué ser el mismo que el nombre del servicio. En “Herramientas Administrativas” - “Servicios”, podemos encontrar un listado de los servicios existentes. Buscamos “Apache Tomcat”, pulsamos con el botón derecho sobre el servicio, y seleccionamos “Propiedades” y podremos ver el nombre real del servicio:
 

En la pantalla anterior podemos ver el servicio de Apache Tomcat que se instala por defecto con Business Objects XI 3.1. El nombre del servicio es “BE120Tomcat” aunque el nombre que se muestra es “Apache Tomcat 5.5.20”. El nombre del servicio nos va a servir para eliminarlo en el caso de que fuese necesario.  Para ello, abrimos la consola y utilizamos:

sc delete “Nombre del servicio”

Los servicios existentes pueden provocar un error en el proceso de instalación, de forma que nos indicaría que no tenemos los privilegios necesarios para instalar (en nuestro caso) “tomcat6w.exe”, que es el binario del servicio Windows de Apache Tomcat. En principio nos va a servir el deshabilitarlo simplemente.

Procedemos a instalar el servidor Tomcat.
 

En la elección de componentes, podemos iniciar automáticamente el servicio marcando el checkbox “Service”:  

En la siguiente pantalla nos pedirá la ruta en la que queremos instalar por defecto Tomcat (dejamos la que aparece por defecto), y en la siguiente pantalla debemos introducir el puerto con el que trabajará Tomcat, y el usuario y contraseña del administrador del servidor.  

Por último, se nos pide la ruta donde tengamos instalado el entorno de ejecución de Java:  

Una vez instalado, podemos comprobar que nos aparece el servicio y que el mismo está levantado:

Y podremos comprobar su funcionamiento accediendo mediante un navegador a la URL http://localhost:8080/ (en el caso de haber seleccionado el puerto que viene por defecto, el 8080).
 

 
2.- Despliegue de las aplicaciones de Business Objects.

Una vez que tenemos el servidor Apache Tomcat instalado y funcionando correctamente vamos a proceder a instalar las distintas aplicaciones de Businness Objects 3.1. Para ello vamos a realizar un despliegue de los ficheros .war guardados en la ruta C:\Archivos de programa\Business Objects\BusinessObjects Enterprise 12.0\java\applications .

Tenemos dos opciones, hacer un despliegue “tradicional”, es decir, o bien copiar los .war en el directorio webapps y Tomcat se ocupará automaticamente de desplegarlos, o bien a través de la consola de administración de Tomcat (http://localhost:8080/manager/html).

Y la segunda opción, por la que nos vamos a decantar, es utilizar los ficheros de lotes “wdeploy” ubicados en C:\Archivos de programa\Business Objects\deployment . En este caso deberemos realizar unas modificaciones previas antes de ejecutarlos desde consola.
En primer lugar, el fichero config.tomcat55 tendremos que modificarlo para indicar la ruta de instalación de nuestro nuevo Tomcat (“as_dir”) y el nombre del servicio (“as_service_name”). Y en el fichero tomcat55.xml buscar la referencia al ejecutable de Tomcat (versión 5.5 por defecto) y sustituirla por la de nuestra nueva versión 6 . La nueva línea quedaría así:

Una vez realizados estos cambios podemos hacer un deploy de todos los .war o bien desplegar una de las aplicaciones en concreto:

wdeploy tomcat55 deployall

o por ejemplo desplegar la aplicación CmcApp:

wdeploy tomcat55 -DAPP=CmcApp deploy 
 

   
De esta forma habremos conseguido cambiar de versión nuestro servidor Tomcat y realizar el correcto despliegue de las aplicaciones de Business Objects.
Para finalizar indicar que los valores que he utilizado, en mi caso, para Java, haciendo uso de tomcat6w.exe (y no de las variables de entorno) son:

-Dcatalina.home=C:\Archivos de programa\Apache Software Foundation\Tomcat 6.0
-Dcatalina.base=C:\Archivos de programa\Apache Software Foundation\Tomcat 6.0
-Djava.endorsed.dirs=C:\Archivos de programa\Apache Software Foundation\Tomcat 6.0\endorsed

-Djava.io.tmpdir=C:\Archivos de programa\Apache Software Foundation\Tomcat 6.0\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\Archivos de programa\Apache Software Foundation\Tomcat 6.0\conf\logging.properties
-Dcom.sun.management.jmxremote
-Daf.configdir=C:/Archivos de programa/Business Objects/Dashboard and Analytics 12.0
-XX:PermSize=256m
-XX:MaxPermSize=384m
-Xms512m
-Xmx512m
-XX:+UseConcMarkSweepGC