Esquemas de contingencia para SQL Server. I Parte.

Una de las primeras labores encargadas como DBA en la empresa donde me encuentro laborando ha sido la implantación de un esquema de contingencia para asegurar una perdida mínima de datos al momento de una posible caida.

Generalmente se pensaria en implementar LogShipping... en un ambiente normal... pero en ambientes que tienen una álta restricción de puertos podemos vernos envueltos en una situación de 'escanear puertos' para concluir que puertos debe usar el LoShipping. En las siguientes entregas observaran un método de 'LogShipping Casero' que puede usar 2 técnicas: copia de archivos por Red y aplicación de Transaction Logs ó Lectura de Transactión Logs por medio de una unidad de red y aplicación directa en el servidor de contingencia.

Pero bueno... me fui a fondo con el tema. Primero un poco de fundamentos para ver de que estamos hablando y que me estaban pidiendo como DBA.

En la actualidad me encuentro administrando bases de datos SQL Server 2000 2005 y Oracle 9i (Próximamente 10g en RAC.... alguien tiene un manual para dummies... =( ). Para bases de datos Oracle como SQL Server existe un esquema de contingencia basado en copiar log de transacciones o archives en el caso de Oracle... el concepto es el mismo... el motor de base de datos lleva un registro de las operaciones realizadas sobre las bases de datos y son almacenadas en un log que en el caso de SQL Server es un archivo transaction log y en el caso de Oracle son los archivos archive que son vaciados de los redo logs. Bueno, la idea con la contingencia es aplicar estos archivos de log de transacciones en una base de datos alterna. Obviamente estabas bases de datos tienen que ser extraidas de la base de datos original... es decir, le debemos sacar un backup a la base de datos a la cual le vamos a implantar una contingencia.

Para organizar el tema realizaremos un checklist de lo que tenemos que hacer... a ver si vamos desenredando todo esto:

1. Tener un servidor al cual le queremos sacar contingencia (jejeje)
2. Preparar el servidor de producción para que pueda retroalimentar la contingencia (no me digan que la base de datos esta en modo recovery simple...)
   
3. Contar con un servidor que nos sirva de contingencia e idealmente en el caso de SQL Server que tenga el mismo Service Pack.
4. Sacar un full backup de la base de datos del ambiente de producción.
5. Restaurar el full backup en modo read only.
6. Definir frecuencia de actualización de contingencia.
7. Implantar scripts de aplicaciòn de transaction log en contingencia.
8. Monitoreo de nuestra contingencia.

Bueno, como el blog está empezando realmente es con ésta publicación no habran muchas lecturas antes de la siguiente publicación. Espero esto les sirva. si alguien me puede colaborar con lo del logo de creattive commons y todo esto les agradezco...

Espero la próxima entrega sea en 8 dias. Bye.