Preguntas y respuestas de SQLPrevención de reinicios, instalación de varias actualizaciones y mucho más.

Editado por Nancy Michell

Cómo evitar reinicios

P ¿Cómo puedo limitar el número de reinicios al aplicar revisiones y similares a SQL Server o al sistema operativo del servidor en general?

R Primero, debe ser que la mayoría de los reinicios posteriores a la instalación no están codificados en el instalador. Normalmente, son el resultado de archivos bloqueados. Esto significa que el instalador está intentado actualizar archivos que ese momento está usando otra aplicación o el sistema operativo (están bloqueados). Existe una manera directa de eliminar estos reinicios, que es asegurarse de que ningún proceso está usando los archivos en cuestión. ¿Cómo puede hacerlo?

El primer paso es determinar los archivos específicos que se estaban usando y estaban bloqueados durante la instalación. La manera más sencilla es buscarlos en el registro, en HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. La comprobación de esta clave de registro tiene dos objetivos: confirma si la solicitud de reinicio fue causada realmente por archivos bloqueados e indica los archivos que estaban bloqueados. Si consulta el registro después de la instalación, pero antes del reinicio, podrá ver la causa de la solicitud de reinicio y efectuar una serie de pasos para eliminarla en futuras instalaciones.

Puede encontrar dos tipos de entradas. Si un archivo estaba bloqueado contra lectura, verá una entrada de una línea por archivo que indica que el archivo actualizado ya está en el disco, pero que debe borrar la copia temporal que se está usando. Si un archivo estaba bloqueado contra escritura, verá una entrada de dos líneas por archivo que indica que la actualización todavía no se ha realizado, la aplicación está en un estado desconocido y no debería usarse. Es, literalmente, como detenerla en medio de la instalación. En este caso, una línea indica el archivo real y la otra apunta a un archivo temporal (que será el archivo real tras el reinicio).

El paso siguiente depende de muchos factores, pero la idea es identificar el software que está usando los archivos bloqueados. Si puede, use comprobadores de dependencia o la base de datos DLL HELP Database de MSDN® (consulte support.microsoft.com/kb/815065).

Si el software que identifica tiene un servicio, detenga el servicio manualmente y vuelva a intentarlo. Si es una aplicación, ciérrela y vuelva a intentarlo. A veces, hay varias aplicaciones usando un solo archivo y debe detenerlas todas.

El resultado de estas pruebas (en su entorno de prueba) es una lista de las aplicaciones y los servicios que debe detener en el entorno de producción antes de la instalación. De esta manera, el entorno de producción no requerirá un reinicio, ya que no habrá ningún software bloqueando los archivos que está instalando el instalador. Por supuesto, acuérdese de reiniciar estos servicios y aplicaciones cuando haya concluido la instalación.

Lo bueno es que, por lo general, los bloqueos no cambian demasiado. Así que, una vez que haya descubierto este patrón en sus sistemas, probablemente se evitará un montón de reinicios mientras dure el sistema.

Existe otro truco que vale la pena mencionar. Es posible que tenga varias versiones de SQL Server™ u otro producto instaladas en paralelo e incluso en diferentes niveles de versión. Primero, siempre debe actualizar la versión más reciente. Hay muchas posibilidades de que la actualización reemplace todo con las versiones más recientes y el resto de instancias no se ocupen del bloqueo en absoluto. Por ejemplo, si tiene tres instancias de SQL Server 2000 SP3, la primera que actualice a SP4 actualizará el archivo MSXML3.dll y requerirá un reinicio. Pongamos que realiza el reinicio en ese momento. Después, podrá reiniciar las dos instancias siguientes a SP4 sin necesidad de reiniciar, pues ya tiene el archivo MSXML3.dll actualizado. Lo mismo sucede si actualiza instancias de SQL Server 2005 antes de instancias de SQL Server 2000, y SQL Server 2000 antes de instancias de SQL Server 7.0. Esta es una estrategia general de minimización de reinicios que funciona bien.

Globalmente, los equipos de desarrollo de Microsoft han trabajado duro para detener o limitar el número de reinicios en muchos escenarios. Dado que estamos en la columna Preguntas y respuestas (Q&A) de SQL, tomemos SQL Server como ejemplo.

En SQL Server 2005, el equipo de SQL Server dividió el código de Microsoft® Data Access Components (MDAC) necesario para SQL Server en SQLNCLI (archivos nuevos), en lugar de actualizar directamente MDAC, y volvió a sincronizar MDAC con el sistema operativo. ¿Para qué sirve esto? El sistema operativo Windows® usa MDAC y bloquea estos archivos. Por este motivo la mayoría de los service packs, y otros paquetes, de SQL Server le obligan a reiniciar. Ahora, SQL Server puede actualizar su versión de MDAC sin tocar los archivos MDAC del sistema operativo que se estén usando, por lo que no tiene que realizar un reinicio.

