Hoy os voy a hablar sobre el proceso de actualización de SQL Server 2005, en un entorno de cluster, aunque ciertos pasos también aplican en un entorno StandAlone.

El proceso de actualización dentro de esta versión de SQL Server es un proceso complejo, donde podemos encontrar diferentes puntos de fallo, de los que suelen poder evitarse muchos, siguiendo las siguientes recomendaciones.

Tareas previas:

1.- Como tarea preventiva, y debido a que esto podría retrasarnos la instalación, vamos a comprobar que los ficheros MSI/MSP que se encuentran disponibles en cada uno de los nodos, son los necesarios para el proceso de actualización:

                Para ello, accederemos a la siguiente URL, http://support.microsoft.com/kb/969052/en-us

                Y generaremos el script FindSQLInstallsOnly.vbs

                Una vez generado, lanzaremos el script de la siguiente manera:

Cscript FindSQLInstallsOnly.vbs %computername%_sql_install_details.txt

Revisaremos la salida del script buscando que cada uno de los MSI/MSP están presentes en la cache de sistema, si encontramos la siguiente salida:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! C:\WINDOWS\Installer\XXXXX DOES NOT exist in the Installer cache. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

                Tendremos que revisar antes de lanzar el proceso de instalación los paquetes MSI/MSP.

2.- Además, sería aconsejable confirmar que los permisos de los diferentes servicios de SQL Server son correctos.

                Para una lista de los mismos, tanto permisos a nivel de sistema, como permisos a nivel NTFS, se aconseja revisar la siguiente lista:

http://msdn.microsoft.com/en-US/library/ms143504(v=sql.90).aspx#Review_NT_rights

*3.- Comprobar con que formato tienen los servicios de SQL Server aplicada la cuenta de usuario que levanta los mismos.

                En caso de que el usuario que figura en esta cuenta está del siguiente modo:

                                usuario@dominio

                Modificar por dominio\usuario

Tareas inmediatamente previas:

1.- Comprobaremos que haya backups de las bases de datos de sistema y de usuario, y que son correctos.

*2.- Comprobaremos que desde los 2 nodos, la resolución directa e inversa de los nodos del cluster, más el recurso de cluster, son correctas:

                Para ello lanzaremos un “ping” hacia los 3 objetos, más un “ping –a”

• Un nslookup no nos valdría, debido a que podemos tener la resolución en DNS correcta, pero podemos tener alguna entrada en el fichero de host, o alguna entrada en la cache de direcciones que no sea correcto.

*3.- Comprobaremos que los servicios”Cryptographic Service”, "Remote Registry Service", "Remote Procedure Call Locator", "Remote Procedure Call Service", "Server" y “Task Scheduler” están levantados y funcionando en ambos nodos.

*4.- Comprobaremos que el shared folder “tasks” del nodo pasivo es accesible desde el activo, y que no hay ninguna tarea creada fuera de las habituales (Buscaremos que no existan tareas de “SQL Server Setup”).

*5.- Comprobaremos que podemos acceder desde el nodo1 a la ruta tasks, dentro de la instalación de Windows (como ejemplo, \\nodo2\c$\Windows\tasks) y que podemos escribir en esa ruta, y viceversa con el usuario que lanza el setup.

*6.- Comprobaremos que no existen usuarios conectados a través de escritorio remoto al nodo secundario.

7.- Comprobaremos que el usuario que lanza el setup de SQL Server es administrador local en todas las maquinas involucradas para esa instancia de SQL Server, y que dispone de los siguientes permisos locales como mínimo:

                a. Act as Part of the Operating System

                b. Bypass Traverse Checking

                c. Log on as Batch Job

                d. Log on as Service

                e. Replace a Process Level Token

8.- Comprobaremos que SQL Server está online.

9.- Tenemos que tener en cuenta que una actualización de SQL Server implica parada de servicio mientras actualiza las BD de sistema.

*10.- Lanzaremos la actualización desde el nodo activo.

Tareas inmediatamente posteriores:

*1.- Una vez realizada la actualización, reiniciaremos el nodo pasivo. Una vez reiniciado, realizaremos un failover sobre este nodo, y reiniciaremos el nodo pendiente de reiniciar.

2.- Comprobamos que la actualización se ha realizado correctamente, comprobando el fichero summary.txt dentro del directorio de setup bootstrap.

Todas las tareas marcadas con un *, son exclusivas de un cluster.

Moisés Romero Senosiain – Microsoft Customer Support Services