Además, ahora, la instalación de SQL Server 2005 SP1 tiene un comprobador de dependencias y una opción de pausa integrados. De esta manera, verá lo que está bloqueado y la causa del bloqueo, y podrá detener en ese momento lo que está causando el bloqueo y continuar con la instalación sin tener que reiniciar. Esto significa que puede hacer pruebas en tiempo real sin necesidad de un laboratorio de pruebas. Por supuesto, también puede continuar y reiniciar si lo desea, o si está realizando la ejecución en modo desatendido. Fíjese lo fácil que es averiguar quién está bloqueando los archivos.

La tecnología de Microsoft Installer también controla las operaciones PendingFileRenameOperations (PFR) existentes mucho mejor. Recordará que la instalación de SQL Server 2000 se bloquea si aparece algún archivo en la clave de registro que mencionamos previamente. La instalación de SQL Server 2005 sólo se bloquea si los archivos pertenecen a SQL Server (pues se produciría un conflicto) e, incluso en esos casos, a menudo puede llegar hasta la clave PFR y actualizarla directamente sin necesidad de reiniciar. Esta tecnología se incluye, a cierto nivel, en MSI y en update.exe, los instaladores estándar de Microsoft actuales que se usan para efectuar todas las instalaciones.

¿Cuáles son algunas de las causas conocidas de estos reinicios? MSXML3.dll es una de los principales. El servicio Windows SVCHost siempre bloquea este archivo, por lo que cualquier operación que incluya este servicio, requerirá un servicio. También se encuentra en la mayoría de las pilas MDAC (mdac_typ.exe). Afortunadamente, MDAC está "sincronizado" con Windows Server® 2003 y Windows XP SP2 y posteriores. El equipo de desarrollo de SQL Server hizo un trabajo excelente al dividir msxmlsql.dll de manera que las actualizaciones de SQL Server no provocasen un reinicio, pero, de momento, sólo verá esto ocasionalmente. No se puede hacer nada al respecto, no puede cerrar SVCHost y seguir ejecutando actualizaciones.

Además, los paquetes update.exe tienen una peculiaridad en el proceso de desinstalación. Si desinstala uno, éste coloca un bloqueo (fuera de las claves PFR, por supuesto) en los archivos locales del instalador. Esto impide que otros paquetes update.exe puedan ejecutarse hasta que reinicie para eliminar el bloqueo. Todo lo que puede hacer es saberlo y programar un reinicio tras la desinstalación de revisiones.

La intermitencia es otro problema. No todos los programas dependen de un archivo el 100% del tiempo. De hecho, los DLL compartidos suelen usarse de forma puntual; es decir, que los otros programas sólo tienen acceso a ellos cuando lo necesitan, en función de su carga de trabajo y las rutas de código. Es decir, que puede hacer la prueba 10 veces y no ver ningún archivo bloqueado y, después, encontrar un archivo bloqueado en la implementación de producción. Desgraciadamente, no hay ninguna bala mágica. Intente crear el entorno de prueba lo más similar posible al entorno de producción, incluida la carga (un buen objetivo, en todo caso), y ejecute las pruebas suficientes para obtener estas permutaciones.

Las actualizaciones y los service packs del sistema operativo se reiniciarán. Además, en las versiones anteriores (Windows 2000, Windows XP y anteriores), la instalación no ha concluido hasta después del reinicio, aunque la clave de registro pendingfilerenameoperations esté vacía. Existen operaciones de registro de paquetes excepcionales que pueden ejecutarse para instalar código durante dicho reinicio. Estas operaciones ni siquiera forman parte de la instalación del service pack, son comandos incrustados en el sistema operativo actual que los escenarios de actualización desencadenan para permitir que ciertas partes del código que está usando sobrevivan a estos escenarios.

Por último, la clave PFR no realiza comprobaciones de versión de archivos ni impone un orden mediante la serialización. Esto significa que inicia las sustituciones de archivos en el orden en que aparecen. Pero se ha demostrado que el orden en que se aplican al disco duro es el último en terminar (no el primero que se inicia). Esto tiene sentido, pero significa que, si tenemos dos copias del mismo archivo en la misma ruta, cada una apuntando a versiones diferentes, el resultado tras el reinicio será aleatorio. Si alguna vez experimenta esto, asegúrese de arreglarlo. Si no está seguro, simplemente vuelva a ejecutar los dos instaladores después del reinicio. Si tiene los archivos correctos, ninguno realizará ninguna acción. Si tiene los erróneos, el paquete que tenga el archivo correcto lo arreglará. Sinceramente, esto es más rápido y más seguro que intentar averiguar el resultado deseado.

Varias instalaciones del service pack

P Tengo ocho instancias de SQL Server 2000 agrupadas en un clúster de 4 nodos y deseo instalar SP4 con el mínimo posible de reinicios. ¿Puedo instalar SP4 en las 8 instancias, una detrás de la otra, y reiniciar todos los nodos al final?

R A Una vez que ha concluido la instalación de una sola instancia de SQL Server SP4, que puede requerir un reinicio, en un servidor Windows determinado (agrupado o no), no debería necesitar reinicios adicionales al instalar SQL Server SP4 en las demás instancias de SQL de ese cuadro. Esto es así porque todos los archivos compartidos (herramientas, MDAC, MSXML, etc.) ya tienen la versión adecuada y, bloqueados o no, no necesitan actualizarse. Todos los archivos no compartidos se usan únicamente en la primera instancia y la instalación los cerrará. Es importante recordar que la instancia más reciente de SQL Server debe actualizarse primero si se tienen varias instancias de diferentes versiones.

Ejecución como un servicio de red

P ¿Qué es exactamente la cuenta AUTHORITY\NETWORK SERVICE de NT y para qué sirve? ¿Y cuáles son las implicaciones de seguridad de esta cuenta, especialmente si se le otorgan derechos sysadmin (sa)?

R Una cuenta del servicio de red tiene la misma identidad (identidad de equipo) que un sistema en la red, pero tiene privilegios reducidos en el cuadro local. Así, si un servicio requiere acceso a los recursos de red, quizás para resolver los nombres de cuenta con el controlador de dominio, debe ejecutarse como un sistema, una cuenta de dominio o un servicio de red. Normalmente, el servicio de red es la opción más segura, ya sólo se limita a un cuadro local e, incluso en éste, tiene privilegios reducidos.

Al convertir el servicio de red en administrador del sistema en SQL Server, los demás servicios que se ejecuten como servicio de red en un cuadro local tendrán un control total sobre el servidor. Esto sucede, por ejemplo, cuando la cuenta de servicio de SQL Server está configurada para ejecutarse como servicio de red. El servidor requiere que la cuenta de servicio de SQL Server sea miembro de sysadmin para su funcionalidad (por ejemplo, para permitir conexiones de bucle invertido). No es muy seguro ejecutar el servicio de red como administrador en SQL Server, pero es mejor (o no) que usar una cuenta de dominio con este fin y mucho más seguro que ejecutar SQL Server como un sistema local.

Si no desea que el servicio de red tenga los privilegios de sysadmin, la siguiente opción es usar una cuenta de dominio dedicada específicamente a ejecutar SQL Server en una o más instalaciones de Windows NT®.

Encontrará ayuda en los artículos siguientes: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp y microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Creación de varias bases de datos

P Estoy pensando en repartir los datos en bases de datos individuales, quizás 250 bases de datos en línea a la vez. Calculo que sólo se usará el 20% a la vez para consultas activas. ¿Es mejor tener muchas bases de datos que tener pocas?

R El número de bases de datos en una instancia de servidor de bases de datos depende de las necesidades empresariales y de factores administrativos. La creación de varias bases de datos en una sola instancia de servidor conlleva poca carga, pero tener más bases de datos implica una mayor carga administrativa en lo que se refiere a tareas de mantenimiento como copias de seguridad y restauración, creación de reflejos, cuentas de usuario y funciones de usuarios. La complejidad administrativa adicional puede pesar más que la ventaja de tener bases de datos adicionales.

Como regla general, todos los datos relacionados con una aplicación deben mantenerse en una base de datos, lo que facilita la recuperación tras un error. Si los datos de una aplicación están repartidos en varias bases de datos, habrá que recuperar todas las bases de datos durante un error. Esto puede retrasar la recuperación o incluso impedirla si no se puede recuperar una de las bases de datos.

Dicho esto, hay varios motivos para separar los datos en varias bases de datos:

• Un subconjunto de datos tiene requisitos de copia de seguridad diferentes a los de otros datos.
• Determinados datos requieren un contexto de seguridad independiente, es decir, un propietario de base de datos diferente.
• A veces, los datos existen con fines históricos y deben estar en modo de sólo lectura.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson y Madhusudhanan Vadlamaani.

Editado por Nancy Michell

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.